Managementul identității în coaliție: autentificare federată în rețelele NATO și ale partenerilor

Când un ofițer de legătură francez se conectează la un sistem de comandă comun al coaliției, nicio organizație unică nu îi deține identitatea. Credențialele sale au fost emise de Direction Interarmées des Réseaux d'Infrastructure et des Systèmes d'Information (DIRISI), autorizarea sa de securitate a fost adjudecată conform politicii naționale de securitate franceze, iar rolurile sale au fost atribuite de lanțul de comandă din Paris. Aplicația de coaliție la care se conectează rulează pe infrastructura gestionată de o națiune parteneră și nu are încredere în niciunul dintre cele de mai sus în mod implicit. Conectarea fiabilă, sigură și fără a necesita provizionarea manuală a mii de conturi temporare de coaliție este problema pe care o rezolvă managementul identității în coaliție. Acest articol examinează protocoalele, structurile PKI, schemele de atribute și mecanismele de politică ce fac posibilă interoperabilitatea în coaliție la nivelul identității.

Problema identității în operațiunile de coaliție

Operațiunile de coaliție reunesc personal din mai multe națiuni suverane în intervale de timp măsurate în zile. O grupă de lucru mixtă permanentă poate include contributori din o duzină de națiuni, fiecare funcționând sub propriul regim de guvernanță a identității, utilizând propria infrastructură de directoare și emițând credențiale sub propria ierarhie PKI națională. Înainte de existența soluțiilor de identitate federată, abordarea standard era provizionarea manuală: personalul de legătură de la granița sistemelor fiecărei națiuni crea conturi locale pentru utilizatorii de coaliție sosiți, atribuia permisiuni manual și dezactiva acele conturi când utilizatorul rotea afară. Acest proces era lent, predispus la erori, documentat inconsecvent și crea conturi orfane persistente care rămâneau active mult după ce personalul pe care îl reprezentau părăsise coaliția.

Cerința fundamentală este că autentificarea și autorizarea trebuie să rămână sub control suveran, permițând în același timp accesul peste granițele naționale. Nicio națiune nu acceptă o autoritate centralizată de identitate a coaliției care ar putea fi capturată, compromisă sau exploatată politic de un alt membru. Arhitectura nu se poate baza, prin urmare, pe un singur depozit de identitate în care toate națiunile să se federeze. În schimb, trebuie să trateze furnizorul de identitate al fiecărei națiuni ca pe un egal, stabilind relații de încredere bilaterale sau multilaterale între ele fără a ceda controlul național asupra credențialelor însele. Aceasta este constrângerea definitorie care face managementul identității în coaliție arhitectural distinct de single sign-on la nivel de întreprindere.

Consecința practică este că fiecare tranzacție de identitate peste o graniță de coaliție implică cel puțin trei părți: furnizorul de identitate al utilizatorului, relying party-ul deținător de resurse la națiunea parteneră și cadrul de încredere sub care ambele părți au convenit să funcționeze. Așa cum este descris în ghidul de implementare a Federated Mission Networking, acest cadru de încredere este documentat în acorduri de federare care specifică ce atribute vor fi schimbate, ce formate de afirmații sunt așteptate și cum se vor lua deciziile de acces la graniță.

Protocoale de federare: SAML 2.0, OAuth 2.0 și OIDC pentru medii de apărare

Security Assertion Markup Language 2.0 (SAML 2.0) rămâne protocolul dominant pentru federarea identității în mediile de apărare și guvernamentale. Maturitatea sa, implementarea largă pe platformele de identitate pentru întreprinderi (Microsoft ADFS, Shibboleth, Ping Identity) și modelul de afirmații bazat pe semnătura XML se aliniază bine cu infrastructura PKI existentă. O afirmație SAML este un document XML semnat ce conține afirmațiile de identitate ale utilizatorului și este emis de IdP-ul de domiciliu după ce utilizatorul se autentifică local. Relying party-ul validează semnătura afirmației față de certificatul de semnare al IdP-ului, verifică restricția de audiență (confirmând că afirmația a fost emisă pentru acest RP specific) și verifică marca de timp a afirmației pentru a preveni atacurile de reluare. Deoarece afirmația este semnată la emitere, RP-ul nu necesită o conexiune directă la IdP la momentul validării, ceea ce este valoros în mediile de coaliție cu conexiune ocazională.

OAuth 2.0 și OpenID Connect (OIDC) sunt din ce în ce mai prezente în arhitecturile de coaliție pe măsură ce sistemele mai noi adoptă API-uri native REST în loc de modelele orientate SOAP pentru care a fost proiectat SAML. OIDC extinde OAuth 2.0 cu un token ID standardizat (un JSON Web Token) ce conține afirmații de identitate, în timp ce token-urile de acces OAuth 2.0 sunt utilizate pentru a autoriza apelurile API în numele utilizatorului autentificat. Formatul mai scurt al token-ului și fluxurile native HTTP fac OIDC preferabil pentru aplicațiile mobile și web. Pentru utilizarea în coaliție, OIDC necesită ca serverul de autorizare al națiunii de domiciliu să fie accesibil din rețeaua partenerului la momentul emiterii token-ului, ceea ce impune o dependență de conectivitate pe care modelul de afirmații offline al SAML o evită. Multe implementări de coaliție rulează astfel SAML pentru autentificarea primară și emit token-uri OIDC de scurtă durată local la granița partenerului, traducând efectiv o afirmație SAML primită într-o sesiune OIDC limitată la ecosistemul de aplicații al partenerului.

Ambele protocoale necesită o întărire atentă pentru mediile de apărare. Criptarea afirmațiilor (nu doar semnarea) este obligatorie când afirmațiile traversează granițele de rețea, deoarece o afirmație SAML semnată dar necriptată expune nivelul de autorizare, naționalitatea și atribuirile de roluri ale utilizatorului oricărui observator de rețea. TLS 1.3 cu autentificare mutuală trebuie să protejeze toate endpoint-urile de federare. Sincronizarea ceasului pe toată infrastructura IdP și RP este o dependență silențioasă: ferestrele de validare a marcajului de timp SAML sunt setate de obicei la cinci minute, iar o deviere a ceasului care depășește această fereastră face ca afirmațiile valide să eșueze, întrerupând accesul utilizatorilor afectați fără nicio eroare evidentă alta decât o expirare a autentificării.

Certificarea încrucișată PKI: conectarea autorităților de certificare naționale

Afirmațiile de federare a identității sunt la fel de demne de încredere ca cheile de semnare din spatele lor. Fiecare IdP SAML semnează afirmațiile sale cu un certificat emis sub o ierarhie de autorități de certificare. Pentru ca RP-ul unei națiuni partenere să aibă încredere în o afirmație primită, trebuie să aibă încredere în CA care a emis certificatul de semnare. Într-o implementare cu o singură organizație internă, aceasta este simplă: un singur CA emite certificate tuturor relying party-urilor și furnizorilor de identitate. Într-o coaliție, fiecare națiune operează propria ierarhie CA, emițând certificate sub cadre de politici naționale pe care sistemele altor națiuni nu le recunosc în mod implicit.

Certificarea încrucișată rezolvă acest lucru prin crearea de legături explicite de încredere între ierarhiile CA naționale. În forma bilaterală cea mai simplă, CA-ul Națiunii A emite un certificat încrucișat pentru CA-ul Națiunii B (și viceversa). Un relying party din Națiunea A care are încredere în propria ierarhie CA are, prin tranzitivitate, încredere în certificatele emise sub CA-ul Națiunii B. Certificatul încrucișat specifică adâncimea căii de încredere și poate include constrângeri de politică care limitează utilizările de certificate de care se face încredere. În NATO, Infrastructura de Cheie Publică NATO operează un CA pod care certifică încrucișat CA-urile națiunilor participante, permițând ca o singură relație de pod să propage încrederea în toate ierarhiile naționale conectate, în loc să necesite fiecare pereche de națiuni să stabilească o certificare încrucișată bilaterală directă.

Identificatorii de politică de certificat (OID în extensiile certificatului) sunt mecanismul prin care relying party-urile aplică decizii de încredere specifice fiecărei națiuni. Un RP de coaliție poate fi configurat să accepte certificate de la toate CA-urile naționale cu certificare încrucișată pentru scopuri generale de autentificare, dar să necesite un OID de politică specific (indicând o credențială bazată pe token hardware sau un nivel specific de asigurare) înainte de a permite accesul la resurse clasificate releasable. Acest model de politică pe două niveluri — încredere largă de autentificare, încredere de autorizare restrânsă — evită problema operațională de a modifica acordul de certificare încrucișată de fiecare dată când o nouă categorie de resurse necesită o asigurare mai mare, deoarece regulile granulare se află în politica locală a RP-ului mai degrabă decât în infrastructura CA.

Maparea rolurilor în directoare de coaliție eterogene

Chiar și atunci când autentificarea reușește peste o graniță de federare, decizia de autorizare la sistemul partenerului necesită traducerea afirmațiilor de identitate primite în ceva ce înțelege sistemul local de control al accesului. Gradul unui ofițer francez de Locotenent-Colonel, afirmat în formatul atributului LDAP militar francez, nu are sens pentru un sistem C2 britanic ale cărui liste de control al accesului sunt construite în jurul gradelor și codurilor de rol britanice. Maparea rolurilor este procesul de stabilire a echivalențelor între schemele de atribute ale diferitelor directoare naționale, astfel încât afirmațiile primite să poată fi convertite în decizii de acces acționabile local.

Stratul de traducere este de obicei implementat ca un set de reguli de transformare a afirmațiilor în RP-ul sau brokerul de identitate al partenerului. Regulile iau forma de mapări condiționale: dacă afirmația primită conține un atribut de naționalitate „FRA" și un cod de grad în intervalul corespunzător OF-4 la OF-5 în scala de grade STANAG NATO, mapați utilizatorul la grupul local „coalition-senior-officer". Scala de grade STANAG este lingua franca care face acest lucru posibil: furnizează un identificator numeric comun pentru fiecare grad în toate națiunile aliate, permițând ca regulile de mapare a rolurilor să fie scrise față de codul STANAG neutru mai degrabă decât față de eticheta de grad nativă a fiecărei națiuni. Națiunile care contribuie cu personal la o coaliție sunt responsabile de includerea echivalentului de grad STANAG în afirmațiile lor SAML, o cerință care trebuie verificată în timpul testării federației.

Atribuirile de roluri organizaționale prezintă o provocare de mapare mai complexă deoarece niciun standard NATO nu furnizează echivalentul codurilor de grad STANAG pentru rolurile funcționale. Un utilizator căruia i s-a atribuit rolul „analist de informații" în directorul Națiunii A poate trebui mapat la roluri locale diferite în funcție de care dintre sistemele partenerului accesează și ce specifică regulile de angajament actuale ale coaliției pentru nivelul de acces al acelui rol. Aceasta necesită ca regulile de mapare a rolurilor să fie menținute ca document viu, actualizat prin procesul de coordonare a managementului identității al coaliției pe măsură ce sunt federate noi sisteme și pe măsură ce cerințele operaționale se schimbă. Provocările de partajare a datelor în coaliție ce apar din modele de date incompatibile sunt cel mai acute tocmai la această graniță de traducere a atributelor.

Controlul de acces bazat pe atribute pentru aplicarea releasability

Controlul de acces bazat pe roluri (RBAC) atribuie permisiuni rolurilor și roluri utilizatorilor. Pentru sistemele de coaliție, acest model este insuficient deoarece deciziile de acces depind de dimensiuni pe care rolurile singure nu le pot capta. Un document marcat REL TO USA, GBR, CAN, AUS, NZL (releasable către națiunile Five Eyes) trebuie să fie accesibil unui ofițer canadian la nivelul SECRET, dar nu unui ofițer francez la nivelul echivalent, indiferent dacă ambii dețin roluri funcționale identice. Releasability este o proprietate a resursei, nu a rolului utilizatorului, și aplicarea sa corectă necesită evaluarea simultană a naționalității utilizatorului, a autorizării, a atribuirii need-to-know și a etichetei de clasificare a resursei.

Controlul de acces bazat pe atribute (ABAC) gestionează acest lucru în mod natural. O politică ABAC este o regulă logică ce evaluează atributele subiectului (naționalitate, autorizare, rol, atribuire), atributele resursei (nivel de clasificare, caveats de releasability, instrucțiuni de gestionare) și atributele de mediu (nivelul de clasificare al rețelei, ora accesului) față de o declarație de politică explicită. O politică pentru documentul de mai sus ar putea fi: permite accesul dacă subject.nationality in [USA, GBR, CAN, AUS, NZL] ȘI subject.clearance >= SECRET ȘI resource.classification <= SECRET ȘI resource.releasability conține subject.nationality. Această regulă este redactabilă, auditabilă și independentă de taxonomia de roluri a oricărei națiuni specifice. Motorul de politică o evaluează la momentul accesului față de afirmațiile extrase din afirmația SAML și metadatele resursei.

eXtensible Access Control Markup Language (XACML) este cel mai matur standard pentru exprimarea și evaluarea politicilor ABAC în mediile de apărare. Un Punct de Decizie a Politicii (PDP) XACML primește o cerere de autorizare care conține atributele subiectului, resursei și mediului, o evaluează față de setul de politici încărcat și returnează o decizie de permis sau refuz. Punctul de Aplicare a Politicii (PEP) din aplicație interceptează fiecare acces la resurse, construiește cererea de autorizare, apelează PDP-ul și aplică decizia. Separarea PEP-ului de PDP permite actualizarea, versionarea și auditarea politicii independent de codul aplicației — o proprietate critică când regulile de releasability se schimbă pe măsură ce situația operațională evoluează.

Configurarea relying party și gestionarea metadatelor la scară

O coaliție de douăsprezece națiuni, fiecare operând zece până la treizeci de aplicații federate, produce o problemă de management al metadatelor cu o suprafață operațională semnificativă. Fiecare relying party trebuie să dețină metadate curente, valide pentru fiecare IdP de la care acceptă afirmații. Fiecare IdP trebuie să fi înregistrat fiecare RP pentru care poate emite afirmații. Când o națiune rotește certificatul de semnare al IdP-ului (ceea ce ar trebui să se întâmple cel puțin anual și ori de câte ori se suspectează o compromitere), fiecare RP care acceptă afirmațiile acelei națiuni trebuie actualizat cu noul certificat înainte ca cel vechi să expire. Efectuarea acestui lucru manual pe sute de înregistrări bilaterale este nesustenabilă operațional și produce întreruperi de acces când actualizările întârzie rotațiile de certificate.

Soluția este un registru de metadate de federare: un document XML semnat, publicat central, care listează metadatele pentru toți IdP-urile și RP-urile înregistrate în federația de coaliție. Fiecare participant preia registrul conform unui program definit (de obicei la fiecare 4-24 de ore), extrage intrările relevante pentru configurația sa de încredere și actualizează platforma de identitate locală. Registrul însuși este semnat de o cheie a autorității de registru a coaliției, iar fiecare participant validează acea semnătură înainte de a aplica orice actualizări — prevenind ca un nod intermediar de rețea compromis să injecteze metadate false pentru a redirecționa fluxurile de autentificare. Registrele de metadate SAML urmând specificația SAML V2.0 Metadata Extensions for Registration and Publication furnizează cadrul tehnic; programul Federated Mission Networking NATO a documentat procesele operaționale din jurul acestuia.

Consumatorii de metadate trebuie configurați să eșueze în mod închis la eșecul preluării metadatelor: dacă registrul este inaccesibil și o copie în cache a expirat, sistemul trebuie să refuze tentativele de autentificare de la IdP-urile afectate mai degrabă decât să continue să se bazeze pe certificate potențial învechite. Compromisul operațional între disponibilitate și securitate este explicit și trebuie codificat în acordul de federare — definind cât timp pot fi folosite metadatele în cache înainte de a fi considerate expirate și care este comportamentul de rezervă când registrul este inaccesibil în timpul operațiunilor de luptă unde conectivitatea rețelei poate fi intermitentă.

Răspuns la incidente: revocarea rapidă a accesului într-o coaliție federată

Problema revocării într-o coaliție federată este mai dificilă decât într-un PKI cu o singură organizație, deoarece acțiunea de revocare trebuie să se propage peste granițele suverane către sisteme pe care națiunea inițiatoare nu le controlează. Când credențialele unui utilizator de coaliție sunt compromise — prin furt, constrângere sau un incident de securitate la națiunea de domiciliu — fiecare relying party din toate națiunile partenere care ar fi putut accepta afirmații de la acel utilizator trebuie informat și trebuie să aplice revocarea. Timpul dintre declararea incidentului și aplicarea universală a revocării este fereastra de expunere în care credențiala compromisă rămâne utilizabilă.

Duratele scurte de viață ale afirmațiilor sunt cel mai eficient control de prim ordin. O afirmație SAML cu o fereastră de valabilitate de 30 de minute expiră înainte ca o credențială compromisă să poată fi exploatată extensiv în majoritatea scenariilor, fără a necesita ca nicio notificare de revocare out-of-band să ajungă la relying party. Costul este că utilizatorul trebuie să se re-autentifice la fiecare 30 de minute, ceea ce este gestionabil cu re-autentificarea SSO fără întreruperi (unde IdP-ul emite silențios o nouă afirmație fără a solicita utilizatorului) dar devine perturbator operațional dacă IdP-ul este inaccesibil în fereastra de re-autentificare. Setarea duratei de viață a afirmației necesită echilibrarea acestui compromis față de profilul de conectivitate așteptat al rețelei de coaliție.

Pentru revocarea certificatelor PKI, Listele de Revocare a Certificatelor (CRL) și Protocolul Online de Stare a Certificatelor (OCSP) sunt cele două mecanisme disponibile. Revocarea bazată pe CRL publică o listă semnată de numere de serie de certificate revocate pe care relying party-urile o preiau periodic; latența de revocare este limitată de intervalul de reîmprospătare a CRL, de obicei 24 de ore în practica PKI națională, dar configurabilă la 1-4 ore pentru scenarii de coaliție de urgență ridicată. OCSP furnizează starea de revocare în timp real, dar necesită ca responderul OCSP să fie accesibil la momentul autentificării — aceeași problemă de dependență de conectivitate ca și OIDC. O abordare pe straturi este adecvată: afirmații SAML de scurtă durată ca control primar, preluări frecvente de CRL ca plasă de siguranță la nivelul certificatelor și OCSP stapling la nivelul TLS pentru aplicațiile unde starea certificatelor în timp real este necesară. Procedurile de notificare out-of-band — liste de contacte documentate, formate de mesaje predefinite și căi de escaladare testate în cadrul coaliției — completează capacitatea de răspuns la incidente pe care niciun protocol tehnic nu o poate automatiza complet.