Впровадження STANAG 4774/4778: мітки конфіденційності на практиці

Безпека з фокусом на даних – ідея, що захист слідує за об'єктом даних, а не за периметром мережі – не нова, але її практична реалізація в коаліційних військових системах історично була складною. STANAG 4774 та STANAG 4778 – формальна відповідь NATO: два взаємопов'язані стандарти, що визначають, як структуруються мітки конфіденційності, як вони прив'язуються до даних і як механізми політики їх оцінюють. Ця стаття охоплює практичну інженерію відповідної реалізації маркування: синтаксис мітки, механізм прив'язки, проєктування точки забезпечення політики, обробку агрегації та дисципліну збереження міток, що визначає, чи переживе ваша архітектура перевірку акредитації. Щодо контексту політики класифікації та releasability, що обрамляє цю інженерну роботу, див. супутню статтю про класифікацію STANAG 4774/4778 та коаліційну releasability.

Модель безпеки з фокусом на даних: чому мітки подорожують з даними

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

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

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

Синтаксис мітки STANAG 4774: структура та кодування

Мітка конфіденційності STANAG 4774 – це XML-документ, що відповідає XML-схемі STANAG 4774. Його елемент верхнього рівня – <ConfidentialityLabel>, який несе три обов'язкові дочірні елементи та кілька необов'язкових розширень.

Ідентифікатор політики. Елемент <PolicyIdentifier> містить об'єктний ідентифікатор (OID), що посилається на документ політики міток, який регулює цю мітку. OID реєструється у визнаному органі – зазвичай національному офісі C3 чи агентстві NATO C3 – і є ключем, що дозволяє приймальним системам шукати повне визначення політики й правильно оцінювати мітку. Мітка без розв'язуваного OID політики не може бути оцінена відповідним механізмом політики та має розглядатися як неперевірена.

Класифікація. Елемент <Classification> визначає рівень класифікації як перелічуване значення: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL чи SECRET. Кодування чутливе до регістру й має точно відповідати рядковим значенням, визначеним у документі політики, на який посилається OID. Мітка, що використовує "Secret" замість "SECRET", не пройде перевірки схеми у відповідній реалізації – поширена помилка інтеграції під час генерації міток із загальноцільових XML-бібліотек, що не забезпечують перелік.

Застереження щодо поводження та releasability. Елемент <CategoryData> несе застереження щодо поводження, як-от ATOMAL, CRYPTO, EYES ONLY чи специфічні для місії застереження, визначені політикою. Елемент <PermittedCountryCodes> несе позначку releasability як набір кодів країн ISO 3166-1 alpha-3. Позначка releasability – найважливіша оперативно частина мітки в багатонаціональних середовищах: вона визначає, яким системам партнерських націй дозволено отримувати марковані дані, незалежно від рівня класифікації.

Генерація міток: вимоги до перевірки

Кожна мітка, згенерована відповідною системою, має бути перевірена за XML-схемою STANAG 4774 перш ніж її буде прив'язано до будь-якого об'єкта даних. Перевірка схеми ловить структурні помилки – некоректні OID, недійсні рядки класифікації, відсутні обов'язкові елементи – але не перевіряє семантичну коректність за документом політики. Окремий крок перевірки на рівні політики має звіряти, що кожне застереження й позначка releasability в мітці визначені в документі політики, на який посилаються, і що комбінація рівня класифікації та застережень дозволена цією політикою. Реалізація, що пропускає перевірку на рівні політики, генеруватиме мітки, які проходять перевірку схеми, але відхиляються подальшими механізмами політики з помилками, які важко діагностувати постфактум. Вбудуйте крок перевірки на рівні політики в генератор міток, а не в окремий аудит після генерації.

Механізми прив'язки STANAG 4778: твердження та інкапсуляція

STANAG 4778 визначає два механізми прив'язки мітки STANAG 4774 до об'єкта даних: прив'язку-твердження та прив'язку-інкапсуляцію. Вони служать різним сценаріям використання та мають різні властивості безпеки, і вибір між ними має бути зроблений на етапі проєктування архітектури.

Прив'язка-твердження породжує підписане XML-твердження, що включає мітку, посилання на об'єкт даних (зазвичай криптографічний хеш корисного навантаження) та цифровий підпис від органу міток. Підпис обчислюється за допомогою XML Digital Signature (XMLDSig) над канонізованим XML мітки. Об'єкт даних і підписане твердження передаються разом – або в тому самому конверті повідомлення, або як пара посилання-і-твердження. Приймальна система перевіряє твердження, звіряючи підпис з сертифікатом відкритого ключа органу міток, потім звіряє хеш об'єкта даних із хешем у твердженні. Якщо обидві перевірки пройдено, мітка перевірена як автентична й незмінена, а прив'язка між міткою та об'єктом даних криптографічно підтверджена.

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

Прив'язка-інкапсуляція вбудовує мітку безпосередньо в структуру об'єкта даних – у заголовок повідомлення, блок метаданих чи визначене поле розширення. Окремого криптографічного підпису немає; прив'язка покладається на цілісність транспортного каналу. Прив'язка-інкапсуляція простіша в реалізації та широко використовується для даних, що залишаються в межах одного домену безпеки. Для системи C2, що працює повністю в межах анклаву SECRET, прив'язки-інкапсуляції в схемі повідомлення достатньо, і вона уникає накладних витрат PKI прив'язки-твердження для кожного внутрішнього повідомлення.

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

Проєктування точки забезпечення політики

Точка забезпечення політики (PEP) – це програмний компонент, що перехоплює запити доступу та обміну даними й оцінює мітку запитуваного об'єкта відносно допуску суб'єкта-запитувача та рівня акредитації системи-запитувача. У архітектурі, сумісній зі STANAG 4774/4778, PEP не є необов'язковою: це механізм, за допомогою якого мітка породжує фактичний контроль доступу, а не є лише анотацією метаданих, яку ніколи не оцінюють.

Алгоритм оцінки PEP має правильно реалізувати домінування. Суб'єкт може отримати доступ до об'єкта тоді й лише тоді, коли допуск суб'єкта домінує над міткою об'єкта: рівень класифікації суб'єкта принаймні настільки ж високий, як в об'єкта, і суб'єкт має всі застереження, потрібні позначками поводження об'єкта, і уповноважений набір releasability суб'єкта покриває всі позначки releasability об'єкта. Кожну з цих трьох умов треба оцінювати незалежно; проходження двох із трьох є порушенням політики, а не частковим наданням доступу.

Найчастіше неправильно реалізованою умовою є releasability. Коректне порівняння releasability перевіряє, що уповноважений набір releasability приймальної системи є надмножиною позначки releasability об'єкта. Система, уповноважена на REL TO DEU GBR USA, може отримати об'єкт, маркований REL TO DEU GBR, бо уповноважений набір містить усі марковані нації. Система, уповноважена на REL TO GBR USA, не може отримати об'єкт, маркований REL TO DEU GBR, навіть якщо GBR з'являється в обох наборах, бо DEU немає в уповноваженому наборі приймальної системи. Реалізація перевірки надмножини, а не перевірки перетину, є коректною логікою; перевірка перетину – поширена помилка, що породжує систему, яка надає доступ до об'єктів, які вона не уповноважена отримувати.

Агрегація та підвищення міток

Агрегація – поєднання двох чи більше маркованих об'єктів у похідний продукт – є найскладнішою проблемою в практичній реалізації STANAG 4774/4778. Похідний продукт має нести мітку, яка є принаймні настільки ж обмежувальною, як найбільш обмежувальний вхід, за всіма трьома компонентами мітки: рівнем класифікації, застереженнями щодо поводження та releasability.

Для рівня класифікації правило просте: вихідна класифікація – це максимум вхідних класифікацій. Продукт, похідний від входів RESTRICTED і CONFIDENTIAL, є CONFIDENTIAL. Для застережень щодо поводження вихід має включати об'єднання всіх вхідних застережень: якщо один вхід несе ATOMAL, а інший CRYPTO, вихід має нести обидва. Для releasability вихід має нести перетин вхідних наборів releasability: якщо один вхід releasable для DEU GBR USA, а інший для GBR FRA, вихід releasable лише для GBR, бо лише GBR уповноважений для обох входів.

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

Збереження міток при коаліційному обміні

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

В інфраструктурі обміну, сумісній з Federated Mission Network (FMN), збереження міток вбудоване в профіль: рівень служб FMN зобов'язаний нести мітки STANAG 4774 в конвертах повідомлень та перевіряти прив'язки під час прийому. На практиці багато розгорнутих систем містять компоненти, що передують відповідності FMN або були інтегровані без розуміння міток – застарілі ретранслятори повідомлень, невідповідні маршрутизатори CoT, проміжне ПЗ баз даних, що відрізає метадані при вставці. Кожен такий компонент становить потенційну точку втрати мітки, яку треба ідентифікувати та пом'якшити в проєкті системи.

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

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