Журнал аудиту: незмінність та контекст подій безпеки

17.09.2026 · Оновлено 26.09.2026 · 8 хв

Журнал аудиту має не просто фіксувати подію, а зберігати достатній контекст, щоб відновити її послідовність: хто виконав дію, коли це сталося і з якої системи надійшов запит. Якщо привілейований користувач може непомітно змінити записи або журнал не пов’язує подію з користувачем і системою, технічна довіра до нього знижується. Тому захист від непомітної модифікації, передавання до окремого сховища та перевірку повноти потрібно закладати в архітектуру журналювання до інциденту, а не лише під час розслідування.

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

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

Ці гарантії забезпечують різні механізми: контроль доступу обмежує суб’єктів і дозволені дії, WORM або retention lock блокує перезапис протягом установленого строку, а HMAC чи цифрові підписи роблять втручання виявлюваним або підтверджують походження в межах конкретної схеми. Сам факт передавання до SIEM не перетворює його на незмінне сховище.

Нормативні орієнтири та межі застосування стандартів

Політика журналювання починається з переліку подій і відповідальних за їх аналіз. Для кожного джерела команда визначає мету збору, потрібний контекст, доступ до записів і спосіб перевірки передачі. NIST SP 800-92 розглядає управління логами як поєднання інфраструктури та процесів. Тому вибір формату або сховища варто доповнити правилами роботи: хто перевіряє пропуски, хто реагує на збій колектора та як зміни конфігурації потрапляють до журналу.

Додаток A ISO/IEC 27001:2022 містить довідковий контроль A.8.15 щодо створення, зберігання, захисту й аналізу релевантних журналів; моніторинг систем на аномальну поведінку окремо розглядає A.8.16. Необхідність і спосіб застосування контролів організація визначає під час оброблення ризиків і фіксує у Statement of Applicability, а ISO/IEC 27002:2022 надає докладніші рекомендації з реалізації. ISO/IEC 27001 не є універсально обов'язковим для всіх організацій і сам по собі не задає єдину технічну архітектуру сховища журналів.

Forward Secure Sealing — механізм перевірки цілісності запечатаних локальних журналів systemd.
ISO/IEC 27001 (A.8.15) — контроль журналювання в додатку A; докладніші рекомендації з реалізації містить ISO/IEC 27002.
NIST SP 800-92 — керівництво з інфраструктури та процесів генерування, передавання, зберігання, аналізу й видалення логів.
RFC 5424 — стандарт, що визначає структуру повідомлень для уніфікації журналів різних систем.

Архітектурний розподіл обов'язків під час збирання подій

NIST SP 800-92 рекомендує розділяти обов'язки між адміністраторами окремих систем і персоналом, який керує централізованою інфраструктурою журналювання, але не встановлює універсальної заборони адміністраторам джерел працювати з локальними журналами. Конкретні ролі залежать від операційної моделі та вибраних контролів. Для суворіших сценаріїв NIST SP 800-53 у контролі AU-9 описує захист аудиторської інформації, а його доповнення — окреме сховище та обмеження аудиторських привілеїв підмножиною привілейованих ролей. Центральне сховище критичних журналів доцільно налаштувати так, щоб адміністратор джерела не міг непомітно змінити або видалити вже прийняті записи.

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

У проєкті інтеграції систему збору подій варто розглядати окремо від прикладних журналів. До технічного завдання можна включити перелік джерел, правила передачі, модель доступу та перевірку втрати зв’язку. Приймання такого рішення має спиратися на погоджені критерії та зафіксовані перевірки; сама наявність журналу не підтверджує виконання всіх вимог безпеки.

Розділення ролей — адміністратор джерела не керує вже прийнятими центральним сховищем записами; операції зі строками зберігання та обслуговування виконують за окремою контрольованою процедурою.
Централізація збору — передавання до окремого сховища з локальною буферизацією, повторними спробами та сповіщенням про збій агента, колектора або зв'язку.
Обмеження доступу — надання доступу до журналів за робочою потребою з окремим контролем адміністративних прав.
Контроль повноти — звірка ідентифікаторів, послідовностей або контрольних точок для кожного джерела та виявлення пропусків між джерелом і сховищем.

Структурування метаданих за специфікацією RFC 5424

RFC 5424 визначає незалежний від транспорту протокол і формат syslog-повідомлення. Поле STRUCTURED-DATA може містити один або кілька SD-ELEMENT; кожен елемент має SD-ID і параметри SD-PARAM. Стандарт надає контейнер, але не визначає прикладну семантику: ідентифікатор користувача, операцію, об'єкт, результат і correlation ID має явно сформувати джерело. Структуровані поля можуть спростити парсинг у SIEM за умови узгодженої схеми, але сам формат не гарантує меншого навантаження на аналітичну систему.

Необов'язкове текстове поле MSG (Message) можна використовувати для детального опису події. RFC 5424 визначає транспортно-незалежний протокол і формат повідомлення syslog, але сам по собі не гарантує, що колектор прийняв і надійно зберіг кожну подію. Для конфіденційності та цілісності каналу може використовуватися транспорт TLS, стандартизований RFC 5425. TLS не замінює прикладного підтвердження приймання, контролю пропусків або захисту журналів після запису до сховища.

Виявлення модифікацій за допомогою технології Forward Secure Sealing

Коли локальний вузол тимчасово втрачає зв'язок із центральним сховищем, журнали можуть накопичуватися локально. Forward Secure Sealing (FSS) у systemd-journald допомагає виявляти втручання у вже запечатані діапазони після компрометації вузла. Це механізм перевірки цілісності, а не захист, що робить файли фізично невидалюваними.

FSS періодично еволюціонує стан ключа запечатування (sealing key) і додає SHA-256 HMAC-теги для часових інтервалів. Компрометація поточного стану не повинна дозволяти коректно обчислити HMAC для вже запечатаної історії; це forward-secure sealing, а не цифровий підпис. FSS потрібно налаштувати завчасно: ключ запечатування залишається на вузлі, а ключ перевірки (verification key) systemd рекомендує зберігати зовні. Команда journalctl --verify без ключа перевіряє внутрішню узгодженість файлу, тоді як автентичність FSS-запечатаних інтервалів перевіряють через journalctl --verify --verify-key=…. FSS не підтверджує правдивість вихідної події, не захищає поточний незапечатаний інтервал, не запобігає вимкненню журналювання, видаленню цілого файла або підміні історії старішою коректною копією і не доводить повноту доставки. Для цих ризиків потрібні централізована копія або зовнішні контрольні точки, резервування й моніторинг; FSS дає змогу виявляти втручання, але не є самодостатнім незмінним сховищем.

Практичні кроки для перевірки цілісності журналів

Побудова надійної системи журналювання потребує регламентації процесів ротації, архівації та перевірки цілісності. Організація має самостійно визначити терміни зберігання логів відповідно до внутрішніх оцінок ризиків та вимог регуляторів, оскільки єдиного обов'язкового строку для всіх компаній не існує.

Перед впровадженням технічних засобів захисту рекомендується провести внутрішній аудит: перевірити права доступу до локальних та централізованих сховищ, налаштувати синхронізацію часу на всіх вузлах та переконатися, що формати повідомлень дозволяють однозначно ідентифікувати користувачів, які виконують критичні операції в системі.

Аудит прав доступу — перевірка фактичних дозволів ролей адміністраторів джерел і централізованого журналювання: зміна, видалення чи скорочення записів, керування строками зберігання, пересиланням і конфігурацією колектора.
Синхронізація часу — контрольована й моніторована інфраструктура часу з незалежними резервними джерелами та контролем відхилення годинників; коли правильний час критично важливий, RFC 8633 рекомендує щонайменше чотири незалежні різнорідні джерела.
Тестування FSS — окремі перевірки внутрішньої узгодженості через journalctl --verify та автентичності запечатаних інтервалів із зовнішнім ключем перевірки.
Перевірка повноти передачі — звірка стабільних ідентифікаторів, порядкових номерів для кожного джерела або контрольних точок, а також контроль пропусків, дублікатів і підтверджень доставки. Порівняння кількості є лише допоміжною метрикою з урахуванням дозволеної фільтрації й трансформацій.

Поширені питання

Як перевірити фактичні права адміністраторів на зміну журналів аудиту?

У тестовому середовищі або в погоджене контрольне вікно перевіряють фактичні дозволи всіх адміністративних ролей: адміністраторів джерела, колектора, сховища та аварійного доступу. Тестують перезапис, скорочення й видалення записів, зміну строку зберігання, вимкнення пересилання, обхід через адміністративний API та спрацювання оповіщень. Якщо протягом установленого строку видалення має бути технічно неможливим, застосовують WORM, retention lock або еквівалентний механізм одноразового запису; реальну компрометацію виробничого облікового запису для цього не імітують.

Які терміни зберігання логів є обов'язковими для організацій?

Універсального терміну зберігання для всіх організацій не існує. Терміни визначаються внутрішніми політиками безпеки, вимогами конкретних галузевих стандартів або регуляторними актами, що застосовуються до конкретного типу підприємства чи об'єкта критичної інфраструктури.

Чи гарантує технологія Forward Secure Sealing (FSS) збереження всіх подій?

Ні. FSS із зовнішнім ключем перевірки допомагає перевірити автентичність уже запечатаних інтервалів, але не гарантує створення, доставку чи збереження всіх подій. Він не запобігає видаленню цілого файла, вимкненню подальшого запечатування або запису неправдивої вихідної події. Для повноти й збереження потрібні окремі механізми централізованого збору, контрольних точок, резервування та контролю доступу.