Een cross-domeinoplossing (CDS) is een hardware- en softwaresysteem dat gecontroleerde overdracht van gegevens mogelijk maakt tussen netwerken die op verschillende beveiligingsclassificatieniveaus opereren — bijvoorbeeld van een SECRET operationeel netwerk naar een UNCLASSIFIED coalitionsportaal, of van een UNCLASSIFIED sensorfeed naar een SECRET commando-en-controlesysteem. Zonder een CDS moeten deze twee netwerken volledig geïsoleerd blijven: er kunnen überhaupt geen gegevens tussen hen stromen. Met een CDS kunnen zorgvuldig gedefinieerde overdrachten plaatsvinden onder strikte beleidshandhaving, waardoor geclassificeerde inlichtingen tactische beslissingen op UNCLASSIFIED-niveau kunnen ondersteunen en UNCLASSIFIED-gegevens geclassificeerde analyses kunnen voeden zonder het netwerk met hogere classificatie bloot te stellen aan compromis.
CDS-technologie bevindt zich op het snijvlak van beleid, engineering en nationale veiligheidswetgeving. Het correct selecteren, implementeren en integreren van een CDS is een van de meest ingrijpende architecturale beslissingen in een geclassificeerd defensie-softwareprogramma. Een slecht gespecificeerde of onjuist geïntegreerde CDS is ofwel te restrictief — waarbij operationeel noodzakelijke gegevensstromen worden geblokkeerd en de missie-effectiviteit vermindert — ofwel te permissief, waardoor een gecontroleerd pad wordt gecreëerd waarlangs gevoelige informatie naar netwerken met een lagere classificatie kan lekken. Dit artikel behandelt de architectuur, accreditatie en integratiepatronen die beveiligingsarchitecten en defensie-CIO's nodig hebben om de juiste beslissingen te nemen.
Waarom cross-domeinoverdrachten operationeel noodzakelijk zijn
De operationele noodzaak voor cross-domein gegevensoverdracht vloeit voort uit de fundamentele spanning in defensie-informatiebeheer: de meest waardevolle inlichtingen zijn vaak sterk geclassificeerd, maar het personeel en de systemen die er op moeten handelen, opereren vaak op lagere classificatieniveaus of in coalitieomgevingen waar het delen van gegevens over nationale classificatiegrenzen heen vereist is.
Inlichtingen-naar-operaties downgrade is de klassieke CDS-toepassing. Een SECRET inlichtingenproduct — een dreigingsbeoordeling, een doelpakket, een rapport over de beschikking van strijdkrachten — moet worden gesaneerd en vrijgegeven aan een UNCLASSIFIED of coalitieknetwerk zodat tactische commandanten en strijdkrachten van partnerlanden erop kunnen handelen. Zonder een CDS vereist dit proces handmatige menselijke controle en handmatige herinvoer van de gedegradeerde informatie, wat traag, foutgevoelig is en niet schaalt met het volume van moderne informatieoperaties.
Aggregatie van sensorgegevens over classificatieniveaus heen drijft de omgekeerde stroom. Ongerubriceerde open-source inlichtingen (OSINT), commercieel beschikbare satellietbeelden en sensorfeeds van partnerlanden moeten worden opgenomen in SECRET of hoger geclassificeerde analyseomgevingen voor fusie met geclassificeerde gegevens. Een CDS biedt het gecontroleerde opnamepad: ongerubriceerde gegevens betreden de hoger geclassificeerde omgeving via de guard, waar ze kunnen worden gecombineerd met geclassificeerde gegevens die het high-side netwerk nooit verlaten.
Coalitieoperaties creëren cross-domeinvereisten over nationale classificatiegrenzen heen. NATO's REL (Releasable) markeringen en het Mission Secret classificatieniveau definiëren welke informatie kan worden gedeeld met specifieke partnerlanden, maar het technische mechanisme voor het handhaven van die deelregels op de netwerklaag vereist een CDS die het gegevensdelingsbeleid van de coalitie begrijpt en handhaaft.
Kerngedachte: De vraag naar cross-domeinoplossingen wordt niet primair gedreven door een wens om netwerken te verbinden — het wordt gedreven door de operationele kosten van het volledig gescheiden houden ervan. Elk handmatig downgradeproces, elk vertraagd inlichtingenproduct, elke analist die geen volledig beeld heeft omdat hij of zij niet de juiste machtiging heeft, vertegenwoordigt een verlies aan missie-effectiviteit dat CDS-technologie is ontworpen om te verminderen.
CDS-architectuurpatronen
CDS-producten implementeren een van de verschillende architectuurpatronen, elk geschikt voor verschillende gegevensstroomvereisten en zekerheidsniveaus.
Datadiodes zijn de eenvoudigste en meest zekere CDS-architectuur. Een datadiode is een hardwareapparaat dat eenrichtingsgegevensstroom fysiek afdwingt met behulp van optische isolatie: een zender aan de high side stuurt gegevens via een glasvezelverbinding naar een ontvanger aan de low side, waarbij geen retourpad fysiek mogelijk is. Omdat er geen retourkanaal is, kan het high-side netwerk geen enkele informatie ontvangen van het low-side netwerk — zelfs geen TCP-bevestigingspakketten. Datadiodes worden gebruikt waar de zekerheid van absolute eenrichtingsstroom belangrijker is dan protocolefficiëntie. Ze vereisen protocolaanpassing (doorgaans op UDP gebaseerde datapompen) om het gebrek aan TCP-bevestiging te omzeilen, en ze voeren geen inhoudsinspectie uit — ze sturen alle gegevens in de opgegeven richting door. Veelvoorkomende toepassingen zijn eenrichtingslogexport van geclassificeerde systemen naar SIEM-platforms, eenrichtingssensorgegevensfeeds naar geclassificeerde netwerken en eenrichtingsrelease van vooraf goedgekeurde bulkgegevens.
Hoog-naar-laag guards zijn bidirectionele apparaten die inhoudsgebaseerd beveiligingsbeleid afdwingen voor gegevens die stromen van een hoger geclassificeerd netwerk naar een lager geclassificeerd netwerk. De guard ontvangt een overdrachtsverzoek van de high side, inspecteert de inhoud aan de hand van het gedefinieerde beveiligingsbeleid en — als de inhoud alle inspecties doorstaat — stuurt de goedgekeurde inhoud door naar de low side. De guard registreert zowel goedgekeurde overdrachten als geblokkeerde overdrachten voor auditdoeleinden. Hoog-naar-laag guards worden gebruikt voor gecontroleerde declassificatie: het vrijgeven van inlichtingenproducten, rapporten of databaserecords van een geclassificeerd netwerk naar een ongerubriceerd of coalitieknetwerk. De inspectie-engine onderzoekt inhoud op classificatiemarkering, gevoelige sleutelwoorden, ingesloten metadata en kwaadaardige inhoud voordat overdracht wordt goedgekeurd.
Bilaterale guards ondersteunen gecontroleerde gegevensuitwisseling in beide richtingen over een classificatiegrens heen. Gegevens die van hoog naar laag stromen, worden geïnspecteerd op naleving van het classificatiebeleid en kwaadaardige inhoud. Gegevens die van laag naar hoog stromen, worden geïnspecteerd op malware, formaatconformiteit en niet-toegestane inhoudstypen. Bilaterale guards worden gebruikt waar operationele werkstromen beide richtingen vereisen: opdrachtberichten die stromen van ongerubriceerde commando-en-controlesystemen naar geclassificeerde sensor- of wapennetwerken, met statusrapporten die terugstromen. Bilaterale guards hebben een groter aanvalsoppervlak dan datadiodes en vereisen een striktere accreditatie, maar ze ondersteunen het volledige scala aan operationele werkstromen.
Op filters gebaseerde guards met inhoudsinspectie implementeren gestructureerde analyse van elk overdrachtsverzoek aan de hand van een formeel beveiligingsbeleid. De inhoudsinspectiepijplijn omvat doorgaans: bestandstypevalidatie (whitelisting van goedgekeurde formaten), schemavalidatie voor gestructureerde gegevens (XML, JSON gecontroleerd aan de hand van goedgekeurde schema's), malwarescanning (AV en sandboxing voor bestanden), metadatastripping (verwijdering van bestandsmetadata die classificatiemarkering of auteursgegevens kunnen bevatten) en — voor hoog-zekerheid hoog-naar-laag overdrachten — semantische inhoudinspectie die tekst analyseert op classificatiemarkering en gevoelige sleutelwoorden.
Kerngedachte: Inhoudsinspectie in een CDS is geen eenvoudige malwarescan — het is een meerlaagse beleidshandhavingspijplijn. Voor hoog-naar-laag overdrachten op SECRET en hoger moet de inspectie in staat zijn classificatiemarkering te detecteren die is ingebed in documenttekst, metadata en zelfs afbeeldingsinhoud. Het correct opstellen van de beleidsspecificatie vereist nauwe samenwerking tussen de beveiligingsarchitect, de informatie-eigenaar en de accrediterende autoriteit, ruim voordat de CDS wordt ingezet.
Accreditatiekaders: UCDMO, NSA en NATO
CDS-producten die worden gebruikt op Amerikaanse nationale veiligheidssystemen moeten worden vermeld op de Unified Cross Domain Management Office (UCDMO) Baseline — de gezaghebbende lijst van door NSA geëvalueerde en goedgekeurde CDS-producten. De UCDMO-basislijn wordt bijgehouden door het National Cross Domain Strategy and Management Office (NCDSMO) van de NSA en is beschikbaar voor geclassificeerde programmabureau's via geclassificeerde kanalen. Een product bereikt de basislijn via het evaluatieproces van de NSA, dat de beveiligingsarchitectuur, de implementatie en de operationele procedures beoordeelt aan de hand van de vereisten van het toepasselijke beveiligingsprofiel.
Het evaluatieproces voor een nieuw CDS-product duurt doorgaans 18–36 maanden. Voor programmabureau's is de praktische implicatie duidelijk: ontwerp uw cross-domeinarchitectuur rond producten die al op de UCDMO-basislijn staan. Proberen een nieuw, niet-geëvalueerd product in uw programma te introduceren, zal uw accreditatietijdlijn met jaren vertragen.
Zelfs bij gebruik van een in de basislijn opgenomen product vereist het inzetten ervan in een specifieke omgeving een locatieaccreditatie. Het locatieaccreditatiepakket documenteert de specifieke configuratie van de CDS, het inhoudsinspatiebeleid dat van kracht is voor elke goedgekeurde gegevensstroom, de integratie met het omringende systeem en de operationele procedures voor het beheren en bewaken van de CDS. De accrediterende autoriteit beoordeelt dit pakket en verleent een Authority to Operate (ATO) voor die specifieke implementatie. Locatieaccreditaties duren doorgaans 3–9 maanden, afhankelijk van de complexiteit van de integratie en de werkdruk van de accrediterende autoriteit.
NATO-accreditatie wordt beheerd via het NATO Communications and Information Agency (NCI Agency) en nationale autoriteiten voor communicatiebeveiliging. NATO CDS-producten worden geëvalueerd aan de hand van NATO-specifieke beveiligingsprofielen en vermeld in het NATO-equivalent van de UCDMO-basislijn. Producten die zijn goedgekeurd voor Amerikaanse nationale veiligheidssystemen worden niet automatisch goedgekeurd voor NATO-gebruik — een afzonderlijke evaluatie en vermelding is vereist, hoewel leveranciers doorgaans beide parallel nastreven.
EU-geclassificeerde informatiesystemen worden geregeld door de EU Classified Information (EUCI)-beveiligingsregels, waarbij accreditatie wordt beheerd door het Veiligheidscomité van de Raad en nationale veiligheidsaccreditatie-autoriteiten. CDS-producten die worden gebruikt in EU-geclassificeerde omgevingen moeten worden goedgekeurd onder het EU-kader, opnieuw via een apart evaluatieproces.
CDS-productcategorieën en het leverancierslandschap
De commerciële CDS-markt wordt bediend door een klein aantal leveranciers die hebben geïnvesteerd in het jarenlange NSA-evaluatieproces. In plaats van specifieke producten aan te bevelen, is het voor architecten nuttiger om de productcategorieën en de te evalueren mogelijkheden te begrijpen.
Guards op netwerkniveau opereren op de IP/TCP-laag en zijn geïntegreerd in de netwerkinfrastructuur tussen de twee netwerken met classificatieniveaus. Ze bieden protocolfiltering, IP-filtering en basale inhoudsinspectie. Ze zijn geschikt voor bulkgegevensoverdrachten waarbij de vereisten voor inhoudsinspectie relatief eenvoudig zijn (bestandstype en malwarescanning) en latentie minder kritiek is.
Guards op toepassingsniveau opereren op de applicatieprotocollaag — e-mail, bestandsoverdracht, webservices — en integreren met specifieke applicatieprotocollen. E-mailguards inspecteren e-mailberichten en bijlagen conform het beveiligingsbeleid; bestandsoverdrachtsguards inspecteren individuele bestanden aan de hand van goedgekeurde schema's en bestandstyperegels; webserviceguards fungeren als API-proxy's die verzoek- en antwoordpayloads inspecteren. Guards op toepassingsniveau bieden rijkere inhoudsinspectiemogelijkheden dan guards op netwerkniveau, maar vereisen integratie met de specifieke applicaties aan elke kant van de grens.
Streamingguards verwerken real-time datastromen — video, telemetrie, sensorgegevens — en zijn geoptimaliseerd voor overdracht met lage latentie en hoge doorvoer met formaatvalidatie en inhoudsfiltering die geschikt is voor het streamtype. Videoguards kunnen bijvoorbeeld ingebedde metadata uit videostreams strippen, codecbeperkingen opleggen en scannen op steganografische inhoud.
Leveranciers die actief zijn op de geaccrediteerde CDS-markt omvatten bedrijven gericht op datadiodehardware (doorgaans voor de vereisten met de hoogste zekerheid in één richting) en bedrijven die bredere guardfamilies aanbieden die e-mail, bestandsoverdracht en webserviceoverdrachten bestrijken. Elke leverancier die CDS-mogelijkheden voor gebruik in nationale veiligheidssystemen claimt, moet kunnen verwijzen naar zijn UCDMO-basislijnvermelding of actieve evaluatiestatus — als ze dat niet kunnen, is het product niet geschikt voor geclassificeerde implementaties, ongeacht zijn technische mogelijkheden.
Integratiepatronen voor defensiesoftware
Defensiesoftwarearchitecten moeten hun applicaties ontwerpen om samen te werken met een bestaande of geplande CDS. De CDS wordt doorgaans apart van de applicatiesoftware aangeschaft en beheerd — uw applicatie beheert de CDS niet; ze dient gegevens in bij de CDS en ontvangt goedgekeurde gegevens ervan. Het integratiepatroon moet worden gekozen zodat het aansluit bij de ondersteunde interfaces van het CDS-product en de vereisten voor gegevensstromen.
API-proxypatroon: De high-side applicatie stuurt gegevens naar een door CDS beheerd API-eindpunt (doorgaans REST of SOAP). De CDS inspecteert de payload en stuurt deze, indien goedgekeurd, door naar het corresponderende low-side eindpunt. De applicatie ontvangt een synchrone respons die aangeeft of een overdracht is goedgekeurd of afgewezen. Dit patroon is geschikt voor overdrachten met laag volume en latenties die toleranter zijn, waarbij de applicatie onmiddellijke feedback nodig heeft over of een overdracht is goedgekeurd.
Berichtenwachtrijpatroon: De high-side applicatie publiceert berichten naar een berichtenwachtrij (JMS, AMQP of een eigen CDS-wachtrij). De CDS verbruikt berichten uit de wachtrij, inspecteert elk bericht en herpubliceert goedgekeurde berichten naar een low-side wachtrij waar de ontvangende applicatie ze verbruikt. Geweigerde berichten worden gelogd en er wordt een melding gegenereerd. Dit patroon is geschikt voor asynchroon overdrachten met hoger volume waarbij het loskoppelen van producerende en consumerende applicaties wenselijk is. De applicatie moet omgaan met het geval dat een bericht wordt geweigerd en niet aan de overzijde wordt afgeleverd.
E-mailgatewaypatroon: De high-side applicatie genereert e-mailberichten met gestructureerde bijlagen (PDF-rapporten, XML-gegevensbestanden) en verzendt ze via de CDS e-mailrelay. De CDS fungeert als een MTA die het bericht en de bijlagen inspecteert voordat ze worden doorgestuurd naar de low-side mailserver. Dit patroon is het meest voorkomend voor door mensen geïnitieerde gegevensreleases — een analist stelt een rapport op, voegt een PDF bij en verzendt het naar een distributielijst op het low-side netwerk. De CDS stript metadata uit de PDF, scant op classificatiemarkering en levert het gesanitiseerde bericht af als het de inspectie doorstaat.
Ongeacht het integratiepatroon moet applicatiecode CDS-afwijzing op een correcte manier afhandelen. Overdrachten kunnen worden geweigerd om beleidsredenen (inhoud bevat een classificatiemarkering die niet mag worden vrijgegeven), technische redenen (misvormde XML, onverwacht bestandstype) of tijdelijke redenen (CDS tijdelijk niet beschikbaar). De applicatie moet expliciet gedrag definiëren voor elk geval: melding aan de operator, quarantainewachtrij, logica voor opnieuw proberen en auditlogging van elke overdrachtspoging en -uitkomst.
Kerngedachte: Ontwerp uw applicatie om de CDS te behandelen als een onbetrouwbare, beleidshandhavende tussenpersoon — niet als een transparante netwerkverbinding. Elke overdrachtspoging moet worden gelogd, elke afwijzing moet een melding aan de operator genereren, en de applicatie mag nooit stilzwijgend gegevens verwijderen die de CDS heeft geblokkeerd. Het auditspoor van CDS-interacties is zelf een beveiligingsrelevant artefact dat accrediterende autoriteiten zullen beoordelen.
Hoe u een CDS-vereiste specificeert voor een nieuw defensiesysteem
Het vroegtijdig specificeren van een CDS-vereiste in een programma voorkomt de kostbare architecturale herontwerpwerkzaamheden die het gevolg zijn van het behandelen van cross-domeinoverdracht als een bijzaak. Het specificatieproces moet een formeel Cross-Domain Transfer Requirements document opleveren dat deel uitmaakt van de beveiligingsvereistenbasislijn van het systeem.
Stap 1 — Identificeer alle cross-domein gegevensstromen. Breng elke gegevensstroom in het systeem in kaart die een classificatiegrens overschrijdt. Documenteer voor elke stroom: bron- en doelclassificatieniveaus, gegevenstype en -formaat, overdrachtsrichting, volume- en latentievereisten en de operationele behoefte die de stroom ondersteunt. Deze inventaris is de basis voor alle vervolgbeslissingen.
Stap 2 — Bepaal het toepasselijke accreditatiekader. Stel vast of het programma US UCDMO, NATO, EU-ACC of een nationaal kader zal gebruiken. Dit bepaalt welke productlijsten gezaghebbend zijn en welke accrediterende autoriteit het locatieaccreditatiepakket moet goedkeuren. Neem vroegtijdig contact op met de accrediterende autoriteit — hun input over aanvaardbare architecturen kan maanden van herziening besparen.
Stap 3 — Selecteer de CDS-architectuur. Pas de architectuur (datadiode, hoog-naar-laag guard, bilaterale guard) aan op de kenmerken van de gegevensstroom. Geef de voorkeur aan eenvoudigere architecturen waar operationeel haalbaar — een datadiode die aan de vereiste voldoet, heeft de voorkeur boven een bilaterale guard die onnodige complexiteit en aanvalsoppervlak introduceert.
Stap 4 — Definieer het inhoudsinspatiebeleid. Specificeer voor elke goedgekeurde gegevensstroom de exacte inspectieregels: toegestane bestandstypen, maximale bestandsgrootte, schemadefinities voor gestructureerde gegevens, vereisten voor malwarescanning en afhandelingsregels voor mislukte inspectie. Het beleidsdocument is een formeel op te leveren resultaat dat als onderdeel van het accreditatiepakket moet worden goedgekeurd.
Stap 5 — Ontwerp de integratie-interface. Kies het integratiepatroon en ontwerp de applicatie-interfaces naar de CDS. Zorg ervoor dat de applicatie afwijzing op een correcte manier afhandelt en alle overdrechtspogingen logt.
Stap 6 — Bouw en test tegen een representatieve CDS-instantie. Verkrijg een testeenheid bij de leverancier en bouw geautomatiseerde integratietests die betrekking hebben op: goedgekeurde gegevens die er doorheen gaan, geweigerde gegevens die worden geblokkeerd, afhandeling van misvormde gegevens en CDS-faalwijzen.
Stap 7 — Stel het locatieaccreditatiepakket op. Compileer de accreditatiedocumentatie en dien in bij de accrediterende autoriteit ruim voor de geplande operationele datum. Plan voor 3–9 maanden beoordelingstijd.
Voor programma's waarbij een CDS-vereiste laat wordt geïdentificeerd — nadat de applicatiearchitectuur al is gedefinieerd — is het integratiewerk complexer, maar gelden dezelfde principes. Neem vroegtijdig contact op met het integratieteam van de CDS-leverancier: zij hebben ervaring met het aanpassen van hun product aan verschillende applicatiearchitecturen en kunnen het integratiepad met de minste wrijving voor uw specifieke situatie identificeren. Voor richtlijnen over hoe CDS-integratie past in een bredere beveiligde cloudarchitectuur, zie ons artikel over zero-trust-architectuur voor militaire netwerken en hoe air-gapped implementatiepatronen CDS-gecontroleerde overdrachtsroutes aanvullen. Voor het beheer van geheimen en sleutels dat elke CDS-implementatie moet vergezellen, zie beheer van geheimen in defensie CI/CD-pijplijnen.