Аудиторські журнали та сліди доступу
1) Призначення та область застосування
Мета: забезпечити доказовість дій користувачів/сервісів, прозорість розслідувань, відповідність вимогам регуляторів і внутрішніх стандартів (GDPR/AML, договори з PSP/KYC-провайдерами, ISO/PCI при застосовності).
Охоплення: всі прод-системи, платформні сервіси (акаунт, платежі, антифрод, КУС/санкції, RG), адмін-панелі, API-шлюзи, DWH/BI, інфраструктура (K8s/хмара), інтеграції з вендорами.
2) Що логувати (класи подій)
1. Ідентифікація та доступ: логін/логаут, MFA, зміна паролів/ключів, SSO, «break-glass» доступ.
2. Адміністративні дії: зміни ролей/прав, конфігурацій, правил антифроду/санкцій, фіча-прапори.
3. Операції з PII/фінданими: читання/експорт/видалення, вивантаження, доступ до KYC, перегляд VIP-профілів.
4. Транзакції та гроші: кеш-аути/депозити, скасування, повернення, рішення по чарджбекам.
5. Комплаєнс/AML/KYC: результати скринінгу (санкції/PEP/Adverse Media), рішення (TP/FP), EDD/STR/SAR.
6. Інциденти та безпека: ескалації, зміни правил WAF/IDS, ізоляція сервісів, ротація секретів.
7. Інтеграції/вендори: виклики API, помилки, таймаути, експорти, підтвердження видалення/повернення даних.
3) Обов'язкові поля події (мінімум)
`event_id` (UUID), `ts_utc`, `ts_local`, `source_service`, `trace_id`/`span_id`
'actor _ type'( user/service/vendor),'actor _ id'( стійкий ідентифікатор),'actor _ org'( якщо B2B)
`subject_type` (account/tx/document/dataset), `subject_id`
`action` (e. g., `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `WITHDRAWAL_APPROVE`)
`result` (success/deny/error) и `reason`/`error_code`
'ip','device _ fingerprint','geo'( країна/регіон),'auth _ context'( MFA/SSO)
'fields _ accessed '/' scope'( при роботі з PII/фінданими) - з маскуванням
'purpose '/' ticket _ id'( основа: DSAR, інцидент, запит регулятора, операційна задача)
4) Незмінюваність і доказовість
WORM-сховище для «золотої» копії (immutable buckets/retention policies).
Криптопідпис/хеш-ланцюжок: періодичний підпис пачок подій та/або побудова ланцюжка хешів (hash chaining) для виявлення модифікацій.
Журнал змін схем/правил: версіонуємо схеми і політику логування; будь-які правки проходять CAB.
Двоконтурне зберігання: оперативний індекс (пошук) + архів/immutability.
5) Синхронізація часу і трасування
Єдиний NTP/Chrony у всіх середовищах; в логах -'ts _ utc'як джерело істини.
У кожен лог -'trace _ id '/' span _ id'для наскрізного трасування запитів (кореляція між сервісами, вендорами і фронтом).
6) Приватність і секрети
Заборонено: паролі, токени, повні PAN/CSC, повні номери документів, «сира» біометрія.
Типове маскування: e-mail/телефон/IBAN/PAN → токени/часткове відображення.
Псевдонімізація: 'user _ id'→ стабільний токен в аналітиці; прив'язка до реального ID - тільки в захищеному контурі.
DSAR-сумісність: можливість вибіркового вилучення логів по суб'єкту без розкриття сторонніх PII.
7) Терміни зберігання та рівні (ретеншн)
8) Доступ і контроль (RBAC/ABAC)
Ролі читання аудиторських логів відокремлені від ролей адміністрування.
MFA і Just-in-Time доступ (break-glass) з автовідзивом/логуванням причин.
Політика «мінімуму»: доступ до полів PII/фінданих тільки за необхідності і з фіксацією'purpose'.
Експорт/вивантаження: білі списки адресатів і форматів; обов'язковий підпис/хеш, журнал вивантажень.
9) Інтеграція з SIEM/SOAR/ETL
Потік audit-подій надходить в SIEM для кореляцій (e. g., масові'READ _ PII'+ вхід з нового пристрою).
SOAR-плейбуки: авто-тікети при порушенні політик (ні'purpose', аномальний обсяг, доступ поза вікном).
ETL/DWH: вітрини'audit _ access','pii _ exports','admin _ changes'з контролем якості і версійністю схем.
10) Якість даних і валідатори
Схеми як код (JSON/Protobuf/Avro): обов'язкові поля, типи, словники; CI-валідатори.
Відбраковка і quarantine-черга для подій з помилками схеми; метрики шлюбу.
Дедуплікація/ідемпотентність по'( event_id, trace_id, ts)'; Контроль повторної відправки.
11) RACI
12) SOP: Розслідування доступу до даних
1. Тригер: алерт SIEM (аномальний'READ _ PII '/експорт), скарга, сигнал від вендора.
2. Збір артефактів: вивантаження подій по'actor _ id '/' subject _ id '/' trace _ id', журнал'purpose', супутні логи (WAF/IdP).
3. Перевірка законності: наявність підстави (DSAR/інцидент/службове завдання), узгодження, вікон доступу.
4. Оцінка впливу: обсяг/категорії PII, юрисдикції, ризик суб'єктам.
5. Рішення: інцидент-бридж (при High/Critical), containment (відгук доступів, ротація ключів).
6. Звіт і CAPA: причини, порушені політики, заходи (маскування, навчання, зміни RBAC), терміни.
13) SOP: Експорт даних (регулятор/партнер/DSAR)
1. Запит → верифікація підстави та особистості (для DSAR) → формування запиту в DWH.
2. Знеособлення/мінімізація за замовчуванням; включення PII тільки при правовій підставі.
3. Генерація вивантаження (CSV/JSON/Parquet) → підпис/хеш → запис в журнал вивантажень (хто/коли/що/кому/підстава).
4. Передача через затверджений канал (sFTP/Secure link); термін зберігання копії - за політикою.
5. Пост-контроль: підтвердження отримання, видалення тимчасових файлів.
14) Метрики та KRIs/KPIs
Coverage: частка критичних систем, що відправляють audit-події ≥ 95%.
DQ-помилки: події, відкинуті валідатором, ≤ 0. 5% від потоку.
MTTD втрати потоку: ≤ 15 хв (алерт при тиші).
Аномальні доступи без'purpose': = 0 (KRI).
Час відповіді на розслідування: медіана ≤ 4 год, P95 ≤ 24 год.
Експорти з підписом/хешами: 100%.
Дотримання ретеншну: видалення/архіви в термін ≥ 99%.
15) Вимоги до вендорів і субпроцесорів
DPA/SLA: опис audit-логів (схеми, терміни, географія, формат експорту), WORM/immutability, SLA повідомлень про інциденти.
Доступ вендора: іменовані сервісні облікові записи, журнали їх дій, можливість вибіркового аудиту.
Оффбординг: відкликання ключів, експорт/видалення журналів, акт закриття, підтвердження знищення бекапів.
16) Безпека і захист від маніпуляцій
Поділ ролей: адмін джерела ≠ адмін сховища ≠ аудитор.
Підпис агентів/колекторів, mTLS між компонентами.
Анти-tamper контролі: порівняння хешів, регулярні перевірки цілісності, алерти на розбіжності.
Гео-реплікація WORM-копій і регулярні тести відновлення.
17) Типові помилки і анти-патерни
Логування чутливих значень (PAN/секрети) → негайне включення redaction-middleware.
Відсутність'purpose '/' ticket _ id'при доступі до PII.
Локальні вивантаження «на робочий стіл» і пересилання по e-mail.
Відсутність єдиної схеми і валідації → «німі» поля, неможливість кореляції.
Єдиний супер-аккаунт без прив'язки до людини або сервісу.
18) Чек-листи
18. 1 Запуск/рев'ю політики
- Схеми і словники затверджені; обов'язкові поля включені
- Включено маскування і заборони на секрети
- Налаштований NTP,'trace _ id'скрізь
- Hot/Warm/Cold/WORM шари заведені
- RBAC/ABAC і break-glass оформлені
- SIEM/SOAR інтегровані, алерти протестовані
18. 2 Щомісячний аудит
- Вибірка експортів: підписи/журнали коректні
- Перевірка ретеншну/видалень/Legal Hold
- DQ-метрики в нормі, quarantine розбір
- Вендорські логи доступні/повні
19) Дорожня карта впровадження
Тижні 1-2: інвентаризація систем, узгодження схем і обов'язкових полів, налаштування часу і трасування.
Тижні 3-4: включення маскування, WORM-шару, інтеграція з SIEM/SOAR, запуск журналів експортів.
Місяць 2: автоматизація валідаторів/алертів, плейбуки розслідувань, навчання команд.
Місяць 3 +: регулярні аудити, стрес-тести цілісності, оптимізація вартості (tiering), ревізія вендорів/договорів.
TL; DR
Сильні аудиторські журнали = повні і структуровані події + immutability (WORM) і підписи + маскування PII + жорсткий доступ і журнал вивантажень + інтеграція з SIEM/SOAR. Це прискорює розслідування, знижує ризики і робить комплаєнс доказовим.