Cross-domain інтеграційний шлюз

Cross-domain gateway — найскладніший клас захищених систем. Призначення: контрольований обмін інформацією між двома (або більше) контурами різного грифу обмеженого доступу. Наприклад: між контуром службової інформації та контуром державної таємниці, між корпоративною мережею та air-gapped операційним контуром промислової системи, між HR-контуром і контуром служби контролю. Помилка проектування таких шлюзів створює ризик витоку даних і порушення безперервності бізнесу.

§ 01 — Тип системи

Cross-domain solution (CDS) — окремий клас засобів захисту, що дозволяє контрольовано переміщувати інформацію між двома контурами з різним рівнем довіри. Класифікація АС за НД ТЗІ 2.5-004-99 — АС-3 з обов’язковими функціями фільтрації.

Типові сценарії використання:

• Передача затвердженого документа з контуру «таємно» у контур «службова інформація» — у бік низхідного грифу
• Отримання даних з зовнішньої системи у захищений контур — після верифікації, що дані не містять malware або стеганографії
• Обмін кадровими даними між загальним HR-контуром та контуром служби контролю охоронної компанії
• Інтеграція з партнерськими системами — контрольований канал з фільтрацією, журналюванням і підтвердженням відповідальної особи

§ 02 — Виклики та модель загроз

Cross-domain — це місце, де перетинаються найбільш кваліфіковані атакувальні актори:

• Витік через прихований канал у легітимних даних. Стеганографія, timing attacks, метадані документів. Шлюз має бути сліпим до спроб обходу через нестандартні канали.
• Атака через скомпрометований документ. Документ з активним контентом, що при відкритті у контурі вищого грифу намагається ексфільтрувати дані назад.
• Помилкова класифікація даних. Дані з вищого грифу помилково передані у нижчий контур — критичний інцидент. Технічні запобіжники потрібні навіть проти повноважних користувачів.
• Атаки на сам шлюз. Шлюз — центральна точка для зловмисника. Його компроментація відкриває обидва контури. Архітектура має передбачати, що шлюз сам по собі — атакована поверхня.
• Інсайдер з можливістю ескалувати дані. Користувач з легітимним доступом у нижчий контур може помилково або зловмисно завантажити дані з вищого грифу. Технічні бар’єри обов’язкові.

§ 03 — Вимоги нормативів

• НД ТЗІ 2.5-004-99 — АС-3 для систем з різними грифами
• НД ТЗІ 2.5-005 — вимоги до засобів з функціональним призначенням «фільтр»
• Закон України «Про державну таємницю» — для частини сценаріїв
• КМУ № 712 (2025) — для авторизації системи
• NIST 800-53 AC-4 Information Flow Enforcement, SC-7 Boundary Protection
• Внутрішні політики комплаєнсу, сегментації мереж і обміну з партнерами

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

Cross-domain на UBD — не «опція», а окремий клас впровадження з власною серверною інфраструктурою.

Принцип фізичного розділення

Два контури — фізично окремі мережі з окремими серверами застосувань, окремими СУБД, окремими АРМ. Спільна точка — тільки шлюз. Шлюз має:

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

Інспекційний прохід

Кожен файл, що проходить через шлюз, проходить інспекцію:

• Перевірка типу. Дозволені тільки явно перелічені типи (DOCX, PDF, специфічні XML-формати).
• Структурна валідація. Перевірка, що файл відповідає очікуваній структурі без додаткових прихованих об’єктів.
• Видалення активного контенту. Макроси, embedded objects, посилання на зовнішні ресурси — видаляються.
• Видалення метаданих. Author, last modified by, hidden text, track changes — видаляється.
• Перевірка на стеганографію. Аналіз зображень, аудіо-фрагментів на наявність прихованого контенту.
• Перевірка цифрового підпису. Якщо документ підписаний — верифікація підпису через ЦСК у контурі-джерелі.

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

Direction control

Шлюз має різні правила залежно від напрямку:

• З нижчого у вищий контур (uplift): базова інспекція + контроль на можливі malware. Користувач з вищого контуру явно «приймає» документ.
• З вищого у нижчий контур (downgrade): найкритичніший напрямок. Окрема процедура санітарної перевірки + обов’язковий підпис відповідальної особи з вищого контуру + дворівневе підтвердження.

Журнал шлюзу

Усі операції — у журнал з повним контекстом: хто запитав передачу, який документ, який результат інспекції, хто підписав, у який бік. Журнал WORM, доступний для постфактум-аудиту з боку служби контролю.

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

§ 06 — Що НЕ робимо у цій архітектурі

• Не real-time стрімінг даних. Cross-domain працює для документів і структурованих повідомлень. Real-time потокова передача (відео-conference з вищого контуру у нижчий) — це окремий клас рішень, що не реалізується через UBD-gateway.
• Не довільні файли. Тільки явно дозволені типи з відомою структурою. Спроба передати, наприклад, executable або zip-архів — блокується автоматично.
• Не bypass для «термінових випадків». У cross-domain не може бути «термінового режиму» з обходом перевірок. Якщо процедура повільна — рішення у організаційній площині (попередня підготовка, делегування повноважень), не у технічному обході.
• Не повна автоматизація. Cross-domain — це гібрид технічного контролю і людського рішення. Адміністратор шлюзу — не оператор, а гарант. Спроби максимально автоматизувати — приховує ризики.

§ 07 — Орієнтовний обсяг проекту

Cross-domain gateway — найдорожчий проект з усіх референсних архітектур через специфіку експертизи і ретельність підготовки.

• Обстеження двох контурів, формування threat model — 4-8 місяців
• Архітектурний дизайн з усіма захисними механізмами — 6-12 місяців
• Розробка шлюзу — 12-24 місяці
• Інтеграційне тестування у тестових контурах — 6-12 місяців
• Експертиза Держспецзв’язку — 6-12 місяців
• Поетапний запуск з обмеженим колом операцій — 6-12 місяців

Загальний термін — від 36 до 72 місяців. Бюджет — індивідуально, від десятків мільйонів грн.

Cross-domain є архітектурою, де помилки коштують найдорожче. Перш ніж починати проект — рекомендуємо звернутися до команди для попередньої оцінки доцільності та ризиків. У значній частині випадків задача може бути вирішена через організаційні заходи без побудови cross-domain solution.