Construire un système C2 de zéro, partie 4 : interopérabilité, sécurité et déploiement

Les parties 1 à 3 ont construit une plateforme qui ingère des données capteur, fusionne des pistes et les présente aux opérateurs. La partie 4 est le travail qui distingue un prototype d'un livrable : les ponts d'interopérabilité OTAN pour que les partenaires de coalition puissent échanger des données ; le marquage de classification et l'application des marquages releasability pour que la plateforme puisse traiter des informations classifiées ; le pipeline DevSecOps qui produit des preuves d'accréditation comme effet de bord de la construction logicielle ; et les patrons de déploiement qui mettent la plateforme sur des réseaux opérationnels allant de GovCloud aux nœuds tactiques air-gappés. Après la partie 4, la plateforme est déployable opérationnellement.

Pour le cadrage architectural sur l'interopérabilité, la sécurité et l'acquisition, voir Le guide complet de l'interopérabilité OTAN et Le guide complet de la cybersécurité de défense.

Étape 1 : ponts d'interopérabilité OTAN

La plateforme d'exemple courante doit échanger des données avec les partenaires de coalition. Le périmètre au niveau brigade rend trois ponts d'interopérabilité essentiels et le reste reportable.

Pont CoT. Cursor on Target est la lingua franca tactique. La plateforme expose un pont CoT bidirectionnel : les pistes sortent en messages CoT pour les clients ATAK/WinTAK et les systèmes partenaires ; les messages CoT entrants deviennent des pistes. Le pont est un adaptateur léger au-dessus du bus de messages — il réutilise le patron d'adaptateur de la partie 2. La validation de schéma est stricte ; un CoT malformé est rejeté avec une erreur journalisée plutôt que silencieusement laissé passer. Les détails d'intégration sont dans Cursor on Target (CoT) : la norme XML derrière les applications de conscience tactique et Développement de plugins ATAK.

Mapping MIP4-IES. Pour l'échange avec les systèmes C2 nationaux au-dessus de la brigade, MIP4-IES est le schéma. Le pont est plus lourd que CoT : le mapping entre le schéma de piste canonique et les entités MIP4 est dense, versionné, et impitoyable en test de conformité. Construire le mapping comme un service distinct avec son propre banc de test aller-retour — voir MIP4-IES : la norme terrestre OTAN. Résister à la tentation d'enchâsser les concepts MIP4 dans le schéma canonique ; le schéma reste propre, le mapping porte la complexité.

Consommateur ISR STANAG 4559. Si la plateforme consomme de l'imagerie d'origine nationale, les interfaces de service NSILI 4559 sont requises. L'implémentation est bien définie ; l'effort d'ingénierie est principalement dans la gestion du magasin d'imagerie, le mapping des métadonnées vers le magasin de pistes, et la gestion de la bande passante sur les liaisons tactiques — voir Implémentation STANAG 4559.

Pour Link 16 et les liaisons de données tactiques similaires, le patron pragmatique est de s'intégrer via un terminal MIDS matériel avec une API fournisseur plutôt que d'implémenter la pile radio J-series en logiciel. Le périmètre au niveau brigade justifie rarement cet effort d'ingénierie. Voir Liaisons de données tactiques Link 16 : vue d'ingénierie.

Étape 2 : marquage de classification et releasability

Chaque objet de données produit par la plateforme porte un marquage de confidentialité. STANAG 4774 définit le format de marquage ; STANAG 4778 définit la liaison cryptographique qui empêche le détachement. Ensemble, ils sont la fondation de tout le partage de données en coalition.

L'intégration d'ingénierie :

• Classification source portée par chaque adaptateur. L'adaptateur connaît la classification de sa source et marque chaque mise à jour de piste avec.
• Classification effective calculée dans le moteur de fusion. Une piste dérivée d'un retour radar NATO SECRET et d'un compte rendu AIS UNCLASSIFIED est NATO SECRET. Une piste dérivée de sources FVEY-only et NATO-only est diffusable uniquement à l'intersection.
• Marquages releasability portés à côté de la classification — une liste de nations ou d'organisations habilitées à recevoir les données.
• Moteur de politiques qui évalue chaque requête : étant donné l'habilitation, la nationalité, le rôle de l'utilisateur, et la classification, la releasability et le compartiment des données demandées, l'accès est-il permis ? Open Policy Agent est une implémentation défendable ; le moteur est découplé de la couche applicative pour que les changements de politique n'exigent pas de release de code.
• Application à chaque couche — frontière API, requête base de données, abonnement bus de messages. Jamais uniquement à l'IHM. Le patron d'intégration RBAC est dans Contrôle d'accès basé sur les rôles dans les systèmes C2 de défense.

Le traitement d'ingénierie plus large du partage de données en coalition — y compris le patron de moteur de politiques et les anti-patrons opérationnels à éviter — est dans Défis du partage de données en coalition.

Étape 3 : pipeline DevSecOps

Le pipeline qui construit et livre la plateforme doit produire des preuves d'accréditation comme effet de bord. Rétro-adapter des preuves à un pipeline ad hoc est un projet pluriannuel ; les intégrer dès le premier jour est un sprint.

Les étapes de pipeline pour l'exemple courant :

• Hooks de gestion de sources. Signature des commits obligatoire. Les pre-commit hooks rejettent les secrets dans le code, exécutent les vérifications de lint et de format.
• Build CI. Builds reproductibles — mêmes entrées, mêmes sorties. Les artefacts de build sont content-addressed (SHA-256 du contenu comme identifiant).
• Analyse statique. Linters spécifiques au langage ; analyse statique orientée sécurité (Semgrep, CodeQL, outils spécifiques au langage). Les constats conditionnent le build, et ne sont pas seulement consultatifs.
• Scan de dépendances. Chaque dépendance directe et transitive vérifiée contre les bases CVE. Les constats déclenchent des échecs de build avec un processus d'exception documenté pour les problèmes non corrigibles.
• Génération SBOM. SBOM SPDX ou CycloneDX pour chaque artefact, publié dans un registre à côté de l'artefact. Voir SBOM dans les achats de défense.
• Durcissement des conteneurs. Images de base minimales (distroless ou scratch lorsque possible). Utilisateurs non-root. Systèmes de fichiers en lecture seule. Signature d'images avec cosign ou équivalent.
• Portes de test. Suites unitaires, d'intégration, de contrat, de performance et adversariales. Cibles de couverture appliquées ; les portes de régression de performance conditionnent la release.
• Releases signées. Chaque artefact de release signé ; la chaîne de signature ancrée dans un magasin de confiance enraciné matériel.
• Collecte de preuves. Résultats de tests, SBOMs, rapports de scan, logs de build, tous collectés et stockés contre la release. Le dossier d'accréditation est construit à partir de la collecte automatiquement.

Le patron détaillé pour adapter le DevSecOps commercial aux cycles d'accréditation est dans DevSecOps pour pipelines de défense. Le socle ISO 27001 qui le soutient est dans ISO 27001 dans le développement de logiciels de défense ; la couche de gestion qualité NATO AQAP-2110 dans NATO AQAP-2110 pour les éditeurs de logiciels.

Étape 4 : déploiement sur tout le spectre

Une plateforme C2 au niveau brigade se déploie sur un spectre d'environnements. Les mêmes artefacts doivent fonctionner dans chacun.

Cloud sécurisé. Azure Government, AWS GovCloud, équivalents. Orchestré par Kubernetes, avec des services gérés pour le bus de messages et les bases de données là où la classification le permet. Le patron est dans Architecture GovCloud pour la défense.

Réseau classifié on-premises. Cluster Kubernetes auto-hébergé sur infrastructure nationale classifiée. Le pipeline s'adapte à la cadence de mise à jour du réseau — typiquement plus lente que le cloud commercial, avec des miroirs de paquets et des portes d'approbation entre dev et prod.

Extrémité tactique. Déploiements mono-nœud ou petit cluster sur matériel durci. k3s ou systemd-nspawn plutôt que Kubernetes complet. Les contraintes de ressources et la connectivité intermittente déterminent les choix architecturaux. Le côté maillage réseau est dans MANET — Maillage réseau militaire ; le côté intégration radio dans Intégration logicielle des radios tactiques.

Déploiement air-gappé. Réseaux entièrement déconnectés. Les mises à jour arrivent via des supports de transfert contrôlés (diodes unidirectionnelles, paquets de mise à jour signés sur supports physiques). Le patron est documenté dans Déploiement air-gappé pour la défense. La discipline la plus facilement négligée : construire le format de paquet hors ligne et le flux de vérification des mises à jour dans la plateforme dès le premier jour, et non après que le premier client air-gappé en a fait la demande.

Le principe unificateur : les quatre modèles de déploiement utilisent les mêmes artefacts. Différents déploiements utilisent différentes orchestrations, différentes cadences de mise à jour, différentes topologies réseau — mais les binaires et la configuration sont les mêmes. Des binaires variants par déploiement sont une source récurrente d'échecs d'accréditation.

Étape 5 : tests, CWIX et validation opérationnelle

Une plateforme qui n'a jamais été testée avec des partenaires de coalition n'est pas interopérable, peu importe ce que disent les résultats des tests de conformité. La hiérarchie de validation :

• Tests unitaires et d'intégration dans le pipeline CI. Couvrir le schéma canonique, le parsing des adaptateurs, la justesse de fusion, les invariants de rendu du COP. Conditionner chaque release.
• Tests de conformité aux normes. Bonne forme CoT, aller-retour MIP4, échange d'imagerie STANAG 4559. Automatisés là où la norme le permet ; manuels là où elle exige des scénarios avec humain dans la boucle.
• Tests d'intégration bilatéraux avec au moins deux partenaires de coalition. Lancer tôt et souvent. Les ambiguïtés dans les normes émergent ici avant les exercices formels.
• CWIX et exercices annuels équivalents. Soumettre les cas de test pertinents. Réussir CWIX est le signal d'interopérabilité le plus fort disponible hors déploiement opérationnel.
• Validation avec opérateur dans la boucle. Vrais opérateurs utilisant la plateforme contre des scénarios réalistes. Le test qui distingue le logiciel survivable opérationnellement du logiciel de niveau démo. La discipline est dans Tester les systèmes C2 critiques.

La posture d'ingénierie plus large pour les plateformes critiques — maintenance de longue traîne, gestion de la dette technique, recrutement d'ingénieurs habilités — est dans Architecture logicielle critique, Dette technique dans les systèmes de défense, et Habilitations de sécurité pour les équipes logicielles.

Clôture de la série

Il y a quatre parties, c'était un dépôt vide. Nous avons choisi le périmètre et l'architecture, conçu le schéma de piste canonique, choisi une pile technique, construit le moteur de fusion, rendu la Common Operational Picture, et maintenant nous avons bouclé la boucle avec l'interopérabilité, la sécurité et le déploiement. La plateforme produit des pistes fiables, les affiche aux opérateurs autorisés, les échange avec les partenaires de coalition sous contrôles de classification, et se livre via un pipeline qui génère automatiquement les preuves d'accréditation.

La série est restée au niveau des décisions architecturales et des principes d'ingénierie. Les implémentations spécifiques — choix d'algorithme de fusion, choix de bibliothèque frontale, choix de bus de messages — sont défendables mais non uniques. Différents choix faits pour des raisons solides produisent des plateformes différentes mais également valides. Les décisions qui ne varient pas sont les décisions structurelles : architecture en quatre couches, schéma de piste canonique, gestion de cycle de vie, classification à chaque couche, pipeline générateur de preuves, spectre de déploiement.

Pour le cadrage architectural plus large d'une build C2 quelconque, voir le guide pilier : Le guide complet des systèmes de commandement et contrôle (C2). Pour des plongées profondes sur les couches individuelles, les articles ciblés liés tout au long de cette série. Pour le contexte d'acquisition, les piliers marché et achats : Fusion de données de défense, Interopérabilité OTAN, IA dans la défense, Cybersécurité de défense.