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

(Раздел: Операции и Управление)

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-срезы и дашборды — и у вас будет надежный фундамент доверия, безопасности и комплаенса.