Pourquoi vos comptes « svc- » sont une bombe à retardement

Par Mirko Peters · 2026-08-11

Bienvenue dans ce podcast et dans notre exploration approfondie de l’architecture de sécurité en entreprise. Si votre organisation ressemble à la plupart, un rapide coup d’œil à votre Active Directory ou à votre annuaire Microsoft Entra ID révélera un vaste cimetière de comptes commençant par « svc- », « app- » ou « admin-bot ». Ces comptes font tourner les services, assurent la circulation des do

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Bienvenue dans ce podcast et dans notre exploration approfondie de l’architecture de sécurité en entreprise. Si votre organisation ressemble à la plupart, un rapide coup d’œil à votre Active Directory ou à votre annuaire Microsoft Entra ID révélera un vaste cimetière de comptes commençant par « svc- », « app- » ou « admin-bot ». Ces comptes font tourner les services, assurent la circulation des données et maintiennent les automatisations en fonctionnement. Mais ce sont aussi le plus grand angle mort de votre posture de sécurité moderne. Dans cet article de blog, nous prolongeons notre dernier échange pour expliquer pourquoi les comptes de service traditionnels compromettent votre architecture Zero Trust, et pourquoi la migration vers Microsoft Entra Workload Identities est la seule voie à suivre.

Pour une analyse audio complète de ce sujet, écoutez notre épisode de podcast associé, Replace Service Accounts with Entra Workload Identities. Plongeons maintenant dans les mécanismes du risque lié aux identités non humaines et voyons comment l’éliminer définitivement.

Points clés

Les comptes de service dotés de secrets statiques et de droits étendus constituent votre plus grande faille en matière d’identité. Les Workload Identities (dans Microsoft Entra ID) offrent à chaque acteur non humain une identité gouvernée, avec moindre privilège, cycle de vie, stratégies d’accès conditionnel, rotation et traces d’audit complètes, sans casser vos automatisations.

Pourquoi les comptes de service échouent (et compromettent le Zero Trust)

Le modèle traditionnel du compte de service a été conçu pour une époque de périmètres réseau qui n’existent plus. À l’époque où la confiance dépendait du fait qu’un appareil était branché au réseau local de l’entreprise, un mot de passe statique stocké dans un fichier de configuration semblait acceptable. Aujourd’hui, cette philosophie de conception est un passif.

• Secrets statiques et absence de MFA -> faciles à voler, difficiles à renouveler en toute sécurité
• Privilèges excessifs par défaut -> les autorisations « il faut que ça marche » deviennent permanentes
• Aucun cycle de vie -> les comptes orphelins ou oubliés survivent aux migrations et aux réorganisations
• Auditabilité insuffisante -> « qui a utilisé ceci et pourquoi ? » = conjectures et captures d’écran
• Culture des exceptions -> les exclusions d’accès conditionnel et de MFA pour les bots élargissent discrètement votre surface d’attaque

Managed Identities : une bonne étape, mais limitée à Azure

Lorsque les organisations réalisent que les comptes de service statiques sont dangereux, leur premier réflexe consiste souvent à se tourner vers les identités managées Azure. Si ces identités représentent un progrès considérable, car elles suppriment entièrement les secrets pour les ressources hébergées sur Azure, elles présentent des limites bien définies.

• ✅ Accès sans secret pour les ressources natives Azure (Functions, VM, Logic Apps)
• ❌ Lacunes pour les cibles hybrides ou tierces, cartographie des responsabilités peu fiable, vues de gouvernance limitées
• ❌ Couverture de l’accès conditionnel et des droits non homogène sur les surfaces hors Azure

Workload Identities : ce que vous obtenez réellement

C’est là qu’interviennent Microsoft Entra Workload Identities. Plutôt que de traiter les acteurs non humains comme des citoyens de seconde zone ou de vous enfermer dans les contraintes d’Azure, Workload Identities élèvent les applications, scripts et services automatisés au rang de principaux de sécurité de premier plan.

• Identités non humaines de premier plan (applications, scripts, connecteurs, RPA, intégrations)
• Autorisations délimitées (rôles Graph et de ressources, authentification uniquement par application) avec moindre privilège
• Cycle de vie (propriétaire, cadence de revue, processus de mise hors service) lié aux processus métier
• Accès conditionnel pour les charges de travail (contrôles tenant compte du risque et du contexte, contrôles de session lorsque cela est pris en charge)
• Hygiène des identifiants (secrets de courte durée, certificats, stratégie de rotation des clés)
• Visibilité unifiée (connexions, jetons, accès aux ressources, historique des modifications) -> prêt pour l’audit

Matrice de comparaison (en un coup d’œil)

Modèles d’architecture (cas d’usage courants)

La mise en œuvre des identités de charge de travail exige de les faire correspondre correctement à vos modèles d’architecture. Voici comment elles s’appliquent aux charges de travail les plus courantes en entreprise :

• Connecteurs Power Platform / flux cloud -> Attribuez une identité de charge de travail par intégration et n’accordez que les étendues Graph/Dataverse nécessaires.
• Applications métier (API web, démons) -> Inscription d’application + certificat ; utilisez des rôles d’application et Graph en mode application uniquement ; appliquez les stratégies d’accès conditionnel lorsque c’est possible.
• Scripts d’automatisation (Azure Automation, GitHub Actions, DevOps) -> Utilisez des informations d’identification fédérées (OIDC), sans secrets stockés.
• Tâches inter-locataires / B2B -> Une identité de charge de travail dédiée par frontière de locataire ; isolez les droits et la journalisation.

Feuille de route de migration (90 jours, sans heurts)

Traiter des centaines de comptes de service hérités peut sembler décourageant. C’est pourquoi vous avez besoin d’une feuille de route de migration structurée, sur 90 jours, centrée sur la réduction des risques.

Phase 1 — Découverte et tri (semaines 0 à 3)

1. Inventoriez les connexions et objets non humains : svc-*, app-*, boîtes aux lettres partagées, inscriptions d’applications, secrets arrivant à expiration dans moins de 90 jours.
2. Associez chacun à un propriétaire, une finalité métier, des cibles, des autorisations et une dépendance au compte d’urgence.
3. Classez par risque : mots de passe statiques, rôles globaux, absence de propriétaire, rotation récente inexistante.

Phase 2 — Convertir d’abord les éléments à risque élevé (semaines 4 à 8)

1. Créez une identité de charge de travail par intégration (ne la réutilisez pas).
2. Remplacez l’authentification par mot de passe par des certificats ou des informations d’identification fédérées ; définissez une rotation.
3. Passez aux autorisations en mode application seule et supprimez les autorisations déléguées par l’utilisateur lorsqu’elles ne sont pas nécessaires.
4. Appliquez des stratégies d’accès conditionnel aux connexions des charges de travail (lorsque cela est pris en charge).
5. Mettez en place des revues d’accès (trimestrielles) et définissez la propriété dans la CMDB/l’ITSM.

Phase 3 — Mise hors service et gouvernance (semaines 9 à 12)

1. Désactivez les anciens comptes de service, surveillez-les pendant 14 jours, puis supprimez-les.
2. Imposez des normes de création : nommage, propriétaire, classification des données et cadence de revue.
3. Ajoutez des alertes : connexions anormales, identités inactives depuis plus de 30, 60 ou 90 jours, secrets arrivant à expiration.
4. Intégrez les contrôles d’identité dans le CI/CD (stratégie sous forme de code).

Accès conditionnel et autorisations (garde-fous concrets)

L’une des fonctionnalités les plus puissantes des plateformes d’identité modernes est la possibilité d’appliquer des garde-fous adaptés spécifiquement aux acteurs non humains. En séparant les stratégies humaines et celles des charges de travail, vous évitez que des robots déclenchent des alertes de « voyage impossible » tout en continuant à bloquer le trafic malveillant.

• Stratégies distinctes pour les identités humaines et celles des charges de travail ; bloquez l’ouverture de session interactive pour les charges de travail.
• Emplacements nommés / restrictions réseau pour l’accès en mode application seule, lorsque c’est faisable.
• Droits limités dans le temps (PIM pour les rôles d’application lorsqu’il est disponible ; revues d’accès planifiées).
• Étendues : privilégiez les rôles d’application ou les rôles propres à une ressource plutôt que les droits à l’échelle de l’annuaire.

Journalisation et audit (ce qu’il faut montrer à l’auditeur)

Lorsque les responsables de la conformité et les auditeurs se présentent, ils n’acceptent plus les tableaux de suivi ni les assurances verbales concernant les personnes ayant accès aux scripts back-end. Vous devez pouvoir prouver la gouvernance immédiatement grâce à une journalisation centralisée.

• Propriétaire de l’application ou de la charge de travail, finalité et sensibilité des données
• Journaux de connexion (connexions des principaux de service), audience du jeton, adresse IP, application cliente
• Attributions de rôles (qui a approuvé, quand la certification a été effectuée)
• Historique des informations d’identification (type, dernière rotation, expiration)
• Cycle de vie : création, modification, désactivation et suppression, avec l’auteur de chaque changement

Tableau de bord des indicateurs clés (prouver l’amélioration)

Pour conserver l’adhésion de la direction, suivez et communiquez les indicateurs clés qui démontrent la réduction, dans la durée, des risques liés aux identités non humaines.

• % d’identités non humaines avec propriétaire et cadence de revue (objectif ≥ 95 %)
• Comptes de service orphelins (objectif → 0)
• Secrets de plus de 90 jours (objectif → 0 ; privilégiez certificats/informations fédérées)
• Étendue des rôles en mode application seule (nombre de « Directory.ReadWrite.All » → en baisse)
• Constats d’audit concernant les accès non humains (en baisse d’un trimestre à l’autre)

Anti-modèles à éliminer

Au fil du nettoyage de votre environnement, veillez à ce que vos équipes ne retombent pas dans leurs anciennes habitudes. Éliminez immédiatement ces anti-modèles :

• Réutiliser un même compte de service générique pour de nombreux systèmes
• Intégrer des mots de passe dans des scripts, web.config ou Key Vault sans stratégie de rotation
• Accorder le rôle Administrateur général / Propriétaire « par précaution », pour que les tâches continuent de fonctionner
• Des exceptions « temporaires » à l’accès conditionnel qui n’expirent jamais

Actions rapides (cette semaine)

Vous n’avez pas besoin d’attendre le lancement d’un grand projet pour améliorer votre posture de sécurité. Voici quatre actions rapides à mettre en œuvre dès cette semaine :

• Associez à chaque identité non humaine les balises Propriétaire, Système et Classe de données.
• Basculez une tâche à haut risque vers des identifiants fédérés (GitHub OIDC -> Entra).
• Remplacez un compte de service partagé dans Power Automate par une identité de charge de travail.
• Créez un rapport des principaux de service dont les secrets arrivent à expiration ou sont déjà expirés, puis planifiez des alertes.

Questions fréquentes (réponses rapides)

Les identités de charge de travail cassent-elles les anciennes tâches sur site ?
Non : faites le pont avec une authentification en mode application uniquement, des certificats ou des services de courtage, puis supprimez progressivement les mots de passe.

Puis-je appliquer l’accès conditionnel aux connexions non humaines ?
Oui, pour les flux pris en charge (connexions de principaux de service). Utilisez les signaux réseau, de localisation ou d’appareil lorsqu’ils sont pertinents, et bloquez les connexions interactives.

Comment éviter la prolifération ?
Une identité de charge de travail par intégration (et non par équipe). Imposez le nommage, un propriétaire et des revues dès la création ; automatisez le nettoyage des identités inactives.

Qu’en est-il de Power Platform ?
Utilisez des principaux de service / identités de charge de travail pour les connecteurs et Dataverse ; cessez d’utiliser des comptes utilisateurs partagés.

Conclusion

Vous ne pouvez pas gérer le risque lié aux comptes de service uniquement par la rotation des secrets. Les Entra Workload Identities intègrent l’accès non humain dans le même modèle Zero Trust, de cycle de vie et d’audit que celui que vous exigez déjà pour les personnes, sans interruption ni héroïsme. Commencez par vos comptes « svc- » les plus risqués, convertissez-les en identités de charge de travail gouvernées, et redonnez aux exceptions leur caractère exceptionnel.

Si cet article vous a plu, ne manquez pas la discussion complète dans notre épisode de podcast, Replace Service Accounts with Entra Workload Identities. Abonnez-vous à l’émission pour d’autres analyses approfondies des stratégies de sécurité Microsoft 365 et Azure en entreprise !