У сучасних умовах, коли сектор критичної інфраструктури (essential entities) стає головною мішенню цілеспрямованих кібератак, забезпечення надійної видимості в ізольованих (air-gapped) мережах є критичним елементом стратегії захисту. Традиційні підходи до моніторингу, які покладаються на хмарні обчислення та автоматичне оновлення Threat Intelligence, виявляються недієвими в закритих контурах. Створення ефективної системи виявлення загроз у таких умовах вимагає переосмислення архітектури збору логів та захисту даних аудиту на рівні прикладного програмного забезпечення.
Специфіка Air-Gap: чому стандартні підходи до SIEM ламаються без хмари
Відповідно до визначення NIST CSRC, ізольована мережа (air gap) — це інтерфейсна розв'язка між системами, за якої дані не передаються напряму між ними. У таких умовах організації сектору B2G та критичної інфраструктури стикаються з неможливістю використання хмарних SIEM-рішень, що вимагає побудови архітектури агрегації логів on-premises.
Сама по собі локальна SIEM-система не гарантує безпеку без належним чином налаштованих правил кореляції. Близько 53.7% інцидентів у закритих мережах пов'язані з діями внутрішніх користувачів або компрометацією облікових даних. При цьому лише 27.7% організацій мають налаштовані правила кореляції, здатні виявити техніки обходу засобів захисту (Defense Evasion) без доступу до зовнішніх баз сигнатур. Отримавши привілеї, зловмисник насамперед намагається модифікувати локальні журнали подій.
Саме тому NIST Cybersecurity Framework (CSF) 2.0 впроваджує функцію Govern, яка наголошує на важливості кіберризиків як невід'ємної частини корпоративного управління. Належне управління логами стає фундаментом для реалізації функції Detect.
Архітектура збору логів за NIST SP 800-92 в закритому контурі
Настанови NIST SP 800-92 слугують методологічною основою для побудови процесів збору та управління логами в ізольованому середовищі. Життєвий цикл логів охоплює їх генерацію, передачу, зберігання та аналіз, кожен з яких адаптується під вимоги закритого контуру.
Кількість джерел логів у великих B2G-системах може сягати тисяч одиниць. Це вимагає розгортання ієрархічної структури збирачів, які акумулюють події з операційних систем, мережевого обладнання та прикладного ПЗ. Слід пам'ятати, що наявність логів не дорівнює наявності повноцінного SOC (Security Operations Center) — зібрані дані потребують систематичного аналізу.
Час зберігання логів у критичній інфраструктурі часто регламентується нормативними вимогами і становить від 1 до 3 років для проведення ретроспективного аналізу. Це вимагає проєктування місткого локального сховища з чітким розділенням на гарячий (для швидкого пошуку) та холодний (захищений від запису архів) рівні.
Захист даних аудиту: роль Row-Level Security (RLS) та ACL на прикладному рівні
Безпека даних аудиту цілком покладається на внутрішні механізми контролю доступу. Якщо адміністратор бази даних має повні права, цілісність аудиту опиняється під загрозою. Для запобігання несанкціонованим змінам застосовують технології Row-Level Security (RLS) та Access Control Lists (ACL) на рівні прикладного ПЗ.
RLS дозволяє обмежити доступ до чутливих записів на рівні бази даних, а ACL гарантує, що адміністратор прикладних систем не має прав на видалення або модифікацію журналів аудиту.
Прикладом технологічного фундаменту для таких завдань є low-code платформа UnityBase (спільна розробка компаній Intecracy Group, де ключовим розробником є InBase). Рішення, побудовані на цій платформі, зокрема Megapolis.DocNet та Scriptum, використовують вбудовані механізми платформи UnityBase для забезпечення суворого аудиту. Завдяки використанню Domain metadata та вбудованому RLS/ACL, системи надійно фіксують дії користувачів. Для проєктів із високим навантаженням або підвищеними вимогами до безпеки офіційна документація рекомендує використання Enterprise або Defence редакцій UnityBase, що дозволяють здійснювати невідкличний аудит безпосередньо на рівні ядра системи.
Однонаправлена передача даних (Data Diodes) як інструмент безпечної агрегації
В ізольованих мережах критично важливо безпечно передавати логи із захищеного сегмента в сегмент моніторингу без порушення ізоляції. Будь-яке двонаправлене з'єднання створює ризик атаки у зворотний бік.
Вирішенням є використання однонаправлених шлюзів (data diodes) для передачі логів. У такій архітектурі налаштовується централізований збір подій з прикладних систем (ERP/ECM) безпосередньо в базу даних аудиту, ізольовану від зовнішнього доступу. Потім через data diode дані транслюються на локальний колектор SIEM-системи, що унеможливлює передачу шкідливих команд назад у критичний контур.
Мапування детекцій на MITRE ATT&CK в умовах обмеженого оновлення сигнатур
Оскільки ізольований SIEM не має доступу до хмарних баз індикаторів компрометації, виникає потреба в ручному управлінні правилами кореляції (offline threat modeling). MITRE ATT&CK використовується для структурування детекцій та мапування поведінки атакувальників у матрицю тактик і технік.
Акцент зміщується з пошуку відомих сигнатур на виявлення аномальної поведінки легітимних інструментів адміністрування. Правила SIEM адаптуються під такі локальні загрози:
- Спроби очищення або модифікації локальних журналів подій.
- Створення нових облікових записів або ескалація привілеїв у закритому контурі.
- Аномальна активність доступу до файлових сховищ чи баз даних.
Чек-лист готовності архітектури логування в ізольованій мережі
- Розділення обов'язків: адміністратори прикладних систем не мають прав на модифікацію або видалення журналів аудиту (ACL).
- Прикладне ПЗ підтримує Row-Level Security (RLS) для обмеження доступу до чутливих записів на рівні БД.
- Передача логів у сегмент SIEM здійснюється через однонаправлені шлюзи (data diodes) для запобігання зворотним атакам.
- Локальне сховище SIEM розраховане на довгострокове зберігання (від 1 до 3 років) відповідно до нормативних вимог.
- Правила кореляції SIEM адаптовані під локальні загрози та регулярно оновлюються в ручному режимі (offline packages).
Поширені питання
Як забезпечити оновлення правил кореляції та сигнатур у SIEM без доступу до інтернету?
Оновлення правил кореляції в ізольованому середовищі здійснюється шляхом імпорту офлайн-пакетів. Пакети завантажуються в зовнішній мережі, проходять перевірку, копіюються на авторизований носій та переносяться в закритий контур відповідно до суворих політик контролю змін.
Чи можна вважати локальні логи захищеними, якщо адміністратор бази даних має до них повний доступ?
Ні. Якщо адміністратор БД має привілеї на редагування або видалення таблиць аудиту, цілісність логів не може бути гарантована. Безпека вимагає використання прикладного ПЗ із вбудованими механізмами RLS та ACL (наприклад, на базі платформи UnityBase), що здійснює логування на рівні ядра системи і унеможливлює приховування слідів.
Як налаштувати передачу подій безпеки через data diode без втрати ізоляції?
Для цього архітектура передбачає збір логів із прикладних систем (ERP/ECM) у внутрішню базу даних аудиту, з якої події через апаратний однонаправлений шлюз (data diode) транслюються до ізольованого сегмента моніторингу. Це забезпечує потік даних виключно в одному напрямку, роблячи фізично неможливими атаки у зворотному напрямку.
Коментар експерта