NATO-Interoperabilitäts-Implementierungs-Walkthrough, Teil 3: STANAG 4774/4778 Klassifikation und Koalitions-Freigabe

Die Datenlinks aus Teil 2 transportieren Nachrichten. Die Klassifikations- und Freigabe-Maschinerie entscheidet, welche Nachrichten zu wem gelangen. STANAG 4774 definiert das Format für Vertraulichkeitslabel; STANAG 4778 definiert die kryptographische Bindung, die verhindert, dass Labels von den Daten getrennt werden, die sie kennzeichnen. Zusammen bilden sie das technische Fundament des gesamten NATO-Koalitions-Datenaustauschs. Eine Plattform, die dies richtig macht, wird in klassifizierten Netzen ausgerollt; eine Plattform, die es als UI-Maske behandelt, scheitert in der ersten Prüfungsrunde der Akkreditierung. Teil 3 behandelt die Implementierungsdisziplin.

Die Säulen-Ebenen-Einordnung steht im Vollständigen Leitfaden zur NATO-Interoperabilität; die breiteren Koalitions-Sharing-Muster in Herausforderungen des Koalitions-Datenaustauschs; die RBAC-Grundlagen in Rollenbasierte Zugriffskontrolle in Verteidigungs-C2-Systemen; die fusionsseitige Propagation in Aufbau einer Verteidigungs-Fusions-Pipeline, Teil 3.

Schritt 1: Labels sind strukturierte Daten, keine Strings

Der mit Abstand häufigste Implementierungsfehler ist, Klassifikation als String-Feld zu behandeln — „SECRET", „NATO RESTRICTED" — angehängt an Datensätze. Das STANAG-4774-Modell ist reicher und strukturell anders.

Ein STANAG-4774-Vertraulichkeitslabel ist ein strukturiertes Objekt mit:

• Policy-Identifikator. Die Klassifikationspolicy, unter der das Label zugewiesen wurde (NATO, national, FVEY, EU). Eine Policy definiert die gültigen Klassifikationsebenen und Kompartimente.
• Klassifikationsebene. Ein geordneter Wert innerhalb der Policy — für NATO: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, COSMIC TOP SECRET.
• Kompartimente. Benannte Vorbehalte, die den Zugriff einschränken — operativ bedeutsam, programmspezifisch, oft selbst klassifiziert.
• Freigabe-Tags. Welche Nationen oder Organisationen die gekennzeichneten Daten empfangen dürfen — FVEY, REL TO NATO, REL TO bestimmten Nationen.
• Vorbehalte (Caveats). Zusätzliche Einschränkungen (NOFORN, ORCON, weitere je nach Policy).
• Urheber. Die erzeugende Entität, für Audit und Rechenschaft.
• Erstellungs-Zeitstempel. Wann das Label zugewiesen wurde.

Implementieren Sie dies als strukturierte Typen mit Validierung. Ein String „SECRET REL FVEY", der zur Laufzeit per String-Matching geparst wird, ist das Engineering-Muster, das die Akkreditierung nicht besteht. Strukturierte Typen, an jeder Grenze schema-validiert, sind das Muster, das besteht.

Schritt 2: Kryptographische Bindung nach STANAG 4778

STANAG 4778 definiert die kryptographische Bindung, die sicherstellt, dass ein Label nicht von den Daten getrennt werden kann, die es kennzeichnet. Die Bindung wird vom Produzenten berechnet und von jedem Konsumenten verifiziert; ohne Verifikation kann das Label entfernt, ausgetauscht oder manipuliert werden.

Das Implementierungsmuster:

Bindung am produzierenden Dienst berechnen. Wenn ein Adapter, ein Fusionsdienst oder eine andere Komponente Daten produziert, berechnet sie die Bindung über das (Label, Daten)-Tupel mit ihrem Signaturschlüssel. Der Schlüssel ist in einem hardware-verwurzelten Trust-Store verankert; die Signaturoperation wird protokolliert.

Bei jedem Lesen verifizieren. Konsumenten (das COP, nachgelagerte Analytik, externe API-Gateways) verifizieren die Bindung, bevor sie die Daten weiterleiten. Verifikationsfehler werden lautstark protokolliert und die Daten zurückgewiesen — nicht stillschweigend herabgestuft.

Bindung über Serialisierungen hinweg bewahren. Wenn Daten auf den Nachrichtenbus, in die Datenbank, über die Leitung zu einem Koalitionspartner fließen, bewegt sich die Bindung mit. Speicherformate berücksichtigen die Bindung; Kommunikationsprotokolle tragen sie. Sie aus „Bequemlichkeit" zu entfernen, ist genau die Art von Abkürzung, nach der Akkreditierungsprüfer gezielt suchen.

Per-Attribut-Bindung, wo erforderlich. Manche Datenobjekte haben Attribute auf unterschiedlichen Klassifikationsebenen. Eine Spur kann UNCLASSIFIED-Position, aber SECRET-Identität haben. STANAG 4778 erlaubt Per-Attribut-Bindung; die Plattform implementiert sie, wo das Klassifikationsmodell sie erfordert.

Schritt 3: Klassifikationspropagation durch Fusion und Ableitung

Verteidigungsplattformen erzeugen abgeleitete Daten. Eine Spur wird aus mehreren Quellbeobachtungen abgeleitet; ein Fusionsprodukt wird aus mehreren Aufklärungsberichten abgeleitet. Die Klassifikation abgeleiteter Daten wird aus der Klassifikation der Quellen berechnet — nicht unabhängig zugewiesen.

Die Propagationsregeln (Wiederholung aus der Fusionsserie und der Säule):

• Klassifikationsebene: Maximum. Eine Ableitung aus SECRET- und UNCLASSIFIED-Quellen ist SECRET.
• Kompartimente: Vereinigung. Eine Ableitung aus Kompartiment-A- und Kompartiment-B-Quellen trägt beide Kompartimente.
• Freigabe: Schnittmenge. Eine Ableitung aus FVEY-only- und NATO-only-Quellen ist nur an die Schnittmenge freigegeben.
• Vorbehalte: am restriktivsten. NOFORN auf einer beliebigen Quelle macht die Ableitung NOFORN.

Die Regeln sind mechanisch. Implementieren Sie sie als Bibliothek, die jeder Fusionsdienst, jeder Adapter und jeder Ableitungspunkt aufruft. Handgestrickte Propagation pro Dienst driftet auseinander und erzeugt Inkonsistenzen, die Akkreditierungsprüfer aufdecken. Eine gemeinsame, codegenerierte Bibliothek, die jede Komponente verwendet, ist die Disziplin, die skaliert.

Schritt 4: Die Policy-Engine

Labels auf Daten sind notwendig, aber nicht hinreichend. Zugriffsentscheidungen erfordern eine Policy-Engine, die die Freigabe, Staatsangehörigkeit und Rolle des Nutzers sowie Klassifikation, Kompartimente und Freigabe-Tags der angeforderten Daten kennt. Jede Abfrage gegen die Plattform passiert diese Engine.

Das Implementierungsmuster:

Policy als Code. Freigaberegeln in einer versionierten Policy-Sprache ausgedrückt. Open Policy Agent mit Rego ist der vertretbare Standard; Alternativen wie Cedar oder handgeschriebene DSLs existieren, bringen aber Wartungsaufwand. Policy-Änderungen laufen durch Code-Review, nicht durch Konfigurationsänderungen.

Entscheidungsauswertung an der Abfragegrenze. Wenn ein Konsument die Plattform abfragt, wertet die Policy-Engine aus, welche Datensätze sichtbar sind und welche Attribute pro Datensatz sichtbar sind. Das Ergebnis ist eine gefilterte Sicht, zur Abfragezeit berechnet. Reines UI-Filtern — die vollständigen Daten an den Client senden und sie mit CSS oder JavaScript verbergen — ist ein Common-Criteria-Verstoß und ein sofortiges Scheitern der Akkreditierung.

Per-Entscheidungs-Audit-Log. Jede Zugriffsentscheidung — Nutzer, angeforderte Daten, Klassifikation, Ergebnis — wird unveränderlich protokolliert. Das Audit-Log ist die Beweisbasis für After-Action-Review, forensische Analyse und periodische Akkreditierungsprüfung.

Performance-Budgets. Die Policy-Engine liegt auf dem kritischen Pfad des COP. Die Entscheidungslatenz muss im Submillisekunden-Bereich liegen. Caching-Strategien, vorkompilierte Policy-Bündel, Per-User-Policy-Fingerprints — alles ist relevant. Eine naive Policy-Engine ist die häufigste Ursache für COP-Langsamkeit in klassifizierten Deployments.

Per-Attribut-Entscheidungen, wo erforderlich. Die Engine wertet nicht nur aus, ob ein Datensatz sichtbar ist, sondern welche seiner Attribute. Eine Spur kann für einen Koalitionsnutzer mit freigegebener Position, aber zurückgehaltener Identität sichtbar sein.

Schritt 5: Enklavenübergreifende Datenflüsse

Verteidigungsnetze sind keine einzelnen Enklaven. Eine Plattform, die über NATO RESTRICTED, NATO SECRET und national-klassifizierte Netze hinweg operiert, muss geeignete Daten zwischen ihnen bewegen und unangemessene Flüsse verhindern.

Die Muster:

Per-Enklaven-Plattform-Instanzen. Jede klassifizierte Enklave betreibt ihre eigene Plattform-Instanz mit eigenem Datenspeicher, eigener Policy-Engine und eigenem Audit-Log. Die Instanzen sind physisch getrennt; die Plattform geht nicht davon aus, dass sie Zustand teilen.

Cross-Domain-Brücken. Wo Daten legitim zwischen Enklaven bewegt werden — UNCLASSIFIED-AIS, das in eine SECRET-Enklave hochfließt, freigabebereinigtes Produkt, das in eine Koalitions-Enklave herunterfließt — geht die Bewegung durch eine akkreditierte Cross-Domain-Lösung. Die Brücke setzt Klassifikationsregeln an der Grenze durch.

Einweg-Dioden, wo erforderlich. Für High-to-Low-Datenbewegung erzwingen Einweg-Datendioden die Richtung auf der Netzwerkebene. Die Plattform integriert sich mit Dioden-Infrastruktur, statt sie selbst zu implementieren.

Manuelle Freigabe, wo Automatisierung nicht reicht. Manche Klassifikationsentscheidungen können nicht sicher automatisiert werden. Die Per-Produkt-Freigabe von HUMINT oder kompartimentierten Daten kann menschliche Genehmigung erfordern. Die Plattform präsentiert den Kandidaten, erfasst die menschliche Entscheidung mit Attribution und propagiert die genehmigte Freigabe mit Audit.

Die detaillierte Engineering-Behandlung des Koalitions-Datenaustauschs steht in Herausforderungen des Koalitions-Datenaustauschs.

Schritt 6: Koalitionsspezifische Freigabe

Unterschiedliche Koalitionen haben unterschiedliche Freigaberegeln. Die Plattform, die über mehrere Koalitionskontexte hinweg ausgerollt werden möchte, muss berücksichtigen:

NATO-Freigabe. Der Standardsatz der NATO-Klassifikationsebenen und die Kennzeichnung REL TO NATO. Die meisten operativen Plattformen zielen zuerst auf diese Baseline.

FVEY-only. Die Five-Eyes-Aufklärungsvereinbarung (AUS, CAN, NZ, UK, US) verwendet Klassifikationspolicies, die nicht sauber auf NATO-Ebenen abbilden. Eine Plattform, die FVEY-Kontexte anvisiert, implementiert die FVEY-Policy neben NATO.

Bilaterale Vereinbarungen. Viele Plattformen haben bilaterale Datenaustausch-Vereinbarungen mit bestimmten Partnern. Ukraine, Israel, Korea, Japan haben alle programmspezifische Vereinbarungen. Die Freigabe-Engine berücksichtigt diese als spezifische REL-TO-Kennzeichnungen plus partnerspezifischen Kompartimentszugriff.

EU-Freigabe. EU-finanzierte Programme haben ihre eigene Klassifikationspolicy (EU CONFIDENTIAL, EU SECRET), die nicht auf NATO-Ebenen kollabiert. EDF-finanzierte Plattformen müssen sowohl NATO- als auch EU-Klassifikation berücksichtigen.

Die Disziplin: implementieren Sie eine Multi-Policy-Klassifikations-Engine, nicht eine einzelne Policy. Die Engine kennt NATO, FVEY, EU und bilaterale Policies als benannte Entitäten; Daten tragen die Policy, unter der sie klassifiziert wurden; die Policy-Engine wertet den Zugriff gegen die Freigabe des Nutzers unter jeder anwendbaren Policy aus.

Schritt 7: Generierung von Akkreditierungs-Nachweisen

Akkreditierungsprüfer werden der Plattform nichts davon einfach glauben. Sie werden Nachweise verlangen. Die Nachweise werden als Nebenprodukt korrekt konstruierter Klassifikations-Maschinerie erzeugt.

Die Nachweise, die Akkreditierungsprüfer als glaubwürdig ansehen:

• Code-Referenzen, die zeigen, wo Klassifikationspropagations-Regeln implementiert sind, mit Nachvollziehbarkeit von Policy zu Code.
• Audit-Log-Beispiele, die die Per-Entscheidungs-Protokollierung über das Spektrum der Zugriffsszenarien hinweg demonstrieren.
• Testergebnisse aus der automatisierten Testsuite der Plattform, die Klassifikationspropagation, Freigabe-Filterung und Bindungs-Verifikation unter adversariellen Eingaben abdeckt.
• Operative Deployment-Nachweise — Monate oder Jahre Produktionsbetrieb mit dokumentierter Incident Response, Verhinderung von Klassifikations-Spillage und bestandenen periodischen Akkreditierungsprüfungen.
• Cross-Domain-Transfer-Logs, die zeigen, dass Bewegung zwischen Enklaven gerechtfertigt, genehmigt und protokolliert war.
• Penetrationstest-Berichte aus Red-Team-Übungen, die gezielt auf die Klassifikations-Maschinerie abzielen.

Die DevSecOps-Disziplin, die diese Nachweise automatisch erzeugt, wird in DevSecOps für Verteidigungs-Pipelines behandelt. Die unterstützenden Akkreditierungsrahmen (ISO 27001, AQAP-2110, NIST) werden in ISO 27001 in der Verteidigungssoftware und NATO AQAP-2110 für Softwareanbieter behandelt.

Was als Nächstes kommt

Teil 3 hat die Klassifikations-Maschinerie implementiert. STANAG-4774-Labels als strukturierte Daten, STANAG-4778-Bindung an jeder Grenze verifiziert, Propagation durch Fusion und Ableitung, die Policy-Engine, die die Freigabe zur Abfragezeit durchsetzt, enklavenübergreifende Flüsse berücksichtigt, Multi-Koalitions-Freigabe unterstützt, Nachweisgenerierung eingebaut.

Teil 4 schließt die Serie mit den Validierungs- und Beschaffungsdisziplinen ab: Konformitätstests, CWIX-Vorbereitung, der Akkreditierungspfad und die Long-Tail-Wartungsdisziplin, die die Plattform über mehrjährige operative Lebenszeiten hinweg einsatzfähig hält.