Pourquoi les programmes PAM n’en finissent jamais

Situation fictive : trois ans après l’achat du PAM, l’équipe découvre encore des comptes. Chaque nouvelle application réouvre l’objectif « tous les comptes du SI ». La liste n’est pas seulement incomplète : elle est vivante. Une cible sans frontière ni date de référence ne permet donc pas de décider ce qui peut être accepté aujourd’hui.

Il faut séparer trois objets : un premier palier de sécurité borné et recetté, des vagues successives d’extension, puis un processus permanent pour les nouveaux systèmes et identités. Le programme continue ; le premier projet peut se terminer. Une vague acceptée ne constitue pas une sécurité définitive de toute l’entreprise.

La Definition of Done PAM porte sur des contrôles en fonctionnement et leur exploitation. Une configuration terminée n’est pas une acceptation. L’écart restant doit avoir une décision, un propriétaire et une revue ; il ne disparaît pas parce que la vague change de nom.

Le propriétaire envoie un Excel partiel. L’équipe PAM demande la famille de compte, la cible, les dépendances et la rotation. Le ticket revient plusieurs jours plus tard. La configuration commence ; la recette révèle un consommateur oublié. Le même expert reprend l’analyse. Chaque demande ressemble à un petit projet indépendant.

Le problème se situe avant la configuration : pas de contrat d’entrée, pas de propriétaire confirmé, modèle de compte inconnu et validations tardives. Les tests arrivent après le changement, et la procédure existe surtout dans la mémoire d’un expert. Ajouter des personnes accélère éventuellement la collecte ; cela ne rend pas le processus reproductible.

Une demande structurée doit indiquer ce qui est obligatoire et pourquoi. Le contrôle de complétude renvoie un motif précis. Une procédure par scénario fixe les contrôles standardisables, les tests et les décisions humaines. Un compte de service dépendant ne suit pas aveuglément la procédure d’un administrateur nominatif. Industrialiser ne signifie ni automatiser un risque inconnu ni supprimer les validations métier.

Un compte technique partagé possède des droits excessifs et un secret ancien. Plusieurs applications, tâches et scripts semblent l’utiliser, mais personne ne peut confirmer l’ensemble des consommateurs. Sa présence dans le coffre ne donne pas au PAM la connaissance des dépendances. Changer le secret sur l’annuaire sans mettre à jour chaque consommateur peut interrompre la production.

Commencer par le propriétaire, puis confronter la configuration des services, tâches, scripts et connexions avec les journaux et les équipes applicatives. Qualifier les droits réellement nécessaires et les délégations. Une absence d’activité dans une courte fenêtre ne prouve pas qu’un traitement mensuel ou un secours n’utilise plus le compte.

La stratégie peut combiner réduction des droits, segmentation des usages, remplacement progressif ou mécanisme natif compatible. Préparer les tests et le retour arrière, faire valider la fenêtre, modifier dans un cadre contrôlé puis vérifier chaque service dépendant et le suivi post-changement. Une difficulté élevée n’abaisse pas le risque ; elle justifie une préparation prioritaire.

Le coffre remet le secret à une personne identifiée, ou le bastion ouvre une session autorisée. Pourtant, le même compte peut encore fonctionner en RDP ou SSH depuis une autre zone réseau. Les règles de la cible et le filtrage acceptent alors une voie que la politique PAM ne décide pas. Le bastion ne peut pas enregistrer une session qui ne le traverse pas.

Recenser les accès directs, les réseaux d’administration trop larges, les identités partagées et les accès prestataires permanents. Qualifier les chemins de secours séparément : ils doivent rester disponibles dans le scénario de panne prévu, mais leur usage doit être attribuable, autorisé et revu. Un accès direct interdit n’est pas une exception autorisée par simple inscription dans un registre.

Le contrôle résulte d’une combinaison : identité, terminal, autorisation, filtrage réseau, restrictions cible, traces et retrait. Tester la réussite sur le chemin prévu et le refus sur les autres voies recensées. Si une voie ne peut pas être fermée immédiatement, documenter le risque résiduel, les mesures compensatoires, le décideur et le réexamen.

La sécurité exige une rotation. Le PAM demande les dépendances. L’application attend une fenêtre de production. L’infrastructure demande qui accepte le risque, et l’IAM attend la confirmation du besoin. Sans décideur nommé, chaque équipe peut avoir correctement exécuté son rôle local sans que le changement soit décidé.

Le propriétaire applicatif explique le besoin, les contraintes et les consommateurs. L’IAM gouverne le cycle de vie et les droits ; le PAM définit et opère les contrôles privilégiés. L’infrastructure valide les conditions techniques, la sécurité fixe et vérifie les exigences, le RUN accepte l’exploitation et le SOC exploite les traces et les alertes selon son périmètre.

Cette répartition varie selon l’organisation : la matrice ci-dessous n’est pas un RACI obligatoire. Il faut surtout attribuer chaque décision structurante, sa preuve et son escalade. Une demande sans propriétaire ne doit pas être considérée comme correctement qualifiée. Nommer « l’équipe PAM » partout ne résout ni la propriété du service ni l’acceptation du risque.

Le tableau de bord affiche davantage de comptes en coffre et d’intégrations. Mais il ne dit pas quelles intégrations ont été testées, quels chemins restent contournables ou quelles exceptions n’ont pas de responsable. Les comptes déclarés, configurés et acceptés sont additionnés sous la même étiquette. Une progression réelle de déploiement devient une promesse de maîtrise non démontrée.

La couverture et les volumes restent utiles : il ne faut pas les supprimer. Les compléter par des chemins vérifiés, une couverture opérationnelle, le délai complet, les reprises, les exceptions non maîtrisées et les retraits prouvés. Chaque calcul doit afficher le même périmètre au numérateur et au dénominateur, la période et les limites connues.

Le délai commence à la demande initiale, pas à la création du dernier ticket technique. La révocation se termine par une vérification des droits, sessions ou jetons selon le service, pas par la fermeture administrative. Une revue RUN utilise ces mesures pour décider une correction, l’attribuer et vérifier son effet ; aucun seuil universel de maturité ne peut remplacer ce travail.

Entreprise entièrement fictive : 180 serveurs Windows, 30 Linux, Active Directory, virtualisation, quelques ressources cloud, 12 administrateurs internes, deux prestataires et plusieurs comptes de service historiques. Le PAM protège déjà une partie des accès critiques. L’extension dépend de demandes manuelles, de validations applicatives et de dépendances non cartographiées ; des chemins directs subsistent.

Avant : le programme est surtout piloté par les comptes intégrés, les tickets et un backlog global. Après, dans la démarche proposée : une vague critique est bornée, son entrée standardisée, les exceptions qualifiées, les décisions attribuées et l’acceptation liée à des tests. Il ne s’agit pas d’un résultat observé : c’est un ordre de travail réutilisable.

Le compte de service complexe reste prioritaire, mais sa modification attend une préparation vérifiée. Le chemin direct est traité avec l’infrastructure plutôt que masqué par un compte en coffre. Une demande acceptée transmet au RUN ses procédures, ses preuves et ses limites. Les chiffres du jeu d’indicateurs fictif illustrent les calculs, pas des gains avant / après.

Un programme PAM qui s’étend sans jamais stabiliser ses méthodes d’intégration finit par consommer sa propre capacité d’évolution.

Il faut donc arrêter de considérer l’onboarding comme une succession de projets techniques et commencer à le traiter comme un processus opérationnel structuré.

Le vrai passage à l’échelle ne consiste pas à embarquer davantage de comptes par effort exceptionnel. Il consiste à rendre chaque nouvelle intégration prévisible, vérifiable et reproductible.

Les procédures, figures, formules et répartitions de responsabilités sont des propositions éditoriales Mon Premier PAM / Ariovis. Les situations et calculs sont fictifs ; aucun gain client ni résultat de terrain n’est revendiqué. Sources publiques vérifiées le 23 octobre 2026.

Microsoft recommande d’attribuer un propriétaire aux comptes de service, de documenter leur usage, leurs ressources et leurs permissions et de suivre leurs activités. Ces recommandations ne prouvent pas qu’une rotation ou une suppression est sans impact. NIST propose des contrôles de gestion des comptes et de retrait d’autorisation à adapter, pas une prescription de produit ni une certification PAM.

• Microsoft — gouverner les comptes de service locaux ↗ — nouvelle fenêtre
• Microsoft — gouverner les comptes de service Entra ↗ — nouvelle fenêtre
• NIST SP 800-53 Rev. 5 — gestion des comptes et contrôle d’accès ↗ — nouvelle fenêtre
• Ariovis — chemins d’administration adaptés au risque ↗ — nouvelle fenêtre

PAM FastTrack et CyberArk Blueprint sont des références conceptuelles du cadrage fourni ; les supports propriétaires n’ont pas été consultés directement ici. Aucun document client confidentiel n’a été utilisé pour publier des détails opérationnels ou des retours d’expérience. Pour reproduire ou adapter une figure, demander une autorisation conformément aux mentions légales.