На тлі посилення кіберзагроз для критичної інфраструктури, вимоги до сегментації та захисту мереж суттєво зросли. Згідно зі звітом ENISA Threat Landscape 2025, 53.7% організацій, що постраждали від кібератак у звітному періоді, належать до категорії життєво важливих та суттєвих об'єктів (essential/important entities). У таких умовах впровадження однонаправлених шлюзів (data diodes) перетворюється з нішевого рішення на стандартну архітектурну вимогу для ізоляції високозахищених контурів.
Чому фізичний Air Gap більше не працює і як з'явилися Data Diodes
Класичний повітряний розрив (Air Gap), який NIST CSRC визначає як ізоляцію інтерфейсів, за якої дані не передаються безпосередньо між системами, забезпечує високий рівень безпеки. Проте в сучасних умовах повної ізоляції досягти складно без порушення критичних бізнес-процесів.
Рішенням стають однонаправлені шлюзи (data diodes), що забезпечують жорстку ізоляцію мережевого шляху, підтримуючи автоматизований обмін. Спираючись на принципи безпечного обміну даними між доменами різного рівня довіри (Cross Domain Solutions), опубліковані NCSC UK, такі рішення дозволяють передавати інформацію з безпечної мережі в менш довірену (або навпаки), фізично блокуючи будь-який зворотний трафік чи потенційне проходження команд керування (C2).
Анатомія однонаправленого шлюзу: чому «ламаються» класичні REST API
Розробники та архітектори часто стикаються з проблемою під час спроби інтегрувати стандартні синхронні API (на кшталт REST чи gRPC) в ізольовані контури. Однонаправлені шлюзи примусово забезпечують строгий односторонній потік трафіку, усуваючи можливість виконання TCP-handshake або надсилання пакетів підтвердження (ACK) від пункту призначення до джерела.
Будь-яка спроба отримати HTTP-статус або квитанцію про доставку з безпечного контуру завершується помилкою таймауту або зависанням системи, оскільки апаратне забезпечення шлюзу повністю блокує зворотний зв'язок на фізичному рівні. Це вимагає фундаментальної відмови від синхронних запитів.
Архітектурні патерни для беззворотного обміну: черги, буферизація та асинхронність
Архітектуру взаємодії систем необхідно повністю перебудовувати на однонаправлені асинхронні рейки з використанням черг повідомлень (Message Queues) на обох боках шлюзу. Замість очікування миттєвої відповіді, відправник гарантує цілісність даних на своїй стороні та передає їх далі, а отримувач обробляє потік автономно.
Типовими прикладами такого підходу є:
- Експорт аудит-логів (audit logs) з високозахищеного внутрішнього контуру в зовнішню систему моніторингу без можливості зворотного проходження трафіку.
- Синхронізація довідників або потоків Threat Intelligence у захищений анклав, де система-отримувач не може підтвердити отримання.
- Організація черг повідомлень у системах документообігу та обліку, де транзакції реєструються в односторонньому порядку.
Архітектурна затримка (latency) у системах на базі шлюзів зазвичай визначається інтервалом опитування (polling interval) на стороні отримувача або частотою пакетування (batching frequency) у черзі відправника.
Обробка помилок та контроль цілісності в умовах нульового зворотного зв'язку
Оскільки класичний error-handling неможливий, системи покладаються на непряме підтвердження через контрольні суми (checksums) у пакетах, сувору нумерацію повідомлень та циклічну передачу критичних даних. Важливо розуміти, що data diode вирішує лише завдання мережевої ізоляції шляху. Він не є заміною засобів фільтрації контенту, тому антивірусні перевірки та валідація даних залишаються обов'язковими на рівні застосунків та проксі-серверів шлюзу.
Практична реалізація: як UnityBase Defence забезпечує асинхронну інтеграцію між контурами
Для побудови систем, здатних стабільно працювати в умовах відсутності зворотного зв'язку, використовують спеціалізовані платформні механізми. Прикладом такого фундаменту є UnityBase — full-stack JavaScript low-code платформа (спільна розробка компаній Intecracy Group, де InBase є ключовим, але не єдиним розробником).
Для об'єктів критичної інфраструктури застосовується комерційна редакція платформи UnityBase Defence edition. Вона містить готові механізми для роботи в ізольованих середовищах:
- Асинхронні черги (пакет ubq): Дозволяють системам фіксувати транзакції локально без очікування відповіді від бази даних отримувача, підтримуючи режими batching.
- Контроль цілісності: Defence edition підтримує накладання цифрових підписів ДСТУ на рівні об'єктів, що дозволяє отримувачу перевіряти автентичність повідомлень без двостороннього сеансу зв'язку.
- Локальний аудит: Механізм DataHistory забезпечує ведення надійних журналів безпеки та аудит-логів на кожній стороні для подальшого аналізу.
На базі платформи UnityBase побудовані корпоративні продукти, такі як система електронного документообігу Megapolis.DocNet від InBase та система управління документами Scriptum.DMS, архітектура яких дозволяє ефективно інтегруватися в ізольовані контури державних і комерційних підприємств.
Порівняння архітектурних підходів: Синхронний API vs Асинхронна черга (Data Diode)
| Параметр | Синхронний підхід (REST/gRPC) | Асинхронний підхід (Data Diode / UnityBase) |
|---|---|---|
| Транспортний рівень | Вимагає двостороннього TCP-handshake та підтвердження (ACK) | Працює на однонаправленому UDP або пропрієтарному фізичному шарі без ACK |
| Реакція на збій доставки | Негайний error-handling на стороні клієнта | Накопичення в буфері відправника (Spooler) до відновлення зв'язку |
| Підтвердження транзакцій | Квитанція про доставку в режимі реального часу | Непряме підтвердження через контрольні суми (checksums) у пакеті або повна асинхронність |
| Вплив на безпеку | Ризик витоку даних через зворотний канал зв'язку | Абсолютна ізоляція: зворотний шлях фізично відсутній |
Поширені питання
Як забезпечити гарантовану доставку даних через data diode без TCP-підтверджень?
В умовах неможливості двостороннього TCP-handshake доставка забезпечується завдяки асинхронним чергам повідомлень, буферизації даних на боці відправника (batching) та використанню контрольних сум (checksums). Отримувач перевіряє цілісність даних локально.
Які зміни потрібно внести в архітектуру бази даних для роботи в однонаправленому контурі?
Необхідно повністю відмовитися від синхронних запитів-відповідей. Транзакції мають реєструватися локально на боці відправника, а синхронізація з цільовою базою даних виконується шляхом однонаправленої передачі серіалізованих подій через черги повідомлень (Message Queues) без зворотного підтвердження.
Як UnityBase Defence edition вирішує проблему синхронізації станів між ізольованими сегментами?
Платформа використовує вбудовані механізми асинхронних черг (модуль ubq), ведення локальної історії змін (DataHistory) та підтримку ДСТУ-сумісних цифрових підписів для об'єктів. Це дозволяє гарантувати цілісність і автентичність синхронізованих даних без потреби у зворотному каналі зв'язку.
Коментар експерта