Журнал аудиту: незмінність та контекст подій безпеки
Журнал аудиту має не просто фіксувати подію, а зберігати достатній контекст, щоб відновити її послідовність: хто виконав дію, коли це сталося і з якої системи надійшов запит. Якщо привілейований користувач може непомітно змінити записи або журнал не пов’язує подію з користувачем і системою, його доказова цінність знижується. Тому незмінність записів, передавання до окремого сховища та перевірку повноти потрібно закладати в архітектуру журналювання до інциденту, а не лише під час розслідування.
Доказовість журналів аудиту досягається не просто фактом їхнього накопичення, а архітектурним розділенням прав доступу, використанням стандартизованих форматів та інструментів виявлення модифікації даних.
Нормативні орієнтири та межі застосування стандартів
Політика журналювання починається з переліку подій і відповідальних за їх аналіз. Для кожного джерела команда визначає мету збору, потрібний контекст, доступ до записів і спосіб перевірки передачі. NIST SP 800-92 розглядає управління логами як поєднання інфраструктури та процесів. Тому вибір формату або сховища варто доповнити правилами роботи: хто перевіряє пропуски, хто реагує на збій колектора та як зміни конфігурації потрапляють до журналу.
Міжнародний стандарт ISO/IEC 27001:2022 у контролі A.8.15 рекомендує впроваджувати ведення, моніторинг та аналіз журналів подій. Цей стандарт не є універсально обов'язковим для всіх організацій, проте його впровадження допомагає структурувати процеси управління інцидентами. Контроль A.8.15 орієнтує на те, що журнали мають бути захищені від несанкціонованого доступу, модифікації та видалення, що вимагає від інженерів використання спеціалізованих архітектурних рішень.
- Forward Secure Sealing — механізм перевірки цілісності запечатаних локальних журналів systemd.
- ISO/IEC 27001 (A.8.15) — міжнародна рекомендація з ведення, захисту та регулярного аналізу журналів подій.
- NIST SP 800-92 — керівництво з побудови інфраструктури збору, передачі та довгострокового зберігання логів.
- RFC 5424 — стандарт, що визначає структуру повідомлень для уніфікації журналів різних систем.
Архітектурний розподіл обов'язків при зборі подій
Відповідно до керівництва NIST SP 800-92, одним із ключових методів захисту журналів є розділення обов'язків (Segregation of Duties). Системні адміністратори, які керують серверами та додатками, не повинні мати технічної можливості змінювати або видаляти журнали аудиту. Ця функція має належати виключно адміністраторам безпеки або автоматизованим системам збору логів.
Для реалізації цього принципу застосовується централізація: події негайно пересилаються з локальних вузлів до ізольованого сховища. Проте необхідно враховувати, що розділення ролей, централізація та обмеження доступу є рекомендаціями архітектури, а не абсолютною гарантією безпеки. Якщо зловмисник отримає повний контроль над мережевою інфраструктурою, він все одно може спробувати заблокувати передачу даних.
У проєкті інтеграції систему збору подій варто розглядати окремо від прикладних журналів. До технічного завдання можна включити перелік джерел, правила передачі, модель доступу та перевірку втрати зв’язку. Приймання такого рішення має спиратися на погоджені критерії та зафіксовані перевірки; сама наявність журналу не підтверджує виконання всіх вимог безпеки.
- Розділення ролей — адміністратори систем не повинні мати прав на зміну чи видалення логів у сховищі.
- Централізація збору — негайна передача подій на виділений сервер для мінімізації локальних маніпуляцій.
- Обмеження доступу — надання доступу до журналів за робочою потребою з окремим контролем адміністративних прав.
- Контроль повноти — моніторинг наявності розривів у послідовності записів для виявлення можливих видалень.
Структурування метаданих за специфікацією RFC 5424
Для ефективного аналізу подій безпеки критично важливо мати структуровані дані. Стандарт RFC 5424 визначає формат повідомлень Syslog, який дозволяє передавати інформацію у вигляді структурованих елементів (Structured Data, SD-ID). Це спрощує автоматизовану обробку логів системами класу SIEM, якщо відправники узгоджено заповнюють потрібні поля. Ідентифікатор користувача та контекст прикладної операції команда має передавати явно: формат сам їх не додає. Використання структурованих даних спрощує обробку без необхідності складного парсингу неструктурованого тексту та знижує навантаження на аналітичні системи під час обробки великих потоків інформації.
При цьому стандартне текстове поле MSG (Message) залишається частиною повідомлення для збереження детального опису події. Необхідно враховувати, що сам протокол RFC 5424 лише задає формат представлення даних. Він не гарантує доставку повідомлень і не забезпечує їхню незмінність у процесі передачі. Для захисту каналу передачі необхідно використовувати додаткові протоколи, такі як TLS.
Виявлення модифікацій за допомогою технології Forward Secure Sealing
У випадках, коли локальний вузол тимчасово втрачає зв'язок із центральним сховищем, журнали накопичуються локально. Для захисту цих даних від модифікації зловмисниками з правами суперкористувача (root) у системному логері systemd-journald реалізовано технологію Forward Secure Sealing (FSS).
Технологія FSS допомагає виявити модифікацію раніше запечатаних даних, але вона не запобігає видаленню файлів журналів з диска і не гарантує збереження всіх подій. Принцип роботи FSS базується на періодичній еволюції ключів. Час роботи системи розбивається на часові інтервали (епохи). Для кожної епохи генерується новий ключ підпису на основі попереднього за допомогою односпрямованої функції, після чого старий ключ безповоротно видаляється з пам'яті. Якщо зловмисник отримує права root, він володіє лише поточним ключем і не може підробити підписи для записів минулих епох, що дозволяє аудиторам виявити факт втручання під час перевірки. Це створює надійний механізм контролю цілісності локальних логів до моменту їх передачі на центральний сервер.
Практичні кроки для перевірки цілісності журналів
Побудова надійної системи журналювання потребує регламентації процесів ротації, архівації та перевірки цілісності. Організація має самостійно визначити терміни зберігання логів відповідно до внутрішніх оцінок ризиків та вимог регуляторів, оскільки єдиного обов'язкового строку для всіх компаній не існує.
Перед впровадженням технічних засобів захисту рекомендується провести внутрішній аудит: перевірити права доступу до локальних та централізованих сховищ, налаштувати синхронізацію часу на всіх вузлах та переконатися, що формати повідомлень дозволяють однозначно ідентифікувати користувачів, які виконують критичні операції в системі.
- Аудит прав доступу — перевірка відсутності прав на запис та видалення у системних адміністраторів у центральному сховищі.
- Синхронізація часу — налаштування єдиного джерела часу NTP для всіх вузлів мережі для точного співставлення подій.
- Тестування FSS — регулярний запуск утиліти верифікації для підтвердження цілісності локальних журналів.
- Перевірка повноти передачі — порівняння кількості згенерованих локальних подій із кількістю отриманих у SIEM.
Поширені питання
Як перевірити, чи дійсно адміністратори не мають доступу до зміни логів?
Для цього проводиться практичний аудит: імітується компрометація облікового запису адміністратора системи, який намагається очистити або змінити записи в централізованому сховищі. Якщо архітектура побудована правильно, сховище відхилить запит на видалення через обмеження прав на рівні самого сховища логів.
Які терміни зберігання логів є обов'язковими для організацій?
Універсального терміну зберігання для всіх організацій не існує. Терміни визначаються внутрішніми політиками безпеки, вимогами конкретних галузевих стандартів або регуляторними актами, що застосовуються до конкретного типу підприємства чи об'єкта критичної інфраструктури.
Чи гарантує технологія Forward Secure Sealing (FSS) збереження всіх подій?
Ні, FSS не запобігає видаленню файлів журналів з диска і не гарантує доставку всіх подій. Ця технологія призначена виключно для виявлення факту модифікації раніше запечатаних даних, оскільки зловмисник після компрометації системи не матиме старих ключів для перепідпису минулих епох.
