Покроковий гайд з імплементації сумісності NATO, Частина 3: STANAG 4774/4778 класифікація та коаліційний releasability

Канали передачі даних із Частини 2 переміщують повідомлення. Машинерія класифікації та releasability вирішує, які повідомлення кому переміщуються. STANAG 4774 визначає формат міток конфіденційності; STANAG 4778 визначає криптографічне зв'язування, що не дозволяє відокремити мітку від даних, які вона маркує. Разом вони — технічний фундамент усього обміну даними в коаліції NATO. Платформа, яка реалізує їх правильно, розгортається у класифікованих мережах; платформа, що трактує їх як UI-маску, провалює акредитацію вже на першому циклі огляду. Частина 3 охоплює дисципліну імплементації.

Пілар-рівневе обрамлення — у Повному посібнику із сумісності NATO; ширші патерни коаліційного обміну — у Викликах обміну даними в коаліції; фундамент RBAC — у Контроль доступу на основі ролей в оборонних C2-системах; поширення на стороні fusion — у Побудова оборонного fusion-пайплайна, Частина 3.

Крок 1: Мітки — це структуровані дані, а не рядки

Найпоширеніша помилка імплементації — трактувати класифікацію як рядкове поле — «SECRET», «NATO RESTRICTED» — приєднане до записів даних. Модель STANAG 4774 багатша та структурно інша.

Мітка конфіденційності за STANAG 4774 — це структурований об'єкт з такими полями:

• Ідентифікатор політики. Політика класифікації, за якою мітку було присвоєно (NATO, національна, FVEY, EU). Політика визначає чинні рівні класифікації та компартменти.
• Рівень класифікації. Впорядковане значення в межах політики — для NATO: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, COSMIC TOP SECRET.
• Компартменти. Іменовані застереження, що обмежують доступ — оперативно значущі, програмо-специфічні, часто самі по собі засекречені.
• Теги releasability. Які нації чи організації можуть отримати марковані дані — FVEY, REL TO NATO, REL TO конкретних націй.
• Застереження. Додаткові обмеження (NOFORN, ORCON та інші, залежно від політики).
• Походжувач. Сутність-продуцент — для аудиту та підзвітності.
• Часова мітка створення. Коли мітку було присвоєно.

Реалізуйте це як структуровані типи з валідацією. Рядок «SECRET REL FVEY», розбираний у рантаймі через пошук підрядків, — інженерний патерн, що провалює акредитацію. Структуровані типи, валідовані за схемою на кожному кордоні, — патерн, що проходить.

Крок 2: Криптографічне зв'язування за STANAG 4778

STANAG 4778 визначає криптографічне зв'язування, що гарантує неможливість відокремлення мітки від даних, які вона маркує. Зв'язування обчислюється продуцентом і верифікується кожним споживачем; без верифікації мітку можна зняти, підмінити чи спотворити.

Патерн імплементації:

Обчислюйте зв'язування у сервісі-продуценті. Коли адаптер, fusion-сервіс або інший компонент продукує дані, він обчислює зв'язування над парою (мітка, дані) своїм підписним ключем. Ключ закріплений у апаратно-укоріненому довірчому сховищі; операцію підпису логують.

Верифікуйте при кожному читанні. Споживачі (COP, downstream-аналітика, зовнішні API-шлюзи) верифікують зв'язування перед поширенням даних. Збої верифікації логуються голосно, а дані відхиляються — не тихо знижуються в класифікації.

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

Поатрибутне зв'язування там, де потрібно. Деякі об'єкти даних мають атрибути різних класифікацій. Трек може мати UNCLASSIFIED позицію, але SECRET ідентичність. STANAG 4778 вміщує поатрибутне зв'язування; платформа реалізує його там, де цього вимагає класифікаційна модель.

Крок 3: Поширення класифікації через fusion та похідні

Оборонні платформи продукують похідні дані. Трек виводиться з кількох вихідних спостережень; fused-продукт — із кількох розвідувальних звітів. Класифікація похідних даних обчислюється з класифікації джерел — а не присвоюється незалежно.

Правила поширення (повторення з fusion-серії та пілара):

• Рівень класифікації: максимум. Похідна з джерел SECRET та UNCLASSIFIED — це SECRET.
• Компартменти: об'єднання. Похідна з джерел компартмент-A та компартмент-B несе обидва компартменти.
• Releasability: перетин. Похідна з джерел FVEY-only та NATO-only випускна лише на перетин.
• Застереження: найсуворіше. NOFORN на будь-якому джерелі робить похідну NOFORN.

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

Крок 4: Policy engine

Мітки на даних необхідні, але недостатні. Рішення про доступ потребують policy engine, який знає допуск, громадянство та роль користувача, а також класифікацію, компартменти та releasability запитуваних даних. Кожен запит до платформи проходить через цей рушій.

Патерн імплементації:

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

Оцінка рішень на кордоні запиту. Коли споживач запитує платформу, policy engine оцінює, які записи видимі та які атрибути видимі в кожному записі. Результат — відфільтрований вид, обчислений під час запиту. Фільтрація лише на UI — надсилання повних даних клієнту і приховування їх CSS чи JavaScript — порушення Common Criteria та миттєвий провал акредитації.

Аудит-лог на кожне рішення. Кожне рішення про доступ — користувач, запитувані дані, класифікація, результат — логується незмінно. Аудит-лог — доказова база для after-action review, форензики та періодичного акредитаційного огляду.

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

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

Крок 5: Між-анклавні потоки даних

Оборонні мережі — не один анклав. Платформа, що працює крізь NATO RESTRICTED, NATO SECRET та національні класифіковані мережі, мусить переміщувати відповідні дані між ними, водночас запобігаючи невідповідним потокам.

Патерни:

Поанклавні екземпляри платформи. Кожен класифікований анклав запускає свій екземпляр платформи з власним сховищем даних, policy engine та аудит-логом. Екземпляри фізично розділені; платформа не припускає, що вони ділять стан.

Cross-domain мости. Там, де дані легально переміщуються між анклавами — UNCLASSIFIED AIS, що йде вгору в SECRET-анклав, releasability-зачищений продукт, що йде вниз у коаліційний анклав — переміщення йде через акредитоване cross-domain рішення. Міст забезпечує правила класифікації на кордоні.

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

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

Детальне інженерне розглядання коаліційного обміну даними — у Викликах обміну даними в коаліції.

Крок 6: Коаліційно-специфічний releasability

Різні коаліції мають різні правила releasability. Платформа, що хоче розгортатися у багатьох коаліційних контекстах, мусить вміщувати:

NATO releasability. Стандартний набір рівнів класифікації NATO та маркування REL TO NATO. Більшість оперативних платформ цілять у цей базовий рівень першочергово.

FVEY-only. Розвідувальна домовленість Five Eyes (AUS, CAN, NZ, UK, US) використовує політики класифікації, які не лягають охайно на рівні NATO. Платформа, що цілить у FVEY-контексти, реалізує політику FVEY поряд із NATO.

Двосторонні домовленості. Багато платформ мають двосторонні домовленості про обмін даними з конкретними партнерами. Україна, Ізраїль, Корея, Японія — усі мають програмо-специфічні домовленості. Releasability-рушій вміщує їх як специфічні REL TO маркування плюс партнеро-специфічний доступ до компартментів.

EU releasability. Програми, фінансовані EU, мають власну політику класифікації (EU CONFIDENTIAL, EU SECRET), яка не складається на рівні NATO. EDF-фінансовані платформи мусять вміщувати і класифікацію NATO, і EU.

Дисципліна: реалізуйте мультиполітичний класифікаційний рушій, а не одну політику. Рушій знає про NATO, FVEY, EU та двосторонні політики як іменовані сутності; дані несуть політику, за якою їх було класифіковано; policy engine оцінює доступ проти допуску користувача за кожною застосовною політикою.

Крок 7: Генерація акредитаційних доказів

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

Докази, які акредитаційні оглядачі вважають достовірними:

• Покликання на код, що показують, де реалізовані правила поширення класифікації, з простежуваністю від політики до коду.
• Зразки аудит-логу, що демонструють поелементне логування у спектрі сценаріїв доступу.
• Результати тестів з автоматизованого тестового набору платформи, що покривають поширення класифікації, releasability-фільтрацію та верифікацію зв'язування на змагальних входах.
• Докази операційного розгортання — місяці чи роки продакшн-роботи з документованим реагуванням на інциденти, запобіганням витоків класифікації та проходженнями періодичних акредитаційних оглядів.
• Логи cross-domain трансферів, що демонструють: переміщення між анклавами було обґрунтоване, затверджене та зафіксоване.
• Звіти пентестів з red-team вправ, що спеціально цілять у машинерію класифікації.

DevSecOps-дисципліна, що генерує ці докази автоматично, висвітлена в DevSecOps для оборонних пайплайнів. Підтримувальні акредитаційні фреймворки (ISO 27001, AQAP-2110, NIST) висвітлені в ISO 27001 в оборонному ПЗ та NATO AQAP-2110 для постачальників ПЗ.

Що далі

Частина 3 реалізувала машинерію класифікації. Мітки STANAG 4774 як структуровані дані, зв'язування STANAG 4778, верифіковане на кожному кордоні, поширення через fusion та похідні, policy engine, що забезпечує releasability під час запиту, вміщені між-анклавні потоки, підтримуваний мультикоаліційний releasability, вбудована генерація доказів.

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