Политика хранения логов и событий
1) Цель и область действия
Цель: обеспечить законное, безопасное и экономичное хранение логов/событий, поддержать расследования, аудит, отчетность AML/KYC и устойчивость платформы.
Охват: все среды (prod/stage/dev), приложения и микросервисы, антифрод и платежи, KYC/санкции, RG, инфраструктура (K8s/облако/СDN/WAF), партнеры/вендоры (PSP, KYC, антифрод, аналитика).
2) Классы логов и минимальный состав полей
1. Безопасность (SecOps/Identity): аутентификация, ATO/антифрод-сигналы, изменения ролей и политик, доступ к PII.
Поля: `actor`, `subject`, `action`, `result`, `ip`, `device`, `geo`, `risk_score`, `trace_id`.
2. Транзакции/платежи: депозиты/выводы, chargebacks, правила антифрода.
Поля: `tx_id`, `amount`, `currency`, `psp`, `status`, `rule_hits[]`, `evidence_ref`.
3. KYC/санкции/PEP: инициации, результаты, провайдер/версия списков, решения (true/false positive).
4. Операции/SRE: метрики SLO, релизы, автокат, инциденты, алерты.
5. Маркетинг/CRM (необязательные): события согласия/отписки, кампании (без лишней PII).
6. Аудит доступа к данным: чтение/экспорт/удаление наборов с PII; ссылки на кейсы DSAR/AML.
3) Сроки хранения и уровни хранения (Hot/Warm/Cold/WORM)
4) Синхронизация времени и трассируемость
Единая временная база: NTP/Chrony, хранить `ts_utc` (UTC) + `ts_local` (для отчетности).
Корреляция: в каждый лог включать `trace_id`/`span_id` и `source_service`.
Часовые пояса: отчеты/экспорт — с явным указанием TZ.
5) Доступ, шифрование и разделение обязанностей
Шифрование: at rest (KMS; ротация ключей не реже 90 дней для секретных пространств) и in transit (TLS 1.2+).
RBAC/ABAC: доступ по минимуму; отдельные роли на чтение аудит-логов.
Break-glass: временный доступ с многофакторной авторизацией и автозакрытием.
Сегментация: логи с PII/финансами — отдельные индексы/баки, отдельные ключи.
Журналы доступа к логам: все чтения/экспорты фиксируются и ревьюятся.
6) Приватность и маскирование
Строго запрещено логировать: пароли, токены, PAN (полностью), CVV/CVC, полные номера документов, «сырые» биометрические данные.
Маскирование по умолчанию: email → `p@domain.com`; телефон → `+XXX123`; IBAN/PAN → токены/последние 4 цифры.
Псевдонимизация: заменять `user_id` на стойкий токен в аналитических/маркетинговых логах.
Куки/SDK: логировать только технические идентификаторы с согласия (CMP) и без склейки с PII, если нет законного основания.
DSAR-совместимость: хранить ссылку на источник набора и возможность выборочного извлечения/удаления.
7) Качество данных (Data Quality) и форматирование
Схема-как-код: централизованные JSON-схемы/протоколы событий, версионирование.
Валидации: not null/диапазоны/регексы; отклоненные события — в quarantine-очередь с меткой причины.
Дедупликация: по `(trace_id, ts, source)`; уровни idempotency для ретраев.
Обогащение: строго детерминированное; гео/девайс-атрибуты — с указанием версии словарей.
8) Архитектура и уровни хранения
Hot: индексируемые хранилища/поисковые кластеры (оперативные расследования, SIEM).
Warm: объектное хранилище с ускоренным доступом/колд-индексами.
Cold: объектное/архивное хранилище (glacier-класс/аналог), запросы через batch.
WORM/Legal Hold: неизменяемые бакеты/политики ретеншна и «правовые удержания» с невозможностью удаления/изменения до истечения срока.
9) Удаление, архивирование и Legal Hold (SOP)
1. Ежедневный планировщик вычисляет кандидатов по срокам.
2. Проверка на активные инциденты/расследования/Legal Hold.
3. Архивирование: перенос в Cold/WORM при необходимости.
4. Удаление: безопасная очистка + журнал (`dataset`, `range`, `actor`, `hash_before/after`).
5. Отчет в Compliance/Data по завершении батча.
10) Интеграция с комплаенсом (GDPR/AML/PCI/ISO)
GDPR: минимизация, цели/основания в RoPA; DSAR-доступность; 72-часовые уведомления опираются на аудит-логи.
AML: хранение логов санкционных проверок, STR/SAR-ссылки; сроки 5–10 лет (по стране).
PCI DSS (если применимо): запрет чувствительных аутентификационных данных; сегрегация логов платежного периметра.
ISO 27001/ISMS: политика логирования как обязательный документ; ежегодные аудиты и тесты.
11) Вендоры и субпроцессоры
DPA/SLA: прописать сроки хранения, географию, TOMs, формат экспорта, WORM/Legal Hold, время реакции на инцидент.
Аудит: опросники, выборочные логи доступа к PII, тест инцидента/уведомления.
Оффбординг: удаление/возврат логов, акт закрытия, подтверждение уничтожения копий/бэкапов.
12) Мониторинг и алерты
KRIs: рост отказов валидаций > X%, лаги ingestion > Y, неуспех ETL <99%, попытки доступа вне окна.
KPI: покрытие логированием ≥ 95% сервисов; MTTD отказа пайплайна ≤ 15 мин; доля запросов к Hot, завершенных ≤ 2 сек — ≥ 95%.
SOAR: авто-тикеты при нарушении ретеншна/доступов/маскирования.
13) RACI
14) Экспорт и отчетность
Белые списки получателей и форматов (CSV/Parquet/JSON) с обезличиванием по умолчанию.
Подпись/хэш каждого архива, журнал выгрузок.
Шаблоны регуляторных отчетов: сводки по санкциям/PEP, KYC, AML-алертам, доступам к PII, инцидентам.
15) Требования к разработке и эксплуатации
Логировать осмысленно: ключевые действия/решения, а не весь трафик.
Стандарты уровней: `DEBUG` запрещен в prod; `INFO` для бизнес-событий; `WARN/ERROR` для аномалий.
Redaction-middleware: единый слой маскирования в гейтвеях/SDK.
Тестовые среды: синтетические данные или псевдонимизация; запрет копий prod-логов в dev.
Релизы: чек-лист логирования/маскирования в CAB; feature-флаги для расширенного логирования.
16) Чек-листы
16.1 Еженедельный контроль
- Синхронизация времени без дрейфа
- Ошибки ingestion < порога
- Нет прямых PII/секретов в сэмплах
- Доступы/роли актуальны
- Успех ETL ≥ 99%
16.2 Ежемесячный аудит
- Проверка ретеншна/удалений
- Случайная выборка экспортов (подпись/хэш ок)
- Ревью вендоров (логи доступов, инциденты)
- Обновление схем/справочников
16.3 Перед удалением/архивом
- Нет Legal Hold/инцидента
- Экспорт связанных артефактов (если требуется)
- Протокол уничтожения сформирован
17) Инциденты логирования (быстрый playbook)
Обнаружены PII/секреты в логах → немедленно включить redaction-правила, ограничить доступ, запустить очистку/ротацию ключей, оценить масштаб (DPO/Legal), при необходимости — уведомления.
Отказ пайплайна логов → переключение на буферизацию, алерт SRE, рестарт ingestion, пост-мортем.
18) Дорожная карта внедрения
Недели 1–2: инвентаризация источников, согласование сроков, базовая матрица ретеншна, схема-как-код.
Недели 3–4: внедрение маскирования/редакции, разделение индексов с PII, NTP/trace-идентификаторы, WORM для критичных наборов.
Месяц 2: автоматизация удаления/архивации, KRIs/KPIs и алерты, SOAR-плейбуки.
Месяц 3+: аудит вендоров, оптимизация стоимости (tiering), квартальные ревью сроков и требований юрисдикций.
TL;DR
Единая политика логов = четкая матрица сроков + маскирование и шифрование + RBAC и аудит доступа + WORM/Legal Hold + качество и синхронизация времени. Это сокращает риски (GDPR/AML/PCI), удешевляет хранение и ускоряет расследования.