Contrôle d'accès basé sur les rôles dans les systèmes C2 de défense : conception et implémentation

Le contrôle d'accès dans les logiciels C2 de défense n'est pas une fonctionnalité ajoutée en fin de développement. C'est une décision architecturale fondamentale qui détermine qui peut voir quelles données, qui peut émettre quels ordres, et comment ces décisions sont appliquées à chaque couche du système — des points de terminaison API aux requêtes de base de données en passant par les abonnements WebSocket. Une erreur ici signifie soit l'exposition de données classifiées à des utilisateurs non autorisés, soit le blocage d'opérateurs qui ont besoin d'une connaissance situationnelle en temps réel.

Le contrôle d'accès basé sur les rôles (RBAC) standard, tel qu'implémenté dans les fournisseurs d'identité commerciaux comme Keycloak ou Azure AD, couvre adéquatement le mappage rôle-permission pour les logiciels d'entreprise. Les systèmes C2 de défense — qu'ils soient développés pour des programmes DGA (Direction générale de l'armement) comme SICS-G ou pour l'EMA (État-major des armées) — nécessitent une dimension supplémentaire : les niveaux de classification et les compartiments. Un utilisateur peut être authentifié et posséder le bon rôle, mais se voir quand même refuser l'accès à une piste spécifique parce qu'elle est marquée avec une classification ou un compartiment pour lequel l'utilisateur n'a pas d'habilitation.

RBAC vs ABAC : quel modèle convient au C2 de défense

Le RBAC pur attribue des permissions aux rôles et des rôles aux utilisateurs. Un rôle "Officier S2 de bataillon" accorde l'accès aux superpositions de renseignement ; un rôle "Officier logistique" accorde l'accès aux données de la chaîne d'approvisionnement. Ce modèle est simple à implémenter et à auditer, mais ne peut pas exprimer des restrictions à granularité fine au niveau des données sans explosion des rôles.

Le contrôle d'accès basé sur les attributs (ABAC) évalue les décisions d'accès en fonction des attributs du sujet (utilisateur), de la ressource (objet de données), de l'action et de l'environnement. Dans un modèle ABAC, l'accès à une piste est accordé si : le niveau d'habilitation de l'utilisateur est supérieur ou égal au niveau de classification de la piste ET l'utilisateur possède tous les tags de compartiments associés à la piste ET le terminal actuel de l'utilisateur se trouve dans un segment réseau approuvé.

En pratique, les systèmes C2 de défense utilisent une approche hybride : RBAC pour l'application grossière des rôles et ABAC pour le filtrage fin des données, avec la couche RBAC appliquée via les claims JWT au moment de l'authentification et la couche ABAC appliquée au moment de la requête par la couche de données.

Niveaux de classification et compartiments

Niveaux de classification OTAN par ordre croissant : UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET. La plupart des systèmes C2 tactiques opèrent au niveau SECRET ou en dessous. Le niveau de classification d'un objet de données est le niveau d'habilitation minimal requis pour y accéder.

Les compartiments sont orthogonaux aux niveaux de classification. Un utilisateur habilité SECRET peut ne pas posséder le compartiment SIGINT ou HUMINT, même au niveau SECRET. Une piste dérivée d'un capteur SIGINT est taguée avec le compartiment SIGINT ; seuls les utilisateurs possédant ce compartiment voient la piste dans la COP, indépendamment de leur niveau d'habilitation global. Dans les logiciels, les compartiments sont implémentés comme un ensemble de tags chaîne sur l'enregistrement de données et dans l'ensemble d'attributs de l'utilisateur ; l'accès n'est accordé que lorsque l'ensemble de compartiments de l'enregistrement est un sous-ensemble de l'ensemble de compartiments de l'utilisateur.

Structure des claims JWT pour le C2 de défense

Les JSON Web Tokens transportent l'identité et les claims d'attributs de l'utilisateur entre le fournisseur d'identité et les services d'application C2 :

{
  "sub": "user-uuid-1234",
  "name": "Cne. A. Dupont",
  "roles": ["operator", "s2-officer"],
  "clearance": "SECRET",
  "compartments": ["SIGINT", "HUMINT"],
  "unit": "1er RIMa",
  "network_segment": "SIPRNET",
  "iat": 1746960000,
  "exp": 1746963600,
  "jti": "unique-token-id"
}

Le claim clearance porte le niveau d'habilitation de l'utilisateur comme une chaîne qui se mappe sur une valeur numérique dans le moteur de politique. Le claim compartments est un tableau de chaînes de compartiments. Le claim network_segment porte le contexte réseau permettant des décisions d'accès basées sur l'environnement. Les périodes de validité des tokens pour les systèmes de défense sont plus courtes que les normes commerciales : tokens d'accès de 60 minutes avec rotation des tokens de rafraîchissement.

Points d'application des politiques

Dans une architecture C2 en microservices, le contrôle d'accès doit être appliqué à plusieurs couches.

Passerelle API (RBAC grossier). Valide la signature et l'expiration du JWT. Rejette les requêtes avec des tokens invalides. Ne prend pas de décisions d'accès au niveau des données.

Couche service (évaluation de politique ABAC). Chaque service gérant des données classifiées dispose d'un point de décision de politique intégré. Avant de retourner un objet de données, le service évalue : habilitation utilisateur >= niveau de classification des données ET compartiments utilisateur sont un sur-ensemble des compartiments des données. Les objets qui échouent cette vérification sont filtrés de la réponse.

Couche base de données (sécurité au niveau des lignes). Les politiques RLS (Row-Level Security) de PostgreSQL appliquent les restrictions au niveau des données directement dans la base de données, fournissant une défense en profondeur contre les erreurs de logique applicative — exigence critique pour les systèmes C2 DGA opérant sur des réseaux classifiés.

Modèle de sécurité multiniveau Bell-LaPadula

Le modèle Bell-LaPadula (BLP) formalise le contrôle d'accès aux informations classifiées avec deux règles principales. La propriété de sécurité simple (pas de lecture vers le haut) : un sujet au niveau de classification L ne peut pas lire un objet au niveau L', où L' > L. La propriété étoile (pas d'écriture vers le bas) : un sujet au niveau L ne peut pas écrire dans un objet au niveau L', où L' < L — empêchant la copie de données classifiées dans un enregistrement non classifié.

En pratique, la règle sans-écriture-vers-le-bas est plus difficile à appliquer dans les architectures d'applications web. L'application nécessite que les opérations d'écriture définissent explicitement le niveau de classification de l'enregistrement cible au maximum du niveau de classification des données source, et que cette logique soit appliquée au niveau de la couche service. Dans les programmes DGA comme SICS, cette exigence est formalisée dans les spécifications de sécurité des cahiers des charges.

Journaux d'audit et intégration SIEM

Chaque décision d'accès — tant les accordances que les refus — doit être enregistrée avec suffisamment de détails pour l'audit de sécurité et la réponse aux incidents. Une entrée de journal d'audit d'un système C2 inclut : horodatage, identifiant utilisateur, niveau d'habilitation, action tentée, identifiant de ressource, niveau de classification de la ressource, décision (GRANT/DENY) et la règle de politique qui a produit la décision. Les journaux d'audit sont transmis à un système SIEM pour la détection d'anomalies en temps réel.