La sécurité centrée sur les données – l'idée que la protection suit l'objet de données plutôt que le périmètre réseau – n'est pas nouvelle, mais sa mise en œuvre pratique dans les systèmes militaires de coalition a historiquement été difficile. STANAG 4774 et STANAG 4778 sont la réponse formelle de l'OTAN : deux normes imbriquées qui définissent comment les étiquettes de confidentialité sont structurées, comment elles sont liées aux données et comment les moteurs de politique les évaluent. Cet article couvre l'ingénierie pratique d'une mise en œuvre d'étiquetage conforme : syntaxe d'étiquette, mécanisme de liaison, conception du point d'application des politiques, gestion de l'agrégation et la discipline de préservation des étiquettes qui détermine si votre architecture survit à la revue d'accréditation. Pour le contexte de politique de classification et de diffusion qui encadre ce travail d'ingénierie, voir l'article complémentaire sur la classification STANAG 4774/4778 et la diffusion en coalition.

Le modèle de sécurité centré sur les données : pourquoi les étiquettes voyagent avec les données

La sécurité traditionnelle centrée sur le réseau repose sur le niveau de classification de l'enclave : dès qu'une donnée se trouve sur un réseau SECRET, chaque système de ce réseau est jugé digne de confiance pour la manipuler. Ce modèle s'effondre dans les environnements de coalition où les données circulent entre des enclaves de niveaux d'accréditation différents, de politiques nationales différentes et d'ensembles de destinataires autorisés différents. Un document SECRET sur un réseau commun n'est pas nécessairement diffusable à chaque nation partenaire ayant accès à ce réseau.

La sécurité centrée sur les données résout cela en faisant de l'étiquette une propriété inséparable de l'objet de données. Chaque objet porte une étiquette de confidentialité lisible par machine qui précise son niveau de classification, les mentions de manipulation régissant son usage et les marquages de diffusion identifiant quelles organisations sont autorisées à le recevoir. Les décisions de politique – transmettre, afficher, stocker ou imprimer un objet – sont prises en évaluant l'étiquette de l'objet par rapport à l'habilitation du sujet demandeur et au niveau d'accréditation du système de destination, plutôt qu'en faisant confiance au réseau pour appliquer la bonne frontière.

STANAG 4774 définit la structure de l'étiquette. STANAG 4778 définit le mécanisme de liaison. Ensemble, ils fournissent le substrat technique pour le partage de données en coalition qui respecte la politique nationale de divulgation de chaque nation sans exiger une revue manuelle de chaque échange de données. Comprendre les deux normes comme une paire – et non isolément – est le prérequis d'une mise en œuvre conforme.

Syntaxe d'étiquette STANAG 4774 : structure et encodage

Une étiquette de confidentialité STANAG 4774 est un document XML conforme au schéma XML STANAG 4774. Son élément de premier niveau est <ConfidentialityLabel>, qui porte trois enfants obligatoires et plusieurs extensions facultatives.

Identifiant de politique. L'élément <PolicyIdentifier> contient un identifiant d'objet (OID) qui référence le document de politique d'étiquetage régissant cette étiquette. L'OID est enregistré auprès d'une autorité reconnue – généralement le bureau C3 national ou l'Agence C3 de l'OTAN – et constitue la clé permettant aux systèmes destinataires de rechercher la définition complète de la politique et d'évaluer correctement l'étiquette. Une étiquette sans OID de politique résoluble ne peut être évaluée par un moteur de politique conforme et doit être traitée comme non vérifiée.

Classification. L'élément <Classification> précise le niveau de classification sous forme de valeur énumérée : UNCLASSIFIED, RESTRICTED, CONFIDENTIAL ou SECRET. L'encodage est sensible à la casse et doit correspondre exactement aux valeurs de chaîne définies dans le document de politique référencé par l'OID. Une étiquette utilisant « Secret » plutôt que « SECRET » échouera à la validation de schéma dans une mise en œuvre conforme – une erreur d'intégration courante lors de la génération d'étiquettes à partir de bibliothèques XML généralistes qui n'appliquent pas l'énumération.

Mentions de manipulation et diffusion. L'élément <CategoryData> porte les mentions de manipulation telles que ATOMAL, CRYPTO, EYES ONLY ou des mentions spécifiques à la mission définies par la politique. L'élément <PermittedCountryCodes> porte le marquage de diffusion sous forme d'ensemble de codes pays ISO 3166-1 alpha-3. Le marquage de diffusion est la partie opérationnellement la plus importante de l'étiquette dans les environnements multinationaux : il détermine quels systèmes de nations partenaires sont autorisés à recevoir les données étiquetées, indépendamment du niveau de classification.

Génération d'étiquettes : exigences de validation

Chaque étiquette générée par un système conforme doit être validée par rapport au schéma XML STANAG 4774 avant d'être liée à un objet de données. La validation de schéma détecte les erreurs structurelles – OID malformés, chaînes de classification invalides, éléments obligatoires manquants – mais ne valide pas la correction sémantique par rapport au document de politique. Une étape de validation distincte au niveau de la politique doit vérifier que chaque mention et chaque marquage de diffusion dans l'étiquette est défini dans le document de politique référencé, et que la combinaison du niveau de classification et des mentions est autorisée par cette politique. Une mise en œuvre qui saute la validation au niveau de la politique générera des étiquettes qui passent la validation de schéma mais sont rejetées par les moteurs de politique en aval avec des erreurs difficiles à diagnostiquer après coup. Intégrez l'étape de validation au niveau de la politique dans le générateur d'étiquettes, et non dans un audit distinct post-génération.

Mécanismes de liaison STANAG 4778 : assertion et encapsulation

STANAG 4778 définit deux mécanismes pour lier une étiquette STANAG 4774 à un objet de données : la liaison par assertion et la liaison par encapsulation. Elles servent des cas d'usage différents et ont des propriétés de sécurité différentes, et le choix entre elles doit être fait au moment de la conception de l'architecture.

La liaison par assertion produit une assertion XML signée qui inclut l'étiquette, une référence à l'objet de données (généralement un hachage cryptographique de la charge utile) et une signature numérique de l'autorité d'étiquetage. La signature est calculée à l'aide de XML Digital Signature (XMLDSig) sur le XML d'étiquette canonisé. L'objet de données et l'assertion signée sont transmis ensemble – soit dans la même enveloppe de message, soit comme paire référence-et-assertion. Le système destinataire vérifie l'assertion en contrôlant la signature par rapport au certificat de clé publique de l'autorité d'étiquetage, puis contrôle le hachage de l'objet de données par rapport au hachage dans l'assertion. Si les deux contrôles réussissent, l'étiquette est vérifiée comme authentique et non modifiée, et la liaison entre l'étiquette et l'objet de données est confirmée cryptographiquement.

La liaison par assertion est obligatoire pour les données qui franchissent des frontières de classification via une solution inter-domaines (CDS). L'accréditeur doit vérifier que la CDS applique correctement les étiquettes, et l'assertion signée fournit les preuves d'audit requises pour cette vérification. Sans liaison par assertion à la frontière de la CDS, l'accréditeur ne peut confirmer que les étiquettes présentées au système du côté bas sont des représentations authentiques de la décision de l'autorité d'étiquetage du côté haut – et la CDS ne sera pas accréditée.

La liaison par encapsulation intègre l'étiquette directement dans la structure de l'objet de données – dans un en-tête de message, un bloc de métadonnées ou un champ d'extension défini. Il n'y a pas de signature cryptographique distincte ; la liaison repose sur l'intégrité du canal de transport. La liaison par encapsulation est plus simple à mettre en œuvre et largement utilisée pour les données qui restent dans un seul domaine de sécurité. Pour un système C2 fonctionnant entièrement au sein d'une enclave SECRET, la liaison par encapsulation dans le schéma de message est suffisante et évite la surcharge PKI de la liaison par assertion pour chaque message interne.

Mélanger les mécanismes de liaison au sein du même système – utiliser la liaison par encapsulation pour les messages internes et la liaison par assertion uniquement à la frontière de la CDS – est correct et courant, mais la frontière doit être clairement définie et appliquée dans la mise en œuvre. L'ambiguïté sur le mécanisme de liaison applicable à telle frontière de système est une source de constats d'accréditation.

Conception du point d'application des politiques

Un point d'application des politiques (PEP) est le composant logiciel qui intercepte les demandes d'accès et d'échange de données et évalue l'étiquette de l'objet demandé par rapport à l'habilitation du sujet demandeur et au niveau d'accréditation du système demandeur. Dans une architecture conforme à STANAG 4774/4778, le PEP n'est pas optionnel : c'est le mécanisme par lequel l'étiquette produit un contrôle d'accès réel, plutôt que d'être une simple annotation de métadonnées jamais évaluée.

L'algorithme d'évaluation du PEP doit mettre en œuvre correctement la dominance. Un sujet peut accéder à un objet si et seulement si l'habilitation du sujet domine l'étiquette de l'objet : le niveau de classification du sujet est au moins aussi élevé que celui de l'objet, le sujet détient toutes les mentions requises par les marquages de manipulation de l'objet, et l'ensemble de diffusion autorisé du sujet couvre tous les marquages de diffusion de l'objet. Chacune de ces trois conditions doit être évaluée indépendamment ; satisfaire deux sur trois est une violation de politique, et non un octroi d'accès partiel.

La condition la plus souvent mal mise en œuvre est la diffusion. Une comparaison de diffusion correcte vérifie que l'ensemble de diffusion autorisé du système destinataire est un sur-ensemble du marquage de diffusion de l'objet. Un système autorisé pour REL TO DEU GBR USA peut recevoir un objet marqué REL TO DEU GBR, car l'ensemble autorisé contient toutes les nations marquées. Un système autorisé pour REL TO GBR USA ne peut recevoir un objet marqué REL TO DEU GBR, même si GBR apparaît dans les deux ensembles, car DEU ne figure pas dans l'ensemble autorisé du système destinataire. Mettre en œuvre une vérification de sur-ensemble plutôt qu'une vérification d'intersection est la logique correcte ; la vérification d'intersection est l'erreur courante et produit un système qui accorde l'accès à des objets qu'il n'est pas autorisé à recevoir.

Point clé : La défaillance d'accréditation la plus fréquente dans les mises en œuvre STANAG 4774/4778 n'est ni la génération ni la liaison des étiquettes – c'est la gestion de l'agrégation. Les systèmes qui étiquettent correctement les objets de données individuels échouent fréquemment à escalader les étiquettes lorsque ces objets sont combinés en produits dérivés. Un moteur de fusion qui fusionne un rapport de piste CONFIDENTIAL avec une localisation de position RESTRICTED doit produire une sortie CONFIDENTIAL ; un intergiciel qui hérite seulement de l'étiquette d'un objet d'entrée produira des sorties mal étiquetées qui atteignent le côté bas via la CDS, constituant une fuite.

Agrégation et escalade des étiquettes

L'agrégation – combiner deux objets étiquetés ou plus en un produit dérivé – est le problème le plus difficile dans une mise en œuvre pratique de STANAG 4774/4778. Le produit dérivé doit porter une étiquette au moins aussi restrictive que l'entrée la plus restrictive, sur les trois composants de l'étiquette : niveau de classification, mentions de manipulation et diffusion.

Pour le niveau de classification, la règle est simple : la classification de sortie est le maximum des classifications d'entrée. Un produit dérivé d'entrées RESTRICTED et CONFIDENTIAL est CONFIDENTIAL. Pour les mentions de manipulation, la sortie doit inclure l'union de toutes les mentions d'entrée : si une entrée porte ATOMAL et une autre CRYPTO, la sortie doit porter les deux. Pour la diffusion, la sortie doit porter l'intersection des ensembles de diffusion d'entrée : si une entrée est diffusable à DEU GBR USA et une autre à GBR FRA, la sortie n'est diffusable qu'à GBR, car seul GBR est autorisé pour les deux entrées.

Cette logique d'agrégation doit être mise en œuvre dans chaque composant qui produit des données dérivées : moteurs de fusion, générateurs de rapports, services de synthèse et tout pipeline analytique combinant des entrées de plusieurs sources. Le calcul d'agrégation d'étiquettes doit se produire avant que l'objet de sortie ne soit écrit dans un tampon ou une file, et non comme une étape de post-traitement. Une sortie qui existe sans étiquette correcte ne serait-ce qu'un bref instant – avant qu'une étape de post-traitement ne se déclenche – représente une fenêtre de non-conformité aux politiques qu'un accréditeur identifiera lors de la revue de conception.

Préservation des étiquettes lors des échanges en coalition

La préservation des étiquettes est la discipline consistant à garantir qu'une étiquette STANAG 4774 et sa liaison STANAG 4778 survivent au chemin de transit complet du système d'origine jusqu'à chaque destinataire autorisé, y compris à travers l'intergiciel, les courtiers de messages, les passerelles de fédération et les composants de traduction de format qui peuvent ne pas être sensibles aux étiquettes.

Dans une infrastructure d'échange conforme au Federated Mission Network (FMN), la préservation des étiquettes est intégrée au profil : la couche de services FMN est tenue de porter les étiquettes STANAG 4774 dans les enveloppes de message et de vérifier les liaisons à l'ingestion. En pratique, de nombreux systèmes déployés comprennent des composants antérieurs à la conformité FMN ou intégrés sans sensibilité aux étiquettes – relais de messages hérités, routeurs CoT non conformes, intergiciel de base de données qui supprime les métadonnées à l'insertion. Chacun de ces composants représente un point de perte d'étiquette potentiel qui doit être identifié et atténué dans la conception du système.

L'atténuation standard du risque de perte d'étiquette consiste à utiliser la liaison par assertion plutôt que la liaison par encapsulation pour les données qui traversent une infrastructure non fiable. Parce que l'assertion fait partie du corps de la charge utile plutôt que d'un en-tête de transport, elle survit au transit à travers des composants qui suppriment ou réécrivent les en-têtes de message. À l'extrémité réceptrice, la vérification de la liaison par assertion confirme que l'étiquette est authentique et intacte même si les métadonnées de transport ont été modifiées en transit.

Pour les systèmes qui doivent s'aligner plus largement sur les normes d'interopérabilité de l'OTAN, les tests de préservation des étiquettes devraient être intégrés au plan de tests d'interopérabilité CWIX comme objectif de test de premier ordre, et non comme un ajout tardif. Un système qui réussit tous les tests d'interopérabilité fonctionnels mais supprime silencieusement les étiquettes en transit échouera à la revue d'accréditation de sécurité, même s'il ne rate jamais un seul test fonctionnel. La suite de tests de préservation des étiquettes doit injecter des objets avec des étiquettes connues à chaque point d'entrée, capturer et inspecter les objets à chaque point de sortie, et vérifier que le contenu de l'étiquette et la signature de liaison sont identiques entre l'injection et la réception.

Appliquez les étiquettes de confidentialité à l'ensemble de vos flux de données en coalition

L'Interoperability Dashboard offre une visibilité en temps réel sur la conformité des étiquettes, la vérification des liaisons et l'application des politiques à travers l'échange de données fédéré – conçu pour la complexité de classification des environnements C2 multinationaux où la conformité à STANAG 4774/4778 doit être démontrable aux accréditeurs.

Explorer l'Interoperability Dashboard → Réserver un briefing

Cette analyse a été préparée par des ingénieurs de Corvus Intelligence qui conçoivent des systèmes d'interopérabilité et de sécurité des données critiques pour des organisations de défense et gouvernementales. En savoir plus sur notre équipe →