Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Service Account

general

Définition

Un compte de service (Service Account) est un compte d'utilisateur non-humain créé pour permettre à une application, un service, ou un processus automatisé de s'authentifier et d'accéder aux ressources réseau. Contrairement aux comptes utilisateurs associés à des personnes physiques, les comptes de service n'ont pas d'interaction humaine directe — ils sont utilisés par les processus en arrière-plan, les services Windows, les tâches planifiées, et les applications. Les comptes de service sont indispensables dans les environnements Active Directory : un service SQL Server qui doit accéder à un partage réseau ou à un autre serveur SQL doit s'authentifier — le service SQL s'exécute sous un compte de service avec un SPN (Service Principal Name) enregistré. Un service IIS qui doit accéder à une base de données utilise un compte de service avec les droits appropriés. Les applications qui communiquent entre elles via des API internes utilisent des comptes de service comme identité. Les risques des comptes de service mal gérés sont significatifs. Droits excessifs : les comptes de service reçoivent souvent plus de droits que nécessaire par facilité (Domain Admin pour éviter les problèmes d'accès — pratique dangereuse). Mots de passe statiques : les mots de passe des comptes de service ne sont souvent jamais changés (peur d'interruption de service) — souvent connus de plusieurs personnes. Kerberoasting : tout utilisateur AD peut demander un ticket Kerberos pour un compte de service avec un SPN, puis le craquer offline pour récupérer le mot de passe. Les alternatives modernes aux comptes de service traditionnels incluent les gMSA (group Managed Service Accounts) — dont le mot de passe est géré automatiquement par Active Directory (rotation tous les 30 jours, mot de passe de 240 caractères aléatoires, personne ne connaît le mot de passe) et les Managed Identities dans le cloud (Azure, AWS) qui éliminent complètement les credentials pour les services cloud.

gMSA — Group Managed Service Accounts

Les gMSA (Group Managed Service Accounts) sont la solution Microsoft pour éliminer les mots de passe statiques des comptes de service. Un gMSA est un compte AD dont le mot de passe est automatiquement généré et géré par le service KDS (Key Distribution Service) d'AD. Les hôtes autorisés à utiliser le gMSA récupèrent automatiquement le mot de passe auprès d'AD lors du démarrage du service — sans intervention humaine et sans stocker de mot de passe en clair. Avantages : rotation automatique du mot de passe (tous les 30 jours par défaut), mot de passe de 240 caractères (résistant au cracking), impossibilité de connexion interactive (protège contre l'abus), et SPN géré automatiquement. Limitation : fonctionne uniquement sur des hôtes membres du domaine Windows — pas pour les applications Linux ou les services cloud.

Service Account Discovery et audit

La découverte de tous les comptes de service dans un environnement AD est une première étape essentielle. La requête PowerShell `Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate | Select Name, SPN, PasswordLastSet, LastLogonDate` liste tous les comptes avec des SPNs (potentiellement des comptes de service). Analyser la date de dernière connexion, la date de dernier changement de mot de passe, et les droits attribués permet d'identifier les comptes orphelins (plus de service actif), les comptes avec mots de passe anciens (jamais changés), et les comptes avec des droits excessifs. CyberArk Discovery & Audit (CDA) automatise ce processus et peut identifier les comptes de service même sans SPN.

Service Accounts dans le cloud — IMDSv2 et Workload Identity

Dans les environnements cloud, les équivalents des comptes de service sont les Workload Identities : AWS IAM Roles (pour EC2, Lambda, ECS), Azure Managed Identities, et GCP Service Accounts. Ces identités cloud n'ont pas de mot de passe statique — elles utilisent des credentials temporaires obtenus via les métadonnées de l'instance ou via les SDK cloud. Kubernetes Workload Identity (GKE Workload Identity, EKS IRSA — IAM Roles for Service Accounts) associe un Service Account Kubernetes à un role cloud IAM — les pods s'authentifient auprès des APIs cloud sans credentials stockés. Cette approche est la bonne pratique pour les applications cloud-native : zéro credential statique, rotation automatique, et audit trail complet dans les logs CloudTrail/Activity Log.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis