Gestion des identités en coalition : authentification fédérée sur les réseaux OTAN et partenaires

Lorsqu'une officière de liaison française se connecte à un système de commandement commun en coalition, aucune organisation unique ne détient son identité. Ses identifiants ont été émis par la Direction Interarmées des Réseaux d'Infrastructure et des Systèmes d'Information (DIRISI), son habilitation a été octroyée selon la politique française de sécurité nationale, et ses rôles ont été attribués par sa chaîne de commandement à Paris. L'application de coalition à laquelle elle se connecte fonctionne sur une infrastructure gérée par une nation partenaire qui ne fait confiance à aucun de ces éléments par défaut. Combler cette lacune de manière fiable, sécurisée et sans nécessiter l'approvisionnement manuel de milliers de comptes de coalition temporaires, tel est le problème que résout la gestion des identités en coalition. Cet article examine les protocoles, les structures PKI, les schémas d'attributs et les mécanismes de politique qui rendent l'interopérabilité en coalition possible au niveau de la couche d'identité.

Le problème d'identité dans les opérations en coalition

Les opérations en coalition rassemblent du personnel de plusieurs nations souveraines sur des délais de quelques jours. Une force opérationnelle interarmées permanente peut inclure des contributeurs d'une douzaine de nations, chacune opérant sous son propre régime de gouvernance des identités, utilisant sa propre infrastructure d'annuaire et émettant des identifiants sous sa propre hiérarchie PKI nationale. Avant l'existence de solutions d'identité fédérées, l'approche standard consistait en un approvisionnement manuel : les agents de liaison à la frontière du système de chaque nation créaient des comptes locaux pour les utilisateurs entrants de la coalition, attribuaient les autorisations manuellement et désactivaient ces comptes lorsque l'utilisateur partait. Ce processus était lent, sujet aux erreurs, documenté de manière incohérente et créait des comptes orphelins persistants qui restaient actifs bien après le départ du personnel qu'ils représentaient.

L'exigence fondamentale est que l'authentification et l'autorisation doivent rester sous contrôle souverain tout en permettant l'accès à travers les frontières nationales. Aucune nation n'accepte une autorité d'identité centralisée pour la coalition qui pourrait être captée, compromise ou exploitée politiquement par un autre membre. L'architecture ne peut donc pas reposer sur un seul magasin d'identités dans lequel toutes les nations seraient fédérées. Elle doit au contraire traiter le fournisseur d'identité de chaque nation comme un pair, établissant des relations de confiance bilatérales ou multilatérales entre eux sans céder le contrôle national sur les identifiants eux-mêmes. C'est la contrainte définissante qui rend la gestion des identités en coalition architecturalement distincte de l'authentification unique en entreprise.

La conséquence pratique est que chaque transaction d'identité à travers une frontière de coalition implique au moins trois parties : le fournisseur d'identité d'origine de l'utilisateur, la partie de confiance propriétaire de la ressource dans la nation partenaire, et le cadre de confiance que les deux parties ont convenu de mettre en œuvre. Comme décrit dans le guide de mise en œuvre des réseaux de mission fédérés, ce cadre de confiance est documenté dans des accords de fédération qui précisent quels attributs seront échangés, quels formats d'assertion sont attendus et comment les décisions d'accès seront prises à la frontière.

Protocoles de fédération : SAML 2.0, OAuth 2.0 et OIDC pour les environnements de défense

Security Assertion Markup Language 2.0 (SAML 2.0) reste le protocole dominant pour la fédération des identités dans les environnements de défense et gouvernementaux. Sa maturité, son large déploiement sur les plateformes d'identité d'entreprise (Microsoft ADFS, Shibboleth, Ping Identity) et son modèle d'assertion basé sur les signatures XML s'alignent bien avec l'infrastructure PKI existante. Une assertion SAML est un document XML signé qui transporte les attributs d'identité de l'utilisateur et est émis par l'IdP d'origine après que l'utilisateur s'est authentifié localement. La partie de confiance valide la signature de l'assertion par rapport au certificat de signature de l'IdP, vérifie la restriction d'audience (confirmant que l'assertion a été émise pour ce RP spécifique) et contrôle l'horodatage de l'assertion pour prévenir les attaques par rejeu. Comme l'assertion est signée à l'émission, le RP n'a pas besoin d'une connexion directe à l'IdP au moment de la validation, ce qui est précieux dans les environnements de coalition à connectivité intermittente.

OAuth 2.0 et OpenID Connect (OIDC) sont de plus en plus présents dans les architectures de coalition à mesure que les nouveaux systèmes adoptent des API REST natives plutôt que les schémas orientés SOAP pour lesquels SAML a été conçu. OIDC étend OAuth 2.0 avec un jeton d'identité standardisé (un JSON Web Token) portant les attributs d'identité, tandis que les jetons d'accès OAuth 2.0 sont utilisés pour autoriser les appels API au nom de l'utilisateur authentifié. Le format de jeton plus court et les flux natifs HTTP rendent OIDC préférable pour les applications mobiles et web. Pour un usage en coalition, OIDC exige que le serveur d'autorisation de la nation d'origine soit accessible depuis le réseau du partenaire au moment de l'émission du jeton, ce qui impose une dépendance de connectivité que le modèle d'assertion hors ligne de SAML évite. De nombreux déploiements en coalition exécutent donc SAML pour l'authentification primaire et émettent des jetons OIDC de courte durée localement à la frontière du partenaire, traduisant effectivement une assertion SAML entrante en une session OIDC limitée à l'écosystème d'applications du partenaire.

Les deux protocoles nécessitent un renforcement attentif pour les environnements de défense. Le chiffrement des assertions (pas seulement la signature) est obligatoire lorsque les assertions traversent des frontières réseau, car une assertion SAML signée mais non chiffrée expose le niveau d'habilitation, la nationalité et les attributions de rôles de l'utilisateur à tout observateur du réseau. TLS 1.3 avec authentification mutuelle doit protéger tous les points de terminaison de fédération. La synchronisation des horloges sur toute l'infrastructure IdP et RP est une dépendance silencieuse : les fenêtres de validation des horodatages SAML sont généralement définies à cinq minutes, et une dérive d'horloge dépassant cette fenêtre provoque l'échec d'assertions valides, rompant l'accès des utilisateurs concernés sans autre erreur évidente qu'un délai d'expiration d'authentification.

Certification croisée PKI : relier les autorités de certification nationales

Les assertions de fédération des identités ne sont fiables qu'à hauteur de la fiabilité des clés de signature qui les sous-tendent. Chaque IdP SAML signe ses assertions avec un certificat émis sous une hiérarchie d'autorité de certification. Pour qu'une RP d'une nation partenaire fasse confiance à une assertion entrante, elle doit faire confiance à la CA qui a émis le certificat de signature. Dans un déploiement domestique à organisation unique, c'est simple : une CA émet des certificats à toutes les parties de confiance et fournisseurs d'identité. Dans une coalition, chaque nation exploite sa propre hiérarchie CA, émettant des certificats sous des cadres de politique nationaux que les systèmes d'autres nations ne reconnaissent pas par défaut.

La certification croisée résout ce problème en créant des liens de confiance explicites entre les hiérarchies CA nationales. Dans sa forme bilatérale la plus simple, la CA de la Nation A émet un certificat croisé pour la CA de la Nation B (et vice versa). Une partie de confiance dans la Nation A qui fait confiance à sa propre hiérarchie CA fait confiance transitivement aux certificats émis sous la CA de la Nation B. Le certificat croisé spécifie la profondeur du chemin de confiance et peut inclure des contraintes de politique qui limitent les usages de certificats approuvés (par exemple, faire confiance aux certificats de la Nation B uniquement pour la vérification des signatures numériques, pas pour le chiffrement de clés). Au sein de l'OTAN, l'Infrastructure à clé publique OTAN exploite une CA passerelle qui certifie de manière croisée les CA des nations participantes, permettant à une seule relation passerelle de propager la confiance à travers toutes les hiérarchies nationales connectées plutôt d'exiger que chaque paire de nations établisse une certification croisée bilatérale directe.

Les identifiants de politique de certificats (OID dans les extensions de certificat) sont le mécanisme par lequel les parties de confiance appliquent des décisions de confiance spécifiques à chaque nation. Une RP de coalition peut être configurée pour accepter des certificats de toutes les CA nationales certifiées de manière croisée à des fins d'authentification générale, mais exiger un OID de politique spécifique (indiquant un identifiant basé sur un jeton matériel ou un niveau d'assurance particulier) avant de permettre l'accès aux ressources classifiées diffusables. Ce modèle de politique à deux niveaux — confiance d'authentification large, confiance d'autorisation étroite — évite le problème opérationnel de modifier l'accord de certification croisée à chaque fois qu'une nouvelle catégorie de ressources nécessite une assurance plus élevée, puisque les règles granulaires résident dans la politique locale de la RP plutôt que dans l'infrastructure CA.

Mappage de rôles entre les annuaires de coalition hétérogènes

Même lorsque l'authentification réussit à travers une frontière de fédération, la décision d'autorisation au système du partenaire nécessite de traduire les attributs d'identité entrants en quelque chose que le système de contrôle d'accès local comprend. Le grade de Lieutenant-Colonel d'un officier français, attesté dans le format d'attribut LDAP militaire français, est sans signification pour un système C2 britannique dont les listes de contrôle d'accès sont construites autour des grades britanniques et des codes de rôle. Le mappage de rôles est le processus d'établissement d'équivalences entre les schémas d'attributs des différents annuaires nationaux afin que les assertions entrantes puissent être converties en décisions d'accès localement applicables.

La couche de traduction est généralement implémentée comme un ensemble de règles de transformation des attributs dans la RP ou le courtier d'identité du partenaire. Les règles prennent la forme de mappages conditionnels : si l'assertion entrante porte un attribut de nationalité "FRA" et un code de grade dans la plage correspondant à OF-4 à OF-5 dans l'échelle de grades STANAG de l'OTAN, mapper l'utilisateur au groupe local "officier-supérieur-coalition". L'échelle de grades STANAG est la lingua franca qui rend cela possible : elle fournit un identifiant numérique commun pour chaque grade à travers toutes les nations alliées, permettant aux règles de mappage de rôles d'être rédigées par rapport au code STANAG neutre plutôt qu'à l'intitulé de grade natif de chaque nation. Les nations qui contribuent du personnel à une coalition ont la responsabilité d'inclure l'équivalent de grade STANAG dans leurs assertions SAML, une exigence qui doit être vérifiée lors des tests de fédération.

Les attributions de rôles fonctionnels présentent un défi de mappage plus complexe car aucune norme OTAN ne fournit l'équivalent des codes de grade STANAG pour les rôles fonctionnels. Un utilisateur ayant le rôle "analyste du renseignement" dans l'annuaire de la Nation A peut avoir besoin d'être mappé vers différents rôles locaux selon les systèmes du partenaire auxquels il accède et ce que les règles d'engagement actuelles de la coalition précisent pour le niveau d'accès de ce rôle. Cela exige que les règles de mappage de rôles soient maintenues comme un document vivant, mis à jour via le processus de coordination de la gestion des identités de la coalition à mesure que de nouveaux systèmes sont fédérés et que les exigences opérationnelles évoluent. Les défis de partage de données en coalition découlant de modèles de données incompatibles sont les plus aigus précisément à cette frontière de traduction des attributs.

Contrôle d'accès basé sur les attributs pour l'application des règles de diffusion

Le contrôle d'accès basé sur les rôles (RBAC) attribue des permissions aux rôles et des rôles aux utilisateurs. Pour les systèmes de coalition, ce modèle est insuffisant car les décisions d'accès dépendent de dimensions que les seuls rôles ne peuvent pas saisir. Un document marqué REL TO USA, GBR, CAN, AUS, NZL (diffusable aux nations du groupe des Five Eyes) doit être accessible à un officier canadien au niveau SECRET mais pas à un officier français au niveau équivalent, indépendamment du fait que les deux exercent des rôles fonctionnels identiques. La diffusion est une propriété de la ressource, pas du rôle de l'utilisateur, et son application correcte nécessite d'évaluer simultanément la nationalité, l'habilitation, le besoin d'en connaître de l'utilisateur et l'étiquette de classification de la ressource.

Le contrôle d'accès basé sur les attributs (ABAC) gère cela naturellement. Une politique ABAC est une règle logique qui évalue les attributs du sujet (nationalité, habilitation, rôle, affectation), les attributs de la ressource (niveau de classification, caveats de diffusion, instructions de traitement) et les attributs environnementaux (niveau de classification du réseau, heure d'accès) par rapport à un énoncé de politique explicite. Une politique pour le document ci-dessus pourrait se lire : autoriser l'accès si sujet.nationalité est dans [USA, GBR, CAN, AUS, NZL] ET sujet.habilitation >= SECRET ET ressource.classification <= SECRET ET ressource.diffusion contient sujet.nationalité. Cette règle est rédigeable, traçable et indépendante de la taxonomie de rôles de toute nation spécifique. Le moteur de politique l'évalue au moment de l'accès en fonction des attributs extraits de l'assertion SAML et des métadonnées de la ressource.

eXtensible Access Control Markup Language (XACML) est la norme la plus mature pour exprimer et évaluer les politiques ABAC dans les environnements de défense. Un point de décision de politique (PDP) XACML reçoit une demande d'autorisation contenant les attributs du sujet, de la ressource et de l'environnement, l'évalue par rapport à l'ensemble de politiques chargé et retourne une décision d'autorisation ou de refus. Le point d'application de politique (PEP) dans l'application intercepte chaque accès aux ressources, construit la demande d'autorisation, appelle le PDP et applique la décision. La séparation du PEP et du PDP permet à la politique d'être mise à jour, versionnée et auditée indépendamment du code de l'application — une propriété critique lorsque les règles de diffusion évoluent au fil de la situation opérationnelle.

Configuration des parties de confiance et gestion des métadonnées à grande échelle

Une coalition de douze nations, chacune exploitant dix à trente applications fédérées, génère un problème de gestion des métadonnées avec une surface opérationnelle non négligeable. Chaque partie de confiance doit disposer de métadonnées actuelles et valides pour chaque IdP dont elle accepte les assertions. Chaque IdP doit avoir enregistré chaque RP pour laquelle il peut émettre des assertions. Lorsqu'une nation fait tourner son certificat de signature IdP (ce qui devrait se produire au moins annuellement et chaque fois qu'une compromission est suspectée), chaque RP qui accepte les assertions de cette nation doit être mise à jour avec le nouveau certificat avant l'expiration de l'ancien. Faire cela manuellement à travers des centaines d'enregistrements bilatéraux est opérationnellement intenable et entraîne des interruptions d'accès lorsque les mises à jour accusent du retard sur les rotations de certificats.

La solution est un registre de métadonnées de fédération : un document XML signé, publié de manière centralisée, qui répertorie les métadonnées de tous les IdP et RP enregistrés dans la fédération de coalition. Chaque participant récupère le registre selon un calendrier défini (généralement toutes les 4 à 24 heures), extrait les entrées pertinentes pour sa configuration de confiance et met à jour sa plateforme d'identité locale. Le registre lui-même est signé par une clé d'autorité de registre de coalition, et chaque participant valide cette signature avant d'appliquer les mises à jour — empêchant un nœud réseau intermédiaire compromis d'injecter de fausses métadonnées pour rediriger les flux d'authentification. Les registres de métadonnées SAML conformes à la spécification SAML V2.0 Metadata Extensions for Registration and Publication fournissent le cadre technique pour cela ; le programme de réseaux de mission fédérés de l'OTAN en a documenté les processus opérationnels.

Les consommateurs de métadonnées doivent être configurés pour fermer l'accès en cas d'échec de récupération des métadonnées : si le registre est inaccessible et qu'une copie en cache a expiré, le système doit refuser les tentatives d'authentification des IdP concernés plutôt que de continuer à s'appuyer sur des certificats potentiellement périmés. Le compromis opérationnel entre disponibilité et sécurité ici est explicite et doit être codifié dans l'accord de fédération — définissant combien de temps les métadonnées en cache peuvent être utilisées avant d'être considérées expirées, et quel est le comportement de repli lorsque le registre est inaccessible lors d'opérations de combat où la connectivité réseau peut être intermittente.

Réponse aux incidents : révoquer rapidement l'accès dans une coalition fédérée

Le problème de révocation dans une coalition fédérée est plus difficile que dans une PKI à organisation unique car l'action de révocation doit se propager à travers des frontières souveraines vers des systèmes que la nation émettrice ne contrôle pas. Lorsque les identifiants d'un utilisateur de coalition sont compromis — par vol, coercition ou un incident de sécurité dans la nation d'origine — chaque partie de confiance à travers toutes les nations partenaires ayant pu accepter des assertions de cet utilisateur doit être informée et doit appliquer la révocation. Le délai entre la déclaration de l'incident et l'application universelle de la révocation constitue la fenêtre d'exposition pendant laquelle l'identifiant compromis reste utilisable.

Les courtes durées de vie des assertions sont le contrôle de premier ordre le plus efficace. Une assertion SAML avec une fenêtre de validité de 30 minutes expire avant qu'un identifiant compromis puisse être largement exploité dans la plupart des scénarios, sans nécessiter qu'une notification de révocation hors bande parvienne à la partie de confiance. Le coût est que l'utilisateur doit se réauthentifier toutes les 30 minutes, ce qui est gérable avec une réauthentification SSO transparente (où l'IdP émet silencieusement une nouvelle assertion sans solliciter l'utilisateur) mais devient opérationnellement perturbateur si l'IdP est inaccessible pendant la fenêtre de réauthentification. La définition de la durée de vie des assertions nécessite d'équilibrer ce compromis par rapport au profil de connectivité attendu du réseau de coalition.

Pour la révocation des certificats PKI, les listes de révocation de certificats (CRL) et le protocole de statut des certificats en ligne (OCSP) sont les deux mécanismes disponibles. La révocation basée sur les CRL publie une liste signée de numéros de série de certificats révoqués que les parties de confiance récupèrent périodiquement ; la latence de révocation est bornée par l'intervalle de renouvellement des CRL, généralement 24 heures dans la pratique PKI nationale mais configurable à 1 à 4 heures pour les scénarios de coalition à haute urgence. L'OCSP fournit le statut de révocation en temps réel mais nécessite que le répondeur OCSP soit accessible au moment de l'authentification — le même problème de dépendance de connectivité qu'avec OIDC. Une approche en couches est appropriée : assertions SAML de courte durée comme contrôle principal, récupérations fréquentes de CRL comme filet de sécurité au niveau des certificats, et agrafage OCSP à la couche TLS pour les applications où le statut de certificat en temps réel est requis. Les procédures de notification hors bande — listes de contacts documentées, formats de messages prédéfinis et chemins d'escalade testés à travers la coalition — complètent la capacité de réponse aux incidents qu'aucun protocole technique ne peut entièrement automatiser.