Журнали аудиту операцій

(Розділ: Операції та Управління)

1) Призначення та принципи

Журнал аудиту - це первинне джерело правди про те, хто, що, де, коли і чому зробив, з можливістю довести незмінність і справжність записів.

• Повнота: покриті дії людей, сервісів і зовнішніх партнерів.
• Незмінюваність: записи не можна переписати/видалити без видимого сліду.
• Атрибуція: дія пов'язана з суб'єктом, роллю, контекстом, артефактами.
• Відтворюваність: подію можна відтворити у звіті/суперечці.
• Мінімізація PII: тільки необхідне, з маскою і токенами.

2) Області покриття

Призначені для користувача дії: вхід/SSO/MFA, зміна ролей/лімітів, операції з PII.
Привілейовані операції: JIT/PAM-сесії, break-glass, адмін-консоль.
Фінанси: прайс-листи/податки/FX публікації, платежі/виплати, ескроу, списання/повернення.
Конфігурації/релізи: фічефлаги, міграції схем, деплою/відкат, ключі/сертифікати.
Інтеграції: вебхуки, підписи, квитанції, idempotency-ключі.
Дані: читання/експорт PII, створення/видалення артефактів, зміни політик.

3) Архітектура і незмінюваність

Ingest-шлюз з аутентифікацією, квотами і схемною валідацією.
WORM-сховище (immutable buckets/append-only): версія, Retention Lock, Legal Hold.
Криптоквітанції: для критичних подій формується'receipt _ hash'і DSSE-підпис.
Merkle-ланцюги: періодично будуються зрізи (checkpoint), публікується кореневий хеш.
Chain of custody: трасування переміщення артефактів (хто отримав доступ, коли, на якій підставі).
Time Sync: NTP/PTP, мітки'event _ time'і'ingest _ time', коригування'skew'.

4) Схема події (референс)

audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

Додатково: для фінансів -'fx _ version/tax _ rule _ version/pricelist _ version'; для вебхуків -'webhook _ id','idempotency _ key'.

5) Модель даних і зони

Hot (оперативка): 7-30 днів, швидкі запити/дашборди.
Warm (OLAP): 6-24 міс, аналітика/пошуки.
Cold (архів/WORM): до 7-10 років (з регуляторики).
Класи ретенції: `operational`, `financial`, `security`, `legal_hold`.
Версіонування політики: всі події позначені'policy _ version'; зміна політики - окрема audit-подія.

6) Доступи та приватність

RBAC/ABAC/ReBAC: видимість по ролі/тенанту/регіону/справі (case).
Маскування PII: токенізація ідентифікаторів, висновок первинки - тільки через схвалені джоби.
Заборона прямого видалення: тільки'tombstone'+ Legal Hold; експлановані «доочищення» з окремим журналом.
Аудит самого аудиту: хто дивився/вивантажував логи - теж логується.

7) Якість, консистентність, дублі

Data contracts: строга схема і лямбда-валідації на вході.
Idempotency & дедуп: `(event_id, producer)`; «seen-cache» + KV.
Корекція часу: водяні знаки (watermarks) для пізніх подій.
Контроль повноти: порівняння лічильників джерел і ingest-метрик.

8) Дашборди і запити

Оперативні: привілейовані дії, SoD-порушення, JIT-підйоми прав, доступ до PII.
Фінансові: публікації FX/Tax/PriceList, розбіжності quote↔checkout, ключові підписи.
Інтеграції: квитанції вебхуків, лаг, ретраї, дублі.
Релізи/конфіги: хто/коли/що увімкнув/відкотив, зв'язок з інцидентами.
Пошукові сценарії: `trace_id`, `subject. id`, `target. id', час/регіон/тенант,'policy _ version'.
Експорт: пакетні вивантаження за запитом з квитанцією (підписаний маніфест).

9) API і вебхуки

'POST/audit/ingest'- прийом подій (автентифікація, ліміти, схема).
'GET/audit/search'- фільтри, пагінація, межа на результат.
'GET/audit/trace/{ trace _ id}'- зв'язка подій по ланцюжку.
'POST/audit/receipt/verify'- перевірка квитанції/DSSE.
Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.

10) SLO/метрики якості аудиту

Ingest Availability: ≥ 99. 95%.
Freshness (оперативка): лаг ≤ 30 з p95.
Completeness: ≥ 99. 5% джерел надіслали дані у вікно.
Correctness: розбіжність контрольних сум ≤ 0. 1%.
Tamper-evidence: 100% періодів завірені Merkle-корінням/підписами.
PII Hygiene: 100% подій з чутливим класом - з маскою/токеном.

11) Плейбуки та інциденти

Підозра на підміну записів: негайна перевірка Merkle-коренів, звірка DSSE-квитанцій, ізоляція доступу, Legal Hold.
Витік PII: пошук порушених подій/експортів, аудит доступу, повідомлення DPO/регулятору за термінами.
Порушення SoD: блок операції, тимчасове зняття ролі, розслідування і коригування політики.
Відмова ingest: буферизація, деградаційний режим, реплей після відновлення, контроль дублікатів.

12) Юридична витримка та комплаєнс

Retention по юрисдикціях: фінанси/податки - 5-10 років; безпека - щодо політики; персональні дані - мінімально необхідний термін.
Legal Hold: заморожування видалення у справі/запиті регулятора.
Звітні артефакти: індекс періодів, кореневі хеші, список підписантів, інвентаризація джерел.
Невідказуваність: криптопідписи, незалежне timestamping (внутрішній TSA).

13) Специфіка iGaming/фінтех

Платежі/виплати: повне трасування авторизацій, клірингу, відмов, chargeback; зіставлення з банківськими квитанціями.
RTP/ліміти: публікації профілів, зміни, спостережуваний RTP і рішення по лімітах - з підписами і версією.
Афіліати: прийом вебхуків, дедуп конверсій, заперечення/ескроу - тільки за підписаними артефактами.
Прайс-листи/податки/FX: версія артефакту в кожному замовленні; відкати - з квитанціями.

14) RACI

15) Ризики та анти-патерни

Редаговані логи без сліду → юридична невитримка.
Відсутність синхронізації часу → нестикуються таймлайни.
Shadow-експорти без квитанцій → витоку/суперечки.
Секрети в логах → компрометація.
Немає зв'язку з SLO/інцидентами → «кладовище даних» без користі.

16) Чек-лист впровадження

• Визначити області покриття і policy_version.
• Розгорнути ingest з автентифікацією, схемами і квотами.
• Включити WORM, Merkle-зрізи, DSSE-підписи, TSA.
• Налаштувати ретенції по класах і Legal Hold.
• Ввести RBAC/ABAC/ReBAC і аудит доступу до журналів.
• Побудувати дашборди: привілеї, PII, фінанси, релізи/конфіги.
• Включити плейбуки: tamper, PII-витік, ingest-відмова, SoD-порушення.
• Випробувати реплей і дедуп на тестовому наборі.
• Налагодити експорт з квитанціями та реєстром запитів.
• Щоквартально проходити аудит метрик якості (freshness/completeness/tamper).

17) FAQ

Чи можна зберігати все в звичайній БД?
Для оперативки - так, але критичні журнали повинні дублюватися в WORM/append-only з підписами і Merkle-зрізами.

Чи потрібно логувати кожне читання даних?
Читання PII/фінансів - обов'язково; решта - за політикою і вартістю.

Як довести незмінність?
Кореневі хеші, DSSE-підписи, незалежний TSA і відтворювані процедури перевірки.

Що робити з «правом на видалення» (GDPR)?
Видаляйте первинку в системах обробки; в аудит-журналах - зберігайте токени/хеші без відновлюваної PII і ведіть Legal Hold при необхідності.

Резюме: Журнали аудиту - це не «логи в S3», а криптографічно доказова історія дій з чіткою політикою, незмінним зберіганням, керованим доступом і готовністю до спору/регуляторної перевірки. Побудуйте ingest за контрактами, підпишіть критичні події, підтримуйте Merkle-зрізи і дашборди - і у вас буде надійний фундамент довіри, безпеки і комплаєнсу.