Audit Trail: відстеження операцій

1) Що таке audit trail і навіщо він потрібен

Audit trail - це доказовий ланцюжок подій про операції з системами і даними: хто, що, де, коли і яким способом зробив, з яким результатом і на підставі якого запиту/тікету.

• Докази (evidence) для регуляторів та аудиторів.
• Розслідування та реагування (таймлайн інцидентів, root cause).
• Підтвердження виконання політик (SoD, ретенція, видалення/анонімізація).
• Нагляд за третіми сторонами і субпроцесорами.

2) Область охоплення (мінімальний набір)

Ідентичності та доступи (IAM/IGA): логін/логут, видача/відкликання ролей, ескалації привілеїв, JIT-доступи.
Дані та приватність: читання/зміна полів PI, вивантаження, маскування, видалення/TTL, Legal Hold.
Фінанси/транзакції: створення/апдейт/скасування, ліміти, реверсали, антифрод-дії.
Інфраструктура/хмара: зміни конфігурацій, секрети, ключі, KMS/HSM операції.
SDLC/DevSecOps: збірки, деплою, гейти відповідності, підтягування бібліотек (SCA), секрет-скан.
Операції/ITSM: інциденти, зміни, релізи, ескалації, DR/BCP тести.
Вебхукі/3rd-party: вхідні/вихідні виклики, підпис, підсумки валідації.

3) Модель події (канонічний формат)

json
{
"ts": "2025-11-01T11:23:45.678Z",
"env": "prod",
"tenant": "eu-1",
"system": "iam",
"domain": "access",
"actor": {"type":"user","id":"u_123","source":"sso","ip":"0.0.0.0"},
"subject": {"type":"role","id":"finance_approver"},
"action": "grant",
"reason": "ITSM-12345",
"result": "success",
"severity": "info",
"labels": {"jurisdiction":"EEA","pii":"no","sod_check":"passed"},
"trace": {"request_id":"r_abc","trace_id":"t_456","span_id":"s_789"},
"integrity": {"batch":"b_20251101_11","merkle_leaf":"..."}
}

Обов'язкові поля: `ts, actor, action, subject, result`.
Рекомендовані: 'reason (тікет/наказ), trace_id/request_id, tenant, jurisdiction'.

4) Принципи якості та семантики

Строго структуровано: тільки JSON/OTel; єдиний словник полів і кодів дій.
Синхронізація часу: NTP/PTP, зберігати'ts'і'received _ at'.
Кореляція: 'trace _ id '/' request _ id'для наскрізного трасування.
Ідемпотентність записів: детерміновані ключі батчів, захист від дублів.
Нормалізація акторів: людина/сервіс/бот/вендор з джерелом аутентифікації.

5) Архітектура audit trail

1. Producers: додатки, платформи, хмари, агенти хоста.
2. Колектори/шина: надійна доставка (TLS/mTLS, ретраї, back-pressure, дедуп).
3. Збагачення/нормалізація: єдині схеми, маппінг ролей/юрисдикцій.

• Гаряче (пошук/аналітика) - 30-90 днів.
• Холодне (об'єкт/архів) - 1-7 років залежно від норм.
• WORM/Object Lock - доказова незмінюваність.
• 5. Цілісність: підпис батчів, ланцюжки хешів, щоденний анкеринг (мерклі-коріння).
• 6. Доступ: RBAC/ABAC, case-based access (доступ тільки в рамках кейса).
• 7. Аналітика/алерти: SIEM/SOAR, кореляції, поведінкові правила.
• 8. Каталог подій: версія схем, довідник дій, тести схем в CI.

6) Незмінюваність і юридична значимість

WORM/Object Lock: заборона видалення/перезапису на термін ретенції.
Криптографічна фіксація: SHA-256 батчів, мерклі-дерева, зовнішній анкеринг (за розкладом).
Chain of Custody: лог доступу до логу (хто і коли читав/експортував), квитанції хешів у звітах.
Регулярна верифікація: завдання перевірки цілісності; алерт при розсинхронізації.

7) Приватність і мінімізація

Мінімізуйте PI: логуйте хеші/токени, маскуйте поля (email/phone/IP).
Контекст замість контенту: фіксуйте «факт операції», не повні payload.
Юрисдикції та межі: зберігання по країні (data residency), позначки для транскордонної передачі.
DSAR і деперсоналізація: мітки для швидкого пошуку, експорт з маскуванням.

8) Управління доступом (хто бачить audit trail)

RBAC/ABAC: аналітик бачить мінімум; експорт тільки за заявкою/кейсом.
Case-based access: розслідування/аудит → тимчасовий доступ з журналюванням.
Segregation of Duties: заборона адмінам систем правити власні сліди.
Щомісячні атестації: re-certification прав читання/експорту.

9) Ретенція, Legal Hold і видалення

Графіки зберігання: за доменами і нормами (наприклад, доступи - 1 рік, фінансові операції - 5-7 років).
Legal Hold: негайне заморожування відповідних подій, пріоритет над TTL.
Підтвердження видалення: звіт з хеш-зведенням віддалених партій.
Наскрізна ретенція для 3rd-party: договірні SLA на зберігання/доступ/видалення.

10) Дашборди та звіти

Coverage: які системи/юрисдикції покриті; прогалини.
Integrity/WORM: статус анкерингу і перевірок цілісності.
Access to Audit Trail: хто дивиться/що експортує; Аномалія.
Change & Admin Activity: чутливі дії (привілеї, ключі, секрети).
Privacy Lens: події над PI, DSAR/видалення, Legal Hold.
Compliance View: готовність «за кнопкою» до аудитів/запитів.

11) Метрики та SLO

Ingestion Lag p95 ≤ 60 сек.
Drop Rate = 0 (алерт> 0. 001%).
Schema Compliance ≥ 99. 5%.
Integrity Pass = 100% перевірок.
Coverage Critical Systems ≥ 98%.
Access Review SLA: 100% щомісячних атестацій прав.
PII Leak Rate: 0 критичних в audit trail.

12) SOP (стандартні процедури)

SOP-1: Підключення джерела

1. Реєстрація джерела і критичності → 2) вибір схеми/OTel → 3) TLS/mTLS, ключі → 4) dry-run (валідація схем/масок) → 5) реліз в прод → 6) включення в каталоги і дашборди.

SOP-2: Відповідь на регуляторний запит/аудит

Відкрити кейс → відфільтрувати події по об'єктах/періоду → експорт з хеш-квитанцією → legal review → відправка через офіційний канал → архівування в WORM.

SOP-3: Інцидент (DFIR)

Freeze (Legal Hold) → таймлайн по trace_id → витягти артефакти (ключові дії) → звіт з доказами → CAPA і оновлення детекцій.

SOP-4: Видалення по TTL

Ідентифікувати готові до видалення батчі → перевірити відсутні Legal Hold → видалити → згенерувати звіт про видалення з хеш-зведенням.

13) Приклади правил/запитів

Пошук критичної ескалації привілеїв (SQL-псевдо)

sql
SELECT ts, actor.id, subject.id
FROM audit_events
WHERE domain='access' AND action='grant'
AND subject.id IN ('admin','db_root','kms_manager')
AND reason NOT LIKE 'ITSM-%'
AND ts BETWEEN @from AND @to;

Правило SoD (псевдо-Rego)

rego deny_if_sod_conflict {
input.domain == "access"
input.action == "grant"
input.subject.id == "payment_approver"
has_role(input.actor.id, "payment_creator")
}

Фільтр на DSAR-операції (JSONPath)

$.events[?(@.domain=='privacy' && @.action in ['dsar_open','dsar_close','delete'])]

14) Меппінг на нормативи (орієнтири)

GDPR (Art. 5, 30, 32, 33, 34): мінімізація, облікові записи дій, безпека обробки, інцидент-повідомлення; DSAR/видалення/Legal Hold.
ISO/IEC 27001/27701: A.12/A. 18 - журналювання, управління доказами, приватність.
SOC 2 (CC6/CC7/CC8): контроль доступу, моніторинг, обробка інцидентів, цілісність логів.
PCI DSS (10. x): трасіруемость дій над даними карт і системами, щоденний огляд, цілісність журналів.

15) Інтеграція з іншими функціями

Compliance-as-Code/CCM: тести політик виконуються і протоколюються; алерти - на відхилення.
RBA (ризик-аудит): вибірки і реперформ за даними audit trail.
Vendor Risk: права аудиту та експортів у договорах; дзеркальна ретенція у підрядників.
Policy Lifecycle: зміни вимог → автогенерація нових правил і полів схем.

16) Антипатерни

«Вільний текст» без схем і семантики.
Неможливість зв'язати подію з тікетом/підставою (reason).
Доступ «для всіх» без кейсу і логування читання.
Відсутність WORM/підпису - спірність доказів.
Змішання часових зон і розсинхрон'ts '/' received _ at'.
Логування «повних» PI/секретів замість хешів/масок.

17) Модель зрілості (M0-M4)

M0 Ручний: розрізнені логи, неповне охоплення, немає ретенції.
M1 Централізований збір: базовий пошук, єдиний формат частково.
M2 Керований: каталог подій, схеми як код, ретенція/Legal Hold, RBAC.
M3 Assured: WORM + анкеринг, case-based access, KPI/SLO, auto-evidence.
M4 Continuous Assurance: наскрізне трасування (trace), прогнозні детекції, «audit-ready по кнопці».

18) Пов'язані статті wiki

Ведення журналів і протоколів

Безперервний моніторинг відповідності (CCM)

KPI та метрики комплаєнсу

Legal Hold і заморожування даних

Життєвий цикл політик і процедур

Комунікація комплаєнс-рішень

Управління змінами в політиці комплаєнсу

Due Diligence і ризики аутсорсингу

Підсумок

Сильний audit trail - це структуровані, незмінні і контекстні події з чітким доступом «за кейсом», наскрізним трасуванням і керованою ретенцією. Така система прискорює розслідування, робить перевірки передбачуваними і перетворює комплаєнс у відтворюваний, вимірюваний процес.