Міждоменні рішення для оборони: безпечне переміщення даних між рівнями таємності

Міждоменне рішення (CDS) — це апаратно-програмна система, що забезпечує контрольовану передачу даних між мережами, які функціонують на різних рівнях таємності — наприклад, з оперативної мережі SECRET до коаліційного порталу UNCLASSIFIED, або з нетаємного сенсорного потоку до системи командування і управління рівня SECRET. Без CDS ці дві мережі мають залишатися повністю ізольованими: між ними взагалі не може передаватися жодних даних. Із CDS чітко визначені передачі можуть здійснюватися під суворим контролем дотримання політики, що дозволяє таємній розвідувальній інформації формувати нетаємні тактичні рішення, а нетаємним даним — надходити до таємної аналітики без ризику компрометації мережі вищого рівня таємності.

Технологія CDS знаходиться на перетині політики, інженерії та законодавства у сфері національної безпеки. Правильний вибір, розгортання та інтеграція CDS є одним із найважливіших архітектурних рішень у класифікованій оборонній програмі. Недостатньо специфіковане або неправильно інтегроване CDS або є надмірно обмежувальним — блокуючи оперативно необхідні потоки даних і знижуючи ефективність виконання місії, — або надто ліберальним, створюючи контрольований шлях, яким чутлива інформація може витікати до мереж нижчого рівня таємності. Ця стаття охоплює архітектуру, акредитацію та шаблони інтеграції, необхідні архітекторам безпеки та ІТ-директорам оборонних відомств для прийняття обґрунтованих рішень.

Чому міждоменна передача є оперативно необхідною

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

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

Агрегація сенсорних даних між рівнями таємності забезпечує зворотний потік. Нетаємна розвідка з відкритих джерел (OSINT), комерційно доступні супутникові знімки та сенсорні потоки від партнерських держав мають надходити до аналітичних середовищ рівня SECRET або вище для злиття з таємними даними. CDS забезпечує контрольований шлях приймання: нетаємні дані потрапляють до середовища вищого рівня таємності через захисний шлюз, де їх можна об'єднати з таємними даними, які ніколи не покидають мережу вищого рівня.

Коаліційні операції формують вимоги до міждоменної передачі через національні класифікаційні межі. Маркування REL (Releasable) NATO та рівень таємності Mission Secret визначають, яку інформацію можна передавати конкретним державам-партнерам, але технічний механізм для забезпечення дотримання цих правил обміну на мережевому рівні вимагає CDS, яке розуміє та дотримується політики обміну даними коаліції.

Архітектурні шаблони CDS

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

Однонаправлені діоди є найпростішою та найнадійнішою архітектурою CDS. Однонаправлений діод — це апаратний пристрій, який фізично забезпечує односторонній потік даних за допомогою оптичної ізоляції: передавач на вищому рівні надсилає дані через оптоволоконне з'єднання до приймача на нижчому рівні без жодного зворотного шляху, фізично можливого. Оскільки зворотного каналу немає, мережа вищого рівня не може отримати жодної інформації від мережі нижчого рівня — навіть пакетів підтвердження TCP. Однонаправлені діоди використовуються там, де надійність абсолютного одностороннього потоку є важливішою за ефективність протоколу. Вони потребують адаптації протоколу (зазвичай насосів даних на базі UDP) для обходу відсутності підтвердження TCP і не виконують перевірку вмісту — вони передають усі дані у зазначеному напрямку. Типові варіанти застосування включають односторонній експорт журналів із класифікованих систем до SIEM-платформ, односторонні сенсорні потоки даних до класифікованих мереж та односторонню публікацію попередньо затверджених масивів даних.

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

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

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

Системи акредитації: UCDMO, NSA та NATO

Продукти CDS, що використовуються в системах національної безпеки США, мають бути включені до базового переліку Unified Cross Domain Management Office (UCDMO) — авторитетного переліку продуктів CDS, оцінених і схвалених NSA. Базовий перелік UCDMO ведеться Національним офісом стратегії та управління міждоменними рішеннями NSA (NCDSMO) і доступний для відповідно допущених програмних офісів через класифіковані канали. Продукт потрапляє до переліку через процес оцінювання NSA, який аналізує архітектуру безпеки, реалізацію та операційні процедури відповідно до вимог відповідного профілю захисту.

Процес оцінювання нового продукту CDS зазвичай займає від 18 до 36 місяців. Для програмних офісів практичний висновок очевидний: проектуйте свою міждоменну архітектуру навколо продуктів, уже включених до базового переліку UCDMO. Спроба запровадити новий, ще не оцінений продукт у вашу програму відкладе вашу акредитацію на роки.

Навіть при використанні продукту, що є у переліку, його розгортання в конкретному середовищі вимагає акредитації об'єкта. Пакет акредитації об'єкта документує конкретну конфігурацію CDS, чинну політику перевірки вмісту для кожного затвердженого потоку даних, інтеграцію з оточуючою системою та операційні процедури управління та моніторингу CDS. Акредитуючий орган перевіряє цей пакет і надає Дозвіл на експлуатацію (ATO) для конкретного розгортання. Акредитації об'єктів зазвичай займають від 3 до 9 місяців залежно від складності інтеграції та завантаженості акредитуючого органу.

Акредитація NATO здійснюється через Агентство зв'язку та інформації NATO (NCI Agency) та національні органи безпеки зв'язку. Продукти CDS NATO оцінюються відповідно до специфічних для NATO профілів захисту та включаються до переліку, еквівалентного базовому переліку UCDMO. Продукти, схвалені для систем національної безпеки США, автоматично не схвалюються для використання в NATO — потрібне окреме оцінювання та включення до переліку, хоча постачальники зазвичай проводять обидва процеси паралельно.

Класифіковані інформаційні системи ЄС регулюються правилами безпеки класифікованої інформації ЄС (EUCI), а акредитація здійснюється Комітетом безпеки Ради та національними органами акредитації безпеки. Продукти CDS, що використовуються в середовищах, класифікованих за стандартами ЄС, мають бути схвалені в рамках системи ЄС, знову ж таки через окремий процес оцінювання.

Категорії продуктів CDS та ринкові гравці

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

Захисні шлюзи мережевого рівня функціонують на рівні IP/TCP і інтегруються в мережеву інфраструктуру між двома мережами різних рівнів таємності. Вони забезпечують фільтрацію протоколів, фільтрацію IP та базову перевірку вмісту. Вони є доречними для масових передач даних, де вимоги до перевірки вмісту відносно прості (тип файлу та сканування на шкідливе програмне забезпечення) і затримка не є критичною.

Захисні шлюзи рівня застосунків функціонують на рівні прикладного протоколу — електронна пошта, передача файлів, вебсервіси — та інтегруються з конкретними прикладними протоколами. Поштові захисні шлюзи перевіряють електронні повідомлення та вкладення відповідно до політики безпеки; захисні шлюзи передачі файлів перевіряють окремі файли відповідно до затверджених схем та правил типів файлів; захисні шлюзи вебсервісів виступають API-проксі, що перевіряють корисне навантаження запитів і відповідей. Захисні шлюзи рівня застосунків забезпечують більш широкі можливості перевірки вмісту, ніж захисні шлюзи мережевого рівня, але вимагають інтеграції з конкретними застосунками з обох боків межі.

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

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

Шаблони інтеграції для оборонного програмного забезпечення

Архітектори оборонного програмного забезпечення мають проектувати свої застосунки для взаємодії з наявним або запланованим CDS. CDS зазвичай закуповується та управляється окремо від прикладного програмного забезпечення — ваш застосунок не контролює CDS; він надсилає до нього дані та отримує від нього затверджені дані. Шаблон інтеграції має бути обраний відповідно до підтримуваних інтерфейсів продукту CDS та вимог до потоку даних.

Шаблон API-проксі: застосунок вищого рівня надсилає дані до API-ендпоінту, керованого CDS (зазвичай REST або SOAP). CDS перевіряє корисне навантаження і, якщо воно затверджене, пересилає його на відповідний ендпоінт нижчого рівня. Застосунок отримує синхронну відповідь, яка вказує на схвалення або відхилення. Цей шаблон є доречним для низькообсягних, толерантних до затримок передач, де застосунку потрібен негайний зворотний зв'язок щодо того, чи було схвалено передачу.

Шаблон черги повідомлень: застосунок вищого рівня публікує повідомлення до черги повідомлень (JMS, AMQP або власна черга CDS). CDS читає повідомлення з черги, перевіряє кожне з них та повторно публікує затверджені повідомлення до черги нижчого рівня, звідки їх читає отримуючий застосунок. Відхилені повідомлення журналюються та генерується сповіщення. Цей шаблон є доречним для передач з більшим обсягом та асинхронних передач, де бажано роз'єднати застосунки, що продукують і споживають дані. Застосунок повинен обробляти випадок, коли повідомлення відхилено і не доставлено на протилежний бік.

Шаблон поштового шлюзу: застосунок вищого рівня генерує електронні повідомлення зі структурованими вкладеннями (PDF-звіти, файли XML-даних) і надсилає їх через поштовий ретранслятор CDS. CDS виступає агентом передачі пошти (MTA), що перевіряє повідомлення та вкладення перед пересиланням на поштовий сервер нижчого рівня. Цей шаблон є найпоширенішим для ініційованих людиною публікацій даних — аналітик складає звіт, додає PDF-файл та надсилає його до списку розсилки в мережі нижчого рівня. CDS видаляє метадані з PDF, сканує на маркування таємності та доставляє санований лист, якщо він пройшов перевірку.

Незалежно від шаблону інтеграції, код застосунку має коректно обробляти відхилення CDS. Передачі можуть бути відхилені з причин, пов'язаних із політикою (вміст містить маркування таємності, яке не має бути опубліковане), технічних причин (неправильно сформований XML, несподіваний тип файлу) або тимчасових причин (CDS тимчасово недоступний). Застосунок має визначити чітку поведінку для кожного випадку: сповіщення оператора, черга карантину, логіка повторних спроб та журналювання аудиту кожної спроби передачі та її результату.

Як сформулювати вимоги до CDS для нової оборонної системи

Раннє формулювання вимог до CDS дозволяє уникнути дорогого пізнього перепроектування архітектури, що виникає внаслідок ставлення до міждоменних передач як до другорядного питання. Процес формулювання вимог має призвести до офіційного документа «Вимоги до міждоменних передач», який стає частиною базового переліку вимог безпеки системи.

Крок 1 — Визначте всі міждоменні потоки даних. Нанесіть на карту кожен потік даних у системі, що перетинає межу таємності. Для кожного потоку задокументуйте: рівні таємності джерела та призначення, тип і формат даних, напрямок передачі, вимоги до обсягу та затримки, а також оперативну необхідність, яку підтримує цей потік. Цей перелік є основою для всіх наступних рішень.

Крок 2 — Визначте відповідну систему акредитації. Встановіть, чи буде програма використовувати US UCDMO, NATO, EU-ACC або національну систему. Це визначає, які переліки продуктів є авторитетними та який акредитуючий орган має схвалити пакет акредитації об'єкта. Залучайте акредитуючий орган на ранньому етапі — їхній внесок щодо прийнятних архітектур може заощадити місяці перепроектування.

Крок 3 — Оберіть архітектуру CDS. Підберіть архітектуру (однонаправлений діод, захисний шлюз «з вищого на нижчий», двосторонній захисний шлюз) до характеристик потоку даних. Надавайте перевагу простішим архітектурам там, де це оперативно можливо — однонаправлений діод, що відповідає вимогам, є кращим, ніж двосторонній захисний шлюз, що вносить зайву складність і збільшує поверхню атаки.

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

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

Крок 6 — Виконайте збірку та тестування на репрезентативному екземплярі CDS. Отримайте тестову одиницю від постачальника та розробіть автоматизовані інтеграційні тести, що охоплюють: проходження затверджених даних, блокування відхилених даних, обробку неправильно сформованих даних і режими відмови CDS.

Крок 7 — Підготуйте пакет акредитації об'єкта. Скомпілюйте документацію акредитації та подайте до акредитуючого органу заздалегідь до запланованої дати введення в експлуатацію. Плануйте від 3 до 9 місяців на час перевірки.

Для програм, де вимогу до CDS виявлено пізно — після того, як архітектуру застосунку вже визначено — інтеграційна робота є складнішою, але ті самі принципи застосовуються. Залучайте команду інтеграції постачальника CDS на ранньому етапі: вони мають досвід адаптації свого продукту до різних архітектур застосунків і можуть визначити найменш проблематичний шлях інтеграції для вашої конкретної ситуації. Для розуміння того, як інтеграція CDS вписується в ширшу архітектуру захищеної хмари, ознайомтеся з нашою статтею про архітектуру нульової довіри для військових мереж та про те, як шаблони розгортання з повітряним зазором доповнюють керовані CDS шляхи передачі. Щодо управління секретами та ключами, яке має супроводжувати будь-яке розгортання CDS, дивіться статтю про управління секретами у конвеєрах CI/CD оборонних систем.