Parcours d'implémentation de l'interopérabilité OTAN, partie 3 : classification STANAG 4774/4778 et diffusion en coalition

Les liaisons de données de la partie 2 transportent les messages. La machinerie de classification et de diffusion décide à qui ces messages sont transmis. STANAG 4774 définit le format des étiquettes de confidentialité ; STANAG 4778 définit la liaison cryptographique qui empêche de détacher les étiquettes des données qu'elles marquent. Ensemble, ils sont la fondation technique de tout le partage de données en coalition OTAN. Une plateforme qui les implémente correctement se déploie sur les réseaux classifiés ; une plateforme qui les traite comme un masque d'IHM échoue à l'accréditation dès le premier cycle de revue. La partie 3 couvre la discipline d'implémentation.

Le cadrage au niveau pilier se trouve dans Le guide complet de l'interopérabilité OTAN ; les patrons plus larges de partage en coalition dans Défis du partage de données en coalition ; les fondations RBAC dans Contrôle d'accès basé sur les rôles dans les systèmes C2 de défense ; la propagation côté fusion dans Construire un pipeline de fusion de défense, partie 3.

Étape 1 : les étiquettes sont des données structurées, pas des chaînes

L'échec d'implémentation le plus courant consiste à traiter la classification comme un champ chaîne de caractères — « SECRET », « NATO RESTRICTED » — attaché aux enregistrements. Le modèle STANAG 4774 est plus riche et structurellement différent.

Une étiquette de confidentialité STANAG 4774 est un objet structuré comportant :

• Identifiant de politique. La politique de classification sous laquelle l'étiquette a été attribuée (OTAN, nationale, FVEY, UE). Une politique définit les niveaux de classification et compartiments valides.
• Niveau de classification. Une valeur ordonnée au sein de la politique — pour l'OTAN : UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, COSMIC TOP SECRET.
• Compartiments. Caveats nommés restreignant l'accès — opérationnellement significatifs, spécifiques à un programme, souvent eux-mêmes classifiés.
• Marquages de diffusion. Quelles nations ou organisations peuvent recevoir les données étiquetées — FVEY, REL TO NATO, REL TO nations spécifiques.
• Caveats. Restrictions supplémentaires (NOFORN, ORCON, autres selon la politique).
• Émetteur. L'entité productrice, pour l'audit et la responsabilité.
• Horodatage de création. Quand l'étiquette a été attribuée.

Implémenter ces éléments comme types structurés avec validation. Une chaîne « SECRET REL FVEY » analysée à l'exécution par recherche de motifs est le patron d'ingénierie qui échoue à l'accréditation. Les types structurés, validés par schéma à chaque frontière, sont le patron qui passe.

Étape 2 : liaison cryptographique STANAG 4778

STANAG 4778 définit la liaison cryptographique qui garantit qu'une étiquette ne peut pas être détachée des données qu'elle marque. La liaison est calculée par le producteur et vérifiée par chaque consommateur ; sans vérification, l'étiquette peut être retirée, échangée ou altérée.

Le patron d'implémentation :

Calculer la liaison au service producteur. Lorsqu'un adaptateur, un service de fusion ou un autre composant produit des données, il calcule la liaison sur le tuple (étiquette, données) avec sa clé de signature. La clé est ancrée dans un magasin de confiance enraciné matériellement ; l'opération de signature est journalisée.

Vérifier à chaque lecture. Les consommateurs (le COP, l'analytique en aval, les passerelles d'API externes) vérifient la liaison avant de propager les données. Les échecs de vérification sont journalisés bruyamment et les données sont rejetées — pas silencieusement déclassées.

Préserver la liaison à travers les sérialisations. Lorsque les données circulent sur le bus de messages, vers la base de données, sur le réseau vers un partenaire de coalition, la liaison les accompagne. Les formats de stockage l'accommodent ; les protocoles de communication la transportent. Le retirer pour « commodité » est exactement le genre de raccourci que les évaluateurs d'accréditation cherchent spécifiquement.

Liaison par attribut là où c'est requis. Certains objets de données ont des attributs à des classifications différentes. Une piste peut avoir une position UNCLASSIFIED mais une identité SECRET. STANAG 4778 accommode la liaison par attribut ; la plateforme l'implémente là où le modèle de classification l'exige.

Étape 3 : propagation de classification à travers la fusion et la dérivation

Les plateformes de défense produisent des données dérivées. Une piste est dérivée de multiples observations source ; un produit fusionné est dérivé de multiples comptes rendus de renseignement. La classification des données dérivées est calculée à partir de la classification des sources — non attribuée indépendamment.

Les règles de propagation de classification (rappel de la série fusion et du pilier) :

• Niveau de classification : maximum. Une dérivation à partir de sources SECRET et UNCLASSIFIED est SECRET.
• Compartiments : union. Une dérivation à partir de sources compartiment-A et compartiment-B porte les deux compartiments.
• Diffusion : intersection. Une dérivation à partir de sources FVEY-only et NATO-only n'est diffusable qu'à l'intersection.
• Caveats : le plus restrictif. NOFORN sur n'importe quelle source rend la dérivation NOFORN.

Les règles sont mécaniques. Les implémenter comme une bibliothèque que chaque service de fusion, adaptateur et point de dérivation appelle. Une propagation artisanale par service dérive et produit des incohérences que les évaluateurs d'accréditation détectent. Une bibliothèque partagée, générée par code, qu'utilise chaque composant, est la discipline qui passe à l'échelle.

Étape 4 : le moteur de politiques

Les étiquettes sur les données sont nécessaires mais pas suffisantes. Les décisions d'accès exigent un moteur de politiques qui connaît l'habilitation, la nationalité et le rôle de l'utilisateur, et la classification, les compartiments et la diffusion des données demandées. Chaque requête contre la plateforme passe par ce moteur.

Le patron d'implémentation :

Politique en tant que code. Règles de diffusion exprimées dans un langage de politiques versionné. Le Rego d'Open Policy Agent est le choix défendable par défaut ; des alternatives comme Cedar ou des DSL artisanaux existent mais introduisent des frais de maintenance. Les changements de politique passent par revue de code, pas par changements de configuration.

Évaluation des décisions à la frontière de la requête. Lorsqu'un consommateur interroge la plateforme, le moteur de politiques évalue quels enregistrements sont visibles et quels attributs sont visibles par enregistrement. Le résultat est une vue filtrée, calculée au moment de la requête. Le filtrage uniquement à l'IHM — envoyer les données complètes au client et les cacher avec du CSS ou du JavaScript — est une violation Common Criteria et un échec d'accréditation immédiat.

Journal d'audit par décision. Chaque décision d'accès — utilisateur, données demandées, classification, résultat — est journalisée de manière immuable. Le journal d'audit est la base de preuves pour la revue après action, l'analyse forensique et la revue périodique d'accréditation.

Budgets de performance. Le moteur de politiques se trouve sur le chemin critique du COP. La latence de décision doit être inférieure à la milliseconde. Les stratégies de cache, les bundles de politiques précompilés, les empreintes de politiques par utilisateur — tout compte. Un moteur de politiques naïf est la cause la plus courante de lenteur du COP dans les déploiements classifiés.

Décisions par attribut là où c'est requis. Le moteur évalue non seulement si un enregistrement est visible, mais lesquels de ses attributs le sont. Une piste peut être visible à un utilisateur de coalition avec position diffusée mais identité retenue.

Étape 5 : flux de données inter-enclaves

Les réseaux de défense ne sont pas des enclaves uniques. Une plateforme opérant sur NATO RESTRICTED, NATO SECRET et des réseaux classifiés nationaux doit déplacer les données appropriées entre eux tout en empêchant les flux inappropriés.

Les patrons :

Instances de plateforme par enclave. Chaque enclave classifiée exécute sa propre instance de plateforme avec son propre magasin de données, moteur de politiques et journal d'audit. Les instances sont physiquement séparées ; la plateforme ne suppose pas qu'elles partagent un état.

Ponts inter-domaines. Là où les données circulent légitimement entre enclaves — AIS UNCLASSIFIED remontant vers une enclave SECRET, produit nettoyé pour diffusion descendant vers une enclave de coalition — le mouvement passe par une solution inter-domaines accréditée. Le pont applique les règles de classification à la frontière.

Diodes unidirectionnelles là où c'est requis. Pour le mouvement de données du haut vers le bas, des diodes unidirectionnelles imposent la direction au niveau réseau. La plateforme s'intègre à l'infrastructure de diodes plutôt que d'implémenter la sienne.

Libération manuelle là où l'automatisation ne peut atteindre. Certaines décisions de classification ne peuvent être automatisées en toute sécurité. La libération par produit de HUMINT ou de données compartimentées peut exiger une approbation humaine. La plateforme expose le candidat, capture la décision humaine avec attribution, et propage la libération approuvée avec audit.

Le traitement détaillé d'ingénierie du partage de données en coalition est dans Défis du partage de données en coalition.

Étape 6 : diffusion spécifique aux coalitions

Différentes coalitions ont différentes règles de diffusion. La plateforme qui veut se déployer dans plusieurs contextes de coalition doit accommoder :

Diffusion OTAN. L'ensemble standard de niveaux de classification OTAN et le marquage REL TO NATO. La plupart des plateformes opérationnelles visent d'abord cette base.

FVEY uniquement. L'accord de partage de renseignement Five Eyes (AUS, CAN, NZ, UK, US) utilise des politiques de classification qui ne s'alignent pas proprement sur les niveaux OTAN. Une plateforme visant des contextes FVEY implémente la politique FVEY aux côtés de l'OTAN.

Arrangements bilatéraux. De nombreuses plateformes ont des arrangements bilatéraux de partage de données avec des partenaires spécifiques. Ukraine, Israël, Corée, Japon ont tous des arrangements spécifiques aux programmes. Le moteur de diffusion les accommode comme marquages REL TO spécifiques plus accès à des compartiments spécifiques au partenaire.

Diffusion UE. Les programmes financés par l'UE ont leur propre politique de classification (EU CONFIDENTIAL, EU SECRET) qui ne se rabat pas sur les niveaux OTAN. Les plateformes financées par le FED doivent accommoder à la fois la classification OTAN et UE.

La discipline : implémenter un moteur de classification multi-politiques, pas une politique unique. Le moteur connaît les politiques OTAN, FVEY, UE et bilatérales comme entités nommées ; les données portent la politique sous laquelle elles ont été classifiées ; le moteur de politiques évalue l'accès face à l'habilitation de l'utilisateur sous chaque politique applicable.

Étape 7 : génération de preuves d'accréditation

Les évaluateurs d'accréditation ne croient pas la plateforme sur parole pour aucun de ces points. Ils demandent des preuves. Les preuves sont générées comme effet de bord d'une machinerie de classification correctement conçue.

Les preuves que les évaluateurs d'accréditation trouvent crédibles :

• Références de code montrant où les règles de propagation de classification sont implémentées, avec traçabilité de la politique au code.
• Échantillons de journal d'audit démontrant la journalisation par décision sur tout le spectre des scénarios d'accès.
• Résultats de tests de la suite de tests automatisés de la plateforme couvrant la propagation de classification, le filtrage de diffusion et la vérification de liaison sous entrées adverses.
• Preuves de déploiement opérationnel — mois ou années d'exploitation en production avec réponse aux incidents documentée, prévention des débordements de classification et passages réussis de revues périodiques d'accréditation.
• Journaux de transfert inter-domaines démontrant que le mouvement entre enclaves a été justifié, approuvé et enregistré.
• Rapports de tests d'intrusion issus d'exercices de red team ciblant spécifiquement la machinerie de classification.

La discipline DevSecOps qui génère automatiquement ces preuves est couverte dans DevSecOps pour pipelines de défense. Les cadres d'accréditation de soutien (ISO 27001, AQAP-2110, NIST) sont couverts dans ISO 27001 dans les logiciels de défense et NATO AQAP-2110 pour les éditeurs de logiciels.

Et ensuite

La partie 3 a implémenté la machinerie de classification. Étiquettes STANAG 4774 comme données structurées, liaison STANAG 4778 vérifiée à chaque frontière, propagation à travers la fusion et la dérivation, moteur de politiques imposant la diffusion au moment de la requête, flux inter-enclaves accommodés, diffusion multi-coalition prise en charge, génération de preuves intégrée.

La partie 4 clôt la série avec les disciplines de validation et d'achat : tests de conformité, préparation à CWIX, parcours d'accréditation et discipline de maintenance de longue traîne qui maintient la plateforme déployable sur des durées de vie opérationnelles pluriannuelles.