Аудиторские журналы и следы доступа

1) Назначение и область применения

Цель: обеспечить доказуемость действий пользователей/сервисов, прозрачность расследований, соответствие требованиям регуляторов и внутренних стандартов (GDPR/AML, договоры с PSP/KYC-провайдерами, ISO/PCI при применимости).
Охват: все прод-системы, платформенные сервисы (аккаунт, платежи, антифрод, KYC/санкции, 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. Это ускоряет расследования, снижает риски и делает комплаенс доказуемым.