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

1) Зачем нужны журналы и протоколы

Журналы — «черный ящик» организации: они обеспечивают доказательства (evidence) для аудитов и расследований, снижают операционный и регуляторный риск, позволяют восстанавливать ход событий и подтверждать исполнение политик (access, ретенция, шифрование, KYC/AML, PCI и др.).

• Трассировка действий (кто/что/когда/где/почему/чем).
• Обнаружение и сдерживание инцидентов (детективные и превентивные контроли).
• Доказательная база для регуляторов/аудиторов (immutability).
• Аналитика производительности и соответствия SLA/SLO.

2) Таксономия логов (минимальный охват)

Доступы и идентичности (IAM/IGA): аутентификация, изменение ролей, SoD, JIT-доступы.
Инфраструктура/облако/IaC: API-вызовы, конфигурационный дрейф, KMS/HSM-события.
Приложения/бизнес: транзакции, операции с PI/финансами, жизненный цикл запросов (DSAR).
Безопасность: IDS/IPS, EDR, DLP/EDRM, WAF, уязвимости/патчи, антивирус.
Сеть: firewall, VPN/Zero Trust, прокси, DNS.
CI/CD/DevSecOps: сборки, деплой, SAST/DAST/SCA, секрет-скан.
Данные/аналитика: lineage, доступ к витринам, маскирование/анонимизация.
Операции: ITSM/тикеты, инциденты, change-management, DR/BCP тесты.
Вендоры/3rd-party: вебхуки, SSO федерация, события SLA.

3) Нормативные требования (ориентиры)

GDPR/ISO 27701: минимизация/маскирование PI, ретенция по графику, Legal Hold, DSAR-трассировка.
SOC 2 / ISO 27001: аудит-трейлы, контроль доступа к логам, доказательства выполнения контролей.
PCI DSS: логирование доступов к средам/данным карт, целостность журналов, ежедневный обзор.
AML/KYC: трассируемость проверок, санкционный/PEP-скрининг, протоколы STR/SAR.

4) Референс-архитектура логирования

1. Producers: приложения, облако, сеть, агенты хоста.
2. Шина/коллекторы: прием с back-pressure, retry, TLS mTLS, дедупликация.
3. Нормализация: единый формат (JSON/OTel), обогащение (tenant, user, geo, severity).

• Горячее (поиск/SIEM): 7–30 дней, быстрый доступ.
• Холодное (объектное): месяцы/годы, дешевое хранение.
• Архив-evidence (WORM/Object Lock): неизменяемость, хеш-квитанции.
• 5. Целостность и подпись: цепочки хешей/меркли-дерево/временные метки.
• 6. Доступ и безопасность: RBAC/ABAC, сегментация по юрисдикциям, кейс-базированный доступ.
• 7. Аналитика и алерты: SIEM/SOAR, correlation ID, playbooks.
• 8. Каталоги и схемы: реестр типов событий, versioning, тесты схем.

5) Политики-как-код (примеры YAML)

Ретенция и Legal Hold

yaml id: LOG-RET-001 title: "Access logs retention"
scope: ["iam. ","app. access"]
retention:
hot_days: 30 cold_days: 365 worm_years: 3 legal_hold: true # when Legal Hold is active, block privacy removal:
pii_mask: ["email","phone","ip"]
review: "annual"

Целостность и подпись

yaml id: LOG-INT-001 title: "Signature and commercial fixation"
hashing: "SHA-256"
anchor:
cadence: "hourly"
store: "s3://evidence/anchors"
verification:
schedule: "daily"
alert_on_failure: true

6) Требования к качеству журналов

Структурированность: только JSON/OTel, без «сырого» текста.
Синхронизация времени: NTP/PTP, контроль drift; запись `timestamp`, `received_at`.
Correlation IDs: `trace_id`, `span_id`, `request_id`, `user_id` (псевдоним).
Семантика полей: словарь (data dictionary) и контракт схемы с тестами.
Локализация/язык: поля — англ. ключи, значения — унифицированные (enum).
Объем и дроп-политика: запрет бесконтрольного дропа; очереди/квоты/семплинг по риску.
Чувствительные данные: маскирование/токенизация; запрет целиком сохранять секреты/карты.

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

PII-гигиена: логируем хэши/токены вместо значений; строгая маска для email/телефона/IP.
Контекст: не писАть payload с персональными данными без основания.
Юрисдикции: хранение и доступ по стране (data residency), трассируемость копий.
DSAR: метки поиска и экспорт по кейсу; возможность печати отчетов с деперсонализацией.

8) Неизменяемость и доказательства (immutability)

WORM/Object Lock: запрет удаления/перезаписи в периоде.
Криптоподпись: подпись батчей; меркли-корни с ежедневным анкерингом.
Цепочка хранения (chain of custody): журнал доступа, хеш-квитанции, квиты в отчетах.
Верификация: периодические проверки целостности и оповещения о рассинхронизации.

9) Управление доступом к логам

RBAC/ABAC: роли «чтение/только поиск» vs «экспорт/шаринг».
Case-based access: доступ к чувствительным логам — только в рамках расследования/тикета.
Секреты/ключи: KMS/HSM; ротация, split-knowledge, dual-control.
Аудит доступа: отдельный журнал «кто читал какие логи» + алерты на аномалии.

10) Метрики и SLO логирования

Ingestion Lag: 95-й перцентиль задержки приема (цель ≤ 60 сек).
Drop Rate: доля потерянных событий (цель 0; алерт > 0.001%).
Schema Compliance: % событий, прошедших валидацию схемы (≥ 99.5%).
Coverage: % систем под централизованным логированием (≥ 98% критичных).
Integrity Pass: успешные проверки хеш-цепочек (100%).
Access Review: ежемесячная рекламация прав, просрочка — 0.
PII Leak Rate: обнаруженные «чистые» PI в логах (цель 0 критических).

11) Дашборды (минимальный набор)

Ingestion & Lag: объем/скорость, лаг, drop, «горячие» источники.
Integrity & WORM: статус анкеринга, верификации, Object Lock.
Security Events: критические корреляции, MITRE-карта.
Access to Logs: кто и что читал/экспортировал; аномалии.
Compliance View: ретенция/Legal Hold статусы, отчеты по аудитам, DSAR-экспорты.
Schema Health: ошибки парсинга/версии схем, доля устаревших агентов.

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

SOP-1: Подключение источника логов

1. Регистрация источника и критичности → 2) выбор схемы/OTel → 3) TLS/mTLS, токены →

2. dry-run в стейджинге (валидация схем, PII-маски) → 5) подключение в прод →

3. добавление в каталоги/дашборды → 7) проверка ретенции/WORM.

SOP-2: Ответ на инцидент (журналы как evidence)

Detect → Triage → Сбор логов (case-scope) → Заморозка (Legal Hold) →

Хеш-фиксация и анкеринг → Аналитика/таймлайн → Отчет и CAPA → Релиз уроков.

SOP-3: Рег-запрос/аудит

1. Открыть кейс и фильтры по ID запроса → 2) экспорт в требуемый формат →

2. верификация Legal/Compliance → 4) хеш-сводка → 5) отправка и журналирование.

SOP-4: Ревизия доступа к логам

Ежемесячная аттестация владельцев; авто-ревок «осиротевших» прав; отчет по SoD.

13) Форматы и примеры

Пример события доступа (JSON)

json
{
"ts": "2025-10-31T13:45:12. 345Z",
"env": "prod",
"system": "iam",
"event": "role_grant",
"actor": {"type": "user", "id": "u_9f1...", "tenant": "eu-1"},
"subject": {"type": "user", "id": "u_1ab..."},
"role": "finance_approver",
"reason": "ticket-OPS-1422",
"ip": "0. 0. 0. 0",
"trace_id": "2a4d...",
"pii": {"email": "hash:sha256:..."},
"sign": {"batch_id":"b_20251031_13","merkle_leaf":"..."}
}

Правило детекции (псевдо-Rego)

rego deny_access_if_sod_conflict {
input. event == "role_grant"
input. role == "finance_approver"
has_role(input. subject. id, "vendor_onboarder")
}

14) Роли и RACI

15) Управление вендорами и цепочкой поставок

В договорах: право аудита логов, форматы, SLA хранения и доступа, WORM/immutability.
Субпроцессоры: реестр источников и «сквозная» ретенция.
Экспорт/оффбординг: подтверждение уничтожения и отчет хеш-сводки.

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

Логи в «свободном тексте», без схем и корреляции.
Хранение без WORM и хеш-фиксации — спорность на аудите.
Чувствительные данные в логах «как есть».
Нет синхронизации времени и нормального trace_id.
Дроп событий при пиках нагрузки; отсутствие back-pressure.
Универсальный доступ к логам без кейс-контроля.
«Вечные» права на чтение логов, без ре-аттестаций.

17) Чек-листы

Запуск функции логирования

• Таксономия источников и критичность определены.
• Схемы и политики ретенции/Legal Hold задекларированы (as-code).
• TLS/mTLS, токены, агенты с авто-обновлением.
• PII-маски/токены протестированы.
• WORM/Object Lock и анкеринг включены.
• Дашборды/алерты/метрики заведены.
• Ревизия доступа и SoD настроены.

Перед аудитом/рег-запросом

• Собран «audit pack»: схемы, политики, отчеты целостности, выборки.
• Проверка integrity и журналов доступа за период.
• DSAR/Legal Hold статусы подтверждены.
• Сформирована хеш-сводка выгрузок и подтверждения отправки.

18) Модель зрелости (M0–M4)

M0 Ручной: разрозненные логи, нет схем и ретенции.
M1 Централизованный сбор: базовый поиск, частичная таксономия.
M2 Управляемый: схемы и политики-как-код, дашборды, ретенция/WORM.
M3 Интегрированный: OTel-трассировка, SOAR, анкеринг/меркли, case-based access.
M4 Assured: «audit-ready по кнопке», прогнозные детекции, автоматический контроль целостности и юридически значимые квитанции.

19) Связанные статьи wiki

Непрерывный мониторинг соответствия (CCM)

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

Legal Hold и заморозка данных

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

Коммуникация комплаенс-решений

Управление изменениями в политике комплаенса

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

Итог

Сильная функция логирования — это не «склад сообщений», а управляемая система: структурированные события, строгие схемы и ретенции, неизменяемость и подпись, приватность по умолчанию, жесткий контроль доступа и репликация в доказательства. Такая система делает расследования быстрыми, аудиты — предсказуемыми, а риски — управляемыми.