Vos comptes les plus dangereux ne s’appellent pas forcément administrateur

Les dix comptes Domain Admins peuvent être suivis dans votre PAM pendant qu’une autre identité conserve un accès aux VM hébergeant les contrôleurs de domaine. La plateforme de virtualisation n’est pas un simple fournisseur de capacité : les fonctions console, disque, instantané et restauration peuvent agir sur le système et ses données. Le pouvoir exact dépend des droits attribués et des protections réellement mises en œuvre. Tous les administrateurs d’hyperviseurs ne disposent pas automatiquement de toutes ces capacités.

Dans le cas fictif VIRT-DC, les permissions console et manipulation de disque sont autorisées sur les VM de DC. Le risque provient de cette relation avec les actifs de confiance. Un environnement qui sépare ces fonctions et protège les données peut présenter une autre situation. La découverte doit donc relier identité, rôle, interface et VM critique. Étiqueter toute virtualisation « Tier 0 » évite précisément la question qu’il fallait poser : quels actifs cette identité peut-elle contrôler ?

La première décision est de confirmer la portée, limiter les fonctions injustifiées et maîtriser les chemins console et API. Prévoir un secours avant fermeture. La recette ne se réduit pas à une connexion réussie au portail : elle vérifie aussi le refus depuis une origine interdite et l’impossibilité d’agir sur une VM exclue.

Une application n’a besoin que d’exécuter une opération ciblée, mais son compte garde des droits de domaine accordés lors d’une mise en service ancienne. Le secret peut être utilisé sur plusieurs serveurs, dans des tâches et des configurations. L’identité ne s’appelle pas administrateur et aucune personne ne l’utilise quotidiennement ; elle reste pourtant un moyen de réutiliser un pouvoir élevé si un consommateur est compromis.

SVC-AD-SCRIPTS obtient 15/16 dans la grille pédagogique, parce que le scénario décrit pouvoir de domaine, plusieurs consommateurs, secret durablement réutilisable et absence de contrôles éprouvés. Ce score n’est pas attribué au nom « compte de service ». Si les droits, l’exposition ou les contrôles changent, il faut recalculer. La difficulté élevée ne fait pas descendre ce risque ; elle indique que la remédiation commence par une préparation spécifique.

Une rotation brutale peut laisser des caches, interrompre des services ou déclencher une remise en place incontrôlée de l’ancien secret. Identifier le propriétaire et les consommateurs, confirmer les droits nécessaires, tester la réduction puis préparer le renouvellement et le retour arrière sont des actions prioritaires. La bonne séquence tient compte de l’exploitation sans transformer la dépendance en exception permanente.

Une identité qui ne porte pas le rôle « Administrateur global » peut quand même modifier une politique, une relation de confiance ou une configuration de workload qui conduit à un pouvoir sensible. L’inventaire doit inclure identités fédérées, rôles assumés, habilitations éligibles et identités machine. Il doit aussi distinguer permission déclarée et permission réellement utilisable dans le contexte considéré.

Dans AWS, l’évaluation combine différents types de politiques ; les refus explicites, limites de permissions, contrôles d’organisation et conditions peuvent empêcher une action. Un rôle intercomptes ajoute l’examen de la relation de confiance et des permissions du principal. Il serait faux de déduire un chemin d’élévation à partir d’un allow isolé. Il serait tout aussi incomplet de regarder uniquement le rôle actif en oubliant une capacité à modifier la politique qui le définit.

CLOUD-POLICY est fictivement capable de modifier une politique appliquée à une identité de déploiement. La décision est d’examiner toute la chaîne, de confirmer conditions et portée, puis de retirer la combinaison injustifiée. Une consultation autorisée et une validation architecturale sont nécessaires : l’outil de priorisation du site ne découvre ni ne teste ces permissions dans votre infrastructure.

Une console CI/CD peut modifier ce qui sera exécuté avec une identité de déploiement. Une console de sauvegarde peut donner accès à des copies critiques ou permettre une restauration. Un outil de sécurité peut modifier des politiques ou piloter des agents. Ces points de concentration ne sont pas forcément recensés parmi les comptes administrateurs des serveurs finaux ; leurs opérateurs peuvent néanmoins agir sur ces serveurs par une autre voie.

CI-DEPLOY combine dans le scénario une capacité de modification du pipeline et l’usage d’une identité puissante lors de la livraison. Un secret correctement conservé ne suffit pas si une personne peut changer librement l’opération qui le consomme. BACKUP-CTRL doit être évalué selon ses fonctions d’export et de restauration des sauvegardes de DC, non selon la seule présence du MFA. Les contrôles pertinents portent sur la séparation des fonctions, les approbations et les ressources accessibles.

Commencez par relier opérateurs, fonctions autorisées, identités d’exécution et cibles. Limitez les pouvoirs d’édition et d’approbation, examinez les interfaces alternatives et exigez une preuve sur le résultat. Les journaux de la console et ceux de la cible peuvent devoir être corrélés ; aucun enregistrement de session ne couvre automatiquement ce qui est exécuté ailleurs par une automatisation.