Service accounts : risques et bonnes pratiques

Un service account (ou compte de service, ou machine identity, ou non-human identity - NHI) est une identité utilisée par un workload, un script, un pipeline CI/CD, un bot ou un agent, pas par un humain. Ces identités ont explosé avec le cloud et les microservices : dans une entreprise typique en 2026, 10 à 50 identités machine existent pour chaque identité humaine. Elles sont aussi les moins bien gérées : pas de MFA, credentials long-lived, owner flou, rotation oubliée, fuites fréquentes dans Git. Ce guide détaille les risques spécifiques, les bonnes pratiques par plateforme, et l'émergence d'une catégorie d'outils dédiée - Non-Human Identity management.

1. Définition et périmètre

1.1 Qu'est-ce qu'un service account

Un service account est une identité créée pour être utilisée par un système, pas par une personne. Il s'authentifie via des credentials (clés, tokens, certificats) et dispose de permissions pour accéder à des ressources. Il n'a pas d'utilisateur assis derrière un clavier.

Exemples concrets :

• Application Java qui se connecte à une base PostgreSQL : credential de DB.
• Pipeline GitHub Actions qui déploie sur AWS : rôle IAM + OIDC.
• Pod Kubernetes qui appelle une API interne : ServiceAccount K8s + token JWT.
• Script cron qui synchronise des données entre SaaS : API keys de chaque SaaS.
• Bot Slack qui répond aux questions : token OAuth bot.
• Agent monitoring qui pousse des métriques : compte dédié dans Prometheus / Datadog.
• Scanner de vulnérabilités qui parcourt le cloud : credentials avec permissions larges de lecture.

1.2 Taxonomie des identités non-humaines

La catégorie "service account" regroupe en réalité plusieurs types distincts :

1.3 Pourquoi le problème grandit

Quatre ruptures techniques depuis 2015 ont fait exploser le nombre d'identités machine :

• Microservices : 1 application monolithique devient 20 à 50 microservices, chacun avec ses propres identités pour s'authentifier aux autres services.
• Cloud-native : chaque ressource (Lambda, Cloud Function, conteneur Fargate) a son propre rôle IAM.
• DevOps industrialisé : chaque pipeline CI/CD, chaque runner, chaque outil de déploiement a ses credentials.
• SaaS et automation : chaque intégration inter-SaaS (Zapier, n8n, Make) crée une identité tierce avec ses permissions.

Résultat mesuré : dans les grandes entreprises en 2025-2026 (rapports Astrix Security, Entro, GitGuardian State of Secrets Sprawl), le ratio typique est 10:1 à 50:1 en faveur des identités machine.

2. Les 8 risques structurels

2.1 Long-lived credentials

Beaucoup de service accounts utilisent des access keys statiques qui ne changent jamais. Vol = accès persistant jusqu'à ce que quelqu'un s'en aperçoive. Durée typique entre création et rotation dans les entreprises non-matures : plusieurs années, voire jamais.

2.2 Over-privileged par défaut

Un développeur qui crée un service account typiquement :

• Attribue des permissions larges "pour ne pas bloquer".
• Utilise les politiques AWS managed AdministratorAccess ou PowerUserAccess.
• Ne teste pas avec un périmètre réduit.

Les observations CIEM convergent : plus de 95 % des permissions accordées à des service accounts cloud ne sont jamais utilisées.

2.3 Absence de MFA

Par design, un service account ne peut pas faire de MFA : il n'y a personne pour cliquer sur une notification ou toucher une YubiKey. Conséquence : le credential est l'unique facteur. Sa compromission équivaut à la compromission de l'identité.

2.4 Owner flou ou inexistant

Question courante : "À qui appartient ce compte de service ?" Réponse typique : "Aucune idée, il existe depuis 3 ans, on n'ose pas le supprimer." Cette incertitude empêche rotation, audit, déprovisioning lors des départs.

2.5 Comptes partagés entre équipes

Un même service account utilisé par 5 équipes différentes pour 5 usages différents. Rotation impossible sans coordination énorme, audit impossible (on ne sait pas qui a fait quoi), déprovisioning impossible (si on retire, ça casse quelque part).

2.6 Credentials hardcodés

Les credentials finissent :

• Dans le code source (Git, GitHub, GitLab).
• Dans les Dockerfiles.
• Dans les configs Terraform commitées.
• Dans les scripts de déploiement.
• Dans les variables d'environnement de production non protégées.
• Dans des documents partagés (Notion, Confluence, Google Docs).

GitGuardian 2024 : 23 millions de secrets ont été détectés dans des repos publics GitHub, 95 % étaient des credentials de service accounts.

2.7 Absence de rotation

Sans processus, aucun credential ne tourne. Clés AWS créées en 2018, toujours utilisées en 2026. Fuite ancienne invisible jusqu'à utilisation offensive.

2.8 Audit faible

Les actions d'un service account sont loguées, mais attribuées à une identité abstraite. Impossible de corréler à une personne ou un projet spécifique sans owner documenté. L'investigation post-incident devient un cauchemar.

3. Vecteurs d'attaque observés

3.1 Secrets dans Git

Scénario archi-classique : un développeur commit une clé AWS "juste pour tester". Push sur un repo public. Dans les 60 secondes, des bots GitHub scannent, détectent, volent. L'attaquant provisionne des instances GPU de minage dans la foulée. Facture 5-6 chiffres en quelques heures.

Mitigation : secret scanning obligatoire en pre-commit (gitleaks, trufflehog), réactivé en GitHub Secret Scanning, révocation immédiate + rotation si exposition.

3.2 Infostealers et postes développeurs

Des infostealers (RedLine, Vidar, StealC, Raccoon) ciblent les postes développeurs pour exfiltrer :

• Clés SSH dans ~/.ssh/.
• Tokens stockés dans ~/.aws/credentials.
• Configs Azure CLI / gcloud.
• Tokens Git stockés dans les credential managers.
• Variables d'environnement depuis processus actifs.

Les credentials revendus sur marketplaces criminels servent à compromettre les environnements cloud de l'entreprise.

3.3 Escalade via service accounts dans le cloud

Pattern bien documenté dans AWS :

1. Attaquant compromet un service account avec permissions modestes.
2. Il découvre un rôle administrateur que son service account peut sts:AssumeRole.
3. Il assume ce rôle et obtient des permissions beaucoup plus larges.
4. Il pivote vers d'autres comptes via trust policies mal configurées.

Équivalent GCP : chaîne d'impersonation via iam.serviceAccounts.actAs ou iam.serviceAccounts.getAccessToken.

Équivalent Azure : abus de Microsoft.Authorization/roleAssignments/write qui permet à une identité de s'attribuer elle-même de nouveaux rôles.

3.4 Kubernetes - kubelet et tokens SA

Un attaquant avec shell sur un pod peut :

1. Lire le token monté par défaut : /var/run/secrets/kubernetes.io/serviceaccount/token.
2. Énumérer l'API Kubernetes selon les permissions du SA (souvent trop larges).
3. Si le kubelet est exposé et mal configuré, récupérer les tokens d'autres pods du même node.
4. Pivoter vers d'autres namespaces via exec dans d'autres pods.

Mitigation : automountServiceAccountToken: false par défaut, RBAC strict, API restreinte au minimum.

3.5 Supply chain via packages tiers

Un package npm / PyPI / Maven compromis peut contenir du code qui exfiltre les credentials du service account qui exécute le pipeline CI. Cas récents : event-stream (npm 2018), ua-parser-js (2021), shhgit-like leak (2024). Le pipeline CI devient un vecteur d'exfiltration.

Mitigation : SBOM, attestation SLSA, execution CI sans credentials long-lived (OIDC), pinning strict des dépendances.

3.6 OAuth apps abusives

Un attaquant crée (ou usurpe) une OAuth app qui demande à un utilisateur des scopes larges (admin.directory.user, drive, mail.readwrite). Consentement du user trompé = accès persistant pour l'attaquant, même après changement de mot de passe. Cas Midnight Blizzard (Microsoft 2024), et de nombreuses attaques Google Workspace.

Mitigation : admin consent obligatoire sur scopes sensibles, inventaire OAuth, alerte sur nouvelles apps.

4. Bonnes pratiques fondamentales

4.1 Ownership documenté

Chaque service account a un human owner clairement identifié :

• Stocké en tag/metadata sur le compte.
• Revu lors des movers/leavers de l'owner (transfert à un successeur).
• Alerte automatique si owner inactif.

Sans owner, pas de rotation, pas d'audit utile, pas de déprovisioning fiable.

4.2 Least privilege strict

Voir least privilege en pratique pour le détail. Spécificités service accounts :

• Politique précise, pas managed large.
• Conditions IAM (ressource spécifique, région, VPC).
• Permissions dérivées de l'usage réel observé (CloudTrail des 90 derniers jours + AWS Access Analyzer).
• Revue trimestrielle obligatoire.

4.3 Workload identity quand possible

La règle d'or 2026 : remplacer les credentials statiques par de la workload identity basée sur la plateforme.

Bénéfices : pas de credential à stocker, pas de rotation à faire, audit natif lié à la plateforme, compromission très difficile.

4.4 Rotation automatique

Si credentials statiques inévitables : rotation automatique obligatoire. Durée typique :

• Clés API : 90 jours maximum.
• Credentials DB : 30 jours ou dynamic secrets (nouveau credential à chaque connexion).
• Tokens OAuth long-lived : 180 jours maximum.

Outils : Vault dynamic secrets, AWS Secrets Manager rotation, GCP Secret Manager + Cloud Scheduler, Azure Key Vault rotation policies.

4.5 Secrets vault obligatoire

Aucun secret en clair dans :

• Code source ou configs committées.
• Variables d'environnement par défaut sans protection.
• ConfigMaps Kubernetes.
• Documents internes (Notion, Confluence, Google Docs).

Plateformes : HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, CyberArk, Doppler, Infisical.

4.6 Ephemeral credentials

Quand possible : tokens courte durée (15 minutes à quelques heures) plutôt que crédentiels long-lived.

• AWS STS AssumeRole : tokens 15 min à 12h.
• GCP GenerateAccessToken : tokens 1h par défaut.
• GitHub Actions OIDC : tokens éphémères par job.
• Vault : dynamic credentials générés à la demande.

4.7 Audit et monitoring

• Logs de toutes les actions d'un service account vers SIEM.
• Alertes sur comportements anormaux (volume, géographie, heure, ressources accédées).
• ITDR étendu aux identités non-humaines (catégorie émergente 2024-2026).
• Kill switch rapide : révocation instantanée en cas de suspicion.

5. Par environnement - implémentations concrètes

5.1 AWS

Mauvaise pratique : créer un IAM user avec access keys, stocker les clés dans .env ou variables d'environnement de production.

Bonnes pratiques modernes :

• IAM Roles + Instance Profiles sur EC2 : l'instance hérite du rôle, pas de credentials statiques.
• IRSA (IAM Roles for Service Accounts) sur EKS : chaque pod assume un rôle via OIDC du cluster.
• EKS Pod Identity (2023+) : alternative plus simple à IRSA.
• Lambda execution role : rôle attaché à la fonction.
• Fargate Task Role : rôle attaché à la tâche ECS/Fargate.
• GitHub Actions → AWS via OIDC : pas de secret, token JWT échangé contre credentials STS.

Pour le résiduel IAM users : rotation automatique via Secrets Manager ou AWS IAM Roles Anywhere pour environnements on-premise.

Exemple Terraform - rôle IRSA :

data "aws_iam_policy_document" "assume_role_policy" {
  statement {
    actions = ["sts:AssumeRoleWithWebIdentity"]
    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.eks.arn]
    }
    condition {
      test     = "StringEquals"
      variable = "${replace(aws_iam_openid_connect_provider.eks.url, "https://", "")}:sub"
      values   = ["system:serviceaccount:payments:api"]
    }
  }
}
 
resource "aws_iam_role" "payments_api" {
  name               = "payments-api-role"
  assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
}

Le pod avec SA api dans namespace payments peut assumer le rôle - pas d'autre pod, pas de credential statique.

5.2 GCP

Workload Identity Federation : le mécanisme préféré en 2026.

• Pas de service account key JSON à télécharger ni stocker.
• Federation avec identity provider externe (Kubernetes, GitHub Actions, GitLab CI).
• Token JWT de la plateforme échangé contre credentials GCP courte durée.

Exemple GitLab CI → GCP :

deploy:
  id_tokens:
    GCP_ID_TOKEN:
      aud: https://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/gitlab-pool/providers/gitlab
  script:
    - gcloud iam workload-identity-pools create-cred-config ... --output-file=/tmp/creds.json
    - export GOOGLE_APPLICATION_CREDENTIALS=/tmp/creds.json
    - gcloud storage ls

Pas de JSON key côté GitLab, pas de rotation à gérer.

Pour GKE : Workload Identity (intra-GCP) lie un ServiceAccount K8s à un service account GCP sans credential.

5.3 Azure

Managed Identities (System-assigned ou User-assigned) : l'identité est attachée à la ressource Azure (VM, App Service, Function, Container Instance).

• System-assigned : identité créée/détruite avec la ressource.
• User-assigned : identité réutilisable entre ressources.

Code applicatif :

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient
 
credential = DefaultAzureCredential()
client = BlobServiceClient(
    account_url="https://monstorage.blob.core.windows.net",
    credential=credential
)

DefaultAzureCredential récupère automatiquement le token via l'Instance Metadata Service. Pas de secret en dur.

Pour GitHub Actions → Azure : OIDC federation via Azure AD (2021+), équivalent moderne au classique client_secret.

5.4 Kubernetes

• ServiceAccount dédié par workload, jamais le default.
• automountServiceAccountToken: false par défaut, activé sélectivement.
• RBAC strict (Role scopé namespace + Binding précis).
• Projected tokens avec audience spécifique pour OIDC vers providers externes.

Exemple complet (vu dans l'article sur le least privilege) :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-reader
  namespace: payments
automountServiceAccountToken: false

5.5 CI/CD (GitHub, GitLab, CircleCI)

OIDC vers cloud providers : la révolution 2021-2024. Le runner CI/CD émet un JWT signé, le cloud provider (AWS/GCP/Azure) accepte ce JWT comme identité pour émettre des credentials courts.

• Pas de secret cloud stocké dans le CI.
• Audit clair côté cloud (qui, quel repo, quelle branche, quel job).
• Révocation simple (on modifie les conditions du rôle côté cloud).

Exemple GitHub Actions → AWS :

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: eu-west-3
      - run: aws s3 ls s3://monbucket/

Pas de AWS_ACCESS_KEY_ID, pas de secret GitHub. Juste de l'OIDC.

5.6 Databases

• Compte applicatif dédié par application.
• Authentification IAM native quand possible (AWS RDS IAM auth, Cloud SQL IAM, Cosmos DB AAD).
• Si password obligatoire : stockage Vault + rotation automatique + injection à la connexion.
• Audit logs activés et exportés.

6. Standards et patterns émergents

6.1 SPIFFE / SPIRE

SPIFFE (Secure Production Identity Framework For Everyone) est un standard CNCF qui définit :

• SPIFFE ID : URI unique pour chaque workload (ex. spiffe://example.com/payments/api).
• SVID (SPIFFE Verifiable Identity Document) : certificat X.509 ou JWT prouvant l'identité.

SPIRE est l'implémentation de référence. Bénéfices :

• Identité workload portable entre cloud providers.
• Rotation automatique courte durée (5 minutes à 1 heure).
• mTLS automatique entre services.
• Standard ouvert, pas de lock-in vendor.

Adopté par : Pinterest, Bloomberg, Uber, Yahoo, ByteDance, plus de nombreuses implémentations cloud native.

6.2 Sigstore - keyless signing

Sigstore (projet Linux Foundation, 2021) : signature d'artefacts sans clé privée stockée.

• Cosign signe avec l'identité OIDC du pipeline CI (GitHub Actions, GitLab CI).
• Signatures enregistrées dans Rekor (transparency log public).
• Vérification : chaque artefact prouve qui l'a construit et via quel pipeline.

Remplace les chaînes PGP complexes et fragiles. Adopté par Kubernetes, Tekton, Red Hat, etc.

6.3 mTLS et service mesh

Authentification mutuelle entre services via certificats TLS, automatisée par service meshes :

• Istio : Certificate management via Citadel, mTLS automatique.
• Linkerd : équivalent plus léger.
• Consul Connect : mTLS Service Mesh HashiCorp.

Chaque service a un certificat d'identité, rotation courte, zéro credential applicatif.

6.4 Workload attestation

Au-delà de l'identité, attester le contexte : quel code est exécuté, sur quelle plateforme, depuis quel pipeline. Standards :

• in-toto : attestations supply chain.
• SLSA (Supply-chain Levels for Software Artifacts) : niveaux de maturité attestation.
• TPM / TEE based attestation : attestation matérielle.

7. Non-Human Identity Management (NHI) - catégorie émergente

7.1 Le constat 2024-2025

Les outils IAM traditionnels (IGA, PAM, CIEM) ciblent essentiellement les humains. Les identités machine échappent à leur périmètre. La catégorie Non-Human Identity Management (NHI) émerge pour combler ce gap.

7.2 Acteurs du marché

Marché naissant en 2024, en forte croissance 2025-2026. Estimation Gartner : 25 % des grandes entreprises auront investi dans des outils NHI dédiés d'ici 2027.

7.3 Fonctionnalités typiques

• Discovery automatique : inventaire des service accounts dans les clouds, Kubernetes, SaaS, CI/CD.
• Ownership attribution : rattachement à un humain via signaux croisés.
• Risk scoring : score par identité basé sur privilèges, usage, exposition, age.
• Lifecycle automation : détection des orphelins, rotation, révocation.
• Anomaly detection : usage atypique signalé.
• Integration workflow : tickets, IGA, SIEM.

8. Gouvernance d'un programme service accounts

8.1 Politique de base

Document court qui établit les règles :

• Toute identité non-humaine doit avoir un human owner documenté.
• Interdiction des credentials long-lived quand workload identity disponible.
• Rotation obligatoire tous les 90 jours pour les credentials résiduels.
• Interdiction du commit de secrets en clair, enforcé par pre-commit + secret scanning.
• Revue trimestrielle des service accounts et de leurs permissions.

8.2 Inventaire et classification

• Discovery initial : scan cross-plateformes pour lister toutes les identités machine.
• Classification par criticité : accès production / dev / staging.
• Tagging : owner, projet, environnement, criticité.
• Dashboard consolidé : combien d'identités, combien sans owner, combien avec permissions larges.

8.3 Cycle de vie

• Création : via IaC (Terraform), reviewée en PR, human owner obligatoire.
• Modification : via PR, changelog tracé.
• Rotation : automatisée, idéalement transparente.
• Désactivation : trigger lors départ owner, décommissionnement workload, inactivité prolongée.
• Suppression : après période de rétention (30-90 jours), pour réversibilité.

8.4 Audit et mesure

Métriques qui comptent :

9. Erreurs classiques

9.1 Service accounts créés manuellement

Création via console UI cloud, sans IaC, sans PR, sans trace. Mitigation : Terraform obligatoire pour création d'identités non-humaines production.

9.2 Credentials committés "temporairement"

"Je commit pour tester, je retirerai après." Le commit reste dans l'historique Git à perpétuité. Mitigation : pre-commit hooks, GitHub Secret Scanning, éducation.

9.3 Partage entre équipes

Un service account utilisé par 5 équipes = ingouvernable. Mitigation : une identité par usage, clairement délimité.

9.4 Pas de différenciation environnements

Même service account pour dev et prod. Mitigation : credentials et identités distincts par environnement, avec permissions adaptées.

9.5 Oubli lors du décommissionnement

Un workload disparaît, son service account reste. Orphelin indéfini. Mitigation : IaC + destroy comprend la suppression de l'identité.

9.6 Secrets non détectés hors Git

Scans focus sur Git, négligent Slack, Notion, Confluence, tickets Jira qui contiennent aussi des secrets collés par inadvertance. Mitigation : outils de discovery couvrant l'ensemble des SaaS collaboratifs.

9.7 Permissions jamais revues

Service account créé avec des permissions larges "pour le POC", POC passe en prod, permissions jamais réduites. Mitigation : access reviews trimestrielles obligatoires.

10. Plan d'implémentation - 6 mois

Mois 1 - visibilité

• Discovery des service accounts existants (IAM AWS/GCP/Azure, K8s SAs, OAuth apps, API keys).
• Classification par criticité et environnement.
• Identification des orphelins (sans owner, ou owner parti).
• Inventaire des secrets dans code base via gitleaks/trufflehog.

Mois 2 - quick wins

• Activation OIDC pour CI/CD vers clouds (plus grand vecteur d'exposition).
• Révocation des credentials identifiés comme fuités ou inutilisés depuis plus de 180 jours.
• Attribution d'owners aux service accounts orphelins.
• Déploiement secret scanning pre-commit + GitHub Secret Scanning.

Mois 3 - vault et rotation

• Centralisation des secrets restants dans Vault ou Secrets Manager.
• Rotation automatisée activée pour credentials DB et API critiques.
• Élimination des secrets en clair dans configs et variables d'environnement.

Mois 4 - workload identity

• Migration vers IRSA/Workload Identity Federation/Managed Identities pour workloads cloud.
• Remplacement des IAM users AWS par IAM roles.
• ServiceAccounts K8s dédiés par workload, automountToken off par défaut.

Mois 5 - permissions

• Revue des permissions via AWS Access Analyzer, GCP Policy Analyzer, CIEM.
• Réduction progressive vers least privilege.
• Application des bonnes pratiques sur les nouveaux service accounts créés.

Mois 6 - gouvernance et NHI

• Politique service accounts formalisée.
• Métriques dashboard CISO.
• Évaluation outil NHI si volumétrie justifie (plus de 500 identités machine).
• Access reviews trimestrielles institutionnalisées.

11. Verdict et posture Zeroday

Les service accounts sont la zone aveugle de la plupart des programmes IAM en 2026. Les entreprises protègent leurs utilisateurs humains avec MFA, SSO, access reviews, PAM, mais laissent 10 à 50 fois plus d'identités machine avec des credentials statiques, des permissions larges, aucun owner clair et aucune rotation.

Cette asymétrie est exploitée systématiquement par les attaquants modernes. La protection sécuritaire réelle d'une organisation est aujourd'hui fortement corrélée à la maturité de sa gestion des identités non-humaines, pas uniquement à celle des identités humaines.

Pour un ingénieur IAM : la maîtrise des workload identities (IRSA, Workload Identity Federation, SPIFFE), de la rotation automatisée et des outils NHI est un axe de carrière rentable en forte croissance sur le marché 2026.

Pour une organisation : investir dans le domaine NHI produit un ROI sécuritaire important à coût modéré. La plupart des bonnes pratiques (OIDC CI/CD, workload identity, secret vault) sont gratuites ou low-cost et éliminent immédiatement les vecteurs d'attaque les plus exploités.

Pour approfondir : least privilege en pratique pour le volet permissions, provisioning et déprovisioning pour le lifecycle, sécurité Kubernetes : les bases pour les SAs K8s, sécurité des workloads cloud pour l'articulation multi-plateformes, secrets management dans le cloud pour la gestion des credentials résiduels.