Le coût caché des comptes de service sur-permissionnés

Votre utilisateur le plus puissant n'est pas une personne

Lorsque les équipes nettoient les accès, elles commencent généralement par les personnes, comme le contractant dont le projet est terminé, l'employé qui a changé de rôle ou l'administrateur ayant plus de droits que nécessaire. C'est un bon point de départ, mais cela laisse de côté une grande partie du tableau. Les comptes de service et les intégrations d'applications ont souvent un accès plus large aux données sensibles que toute personne seule, et ils sont généralement la dernière chose que quelqu'un examine. Dans un environnement peu hygiénique, un compte de service tout-puissant peut devenir le moyen le plus facile d'entrer.

Pourquoi les revues d’accès commencent et s’arrêtent avec les personnes

Les personnes ont toujours été les acteurs les plus familiers dans une violation. Elles sont souvent la manière dont les attaquants entrent : par phishing, mots de passe volés et ingénierie sociale. Elles sont aussi une voie courante pour la sortie des données, que ce soit un initié qui copie des fichiers en partant ou un attaquant qui utilise un compte compromis pour extraire des données. Verizon's 2026 Data Breach Investigations Report a constaté que l'élément humain était impliqué dans 62 % des violations. Il est donc logique que les revues d'accès, les listes de contrôle de départ et les projets de moindre privilège soient construits autour des comptes utilisateurs.

Les comptes de service correspondent rarement à ce processus. Ils sont créés pour faire fonctionner quelque chose, souvent avec des droits étendus pour éviter toute panne, puis personne ne les gère. Lorsque la personne qui l’a configuré part, le compte reste, et les équipes hésitent à le modifier car elles ne savent pas ce qui pourrait échouer. Ainsi, lors de la revue des accès, les comptes de service sont au mieux une cible secondaire.

Pourquoi les comptes de service sont une cible attrayante

Les identités machines dépassent les identités humaines dans un rapport de 82 pour 1, selon CyberArk's 2025 Identity Security Landscape, et près de la moitié d’entre elles disposent d’un accès sensible ou privilégié. Elles fonctionnent 24h/24, ne peuvent généralement pas utiliser la MFA et conservent souvent le même mot de passe pendant des années.

Dans Active Directory, les attaquants disposent d'une technique qui leur est directement destinée. Tout utilisateur de domaine peut demander un ticket de service Kerberos pour un compte avec un nom principal de service (SPN), et une partie de ce ticket est chiffrée avec une clé dérivée du mot de passe du compte de service. Un attaquant peut récupérer le ticket hors ligne et le craquer sans toucher à nouveau au compte. Cette technique s'appelle Kerberoasting (MITRE ATT&CK T1558.003). Elle fonctionne mieux contre le type de compte de service que la plupart des environnements possèdent : un ancien mot de passe qui ne change jamais, avec des chiffrement plus anciens comme RC4 encore activés.

Les comptes de service ne sont pas toujours non humains en pratique. Les administrateurs se connectent avec eux pour effectuer des travaux manuels, partagent un ensemble d’identifiants au sein d’une équipe ou réutilisent un seul compte pour plusieurs applications. Le OWASP Non-Human Identities Top 10 nomme les deux problèmes : identités non humaines surprivilegiées (NHI5) et utilisation humaine d’identités non humaines (NHI10). Lorsqu’une personne travaille via un compte de service, on perd la trace de qui a fait quoi.

À quoi cela ressemble dans de vraies violations

Uber, 2022. Un attaquant a trompé un sous-traitant pour qu’il approuve une demande MFA et a accédé au réseau interne. Sur un partage réseau, il a trouvé des scripts PowerShell avec des identifiants administrateur codés en dur pour l’outil de Privileged Access Management d’Uber. Cela a ouvert la porte à AWS, Google Cloud, Google Drive, Slack, et plus encore.

Cloudflare, 2023. Après la violation d’Okta, Cloudflare a renouvelé des milliers d’identifiants mais a manqué un jeton de service et trois identifiants de compte de service que l’équipe pensait inutilisés. L’un était un compte de service Smartsheet avec un accès administratif à Jira. Les attaquants les ont utilisés pour accéder aux systèmes Confluence, Jira et Bitbucket de Cloudflare.

Salesloft Drift, 2025. Des attaquants ont volé des jetons OAuth de l'intégration du chatbot Drift et les ont utilisés pour exporter des données des environnements Salesforce dans plus de 700 organisations.

Dans chaque cas, l’accès le plus dommageable provenait d’une identité non humaine avec une portée plus grande que celle surveillée par quiconque.

Quatre problèmes d’accès cachés dans vos comptes de service

Les comptes de service ont les mêmes problèmes d’accès que les personnes. Ils sont juste plus difficiles à repérer, car personne ne les cherche.

• Accès ouvert. Les dossiers et partages dont dépend un compte de service sont souvent largement ouverts pour que l’application ne rencontre jamais d’erreur de permission, et ils restent ainsi. Les données ouvertes à tous dans l’entreprise sont également ouvertes à tout compte compromis.
• Accès obsolète et inactif. L'application a été retirée, mais le compte est toujours activé et conserve ses droits. Un compte inutilisé depuis un an fonctionne toujours pour toute personne possédant ses identifiants.
• Accès orphelin. La personne qui a créé le compte est partie, ou le système qu'il servait a disparu. Personne ne sait à quoi sert ce compte, il n'est donc jamais supprimé.
• Accès privilégié et excessif. Les comptes de service sont souvent ajoutés aux groupes d’administrateurs ou se voient attribuer le Contrôle total « pour que ça fonctionne ». Même sans droits d’administrateur, la plupart disposent de bien plus d’accès que nécessaire pour leur travail.

Chacun d’eux élargit le rayon d’impact du compte. Ensemble, ils transforment un seul mot de passe en accès à une grande partie de vos données sensibles.

L'IA agentive augmente les enjeux

Les agents IA et copilotes sont également des identités non humaines. Ils agissent avec les permissions qui leur sont accordées, souvent via un compte de service ou une autorisation OAuth. Si un agent fonctionne sous un compte pouvant lire tous les partages de fichiers, il peut les lire et potentiellement les exposer tous. À mesure que les organisations connectent plus d’outils IA à leurs données, le nombre d’identités non humaines continuera d’augmenter, tout comme le coût d’une mauvaise gestion de leurs permissions.

Comment intégrer les comptes de service dans votre hygiène d'accès

• Constituez un inventaire. Dans Active Directory, les comptes avec un SPN sont un bon point de départ. Ajoutez ensuite les enregistrements d’applications Entra ID, les intégrations SaaS et les jetons API.
• Attribuez un propriétaire à chaque compte qui peut expliquer son fonctionnement et approuver les modifications.
• Cartographiez l'accès effectif. Vérifiez ce que chaque compte peut atteindre via les appartenances à des groupes et l'héritage cassé, en mettant l'accent sur les données sensibles. Travaillez dans les deux sens : quels comptes peuvent accéder à un partage sensible, et ce qu'un compte donné peut atteindre.
• Adaptez la taille en fonction de l'utilisation réelle. Comparez ce à quoi le compte peut accéder avec ce qu'il a utilisé. Supprimer les accès inutilisés présente le moindre risque de provoquer un dysfonctionnement.
• Examinez les intégrations SaaS là où elles se trouvent. Les autorisations OAuth sont généralement gérées dans la console d'administration de chaque plateforme ou par votre fournisseur d'identité.
• Renforcez les identifiants. Faites tourner les anciens mots de passe, supprimez les identifiants hardcoded des scripts et partages de fichiers, et désactivez RC4 quand vous le pouvez.
• Surveillez l'utilisation humaine, comme les connexions interactives ou les ouvertures de session depuis des postes de travail.
• Ajoutez les comptes de service à vos revues régulières des droits, selon le même calendrier que les utilisateurs.

Ne pensez plus seulement aux personnes

Toute identité pouvant accéder à des données sensibles, humaine ou non, fait partie de votre surface d’attaque, et les comptes de service en sont souvent la partie la plus large. La prochaine fois que vous effectuez une revue d’accès, suivez les mêmes étapes pour vos comptes de service.

Pour les comptes de service dans Active Directory et sur vos serveurs de fichiers, Netwrix Access Analyzer couvre les étapes d’inventaire, de cartographie et de revue. Il identifie les comptes de service, montre la dernière activité de chacun et signale ceux vulnérables au Kerberoasting. Il calcule l’accès effectif sur les serveurs de fichiers, SharePoint et Active Directory. Vous pouvez consulter cet accès dans les deux sens : commencez par un dossier pour voir quels comptes peuvent y accéder, ou par un compte, humain ou service, pour voir tout ce à quoi il peut accéder. Ensuite, l’Access Information Center permet aux propriétaires de ressources d’effectuer des revues régulières des droits et de décider ce qu’il faut conserver, supprimer ou modifier.