Une solution interdomaine (CDS) est un système matériel et logiciel qui permet le transfert contrôlé de données entre des réseaux opérant à différents niveaux de classification de sécurité — par exemple, d'un réseau opérationnel SECRET vers un portail de coalition NON CLASSIFIÉ, ou d'un flux de capteurs NON CLASSIFIÉ vers un système de commandement et de contrôle SECRET. Sans CDS, ces deux réseaux doivent rester complètement isolés : aucune donnée ne peut circuler entre eux. Avec un CDS, des transferts soigneusement définis peuvent avoir lieu sous l'application stricte d'une politique, permettant au renseignement classifié d'éclairer les décisions tactiques non classifiées, et aux données non classifiées d'alimenter les analyses classifiées sans exposer le réseau de classification supérieure à une compromission.
La technologie CDS se situe à l'intersection de la politique, de l'ingénierie et du droit de la sécurité nationale. Sélectionner, déployer et intégrer correctement un CDS est l'une des décisions architecturales les plus déterminantes dans un programme de logiciel de défense classifié. Un CDS mal spécifié ou incorrectement intégré est soit trop restrictif — bloquant les flux de données opérationnellement nécessaires et dégradant l'efficacité de la mission — soit trop permissif, créant un chemin contrôlé par lequel des informations sensibles peuvent fuir vers des réseaux de classification inférieure. Cet article couvre les architectures, l'accréditation et les schémas d'intégration dont les architectes de sécurité et les DSI de la défense ont besoin pour naviguer dans cette décision.
Pourquoi les transferts interdomaines sont opérationnellement nécessaires
L'impératif opérationnel du transfert de données interdomaines découle de la tension fondamentale dans la gestion de l'information de défense : le renseignement le plus précieux est souvent hautement classifié, mais le personnel et les systèmes qui doivent agir sur cette base opèrent fréquemment à des niveaux de classification inférieurs ou au sein d'environnements de coalition où le partage de données à travers les frontières nationales de classification est requis.
La rétrogradation du renseignement vers les opérations est le cas d'usage classique du CDS. Un produit de renseignement SECRET — une évaluation des menaces, un ensemble de ciblage, un rapport de disposition des forces — doit être sanitisé et diffusé vers un réseau NON CLASSIFIÉ ou de coalition afin que les commandants tactiques et les forces de nations partenaires puissent agir dessus. Sans CDS, ce processus nécessite une révision humaine manuelle et une ressaisie manuelle des informations rétrogradées, ce qui est lent, source d'erreurs et ne peut pas s'adapter au volume des opérations d'information modernes.
L'agrégation de données de capteurs entre les niveaux de classification génère le flux inverse. Le renseignement en source ouverte (OSINT) non classifié, l'imagerie satellitaire disponible commercialement et les flux de capteurs des nations partenaires doivent être intégrés dans des environnements analytiques classifiés SECRET ou plus pour la fusion avec des données classifiées. Un CDS fournit le chemin d'ingestion contrôlé : les données non classifiées entrent dans l'environnement de classification supérieure via le garde, où elles peuvent être combinées avec des données classifiées qui ne quittent jamais le réseau côté haut.
Les opérations de coalition créent des exigences interdomaines à travers les frontières nationales de classification. Les marquages REL (Releasable) de NATO et le niveau de classification Mission Secret définissent quelles informations peuvent être partagées avec des nations partenaires spécifiques, mais le mécanisme technique pour appliquer ces règles de partage au niveau de la couche réseau nécessite un CDS qui comprend et applique les politiques de partage de données de la coalition.
Idée clé : La demande de solutions interdomaines n'est pas principalement motivée par le désir de connecter des réseaux — elle est motivée par le coût opérationnel de leur séparation totale. Chaque processus de rétrogradation manuel, chaque produit de renseignement retardé, chaque analyste qui ne peut pas accéder à la vue d'ensemble parce qu'il ne dispose pas du niveau d'habilitation approprié représente une perte d'efficacité de mission que la technologie CDS est conçue pour réduire.
Schémas d'architecture CDS
Les produits CDS mettent en œuvre l'un de plusieurs schémas architecturaux, chacun approprié à différentes exigences de flux de données et niveaux d'assurance.
Les diodes de données sont l'architecture CDS la plus simple et la plus sûre. Une diode de données est un dispositif matériel qui impose physiquement un flux de données unidirectionnel par isolation optique : un émetteur côté haut envoie des données via une liaison à fibre optique vers un récepteur côté bas, sans chemin de retour physiquement possible. Comme il n'y a pas de canal de retour, le réseau côté haut ne peut recevoir aucune information du réseau côté bas — pas même les paquets d'accusé de réception TCP. Les diodes de données sont utilisées lorsque l'assurance d'un flux strictement unidirectionnel est plus importante que l'efficacité du protocole. Elles nécessitent une adaptation de protocole (typiquement des pompes de données basées sur UDP) pour contourner l'absence d'accusé de réception TCP, et elles n'effectuent pas d'inspection du contenu — elles transmettent toutes les données dans la direction spécifiée. Les cas d'usage courants incluent l'exportation unidirectionnelle de journaux de systèmes classifiés vers des plateformes SIEM, les flux de données de capteurs unidirectionnels vers des réseaux classifiés, et la diffusion unidirectionnelle de données en vrac pré-approuvées.
Les gardes haut-vers-bas sont des dispositifs bidirectionnels qui appliquent une politique de sécurité basée sur le contenu pour les données circulant d'un réseau de classification supérieure vers un réseau de classification inférieure. Le garde reçoit une demande de transfert du côté haut, inspecte le contenu selon la politique de sécurité définie et — si le contenu passe toutes les vérifications d'inspection — transmet le contenu approuvé au côté bas. Le garde journalise à la fois les transferts approuvés et les transferts bloqués à des fins d'audit. Les gardes haut-vers-bas sont utilisés pour la déclassification contrôlée : diffusion de produits de renseignement, de rapports ou d'enregistrements de bases de données d'un réseau classifié vers un réseau non classifié ou de coalition. Le moteur d'inspection examine le contenu pour les marquages de classification, les mots-clés sensibles, les métadonnées incorporées et le contenu malveillant avant d'approuver le transfert.
Les gardes bilatéraux prennent en charge l'échange de données contrôlé dans les deux directions à travers une frontière de classification. Les données circulant du haut vers le bas sont inspectées pour la conformité à la politique de classification et pour le contenu malveillant. Les données circulant du bas vers le haut sont inspectées pour les logiciels malveillants, la conformité de format et les types de contenu non autorisés. Les gardes bilatéraux sont utilisés lorsque les flux de travail opérationnels nécessitent les deux directions : messages de commande circulant de systèmes de commandement et de contrôle non classifiés vers des réseaux de capteurs ou d'armement classifiés, avec des rapports d'état retournant dans l'autre sens. Les gardes bilatéraux ont une surface d'attaque plus grande que les diodes de données et nécessitent une accréditation plus rigoureuse, mais ils prennent en charge l'ensemble des flux de travail opérationnels.
Les gardes à filtrage avec inspection du contenu mettent en œuvre une analyse structurée de chaque demande de transfert selon une politique de sécurité formelle. Le pipeline d'inspection du contenu comprend généralement : la validation du type de fichier (liste blanche des formats approuvés), la validation de schéma pour les données structurées (XML, JSON vérifié contre des schémas approuvés), l'analyse antivirus (AV et bac à sable pour les fichiers), la suppression des métadonnées (retrait des métadonnées de fichier pouvant contenir des marqueurs de classification ou des informations d'auteur), et — pour les transferts haut-vers-bas à haute assurance — l'inspection sémantique du contenu qui analyse le texte pour les marquages de classification et les mots-clés sensibles.
Idée clé : L'inspection du contenu dans un CDS n'est pas une simple analyse antivirus — c'est un pipeline d'application de politiques à plusieurs couches. Pour les transferts haut-vers-bas au niveau SECRET et au-dessus, l'inspection doit être capable de détecter les marquages de classification intégrés dans le texte des documents, les métadonnées et même le contenu des images. Bien définir la politique nécessite une collaboration étroite entre l'architecte de sécurité, le propriétaire de l'information et l'autorité d'accréditation bien avant le déploiement du CDS.
Cadres d'accréditation : UCDMO, NSA et NATO
Les produits CDS utilisés sur les systèmes de sécurité nationale américains doivent figurer sur la liste de référence du Bureau unifié de gestion interdomaines (UCDMO) — la liste faisant autorité des produits CDS évalués et approuvés par la NSA. La liste de référence UCDMO est maintenue par le Bureau national de stratégie et de gestion interdomaines (NCDSMO) de la NSA et est accessible aux bureaux de programme habilités via des canaux classifiés. Un produit rejoint la liste de référence via le processus d'évaluation de la NSA, qui évalue l'architecture de sécurité, la mise en œuvre et les procédures opérationnelles par rapport aux exigences du profil de protection applicable.
Le processus d'évaluation pour un nouveau produit CDS prend généralement 18 à 36 mois. Pour les bureaux de programme, l'implication pratique est claire : concevez votre architecture interdomaine autour de produits déjà inscrits sur la liste de référence UCDMO. Tenter d'introduire un nouveau produit non évalué dans votre programme retardera votre calendrier d'accréditation de plusieurs années.
Même en utilisant un produit inscrit sur la liste, son déploiement dans un environnement spécifique nécessite une accréditation du site. Le dossier d'accréditation du site documente la configuration spécifique du CDS, la politique d'inspection du contenu en vigueur pour chaque flux de données approuvé, l'intégration avec le système environnant et les procédures opérationnelles de gestion et de surveillance du CDS. L'autorité d'accréditation examine ce dossier et accorde une Autorisation d'exploitation (ATO) pour ce déploiement spécifique. Les accréditations de site prennent généralement 3 à 9 mois selon la complexité de l'intégration et la charge de travail de l'autorité d'accréditation.
L'accréditation NATO est gérée par l'Agence des communications et de l'information de l'OTAN (Agence NCI) et les autorités nationales de sécurité des communications. Les produits CDS NATO sont évalués selon des profils de protection spécifiques à l'OTAN et inscrits dans l'équivalent NATO de la liste de référence UCDMO. Les produits approuvés pour les systèmes de sécurité nationale américains ne sont pas automatiquement approuvés pour une utilisation NATO — une évaluation et une inscription séparées sont requises, bien que les fournisseurs les poursuivent généralement en parallèle.
Les systèmes d'information classifiés de l'UE sont régis par les règles de sécurité des informations classifiées de l'UE (EUCI), avec une accréditation gérée par le Comité de sécurité du Conseil et les Autorités nationales d'accréditation de sécurité. Les produits CDS utilisés dans les environnements classifiés UE doivent être approuvés dans le cadre du système UE, là encore via un processus d'évaluation séparé.
Catégories de produits CDS et paysage des fournisseurs
Le marché commercial des CDS est desservi par un petit nombre de fournisseurs ayant investi dans le processus d'évaluation NSA qui dure des années. Plutôt que d'approuver des produits spécifiques, il est plus utile pour les architectes de comprendre les catégories de produits et les capacités à évaluer.
Les gardes de niveau réseau opèrent au niveau de la couche IP/TCP et sont intégrés dans l'infrastructure réseau entre les deux réseaux de niveaux de classification. Ils fournissent un filtrage de protocole, un filtrage IP et une inspection de contenu de base. Ils conviennent aux transferts de données en vrac où les exigences d'inspection du contenu sont relativement simples (type de fichier et analyse antivirus) et la latence est moins critique.
Les gardes de niveau applicatif opèrent au niveau de la couche de protocole applicatif — e-mail, transfert de fichiers, services web — et s'intègrent à des protocoles d'application spécifiques. Les gardes e-mail inspectent les messages et les pièces jointes selon la politique de sécurité ; les gardes de transfert de fichiers inspectent les fichiers individuels selon des schémas approuvés et des règles de type de fichier ; les gardes de services web agissent comme des proxys API qui inspectent les charges utiles des requêtes et des réponses. Les gardes de niveau applicatif offrent des capacités d'inspection du contenu plus riches que les gardes de niveau réseau, mais nécessitent une intégration avec les applications spécifiques de chaque côté de la frontière.
Les gardes de streaming gèrent les flux de données en temps réel — vidéo, télémétrie, données de capteurs — et sont optimisés pour les transferts à faible latence et à haut débit avec validation de format et filtrage de contenu appropriés au type de flux. Les gardes vidéo, par exemple, peuvent supprimer les métadonnées incorporées des flux vidéo, imposer des restrictions de codec et analyser le contenu stéganographique.
Les fournisseurs actifs sur le marché des CDS accrédités comprennent des entreprises spécialisées dans le matériel de diodes de données (généralement pour les exigences unidirectionnelles à la plus haute assurance) et des entreprises proposant des familles de produits gardes plus larges couvrant les transferts par e-mail, transfert de fichiers et services web. Tout fournisseur revendiquant des capacités CDS pour une utilisation sur les systèmes de sécurité nationale devrait être en mesure de pointer vers son inscription sur la liste de référence UCDMO ou son statut d'évaluation en cours — dans le cas contraire, le produit ne convient pas aux déploiements classifiés, quelles que soient ses capacités techniques.
Schémas d'intégration pour les logiciels de défense
Les architectes de logiciels de défense doivent concevoir leurs applications pour interopérer avec un CDS existant ou planifié. Le CDS est généralement acquis et géré séparément du logiciel d'application — votre application ne contrôle pas le CDS ; elle lui soumet des données et reçoit de lui les données approuvées. Le schéma d'intégration doit être choisi pour correspondre aux interfaces prises en charge par le produit CDS et aux exigences du flux de données.
Schéma de proxy API : L'application côté haut envoie des données à un point de terminaison API géré par le CDS (généralement REST ou SOAP). Le CDS inspecte la charge utile et, si elle est approuvée, la transfère au point de terminaison côté bas correspondant. L'application reçoit une réponse synchrone indiquant l'approbation ou le rejet. Ce schéma convient aux transferts à faible volume et tolérants à la latence où l'application a besoin d'un retour immédiat sur l'approbation ou non d'un transfert.
Schéma de file de messages : L'application côté haut publie des messages dans une file de messages (JMS, AMQP, ou une file propriétaire CDS). Le CDS consomme les messages depuis la file, inspecte chacun d'eux et republie les messages approuvés dans une file côté bas où l'application réceptrice les consomme. Les messages rejetés sont journalisés et une alerte est générée. Ce schéma convient aux transferts asynchrones à volume plus élevé où le découplage des applications productrices et consommatrices est souhaitable. L'application doit gérer le cas où un message est rejeté et non livré à l'autre bout.
Schéma de passerelle e-mail : L'application côté haut génère des messages e-mail avec des pièces jointes structurées (rapports PDF, fichiers de données XML) et les envoie via le relais e-mail CDS. Le CDS agit comme un MTA qui inspecte le message et les pièces jointes avant de les transmettre au serveur de messagerie côté bas. Ce schéma est le plus courant pour les diffusions de données initiées par des humains — un analyste rédige un rapport, joint un PDF et l'envoie à une liste de distribution sur le réseau côté bas. Le CDS supprime les métadonnées du PDF, analyse les marquages de classification et livre le message sanitisé s'il passe l'inspection.
Quel que soit le schéma d'intégration, le code d'application doit gérer les rejets du CDS correctement. Les transferts peuvent être rejetés pour des raisons de politique (le contenu contient un marquage de classification qui ne devrait pas être diffusé), des raisons techniques (XML malformé, type de fichier inattendu) ou des raisons transitoires (CDS temporairement indisponible). L'application doit définir un comportement explicite pour chaque cas : notification de l'opérateur, file de quarantaine, logique de réessai et journalisation d'audit de chaque tentative de transfert et de son résultat.
Idée clé : Concevez votre application pour traiter le CDS comme un intermédiaire peu fiable appliquant des politiques — pas comme une connexion réseau transparente. Chaque tentative de transfert doit être journalisée, chaque rejet doit générer une notification pour l'opérateur, et l'application ne doit jamais supprimer silencieusement des données que le CDS a bloquées. La piste d'audit des interactions CDS est elle-même un artefact pertinent pour la sécurité que les autorités d'accréditation examineront.
Comment définir les exigences d'un CDS pour un nouveau système de défense
Définir les exigences d'un CDS tôt dans un programme évite la refonte architecturale coûteuse en fin de projet qui résulte du traitement du transfert interdomaine comme un afterthought. Le processus de définition doit produire un document formel d'exigences de transfert interdomaine qui devient partie intégrante de la ligne de base des exigences de sécurité du système.
Étape 1 — Identifier tous les flux de données interdomaines. Cartographiez chaque flux de données du système qui franchit une frontière de classification. Pour chaque flux, documentez : les niveaux de classification source et destination, le type et le format des données, la direction du transfert, les exigences de volume et de latence, et le besoin opérationnel que le flux sert. Cet inventaire est le fondement de toutes les décisions ultérieures.
Étape 2 — Déterminer le cadre d'accréditation applicable. Identifiez si le programme utilisera UCDMO américain, NATO, EU-ACC ou un cadre national. Cela détermine quelles listes de produits font autorité et quelle autorité d'accréditation doit approuver le dossier d'accréditation du site. Engagez l'autorité d'accréditation tôt — ses contributions sur les architectures acceptables peuvent faire économiser des mois de refonte.
Étape 3 — Sélectionner l'architecture CDS. Adaptez l'architecture (diode de données, garde haut-vers-bas, garde bilatéral) aux caractéristiques du flux de données. Privilégiez les architectures plus simples lorsque c'est opérationnellement faisable — une diode de données qui répond à l'exigence est préférable à un garde bilatéral qui introduit une complexité et une surface d'attaque inutiles.
Étape 4 — Définir la politique d'inspection du contenu. Pour chaque flux de données approuvé, spécifiez les règles d'inspection exactes : types de fichiers autorisés, taille maximale de fichier, définitions de schémas pour les données structurées, exigences d'analyse antivirus et règles de traitement en cas d'échec d'inspection. Le document de politique est un livrable formel qui doit être approuvé dans le cadre du dossier d'accréditation.
Étape 5 — Concevoir l'interface d'intégration. Choisissez le schéma d'intégration et concevez les interfaces d'application vers le CDS. Assurez-vous que l'application gère les rejets correctement et journalise toutes les tentatives de transfert.
Étape 6 — Construire et tester contre une instance CDS représentative. Obtenez une unité de test auprès du fournisseur et créez des tests d'intégration automatisés couvrant : les données approuvées passant correctement, les données rejetées étant bloquées, la gestion des données malformées et les modes de défaillance du CDS.
Étape 7 — Préparer le dossier d'accréditation du site. Compilez la documentation d'accréditation et soumettez-la à l'autorité d'accréditation bien avant la date opérationnelle prévue. Prévoyez 3 à 9 mois de délai de révision.
Pour les programmes où une exigence CDS est identifiée tardivement — après que l'architecture d'application est déjà définie — le travail d'intégration est plus complexe mais les mêmes principes s'appliquent. Engagez l'équipe d'intégration du fournisseur CDS tôt : elle a l'expérience de l'adaptation de son produit à différentes architectures d'application et peut identifier le chemin d'intégration à moindre friction pour votre situation spécifique. Pour des conseils sur la façon dont l'intégration CDS s'inscrit dans une architecture cloud sécurisée plus large, consultez notre article sur l'architecture zéro-confiance pour les réseaux militaires et sur la façon dont les schémas de déploiement air-gap complètent les chemins de transfert contrôlés par CDS. Pour la gestion des secrets et des clés qui doit accompagner tout déploiement CDS, consultez la gestion des secrets dans les pipelines CI/CD de défense.