Un compte de service peut continuer de fonctionner longtemps après le départ de la personne qui l’a créé. Son usage régulier rassure parfois l’exploitation, alors même que personne ne sait quel traitement s’arrêterait si on le désactivait ni pourquoi il dispose encore d’un privilège étendu. Une revue utile attribue à cette identité non humaine un service, un propriétaire capable de décider, des permissions comprises et une prochaine date de décision.
Cette page propose un registre et un protocole de revue. La politique de mots de passe traite les secrets et moyens d’authentification ; le dossier de revue des accès privilégiés examine les droits. Le présent travail relie surtout le compte à l’application, aux dépendances et à une personne responsable de son cycle de vie. La documentation Microsoft sur la gouvernance des comptes de service Entra recommande propriétaire, but, permissions, lien CMDB, risque, période de revue et durée de vie. Ce sont des recommandations pour cet environnement, à adapter aux autres plateformes.
Définir ce que vous appelez un compte de service
L’inventaire peut comprendre identités managées, principaux de service, comptes utilisateurs employés par une tâche automatique, comptes locaux, comptes de base de données et identités créées par un fournisseur. Leur mécanisme d’authentification diffère, mais la question de gouvernance reste proche : quelle application agit, sur quoi, et qui peut l’arrêter ? Évitez de les confondre avec les comptes de secours administrateurs, dont la raison d’être et les essais sont distincts.
Microsoft distingue, dans Entra ID, identités managées, principaux de service et comptes utilisateurs utilisés comme comptes de service. Sa présentation des types d’identités privilégie une identité managée lorsque le service hébergé dans Azure la prend en charge, puis un principal de service selon le cas ; elle déconseille de créer une identité utilisateur simplement pour faire tourner un automatisme. Ce choix ne s’étend pas tel quel à tous les produits ni à un système historique sans ces possibilités.
Commencez par les sources techniques : annuaire, applications enregistrées, API, ordonnanceurs, coffres de secrets et inventaires d’infrastructure. Comparez-les aux fiches applicatives. Un compte « inconnu » ne doit pas être supprimé sur la seule base de son nom ; il doit être investigué. La cartographie du SI aide à relier le compte à un service et à ses dépendances.
Construire une fiche par identité et par usage
Une même identité partagée par plusieurs applications rend la revue difficile. Si ce partage existe, notez chaque usage et préparez une séparation lorsque le risque le justifie. Un identifiant stable permet de suivre la fiche même si le nom affiché change. Conservez la source de découverte, la date et le type de compte, afin de pouvoir répéter l’inventaire.
| Champ | Décision à enregistrer | Preuve possible |
|---|---|---|
| Identifiant et plateforme | Quel compte technique est examiné ? | Référence d’objet et système |
| Application et finalité | Quelle tâche dépend de lui ? | Fiche service, script, propriétaire |
| Propriétaire métier | Qui accepte l’effet d’une panne ou d’un abus ? | Nom de rôle et suppléant |
| Exploitant | Qui modifie la configuration et répond aux alertes ? | Équipe et procédure d’astreinte |
| Ressources et droits | À quoi peut-il accéder, directement ou par héritage ? | Export de permissions daté |
| Authentification | Identité managée, certificat, secret ou autre | Configuration sans exposer le secret |
| Dépendances | Jobs, API, partenaires, calendrier d’exécution | Inventaire et derniers essais |
| Criticité | Conséquence d’une compromission ou indisponibilité | Scénario de risque explicite |
| Revue | Responsable, prochaine date, décision | Trace et approbation |
| Sortie | Critère de retrait, essai, retour arrière | Résultat vérifié et historique |
Le registre doit référencer les secrets plutôt que les copier. La référence peut indiquer le coffre, la politique d’accès et la date d’expiration, mais pas la valeur du secret. Protégez aussi les exports de permissions : ils révèlent parfois l’architecture et les chemins les plus sensibles du SI.
Nommer un propriétaire qui peut vraiment décider
Le créateur du compte n’est pas nécessairement son propriétaire durable. Le propriétaire métier sait pourquoi l’application fonctionne et quel arrêt serait acceptable ; l’exploitant sait comment modifier le compte. Pour une intégration fournie par un tiers, désignez un responsable interne capable d’interroger le fournisseur et d’arbitrer les risques. « Équipe informatique » comme seule valeur laisse souvent la décision sans destinataire.
Vérifiez que le propriétaire connaît l’usage du compte. Envoyez-lui la fiche avec la tâche, les ressources et la conséquence potentielle d’un retrait, puis demandez une confirmation ou une correction. Une approbation automatique d’une liste de noms ne constitue pas une revue. Si le propriétaire est parti, la fiche passe en exception ouverte jusqu’à désignation d’un remplaçant et vérification du service. Le silence ne doit pas devenir une acceptation tacite de privilèges.
La PSSI doit décrire la responsabilité générale. Le registre la rend applicable compte par compte. Pour les identités très privilégiées, reliez la fiche au dossier de décision sur les droits afin de distinguer l’utilité du compte de la nécessité de chaque permission.
Comprendre les permissions réelles
Une étiquette « lecture seule » peut masquer un accès à toutes les données d’une API ; une appartenance à un groupe peut accorder un rôle administrateur sur une ressource éloignée. Examinez les attributions directes, les groupes, les consentements applicatifs, les rôles dans l’application et les secrets qui permettent d’agir sous une autre identité. Notez la portée exacte et la source technique consultée.
Demandez quelle opération échouerait si une permission était retirée. Si personne ne peut répondre, préparez un essai contrôlé sur un environnement adapté ou surveillez la prochaine exécution prévue avant de réduire le droit. L’absence d’erreur récente ne démontre pas qu’un job mensuel ou annuel est inutile. À l’inverse, une connexion fréquente ne justifie pas un accès global si une permission plus étroite suffit.
Pour un compte partagé, évaluez aussi l’imputabilité. Qui ou quel processus utilise les moyens d’accès ? Peut-on distinguer les applications consommatrices dans les journaux ? Si ce n’est pas possible, une migration vers des identités séparées peut réduire le risque et faciliter la sortie. Documentez les contraintes qui empêchent cette évolution au lieu de présenter le partage comme un choix normalisé.
Adapter la date de revue au risque et au changement
Microsoft recommande de définir une période de revue et de traiter les retards dans le processus de gouvernance Entra. Ce n’est pas une cadence légale universelle de trente ou quatre-vingt-dix jours. Décidez selon privilège, exposition, fréquence d’usage, dépendance métier, durée des identifiants et rythme de changement de l’application. Un compte puissant employé dans un déploiement quotidien appelle une surveillance et une revue différentes d’une identité limitée à une tâche stable.
Consignez la prochaine date et les événements qui avancent la revue : changement d’application, nouveau fournisseur, incident, départ du propriétaire, augmentation de permissions ou expiration d’un certificat. Une date sans mécanisme de rappel ni remplaçant devient décorative. Si la revue n’a pas lieu, le processus doit dire qui est alerté et quel traitement prudent est possible, sans désactiver aveuglément un service critique.
La revue porte sur cinq questions : le compte reste-t-il nécessaire ? Son usage correspond-il à la finalité ? Les permissions sont-elles minimales pour la tâche ? Les moyens d’authentification et leur durée sont-ils maîtrisés ? Le propriétaire et la date de sortie sont-ils encore valides ? Une réponse « oui » sans preuve d’usage ni analyse de dépendance mérite une demande de complément.
Examiner les secrets et la rotation sans interruption aveugle
Pour un principal de service, un certificat ou un secret peut permettre l’authentification. Connaître sa date d’expiration et le lieu de stockage évite qu’un renouvellement inattendu rompe le service. La rotation doit identifier tous les consommateurs avant de remplacer le moyen d’accès, disposer d’une fenêtre de transition et vérifier le fonctionnement après changement. La nouvelle valeur ne doit pas être copiée dans le registre d’audit.
Une identité managée peut réduire la gestion manuelle d’un secret, mais elle conserve des permissions, un propriétaire et une dépendance applicative. Changer de mécanisme d’authentification ne ferme pas le cycle de gouvernance. Pour un compte utilisateur utilisé par un automatisme, vérifiez pourquoi il existe et si une identité technique plus adaptée peut le remplacer. Ne présentez pas une conversion comme triviale sans tester l’application.
La journalisation des accès aide à repérer des changements de comportement et à vérifier des opérations. Notez la durée réellement disponible et les événements visibles. Ne concluez pas qu’un compte est inutilisé sur un an à partir d’un journal de trente jours.
Exemple suivi : la sauvegarde qui dépend d’un ancien compte
Dans un exemple fictif, un service de sauvegarde utilise un compte créé par un administrateur parti il y a deux ans. Le compte dispose de droits sur tous les volumes et son secret est intégré à un ancien script. Personne ne sait s’il dessert encore le site secondaire. La première décision n’est ni de prolonger sans limite ni de désactiver immédiatement : l’équipe crée une fiche, désigne le responsable sauvegarde et retrouve les exécutions et scripts consommateurs.
Elle découvre deux tâches actives et une tâche historique arrêtée. Le responsable métier confirme les volumes réellement nécessaires ; l’exploitant prépare une identité propre au service et une réduction de portée. Un essai de sauvegarde puis de restauration vérifie les fonctions importantes. La tâche historique est retirée. L’ancien secret est remplacé après la migration et l’ancien compte est désactivé, puis surveillé durant une période décidée pour détecter une dépendance oubliée.
Le dossier conserve les permissions avant et après, les essais, la décision de sortie et une réserve : le site secondaire n’a pas encore été testé en conditions complètes. Le compte ne reçoit pas une « clôture verte » tant que cette réserve peut modifier la décision. La préparation d’un plan de reprise peut aider à organiser l’essai, mais la fiche reste centrée sur l’identité de service.
Préparer la désactivation puis la suppression
La sortie commence lorsque l’application ou le script est retiré, lorsque le compte est remplacé ou lorsque son besoin n’est plus démontré. Recherchez les usages sur une période compatible avec les tâches prévues. Informez les propriétaires des ressources touchées. Retirez ou réduisez d’abord les permissions selon un plan, désactivez l’identité si le système le permet, puis vérifiez l’absence d’effet inattendu. Une suppression définitive peut suivre après la période et les validations internes prévues.
Le processus doit prévoir un retour arrière contrôlé. Réactiver temporairement un compte au moindre message d’erreur sans vérifier la cause annulerait le travail. Enregistrez l’incident, la tâche concernée et la décision ; corrigez la dépendance ou rétablissez un accès limité si nécessaire. Gardez la preuve que l’ancien droit a disparu après résolution. La documentation Microsoft de déprovisionnement décrit des étapes propres à Entra, notamment révocation des rôles et consentements ; adaptez-les à vos plateformes.
Vérifier le registre par les systèmes, pas seulement par ses lignes
Une revue de toutes les fiches connues ne découvre pas les comptes jamais enregistrés. Prélevez donc un ensemble d’identités directement dans l’annuaire, les applications et les coffres, puis cherchez leur fiche. Examinez aussi les créations récentes et les comptes dont le propriétaire n’existe plus. Les écarts de couverture doivent être attribués à un responsable ; sinon le taux de revues achevées surestime la réalité.
La méthode NIST SP 800-53A distingue examen, entretien et test pour évaluer un contrôle. Ici, l’examen lit registre et permissions, l’entretien vérifie que le propriétaire comprend la dépendance, et le test montre l’effet d’une réduction ou d’un retrait contrôlé. NIST ne fixe pas pour cette fiche un seuil légal français ni une périodicité unique.
À chaque revue, notez aussi ce que vous n’avez pas pu observer : journal absent, tâche annuelle non exécutée, fournisseur sans réponse, environnement hors périmètre. La conclusion doit porter sur les usages examinés. Une incertitude résoluble reçoit une action et une date ; une incertitude durable peut demander une restriction provisoire ou un arbitrage de risque. C’est cette décision documentée qui transforme une liste de comptes en gouvernance exploitable.
Transférer la propriété après un changement d’équipe
Le départ d’un développeur ou la réorganisation d’une équipe ne doit pas laisser une identité technique sans responsable. Lorsqu’une application change de propriétaire, transmettez la fiche complète : finalité, systèmes consommateurs, permissions, secret ou certificat, prochaine échéance et incidents connus. Le nouveau responsable confirme ce qu’il comprend et signale les usages qu’il ne peut pas encore expliquer. Son nom dans une colonne ne vaut pas acceptation éclairée si les dépendances restent opaques.
Associez le transfert à un essai de fonctionnement et à une vérification des accès administratifs. L’ancien propriétaire peut conserver un droit de gestion du compte ou connaître un secret, même si la fiche a été réattribuée. Traitez ces accès humains dans le processus d’arrivées, mobilités et départs, puis vérifiez leur retrait. Si l’équipe d’accueil n’a pas les moyens d’exploiter la tâche, la direction doit décider d’un support ou d’une migration ; le risque ne disparaît pas grâce à la seule réaffectation documentaire.
Préparer une preuve lisible sans exposer les moyens d’accès
Un auditeur devrait pouvoir retrouver la version de la fiche examinée, la personne qui a confirmé l’utilité du compte, les permissions observées et la décision de réduction ou maintien. Un export de configuration peut servir de pièce, mais il faut dater sa collecte et préciser le tenant, l’application et les exclusions. Un écran qui affiche « actif » sans source ni périmètre ne suffit pas à étayer une décision sur des droits effectifs.
Séparez le dossier de décision des éléments opérationnels nécessaires pour utiliser le compte. L’audit n’a normalement pas besoin de lire le secret, la clé privée ou les codes de récupération. Utilisez une référence contrôlée au coffre et, si besoin, une attestation de l’exploitant sur la politique de rotation. Limitez l’accès aux détails d’architecture selon les rôles. Cette séparation permet de produire une preuve exploitable tout en réduisant le nombre de copies sensibles créées par la revue elle-même.