Події безпеки — це журнал активності Вашої Організації: кожен вхід, зміна дозволів, рух коштів і зміна конфігурації, із зазначенням того, хто, звідки й коли виконав дію. Для інституційних команд це інструмент, який дає відповіді на питання комплаєнсу, підтримує внутрішні аудити та своєчасно виявляє аномалії.
Події безпеки охоплюють активність усієї Організації:
Категорія | Приклади подій |
|---|---|
Вхід і сесія | Вхід виконано, вихід виконано, невдалі спроби входу, виклики та зміни 2FA |
Пристрої | Пристрій підʼєднано, пристрою надано довіру, пристрій схвалено, пристрій відкликано |
Рух коштів | Запит на виведення створено, кошти зараховано, переказ ініційовано та завершено |
Адреси | Адресу виведення коштів додано, оновлено, видалено |
Команда | Ролі створено, оновлено, видалено; ролі призначено учасникам і знято з них |
АРІ ключі | API-ключ створено, оновлено, видалено |
Облікові записи | Обліковий запис створено, додано до Організації або видалено з неї |
Схвалення | Запит на затвердження створено, рішення щодо затвердження подано — у всіх робочих процесах. |
Політики | Політику оновлено, заблоковано, розблоковано |
Невдалі спроби входу фіксуються поряд з успішними. Серія невдалих входів із незнайомої локації — це саме той сигнал, який покликаний показувати цей інструмент.
Кожна подія відповідає на питання, які аудитор або фахівець з реагування на інциденти ставить насамперед:
Стовпець | Що це показує |
|---|---|
Дія | Що сталося, зрозумілою мовою: вхід виконано, запит на виведення створено, API-ключ створено |
Ініціатор | Хто виконав дію — учасник або API-ключ, що її ініціював |
OS | Операційна система пристрою, з якого виконано дію |
Браузер | Браузер або клієнт, з якого виконано дію |
Розташування та IP-адреса | Географічне походження та IP-адреса запиту |
Ідентифікатор запиту | Для регульованих операцій — запит на затвердження, який авторизував дію |
Дата | Коли це сталося |
Події, що виникли в межах сесії клієнта, містять повний контекст клієнта: ОС, браузер, розташування та IP. Події, які система виконує від імені клієнта, натомість містять Request ID: контекст клієнта зберігається в подіях затвердження відповідного запиту.
Коли виконується регульована операція, її події безпеки містять ідентифікатор запиту на затвердження, що стоїть за нею. За Request ID Ви можете відкрити запит і побачити, хто його ініціював, хто затвердив, хто відхилив і коли було прийнято кожне рішення.
Так замикається аудиторський ланцюжок. Для будь-якого руху коштів або адміністративної зміни Ви можете відновити повний ланцюжок: дію, запит за нею та осіб, які її підписали, — не виходячи з продукту.
Прямі операції — входи, зміни пристроїв і облікових даних — фіксуються як події без Request ID, оскільки за своєю природою не потребують затвердження.
Доступ до подій безпеки регулюється тією самою моделлю, що й решта функцій: видимість визначається відповідними рівнями робочого процесу в профілі робочого процесу учасника.
Періодичний огляд доступу. Відфільтруйте зміни ролей і політик за період перевірки. Кожна зміна повʼязана зі своїм запитом на схвалення через ID запиту — Ви бачите зміну та її авторизацію в одному вікні.
Розбір інцидентів. Невдалі входи та незнайомі місцезнаходження одразу впадають в очі у стовпці «Місцезнаходження та IP». Відфільтруйте за учасником, щоб відтворити повну активність сесії.
Звірка. Події переміщення коштів містять ID запиту, тож фінансова команда може зіставити записи в леджері із запитами та схваленнями, що їх спричинили.
Стовпці «Виконавець», «ОС», «Браузер» і «Місцезнаходження та IP» визначають, хто виконав дію і звідки. Якщо виконавцем є учасник, зверніться до нього безпосередньо. Якщо активність справді невідома — незнайоме місцезнаходження або пристрій — розцінюйте це як можливу компрометацію: деактивуйте учасника або відкличте відповідний API-ключ і зверніться до Служби підтримки.
ID запиту мають лише керовані операції. Прямі операції — входи, зміни пристроїв, зміни облікових даних — завершуються без запиту на схвалення за задумом, тому стовпець для них порожній.
Події, виконані системою від імені клієнта, — наприклад, зміни, застосовані після схвалення запиту, — не мають власної клієнтської сесії. Перейдіть за ID запиту до запиту на схвалення: події ініціювання та перегляду запиту містять клієнтський контекст залучених осіб.