La gestion des accès à privilèges (PAM) dans un réseau de défense n'est pas le même problème que celui que le PAM résout dans une entreprise commerciale. Une banque qui se trompe sur le PAM perd des données client ; une organisation de défense qui se trompe sur le PAM perd le réseau — et les opérations qui tournent dessus. L'autorité d'accréditation le sait, et la chaîne d'audit le reflète. Cet article parcourt les décisions d'ingénierie qui séparent un déploiement PAM de qualité défense d'un déploiement commercial, en s'appuyant sur les motifs que nous avons vu réussir (et échouer) à l'intérieur d'enclaves classifiées, de workflows résidant en SCIF et de parcs OT. Pour la vue d'ensemble, voir notre guide complet de la cybersécurité de défense.

1. Pourquoi le PAM en défense est différent

Trois propriétés rendent le PAM de défense structurellement différent du PAM commercial. Premièrement, les utilisateurs sont multi-classification : le même opérateur humain peut détenir des comptes sur un LAN administratif non classifié, un réseau de mission SECRET et une enclave de renseignement TOP SECRET, et la plateforme PAM ne doit jamais arbitrer un identifiant à travers cette frontière. Deuxièmement, les workflows à plus haute valeur sont résidants en SCIF — l'utilisateur, le poste, le jump host et le coffre sont tous à l'intérieur de la même pièce accréditée, et tout composant qui vit en dehors du SCIF est, par définition, la mauvaise architecture. Troisièmement, l'attente de chaîne d'audit est bien plus stricte que dans le commercial : l'autorité d'accréditation n'accepte pas « nous avons des logs » — elle attend un enregistrement à preuve d'altération, rejouable, à rétention bornée de chaque action privilégiée, rattachée à un individu habilité, et survivable quand le réseau est hors ligne pendant des semaines.

La conséquence pratique est que « déployez CyberArk et c'est fini » — la réponse qui fonctionne dans la plupart des déploiements commerciaux — n'est pas la réponse en défense. Le choix de plateforme compte moins que la topologie de l'enclave, le modèle de brokering et le pipeline d'audit. Nous avons vu des organisations acheter le bon produit et échouer à l'accréditation parce qu'elles ont fusionné deux niveaux de classification dans un seul coffre.

2. CyberArk / HashiCorp Vault / BeyondTrust / Delinea

CyberArk reste l'incumbent pour les déploiements classifiés dans les organisations de défense des États membres de l'OTAN. Son Privileged Session Manager (PSM) est mature, validé FIPS 140-2, et l'Enterprise Password Vault détient une certification Common Criteria EAL4+ — deux items que l'accréditeur vérifiera en premier. Le coût est raide, et le modèle de licence suppose une connectivité à l'infrastructure de mise à jour CyberArk, ce qui force un workflow de mise à jour hors ligne à l'intérieur des enclaves air-gappées.

HashiCorp Vault (Enterprise) est le choix quand la charge de travail est pilotée par API, éphémère et adjacente à Kubernetes. Ses moteurs dynamic-secrets et PKI sont excellents pour l'émission X.509 à courte durée, ce qui est de plus en plus la façon dont les charges de travail de défense modernes s'authentifient. Vault Enterprise supporte le mode FIPS 140-2 et l'intégration HSM via PKCS#11. Sa faiblesse dans un contexte de défense est le brokering de session — Vault est un moteur de secrets, pas un proxy de session, donc un workflow admin interactif nécessite un composant séparé (Boundary, ou un bastion tiers) superposé.

BeyondTrust (Password Safe + Privileged Remote Access) a la meilleure histoire OT/ICS des quatre. Son modèle de jump host a été conçu pour l'accès distant géré par fournisseur dans les usines industrielles, ce qui correspond proprement aux workflows de maintenance en dépôt et de support OEM que les organisations logistiques de défense exécutent réellement. Validé FIPS 140-2 ; le pipeline d'enregistrement de session est le plus mature de tous les produits de cette catégorie.

Delinea (anciennement Thycotic + Centrify) est l'option plus légère, souvent choisie pour les sous-enclaves où l'empreinte CyberArk complète est exagérée. Secret Server est validé FIPS 140-2 ; la Server Suite couvre le bridging AD pour Linux/Unix dont dépendent encore les parcs de défense plus anciens.

Pour les quatre, la transition FIPS 140-3 est en cours — les validations 140-2 restent acceptées sous les règles transitoires jusqu'au cycle d'accréditation 2026 dans la plupart des contextes OTAN, mais les nouveaux déploiements devraient spécifier 140-3 quand le fournisseur l'offre. La couverture Common Criteria est inégale ; CyberArk et BeyondTrust ont les calendriers les plus profonds.

3. Brokering de session avec conscience de classification

La décision architecturale la plus conséquente dans le PAM de défense est de savoir si la plateforme arbitre des sessions à travers les frontières de classification — et la bonne réponse est toujours « non ». Chaque enclave reçoit son propre coffre, son propre gestionnaire de sessions et son propre store d'audit. L'identifiant du compte admin SECRET n'existe jamais dans le coffre non classifié, même chiffré, même « pour cas d'urgence ». Si l'accréditation trouve un seul enregistrement d'un identifiant de classification supérieure à l'intérieur d'un composant de classification inférieure, le déploiement entier repart à zéro.

L'escalade de session inter-enclaves — le workflow où un opérateur côté non classifié doit atteindre un hôte SECRET — est résolue à la frontière de la solution cross-domain (CDS), pas à l'intérieur de la plateforme PAM. L'opérateur s'authentifie à l'intérieur de l'enclave de classification supérieure ; la CDS ne passe pas d'identifiants à travers. La plateforme PAM de chaque côté ignore l'autre. Cela correspond proprement au modèle réseaux militaires zero trust où chaque enclave est son propre domaine de confiance.

Pour les workflows résidants en SCIF, le coffre, le gestionnaire de sessions et le collecteur d'audit vivent tous à l'intérieur du SCIF. La tentation d'héberger le plan de gestion en dehors du SCIF « pour faciliter l'administration » est la faute architecturale la plus courante que nous voyons, et elle est non récupérable — l'accréditeur n'approuvera pas un canal de gestion à distance vers un store d'identifiants résidant en SCIF, peu importe comment il est chiffré.

4. Élévation juste-à-temps (JIT)

L'élévation JIT est la discipline d'accorder un accès privilégié uniquement au moment où il est nécessaire, pour la durée où il est nécessaire, et de le révoquer automatiquement ensuite. Dans les réseaux de défense, elle remplace le motif de longue date « l'équipe de maintenance a Domain Admin en permanence parce qu'elle en a parfois besoin à 3 h du matin » — qui est exactement le motif qu'un adversaire à accès persistant exploite.

L'architecture a trois composants. Premièrement, un workflow de demande — typiquement intégré au système de ticketing — où l'opérateur demande l'élévation, avec une raison déclarée et une durée déclarée. Deuxièmement, un chemin d'approbation : pour la maintenance routinière, cela peut être automatisé par politique ; pour une urgence sur les systèmes OT ou le matériel de clé cryptographique, cela nécessite l'approbation d'un second opérateur habilité (principe des quatre yeux). Troisièmement, un mécanisme d'émission : la plateforme PAM frappe un identifiant borné en temps — un certificat SSH éphémère (typiquement 1–4 heures), un certificat client X.509 à courte durée pour l'accès API, ou une appartenance temporaire à un groupe AD qui expire sur un minuteur programmé.

Les certificats SSH éphémères sont le motif le plus propre pour l'administration Linux/Unix : la demande de l'opérateur déclenche Vault (ou l'équivalent CyberArk) à frapper un certificat signé par l'autorité de certification SSH, scopé à des hôtes spécifiques, avec une validité de 4 heures. Aucune clé publique à longue durée ne réside jamais sur l'hôte cible, et la révocation est automatique à l'expiration du certificat. Pour l'administration Windows, les certificats clients X.509 à courte durée combinés à des lecteurs de carte à puce atteignent la même propriété, exploitant la racine de confiance matérielle déjà présente sur la plupart des postes de défense.

5. Comptes de service et secrets

Les cadences de rotation recommandées par le fournisseur — 30 jours pour les comptes de service, 90 jours pour les secrets d'application, annuelles pour les clés CA racine — sont la partie facile. La partie difficile est la rotation sous air gap. Une entreprise connectée fait tourner un mot de passe de compte de service et le nouvel identifiant se propage à travers Active Directory, le store de secrets, l'application consommatrice et le système de monitoring en quelques secondes. À l'intérieur d'une enclave air-gappée, chacune de ces étapes est manuelle, planifiée et porteuse de risque — et la fenêtre de maintenance se mesure en heures à un seul chiffre, souvent la nuit, souvent avec un opérateur de secours en veille.

La réponse opérationnelle réaliste est des cadences par paliers : les identifiants à haute valeur (Domain Admin, CA racine, clés de déverrouillage KMS) tournent sur des horaires accélérés avec une discipline complète de contrôle de changement ; les identifiants à valeur moyenne (comptes de service de base de données, principals d'application) tournent via des workflows PAM automatisés pendant les fenêtres de maintenance planifiées ; les identifiants à faible valeur mais à longue durée (comptes d'applications héritées, mots de passe de périphériques embarqués) sont inventoriés, mis en coffre et rotés sur la cadence la plus lente que le registre de risque acceptera.

La réalité des identifiants à longue durée est celle que l'audit attrape toujours. Chaque parc de défense d'une certaine taille a une longue queue de comptes de service créés en 2014 pour un système que plus personne ne possède, avec le mot de passe dans une page wiki qui a été migrée quatre fois. Le déploiement PAM les découvre, et la découverte elle-même est la valeur — même si la rotation prend une autre année.

6. PAM pour OT / installations industrielles

La technologie opérationnelle — les systèmes de contrôle industriel exécutant la machinerie de dépôt, l'infrastructure d'alimentation de base, le stockage de carburant, et de plus en plus les lignes de fabrication alimentant la chaîne d'approvisionnement de défense — est l'environnement PAM le plus difficile dans toute organisation de défense. Trois motifs dominent.

Premièrement, l'architecture jump host : chaque connexion administrative dans le réseau OT se termine à un bastion durci qui arbitre le protocole (RDP, VNC, série-sur-IP), impose l'enregistrement de session, et isole le poste de l'opérateur du réseau de contrôle. Le produit Privileged Remote Access de BeyondTrust est l'implémentation de référence ici ; PSM for SSH de CyberArk et le motif open-source Apache Guacamole couvrent le même terrain à différents points de coût.

Deuxièmement, le problème du mot-de-passe-non-changé-depuis-15-ans. Les PLC, HMI et serveurs historian expédiés par l'OEM avec des identifiants par défaut ou rarement rotés, et les faire tourner risque de briquer l'appareil ou de casser un contrat de support fournisseur. La réponse pragmatique est de mettre l'identifiant en coffre (afin qu'au moins le chemin d'accès soit audité et que le cleartext soit retiré de la mémoire de l'opérateur et des post-it), de différer la rotation jusqu'à la prochaine fenêtre d'interruption planifiée, et de documenter le risque résiduel dans le dossier d'accréditation.

Troisièmement, l'accès distant géré par fournisseur. Les techniciens OEM doivent atteindre l'équipement pour le support de garantie. La plateforme PAM arbitre cela comme une session entièrement enregistrée, bornée en temps, arbitrée à travers le jump host — jamais un tunnel VPN permanent dans le réseau OT. Le compte du fournisseur est émis en JIT, la session est enregistrée de bout en bout, et l'opérateur habilité côté défense approuve et observe.

Insight clé : La plateforme PAM n'est pas le contrôle de sécurité. La chaîne d'audit accréditable l'est. Un coffre parfait avec un pipeline d'audit cassé échoue à l'accréditation ; un coffre modeste avec une chaîne d'audit ininterrompue et disciplinée en rétention passe. Concevez d'abord pour l'audit ; les workflows d'identifiants en découleront.

7. Chaîne d'audit et enregistrement de session

La chaîne d'audit est l'artefact qui importe le plus à l'autorité d'accréditation, et c'est celui que les déploiements PAM de défense sous-construisent le plus souvent. Trois couches comptent. La journalisation des frappes capture les commandes littérales qu'un opérateur a tapées dans une session privilégiée — inestimable pour la forensique, coûteux en stockage, et sujet à la discipline de rétention. L'enregistrement vidéo de session capture les images RDP/VNC rendues — non négociable pour les sessions SCADA/HMI où l'interaction de l'opérateur est graphique, pas textuelle. L'audit au niveau commande capture l'événement structuré (« l'utilisateur X a élevé au rôle Y sur l'hôte Z au temps T pour le ticket #N ») — la couche que le SOC consomme réellement dans la corrélation SIEM et la vérification zero-trust.

La discipline de rétention longue est l'endroit où les playbooks PAM commerciaux échouent. Les horizons de rétention de défense atteignent régulièrement 7–10 ans, parfois plus longtemps pour les contextes adjacents au nucléaire ou aux systèmes stratégiques. La couche de stockage doit être immuable (classe WORM, ou stockage objet à écriture unique avec verrous de rétention), l'intégrité doit être ancrée cryptographiquement (manifestes signés, logs chaînés par hash), et le chemin de récupération doit fonctionner en 2034 avec les personnes et l'outillage disponibles alors — pas les personnes disponibles aujourd'hui.

L'alignement RGPD et NIS2 compte dans les contextes de défense UE. L'enregistrement de session capture des données personnelles (les frappes de l'opérateur, parfois son visage sur une session webcam-activée). La base légale sous RGPD est typiquement « obligation légale » plus « intérêt légitime », avec des limites de rétention documentées et des contrôles d'accès. NIS2 renforce cela avec des exigences explicites de réponse à incident et de disponibilité d'audit que la journalisation PAM sert directement.

8. Migration et coexistence

Le calendrier réaliste pour amener un parc de défense AD-only dans le PAM moderne est de deux à quatre ans. La première année est la découverte et la mise en coffre : chaque identifiant privilégié est inventorié, mis en coffre, et amené sous workflow check-out/check-in, sans encore changer la façon dont les opérateurs travaillent. La deuxième année est le brokering de session : les sessions admin interactives se déplacent derrière le proxy PAM, l'enregistrement commence, et la chaîne d'audit entre en service. La troisième année est l'élévation JIT et la rotation : les privilèges permanents sont convertis en bornés en temps, et les cadences de rotation sont appliquées. La quatrième année, si nécessaire, est le nettoyage de la longue queue de comptes de service et d'identifiants OT.

La coexistence avec les motifs AD-only hérités est la norme, pas l'exception, pour la majeure partie de ce calendrier. La plateforme PAM arbitre l'accès aux hôtes joints à AD, met en coffre les identifiants AD, et remplace graduellement l'appartenance permanente à Domain Admin par l'élévation JIT via des groupes fantômes. Essayer de basculer tout le parc en un seul week-end a échoué chaque fois que nous l'avons vu tenté.

La leçon durement gagnée : un rollback PAM est pire qu'un déploiement lent. Une fois qu'une population d'opérateurs a été déplacée sur des workflows arbitrés par coffre, élevés JIT, entièrement audités, retourner au motif « Domain Admin en permanence » est opérationnellement et culturellement quasi impossible — le gap d'audit est visible, le SOC est venu à dépendre de la télémétrie, et le dossier d'accréditation a été mis à jour. Un déploiement partiel qui tient est meilleur qu'un déploiement complet qui doit être inversé. Planifiez les phases pour que chaque phase soit indépendamment stable, et traitez la cadence pluriannuelle comme une fonctionnalité, pas un bug.