Управління ідентифікацією в коаліції: федеративна автентифікація в мережах NATO та партнерів

Коли французький офіцер зв'язку підключається до спільної коаліційної командної системи, жодна організація не є єдиним власником її особистих даних. Її облікові дані були видані Міжвидовим директоратом мережевої інфраструктури та інформаційних систем (DIRISI), її допуск було отримано відповідно до французької національної безпекової політики, а ролі були призначені її ланцюгом командування в Парижі. Коаліційний застосунок, до якого вона підключається, функціонує на інфраструктурі під управлінням держави-партнера і за замовчуванням не довіряє жодному з вищезазначеного. Подолати цей розрив надійно, безпечно та без необхідності ручного надання тисяч тимчасових коаліційних облікових записів — це та проблема, яку вирішує управління ідентифікацією в коаліції. У цій статті розглядаються протоколи, структури PKI, схеми атрибутів та механізми політики, що забезпечують коаліційну сумісність на рівні ідентифікації.

Проблема ідентифікації в коаліційних операціях

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

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

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

Протоколи федерації: SAML 2.0, OAuth 2.0 та OIDC для оборонних середовищ

Security Assertion Markup Language 2.0 (SAML 2.0) залишається домінуючим протоколом для федерації ідентифікаційних даних в оборонних та урядових середовищах. Його зрілість, широка реалізація на корпоративних платформах ідентифікації (Microsoft ADFS, Shibboleth, Ping Identity) та модель підтвердження на основі XML-підпису добре узгоджуються з наявною інфраструктурою PKI. Підтвердження SAML — це підписаний XML-документ, що містить заявки щодо ідентифікаційних даних користувача та видається домашнім IdP після локальної автентифікації користувача. Сторона, що спирається на дані, перевіряє підпис підтвердження відносно підписного сертифіката IdP, перевіряє обмеження аудиторії (підтверджуючи, що підтвердження було видане саме для цього конкретного RP), та перевіряє мітку часу підтвердження для запобігання атакам відтворення. Оскільки підтвердження підписується при видачі, RP не потребує прямого підключення до IdP під час перевірки, що є цінним у середовищах коаліції з нерегулярним підключенням.

OAuth 2.0 та OpenID Connect (OIDC) дедалі більше присутні в архітектурах коаліції, оскільки новіші системи використовують REST-орієнтовані API замість SOAP-орієнтованих шаблонів, для яких було розроблено SAML. OIDC розширює OAuth 2.0 стандартизованим ID-токеном (JSON Web Token), що містить заявки щодо ідентифікаційних даних, тоді як токени доступу OAuth 2.0 використовуються для авторизації API-викликів від імені автентифікованого користувача. Коротший формат токена та HTTP-нативні потоки роблять OIDC кращим вибором для мобільних і веб-застосунків. Для використання в коаліції OIDC вимагає доступності сервера авторизації домашньої держави з мережі партнера під час видачі токена, що створює залежність від підключення, якої уникає офлайн-модель підтверджень SAML. Тому багато коаліційних розгортань використовують SAML для первинної автентифікації та видають короткочасні токени OIDC локально на межі партнера, фактично перетворюючи вхідне підтвердження SAML на сесію OIDC, обмежену екосистемою застосунків партнера.

Обидва протоколи вимагають ретельного посилення для оборонних середовищ. Шифрування підтверджень (не лише підпис) є обов'язковим, коли підтвердження перетинають межі мереж, оскільки підписане, але незашифроване підтвердження SAML розкриває рівень допуску, громадянство та призначення ролей користувача будь-якому спостерігачу мережі. TLS 1.3 з взаємною автентифікацією має захищати всі кінцеві точки федерації. Синхронізація часу на всій інфраструктурі IdP та RP є прихованою залежністю: вікна перевірки мітки часу SAML зазвичай встановлюються на п'ять хвилин, і відхилення годинника, що перевищує це вікно, призводить до відмови дійсних підтверджень, блокуючи доступ для постраждалих користувачів без будь-якої очевидної помилки, окрім тайм-ауту автентифікації.

Перехресна сертифікація PKI: поєднання національних центрів сертифікації

Підтвердження федерації ідентифікаційних даних є настільки надійними, наскільки надійні ключі підпису за ними. Кожен IdP SAML підписує свої підтвердження сертифікатом, виданим у рамках ієрархії центру сертифікації. Щоб сторона, що спирається на дані в держави-партнера, довіряла вхідному підтвердженню, вона повинна довіряти CA, що видав підписний сертифікат. У рамках внутрішнього розгортання однієї організації це просто: один CA видає сертифікати всім сторонам, що спираються на дані, і постачальникам ідентифікаційних даних. У коаліції кожна держава керує власною ієрархією CA, видаючи сертифікати в рамках національних законодавчих фреймворків, які системи інших держав за замовчуванням не визнають.

Перехресна сертифікація вирішує це, створюючи явні зв'язки довіри між національними ієрархіями CA. У найпростішій двосторонній формі CA держави A видає перехресний сертифікат для CA держави B (і навпаки). Сторона, що спирається на дані в державі A та довіряє власній ієрархії CA, транзитивно довіряє сертифікатам, виданим під CA держави B. Перехресний сертифікат визначає глибину шляху довіри та може включати обмеження політики, що обмежують використання довірених сертифікатів (наприклад, довіряти сертифікатам держави B лише для перевірки цифрового підпису, але не для шифрування ключа). У NATO Інфраструктура відкритих ключів NATO управляє CA-мостом, що виконує перехресну сертифікацію CA держав-учасниць, дозволяючи єдиним відношенням моста поширювати довіру на всі підключені національні ієрархії замість того, щоб кожна пара держав встановлювала пряму двосторонню перехресну сертифікацію.

Ідентифікатори політики сертифікатів (OID у розширеннях сертифіката) є механізмом, за допомогою якого сторони, що спираються на дані, застосовують рішення про довіру, специфічні для держави. RP коаліції може бути налаштована на прийняття сертифікатів від усіх перехресно сертифікованих національних CA для загальних цілей автентифікації, але вимагати конкретного OID політики (що вказує на облікові дані на основі апаратного токена або певний рівень забезпечення) перед наданням доступу до ресурсів, що підлягають класифікованому допуску. Ця дворівнева модель політики — широка довіра автентифікації, вузька довіра авторизації — дозволяє уникнути операційної проблеми зміни угоди про перехресну сертифікацію кожного разу, коли нова категорія ресурсів вимагає вищого рівня забезпечення, оскільки деталізовані правила існують у локальній політиці RP, а не в інфраструктурі CA.

Мапування ролей у гетерогенних коаліційних каталогах

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

Шар трансляції зазвичай реалізується як набір правил трансформації заявок у RP або брокері ідентифікаційних даних партнера. Правила мають форму умовних зіставлень: якщо вхідне підтвердження містить атрибут громадянства "FRA" та код звання в діапазоні, що відповідає OF-4 до OF-5 за шкалою рангів STANAG NATO, зіставити користувача з локальною групою "coalition-senior-officer". Шкала рангів STANAG є спільною мовою, що робить це можливим: вона надає загальний числовий ідентифікатор для кожного звання у всіх союзних державах, дозволяючи писати правила мапування ролей відносно нейтрального коду STANAG, а не рідного назви звання кожної держави. Держави, що надають особовий склад до коаліції, відповідають за включення еквівалента звання STANAG у свої підтвердження SAML — вимога, яку слід перевіряти під час тестування федерації.

Призначення організаційних ролей становить складнішу задачу для мапування, оскільки жоден стандарт NATO не надає еквівалента кодів звань STANAG для функціональних ролей. Користувач з роллю "аналітик розвідки" в каталозі держави A може потребувати зіставлення з різними локальними ролями залежно від того, до якої з систем партнера він звертається і що поточні коаліційні правила ведення операцій визначають для рівня доступу цієї ролі. Це вимагає, щоб правила мапування ролей підтримувались як живий документ, що оновлюється через процес координації управління ідентифікацією коаліції в міру того, як нові системи приєднуються до федерації та змінюються оперативні вимоги. Виклики обміну даними в коаліції, що виникають через несумісні моделі даних, є найгострішими саме на цій межі трансляції атрибутів.

Атрибутивний контроль доступу для виконання правил допуску

Рольовий контроль доступу (RBAC) призначає дозволи ролям, а ролі — користувачам. Для коаліційних систем ця модель є недостатньою, оскільки рішення про доступ залежать від вимірів, які самі ролі не можуть охопити. Документ з позначкою REL TO USA, GBR, CAN, AUS, NZL (дозволений для розповсюдження державам Five Eyes) має бути доступним для канадського офіцера з допуском SECRET, але не для французького офіцера з еквівалентним рівнем допуску, незалежно від того, чи обидва займають ідентичні функціональні ролі. Допуск є властивістю ресурсу, а не ролі користувача, і правильне його виконання вимагає одночасної оцінки громадянства користувача, допуску, необхідності знання та мітки класифікації ресурсу.

Атрибутивний контроль доступу (ABAC) природно вирішує це завдання. Політика ABAC — це логічне правило, що оцінює атрибути суб'єкта (громадянство, допуск, роль, призначення), атрибути ресурсу (рівень класифікації, застереження щодо допуску, інструкції щодо обробки) та атрибути середовища (рівень класифікації мережі, час доступу) відносно явного положення політики. Політика для наведеного вище документа може читатися так: дозволити доступ, якщо subject.nationality входить до [USA, GBR, CAN, AUS, NZL] ТА subject.clearance >= SECRET ТА resource.classification <= SECRET ТА resource.releasability містить subject.nationality. Це правило є доступним для розробки, підзвітним та незалежним від таксономії ролей будь-якої конкретної держави. Механізм політики оцінює його під час звернення до ресурсу відносно заявок, вилучених з підтвердження SAML, та метаданих ресурсу.

eXtensible Access Control Markup Language (XACML) є найзрілішим стандартом для вираження та оцінки політик ABAC в оборонних середовищах. Точка прийняття рішень (PDP) XACML отримує запит авторизації, що містить атрибути суб'єкта, ресурсу та середовища, оцінює його відносно завантаженого набору політик та повертає рішення про дозвіл або відмову. Точка виконання політики (PEP) у застосунку перехоплює кожен запит до ресурсу, формує запит авторизації, звертається до PDP та виконує рішення. Відокремлення PEP від PDP дозволяє оновлювати, версіонувати та перевіряти політику незалежно від коду застосунку — критична властивість, коли правила допуску змінюються в міру розвитку оперативної ситуації.

Налаштування сторони, що спирається на дані, та управління метаданими у великому масштабі

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

Рішенням є реєстр метаданих федерації: централізовано опублікований, підписаний XML-документ, що перераховує метадані для всіх зареєстрованих IdP та RP у федерації коаліції. Кожен учасник завантажує реєстр за визначеним графіком (зазвичай кожні 4-24 години), витягує записи, що стосуються його конфігурації довіри, та оновлює свою локальну платформу ідентифікаційних даних. Сам реєстр підписується ключем органу реєстру коаліції, і кожен учасник перевіряє цей підпис перед застосуванням будь-яких оновлень — запобігаючи тому, щоб скомпрометований проміжний мережевий вузол міг впровадити хибні метадані для перенаправлення потоків автентифікації. Реєстри метаданих SAML відповідно до специфікації SAML V2.0 Metadata Extensions for Registration and Publication надають технічну основу для цього; програма Federated Mission Networking NATO задокументувала відповідні операційні процеси.

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

Реагування на інциденти: оперативне скасування доступу в федеративній коаліції

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

Короткі терміни дії підтверджень є найефективнішим контролем першого порядку. Підтвердження SAML з вікном дійсності 30 хвилин закінчується до того, як скомпрометовані облікові дані можуть бути широко використані в більшості сценаріїв, без необхідності досягнення сповіщення про скасування позасмуговим каналом на стороні, що спирається на дані. Ціна полягає в тому, що користувач повинен повторно автентифікуватись кожні 30 хвилин, що є прийнятним з безшовною повторною автентифікацією SSO (де IdP тихо видає нове підтвердження без запиту до користувача), але стає операційно руйнівним, якщо IdP недоступний під час вікна повторної автентифікації. Встановлення терміну дії підтвердження вимагає балансування цього компромісу відносно очікуваного профілю підключення коаліційної мережі.

Для скасування сертифікатів PKI доступні два механізми: списки відкликаних сертифікатів (CRL) та протокол онлайн-перевірки статусу сертифіката (OCSP). Скасування на основі CRL публікує підписаний список відкликаних серійних номерів сертифікатів, які сторони, що спираються на дані, завантажують periodically; затримка скасування обмежена інтервалом оновлення CRL, зазвичай 24 години в практиці національної PKI, але настроюється до 1-4 годин для сценаріїв коаліції підвищеної терміновості. OCSP забезпечує статус скасування у реальному часі, але вимагає доступності відповідача OCSP під час автентифікації — та сама залежність від підключення, що й OIDC. Рівневий підхід є доцільним: короткочасні підтвердження SAML як основний контроль, часте завантаження CRL як страховий захист на рівні сертифіката, та прив'язка OCSP на рівні TLS для застосунків, де потрібен статус сертифіката у реальному часі. Процедури сповіщення позасмуговим каналом — задокументовані списки контактів, заздалегідь визначені формати повідомлень та перевірені шляхи ескалації в коаліції — доповнюють можливості реагування на інциденти, яку жоден технічний протокол не може повністю автоматизувати.