Koalitions-Identitätsmanagement: föderierte Authentifizierung in NATO- und Partnernetzwerken

Wenn eine französische Verbindungsoffizierin eine Verbindung zu einem gemeinsamen Koalitionskommandosystem herstellt, ist ihre Identität keiner einzigen Organisation zuzuordnen. Ihre Zugangsdaten wurden von der Direction Interarmées des Réseaux d'Infrastructure et des Systèmes d'Information (DIRISI) ausgestellt, ihre Geheimhaltungseinstufung erfolgte nach französischer nationaler Sicherheitsrichtlinie, und ihre Rollen wurden von ihrer Befehlskette in Paris zugewiesen. Die Koalitionsanwendung, auf die sie zugreift, läuft auf einer Infrastruktur einer Partnernation und vertraut keinem der genannten Punkte standardmäßig. Diese Lücke zuverlässig, sicher und ohne manuelle Bereitstellung Tausender vorübergehender Koalitionskonten zu überbrücken – das ist das Problem, das das Koalitions-Identitätsmanagement löst. Dieser Artikel untersucht die Protokolle, PKI-Strukturen, Attributschemata und Richtlinienmechanismen, die Koalitionsinteroperabilität auf der Identitätsebene ermöglichen.

Das Identitätsproblem in Koalitionsoperationen

Koalitionsoperationen bringen Personal aus mehreren souveränen Nationen in einem Zeitrahmen von Tagen zusammen. Eine ständige gemeinsame Task Force kann Beitragende aus einem Dutzend Nationen umfassen, von denen jede nach ihrem eigenen Identitäts-Governance-Regime vorgeht, eine eigene Verzeichnisinfrastruktur betreibt und Zugangsdaten unter ihrer eigenen nationalen PKI-Hierarchie ausstellt. Bevor es föderierte Identitätslösungen gab, war die übliche Vorgehensweise die manuelle Bereitstellung: Verbindungspersonal an der Systemgrenze jeder Nation erstellte lokale Konten für eingehende Koalitionsnutzer, wies Berechtigungen manuell zu und deaktivierte diese Konten, wenn der Nutzer abgelöst wurde. Dieser Prozess war langsam, fehleranfällig, inkonsistent dokumentiert und führte zu persistenten verwaisten Konten, die noch lange aktiv blieben, nachdem das zugehörige Personal die Koalition verlassen hatte.

Die grundlegende Anforderung lautet, dass Authentifizierung und Autorisierung unter souveräner Kontrolle bleiben müssen, während nationenübergreifender Zugriff ermöglicht wird. Keine Nation akzeptiert eine zentralisierte Koalitions-Identitätsbehörde, die von einem anderen Mitglied übernommen, kompromittiert oder politisch eingesetzt werden könnte. Die Architektur kann sich daher nicht auf einen einzigen Identitätsspeicher stützen, in den alle Nationen eingebunden werden. Stattdessen muss sie den Identitätsanbieter jeder Nation als gleichberechtigten Partner behandeln und bilaterale oder multilaterale Vertrauensbeziehungen zwischen ihnen aufbauen, ohne die nationale Kontrolle über die Zugangsdaten selbst aufzugeben. Dies ist die definitorische Einschränkung, die das Koalitions-Identitätsmanagement architektonisch von unternehmensweitem Single Sign-On unterscheidet.

Die praktische Konsequenz ist, dass jede Identitätstransaktion über eine Koalitionsgrenze hinweg mindestens drei Parteien einbezieht: den heimischen Identitätsanbieter des Nutzers, die ressourcenverwaltende vertrauende Partei bei der Partnernation und den Vertrauensrahmen, auf den sich beide Seiten geeinigt haben zu betreiben. Wie im Leitfaden zur Implementierung von Federated Mission Networking beschrieben, ist dieser Vertrauensrahmen in Föderationsvereinbarungen dokumentiert, die festlegen, welche Attribute ausgetauscht werden, welche Anspruchsformate erwartet werden und wie Zugriffsentscheidungen an der Grenze getroffen werden.

Föderationsprotokol­le: SAML 2.0, OAuth 2.0 und OIDC für Verteidigungsumgebungen

Security Assertion Markup Language 2.0 (SAML 2.0) ist nach wie vor das dominierende Protokoll für Identitätsföderierung in Verteidigungs- und Regierungsumgebungen. Seine Reife, die breite Implementierung auf Enterprise-Identitätsplattformen (Microsoft ADFS, Shibboleth, Ping Identity) und sein XML-signaturbasiertes Assertion-Modell passen gut zur bestehenden PKI-Infrastruktur. Eine SAML-Assertion ist ein signiertes XML-Dokument, das die Identitätsangaben des Nutzers trägt und vom heimischen Identitätsanbieter nach der lokalen Authentifizierung ausgestellt wird. Die vertrauende Partei validiert die Signatur der Assertion anhand des Signaturzertifikats des Identitätsanbieters, überprüft die Audience-Restriction (um zu bestätigen, dass die Assertion für diesen spezifischen RP ausgestellt wurde) und prüft den Assertion-Zeitstempel, um Replay-Angriffe zu verhindern. Da die Assertion bei der Ausstellung signiert wird, benötigt die vertrauende Partei bei der Validierung keine direkte Verbindung zum Identitätsanbieter – ein wertvoller Vorteil in zeitweise nicht verbundenen Koalitionsumgebungen.

OAuth 2.0 und OpenID Connect (OIDC) sind zunehmend in Koalitionsarchitekturen präsent, da neuere Systeme REST-native APIs anstelle der SOAP-orientierten Muster übernehmen, für die SAML konzipiert wurde. OIDC erweitert OAuth 2.0 um ein standardisiertes ID-Token (ein JSON Web Token), das Identitätsangaben enthält, während OAuth 2.0-Zugriffstoken zur Autorisierung von API-Aufrufen im Namen des authentifizierten Nutzers verwendet werden. Das kürzere Token-Format und die HTTP-nativen Abläufe machen OIDC für mobile und Webanwendungen bevorzugt. Für den Koalitionseinsatz setzt OIDC voraus, dass der Autorisierungsserver der Heimnation zum Zeitpunkt der Token-Ausstellung aus dem Netzwerk der Partnernation erreichbar ist – was eine Konnektivitätsabhängigkeit schafft, die das Offline-Assertion-Modell von SAML vermeidet. Viele Koalitionsbereitstellungen setzen daher SAML für die primäre Authentifizierung ein und geben kurzlebige OIDC-Token lokal an der Grenze der Partnernation aus, wodurch eine eingehende SAML-Assertion effektiv in eine auf das Anwendungs-Ökosystem der Partnernation zugeschnittene OIDC-Sitzung übersetzt wird.

Beide Protokolle erfordern sorgfältige Härtung für Verteidigungsumgebungen. Die Assertion-Verschlüsselung (nicht nur Signierung) ist obligatorisch, wenn Assertions Netzwerkgrenzen überqueren, da eine signierte, aber unverschlüsselte SAML-Assertion die Geheimhaltungsstufe, Nationalität und Rollenzuweisungen des Nutzers für jeden Netzwerkbeobachter offenlegt. TLS 1.3 mit gegenseitiger Authentifizierung sollte alle Föderationsendpunkte schützen. Die Zeitsynchronisierung aller IdP- und RP-Infrastruktur ist eine stille Abhängigkeit: SAML-Zeitstempelvalidierungsfenster sind typischerweise auf fünf Minuten gesetzt, und eine Uhr­abweichung über diesem Fenster führt dazu, dass gültige Assertions fehlschlagen und den Zugriff für betroffene Nutzer ohne offensichtlichen Fehler außer einem Authentifizierungs-Timeout unterbrechen.

PKI-Kreuzzertifizierung: Überbrückung nationaler Zertifizierungsstellen

Identitätsföderations-Assertions sind nur so vertrauenswürdig wie die dahinterstehenden Signierungsschlüssel. Jeder SAML-Identitätsanbieter signiert seine Assertions mit einem Zertifikat, das unter einer Zertifizierungsstellen-Hierarchie ausgestellt wurde. Damit die vertrauende Partei einer Partnernation einer eingehenden Assertion vertrauen kann, muss sie der CA vertrauen, die das Signaturzertifikat ausgestellt hat. In einer internen Einzelorganisationsbereitstellung ist dies unkompliziert: Eine CA stellt Zertifikate für alle vertrauenden Parteien und Identitätsanbieter aus. In einer Koalition betreibt jede Nation ihre eigene CA-Hierarchie und stellt Zertifikate unter nationalen Richtlinienrahmen aus, die die Systeme anderer Nationen standardmäßig nicht anerkennen.

Die Kreuzzertifizierung löst dies, indem sie explizite Vertrauensverknüpfungen zwischen nationalen CA-Hierarchien herstellt. In ihrer einfachsten bilateralen Form stellt die CA von Nation A ein Kreuzzertifikat für die CA von Nation B aus (und umgekehrt). Eine vertrauende Partei in Nation A, die ihrer eigenen CA-Hierarchie vertraut, vertraut transitiv den unter der CA von Nation B ausgestellten Zertifikaten. Das Kreuzzertifikat gibt die Tiefe des Vertrauenspfads an und kann Richtlinienbeschränkungen enthalten, die begrenzen, für welche Zertifikatsverwendungen vertraut wird (z. B. Vertrauen in Nation-B-Zertifikate nur zur digitalen Signaturverifizierung, nicht zur Schlüsselverschlüsselung). In der NATO betreibt die NATO Public Key Infrastructure eine Brücken-CA, die die CAs der Teilnehmernationen kreuzzertifiziert, sodass eine einzige Brückenbeziehung das Vertrauen über alle verbundenen nationalen Hierarchien hinweg verbreiten kann, ohne dass jedes Nationenpaar eine direkte bilaterale Kreuzzertifizierung einrichten muss.

Zertifikatsrichtlinienkennungen (OIDs in den Zertifikatserweiterungen) sind der Mechanismus, durch den vertrauende Parteien nationenspezifische Vertrauensentscheidungen anwenden. Eine Koalitions-RP kann so konfiguriert werden, dass sie Zertifikate von allen kreuzzertifizierten nationalen CAs für allgemeine Authentifizierungszwecke akzeptiert, jedoch einen spezifischen Richtlinien-OID (der ein hardware-tokenbasiertes Zugangsmittel oder ein bestimmtes Sicherungsniveau angibt) verlangt, bevor der Zugriff auf als freigabefähig klassifizierte Ressourcen gestattet wird. Dieses zweistufige Richtlinienmodell – breites Authentifizierungsvertrauen, enges Autorisierungsvertrauen – vermeidet das betriebliche Problem, die Kreuzzertifizierungsvereinbarung jedes Mal ändern zu müssen, wenn eine neue Ressourcenkategorie eine höhere Sicherungsstufe erfordert, da die feingranularen Regeln in der lokalen Richtlinie der vertrauenden Partei und nicht in der CA-Infrastruktur liegen.

Rollenmapping über heterogene Koalitionsverzeichnisse hinweg

Selbst wenn die Authentifizierung über eine Föderationsgrenze hinweg gelingt, erfordert die Autorisierungsentscheidung beim System der Partnernation die Übersetzung der eingehenden Identitätsangaben in etwas, das das lokale Zugangskontrollsystem versteht. Der Dienstgrad eines französischen Offiziers, Lieutenant-Colonel, der im LDAP-Attributformat des französischen Militärs übermittelt wird, ist für ein britisches C2-System bedeutungslos, dessen Zugangskontrolllisten auf britischen Dienstgradgruppen und Rollencodes basieren. Rollenmapping ist der Prozess, Äquivalenzen zwischen den Attributschemata verschiedener nationaler Verzeichnisse herzustellen, sodass eingehende Assertions in lokal umsetzbare Zugriffsentscheidungen umgewandelt werden können.

Die Übersetzungsschicht wird typischerweise als Anspruchstransformationsregelsatz in der vertrauenden Partei oder im Identitätsvermittler der Partnernation implementiert. Regeln haben die Form von bedingten Zuordnungen: Wenn die eingehende Assertion ein Nationalitätsattribut „FRA" und einen Rangcode im Bereich OF-4 bis OF-5 der STANAG-Rangtabelle der NATO enthält, wird der Nutzer der lokalen Gruppe „coalition-senior-officer" zugeordnet. Die STANAG-Rangtabelle ist die gemeinsame Sprache, die dies ermöglicht: Sie liefert eine gemeinsame numerische Kennung für jeden Dienstgrad aller Verbündeten, sodass Rollenmapping-Regeln gegen den neutralen STANAG-Code und nicht gegen die native Rangbezeichnung jeder Nation verfasst werden können. Nationen, die Personal zu einer Koalition beitragen, sind dafür verantwortlich, das STANAG-Rangäquivalent in ihre SAML-Assertions aufzunehmen – eine Anforderung, die während der Föderationstests überprüft werden sollte.

Organisatorische Rollenzuweisungen stellen eine komplexere Mapping-Herausforderung dar, da kein NATO-Standard das Äquivalent der STANAG-Rangcodes für Funktionsrollen bereitstellt. Ein Nutzer, dem in den Verzeichnissen von Nation A die Rolle „Geheimdienstanalytiker" zugewiesen ist, muss möglicherweise auf verschiedene lokale Rollen abgebildet werden, je nachdem, auf welches der Systeme der Partnernation er zugreift und was die aktuellen Koalitions-Einsatzregeln für den Zugriffslevel dieser Rolle vorsehen. Dies erfordert, dass Rollenmapping-Regeln als lebendiges Dokument geführt werden, das über den Identitätsmanagement-Koordinierungsprozess der Koalition aktualisiert wird, wenn neue Systeme eingebunden werden und sich die operativen Anforderungen ändern. Die Herausforderungen des Koalitionsdatenaustauschs, die durch inkompatible Datenmodelle entstehen, sind genau an dieser Attributübersetzungsgrenze am akutesten.

Attributbasierte Zugriffskontrolle für die Freigabeerzwingung

Die rollenbasierte Zugriffskontrolle (RBAC) weist Berechtigungen Rollen und Rollen Nutzern zu. Für Koalitionssysteme ist dieses Modell unzureichend, da Zugriffsentscheidungen von Dimensionen abhängen, die Rollen allein nicht erfassen können. Ein Dokument mit der Kennzeichnung REL TO USA, GBR, CAN, AUS, NZL (freigabefähig für die Five-Eyes-Nationen) muss für einen kanadischen Offizier auf SECRET-Ebene zugänglich sein, aber nicht für einen französischen Offizier auf der entsprechenden Ebene, unabhängig davon, ob beide identische Funktionsrollen innehaben. Freigabefähigkeit ist eine Eigenschaft der Ressource, nicht der Rolle des Nutzers, und ihre korrekte Durchsetzung erfordert die gleichzeitige Auswertung von Nationalität, Geheimhaltungsstufe, Need-to-know und dem Klassifizierungslabel der Ressource.

Die attributbasierte Zugriffskontrolle (ABAC) handhabt dies auf natürliche Weise. Eine ABAC-Richtlinie ist eine logische Regel, die Subjektattribute (Nationalität, Geheimhaltungsstufe, Rolle, Zuweisung), Ressourcenattribute (Klassifizierungsstufe, Freigabevorbehalte, Handhabungsanweisungen) und Umgebungsattribute (Netzwerkklassifizierungsstufe, Zugriffszeit) gegen eine explizite Richtlinienaussage auswertet. Eine Richtlinie für das obige Dokument könnte lauten: Zugriff erlauben, wenn Subjekt.Nationalität in [USA, GBR, CAN, AUS, NZL] UND Subjekt.Geheimhaltungsstufe >= SECRET UND Ressource.Klassifizierung <= SECRET UND Ressource.Freigabefähigkeit enthält Subjekt.Nationalität. Diese Regel ist autorisierbar, prüfbar und unabhängig von der Rollentaxonomie einer bestimmten Nation. Die Richtlinienmaschine wertet sie zum Zugriffszeit­punkt gegen die aus der SAML-Assertion extrahierten Angaben und die Metadaten der Ressource aus.

Die eXtensible Access Control Markup Language (XACML) ist der ausgereifteste Standard für die Formulierung und Auswertung von ABAC-Richtlinien in Verteidigungsumgebungen. Ein XACML Policy Decision Point (PDP) empfängt eine Autorisierungsanfrage mit Subjekt-, Ressourcen- und Umgebungsattributen, wertet sie gegen den geladenen Richtliniensatz aus und gibt eine Erlaubnis- oder Ablehnungsentscheidung zurück. Der Policy Enforcement Point (PEP) in der Anwendung fängt jeden Ressourcenzugriff ab, erstellt die Autorisierungsanfrage, ruft den PDP auf und setzt die Entscheidung durch. Die Trennung von PEP und PDP ermöglicht es, die Richtlinie unabhängig vom Anwendungscode zu aktualisieren, zu versionieren und zu prüfen – eine kritische Eigenschaft, wenn sich Freigaberegeln mit der Entwicklung der Lage ändern.

Konfiguration vertrauender Parteien und Metadatenverwaltung im großen Maßstab

Eine Koalition aus zwölf Nationen, die jeweils zehn bis dreißig föderierte Anwendungen betreiben, erzeugt ein Metadatenverwaltungsproblem mit einer nicht trivialen Betriebsoberfläche. Jede vertrauende Partei muss aktuelle, gültige Metadaten für jeden Identitätsanbieter haben, von dem sie Assertions akzeptiert. Jeder Identitätsanbieter muss jede vertrauende Partei registriert haben, für die er Assertions ausstellen kann. Wenn eine Nation ihr IdP-Signaturzertifikat rotiert (was mindestens jährlich und bei Verdacht auf Kompromittierung geschehen sollte), muss jede vertrauende Partei, die Assertions dieser Nation akzeptiert, vor Ablauf des alten Zertifikats mit dem neuen aktualisiert werden. Dies manuell über Hunderte von bilateralen Registrierungen hinweg zu tun, ist betrieblich nicht tragbar und führt zu Zugriffsausfällen, wenn Aktualisierungen hinter Zertifikatsrotierungen zurückbleiben.

Die Lösung ist eine Föderationsmetadaten-Registry: ein zentral veröffentlichtes, signiertes XML-Dokument, das die Metadaten für alle registrierten Identitätsanbieter und vertrauenden Parteien in der Koalitionsföderierung auflistet. Jeder Teilnehmer ruft die Registry nach einem definierten Zeitplan ab (typischerweise alle 4–24 Stunden), extrahiert die für seine Vertrauenskonfiguration relevanten Einträge und aktualisiert seine lokale Identitätsplattform. Die Registry selbst ist durch einen Koalitions-Registry-Authorityenschlüssel signiert, und jeder Teilnehmer validiert diese Signatur, bevor er Aktualisierungen anwendet – was verhindert, dass ein kompromittierter Zwischennetzwerkknoten falsche Metadaten einschleust, um Authentifizierungsabläufe umzuleiten. SAML-Metadaten-Registrys gemäß der SAML V2.0 Metadata Extensions for Registration and Publication-Spezifikation bieten den technischen Rahmen dafür; das Federated Mission Networking-Programm der NATO hat die dazugehörigen operativen Prozesse dokumentiert.

Metadatenkonsumenten sollten so konfiguriert sein, dass sie bei einem Metadaten-Abruffehler geschlossen versagen: Wenn die Registry nicht erreichbar ist und eine zwischengespeicherte Kopie abgelaufen ist, sollte das System Authentifizierungsversuche von betroffenen Identitätsanbietern verweigern, anstatt sich weiterhin auf potenziell veraltete Zertifikate zu stützen. Der betriebliche Kompromiss zwischen Verfügbarkeit und Sicherheit ist hier explizit und sollte in der Föderationsvereinbarung kodifiziert werden – mit der Festlegung, wie lange zwischengespeicherte Metadaten verwendet werden können, bevor sie als abgelaufen gelten, und was das Rückfallverhalten ist, wenn die Registry während Kampfoperationen mit möglicherweise unterbrochener Netzwerkkonnektivität nicht erreichbar ist.

Incident Response: Zugriff in einer föderierten Koalition schnell widerrufen

Das Widerrufsproblem in einer föderierten Koalition ist schwieriger als in einer Einzelorganisations-PKI, weil die Widerrufsaktion über souveräne Grenzen hinweg zu Systemen propagieren muss, die die originierende Nation nicht kontrolliert. Wenn die Zugangsdaten eines Koalitionsnutzers kompromittiert werden – durch Diebstahl, Nötigung oder einen Sicherheitsvorfall bei der Heimnation – muss jede vertrauende Partei über alle Partnernationen hinweg, die möglicherweise Assertions von diesem Nutzer akzeptiert haben, informiert werden und den Widerruf durchsetzen. Die Zeit zwischen der Vorfallserklärung und der universellen Durchsetzung des Widerrufs ist das Expositionsfenster, in dem das kompromittierte Zugangsmittel noch einsatzfähig bleibt.

Kurze Assertion-Laufzeiten sind die effektivste erstrangige Kontrolle. Eine SAML-Assertion mit einem 30-minütigen Gültigkeitsfenster läuft ab, bevor ein kompromittiertes Zugangsmittel in den meisten Szenarien umfassend ausgenutzt werden kann, ohne dass eine außerbandseitige Widerrufsmeldung die vertrauende Partei erreichen muss. Der Preis ist, dass sich der Nutzer alle 30 Minuten erneut authentifizieren muss, was mit nahtloser SSO-Neuenthentifizierung (bei der der Identitätsanbieter stillschweigend eine neue Assertion ausstellt, ohne den Nutzer aufzufordern) handhabbar ist, aber betrieblich störend wird, wenn der Identitätsanbieter während des Neuenthentifizierungsfensters nicht erreichbar ist. Die Festlegung der Assertion-Laufzeit erfordert ein Abwägen dieses Kompromisses gegen das erwartete Konnektivitätsprofil des Koalitionsnetzwerks.

Für den PKI-Zertifikatswiderruf stehen zwei Mechanismen zur Verfügung: Zertifikatsperrlisten (CRL) und Online Certificate Status Protocol (OCSP). Der CRL-basierte Widerruf veröffentlicht eine signierte Liste widerrufener Zertifikatsseriennummern, die vertrauende Parteien regelmäßig abrufen; die Widerrufslatenz ist durch das CRL-Aktualisierungsintervall begrenzt, typischerweise 24 Stunden in nationaler PKI-Praxis, aber für hochdringliche Koalitionsszenarien auf 1–4 Stunden konfigurierbar. OCSP liefert den Echtzeit-Widerrufsstatus, setzt aber voraus, dass der OCSP-Responder zum Authentifizierungszeitpunkt erreichbar ist – das gleiche Konnektivitätsabhängigkeitsproblem wie bei OIDC. Ein mehrschichtiger Ansatz ist angemessen: kurzlebige SAML-Assertions als primäre Kontrolle, häufige CRL-Abrufe als Sicherheitsnetz auf Zertifikatsebene und OCSP-Stapling auf TLS-Ebene für Anwendungen, bei denen der Echtzeit-Zertifikatsstatus erforderlich ist. Außerbandseitige Benachrichtigungsverfahren – dokumentierte Kontaktlisten, vordefinierte Nachrichtenformate und getestete Eskalationswege innerhalb der Koalition – vervollständigen die Incident-Response-Fähigkeit, die kein technisches Protokoll vollständig automatisieren kann.