Service Accounts With Standing Administrative Privileges

Des comptes de service — identités non humaines utilisées par des applications, des tâches planifiées, des agents, des intégrations — détiennent des privilèges d’administration permanents, souvent au niveau le plus large : administration de l’annuaire, de la plateforme de sauvegarde, du parc entier.

C’est structurel : au déploiement d’un produit, accorder le privilège maximal est le chemin qui « marche du premier coup », et la documentation d’installation le demande parfois explicitement. Personne ne revient réduire ensuite, car le compte « appartient » à l’application, pas à une personne — il échappe aux revues d’accès conçues pour les humains, aux départs, aux recertifications. S’ajoutent des propriétés aggravantes par nature : secret ancien et rarement tourné (la rotation casse des choses), MFA impossible, et une activité légitime automatisée, massive et nocturne — le camouflage parfait.

Ces comptes sont une cible prioritaire de l’élévation de privilèges : leurs secrets se récoltent — mémoire des machines où ils s’exécutent, fichiers de configuration, définitions de tâches planifiées — et leur usage malveillant se fond dans leur activité normale. Un compte de service qui se connecte à quarante machines pendant la nuit est normal : c’est son travail. Le même motif, produit par un attaquant, ne détonne pas.

Deux conséquences spécifiques en incident :

• la détection comportementale est affaiblie précisément sur les comptes les plus puissants : leur base d’activité « normale » est si large que presque tout y ressemble ;
• la remédiation est douloureuse : tourner le secret d’un compte de service administrateur casse les applications qui en dépendent — dépendances que personne n’a documentées. La rotation est donc différée pendant l’incident, laissant à l’attaquant un accès à privilèges que toute l’équipe connaît et que personne n’ose fermer.

Partir de l’annuaire, pas de l’inventaire déclaratif :

• extraire les membres des groupes d’administration et isoler les non-humains : convention de nommage, absence de connexion interactive, ancienneté du mot de passe ;
• pour chacun : qui peut expliquer ce qu’il fait ? de quels droits a-t-il réellement besoin — souvent des droits précis sur des objets précis, pas l’administration globale ? quand son secret a-t-il été changé ? depuis quelles machines se connecte-t-il légitimement ?

Le compte que personne ne peut expliquer mais que personne n’ose toucher est la signature du pattern — le noter tel quel dans le constat.

Compléter par la chasse aux secrets exposés : mots de passe de comptes de service en clair dans des scripts, des fichiers de configuration, des définitions de tâches — chaque occurrence est un point de collecte offert à l’attaquant.

Quatre chantiers, par ordre de rendement :

• inventaire avec propriétaire : chaque compte de service a un responsable nommé, une fonction documentée, et une liste des systèmes qui en dépendent — c’est cette liste qui rend la rotation possible le jour où elle est urgente ;
• réduction au privilège réel : déléguer des droits précis plutôt qu’une appartenance aux groupes d’administration ; la plupart des produits fonctionnent avec moins que ce que leur guide d’installation réclame ;
• rotation outillée : coffre de secrets, ou comptes de service gérés par la plateforme d’identité quand le mécanisme existe — la rotation qui ne casse rien est celle qu’on peut faire souvent ;
• restriction et détection : un compte de service se connecte depuis ses machines, vers ses cibles ; une connexion interactive avec un tel compte est une alerte, pas un événement. Et aucune création de compte de service privilégié sans revue.

Les comptes de service à privilèges entrent dans le périmètre par défaut :

• relire leur activité sur la fenêtre de compromission en cherchant les écarts à leur routine : nouvelles machines cibles, connexions interactives, horaires inhabituels, actions hors de leur fonction — la routine étant large, ce sont les écarts qui parlent ;
• couper d’abord l’utilisabilité, tourner ensuite : restreindre immédiatement les origines réseau autorisées du compte, retirer les droits non nécessaires à sa fonction, interdire sa connexion interactive et journaliser finement. Ces gestes sont réversibles et ne cassent pas les dépendances inconnues ;
• la rotation du secret suit, planifiée avec l’équipe applicative — mais elle ne conditionne plus le confinement. Une restriction imparfaite tout de suite vaut mieux qu’une rotation parfaite dans douze heures ;
• après rotation, vérifier dans les journaux que l’ancien secret n’est plus utilisé nulle part : un échec d’authentification répété révèle à la fois une dépendance oubliée et, parfois, l’attaquant qui retente.