Pourquoi certains projets PAM n’en finissent jamais

Un comité suit le nombre de comptes embarqués. Le coffre se remplit ; de nouvelles cibles apparaissent ; les administrateurs maintiennent leurs accès directs pour travailler. Chaque réunion conclut qu’il reste trop de choses à faire pour passer en exploitation. Le problème n’est pas nécessairement le logiciel. Le projet n’a peut-être jamais défini ce qui le rendrait terminé.

Cette analyse est éditoriale. Les situations décrites sont des mécanismes possibles, pas des statistiques de marché ni des cas clients. Il ne s’agit pas de minimiser les incompatibilités techniques : elles existent. Mais changer de produit ne résout pas un propriétaire absent, un flux de secours non décidé ou un périmètre sans limite.

Le périmètre final remplace le premier résultat

« Sécuriser tous les comptes privilégiés » donne une direction de programme, pas un livrable de premier palier. Dès qu’un nouveau compte est trouvé, la cible recule. L’inventaire devient une condition préalable à toute réussite, alors même que les usages et les systèmes évoluent. On finit par confondre l’acceptation d’un périmètre maîtrisé avec la disparition de tout risque dans le SI.

Dans l’ETI fictive de notre guide — 180 serveurs Windows, 30 Linux, 12 administrateurs et 2 prestataires — l’administration AD et les hyperviseurs hébergeant les DC forment un lot critique cohérent. La rotation de tous les comptes de service historiques n’a pas à être terminée pour accepter ce lot. En revanche, un accès direct de prestataire vers ces mêmes cibles ne peut pas être ignoré simplement parce que les prestataires sont annoncés dans une vague ultérieure.

Le nombre de comptes masque la maîtrise des chemins

Le nombre de comptes embarqués mesure une activité. Il ne mesure pas, seul, la réduction du risque. Le secret peut rester dans un script ; un administrateur peut connaître l’ancien mot de passe ; une console peut ouvrir la cible hors du parcours ; un rôle global peut rester attribué après une session enregistrée. Un coffre rempli devient alors une réussite déclarative.

Remplacer ce pilotage exclusif par des preuves liées aux risques : une intervention autorisée fonctionne ; une cible hors périmètre est refusée ; un accès direct interdit échoue ; le droit effectivement accordé est limité puis retiré ; une trace peut être reliée à une personne et une ressource. Garder le volume comme indicateur d’avancement, avec un inventaire et des familles de risque, pas comme critère unique de sécurité.

Les dépendances applicatives sont découvertes au moment de la rotation

Un compte dit « technique » peut alimenter des tâches planifiées, plusieurs scripts, un service Windows et une intégration distante. Son propriétaire réel est parfois différent du propriétaire du serveur qui l’héberge. Stocker son secret ne révèle pas automatiquement les consommateurs. Le premier changement de mot de passe peut donc interrompre une fonction mal inventoriée.

Avant modification, recenser les consommateurs, les modes de stockage, les caches, les horaires d’exécution et les moyens de test. Faire valider la propagation du nouveau secret et le retour arrière par l’équipe applicative. Sur environnement adapté, déclencher la rotation, vérifier les consommateurs et provoquer un échec contrôlé pour éprouver l’alerte. Ce travail appartient à un lot préparé, pas à une migration aveugle destinée à faire monter le compteur.

Si la dépendance reste inconnue, documenter le report avec un propriétaire et un risque résiduel. « Nous verrons plus tard » n’est pas une décision exploitable. Un report responsable a une échéance de réexamen et des mesures temporaires adaptées.

Les administrateurs maintiennent les chemins directs

Le parcours PAM peut être approuvé sur un schéma et inutilisable pendant une intervention réelle : outil absent, protocole mal couvert, transfert de fichier impossible ou session trop limitée pour une opération légitime. Les administrateurs conservent alors un chemin de travail parallèle. Il contourne les contrôles et devient progressivement la procédure habituelle.

Faire réaliser des opérations représentatives avant de fermer les flux directs : maintenance, redémarrage, accès console et diagnostic en mode dégradé. Adapter le chemin normal aux besoins autorisés, sans donner automatiquement des droits globaux. Concevoir le secours pour les pannes identifiées puis le tester. Le réseau et les propriétaires de cibles doivent participer : le bastion, à lui seul, ne bloque pas les autres interfaces.

Fermer sans alternative peut créer un incident ; laisser ouvert sans contrôle maintient le risque. L’arbitrage consiste à rendre le chemin sécurisé praticable et à encadrer le secours, pas à choisir entre sécurité et exploitation.

Chaque nouvelle cible devient un projet particulier

Si l’intégration repose sur les connaissances d’un seul opérateur, la deuxième vague répète les découvertes de la première. Un port est ajouté manuellement, les droits du connecteur changent selon la cible, les journaux ne sont pas collectés de la même manière. L’onboarding produit des exceptions avant de produire une méthode.

Décrire une fiche de prérequis par famille : identité, réseau, protocole, droit d’intégration, politique d’activité, traces et tests de sortie. Versionner les configurations non secrètes dans l’environnement interne prévu et conserver les secrets dans leur canal approprié. Faire intégrer une nouvelle cible par un autre opérateur à partir de la procédure. Les écarts détectés deviennent des corrections de la méthode, plutôt que des connaissances tacites.

L’automatisation n’est utile qu’après cette clarification. Automatiser une configuration non comprise multiplie les erreurs. Une famille incompatible mérite un traitement distinct : ne prétendez pas reproduire un contrôle de session sur une interface que le dispositif ne couvre pas.

Les exceptions n’ont ni fin ni propriétaire

Une règle de pare-feu temporaire, un rôle permanent conservé « pendant les tests », un compte partagé utilisé pour le secours : chaque exception peut avoir une raison valable. Sans responsable, échéance et contrôle compensatoire, elles s’accumulent jusqu’à devenir l’architecture réelle. La recette officielle ne correspond alors plus au système exploité.

Tenir un registre qui précise motif, ressource, pouvoir accordé, responsable, risque, compensation, échéance et décision de renouvellement ou de fermeture. L’autorité compétente accepte le risque ; l’équipe technique ne transforme pas silencieusement une anomalie en exception. Un test non réalisé reste non testé. Un non-applicable doit être justifié par le périmètre ou le mécanisme retenu.

Le BUILD ne transmet pas un service au RUN

Le projet a configuré les composants mais personne n’a accepté leur exploitation. Qui surveille les échecs de retrait des droits ? Qui traite un certificat expiré, restaure la configuration ou assiste un administrateur bloqué ? Qui sait si un enregistrement est réellement consultable et si sa conservation reste conforme aux choix de l’organisation ?

Préparer le dossier RUN pendant le déploiement : support, supervision, sauvegarde, reprise, gestion des changements, droits d’administration du PAM, procédures d’onboarding et de secours. Simuler une indisponibilité dans un cadre contrôlé ; vérifier l’alerte, la prise en charge et le retour à l’état nominal. Une équipe RUN nommée et disponible vaut mieux qu’une procédure laissée dans un dossier sans lecteur.

Terminer un palier, puis élargir

1. Réduire le périmètre à un lot cohérent. Garder les chemins alternatifs donnant le même pouvoir dans le raisonnement ; reporter les autres lots avec un responsable.
2. Formaliser les critères de réussite. Utiliser des résultats observables et les 20 tests de recette. Les échecs critiques appellent une correction, pas une hausse du volume embarqué.
3. Stabiliser l’intégration. Reproduire une cible, corriger les prérequis et expliciter les différences entre familles.
4. Confier le palier au RUN. Faire accepter les responsabilités, les alertes, le secours et la reprise ; conserver un PV et des risques résiduels connus.
5. Élargir progressivement. Réévaluer la criticité et les dépendances à chaque vague ; envisager JIT, ZSP ou secrets techniques dès que les conditions sont réunies.

Un projet fini n’est pas un programme abandonné. C’est un périmètre dont les limites et les preuves sont connues, que l’organisation sait exploiter. La suite devient alors une progression à partir d’un socle stable, non la prolongation d’une installation sans point d’acceptation.

Pour repartir sur cette base, utiliser le guide du premier projet PAM, la note de cadrage remplie et la feuille de route pédagogique. Leur rôle est de rendre les décisions explicites, pas de promettre un calendrier universel.