Інтеграційний шлюз між контурами різного грифу обмеженого доступу

Тип системи: cross-domain integration gateway (CDG). За класифікацією NSA/CISA — High Assurance Guard. Завдання — забезпечити санкціонований, контрольований і верифікований обмін даними між інформаційними системами різних грифів захисту, без створення нових каналів витоку.

§ 01 — Постановка задачі

В установі (державний орган, корпорація, силове відомство) існує кілька паралельних інформаційних контурів:

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

Між цими контурами завжди є необхідність легітимного обміну: статистична звітність із захищеного контуру у відкритий, оновлення довідників із відкритого у захищений, передача документів через грифи у разі зміни режиму. Прямі мережеві з’єднання заборонені нормативно. Cross-domain gateway — це інженерна відповідь на проблему: як забезпечити такий обмін, не відкриваючи нову поверхню атаки.

§ 02 — Модель загроз

Витік чутливих даних через канал, що задумувався як «безпечний обмін статистикою».
Прихований канал (covert channel): зловмисник кодує приховану інформацію у легітимному трафіку (через timing, через метадані, через структуру повідомлень).
Зворотний потік: канал, задуманий як однонаправлений, у разі некоректної реалізації стає двонаправленим.
Атака на сам шлюз: компрометація CDG означає компрометацію всіх контурів одразу.
Конфігураційна помилка: неправильна політика фільтрації може як заблокувати легітимний обмін, так і пропустити чутливий контент.

§ 03 — Відповідність нормативам

В Україні: НД ТЗІ 1.4-001 (загальні положення про захист інформації), НД ТЗІ 2.5-005 (вимоги до засобів захисту з функціональним призначенням «фільтр»), Закон «Про державну таємницю» у частині, що стосується знімання грифу. Міжнародні рамки: NIST SP 800-160 (Systems Security Engineering), CCEVS Cross Domain Solutions, NCSC UK Pattern for Cross-Domain Solutions.

§ 04 — Архітектурне рішення

4.1. Архітектурні принципи

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

4.2. Типи фільтрів

Whitelist схеми: пропускаються лише повідомлення, що відповідають визначеній схемі (наприклад, JSON Schema). Все інше — відхиляється.
Контентна санітизація: з повідомлення видаляються метадані, форматування, приховані поля. Залишається лише semantic payload.
Перевірка цілісності: повідомлення мають бути підписані ЕЦП відправника, і шлюз перевіряє підпис до пропуску.
Антивірусна перевірка: для файлових даних — повна санітизація, переконвертація форматів (наприклад, з docx у pdf).

4.3. Транспортна реалізація

Найбільш безпечний варіант — фізичний обмін через зовнішній носій (file drop) з ручним підтвердженням з обох боків. Менш суворий варіант — однонаправлений шлюз data diode (фізичне обладнання, що електрично не може передавати у зворотному напрямку). Програмні рішення (firewall з суворими правилами) допустимі лише для контурів нижнього грифу.

4.4. Управління життєвим циклом

Шлюз має власний регламент експлуатації: політики оновлюються через окрему процедуру з підписами двох незалежних адміністраторів. Будь-яка зміна політики потрапляє у незмінний журнал. Тестування політик — на ізольованому стенді з представницькими наборами даних.

§ 05 — Mapping відповідності

Стандарт / норматив	Положення	Реалізація
НД ТЗІ 2.5-005	Вимоги до фільтрів	Реалізовано
ЗУ «Про державну таємницю»	Знімання грифу за процедурою	Реалізовано
NIST 800-160 Vol 1	Systems Security Engineering	Реалізовано
NCSC CDS Pattern	Cross-Domain Solutions Pattern	Реалізовано
NIS2 Article 21.2(j)	Inter-system communication	Реалізовано

[ ПРАКТИЧНА РЕАЛІЗАЦІЯ ]

Як цю архітектуру реалізовано на UnityBaseDefense

UnityBaseDefense підтримує роботу у режимі «адаптера до CDG»: платформа коректно поводиться, коли її REST API працює лише через однонаправлений шлюз — без потреби у синхронних відповідях, з gracefully degraded модами роботи. Журналювання усіх вихідних та вхідних повідомлень — на рівні ядра. Інтеграція з зовнішніми криптографічними засобами української сертифікації — стандартна.

Технічна архітектура UnityBaseDefense →

§ 06 — Компроміси та обмеження

Це найскладніший клас систем у дисципліні — як технічно, так і організаційно. Помилки тут найкоштовніші.
Latency: від хвилин до годин на обмін повідомленням. Real-time обмін через CDG — методологічно сумнівна постановка задачі.
Регуляторна тривалість: створення сертифікованого CDG може зайняти 2-4 роки з урахуванням експертизи захищеності, особливо якщо передбачається робота з державною таємницею.
Економічна доцільність: вартість CDG може перевищувати вартість обох інтегрованих систем разом. Перш ніж проектувати — варто переконатися, що задача справді вимагає такого рівня ізоляції.