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

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: трасування перевірок, санкційний/РЕР-скринінг, протоколи 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 і ризики аутсорсингу

Підсумок

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