Identity Governance und Administration für Verteidigungsorganisationen

Identity Governance und Administration (IGA) ist die Disziplin, systematisch zu kontrollieren, wer auf was, wie lange und auf welcher Grundlage Zugriff hat — und prüfbare Nachweise zu erstellen, dass der Zugriff zu jedem Zeitpunkt angemessen ist. In einem kommerziellen Unternehmen verwaltet IGA Rollen, Berechtigungen und regelmäßige Überprüfungen über einen HR-gesteuerten Mitarbeiterlebenszyklus. In einer Verteidigungsorganisation muss IGA all das leisten und gleichzeitig ein zweites Zugriffskontrollgitter durchsetzen, das aus Sicherheitsfreigabestufen, Compartment-Mitgliedschaften, Need-to-Know-Entscheidungen und Programmgenehmigungen besteht. Die Kluft zwischen diesen beiden Problemstellungen ist der Ort, an dem die meisten kommerziellen IGA-Implementierungen scheitern, wenn sie in die Verteidigung übertragen werden. Dieser Artikel befasst sich mit den Engineering-Entscheidungen, die diese Kluft schließen — er behandelt freigabebasierte Provisionierung, Rollenentwicklung für Multi-Klassifizierungsumgebungen, Aufgabentrennung bei kleinen Teams, Design von Zugriffszertifizierungen, CAC/PIV-Integration und die Audit-Trail-Architektur, die für eine RMF-Akkreditierung erforderlich ist. Für die Credential-Broker-Schicht, auf die IGA bei privilegiertem Zugriff angewiesen ist, lesen Sie unsere Abhandlung über Privileged Access Management für die Verteidigung.

Warum sich IGA in der Verteidigung von Unternehmen unterscheidet — Freigabestufen als zusätzliche Zugriffsdimension, Compartment-Verwaltung, Need-to-Know-Durchsetzung

In einem kommerziellen Unternehmen hat die Zugriffskontrolle zwei wesentliche Dimensionen: wer der Benutzer ist (Identität) und welcher Rolle oder Gruppe er angehört (Berechtigung). Eine Verteidigungsorganisation fügt eine dritte Dimension hinzu, die zu beiden orthogonal ist: wozu der Benutzer freigegeben und berechtigt ist. Ein erfahrener Netzwerkingenieur kann eine gültige SECRET-Freigabe besitzen, aber keine Genehmigung haben, auf das Intelligence-Compartment zuzugreifen, das im selben Netzwerk auf SECRET-Ebene läuft. Ein Junior-Analyst kann bis TOP SECRET freigegeben und speziell in ein Compartment eingelesen sein, auf das der erfahrene Ingenieur keinen Zugang hat. Weder Dienstalter noch Organisationshierarchie klären diese Entscheidungen — nur der formelle Genehmigungsdatensatz tut dies.

Kommerzielle IGA-Plattformen — SailPoint IdentityNow, Saviynt, Omada, One Identity — sind für das zweidimensionale Problem konzipiert. Sie können benutzerdefinierte Attribute speichern und mit ausreichender Anpassung Freigabeebenen-Einschränkungen durchsetzen, aber sie modellieren nativ keine Compartments, Handling-Caveats oder Programmzugangsberechtigungen als erstklassige Objekte. Die Plattform lässt Sie ein benutzerdefiniertes Attribut namens „clearance_level" hinzufügen und eine Provisionierungsregel schreiben, die es prüft. Die Plattform wird jedoch ohne benutzerdefinierte Entwicklung keinen Live-Feed von einem Personalsicherheitssystem pflegen, den Unterschied zwischen einem formellen SCI-Einlesungsprotokoll und einer selbst gemeldeten Freigabebehauptung auflösen oder das Gitter von Compartments mit ihren eigenen Einlese- und Auslese-Workflows modellieren.

Die Need-to-Know-Durchsetzung ist der gravierendste Unterschied. In der Unternehmens-IGA wird der Zugriff in der Regel auf eine Ressourcenklasse gewährt — „dieser Benutzer kann auf den Finance-Data-Lake zugreifen." In der Verteidigung kann der Zugriff auf dieselbe Ressource Benutzer A, aber nicht Benutzer B gewährt werden, obwohl beide die korrekte Freigabe besitzen, weil Benutzer B nicht formell in das Programm eingelesen wurde, das die Daten produziert. IGA muss dies zum Zeitpunkt der Provisionierung und der Rezertifizierung durchsetzen, indem maßgebliche Programmzugangsdatensätze abgefragt werden, anstatt sich auf die Bestätigung eines Managers zu verlassen. Die Lücke zwischen „mein Manager hat meinen Zugriff genehmigt" und „der maßgebliche Datensatz bestätigt, dass ich in dieses Programm eingelesen bin" ist genau die Lücke, die zu Prüfungsbefunden und in den schlimmsten Fällen zu unbefugten Offenlegungen führt.

Die praktische Implikation ist, dass eine IGA-Implementierung für die Verteidigung Connector-Entwicklung und Workflow-Anpassung über das hinaus erfordert, was jedes handelsübliche IGA-Produkt mitliefert. Planen Sie dies im Vorfeld ein, behandeln Sie die Freigabe- und Compartment-Daten-Feeds als die kritischste Integrationsarbeit im Projekt, und überlegen Sie, ob das bestehende kommerzielle Produkt erweitert werden kann, um die Anforderungen zu erfüllen, oder ob eine verteidigungsspezifische IGA-Lösung (wie solche, die auf der Enterprise-Identity-Service-Architektur der IC aufgebaut sind) der richtige Ausgangspunkt ist. Das Zero-Trust-Modell für Verteidigungssoftware hängt davon ab, dass IGA genaue, kontinuierlich validierte Berechtigungsdaten liefert — ohne diese treffen Policy-Engines Autorisierungsentscheidungen auf Basis veralteter oder nicht verifizierbarer Identitätsattribute.

Der Joiner-Mover-Leaver-Lebenszyklus in einer klassifizierten Umgebung — automatisierte Provisionierungsauslöser, Integration der Freigabeprüfung, Rollenübergänge bei Versetzungen

Der Joiner-Mover-Leaver-Lebenszyklus (JML) ist die grundlegende Betriebsschleife jeder IGA-Implementierung. In der Verteidigung hat jede Phase der Schleife zusätzliche Einschränkungen, die sie verlangsamen, aber auch folgenreicher machen, wenn sie falsch gehandhabt wird.

Joiner-Workflow. Ein Joiner-Ereignis wird ausgelöst, wenn ein maßgebliches HR- oder Personalsystem einen neuen Datensatz erstellt — Neueinstellung, neuer Auftragnehmer, neue temporäre Zuweisung. In der Verteidigung darf die Provisionierung erst beginnen, wenn die IGA-Plattform unabhängig die adjudizierte Freigabestufe des Betreffenden aus dem Personalsicherheitssystem (JPAS oder DISS im US-DoD-Kontext; nationale Entsprechungen in alliierten Verteidigungsorganisationen) bestätigt hat, und einen gültigen CAC- oder PIV-Karten-DN aus dem Einschreibungssystem bestätigt hat. Die Reihenfolge ist entscheidend: Die Freigabeprüfung steuert die Provisionierung, nicht umgekehrt. Eine IGA-Plattform, die zuerst ein Konto provisioniert und dann die Freigabe in einem Hintergrundjob prüft, hat bereits ein ausnutzbares Zeitfenster geschaffen.

Der Joiner-Workflow sollte auch eine Compartment-Zugangsüberprüfung für jede Berechtigung auslösen, die eine formelle Einlesung in ein Programm erfordert. Wenn der Einlesungsdatensatz im maßgeblichen Programmzugangssystem existiert, schreitet die Provisionierung fort. Wenn nicht, wird die Berechtigung unterdrückt und ein Workflow-Element für den Sicherheitsbeauftragten erstellt, um den formellen Einlese-Prozess einzuleiten. Das Konto existiert; die sensible Berechtigung tut es nicht, bis der Papierdatensatz zu ihrer Rechtfertigung vorhanden ist.

Mover-Workflow. Versetzungen in Verteidigungsorganisationen sind häufig und folgenreich. Eine Person, die von einem Programm zu einem anderen wechselt, verliert in der Regel den Zugang zu den Systemen des ersten Programms und erhält Zugang zu denen des zweiten. Der IGA-Mover-Workflow muss diesen Übergang deterministisch auflösen: das Berechtigungsdelta zwischen dem alten Rollensatz und dem neuen berechnen, was nicht mehr angemessen ist widerrufen, und was neu gerechtfertigt ist provisionieren — alles durch dieselben Freigabe- und Compartment-Prüfungen gesteuert. Wenn die neue Rolle eine höhere Freigabe erfordert, als die Person derzeit besitzt, wird das Konto für diese Klassifizierungsdomäne bis zur Feststellung einer Freigabe-Aufwertung unterdrückt.

Der schwierigere Mover-Fall ist temporärer Dienst (TDY) oder Abordnung. Die Person behält ihren Heimateinheit-Rollensatz und erwirbt einen zeitlich begrenzten ergänzenden Rollensatz für die Dauer der Zuweisung. IGA muss dies modellieren, ohne der Person dauerhaft erhöhten Zugang zu geben, der das Ende der Zuweisung überlebt. Zeitlich begrenzte Rollenzuweisungen mit automatischem Ablauf, die von den Sicherheitsbeauftragten der Heimat- und Gasteinheit geprüft werden, sind das richtige Muster.

Leaver-Workflow. Der Leaver-Workflow — ausgelöst durch Kündigung, Vertragsende, Ruhestand oder Widerruf der Freigabe — ist die Phase mit den höchsten Einsätzen und diejenige, bei der kommerzielle IGA-Implementierungen in der Verteidigung am häufigsten scheitern. Die Erwartung ist eine taggleiche De-Provisionierung aller Konten über alle verbundenen Systeme hinweg, unabhängig davon, ob die Person physisch ihre CAC zurückgegeben hat, sich von ihrem Arbeitsplatz abgemeldet hat oder einen HR-Abmeldeprozess abgeschlossen hat. Die IGA-Plattform darf nicht warten, bis ein HR-Datensatz den Status „beendet" erreicht, bevor der Zugriff entzogen wird — das Freigabe-Widerrufsereignis vom Personalsicherheitssystem ist der Auslöser, und er muss sich nahezu in Echtzeit verbreiten.

# Leaver-Workflow SLA-Ziele (Verteidigungskontext)
clearance_revocation_to_AD_disable:   < 1 Stunde
AD_disable_to_all_app_deprovisioning: < 4 Stunden
CAC_invalidation_propagation:         < 1 Stunde (DEERS → verbundene Systeme)
audit_closure_record_generated:       selber Geschäftstag
physical_access_revocation:           selber Tag (Integration Physisches Zugangssystem)

Rollenentwicklung für Multi-Klassifizierungsumgebungen — Rollenmodelldesign, freigabebegrenzte Rollensätze, attributbasiertes vs. rollenbasiertes Hybrid für Compartments

Rollenentwicklung — der Prozess der Definition und Pflege des Rollenmodells, das die IGA-Plattform durchsetzt — ist der zeitaufwändigste Teil einer IGA-Implementierung für die Verteidigung und derjenige, der am wahrscheinlichsten persistente technische Schulden produziert, wenn er schlecht durchgeführt wird. Die grundlegende Einschränkung ist, dass Rollen über organisatorische Änderungen hinweg stabil sein müssen, weil jede Rollenänderung in der IGA-Plattform ein administratives Ereignis ist, das Change-Control, erneutes Testen und möglicherweise eine Rezertifizierungskampagne erfordert.

Die erste Designentscheidung ist die Domänentrennung. Verteidigungsorganisationen operieren über mehrere Klassifizierungsdomänen — mindestens UNCLASSIFIED und SECRET, oft auch TOP SECRET und eine oder mehrere SCI-Enklaven. Rollen müssen innerhalb jeder Domäne separat definiert und in separaten Verzeichnisinstanzen gespeichert werden. Eine Rolle namens „Analyst" in der UNCLASSIFIED-Domäne und eine Rolle namens „Analyst" in der SECRET-Domäne sind nicht dieselbe Rolle — sie tragen unterschiedliche Berechtigungen, unterschiedliche Freigabe-Voraussetzungen und werden von verschiedenen Sicherheitsbeauftragten verwaltet. Sie in eine einzelne domänenübergreifende Rolle zusammenzufassen, ist ein architektonischer Fehler, den Akkreditierungsstellen sofort finden werden und der ein reales Risiko domänenübergreifender Berechtigungslecks schafft.

Innerhalb jeder Domäne sollten Rollen funktional statt organisatorisch sein. Eine organisatorische Rolle — „Mitglied der Geheimdienstzelle des 3. Geschwaders" — ist nur so lange stabil, wie die Organisation es ist. Eine funktionale Rolle — „Geheimdienstanalyst, klassifizierte Systeme" — begleitet die Funktion einer Person über Organisationsgrenzen hinweg und übersteht die Reorganisationen, die in den meisten Verteidigungsumgebungen alle achtzehn Monate stattfinden. Funktionale Rollen lassen sich auch sauberer zusammensetzen: Eine Person mit einer Doppelrolle (Analyst und Abteilungsadministrator) erhält zwei funktionale Rollen, die jeweils unabhängig verwaltet und zertifiziert werden.

Die Compartment-Verwaltung erfordert eine attributbasierte Zugriffskontroll-Schicht (ABAC) auf der RBAC-Grundlage. Die Rolle legt fest, was die Person tun kann; die Compartment-Attribute in ihrem Identitätsdatensatz legen fest, was sie dabei sehen kann. Dieses Hybridmodell — RBAC für strukturelle Berechtigungen, ABAC für Datenebenenfilterung — ist die Architektur, die mit der Komplexität einer echten Verteidigungsorganisation skaliert, ohne für jedes neu erstellte Compartment eine neue Rolle zu erfordern.

# Identitätsattribut-Schema (vereinfacht)
{
  "dn": "CN=J.Smith,OU=SECRET,DC=mil",
  "clearance_level": "SECRET",
  "compartments": ["ALPHA", "BRAVO"],
  "programs": ["PGM-001", "PGM-004"],
  "roles": ["intelligence-analyst-s", "portal-user-s"],
  "card_dn": "CN=SMITH.JANE.1234567890,OU=DoD,O=U.S. Government,C=US",
  "clearance_expiry": "2028-03-15",
  "last_certified": "2026-04-01"
}

Die Rollenlebenszyklusverwaltung — Hinzufügen, Ändern und Außerdienststellung von Rollen — erfordert einen separaten Governance-Prozess von der Benutzerlebenszyklusverwaltung. Neue Rollen sollten eine Genehmigung des Sicherheitsbeauftragten, eine Berechtigungsfolgenanalyse und eine Testumgebungsvalidierung erfordern, bevor sie in die Produktion überführt werden. Außer Dienst gestellte Rollen erfordern einen Migrationsplan, der aktuelle Rolleninhaber auf Ersatzrollen umzieht, bevor die alte Rolle entfernt wird, um verwaiste Berechtigungen in verbundenen Systemen zu verhindern.

Aufgabentrennung in Verteidigungsprogrammen — SoD-Regeldesign für Beschaffung und Betrieb, kompensierende Kontrollen für Ausnahmen in kleinen Teams

Aufgabentrennung (SoD) ist das Kontrollprinzip, dass kein einzelner Mitarbeiter beide Seiten einer risikoreichen Transaktion innehaben sollte — die Fähigkeit, sowohl eine finanzielle Verpflichtung einzuleiten als auch zu genehmigen, oder sowohl eigenen Zugriff zu beantragen als auch zu gewähren, oder sowohl eine Softwareversion zu schreiben als auch zu zertifizieren. In Beschaffungs- und Betriebsumgebungen der Verteidigung haben SoD-Versagen einige der kostspieligsten Betrugs- und Misswirtschaftsfälle verursacht: ein Beschaffungsbeauftragter, der auch Rechnungszahlungen zertifizieren konnte; ein Systemadministrator, der sowohl Anwendungscode als auch dessen Zugriffskontrollen ändern konnte; ein Logistikmanager, der sowohl Material bestellen als auch den Empfang zertifizieren konnte.

IGA setzt SoD durch einen Regelsatz durch, der konfliktbehaftete Berechtigungspaare identifiziert und verhindert, dass eine einzelne Identität beide hält. Der Regelsatz muss mit Blick auf die spezifischen risikoreichen Workflows der Verteidigungsbeschaffung gestaltet sein, nicht aus einer kommerziellen Finanzdienstleistungsvorlage übernommen. Wichtige Konfliktpaare in Verteidigungskontexten umfassen:

• Vertragseinleitung und Vertragsfreigabe (Beschaffungs-SoD)
• Zugriffsantragseinreichung und Zugriffsgenehmigung (IAM-SoD)
• Code-Commit und Autorisierung der Code-Bereitstellung (DevSecOps-SoD)
• Kryptografische Schlüsselgenerierung und Schlüsselverwahrerzertifizierung
• Entsorgungsgenehmigung von Vermögenswerten und Empfangszertifizierung
• Eingabe finanzieller Verpflichtungen und Verpflichtungszertifizierung

Die Engineering-Herausforderung in der Verteidigung besteht darin, dass viele Programme mit sehr kleinen Teams laufen — manchmal weniger als zehn freigegebene Mitarbeiter, die alle Rollen abdecken. Eine SoD-Regel, die erfordert, dass zwei verschiedene Personen die konfliktbehafteten Berechtigungen innehaben, kann in einem dreiköpfigen vorwärts eingesetzten Detachement nicht durchsetzbar sein. Die richtige IGA-Reaktion besteht nicht darin, SoD-Regeln für kleine Teams zu deaktivieren; es geht darum, einen strukturierten Ausnahme-Workflow mit kompensierenden Kontrollen zu implementieren.

Eine kompensierende Kontrolle für eine SoD-Ausnahme sollte beinhalten: dokumentierte Risikoakzeptanz, die vom genehmigenden Beamten unterzeichnet wurde; ein verstärktes Audit-Flag für alle Transaktionen, die vom Ausnahmeinhaber ausgeführt werden, sodass jede solche Transaktion in der nächsten Compliance-Überprüfung angezeigt wird; eine obligatorische Sekundärprüfungsanforderung (die Transaktion ist abgeschlossen, aber eine zweite freigegebene Person muss innerhalb eines definierten Zeitfensters prüfen und gegenzeichnen); und ein Ablaufdatum für die Ausnahme, das eine Neubewertung auslöst statt still weiterzulaufen.

SoD-Regeln werden auch während Zugriffszertifizierungskampagnen sichtbar. Wenn ein Rezertifizierungsprüfer den Zugriff für jemanden genehmigt, der ein konfliktbehaftetes Berechtigungspaar hält, sollte die IGA-Plattform den Konflikt sichtbar darstellen und eine explizite Außerkraftsetzungsentscheidung erfordern, anstatt die Genehmigung still zu erlauben. Jede Außerkraftsetzung wird als Zertifizierungsausnahme im Audit-Trail aufgezeichnet, sodass der Akkreditierungsbeauftragte nicht nur sehen kann, welcher Zugriff existiert, sondern welche SoD-Konflikte wissentlich akzeptiert wurden und von wem.

Zugriffszertifizierungskampagnen — Kampagnenhäufigkeit für klassifizierten Systemzugriff, automatisierte Prüferzuweisung nach Vorgesetztenkette, Batch- vs. risikobasierte Rezertifizierung

Zugriffszertifizierung ist der periodische Prozess, bei dem die aktuellen Berechtigungen jedes Benutzers einem verantwortlichen Prüfer zur Bestätigung vorgelegt werden, dass der Zugriff weiterhin angemessen ist. In der Verteidigung ist es auch der primäre Mechanismus, durch den eine Organisation kontinuierliche Compliance mit AC-2 und verwandten Kontrollen nachweist — die Frage des Akkreditierungsbeauftragten „Können Sie mir zeigen, dass alle Zugriffe auf diesem System derzeit autorisiert sind?" wird durch den Zertifizierungskampagnendatensatz beantwortet.

Die NIST 800-53 AC-2(j)-Mindestanforderung erfordert eine jährliche Überprüfung aller Konten, aber die Verteidigungspraxis und die meisten Akkreditierungsrichtlinien erwarten mehr. Ein praktischer Kampagnenplan für klassifizierte Systeme:

• Vierteljährlich: Privilegierte Konten (Systemadministratoren, Sicherheitsbeauftragte, Dienstkonten mit erhöhten Rechten), Konten auf Cross-Domain-Lösungen, kryptografischen Schlüsselverwaltungssystemen und Intelligence-Repositories
• Halbjährlich: Alle Benutzerkonten auf SECRET-Systemen und darüber; Konten mit Zugriff auf Finanzierungs- und Beschaffungsfunktionen
• Jährlich: UNCLASSIFIED-Systemkonten; Nur-Lese-Konten ohne Schreib- oder Privilegiertenfähigkeit
• Ereignisgesteuert: Jedes Konto einer Person, die Rolle, Programm oder Einheit wechselt; jedes Konto auf einem System, das eine größere Änderung abschließt; jedes Konto, bei dem eine Freigabeerneuerung oder Auf-/Abstufung stattgefunden hat

Die automatisierte Prüferzuweisung ist in Verteidigungsumgebungen kritisch, wo sich Organisationsstrukturen häufig ändern und die IGA-Plattform nicht auf eine statische Prüferzuordnung angewiesen sein kann. Die korrekte Quelle der Prüferzuweisung ist die maßgebliche Vorgesetztenkette aus dem HR-System — wenn die IGA-Plattform eine Zertifizierungskampagne generiert, fragt sie den aktuellen Vorgesetztendatensatz für jede Identität ab und weist die Überprüfung diesem Vorgesetzten zu. Wenn die Vorgesetztenposition vacant ist (ein häufiges Vorkommen in eingesetzten Umgebungen), eskaliert die Kette automatisch zum Vorgesetzten der nächsten Ebene, mit einem definierten Eskalations-Timeout, der eine Sicherheitsbeauftragten-Überschreibung auslöst.

Batch-Zertifizierung — Präsentation aller Berechtigungen für eine Benutzerpopulation auf einmal — ist für die halbjährlichen und jährlichen Kampagnen geeignet, bei denen das Ziel eine umfassende Überprüfung ist. Risikobasierte Zertifizierung ist für hochfrequente Überprüfungen vorzuziehen: Anstatt den gesamten Berechtigungssatz eines privilegierten Benutzers vierteljährlich zu präsentieren, identifiziert die IGA-Plattform, welche Berechtigungen sich geändert haben, welche genutzt wurden (und welche nicht) und welche SoD-Konflikte tragen, und präsentiert nur diese zur fokussierten Überprüfung. Nicht genutzte Berechtigungen — eine privilegierte Rolle, die vor sechs Monaten gewährt wurde und nie ausgeübt wurde — sind der wertvollste Fund einer risikobasierten Kampagne; sie stellen Zugriff dar, der auf dem Papier existiert, der Organisation aber nichts kostet zu widerrufen, und ihre sofortige Entfernung reduziert die im Insider-Bedrohungserkennungsmodell dokumentierte Angriffsfläche sofort.

Kampagnenabschlussquoten sind ein nachlaufender Indikator für die Programmgesundheit. Eine Kampagne, die 95 % Abschluss mit 5 % Ausnahmen erreicht, ist vertretbar. Eine Kampagne, die 60 % Abschluss erreicht, weil Prüfer die Benachrichtigung ignorierten, ist ein Audit-Befund in Wartestellung. IGA-Plattformen sollten unvollständige Überprüfungen mit zunehmender Dringlichkeit durch die Vorgesetztenkette eskalieren, und Sicherheitsbeauftragte sollten in Echtzeit Dashboard-Einblick in Kampagnenabschlussquoten haben, anstatt ein Abschlussproblem erst am Kampagnendeadline zu entdecken.

Integration mit HR, Identitätsanbietern und CAC/PIV — Integrationsarchitektur für DoD/NATO-PKI, CAC/PIV-verknüpfte Provisionierung, Echtzeit-Propagierung von Freigabe-Widerrufen

Die Integrationsarchitektur für eine Verteidigungs-IGA-Plattform ist komplexer als jede kommerzielle Implementierung, weil sie mehrere maßgebliche Systeme überspannt, die keinen gemeinsamen API-Vertrag teilen, auf verschiedenen Klassifizierungsebenen operieren und verschiedenen Organisationen gehören.

Der Identitätsanker im US-DoD-Kontext ist die Common Access Card (CAC). Jedes aktive Militärmitglied, Reservist im Dienst und die meisten zivilen und Auftragnehmergestellten tragen eine. Die CAC enthält drei PKI-Zertifikate (Identität, E-Mail und Content-Signing), deren Distinguished Names als stabiler, maßgeblicher Identifier für die Person über alle verbundenen Systeme hinweg dienen. Das Kontomodell der IGA-Plattform muss um den CAC-DN gebaut werden, nicht um eine E-Mail-Adresse oder Mitarbeiter-ID, weil diese sich ändern können, während der CAC-DN über Kartenerneuerungen hinweg stabil bleibt.

CAC-Ausgabe- und Erneuerungsdaten fließen vom Defense Enrollment Eligibility Reporting System (DEERS) durch das Real-time Automated Personnel Identification System (RAPIDS). Die IGA-Integration mit DEERS/RAPIDS liefert drei kritische Ereignisse: Kartenausgabe (löst Kontoaktivierung aus), Kartenerneuerung (löst DN-Aktualisierungspropagierung zu allen verbundenen Systemen aus) und Kartenwiderruf (löst sofortige Kontosperrung aus). Die Widerrufspropagierung muss nahezu in Echtzeit erfolgen — eine widerrufene CAC, die noch 24 Stunden lang Systemzugriff gewährt, weil die IGA-Plattform DEERS einmal täglich abfragt, ist ein Compliance-Versagen und ein Sicherheitsvorfall in Wartestellung. Das Ziel ist eine sub-stündige Propagierung für Widerrufereignisse, erreicht durch ereignisgesteuerte Webhooks oder einen hochfrequenten Delta-Sync-Feed statt Batch-Abfragen.

Die Propagierung von Freigabewiderrufen hat dieselbe Anforderung. Der Ablauf ist: Personalsicherheitsbeauftragter widerruft Freigabe in JPAS/DISS → IGA-Plattform empfängt Ereignis → alle Konten auf der widerrufenen Freigabestufe und darüber werden gesperrt → verbundene Systeme propagieren die Sperrung durch ihre eigenen IGA-Connectors. Die IGA-Plattform ist die Orchestrierungsschicht; jedes verbundene System ist verantwortlich, die Sperrung durch seine eigenen Zugriffskontrollen durchzusetzen, anstatt darauf zu vertrauen, dass die IGA-Plattform individuell jede API jedes Systems aufruft.

Für alliierte Verteidigungsorganisationen, die unter NATO-PKI operieren, folgt die Integrationsarchitektur demselben Muster mit nationalen PKI-CAs statt DoD-PKI. Die IGA-Plattform muss dem entsprechenden nationalen Trust-Anchor vertrauen und die DN-Struktur der nationalen PKI-Zertifikate parsen, die sich vom DoD-Format unterscheidet. Domänenübergreifende Szenarien — ein US-Verbindungsoffizier, der im Netzwerk einer Partnernation operiert — erfordern Föderierung über Trust-Anchors hinweg, typischerweise durch eine PKI-Bridge oder eine missionssspezifische Föderierungsvereinbarung implementiert, die die IGA-Plattform in eine temporäre Identitätsbindung übersetzt.

# IGA-Integrationstopologie
HR-System (DCPDS / SAP) ──→ [IGA-Plattform] ←── Personalsicherheit (JPAS/DISS)
                                   ↑
DEERS/RAPIDS (CAC-Ereignisse) ─────┘
                                   ↓
           ┌───────────────────────┼───────────────────────┐
           ↓                       ↓                       ↓
   AD (UNCLASSIFIED)        AD (SECRET)           AD (TS/SCI)
           ↓                       ↓                       ↓
   App-Connectors           App-Connectors         App-Connectors
   (NIPR-Systeme)           (SIPR-Systeme)         (JWICS-Systeme)

Audit-Trails und Compliance-Reporting — NIST 800-53 AC/IA-Kontrollen, Audit-Log-Anforderungen für klassifizierten Systemzugriff, Erstellung von Compliance-Nachweisen

Der von einer IGA-Plattform produzierte Audit-Trail ist das primäre Nachweis-Artefakt für die Zugriffskontroll- und Identifikations-und-Authentifizierungs-Kontrollfamilien in einer NIST 800-53-Bewertung. Dies richtig zu machen ist keine Option — es ist der Unterschied zwischen einem Akkreditierungspaket, das kontinuierliche Compliance nachweist, und einem, das für jeden Zugriffskontrollbefund einen Plan of Action and Milestones (POA&M) auslöst.

Das IGA-Audit-Log muss jedes Provisionierungs- und De-Provisionierungsereignis auf Transaktionsebene erfassen. Jeder Datensatz sollte enthalten: die betroffene Identität, die gewährte oder widerrufene Berechtigung, den Zeitpunkt des Ereignisses, die Autorität, unter der das Ereignis ausgeführt wurde (automatisierter Workflow, Manager-Genehmigung, Sicherheitsbeauftragten-Überschreibung oder Zertifizierungskampagnenentscheidung), und eine stabile Referenz auf das Quellereignis, das die Aktion ausgelöst hat (die HR-Datensatzänderung, das Freigabeereignis, die Zertifizierungsentscheidung). Dieses Detailniveau unterstützt drei verschiedene Audit-Anwendungsfälle: Rekonstruktion des Zugriffsstatus zu einem beliebigen historischen Zeitpunkt, Untersuchung eines spezifischen Zugriffsereignisses und aggregiertes Compliance-Reporting über die Benutzerpopulation.

Die NIST 800-53-Kontrollen, die am direktesten durch IGA-Audit-Daten belegt werden, sind:

• AC-2 (Kontoverwaltung): IGA-Lebenszyklusdatensätze zeigen, dass Konten nur für autorisierte Personen erstellt, in definierten Häufigkeiten überprüft und deaktiviert werden, wenn Personen ausscheiden
• AC-5 (Aufgabentrennung): SoD-Regelanwendungslogs und Ausnahmedatensätze zeigen, dass konfliktbehaftete Aufgaben identifiziert und verwaltet werden
• AC-6 (Minimale Privilegien): Rollenentwicklungsdatensätze und Nicht-Nutzungsanalysen von Zertifizierungskampagnen zeigen, dass der Zugriff auf das erforderliche Minimum begrenzt ist
• IA-2 (Identifikation und Authentifizierung): CAC/PIV-Bindungsdatensätze zeigen, dass Multi-Faktor-Authentifizierung für alle Benutzerkonten auf klassifizierten Systemen durchgesetzt wird
• IA-4 (Identifier-Verwaltung): Joiner- und Leaver-Datensätze zeigen, dass Konto-Identifiers unter einem definierten Verwaltungsprozess vergeben und deaktiviert werden
• IA-5 (Authenticator-Verwaltung): Kartenbindungs- und Kartenwiderruf-Propagierungsdatensätze zeigen, dass Authenticators kontrolliert und rechtzeitig verwaltet und widerrufen werden

Compliance-Reporting von der IGA-Plattform sollte so gestaltet sein, dass es vorformatierte Nachweis-Pakete produziert, keine rohen Log-Exporte. Ein Akkreditierungsbeauftragter, der AC-2 bewerten soll, sollte einen Bericht erhalten können, der alle aktiven Konten, das Datum der letzten Überprüfung, ob welche zur Zertifizierung überfällig sind und eine Anzahl der Ausnahmen zeigt — keine 500.000-Zeilen-Ereignisprotokolle mit der Bitte, „sie selbst zu analysieren." Diese Berichte vor der ersten Akkreditierungsüberprüfung zu gestalten und zu validieren, dass sie die Kontrollimplementierung korrekt widerspiegeln, ist der Unterschied zwischen einem zweitägigen und einem zweiwöchigen Krisenprotokoll bei der Nachweiserhebung.

Die Unveränderlichkeit des Audit-Logs erfordert Write-Once-Speicher oder kryptografisches Hash-Chaining. Die Aufbewahrungsanforderungen der Verteidigung für Zugriffsprotokoll klassifizierter Systeme laufen typischerweise 3–7 Jahre, je nach Mission und Klassifizierungsstufe des Systems; einige nuklear-angrenzende und strategische Systeme haben längere Aufbewahrungsanforderungen. Die Speicherstufe muss entsprechend dimensioniert und lebenszyklusverwaltet werden, mit Abrufverfahren, die funktionieren, wenn der ursprüngliche Software-Stack nicht mehr unterstützt wird. Eine Aufbewahrungsanforderung, die am ersten Tag erfüllt wird, aber im sechsten Jahr unleserliche Logs produziert, ist ein Compliance-Versagen auf dem Zeitstrahl, der zählt.