Quels comptes à privilèges sécuriser en premier ? La méthode pour ne pas se tromper de priorité.

Un compte utilisateur classique consomme des services dans un périmètre prévu. Il devient sensible lorsque ses droits lui permettent de modifier un système, d’accorder un accès, de lire une donnée protégée ou d’agir sur une identité plus puissante. Le libellé « administrateur » n’est donc ni une condition nécessaire, ni une mesure suffisante du risque. Ce que vous cherchez à inventorier, ce n’est pas simplement une liste d’utilisateurs : c’est une carte des pouvoirs dans votre système d’information.

Un administrateur nominatif associe un accès à une personne ; il faut encore distinguer son identité quotidienne de son identité d’administration. Un administrateur partagé est utilisé par plusieurs intervenants : le compte cible ne suffit alors pas à attribuer une action. Le compte local dépend d’une machine ou d’une application plutôt que de l’annuaire central. Sa portée peut être restreinte, mais la réutilisation d’un secret ou le contrôle d’une machine critique change les conséquences possibles.

Les comptes techniques et de service exécutent des traitements. Les identités applicatives ou machine authentifient un workload, un robot ou une intégration, parfois sans mot de passe traditionnel. L’identité externe d’un prestataire doit être rattachée à un mandat et à une échéance. Le compte d’urgence répond à une panne ou une reprise : sa nécessité n’autorise pas un usage permanent sans contrôle. Pour chacune de ces familles, cherchez le responsable, le besoin réel et le pouvoir effectivement disponible.

Un rôle privilégié cloud représente un ensemble de permissions que différentes identités peuvent recevoir ou activer. Une clé SSH, un jeton API ou un secret est un moyen d’authentification ou une capacité d’accès, pas nécessairement un compte distinct. Notez le type de credential et son détenteur ou son consommateur, jamais sa valeur. Un même compte peut porter plusieurs clés et plusieurs pouvoirs ; une même identité peut assumer plusieurs rôles selon le contexte.

Distinguez privilège permanent et privilège temporaire : le premier reste disponible entre les opérations, le second dépend d’une activation et d’une durée. Un token court ne rend pas automatiquement temporaire l’autorisation qui permet de le renouveler. Examinez aussi les sessions existantes, la révocation et les autres mécanismes d’authentification. La fin d’une session PAM et la disparition d’un droit sur la cible sont deux événements différents.

Dans Active Directory, les membres effectifs des groupes fortement privilégiés méritent une attention immédiate. Mais le domaine de confiance comprend aussi les identités capables d’agir sur les contrôleurs de domaine, leurs données, leur système ou leur disponibilité. Une délégation de permission, un droit de réplication ou la capacité à modifier un groupe puissant peut offrir une voie indirecte. Une liste de Domain Admins protégés ne suffit pas à conclure que le contrôle de l’annuaire est maîtrisé.

Prenez l’administrateur de virtualisation. S’il peut ouvrir la console d’une VM hébergeant un DC, manipuler ses disques ou exploiter une copie de cette machine, il peut disposer d’un chemin de prise de contrôle sans appartenir à Domain Admins. Les possibilités exactes dépendent des rôles, de la séparation des fonctions, du chiffrement, des protections de la plateforme et des accès aux données. Inventoriez les capacités effectivement autorisées et les VM concernées ; ne transformez pas ce scénario en affirmation universelle.

Dans le cloud, cherchez les identités capables de modifier les politiques d’accès, les relations de confiance ou la fédération. Un rôle de gouvernance IAM peut changer qui reçoit un droit, même sans permission directe sur le service final. Il faut analyser l’interaction des politiques, des limites, des conditions et des refus explicites. Une possibilité déclarée dans une politique isolée n’est pas toujours une permission effective ; inversement, plusieurs permissions anodines séparément peuvent composer un pouvoir critique.

Les consoles de sauvegarde et les outils de sécurité sont également des points de contrôle adjacents. Selon les fonctions accordées, une identité peut exporter des données sensibles, restaurer une machine critique, déployer un agent ou modifier une politique de protection. Le pouvoir peut provenir de l’accès aux copies et aux consoles autant que de l’accès au système vivant. Reliez chaque administrateur d’outil aux actifs qu’il peut effectivement lire, modifier ou reconstruire.

Le terme Tier 0 sert à raisonner sur la confiance de l’environnement d’identité concerné. Il ne qualifie pas universellement tout hyperviseur, tout cloud ou toute sauvegarde. Justifiez la priorité par une chaîne de contrôle : identité, permission, interface, actif critique et conséquence. Pour une zone cloud indépendante, décrivez un niveau critique équivalent dans son propre domaine de confiance plutôt que de plaquer une classification AD sans explication.

Les comptes de service héritent de droits accordés pour résoudre rapidement un problème puis jamais réexaminés. Leur secret peut être référencé dans des scripts, des tâches planifiées ou des configurations. Cherchez ce que le traitement doit réellement accomplir, puis comparez avec ses groupes et délégations. La remédiation demande de connaître les consommateurs, les caches et les possibilités de retour arrière. La rotation immédiate d’un secret très partagé peut interrompre l’application sans réduire les droits excessifs.

Les comptes locaux Windows ne sont pas tous visibles dans le référentiel des comptes de domaine. Des mots de passe identiques entre machines peuvent faciliter des déplacements latéraux après une première compromission. Windows LAPS peut gérer les mots de passe des comptes locaux concernés, avec des possibilités et conditions spécifiques selon l’environnement. Vérifiez déploiement, lecture autorisée, rotation et cibles réellement couvertes. LAPS ne protège pas tous les comptes, tous les rôles ni tous les chemins d’administration.

Sous Linux et Unix, ne vous arrêtez pas à root. Les règles sudo, les groupes privilégiés, les délégations et les clés SSH créent d’autres chemins. Une commande autorisée peut offrir davantage que l’intention initiale selon ses arguments et les possibilités de l’exécutable. La configuration SSH décide des moyens et conditions de connexion ; la politique sudo décide d’une partie des élévations après connexion. Examinez ces surfaces séparément, avec l’équipe Linux, sans copier de clés privées dans le fichier.

Virtualisation et interfaces hors bande, notamment iLO, iDRAC ou équivalents, sont souvent gérées par des équipes distinctes. Leurs consoles peuvent agir sur des hôtes sensibles avant même le démarrage du système. Les bases de données comportent des administrateurs intégrés, nominatifs et parfois des identités applicatives trop puissantes. Pour ces familles, demandez qui utilise l’accès, quelles fonctions il autorise et si les interfaces alternatives échappent au parcours censé être contrôlé.

Le cloud exige de regarder rôles assumés, identités fédérées, workloads et possibilités d’élévation, pas seulement les utilisateurs créés à la main. Le CI/CD concentre le pouvoir d’édition d’un pipeline et celui d’exécuter un déploiement avec une identité machine. Enfin, un prestataire peut conserver un accès après la fin du besoin. Un compte sans propriétaire n’est pas seulement un problème administratif : personne ne peut correctement justifier son existence, ses droits et son maintien.

Partez des référentiels existants : Active Directory, Entra ID, LDAP, habilitations IAM, CMDB, consoles cloud et coffres ou PAM déjà en place. Notez pour chaque source sa date, son périmètre et ses limites. Un coffre décrit les accès gérés, pas nécessairement tous les accès disponibles. Une CMDB identifie des ressources, pas automatiquement les personnes ou workloads qui les contrôlent. La confrontation entre ces sources produit plus de valeur qu’une exportation présentée comme exhaustive.

Interrogez ensuite les équipes systèmes, réseau, bases de données, cloud et applications. Demandez quelles opérations elles réalisent, depuis quel terminal, avec quelle identité et sur quelle cible. Une question sur l’usage révèle souvent une console de secours, un script ou une délégation absente du référentiel central. Les propriétaires métier et les responsables de contrat aident à justifier les accès techniques ou externes. Documentez les divergences plutôt que de retenir automatiquement le fichier le plus récent.

La troisième étape consiste à établir les droits effectifs. Les appartenances directes ne suffisent pas : les groupes imbriqués, l’héritage et les délégations peuvent étendre le pouvoir. Le champ memberOf d’un objet AD ne donne pas, à lui seul, toutes les appartenances transitives. Côté cloud, la portée, les relations de confiance, les politiques applicables et les conditions participent à la décision. Faites confirmer le chemin de pouvoir avec les outils de consultation validés par l’organisation.

Examinez les identités non humaines avec leurs responsables applicatifs. Recherchez les références de comptes d’exécution, robots, clés, secrets et intégrations dans les configurations autorisées, sans exporter les valeurs sensibles. Puis confrontez l’inventaire aux usages observables lorsque les traces sont fiables : connexions, exécutions, changements et interventions. Un accès dormant peut justifier une revue, mais l’absence de trace ne prouve pas l’absence d’usage, notamment si la rétention ou la couverture est insuffisante.

Organisez enfin la découverte continue. Création d’une ressource, nouvelle application, changement de pipeline, nouveau rôle et fin de contrat doivent déclencher une mise à jour. Définissez qui signale le changement, qui confirme les droits et qui accepte la décision. Réexaminez aussi périodiquement les zones sans déclencheur fiable. Cette méthode repose sur la consultation autorisée, les configurations existantes et les outils validés ; elle ne fournit pas de scripts de scan actif à lancer aveuglément.

Attribuez un identifiant stable à la situation et utilisez un alias anonymisé pour les outils de ce site. Collectez famille, environnement, cible, propriétaire responsable, équipe utilisatrice et fonction du compte. Le propriétaire est celui qui peut justifier le besoin et arbitrer la modification, pas nécessairement la personne qui a créé le compte. Lorsque ce rôle est inconnu, écrivez « Inconnu » et désignez un responsable de recherche. Une cellule vide peut être interprétée à tort comme un point non applicable.

Décrivez droits ou rôles effectifs, portée du privilège et type d’authentification. Séparez accès nominatif, partagé ou machine, puis permanent ou temporaire. Ajoutez mode d’accès et exposition réseau : le risque change si une même interface est atteignable depuis un poste bureautique, une zone d’administration ou un accès externe. Mentionnez les chemins alternatifs connus. N’écrivez pas simplement « MFA » : précisez à quelle entrée il s’applique et si un autre chemin peut l’éviter.

Collectez contrôles existants et présence d’un PAM ou mécanisme équivalent avec leurs preuves et limites. Un LAPS déployé mais non vérifié n’est pas identique à une rotation éprouvée avec lecteurs du secret restreints. La dernière utilisation connue est facultative : elle dépend des traces disponibles et doit être accompagnée de leur portée. Ne la transformez pas en critère automatique de suppression. Documentez criticité argumentée, dépendances, action recommandée et état de traitement.

Le dictionnaire de l’inventaire distingue les champs obligatoires des champs facultatifs : dernière utilisation et preuve attendue peuvent rester non disponibles. Obligatoire signifie qu’une valeur ou une inconnue explicite doit être conservée ; cela ne crée pas une certitude. Pour un inventaire réel, les références nominatives et techniques restent dans votre environnement sécurisé, avec les droits de lecture appropriés. Les exemples et saisies de ce site doivent rester fictifs ou anonymisés.

Ne stockez jamais dans le modèle un mot de passe, une clé privée, un jeton ou une copie de configuration contenant un secret. Le fichier décrit le credential et son usage, pas sa valeur. Il devient déjà sensible par les chemins qu’il révèle : définissez propriétaire du référentiel, diffusion, protection et mise à jour. Une ligne représente une relation identité / pouvoir / cible ; plusieurs lignes peuvent être nécessaires pour ne pas masquer des portées très différentes.

Évaluez d’abord le risque selon quatre dimensions : pouvoir effectif, exposition, persistance ou réutilisation du privilège, insuffisance des contrôles. Chaque dimension reçoit une valeur de 0 à 4 justifiée par la situation. La somme sur 16 sert à organiser une conversation, pas à produire une certification. Un administrateur local correctement isolé sur une cible peu sensible et un administrateur local sur une infrastructure d’identité n’ont pas nécessairement le même pouvoir ni les mêmes conséquences.

Les seuils de Mon Premier PAM sont une convention pédagogique : 0 à 4, risque relativement limité selon cette grille ; 5 à 8, vigilance modérée ; 9 à 12, risque élevé ; 13 à 16, risque critique. Ils ne constituent pas un standard ISO, NIST ou ANSSI. Si une dimension est inconnue, l’outil affiche « À qualifier » sans score complet. Un zéro correspond à une situation documentée de faible contribution au risque, pas à une information manquante.

Évaluez séparément la préparation : dépendances applicatives, complexité technique, disponibilité du propriétaire, possibilité de tester et risque d’interruption. Documentez les blocages avant de proposer une opération. Une difficulté faible indique que l’action paraît préparable, pas qu’elle peut être exécutée immédiatement sans autorisation. Une difficulté inconnue impose de préparer les prérequis. Le score de risque conserve exactement la même valeur quelle que soit la difficulté déclarée.

Trois décisions structurent les cas suffisamment qualifiés. « Sécuriser en priorité » concerne un risque important avec action rapidement préparable. « Préparer une remédiation prioritaire » concerne un risque important avec dépendances ou validations à traiter. « Planifier dans une vague suivante » concerne un risque moins immédiat selon cette grille, tout en vérifiant les contrôles existants et le risque résiduel. Les inconnues restent hors du classement chiffré jusqu’à qualification.

La matrice explique son calcul et ses facteurs. Elle place les scores à partir de 9 dans la priorité immédiate si la difficulté est faible, sinon dans la préparation prioritaire. Les scores 0–8 alimentent une vague suivante. Cet ordre reste un outil d’arbitrage : une évolution d’exposition, un incident ou une faiblesse omise peut changer la décision. Révisez les valeurs lorsqu’une preuve nouvelle apparaît et conservez la justification, pas seulement le nombre.

Commencez par la nécessité : quel usage actuel justifie cette identité ? Si le besoin a disparu, préparez la suppression avec les vérifications de dépendances et une preuve de clôture. L’absence d’usage connu n’est pas suffisante lorsque les traces sont incomplètes. Si le compte reste nécessaire, demandez si ses droits le sont aussi. Réduire une permission globale à l’opération attendue peut apporter davantage que conserver le même pouvoir derrière un nouveau point d’entrée.

Examinez les protections natives adaptées. Windows LAPS, un rôle temporaire natif ou une politique de délégation peuvent déjà traiter une partie du besoin lorsqu’ils sont réellement appliqués et vérifiés. Le compte peut nécessiter un coffre et une rotation, un chemin de session sécurisé, ou une transformation vers des droits temporaires. Ces décisions ne sont pas exclusives : la gestion du secret, la politique de droits et le filtrage réseau répondent à des couches différentes.

Pour un accès humain, vérifiez identité de départ, terminal, authentification, autorisation d’activité, cible et retrait final. Pour une identité machine, vérifiez consommateurs, permissions, mécanisme de renouvellement et comportement en erreur. La rotation n’annule pas nécessairement une session déjà établie ; la fermeture d’un bastion ne bloque pas automatiquement une API accessible autrement. Les voies de secours doivent rester utilisables, distinctes et surveillées, sans devenir des accès quotidiens non maîtrisés.

Cinq décisions résument le traitement : supprimer, réduire les droits, sécuriser, transformer l’accès ou reporter sous contrôle. Le report est une exception documentée, pas une disparition du risque. Indiquez motif, responsable, mesure compensatoire, échéance et réexamen. Pour un compte de service, la première étape peut être une cartographie et une réduction des droits avant une rotation contrôlée. Le projet doit pouvoir expliquer pourquoi l’opération proposée respecte les dépendances sans abandonner la priorité.

Sélectionnez les risques significatifs pour le domaine de confiance retenu. Dans l’ETI fictive du premier chantier — 180 serveurs Windows, 30 Linux, 12 administrateurs internes, 2 prestataires, AD, virtualisation et services historiques — DA-PILOTE et VIRT-DC donnent des chemins critiques compréhensibles. La petite zone cloud complète ici le scénario pédagogique, sans prétendre constituer un environnement client. Les 13 lignes de l’inventaire représentent des situations, pas un dénombrement complet du SI.

Un pilote doit être important et testable : propriétaire disponible, cible représentative, usage légitime réalisable et refus vérifiables. Isolez les cas dépendants d’applications dans une préparation prioritaire parallèle. Le compte de service à 15/16 n’attend pas passivement la fin du pilote : cartographie, validation de besoin et préparation du changement commencent avec son équipe. Les actions immédiates et les préparations spécifiques peuvent avancer simultanément selon les ressources du programme.

Affectez à chaque action un responsable, les prérequis et la preuve de remédiation. Pour un chemin d’administration, démontrez que l’intervention autorisée fonctionne, que l’origine interdite est refusée et que le droit final correspond au besoin. Pour un compte de service, démontrez que les consommateurs restent fonctionnels, que les droits excessifs sont retirés et que l’ancien moyen d’accès est traité selon le scénario. Une preuve porte sur un résultat, pas seulement sur une case de configuration.

Préparez enfin l’intégration continue : nouvelle ressource, changement de rôle, nouvelle automatisation et fin de contrat déclenchent une revue. Conservez les zones non couvertes et faites réexaminer les exceptions. Le cadrage du premier projet décrit le périmètre et les critères de recette ; l’inventaire explique quels pouvoirs doivent y entrer et pourquoi. Reliez les deux documents plutôt que de lancer un chantier indépendant qui oublie les chemins d’administration et les responsabilités de RUN.