Eine Cross-Domain-Lösung (CDS) ist ein Hardware- und Softwaresystem, das den kontrollierten Transfer von Daten zwischen Netzwerken ermöglicht, die auf unterschiedlichen Sicherheits-Geheimhaltungsstufen betrieben werden — zum Beispiel von einem operativen SECRET-Netzwerk zu einem UNCLASSIFIED-Koalitionsportal oder von einem UNCLASSIFIED-Sensorfeed zu einem SECRET-Führungs- und Kontrollsystem. Ohne eine CDS müssen diese beiden Netzwerke vollständig isoliert bleiben: Es können keinerlei Daten zwischen ihnen fließen. Mit einer CDS können sorgfältig definierte Transfers unter strenger Richtliniendurchsetzung stattfinden, sodass klassifizierte Geheimdienstinformationen unkritische taktische Entscheidungen informieren und unkritische Daten klassifizierte Analysen speisen können, ohne das Netzwerk mit höherer Geheimhaltungsstufe zu gefährden.

CDS-Technologie befindet sich an der Schnittstelle von Richtlinien, Engineering und nationalem Sicherheitsrecht. Die korrekte Auswahl, Bereitstellung und Integration einer CDS ist eine der folgenreichsten Architekturentscheidungen in einem klassifizierten Verteidigungssoftwareprogramm. Eine schlecht spezifizierte oder unsachgemäß integrierte CDS ist entweder zu restriktiv — sie blockiert operativ notwendige Datenflüsse und beeinträchtigt die Missionswirksamkeit — oder zu permissiv und schafft einen kontrollierten Pfad, durch den sensible Informationen in Netzwerke niedrigerer Geheimhaltungsstufe gelangen können. Dieser Artikel behandelt die Architektur, Akkreditierung und Integrationsmuster, die Sicherheitsarchitekten und Verteidigungs-CIOs für diese Entscheidung kennen müssen.

Warum bereichsübergreifende Transfers operativ notwendig sind

Der operative Bedarf nach bereichsübergreifendem Datentransfer ergibt sich aus der grundlegenden Spannung im militärischen Informationsmanagement: Die wertvollsten Geheimdienstinformationen sind häufig hoch klassifiziert, aber das Personal und die Systeme, die darauf reagieren müssen, operieren oft auf niedrigeren Geheimhaltungsstufen oder in Koalitionsumgebungen, in denen der Datenaustausch über nationale Klassifikationsgrenzen hinweg erforderlich ist.

Herabstufung von Geheimdienstinformationen für den operativen Einsatz ist der klassische CDS-Anwendungsfall. Ein SECRET-Geheimdienstprodukt — eine Bedrohungsbeurteilung, ein Zielpaket, ein Kräftedispositionsbericht — muss bereinigt und für ein UNCLASSIFIED- oder Koalitionsnetzwerk freigegeben werden, damit taktische Kommandeure und Partnernationskräfte darauf reagieren können. Ohne eine CDS erfordert dieser Prozess manuelle menschliche Überprüfung und manuelle Neueingabe der herabgestuften Informationen, was langsam, fehleranfällig und nicht skalierbar für das Volumen moderner Informationsoperationen ist.

Sensor-Datenaggregation über Geheimhaltungsstufen hinweg treibt den umgekehrten Fluss an. Unkritische Open-Source-Geheimdienstinformationen (OSINT), kommerziell verfügbare Satellitenbilder und Sensordaten von Partnernationen müssen in SECRET- oder höher klassifizierte Analyseumgebungen für die Fusion mit klassifizierten Daten aufgenommen werden. Eine CDS stellt den kontrollierten Aufnahmeweg bereit: Unkritische Daten gelangen durch den Guard in die höher klassifizierte Umgebung, wo sie mit klassifizierten Daten kombiniert werden können, die das High-Side-Netzwerk nie verlassen.

Koalitionsoperationen schaffen bereichsübergreifende Anforderungen über nationale Klassifikationsgrenzen hinweg. Die REL-Kennzeichnungen (Releasable) der NATO und die Mission-Secret-Klassifikationsstufe definieren, welche Informationen mit bestimmten Partnernationen geteilt werden können, aber der technische Mechanismus zur Durchsetzung dieser Freigaberegeln auf Netzwerkebene erfordert eine CDS, die die Datenaustauschrichtlinien der Koalition versteht und durchsetzt.

Wichtige Erkenntnis: Der Bedarf nach Cross-Domain-Lösungen wird nicht primär durch den Wunsch angetrieben, Netzwerke zu verbinden — er wird durch die operativen Kosten ihrer vollständigen Trennung angetrieben. Jeder manuelle Herabstufungsprozess, jedes verzögerte Geheimdienstprodukt, jeder Analyst, der keinen Zugang zum vollständigen Lagebild hat, weil ihm die richtige Freigabe fehlt, stellt einen Verlust an Missionswirksamkeit dar, den CDS-Technologie reduzieren soll.

CDS-Architekturmuster

CDS-Produkte implementieren eines von mehreren Architekturmustern, die jeweils für unterschiedliche Datenflusseigenschaften und Sicherheitsniveaus geeignet sind.

Datendioden sind die einfachste und sicherste CDS-Architektur. Eine Datendioide ist ein Hardwaregerät, das mithilfe optischer Isolation einen einseitigen Datenfluss physisch erzwingt: Ein Sender auf der High-Side überträgt Daten über eine Glasfaserverbindung an einen Empfänger auf der Low-Side, ohne dass ein Rückkanal physisch möglich ist. Da kein Rückkanal vorhanden ist, kann das High-Side-Netzwerk keinerlei Informationen vom Low-Side-Netzwerk empfangen — nicht einmal TCP-Bestätigungspakete. Datendioden werden dort eingesetzt, wo die Sicherheit eines absolut einseitigen Flusses wichtiger ist als Protokolleffizienz. Sie erfordern Protokolladaptierungen (typischerweise UDP-basierte Datenpumpen), um das Fehlen von TCP-Bestätigungen zu umgehen, und führen keine Inhaltsprüfung durch — sie leiten alle Daten in der angegebenen Richtung weiter. Häufige Anwendungsfälle sind der einseitige Log-Export von klassifizierten Systemen zu SIEM-Plattformen, einseitige Sensordatenfeeds in klassifizierte Netzwerke und die einseitige Freigabe vorab genehmigter Massendaten.

High-to-Low-Guards sind bidirektionale Geräte, die eine inhaltsbasierte Sicherheitsrichtlinie für Daten durchsetzen, die von einem höher klassifizierten Netzwerk zu einem niedriger klassifizierten fließen. Der Guard empfängt eine Transferanfrage von der High-Side, prüft den Inhalt gegen die definierte Sicherheitsrichtlinie und leitet — wenn der Inhalt alle Prüfungen besteht — den genehmigten Inhalt an die Low-Side weiter. Der Guard protokolliert sowohl genehmigte als auch blockierte Transfers zur Überprüfung. High-to-Low-Guards werden für kontrollierte Deklassifizierung eingesetzt: Freigabe von Geheimdienstprodukten, Berichten oder Datenbankeinträgen aus einem klassifizierten Netzwerk in ein unkritisches oder Koalitionsnetzwerk. Die Inspektions-Engine prüft Inhalte auf Klassifizierungskennzeichnungen, sensible Schlüsselwörter, eingebettete Metadaten und böswillige Inhalte, bevor sie einen Transfer genehmigt.

Bilaterale Guards unterstützen den kontrollierten Datenaustausch in beide Richtungen über eine Klassifizierungsgrenze hinweg. Daten, die von High-to-Low fließen, werden auf Einhaltung der Klassifizierungsrichtlinien und auf böswillige Inhalte geprüft. Daten, die von Low-to-High fließen, werden auf Malware, Formatkonformität und nicht autorisierte Inhaltstypen geprüft. Bilaterale Guards werden dort eingesetzt, wo operative Workflows beide Richtungen erfordern: Befehlsnachrichten, die von unkritischen Führungs- und Kontrollsystemen in klassifizierte Sensor- oder Waffennetzwerke fließen, mit Statusberichten, die zurückfließen. Bilaterale Guards haben eine größere Angriffsfläche als Datendioden und erfordern eine strengere Akkreditierung, unterstützen aber das gesamte Spektrum operativer Workflows.

Filter-basierte Guards mit Inhaltsprüfung implementieren eine strukturierte Analyse jeder Transferanfrage gegen eine formale Sicherheitsrichtlinie. Die Inhaltsprüfungs-Pipeline umfasst typischerweise: Dateityp-Validierung (Whitelisting genehmigter Formate), Schema-Validierung für strukturierte Daten (XML, JSON gegen genehmigte Schemata geprüft), Malware-Scan (AV und Sandboxing für Dateien), Metadaten-Bereinigung (Entfernen von Dateimetadaten, die Klassifizierungsmarkierungen oder Autorenangaben enthalten können), und — für High-Assurance-High-to-Low-Transfers — semantische Inhaltsprüfung, die Text auf Klassifizierungsmarkierungen und sensible Schlüsselwörter analysiert.

Wichtige Erkenntnis: Die Inhaltsprüfung in einer CDS ist kein einfacher Malware-Scan — sie ist eine mehrschichtige Richtliniendurchsetzungs-Pipeline. Bei High-to-Low-Transfers auf SECRET-Ebene und darüber muss die Prüfung in der Lage sein, Klassifizierungsmarkierungen zu erkennen, die in Dokumenttext, Metadaten und sogar Bildinhalt eingebettet sind. Die korrekte Spezifikation der Richtlinien erfordert eine enge Zusammenarbeit zwischen dem Sicherheitsarchitekten, dem Informationseigentümer und der Akkreditierungsbehörde lange vor dem Einsatz der CDS.

Akkreditierungsrahmen: UCDMO, NSA und NATO

CDS-Produkte, die auf US-amerikanischen nationalen Sicherheitssystemen eingesetzt werden, müssen in der Unified Cross Domain Management Office (UCDMO) Baseline aufgeführt sein — der maßgeblichen Liste der von der NSA bewerteten und genehmigten CDS-Produkte. Die UCDMO-Baseline wird vom National Cross Domain Strategy and Management Office (NCDSMO) der NSA gepflegt und ist für zugelassene Programmbüros über klassifizierte Kanäle zugänglich. Ein Produkt gelangt durch das Bewertungsverfahren der NSA in die Baseline, das die Sicherheitsarchitektur, die Implementierung und die betrieblichen Verfahren gegen die Anforderungen des jeweiligen Schutzprofils bewertet.

Das Bewertungsverfahren für ein neues CDS-Produkt dauert typischerweise 18–36 Monate. Für Programmbüros ist die praktische Konsequenz klar: Entwerfen Sie Ihre bereichsübergreifende Architektur rund um Produkte, die bereits in der UCDMO-Baseline enthalten sind. Der Versuch, ein neues, noch nicht bewertetes Produkt in Ihr Programm einzuführen, wird Ihren Akkreditierungszeitplan um Jahre verzögern.

Selbst bei der Verwendung eines in der Baseline enthaltenen Produkts ist für dessen Einsatz in einer konkreten Umgebung eine Standortakkreditierung erforderlich. Das Standortakkreditierungspaket dokumentiert die spezifische Konfiguration der CDS, die für jeden genehmigten Datenfluss geltende Inhaltsprüfungsrichtlinie, die Integration mit dem umgebenden System und die betrieblichen Verfahren zur Verwaltung und Überwachung der CDS. Die Akkreditierungsbehörde prüft dieses Paket und erteilt eine Betriebsgenehmigung (Authority to Operate, ATO) für diese spezifische Bereitstellung. Standortakkreditierungen dauern je nach Komplexität der Integration und Arbeitsbelastung der Akkreditierungsbehörde typischerweise 3–9 Monate.

NATO-Akkreditierung wird durch die NATO Communications and Information Agency (NCI Agency) und nationale Kommunikationssicherheitsbehörden verwaltet. NATO-CDS-Produkte werden gegen NATO-spezifische Schutzprofile bewertet und in der NATO-Entsprechung der UCDMO-Baseline aufgeführt. Produkte, die für US-nationale Sicherheitssysteme zugelassen sind, sind nicht automatisch für den NATO-Einsatz genehmigt — eine separate Bewertung und Auflistung ist erforderlich, wobei Anbieter typischerweise beide parallel anstreben.

EU-Verschlusssachen-Informationssysteme werden durch die EU-EUCI-Sicherheitsregeln (EU Classified Information) geregelt, mit Akkreditierung durch den Rat-Sicherheitsausschuss und nationale Sicherheits-Akkreditierungsbehörden. CDS-Produkte in EU-klassifizierten Umgebungen müssen nach dem EU-Rahmen zugelassen sein, wiederum durch ein separates Bewertungsverfahren.

CDS-Produktkategorien und Anbieter

Der kommerzielle CDS-Markt wird von einer kleinen Anzahl von Anbietern bedient, die in das jahrelange NSA-Bewertungsverfahren investiert haben. Anstatt spezifische Produkte zu empfehlen, ist es für Architekten sinnvoller, die Produktkategorien und die zu bewertenden Fähigkeiten zu verstehen.

Netzwerkseitige Guards arbeiten auf der IP/TCP-Ebene und sind in die Netzwerkinfrastruktur zwischen den zwei Netzwerken unterschiedlicher Geheimhaltungsstufen integriert. Sie bieten Protokollfilterung, IP-Filterung und grundlegende Inhaltsprüfung. Sie eignen sich für Massendatentransfers, bei denen die Anforderungen an die Inhaltsprüfung relativ einfach sind (Dateityp und Malware-Scan) und Latenz weniger kritisch ist.

Anwendungsseitige Guards arbeiten auf der Anwendungsprotokoll-Ebene — E-Mail, Dateitransfer, Webdienste — und integrieren sich in spezifische Anwendungsprotokolle. E-Mail-Guards prüfen E-Mail-Nachrichten und Anhänge gemäß der Sicherheitsrichtlinie; Dateitransfer-Guards prüfen einzelne Dateien gegen genehmigte Schemata und Dateityp-Regeln; Webdienst-Guards fungieren als API-Proxys, die Anfrage- und Antwortpayloads prüfen. Anwendungsseitige Guards bieten reichhaltigere Inhaltsprüfungsfähigkeiten als netzwerkseitige Guards, erfordern aber eine Integration mit den spezifischen Anwendungen auf jeder Seite der Grenze.

Streaming-Guards verarbeiten Echtzeit-Datenströme — Video, Telemetrie, Sensordaten — und sind für latenzarmen, hochdurchsatzfähigen Transfer mit Formatvalidierung und Inhaltsfilterung optimiert, die dem Streamtyp entspricht. Video-Guards können beispielsweise eingebettete Metadaten aus Videostreams entfernen, Codec-Einschränkungen durchsetzen und auf steganografische Inhalte scannen.

Anbieter, die auf dem akkreditierten CDS-Markt aktiv sind, umfassen Unternehmen, die auf Datendioide-Hardware spezialisiert sind (typischerweise für die höchsten High-Assurance-Einwegübertragungsanforderungen), sowie Unternehmen, die breitere Guard-Produktfamilien anbieten, die E-Mail-, Dateitransfer- und Webdienstetransfers abdecken. Jeder Anbieter, der CDS-Fähigkeiten für den Einsatz in nationalen Sicherheitssystemen beansprucht, sollte in der Lage sein, auf seine UCDMO-Baseline-Listung oder seinen aktiven Bewertungsstatus zu verweisen — andernfalls ist das Produkt ungeachtet seiner technischen Fähigkeiten nicht für klassifizierte Einsätze geeignet.

Integrationsmuster für Verteidigungssoftware

Architekten von Verteidigungssoftware müssen ihre Anwendungen so entwerfen, dass sie mit einer bestehenden oder geplanten CDS interoperieren. Die CDS wird typischerweise getrennt von der Anwendungssoftware beschafft und verwaltet — Ihre Anwendung kontrolliert die CDS nicht; sie übermittelt Daten an sie und empfängt von ihr genehmigte Daten. Das Integrationsmuster muss so gewählt werden, dass es zu den unterstützten Schnittstellen des CDS-Produkts und den Datenflusseigenschaften passt.

API-Proxy-Muster: Die High-Side-Anwendung sendet Daten an einen CDS-verwalteten API-Endpunkt (typischerweise REST oder SOAP). Die CDS prüft die Payload und leitet sie, wenn genehmigt, an den entsprechenden Low-Side-Endpunkt weiter. Die Anwendung erhält eine synchrone Antwort, die angibt, ob ein Transfer genehmigt oder abgelehnt wurde. Dieses Muster eignet sich für Transfers mit geringem Volumen und tolerabler Latenz, bei denen die Anwendung unmittelbares Feedback benötigt, ob ein Transfer genehmigt wurde.

Message-Queue-Muster: Die High-Side-Anwendung veröffentlicht Nachrichten in einer Message-Queue (JMS, AMQP oder eine proprietäre CDS-Queue). Die CDS konsumiert Nachrichten aus der Queue, prüft jede einzelne und veröffentlicht genehmigte Nachrichten erneut in einer Low-Side-Queue, aus der die empfangende Anwendung sie konsumiert. Abgelehnte Nachrichten werden protokolliert und ein Alarm wird ausgelöst. Dieses Muster eignet sich für Transfers mit höherem Volumen und asynchronem Betrieb, bei denen eine Entkopplung der produzierenden und konsumierenden Anwendungen wünschenswert ist. Die Anwendung muss den Fall behandeln, dass eine Nachricht abgelehnt und nicht auf der Gegenseite zugestellt wird.

E-Mail-Gateway-Muster: Die High-Side-Anwendung erzeugt E-Mail-Nachrichten mit strukturierten Anhängen (PDF-Berichte, XML-Datendateien) und sendet sie über das CDS-E-Mail-Relay. Die CDS fungiert als MTA, der die Nachricht und Anhänge vor der Weiterleitung an den Low-Side-Mailserver prüft. Dieses Muster ist das häufigste für vom Menschen initiierte Datenfreigaben — ein Analyst verfasst einen Bericht, fügt eine PDF an und sendet sie an eine Verteilerliste im Low-Side-Netzwerk. Die CDS entfernt Metadaten aus der PDF, scannt auf Klassifizierungsmarkierungen und leitet die bereinigten Nachrichten weiter, wenn sie die Prüfung bestehen.

Unabhängig vom Integrationsmuster muss der Anwendungscode CDS-Ablehnungen ordnungsgemäß behandeln. Transfers können aus Richtliniengründen abgelehnt werden (Inhalt enthält eine Klassifizierungsmarkierung, die nicht freigegeben werden sollte), aus technischen Gründen (fehlerhaftes XML, unerwarteter Dateityp) oder aus vorübergehenden Gründen (CDS vorübergehend nicht verfügbar). Die Anwendung sollte für jeden Fall ein explizites Verhalten definieren: Operator-Benachrichtigung, Quarantäne-Queue, Wiederholungslogik und Prüfprotokollierung jedes Transferversuchs und -ergebnisses.

Wichtige Erkenntnis: Entwerfen Sie Ihre Anwendung so, dass sie die CDS als unzuverlässigen, richtliniendurchsetzenden Vermittler behandelt — nicht als transparente Netzwerkverbindung. Jeder Transferversuch sollte protokolliert werden, jede Ablehnung sollte eine Operator-Benachrichtigung erzeugen, und die Anwendung sollte niemals stillschweigend Daten verwerfen, die die CDS blockiert hat. Der Prüfpfad der CDS-Interaktionen ist selbst ein sicherheitsrelevantes Artefakt, das Akkreditierungsbehörden überprüfen werden.

So spezifizieren Sie eine CDS-Anforderung für ein neues Verteidigungssystem

Die frühzeitige Spezifizierung einer CDS-Anforderung vermeidet die kostspielige Architekturüberarbeitung in späten Phasen, die entsteht, wenn bereichsübergreifende Transfers als Nachgedanke behandelt werden. Der Spezifikationsprozess sollte ein formales Cross-Domain-Transfer-Anforderungsdokument produzieren, das Teil der Sicherheitsanforderungs-Baseline des Systems wird.

Schritt 1 — Alle bereichsübergreifenden Datenflüsse identifizieren. Kartieren Sie jeden Datenfluss im System, der eine Klassifizierungsgrenze überschreitet. Dokumentieren Sie für jeden Fluss: Quell- und Ziel-Geheimhaltungsstufen, Datentyp und -format, Übertragungsrichtung, Volumen- und Latenzanforderungen sowie den operativen Bedarf, den der Fluss unterstützt. Dieses Inventar ist die Grundlage für alle nachfolgenden Entscheidungen.

Schritt 2 — Den anwendbaren Akkreditierungsrahmen bestimmen. Ermitteln Sie, ob das Programm US-UCDMO, NATO, EU-ACC oder einen nationalen Rahmen verwenden wird. Dies bestimmt, welche Produktlisten maßgeblich sind und welche Akkreditierungsbehörde das Standortakkreditierungspaket genehmigen muss. Engagieren Sie die Akkreditierungsbehörde frühzeitig — ihre Rückmeldungen zu akzeptablen Architekturen können Monate an Überarbeitungen einsparen.

Schritt 3 — Die CDS-Architektur auswählen. Passen Sie die Architektur (Datendioide, High-to-Low-Guard, bilateraler Guard) an die Datenflusskennzeichen an. Bevorzugen Sie einfachere Architekturen, wo operativ möglich — eine Datendioide, die die Anforderung erfüllt, ist einem bilateralen Guard vorzuziehen, der unnötige Komplexität und Angriffsfläche einführt.

Schritt 4 — Die Inhaltsprüfungsrichtlinie definieren. Spezifizieren Sie für jeden genehmigten Datenfluss die genauen Prüfregeln: zulässige Dateitypen, maximale Dateigröße, Schemadefinitionen für strukturierte Daten, Anforderungen an den Malware-Scan und Handhabungsregeln für fehlgeschlagene Prüfungen. Das Richtliniendokument ist ein formales Lieferobjekt, das als Teil des Akkreditierungspakets genehmigt werden muss.

Schritt 5 — Die Integrationsschnittstelle entwerfen. Wählen Sie das Integrationsmuster und entwerfen Sie die Anwendungsschnittstellen zur CDS. Stellen Sie sicher, dass die Anwendung Ablehnungen ordnungsgemäß behandelt und alle Transferversuche protokolliert.

Schritt 6 — Gegen eine repräsentative CDS-Instanz bauen und testen. Beschaffen Sie eine Testeinheit vom Anbieter und erstellen Sie automatisierte Integrationstests, die Folgendes abdecken: genehmigte Daten, die durchgeleitet werden, abgelehnte Daten, die blockiert werden, Behandlung fehlerhafter Daten und CDS-Fehlermodi.

Schritt 7 — Das Standortakkreditierungspaket vorbereiten. Stellen Sie die Akkreditierungsdokumentation zusammen und reichen Sie sie bei der Akkreditierungsbehörde rechtzeitig vor dem geplanten Betriebsdatum ein. Planen Sie 3–9 Monate Prüfzeit ein.

Bei Programmen, bei denen eine CDS-Anforderung spät identifiziert wird — nachdem die Anwendungsarchitektur bereits definiert ist — ist die Integrationsarbeit komplexer, aber die gleichen Prinzipien gelten. Engagieren Sie das Integrationsteam des CDS-Anbieters frühzeitig: Es verfügt über Erfahrung bei der Anpassung des Produkts an unterschiedliche Anwendungsarchitekturen und kann den reibungsärmsten Integrationspfad für Ihre spezifische Situation identifizieren. Hinweise dazu, wie CDS-Integration in eine breitere sichere Cloud-Architektur passt, finden Sie in unserem Artikel über Zero-Trust-Architektur für militärische Netzwerke und darüber, wie Air-Gap-Deployment-Muster CDS-kontrollierte Transferpfade ergänzen. Informationen zum Secrets- und Key-Management, das jede CDS-Bereitstellung begleiten muss, finden Sie unter Secrets-Management in Verteidigungs-CI/CD-Pipelines.