Референсна архітектура XDOM

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

Як побудувати контрольований шлюз між контурами різного грифу обмеженого доступу на UnityBaseDefense — з зворотним інспекційним проходом, фільтрацією змісту, гранулярним контролем напрямку.

СЕКТОР: XDOM СКЛАДНІСТЬ: дуже висока ДЛЯ: Архітектор безпеки, аналітик розвідки

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

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

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

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

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

§ 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
  • Стандарти NATO для cross-domain (для відповідних інтеграцій)

§ 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 відповідності

Контроль Норматив Реалізація на UBD
Профіль захисту АС-3 НД ТЗІ 2.5-004-99 У проектах окремо
Функція «фільтр» НД ТЗІ 2.5-005 Через інспекційний прохід
Information Flow Enforcement NIST 800-53 AC-4 Прикладна логіка
Boundary Protection NIST 800-53 SC-7 Архітектурно
Контроль адміністратора шлюзу Best practice Two-person rule
Дворівнева верифікація downgrade У прикладній логіці
Журнал operations шлюзу NIST 800-53 AU WORM, повний контекст

§ 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.