Coalitiebeheer van identiteiten: gefedereerde authenticatie over NAVO- en partnernetwerken

Wanneer een Franse verbindingsofficier verbinding maakt met een gedeeld coalitie-commandosysteem, is er geen enkele organisatie die haar identiteit beheert. Haar credentials zijn uitgegeven door de Direction Interarmees des Reseaux d'Infrastructure et des Systemes d'Information (DIRISI), haar beveiligingsclassificatie is vastgesteld onder het Franse nationale veiligheidsbeleid en haar rollen zijn toegewezen door haar commandolijn in Parijs. De coalitieapplicatie waarmee zij verbinding maakt, draait op infrastructuur die wordt beheerd door een partnernatie en vertrouwt geen van het bovenstaande standaard. Dit gat betrouwbaar, veilig en zonder handmatig aanmaken van duizenden tijdelijke coalitieaccounts te overbruggen, is het probleem dat coalitiebeheer van identiteiten oplost. Dit artikel onderzoekt de protocollen, PKI-structuren, attributenschema's en beleidsmechanismen die coalitie-interoperabiliteit mogelijk maken op de identiteitslaag.

Het identiteitsprobleem bij coalitieoperaties

Coalitieoperaties brengen personeel van meerdere soevereine naties samen op tijdschalen van enkele dagen. Een permanente gezamenlijke taakgroep kan bijdragers bevatten van een tiental naties, elk opererend onder hun eigen identiteitsbeheersregime, met hun eigen directoryinfrastructuur en hun eigen nationale PKI-hiërarchie voor het uitgeven van credentials. Vóór gefedereerde identiteitsoplossingen bestonden, was de standaardaanpak handmatige provisioning: verbindingspersoneel bij de systeemgrens van elke natie maakte lokale accounts aan voor binnenkomende coalitiegebruikers, wees handmatig machtigingen toe en deactiveerde deze accounts wanneer de gebruiker werd afgelost. Dit proces was traag, foutgevoelig, inconsistent gedocumenteerd en creëerde persistente zwevende accounts die actief bleven lang nadat het personeel dat ze vertegenwoordigden de coalitie had verlaten.

De fundamentele vereiste is dat authenticatie en autorisatie onder soevereine controle blijven, terwijl toegang over nationale grenzen heen mogelijk wordt gemaakt. Geen enkele natie accepteert een gecentraliseerde coalitie-identiteitsautoriteit die kan worden overgenomen, gecompromitteerd of politiek ingezet door een ander lid. De architectuur kan daarom niet steunen op één gecentraliseerde identiteitsopslag waaraan alle naties federeren. In plaats daarvan moet elke nationale identiteitsprovider worden behandeld als een gelijkwaardige partij, waarbij bilaterale of multilaterale vertrouwensrelaties worden vastgelegd zonder de soevereine controle over de credentials zelf op te geven. Dit is de bepalende beperking die coalitiebeheer van identiteiten architecturaal onderscheidt van enterprise single sign-on.

De praktische consequentie is dat elke identiteitstransactie over een coalitiegrenzen ten minste drie partijen omvat: de identiteitsprovider van de thuisnatie van de gebruiker, de resource-beherende relying party bij de partnernatie en het vertrouwenskader dat beide partijen hebben afgesproken te hanteren. Zoals beschreven in de implementatiegids voor Federated Mission Networking, is dit vertrouwenskader vastgelegd in federatieakkoorden die specificeren welke attributen worden uitgewisseld, welke claim-formaten worden verwacht en hoe toegangsbeslissingen aan de grens worden genomen.

Federatieprotocollen: SAML 2.0, OAuth 2.0 en OIDC voor defensieomgevingen

Security Assertion Markup Language 2.0 (SAML 2.0) blijft het dominante protocol voor identiteitsfederatie in defensie- en overheidsomgevingen. De volwassenheid, brede implementatie op enterprise-identiteitsplatforms (Microsoft ADFS, Shibboleth, Ping Identity) en het op XML-handtekeningen gebaseerde assertiemodel sluiten goed aan bij bestaande PKI-infrastructuur. Een SAML-assertie is een ondertekend XML-document dat de identiteitsclaims van de gebruiker bevat en wordt uitgegeven door de thuis-IdP nadat de gebruiker lokaal heeft geauthenticeerd. De relying party valideert de handtekening van de assertie aan de hand van het ondertekeningscertificaat van de IdP, controleert de audience-restrictie (bevestigt dat de assertie is uitgegeven voor deze specifieke RP) en verifieert de assertietijdstempel om replay-aanvallen te voorkomen. Omdat de assertie bij uitgifte wordt ondertekend, heeft de RP geen directe verbinding met de IdP nodig tijdens validatie — wat waardevol is in intermittent verbonden coalitieomgevingen.

OAuth 2.0 en OpenID Connect (OIDC) zijn steeds meer aanwezig in coalitie-architecturen naarmate nieuwere systemen REST-native API's adopteren in plaats van de SOAP-georiënteerde patronen waarvoor SAML was ontworpen. OIDC breidt OAuth 2.0 uit met een gestandaardiseerd ID-token (een JSON Web Token) dat identiteitsclaims bevat, terwijl OAuth 2.0-toegangstokens worden gebruikt om API-aanroepen namens de geauthenticeerde gebruiker te autoriseren. Het kortere tokenformaat en de HTTP-native flows maken OIDC de voorkeur voor mobiele en webapplicaties. Voor coalitiegebruik vereist OIDC dat de autorisatieserver bij de thuisnatie bereikbaar is vanuit het netwerk van de partner bij het aanmaken van tokens — een connectiviteitsafhankelijkheid die het offline assertiemodel van SAML vermijdt. Veel coalitie-implementaties gebruiken daarom SAML voor primaire authenticatie en geven kortdurende OIDC-tokens lokaal uit aan de grens van de partner, waarbij een inkomende SAML-assertie effectief wordt vertaald naar een OIDC-sessie voor het applicatie-ecosysteem van de partner.

Beide protocollen vereisen zorgvuldige beveiliging voor defensieomgevingen. Assertieversleuteling (niet alleen ondertekening) is verplicht wanneer asserties over netwerkgrenzen gaan, omdat een ondertekende maar onversleutelde SAML-assertie het beveiligingsclassificatieniveau, nationaliteit en rolbezettingen van de gebruiker blootstelt aan elke netwerksniffer. TLS 1.3 met wederzijdse authenticatie moet alle federatie-eindpunten beschermen. Kloaksynchronisatie over alle IdP- en RP-infrastructuur is een stille afhankelijkheid: validatievensters voor SAML-tijdstempels zijn doorgaans ingesteld op vijf minuten, en een klokafwijking die dit venster overschrijdt, zorgt ervoor dat geldige asserties mislukken, wat toegang voor getroffen gebruikers verbreekt zonder enige duidelijke fout anders dan een authenticatietimeout.

PKI-kruiscertificering: nationale certificaatautoriteiten verbinden

Identiteitsfederatie-asserties zijn slechts zo betrouwbaar als de ondertekeningssleutels erachter. Elke SAML-IdP ondertekent zijn asserties met een certificaat dat is uitgegeven onder een certificaatautoriteitshiërarchie. Wil de RP van een partnernatie een inkomende assertie vertrouwen, dan moet zij de CA vertrouwen die het ondertekeningscertificaat heeft uitgegeven. In een binnenlandse enkelvoudige-organisatieimplementatie is dit eenvoudig: één CA geeft certificaten uit aan alle relying parties en identiteitsproviders. In een coalitie beheert elke natie zijn eigen CA-hiërarchie en geeft certificaten uit onder nationale beleidskaders die de systemen van andere naties standaard niet erkennen.

Kruiscertificering lost dit op door expliciete vertrouwensverbindingen te leggen tussen nationale CA-hiërarchieën. In zijn eenvoudigste bilaterale vorm geeft de CA van Natie A een kruiscertificaat uit voor de CA van Natie B (en omgekeerd). Een relying party in Natie A die haar eigen CA-hiërarchie vertrouwt, vertrouwt transitief certificaten die zijn uitgegeven onder de CA van Natie B. Het kruiscertificaat specificeert de diepte van het vertrouwenspad en kan beleidsbeperkingen bevatten die beperken welke certificaatgebruiken worden vertrouwd (bijv. certificaten van Natie B alleen vertrouwen voor verificatie van digitale handtekeningen, niet voor sleutelversleuteling). Binnen de NAVO wordt dit gecoördineerd via de NATO Public Key Infrastructure, die een bridge-CA beheert die de CA's van deelnemende naties kruiscertificeert, zodat één enkele bridgerelatie vertrouwen kan verspreiden over alle verbonden nationale hiërarchieën in plaats van dat elk landenpaar een directe bilaterale kruiscertificering moet opzetten.

Certificaatbeleidsidentificatoren (OID's in de certificaatextensies) zijn het mechanisme waarmee relying parties natiespecifieke vertrouwensbeslissingen toepassen. Een coalitie-RP kan worden geconfigureerd om certificaten van alle kruisgecertificeerde nationale CA's te accepteren voor algemene authenticatiedoeleinden, maar een specifieke beleids-OID vereisen (die een op hardware-token gebaseerde credential of een specifiek zekerheidssniveau aangeeft) voordat toegang tot geclassificeerde-vrijgave-resources wordt toegestaan. Dit tweelaagsbeleid — brede authenticatiebetrouwbaarheid, smalle autorisatiebetrouwbaarheid — vermijdt het operationele probleem dat het kruiscertificeringsovereenkomst moet worden gewijzigd elke keer dat een nieuwe resourcecategorie een hogere zekerheid vereist, omdat de fijnmazige regels in het lokale beleid van de RP staan en niet in de CA-infrastructuur.

Rolkoppeling over heterogene coalitie-directories

Zelfs wanneer authenticatie slaagt over een federatiegrens, vereist de autorisatiebeslissing bij het systeem van de partner het vertalen van de inkomende identiteitsclaims naar iets dat het lokale toegangscontrolesysteem begrijpt. De rang van Luitenant-Kolonel van een Franse officier, beweerd in het LDAP-attribuutformaat van het Franse leger, is betekenisloos voor een Brits C2-systeem waarvan de toegangscontrolelijsten zijn opgebouwd rond Britse ranggraden en rolcodes. Rolkoppeling is het proces van het vastleggen van equivalenties tussen de attributenschema's van verschillende nationale directories, zodat inkomende asserties kunnen worden omgezet in lokaal uitvoerbare toegangsbeslissingen.

De vertaallaag wordt doorgaans geïmplementeerd als een claimtransformatieregel in de RP of identiteitsmakelaar van de partner. Regels hebben de vorm van voorwaardelijke koppelingen: als de inkomende assertie een nationaliteitsattribuut van "FRA" bevat en een rangcode in het bereik van OF-4 tot OF-5 op de STANAG-rangschaal van de NAVO, koppel de gebruiker dan aan de lokale groep "coalition-senior-officer". De STANAG-rangschaal is de gemeenschappelijke taal die dit mogelijk maakt: het biedt een gemeenschappelijke numerieke identifier voor elke rang bij alle geallieerde naties, waardoor rolkoppelingsregels kunnen worden geschreven aan de hand van de neutrale STANAG-code in plaats van het eigen ranglabel van elke natie. Naties die personeel bijdragen aan een coalitie zijn verantwoordelijk voor het opnemen van het STANAG-rangequivalent in hun SAML-asserties — een vereiste die tijdens federatietests moet worden geverifieerd.

Organisatorische rolbezettingen vormen een complexere koppelingsuitdaging omdat geen enkele NAVO-standaard het equivalent biedt van STANAG-rangcodes voor functionele rollen. Een gebruiker die de rol "inlichtingenanalist" heeft toegewezen gekregen in de directory van Natie A, moet mogelijk worden gekoppeld aan verschillende lokale rollen afhankelijk van welke systemen van de partner ze raadplegen en wat de huidige coalitie-inzetregels specificeren voor het toegangsniveau van die rol. Dit vereist dat rolkoppelingsregels worden bijgehouden als een levend document, bijgewerkt via het identiteitsbeheercoördinatieproces van de coalitie naarmate nieuwe systemen worden gefedereerd en operationele vereisten veranderen. De uitdagingen bij het delen van coalitiegegevens die voortkomen uit incompatibele gegevensmodellen zijn het meest acuut precies aan deze grens van attribuutvertaling.

Attributen-gebaseerde toegangscontrole voor vrijgavehandhaving

Rolgebaseerde toegangscontrole (RBAC) kent machtigingen toe aan rollen en rollen aan gebruikers. Voor coalitiesystemen is dit model ontoereikend omdat toegangsbeslissingen afhankelijk zijn van dimensies die rollen alleen niet kunnen vastleggen. Een document gemarkeerd als REL TO USA, GBR, CAN, AUS, NZL (vrijgegeven aan de Five Eyes-naties) moet toegankelijk zijn voor een Canadese officier op SECRET-niveau maar niet voor een Franse officier op het equivalente niveau, ongeacht of beiden identieke functionele rollen bekleden. Vrijgave is een eigenschap van de resource, niet van de rol van de gebruiker, en correcte handhaving ervan vereist gelijktijdige evaluatie van de nationaliteit van de gebruiker, het beveiligingsclassificatieniveau, de need-to-know en het classificatielabel van de resource.

Attributen-gebaseerde toegangscontrole (ABAC) verwerkt dit op een natuurlijke wijze. Een ABAC-beleid is een logische regel die subjectattributen (nationaliteit, beveiligingsclassificatieniveau, rol, toewijzing), resourceattributen (classificatieniveau, vrijgavevoorbehouden, verwerkingsinstructies) en omgevingsattributen (classificatieniveau van het netwerk, tijdstip van toegang) evalueert aan de hand van een expliciete beleidsverklaring. Een beleid voor het bovenstaande document kan luiden: verleen toegang als subject.nationaliteit in [USA, GBR, CAN, AUS, NZL] EN subject.beveiligingsclassificatieniveau >= SECRET EN resource.classificatie <= SECRET EN resource.vrijgave bevat subject.nationaliteit. Deze regel is te schrijven, te controleren en onafhankelijk van de roltaxonomy van een specifieke natie. De beleidsengine evalueert het bij toegangstijd aan de hand van de claims die zijn geëxtraheerd uit de SAML-assertie en de metadata van de resource.

De eXtensible Access Control Markup Language (XACML) is de meest volwassen standaard voor het uitdrukken en evalueren van ABAC-beleid in defensieomgevingen. Een XACML Policy Decision Point (PDP) ontvangt een autorisatieverzoek met subject-, resource- en omgevingsattributen, evalueert het aan de hand van de geladen beleidsset en retourneert een verleen- of weigeringsbeslissing. Het Policy Enforcement Point (PEP) in de applicatie onderschept elke resource-toegang, stelt het autorisatieverzoek samen, roept het PDP aan en handhaaft de beslissing. Het scheiden van het PEP van het PDP maakt het mogelijk het beleid onafhankelijk van de applicatiecode bij te werken, te versiebeheren en te controleren — een kritieke eigenschap wanneer vrijgaveregels veranderen naarmate de operationele situatie evolueert.

Configuratie van relying parties en metadatabeheer op schaal

Een coalitie van twaalf naties, elk met tien tot dertig gefedereerde applicaties, produceert een metadatabeheervraagstuk met een niet-triviale operationele omvang. Elke relying party moet actuele, geldige metadata hebben voor elke IdP waarvan ze asserties accepteert. Elke IdP moet elke RP hebben geregistreerd waarvoor ze asserties kan uitgeven. Wanneer een natie haar IdP-ondertekeningscertificaat roteert (wat minimaal jaarlijks en bij vermoeden van compromittering zou moeten gebeuren), moet elke RP die asserties van die natie accepteert worden bijgewerkt met het nieuwe certificaat voordat het oude verloopt. Dit handmatig doen over honderden bilaterale registraties is operationeel onhoudbaar en produceert toegangsstoringen wanneer updates achter certificaatroulaties aan lopen.

De oplossing is een federatiemetadataregister: een centraal gepubliceerd, ondertekend XML-document dat de metadata van alle geregistreerde IdP's en RP's in de coalitie-federatie opsomt. Elke deelnemer haalt het register op volgens een vastgesteld schema (doorgaans elke 4-24 uur), extraheert de relevante vermeldingen voor zijn vertrouwensconfiguratie en werkt zijn lokaal identiteitsplatform bij. Het register zelf is ondertekend door een sleutel van de coalitie-registerautoriteit, en elke deelnemer valideert die handtekening voordat updates worden toegepast — om te voorkomen dat een gecompromitteerd tussenliggend netwerkknooppunt valse metadata kan injecteren om authenticatieflows om te leiden. SAML-metadataregisters die de SAML V2.0 Metadata Extensions for Registration and Publication-specificatie volgen, bieden het technische kader hiervoor; het Federated Mission Networking-programma van de NAVO heeft de operationele processen erromheen gedocumenteerd.

Metadataconsumenten moeten worden geconfigureerd om bij een ophaalfout te mislukken in gesloten staat: als het register onbereikbaar is en een gecachede kopie is verlopen, moet het systeem authenticatiepogingen van betrokken IdP's weigeren in plaats van door te gaan met mogelijk verouderde certificaten. De operationele afweging tussen beschikbaarheid en beveiliging is hier expliciet en moet worden vastgelegd in het federatieakkoord — waarbij wordt gedefinieerd hoe lang gecachede metadata mag worden gebruikt voordat deze als verlopen wordt beschouwd, en wat het terugvalgedrag is wanneer het register onbereikbaar is tijdens gevechtsoperaties waarbij de netwerkconnectiviteit intermitterend kan zijn.

Incidentrespons: toegang snel intrekken over een gefedereerde coalitie

Het intrekkingsprobleem in een gefedereerde coalitie is moeilijker dan in een PKI van één enkele organisatie, omdat de intrekkingsactie over soevereine grenzen heen moet worden doorgegeven naar systemen die de initierende natie niet beheert. Wanneer de credentials van een coalitiegebruiker worden gecompromitteerd — door diefstal, dwang of een beveiligingsincident bij de thuisnatie — moet elke relying party bij alle partnernaties die asserties van die gebruiker kan hebben geaccepteerd worden geïnformeerd en de intrekking moeten handhaven. De tijd tussen de incidentverklaring en de universele handhaving van de intrekking is het blootstellingsvenster waarbinnen de gecompromitteerde credential bruikbaar blijft.

Korte assertielevensduren zijn de meest effectieve eerstelijnscontrole. Een SAML-assertie met een geldigheidsvenster van 30 minuten verloopt voordat een gecompromitteerde credential in de meeste scenario's uitgebreid kan worden misbruikt, zonder dat een out-of-band intrekkingsmelding de relying party hoeft te bereiken. De kosten zijn dat de gebruiker elke 30 minuten opnieuw moet authenticeren, wat beheersbaar is bij naadloze SSO-herauthenticatie (waarbij de IdP stil een nieuwe assertie uitgeeft zonder de gebruiker te vragen) maar operationeel verstorend wordt als de IdP onbereikbaar is tijdens het herauthenticatievenster. Het instellen van de assertielevensduur vereist het balanceren van deze afweging tegen het verwachte connectiviteitsprofiel van het coalitieNetwerk.

Voor PKI-certificaatintrekking zijn Certificate Revocation Lists (CRL's) en Online Certificate Status Protocol (OCSP) de twee beschikbare mechanismen. Op CRL gebaseerde intrekking publiceert een ondertekende lijst van ingetrokken certificaatserienummers die relying parties periodiek ophalen; de intrekkingslatentie is gebonden aan het CRL-vernieuwingsinterval, doorgaans 24 uur in nationale PKI-praktijk maar configureerbaar tot 1-4 uur voor hoogdringende coalitie-scenario's. OCSP biedt realtime intrekkingsstatus maar vereist dat de OCSP-responder bereikbaar is bij authenticatietijd — hetzelfde connectiviteitsafhankelijkheidsprobleem als bij OIDC. Een gelaagde aanpak is passend: kortdurende SAML-asserties als primaire controle, frequente CRL-ophaling als veiligheidsmechanisme op certificaatniveau, en OCSP-stapling op TLS-laag voor applicaties waar realtime certificaatstatus vereist is. Out-of-band-meldingsprocedures — gedocumenteerde contactlijsten, voorgedefinieerde berichtformaten en geteste escalatiepaden binnen de coalitie — completeren de incidentresponscapaciteit die geen enkel technisch protocol volledig kan automatiseren.