Zugriffskontrolle in Verteidigungs-C2-Software ist keine Funktion, die am Ende der Entwicklung hinzugefügt wird. Sie ist eine grundlegende Architekturentscheidung, die bestimmt, wer welche Daten sehen kann, wer welche Befehle erteilen kann und wie diese Entscheidungen auf jeder Systemebene durchgesetzt werden — von API-Endpunkten bis zu Datenbankabfragen und WebSocket-Abonnements. Ein Fehler hier bedeutet entweder die Offenlegung von Verschlusssachen gegenüber nicht autorisierten Benutzern oder die Blockierung von Operateuren, die Situationsbewusstsein in Echtzeit benötigen.

Standardmäßige rollenbasierte Zugriffskontrolle (RBAC), wie sie in kommerziellen Identity-Providern wie Keycloak oder Azure AD implementiert ist, deckt die Rollen-zu-Berechtigungs-Zuordnung für Unternehmenssoftware ausreichend ab. Verteidigungs-C2-Systeme — ob für die Bundeswehr oder BMVg-Beschaffungsprogramme — benötigen eine zusätzliche Dimension: Geheimhaltungsgrade und Fächer. Ein Benutzer kann authentifiziert sein und die richtige Rolle innehaben, aber dennoch der Zugriff auf eine bestimmte Spur verweigert werden, weil diese Spur mit einem Geheimhaltungsgrad oder Fach versehen ist, für das der Benutzer keine Ermächtigung besitzt.

RBAC vs. ABAC: Welches Modell passt für Verteidigungs-C2

Reines RBAC weist Rollen Berechtigungen zu und Benutzern Rollen. Eine Rolle "Bataillons-S2" gewährt Zugriff auf Geheimdienstüberlagerungen; eine Rolle "Versorgungsoffizier" gewährt Zugriff auf Versorgungskettendaten. Dieses Modell ist einfach zu implementieren und zu prüfen, kann aber keine feingranularen Einschränkungen auf Datenebene ausdrücken, ohne eine Rollenexplosion zu verursachen.

Attributbasierte Zugriffskontrolle (ABAC) bewertet Zugriffsentscheidungen basierend auf Attributen des Subjekts (Benutzer), der Ressource (Datenobjekt), der Aktion und der Umgebung. In einem ABAC-Modell wird der Zugriff auf eine Spur gewährt, wenn: die Ermächtigungsstufe des Benutzers größer oder gleich der Geheimhaltungsstufe der Spur ist UND der Benutzer alle mit der Spur verbundenen Fach-Tags besitzt UND das aktuelle Terminal des Benutzers sich in einem genehmigten Netzwerksegment befindet.

In der Praxis verwenden Verteidigungs-C2-Systeme eine Hybridlösung: RBAC für grobes Rollendurchsetzen (wer auf welches Anwendungsmodul zugreifen kann) und ABAC für feingranulares Datenfiltern. In Bundeswehr-Systemen wie dem FüInfoSysH wird diese Hybridarchitektur durch die Integration mit dem militärischen Verzeichnisdienst (LDAP-Anbindung an das Bundeswehr-Active-Directory) realisiert.

Geheimhaltungsgrade und Fächer

NATO-Klassifizierungsstufen in aufsteigender Reihenfolge: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET. Die meisten taktischen C2-Systeme arbeiten auf SECRET-Ebene oder darunter. Der Geheimhaltungsgrad eines Datenobjekts ist die Mindestermächtigungsstufe, die für den Zugriff darauf erforderlich ist.

Fächer sind orthogonal zu Geheimhaltungsgraden. Ein Benutzer mit SECRET-Ermächtigung besitzt möglicherweise nicht das SIGINT- oder HUMINT-Fach, selbst auf SECRET-Ebene. Eine von einem SIGINT-Sensor abgeleitete Spur wird mit dem SIGINT-Fach getaggt; nur Benutzer mit diesem Fach sehen die Spur im Lagebild, unabhängig von ihrer Gesamtermächtigungsstufe. In Software werden Fächer als Satz von String-Tags sowohl auf dem Datensatz als auch im Attributsatz des Benutzers implementiert; Zugriff wird nur gewährt, wenn der Fachsatz des Datensatzes eine Teilmenge des Fachsatzes des Benutzers ist.

JWT-Claim-Struktur für Verteidigungs-C2

JSON Web Tokens tragen die Identität und Attributansprüche des Benutzers zwischen dem Identity-Provider und den C2-Anwendungsdiensten:

{
  "sub": "user-uuid-1234",
  "name": "Hptm. A. Müller",
  "roles": ["operator", "s2-officer"],
  "clearance": "SECRET",
  "compartments": ["SIGINT", "HUMINT"],
  "unit": "PzGrenBtl 212",
  "network_segment": "SIPRNET",
  "iat": 1746960000,
  "exp": 1746963600,
  "jti": "unique-token-id"
}

Der clearance-Claim trägt die Ermächtigungsstufe des Benutzers als String, der auf einen numerischen Wert im Richtlinienmodul abgebildet wird. Der compartments-Claim ist ein Array von Fach-Strings. Der network_segment-Claim trägt den Netzwerkkontext und ermöglicht umgebungsbasierte Zugriffsentscheidungen. Token-Gültigkeitszeiträume für Verteidigungssysteme sind kürzer als kommerzielle Normen: 60-Minuten-Zugriffstoken mit Refresh-Token-Rotation.

Richtliniendurchsetzungspunkte

In einer Mikroservice-C2-Architektur muss die Zugriffskontrolle auf mehreren Ebenen durchgesetzt werden.

API-Gateway (grobe RBAC). Validiert JWT-Signatur und -Ablauf. Lehnt Anfragen mit ungültigen Tokens ab. Trifft keine datenebenenbezogenen Zugriffsentscheidungen.

Dienstebene (ABAC-Richtlinienauswertung). Jeder Dienst, der Verschlusssachen behandelt, hat einen eingebetteten Richtlinienentscheidungspunkt. Bevor ein Datenobjekt zurückgegeben wird, bewertet der Dienst: Benutzerermächtigung >= Datengeheimhaltungsgrad UND Benutzerfächer sind Obermenge der Datenfächer. Objekte, die diese Prüfung nicht bestehen, werden aus der Antwort herausgefiltert.

Datenbankebene (Sicherheit auf Zeilenebene). PostgreSQL-Zeilenebenensicherheits-(RLS)-Richtlinien setzen Einschränkungen auf Datenebene direkt in der Datenbank durch, was Tiefenverteidigung gegen Anwendungslogikfehler bietet — eine Anforderung für Bundeswehr-C2-Systeme, die in klassifizierten Netzwerken betrieben werden.

Bell-LaPadula-Mehrstufiges Sicherheitsmodell

Das Bell-LaPadula-Modell (BLP) formalisiert die Zugriffskontrolle für klassifizierte Informationen mit zwei Hauptregeln. Die einfache Sicherheitseigenschaft (kein Lesen nach oben): ein Subjekt auf Klassifizierungsstufe L kann kein Objekt auf Stufe L' lesen, wo L' > L. Die Sterneneigenschaft (kein Schreiben nach unten): ein Subjekt auf Stufe L kann nicht in ein Objekt auf Stufe L' schreiben, wo L' < L — was das Kopieren klassifizierter Daten in einen nicht klassifizierten Datensatz verhindert.

In der Praxis ist die Keine-Schreiben-nach-unten-Regel in Web-Anwendungsarchitekturen schwieriger durchzusetzen. Die Durchsetzung erfordert, dass Schreiboperationen den Klassifizierungsgrad des Zieldatensatzes explizit auf das Maximum des Klassifizierungsgrads der Quelldaten setzen, und dass diese Logik auf der Dienstebene durchgesetzt wird.

Prüfprotokolle und SIEM-Integration

Jede Zugriffsentscheidung — sowohl Gewährungen als auch Verweigerungen — muss mit ausreichenden Details für Sicherheitsprüfungen und Incident Response protokolliert werden. Ein Prüfprotokolleintrag enthält: Zeitstempel, Benutzerkennung, Ermächtigungsstufe des Benutzers, versuchte Aktion, Ressourcenkennung, Klassifizierungsgrad der Ressource, Entscheidung (GRANT/DENY) und die Richtlinienregel, die die Entscheidung herbeigeführt hat. Prüfprotokolle werden zur Echtzeitanomalieerfassung an ein SIEM-System weitergeleitet.

Implementierungshinweis: Niemals Zugriffskontrolle nur als UI-Beschränkung implementieren. Das Ausblenden einer Schaltfläche in der Benutzeroberfläche bei gleichzeitiger Belassung des zugrundeliegenden API-Endpunkts ungeschützt ist ein häufiger Fehler in der frühen Entwicklung von Verteidigungssoftware. Jeder API-Endpunkt muss die Autorisierung des Aufrufers unabhängig überprüfen, bevor er Daten zurückgibt.