Аудит і незмінні журнали

Аудит і незмінні журнали

1) Навіщо це потрібно

Мета аудиту - зафіксувати «хто, що, де, коли і чому» з доказовою цілісністю, щоб підтримувати безпеку, розслідування, фінансову звітність і відповідність вимогам.
Незмінний журнал - формат і сховище, де події записуються тільки додаванням (append-only), а подальша зміна/видалення або неможливо, або виявимо криптографічними засобами і політиками зберігання.

2) Модель загроз і цілі контролю

• Умисна правка/видалення подій інсайдером.
• Підміна часу/джерела (replay/backdating).
• «Тихе» вимкнення логування на вузлі.
• Втрата частини журналу при аваріях/міграціях.
• Надлишковий збір PII і розлад з приватністю.

1. Цілісність: доведена захистом від модифікацій/видалень.

2. Повнота: закриття ключових потоків (control plane, data plane, доступи, гроші).

3. Точність часу: відтворюваний, синхронізований час.

4. Доступність: читання та пошук в межах SLO.

5. Приватність: мінімум PII, токенізація/шифрування, законність використання.

3) Таксономія та пріоритети подій

• Control Plane: автентифікація/авторизація, зміни конфігурацій, операції з ключами (KMS), управління секретами, зміна політик.
• Data Plane: доступ до об "єктів/записів/чекаутів/платежів; читання/створення/видалення.
• Адмін і DevOps: SSH/консоль, CI/CD, зміни інфраструктури/IaC, ескалації прав.
• Продуктові: транзакції, білінг, операції клієнтів.
• Системні/мережеві: ядро/агенти/проксі/балансери, брокери, БД.
• Безпека: IDS/IPS/EDR, WAF, анти-DDoS, антифрод, DLP.

Для кожного класу фіксуємо: критичність, схему, обов'язкові поля, термін зберігання, вимоги до незмінюваності.

4) Обов'язкові поля і формат

Ідентифікатори кореляції: 'trace _ id','span _ id','request _ id','actor _ id'( користувач/сервіс),'tenant _ id','resource _ id'.
Контекст A&A: спосіб автентифікації, ролі/політики на момент дії.
Час: RFC3339/UTC, мілісекунди/наносекунди; Джерело синхронізації.
Дія та результат: тип операції, мета, статус, кількість порушених об'єктів.
Цілісність: локальний HMAC запису, порядковий номер (sequence), hash-prev.
Схема: JSON зі стабільною моделлю (наприклад, сумісною із загальними словниками подій).

Заборонено: секрети, ключі, токени, повні PAN, паролі, приватні ключі. PII - тільки за необхідності, з маскуванням/токенізацією.

5) Час і синхронізація

Джерело часу: як мінімум два незалежних джерела (NTP/PTP) + моніторинг зсуву.
Критичні підписи часу: використовуйте сервіси довіреної позначки часу (TSA) або внутрішній time-sealing сервіс для пачок подій.
Правила: ніяких локальних часових поясів, тільки UTC; логувати і зміщення/якість часу.

6) Архітектура потоку логів

Агенти → Буфер → Транспорт → Лендінг → Хеш-ланцюг/підпис → Холод/Архів → Індекс для пошуку.

Збір на вузлі: легкі агенти (daemonset/sidecar) з буфером на диску (back-pressure).
Транспорт: захищений канал (TLS/mTLS), гарантована доставка (at-least-once), idempotent-інгест.
Лендінг-зона: об'єктне сховище в «сирому» вигляді (партії за датою/тенанту/типу).
Індекс: рушій пошуку/аналітики для online-запитів (гарячий шар).
Архів (WORM): незмінні бакети/стрічки з політиками ретенції та юридичними hold.
Anchor/Seal: періодична «запайка» пачок хеш-ланцюгів (див. нижче).

7) Криптографічна незмінюваність

7. 1 Ланцюжки хешів (append-only)

Кожен запис містить: 'hash _ curr = H (record)','hash _ prev'з попереднього запису,'seq'. Будь-яка правка ламає ланцюг.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 Підпис пачок і штамп часу

Кожні N секунд/МБ формуємо блок: корінь Меркла всіх'hash _ curr'.
Підписуємо блок ключем аудиту (стійко зберігається в KMS/HSM).
Додаємо позначку часу TSA і публікуємо «каталог блоків» (Transparency Log).
Опціонально: періодично якорим хеш кореня в зовнішній доказовий простір (наприклад, незалежний журнал або публічне незмінне сховище).

7. 3 Управління ключами аудиту

Ключі підпису - в KMS/HSM, ротація за графіком, багатофакторний доступ, dual-control для експорту.
Відгук ключа → нова гілка довіри; старі підписи залишаються перевіреними.

8) Політики зберігання та WORM

WORM/immutability: включаємо незмінні контейнери/бакети з політикою Retention і Legal Hold для класів P0/P1.
Версіонування: включено; видалення - тільки за процедурами із затримкою (заборона миттєвого purge).
Ретенція: гарячий (7-30 днів), теплий (3-6 місяців), холодний/архів (1-7 років і більше - залежно від регулятора/контракту).
Багатоарендність: окремі простори імен/обліки/ключі шифрування на орендаря; звітність по доступах до журналів.

9) Приватність і мінімізація

Збір за принципом необхідності: не логуємо зайве.
Токенізація/псевдонімізація чутливих полів, хеш з сіллю для ідентифікаторів.
Шифрування полів на стороні продьюсера (AEAD) при зберіганні в загальному об'єктному сховищі.
Право на видалення (де застосовується): реалізується через крипто-стирання ключів полів/партій, не порушуючи незмінюваність контейнера (планується при проектуванні).

10) Доступ, ролі та аудит самого аудиту

Розділення: producers ≠ readers ≠ admins.
Тільки читання з WORM; зміна політик ретенції - через відокремлені ролі і процедуру зі схваленням.
Всі операції читання/експорту журналюються у вторинний журнал (мета-аудит).
Експорт для слідства/комплаєнсу - в зашифрованому вигляді з каталогом хеш-блоків і ланцюгом довіри.

11) Спостережуваність і SLO

Метрики: швидкість інжесту, лаг до індексу,% втрачених/повторних, частка несинхронізованого часу, помилки підпису/якоріння, заповнення буферів.
SLO: ≥99. 9% подій доставлені ≤ X сек до гарячого індексу; 0 незрозумілих «дір» в послідовностях; 100% блоків підписані і промарковані часом.
Алерти: пауза інжесту> N хвилин, зростання invalid-hash, розбіжність ланцюга, провал підпису/таймстампа, зміщення часу за поріг.

12) Тестування та верифікація

Red/Blue-тести: спроба редагування/видалення запису на різних стадіях; перевірка детектування.
Chaos: відключення агента на вузлі, розрив мережі, переповнення буфера, «підміна часу».
Крипто-перевірки: регулярна валідація ланцюгів, звірка коренів Меркла і штампів.
Форензика: відтворення сценаріїв розслідувань з журналів end-to-end.

13) Експлуатація та процедури

Runbook «перевірка цілісності» (on-demand і за розкладом).
Процедура legal hold і тимчасової «заморозки» партій.
Процедура discovery та експорту зі збереженням ланцюга довіри.
План ротації ключів аудиту та реакції на компрометацію (нова гілка довіри, пере-підпис блоків, повідомлення).

14) Міні-рецепти

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Control/Data plane P0: гарячий 30 днів → теплий 6 міс → архів 7 років (WORM).
• DevOps: гарячий 14 днів → теплий 3 міс → архів 1 рік.
• Секуриті-сигнали: гарячий 90 днів (для розслідувань), потім 1-3 роки.

15) Часті помилки

«Логи - це текст без схеми». Без схеми немає детермінованої цілісності і пошуку; обов'язковий канонічний JSON і фіксовані поля.
Немає кореляції. Відсутність'trace _ id'ламає розслідування.
Локальний час. Тільки UTC і контроль зміщення.
Запис у змінювані томи. Без WORM будь-яка незмінюваність - фікція.
Не логують читання. Читання чутливих даних важливо фіксувати не менше, ніж запис.
Секрети в логах. Включайте санітайзери до відправки, «червоні списки» патернів.
Один ключ на все. Ключі підпису і шифрування - роздільно, з роллю і ротацією.

16) Відповідність і регулювання

Вимоги до термінів зберігання/незмінюваності залежать від домену (фінанси, платіжний, телеком тощо).
Доведення: наявність протоколів WORM/ретенції, звітів валідації ланцюгів, журналів доступу до журналів, процедур legal hold та експорту.

17) Чек-листи

Перед продом

• Затверджено таксономію подій і схему (обов'язкові поля).
• Налаштовані агенти, буфери, захищений транспорт, back-pressure.
• Включені: ланцюжки хешів, блоковий підпис, штамп часу, transparency-лог.
• Сховище WORM/ретенції включено; тест на неможливість перезапису/видалення.
• Маскування/токенізація чутливих полів.
• Синхронізація часу і моніторинг зміщення.
• План ротації та зберігання ключів аудиту в KMS/HSM.

Експлуатація

• Щотижнева валідація ланцюгів і блоків (+ звіт).
• Алерти на розрив ланцюга/помилки підпису/зміщення часу.
• Періодичні Red-team тести на підміну/видалення.
• Регулярний review ретенцій і витрат.

18) FAQ

В: Чи достатньо просто «тільки-додавання» на рівні БД?
О ні. Потрібні криптографічні гарантії (ланцюжки хешів, підписи блоків, штампи часу) і політики WORM.

В: Як бути з правом на видалення даних?
ПРО: Проектуйте крипто-стирання (видалення ключів) для полів/партій, зберігаючи незмінність носія і доказовість журналів.

В: Чи потрібен окремий ключ для підпису блоків?
ПРО: Так. Ключі підпису блоків відокремлюйте від ключів шифрування зберігання; зберігайте в KMS/HSM, з ротацією і аудитом.

В: Чи можна «якорити» в публічний простір?
ПРО: Опціонально. Це посилює перевірюваність і відсіче «переписування історії» всередині контуру.

• «Шифрування At Rest»
• «Шифрування In Transit»
• «Менеджмент секретів»
• «Управління ключами та ротація»
• «Підпис і верифікація запитів»