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: аналитик видит минимум; экcпорт только по заявке/кейсу.
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 — это структурированные, неизменяемые и контекстные события с четким доступом «по кейсу», сквозной трассировкой и управляемой ретенцией. Такая система ускоряет расследования, делает проверки предсказуемыми и превращает комплаенс в воспроизводимый, измеримый процесс.