Dans chaque tenant Microsoft 365 audité, on trouve la même chose : des comptes créés "pour un truc temporaire" il y a trois ans, toujours actifs, avec un mot de passe qui n'a jamais changé, sans MFA, et dont personne ne sait vraiment à quoi ils servent encore.

Ce sont les comptes de service. Et ils sont systématiquement le point le plus négligé de la sécurité M365.

C'est quoi un compte de service ?

Un compte de service, c'est un compte utilisateur créé non pas pour une personne, mais pour une application, un script ou un processus automatisé. Exemples courants :

Ces comptes ne sont pas intrinsèquement problématiques. Le problème, c'est comment ils sont gérés — ou plutôt, comment ils ne sont pas gérés.

Pourquoi c'est un problème

Trois caractéristiques rendent les comptes de service particulièrement dangereux :

Pas de MFA. Les comptes de service utilisent souvent des protocoles d'authentification legacy (SMTP authentifié, IMAP, connexion via basic auth) qui ne supportent pas le MFA. Même si votre politique MFA est active sur tous les autres comptes, ces comptes y échappent par construction.

Mot de passe statique. Le mot de passe d'un compte de service est configuré une fois, intégré dans une application ou un script, et n'est plus jamais changé — parce que le changer impliquerait de mettre à jour tous les endroits où il est utilisé, et personne ne sait exactement lesquels.

Aucun propriétaire. La personne qui a créé le compte a souvent quitté l'entreprise. L'application pour laquelle il a été créé a parfois été remplacée. Personne ne surveille ce compte, personne ne recevrait d'alerte si quelqu'un s'y connectait.

Ce qu'on voit souvent : un compte de service avec SMTP authentifié, un mot de passe configuré en 2019 et des droits de lecture sur toutes les boîtes mail du tenant — parce qu'à l'époque c'était "plus simple". Ce compte est visible depuis l'extérieur, jamais surveillé, et son mot de passe n'a aucune chance d'être dans une politique de rotation.

Les identifier

La première étape c'est de savoir ce qui existe. Entra ID ne distingue pas nativement les comptes de service des comptes utilisateurs — tout est dans la même liste.

Chercher les comptes sans activité interactive. Un compte de service ne se connecte généralement pas à des applications interactives comme Teams ou SharePoint. Dans les journaux de connexion, il apparaît avec des connexions non interactives uniquement, souvent via des protocoles legacy.

Entra admin center → Surveillance → Journaux de connexion → Filtrer "Type de connexion : Non interactif"

Chercher les noms suspects. Les comptes de service ont souvent des noms qui trahissent leur usage : svc-erp, sync-rh, smtp-alerts, monitoring-user, noreply@.... Un filtre sur ces patterns dans la liste des utilisateurs remonte rapidement les candidats.

Chercher les comptes avec authentification legacy active. Dans les journaux de connexion, filtrer sur "Client d'authentification héritée" liste tous les comptes qui utilisent encore IMAP, POP3 ou SMTP basic. Ce sont presque exclusivement des comptes de service.

Entra admin center → Surveillance → Journaux de connexion → Filtrer "Application cliente : Clients d'authentification héritée"
Ce qu'on voit souvent : entre 5 et 15 comptes de service non documentés dans les tenants PME de 50 à 200 utilisateurs. La moitié utilisent encore des protocoles legacy. Un quart n'ont pas eu de connexion depuis plus de 6 mois — mais sont toujours actifs.

Les sécuriser

Une fois identifiés, il faut traiter chaque compte individuellement.

Supprimer les comptes inutiles. Si l'application associée n'existe plus ou si le compte n'a pas eu de connexion depuis 6 mois, désactiver puis supprimer. Tester d'abord la désactivation — si rien ne se plaint dans les 2 semaines, supprimer.

Migrer vers des méthodes modernes. Les comptes utilisés pour SMTP peuvent souvent être remplacés par OAuth2 ou par le relais SMTP d'Exchange Online sans basic auth. Les scripts PowerShell peuvent utiliser des app registrations avec certificat plutôt qu'un compte utilisateur avec mot de passe.

Limiter les permissions. Un compte de service ne devrait avoir que les droits strictement nécessaires à sa fonction. Un compte SMTP n'a pas besoin de droits de lecture sur les boîtes mail. Un compte de synchronisation n'a pas besoin d'être admin.

Rotation des mots de passe. Pour les comptes qui ne peuvent pas migrer vers OAuth, mettre en place une rotation régulière des mots de passe — et documenter tous les endroits où ce mot de passe est utilisé avant de le changer.

Les documenter

Le problème des comptes de service, c'est autant l'absence de documentation que l'absence de sécurité. Sans documentation, il est impossible de savoir quoi supprimer, quoi garder, et qui contacter si quelque chose casse.

Pour chaque compte de service, documenter au minimum :

Un simple tableau dans Notion, Confluence ou même un fichier Excel suffit. L'important c'est que ça existe et que quelqu'un en soit responsable.

AuditMS identifie automatiquement les comptes de service sur votre tenant : connexions legacy actives, comptes sans activité interactive, permissions excessives — en moins de 2 minutes.

Lancer l'audit sur mon tenant