Cross-domain solution (CDS) — найскладніший клас систем інформаційної безпеки. Будувати CDS дорого, експлуатувати ще дорожче, повторна експертиза при кожному оновленні. Перш ніж проектувати CDS, варто чесно відповісти на запитання: чи дійсно потрібен CDS, чи можна обійтися організаційними заходами?
Що таке cross-domain
Cross-domain solution — це система, що контрольовано переносить інформацію між мережевими або інформаційними середовищами різних рівнів довіри або різних грифів. Класичний приклад: треба передати дані з мережі з грифом «таємно» у мережу «для службового користування» — для аналітики, звітності, обміну з партнерами.
На відміну від звичайного фаєрволу, CDS не просто фільтрує пакети — він глибоко аналізує вміст, виконує трансформації, видаляє чутливі поля, перевіряє цілісність і легітимність кожного повідомлення.
Три типи cross-domain
1. Uplift (підвищення рівня)
Дані з менш захищеної мережі переносяться у більш захищену. Менш ризикований напрямок з точки зору розголошення (нижчий рівень виходить у вищий), але є ризики цілісності і шкідливого коду.
Приклад: завантаження дослідницьких даних з відкритого інтернету у захищену аналітичну систему.
2. Downgrade (зниження рівня)
Найскладніший випадок. Дані з більш захищеної мережі переносяться у менш захищену. Ризик прямого розголошення. CDS повинен переконатися, що передаються тільки дозволені до пониження дані, і нічого більше.
Приклад: експорт звітів з системи «обмеженого доступу» у відкриту систему публічної статистики.
3. Lateral (між рівнями того самого класу)
Дані між двома мережами однакового рівня, але різних доменів довіри (наприклад, між системами двох різних відомств). Менш зрозумілий напрямок з регуляторної точки зору, але часто зустрічається у міжвідомчих обмінах.
Правильні запитання перед CDS-проектом
- Який обсяг передачі? Кілька повідомлень на день — можливо, ручна процедура. Тисячі повідомлень на день — потрібен CDS.
- Який характер даних? Структуровані дані з фіксованою схемою легше пропустити через CDS, ніж довільні документи.
- Чи можна організаційно? Іноді ручний контроль (співробітник перевіряє кожне повідомлення перед передачею) — достатній і дешевший.
- Які наслідки помилки? Якщо помилка призведе до розголошення таємниці — CDS необхідний. Якщо до службового замішання — можливо, надмірно.
- Що каже регулятор? Для державної таємниці CDS-проект обов'язково узгоджується з СБУ.
Коли CDS справді потрібний
- Системи з державною таємницею з потребою обміну з відкритими мережами — обов'язково.
- OT/IT шлюзи на критичних об'єктах інфраструктури — між системою керування технологічним процесом та офісною мережею.
- Міжнародний обмін чутливою інформацією (з міжнародними партнерами, з ООН-структурами).
- Висока частота обміну (>1000 повідомлень на день), де ручний контроль неможливий.
Коли CDS НЕ потрібний
- Невеликий обсяг обміну з регулярним характером — достатньо ручної процедури з журналом.
- Однорідні рівні захисту — якщо обидві системи однакового грифу, CDS не потрібний, достатньо звичайних мережевих засобів.
- Обмін агрегованими, неперсональними звітами — часто достатньо процедурного контролю.
- Тимчасова потреба у обміні (проєкт триватиме 6 місяців) — побудова CDS не виправдана за вартістю.
Орієнтовні витрати на CDS-проект
| Стаття | Порядок витрат |
|---|---|
| Проєктування | 3-9 місяців експертної роботи |
| Розробка/інтеграція | 6-18 місяців |
| Експертиза CDS | 9-12 місяців (без врахування доопрацювань) |
| Експлуатація на рік | 2-3 FTE спеціалістів |
| Повторна експертиза при суттєвих змінах | 3-6 місяців |
Ризики CDS-проектів
- Архітектурний борг: CDS будується під поточні вимоги. Через 3-5 років вимоги змінюються — CDS не підходить, але вже інтегрований у багато систем.
- Single point of failure: якщо CDS падає — обмін зупиняється. Потрібна резервна архітектура.
- Latency: глибокий аналіз кожного повідомлення додає мілісекунди-секунди до часу передачі.
- False positives: легітимні повідомлення блокуються — потрібна процедура ескалації і ручної верифікації.
- Складна експлуатація: CDS потребує спеціалізованих адміністраторів. Звичайні мережеві адміністратори їх не замінять.
Alternative analysis: правильний підхід
Перед CDS-проектом обов'язково провести alternative analysis — формальне порівняння CDS з організаційними альтернативами:
- Ручна процедура з журналом і подвійним контролем.
- Періодичний пакетний експорт з ручною перевіркою.
- Перевід частини процесів у середовище нижчого рівня.
- Розділення системи на дві окремі без обміну.
Якщо альтернативи не підходять — тоді CDS. Якщо хоча б одна підходить за функціональними вимогами — варто серйозно зважити.
UBD має референсну архітектуру cross-domain gateway з інспекційним проходом у 6 кроків: парсинг → перевірка схеми → видалення заборонених полів → нормалізація → підпис → запис у журнал. Архітектура задокументована, але кожне впровадження вимагає окремого проєктування під специфіку даних і регуляторного контексту. Це не «коробкове» рішення — це методологія.
UnityBaseDefense — технічна довідка →