Cross-domain рішення: коли воно справді потрібне

Cross-domain solution (CDS) — найскладніший клас систем інформаційної безпеки. Будувати CDS дорого, експлуатувати ще дорожче, повторна експертиза при кожному оновленні. Перш ніж проектувати CDS, варто чесно відповісти на запитання: чи дійсно потрібен CDS, чи можна обійтися організаційними заходами?

Що таке cross-domain

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

На відміну від звичайного фаєрволу, CDS не просто фільтрує пакети — він глибоко аналізує вміст, виконує трансформації, видаляє чутливі поля, перевіряє цілісність і легітимність кожного повідомлення.

Три типи cross-domain

1. Uplift (підвищення рівня)

Дані з менш захищеної мережі переносяться у більш захищену. Менш ризикований напрямок з точки зору розголошення (нижчий рівень виходить у вищий), але є ризики цілісності і шкідливого коду.

Приклад: завантаження дослідницьких даних з відкритого інтернету у захищену аналітичну систему.

2. Downgrade (зниження рівня)

Найскладніший випадок. Дані з більш захищеної мережі переносяться у менш захищену. Ризик прямого розголошення. CDS повинен переконатися, що передаються тільки дозволені до пониження дані, і нічого більше.

Приклад: експорт звітів з системи «обмеженого доступу» у відкриту систему публічної статистики.

3. Lateral (між рівнями того самого класу)

Дані між двома мережами однакового рівня, але різних доменів довіри (наприклад, між системами двох різних відомств). Менш зрозумілий напрямок з регуляторної точки зору, але часто зустрічається у міжвідомчих обмінах.

Правильні запитання перед CDS-проектом

1. Який обсяг передачі? Кілька повідомлень на день — можливо, ручна процедура. Тисячі повідомлень на день — потрібен CDS.
2. Який характер даних? Структуровані дані з фіксованою схемою легше пропустити через CDS, ніж довільні документи.
3. Чи можна організаційно? Іноді ручний контроль (співробітник перевіряє кожне повідомлення перед передачею) — достатній і дешевший.
4. Які наслідки помилки? Якщо помилка призведе до розголошення таємниці — CDS необхідний. Якщо до службового замішання — можливо, надмірно.
5. Що каже регулятор? Для державної таємниці CDS-проект обов’язково узгоджується з СБУ.

Коли CDS справді потрібний

• Системи з державною таємницею з потребою обміну з відкритими мережами — обов’язково.
• OT/IT шлюзи на критичних об’єктах інфраструктури — між системою керування технологічним процесом та офісною мережею.
• Міжнародний обмін чутливою інформацією (з міжнародними партнерами, з ООН-структурами).
• Висока частота обміну (>1000 повідомлень на день), де ручний контроль неможливий.

Коли CDS НЕ потрібний

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

Орієнтовні витрати на CDS-проект

Ризики CDS-проектів

• Архітектурний борг: CDS будується під поточні вимоги. Через 3-5 років вимоги змінюються — CDS не підходить, але вже інтегрований у багато систем.
• Single point of failure: якщо CDS падає — обмін зупиняється. Потрібна резервна архітектура.
• Latency: глибокий аналіз кожного повідомлення додає мілісекунди-секунди до часу передачі.
• False positives: легітимні повідомлення блокуються — потрібна процедура ескалації і ручної верифікації.
• Складна експлуатація: CDS потребує спеціалізованих адміністраторів. Звичайні мережеві адміністратори їх не замінять.

Alternative analysis: правильний підхід

Перед CDS-проектом обов’язково провести alternative analysis — формальне порівняння CDS з організаційними альтернативами:

• Ручна процедура з журналом і подвійним контролем.
• Періодичний пакетний експорт з ручною перевіркою.
• Перевід частини процесів у середовище нижчого рівня.
• Розділення системи на дві окремі без обміну.

Якщо альтернативи не підходять — тоді CDS. Якщо хоча б одна підходить за функціональними вимогами — варто серйозно зважити.