Zarządzanie tożsamością w koalicji: uwierzytelnianie federacyjne w sieciach NATO i partnerów

Gdy francuski oficer łącznikowy łączy się ze wspólnym koalicyjnym systemem dowodzenia, żadna pojedyncza organizacja nie jest właścicielem jej tożsamości. Jej poświadczenia zostały wydane przez Direction Interarmées des Réseaux d'Infrastructure et des Systèmes d'Information (DIRISI), jej uprawnienia zostały zatwierdzone zgodnie z francuską krajową polityką bezpieczeństwa, a role zostały przypisane przez jej przełożonych w Paryżu. Aplikacja koalicyjna, z którą się łączy, działa na infrastrukturze zarządzanej przez kraj partnerski i domyślnie nie ufa żadnemu z powyższych. Niezawodne, bezpieczne wypełnienie tej luki bez konieczności ręcznego zakładania tysięcy tymczasowych kont koalicyjnych to właśnie problem, który rozwiązuje zarządzanie tożsamością w koalicji. Niniejszy artykuł analizuje protokoły, struktury PKI, schematy atrybutów i mechanizmy polityki umożliwiające interoperacyjność koalicyjną na poziomie tożsamości.

Problem tożsamości w operacjach koalicyjnych

Operacje koalicyjne skupiają personel z wielu suwerennych państw w ciągu dni. Stały połączony zespół zadaniowy może obejmować kontrybutorów z kilkudziesięciu krajów, z których każdy działa w oparciu o własny reżim zarządzania tożsamością, własną infrastrukturę katalogową i wydaje poświadczenia w ramach własnej krajowej hierarchii PKI. Przed pojawieniem się federacyjnych rozwiązań tożsamości standardowym podejściem było ręczne zakładanie kont: personel łącznikowy na granicy systemów każdego kraju tworzył lokalne konta dla przychodzących użytkowników koalicji, ręcznie przypisywał uprawnienia i dezaktywował te konta po rotacji użytkownika. Proces ten był powolny, podatny na błędy, niespójnie dokumentowany i tworzył trwałe nieaktywne konta, które pozostawały aktywne długo po tym, jak reprezentowany przez nie personel opuścił koalicję.

Zasadnicze wymaganie polega na tym, że uwierzytelnianie i autoryzacja muszą pozostawać pod suwerenną kontrolą, jednocześnie umożliwiając dostęp przez granice krajowe. Żaden kraj nie zaakceptuje scentralizowanego organu tożsamości koalicji, który mógłby zostać przejęty, skompromitowany lub politycznie wykorzystany przez innego członka. Architektura nie może zatem opierać się na pojedynczym magazynie tożsamości, do którego wszystkie kraje przystępują federacyjnie. Zamiast tego musi traktować dostawcę tożsamości każdego kraju jako równorzędnego uczestnika, ustanawiając dwustronne lub wielostronne relacje zaufania między nimi bez rezygnowania z krajowej kontroli nad poświadczeniami. To właśnie ten definiujący ogranicznik sprawia, że zarządzanie tożsamością w koalicji jest architektonicznie odmienne od jednokrotnego logowania w przedsiębiorstwie.

Praktyczną konsekwencją jest to, że każda transakcja tożsamości przez granicę koalicyjną angażuje co najmniej trzy strony: macierzysty dostawca tożsamości użytkownika, strona ufająca będąca właścicielem zasobu w kraju partnerskim oraz ramy zaufania, na których obie strony uzgodniły działanie. Jak opisano w przewodniku wdrożeniowym Federated Mission Networking, te ramy zaufania są dokumentowane w umowach federacji określających, jakie atrybuty będą wymieniane, jakich formatów twierdzeń się oczekuje i jak będą podejmowane decyzje dostępowe na granicy.

Protokoły federacji: SAML 2.0, OAuth 2.0 i OIDC dla środowisk obronnych

Security Assertion Markup Language 2.0 (SAML 2.0) pozostaje dominującym protokołem federacji tożsamości w środowiskach obronnych i rządowych. Jego dojrzałość, szerokie wdrożenie na platformach tożsamości przedsiębiorstw (Microsoft ADFS, Shibboleth, Ping Identity) oraz model twierdzenia oparty na podpisie XML dobrze współgrają z istniejącą infrastrukturą PKI. Twierdzenie SAML to podpisany dokument XML zawierający twierdzenia dotyczące tożsamości użytkownika, wydawany przez macierzysty IdP po lokalnym uwierzytelnieniu użytkownika. Strona ufająca waliduje podpis twierdzenia względem certyfikatu podpisywania IdP, sprawdza ograniczenie odbiorców (potwierdzając, że twierdzenie zostało wydane dla tego konkretnego RP) i weryfikuje sygnaturę czasową twierdzenia, aby zapobiec atakom powtórzeniowym. Ponieważ twierdzenie jest podpisywane przy wydaniu, RP nie potrzebuje bezpośredniego połączenia z IdP w czasie walidacji, co jest cenne w okazjonalnie rozłączonych środowiskach koalicyjnych.

OAuth 2.0 i OpenID Connect (OIDC) są coraz częściej obecne w architekturach koalicyjnych, ponieważ nowsze systemy przyjmują interfejsy API natywne dla REST zamiast wzorców zorientowanych na SOAP, dla których SAML był projektowany. OIDC rozszerza OAuth 2.0 o ustandaryzowany token ID (JSON Web Token) przenoszący twierdzenia tożsamości, podczas gdy tokeny dostępowe OAuth 2.0 służą do autoryzacji wywołań API w imieniu uwierzytelnionego użytkownika. Krótszy format tokenu i przepływy natywne dla HTTP sprawiają, że OIDC jest preferowany dla aplikacji mobilnych i webowych. W zastosowaniach koalicyjnych OIDC wymaga, aby serwer autoryzacji w macierzystym kraju był dostępny z sieci partnera w momencie wydania tokenu, co nakłada zależność od łączności, której unika model asynchronicznych twierdzeń SAML. Wiele wdrożeń koalicyjnych stosuje zatem SAML do uwierzytelniania głównego i lokalnie wydaje krótkotrwałe tokeny OIDC na granicy partnera, skutecznie przekształcając przychodzące twierdzenie SAML w sesję OIDC ograniczoną do ekosystemu aplikacji partnera.

Oba protokoły wymagają starannego zabezpieczenia dla środowisk obronnych. Szyfrowanie twierdzeń (nie tylko podpisywanie) jest obowiązkowe, gdy twierdzenia przechodzą przez granice sieciowe, ponieważ podpisane, lecz niezaszyfrowane twierdzenie SAML ujawnia poziom uprawnień użytkownika, narodowość i przypisania ról każdemu obserwatorowi sieci. TLS 1.3 z uwierzytelnianiem wzajemnym (mTLS) powinien chronić wszystkie punkty końcowe federacji. Synchronizacja zegarów we wszystkich infrastrukturach IdP i RP jest cichą zależnością: okna walidacji znacznika czasu SAML są zazwyczaj ustawione na pięć minut, a dryft zegara przekraczający to okno powoduje, że prawidłowe twierdzenia nie przechodzą walidacji, blokując dostęp dla dotkniętych użytkowników bez żadnego oczywistego błędu poza limitem czasu uwierzytelniania.

Wzajemna certyfikacja PKI: łączenie krajowych urzędów certyfikacji

Twierdzenia federacji tożsamości są tylko tak wiarygodne, jak klucze podpisywania za nimi stojące. Każdy IdP SAML podpisuje twierdzenia certyfikatem wydanym w hierarchii urzędu certyfikacji. Aby RP kraju partnerskiego mógł ufać przychodzącemu twierdzeniu, musi ufać CA, który wydał certyfikat podpisywania. W jednoimplementacyjnym wdrożeniu krajowym jest to proste: jeden CA wydaje certyfikaty wszystkim stronom ufającym i dostawcom tożsamości. W koalicji każdy kraj obsługuje własną hierarchię CA, wydając certyfikaty w ramach krajowych ram polityki, których systemy innych krajów domyślnie nie uznają.

Wzajemna certyfikacja rozwiązuje to poprzez tworzenie explicite powiązań zaufania między krajowymi hierarchiami CA. W najprostszej formie dwustronnej CA Kraju A wydaje wzajemny certyfikat dla CA Kraju B (i odwrotnie). Strona ufająca w Kraju A, która ufa własnej hierarchii CA, przejściowo ufa certyfikatom wydanym w hierarchii CA Kraju B. Wzajemny certyfikat określa głębokość ścieżki zaufania i może zawierać ograniczenia polityki limitujące, które zastosowania certyfikatów są zaufane (np. ufanie certyfikatom Kraju B tylko do weryfikacji podpisu cyfrowego, nie do szyfrowania kluczy). W NATO Infrastruktura Klucza Publicznego NATO obsługuje mostkowy CA, który wzajemnie certyfikuje CA krajów uczestniczących, umożliwiając pojedynczej relacji mostkowej propagację zaufania we wszystkich połączonych krajowych hierarchiach zamiast wymagania od każdej pary krajów ustanowienia bezpośredniej dwustronnej wzajemnej certyfikacji.

Identyfikatory polityki certyfikatów (OID w rozszerzeniach certyfikatu) to mechanizm, za pomocą którego strony ufające stosują decyzje zaufania specyficzne dla danego kraju. RP koalicji może być skonfigurowana tak, aby akceptowała certyfikaty ze wszystkich wzajemnie certyfikowanych krajowych CA do celów uwierzytelniania ogólnego, ale wymagała konkretnego OID polityki (wskazującego na poświadczenie oparte na tokenie sprzętowym lub określony poziom zapewnienia) przed zezwoleniem na dostęp do zasobów z klauzulą releasability. Ten dwupoziomowy model polityki — szerokie zaufanie uwierzytelniające, wąskie zaufanie autoryzacyjne — pozwala uniknąć operacyjnego problemu zmieniania umowy wzajemnej certyfikacji za każdym razem, gdy nowa kategoria zasobów wymaga wyższego zapewnienia, ponieważ szczegółowe reguły żyją w lokalnej polityce RP, a nie w infrastrukturze CA.

Mapowanie ról w heterogenicznych katalogach koalicyjnych

Nawet gdy uwierzytelnianie powiedzie się przez granicę federacji, decyzja autoryzacyjna w systemie partnera wymaga przetłumaczenia przychodzących twierdzeń tożsamości na coś, co lokalny system kontroli dostępu rozumie. Stopień oficera francuskiego — Lieutenant-Colonel — wyrażony w formacie atrybutu LDAP armii francuskiej jest bezznaczeniowy dla brytyjskiego systemu C2, którego listy kontroli dostępu są zbudowane wokół brytyjskich klas rang i kodów ról. Mapowanie ról to proces ustalania równoważności między schematami atrybutów różnych katalogów krajowych, aby przychodzące twierdzenia mogły zostać przekształcone w lokalnie wykonalne decyzje dostępowe.

Warstwa przekształceń jest zazwyczaj implementowana jako zestaw reguł przekształcania twierdzeń w RP lub brokerze tożsamości partnera. Reguły przyjmują formę warunkowych mapowań: jeśli przychodzące twierdzenie zawiera atrybut narodowości "FRA" i kod stopnia w zakresie odpowiadającym OF-4 do OF-5 w skali rang STANAG NATO, mapuj użytkownika do lokalnej grupy "coalition-senior-officer". Skala rang STANAG jest lingua franca, która to umożliwia: dostarcza wspólny identyfikator numeryczny dla każdego stopnia we wszystkich krajach sojuszniczych, umożliwiając pisanie reguł mapowania ról w odniesieniu do neutralnego kodu STANAG, a nie natywnej etykiety stopnia każdego kraju. Kraje, które kontrybuują personel do koalicji, są odpowiedzialne za włączenie odpowiednika stopnia STANAG do twierdzeń SAML — wymóg, który powinien być weryfikowany podczas testów federacji.

Przypisania ról organizacyjnych stanowią bardziej złożone wyzwanie mapowania, ponieważ żaden standard NATO nie zapewnia odpowiednika kodów rang STANAG dla ról funkcjonalnych. Użytkownik przypisany do roli "analityk wywiadu" w katalogu Kraju A może wymagać mapowania na różne role lokalne w zależności od tego, do którego systemu partnera uzyskuje dostęp i co aktualne koalicyjne zasady zaangażowania określają dla poziomu dostępu tej roli. Wymaga to utrzymywania reguł mapowania ról jako dokumentu roboczego, aktualizowanego w ramach koalicyjnego procesu koordynacji zarządzania tożsamością w miarę federzowania nowych systemów i zmieniania się wymagań operacyjnych. Koalicyjne wyzwania związane z udostępnianiem danych wynikające z niekompatybilnych modeli danych są najbardziej dotkliwe właśnie na tej granicy przekształcania atrybutów.

Kontrola dostępu oparta na atrybutach do egzekwowania releasability

Kontrola dostępu oparta na rolach (RBAC) przypisuje uprawnienia do ról, a role do użytkowników. W przypadku systemów koalicyjnych model ten jest niewystarczający, ponieważ decyzje dostępowe zależą od wymiarów, których same role nie mogą uchwycić. Dokument oznaczony REL TO USA, GBR, CAN, AUS, NZL (do udostępnienia krajom Five Eyes) musi być dostępny dla kanadyjskiego oficera na poziomie SECRET, ale nie dla francuskiego oficera na równoważnym poziomie, niezależnie od tego, czy obaj pełnią identyczne role funkcjonalne. Releasability jest właściwością zasobu, nie roli użytkownika, a jej prawidłowe egzekwowanie wymaga jednoczesnej oceny narodowości użytkownika, uprawnień, need-to-know i etykiety klasyfikacyjnej zasobu.

Kontrola dostępu oparta na atrybutach (ABAC) naturalnie to obsługuje. Polityka ABAC to logiczna reguła oceniająca atrybuty podmiotu (narodowość, uprawnienia, rola, przydział), atrybuty zasobu (poziom klasyfikacji, klauzule releasability, instrukcje obsługi) i atrybuty środowiskowe (poziom klasyfikacji sieci, czas dostępu) w odniesieniu do explicite sformułowanego oświadczenia polityki. Polityka dla powyższego dokumentu mogłaby brzmieć: zezwól na dostęp, jeśli subject.nationality in [USA, GBR, CAN, AUS, NZL] I subject.clearance >= SECRET I resource.classification <= SECRET I resource.releasability contains subject.nationality. Reguła ta jest autoryzowalna, audytowalna i niezależna od taksonomii ról jakiegokolwiek konkretnego kraju. Silnik polityki ocenia ją podczas dostępu w odniesieniu do twierdzeń wyodrębnionych z twierdzenia SAML i metadanych zasobu.

eXtensible Access Control Markup Language (XACML) to najbardziej dojrzały standard do wyrażania i oceniania polityk ABAC w środowiskach obronnych. Punkt decyzji polityki (PDP) XACML otrzymuje żądanie autoryzacji zawierające atrybuty podmiotu, zasobu i środowiska, ocenia je w odniesieniu do załadowanego zestawu polityk i zwraca decyzję zezwolenia lub odmowy. Punkt egzekwowania polityki (PEP) w aplikacji przechwytuje każdy dostęp do zasobów, konstruuje żądanie autoryzacji, wywołuje PDP i egzekwuje decyzję. Oddzielenie PEP od PDP pozwala na aktualizowanie, wersjonowanie i audytowanie polityki niezależnie od kodu aplikacji — kluczowa właściwość, gdy zasady releasability zmieniają się wraz z ewolucją sytuacji operacyjnej.

Konfiguracja strony ufającej i zarządzanie metadanymi na dużą skalę

Koalicja dwunastu krajów, z których każdy obsługuje od dziesięciu do trzydziestu sfederowanych aplikacji, generuje problem zarządzania metadanymi o nietrywialnej skali operacyjnej. Każda strona ufająca musi posiadać aktualne, ważne metadane dla każdego IdP, od którego akceptuje twierdzenia. Każdy IdP musi mieć zarejestrowaną każdą RP, dla której może wydawać twierdzenia. Gdy kraj rotuje swój certyfikat podpisywania IdP (co powinno mieć miejsce co najmniej raz do roku i zawsze, gdy podejrzewa się kompromitację), każda RP akceptująca twierdzenia tego kraju musi zostać zaktualizowana o nowy certyfikat przed wygaśnięciem starego. Ręczne wykonywanie tej czynności dla setek dwustronnych rejestracji jest operacyjnie nieutrzymywalne i powoduje przerwy w dostępie, gdy aktualizacje opóźniają rotację certyfikatów.

Rozwiązaniem jest rejestr metadanych federacji: centralnie publikowany, podpisany dokument XML zawierający metadane wszystkich zarejestrowanych IdP i RP w federacji koalicyjnej. Każdy uczestnik pobiera rejestr zgodnie z ustalonym harmonogramem (zazwyczaj co 4-24 godziny), wyodrębnia wpisy istotne dla swojej konfiguracji zaufania i aktualizuje lokalną platformę tożsamości. Sam rejestr jest podpisany przez klucz organu rejestru koalicji, a każdy uczestnik waliduje ten podpis przed zastosowaniem jakichkolwiek aktualizacji — zapobiegając wstrzyknięciu fałszywych metadanych przez skompromitowany węzeł sieci pośredniej w celu przekierowania przepływów uwierzytelniania. Rejestry metadanych SAML zgodne ze specyfikacją SAML V2.0 Metadata Extensions for Registration and Publication zapewniają techniczne ramy do tego celu; program Federated Mission Networking NATO udokumentował otaczające je procesy operacyjne.

Konsumenci metadanych powinni być skonfigurowane do działania w trybie fail-closed przy niepowodzeniu pobierania metadanych: jeśli rejestr jest nieosiągalny, a kopia w pamięci podręcznej wygasła, system powinien odmówić prób uwierzytelnienia od dotkniętych IdP, zamiast nadal polegać na potencjalnie nieaktualnych certyfikatach. Kompromis operacyjny między dostępnością a bezpieczeństwem powinien być tutaj explicite sformułowany i skodyfikowany w umowie federacji — definiując, jak długo buforowane metadane mogą być używane przed uznaniem ich za wygasłe i jakie jest zachowanie awaryjne, gdy rejestr jest nieosiągalny podczas operacji bojowych, gdzie łączność sieciowa może być przerywana.

Reagowanie na incydenty: szybkie unieważnianie dostępu w sfederowanej koalicji

Problem unieważnienia w sfederowanej koalicji jest trudniejszy niż w jednoimplementacyjnym PKI, ponieważ działanie unieważnienia musi propagować się przez granice suwerenne do systemów, których kraj inicjujący nie kontroluje. Gdy poświadczenia użytkownika koalicji zostaną skompromitowane — przez kradzież, przymus lub incydent bezpieczeństwa w macierzystym kraju — każda strona ufająca we wszystkich krajach partnerskich, która mogła zaakceptować twierdzenia od tego użytkownika, musi zostać poinformowana i musi egzekwować unieważnienie. Czas między ogłoszeniem incydentu a powszechnym egzekwowaniem unieważnienia to okno ekspozycji, w którym skompromitowane poświadczenie pozostaje użyteczne.

Krótkie czasy życia twierdzeń są najskuteczniejszą kontrolą pierwszego rzędu. Twierdzenie SAML z 30-minutowym oknem ważności wygasa, zanim skompromitowane poświadczenie może być szeroko wykorzystane w większości scenariuszy, bez konieczności dotarcia jakiegokolwiek pozapasmowego powiadomienia o unieważnieniu do strony ufającej. Kosztem jest to, że użytkownik musi ponownie uwierzytelniać się co 30 minut, co jest do zarządzenia przy bezproblemowym ponownym uwierzytelnieniu SSO (gdzie IdP cicho wydaje nowe twierdzenie bez monitowania użytkownika), ale staje się operacyjnie zakłócające, jeśli IdP jest nieosiągalny podczas okna ponownego uwierzytelniania. Ustawienie czasu życia twierdzenia wymaga wyważenia tego kompromisu w odniesieniu do oczekiwanego profilu łączności sieci koalicyjnej.

Do unieważniania certyfikatów PKI dostępne są dwa mechanizmy: listy unieważnionych certyfikatów (CRL) i protokół Online Certificate Status Protocol (OCSP). Unieważnienie oparte na CRL publikuje podpisaną listę unieważnionych numerów seryjnych certyfikatów, które strony ufające pobierają okresowo; opóźnienie unieważnienia jest ograniczone przez interwał odświeżania CRL, zazwyczaj 24 godziny w krajowej praktyce PKI, ale konfigurowalne do 1-4 godzin dla pilnych scenariuszy koalicyjnych. OCSP zapewnia status unieważnienia w czasie rzeczywistym, ale wymaga, aby serwer odpowiedzi OCSP był dostępny w czasie uwierzytelniania — ten sam problem zależności od łączności co OIDC. Podejście warstwowe jest właściwe: krótkotrwałe twierdzenia SAML jako podstawowa kontrola, częste pobieranie CRL jako siatka bezpieczeństwa na poziomie certyfikatu i spinanie OCSP na warstwie TLS dla aplikacji, gdzie wymagany jest status certyfikatu w czasie rzeczywistym. Pozapasmowe procedury powiadamiania — udokumentowane listy kontaktów, predefiniowane formaty wiadomości i przetestowane ścieżki eskalacji w całej koalicji — uzupełniają zdolność reagowania na incydenty, której żaden protokół techniczny nie może w pełni zautomatyzować.