Aller au contenu

Compte de service : Service account

Sécurité

Identité non humaine portée par une application, un script ou une machine pour s'authentifier et accéder à des ressources sans qu'aucun utilisateur n'intervienne. Ses droits et ses identifiants se gèrent comme ceux d'un humain, en plus strict.

Diagramme de séquence entre cinq acteurs : Application, Fournisseur d'identité, API cible, Ressource et Journal d'audit. 1. L'application envoie au fournisseur d'identité l'identifiant du compte de service (clé, certificat ou jeton fédéré). 2. Le fournisseur lui renvoie un jeton d'accès à durée courte. 3. L'application envoie à l'API cible sa requête et le jeton d'accès. 4. Si les droits suffisent, l'API exécute l'action autorisée sur la ressource. S'ils sont insuffisants, elle renvoie à l'application un refus 403. 5. L'API inscrit dans le journal d'audit l'action, attribuée au compte de service.

Personne derrière le clavier : Il s'authentifie avec une clé, un certificat ou un jeton, jamais avec un mot de passe tapé à la main ni une validation sur téléphone. Personne ne s'étonnera donc d'une connexion à trois heures du matin depuis un pays où l'entreprise n'a jamais ouvert de bureau : la surveillance doit s'en charger à sa place.

Moindre privilège : On ne lui accorde que les droits exigés par sa tâche, sur les seules ressources concernées. Le compte créé « temporairement » avec les droits d'administrateur pour débloquer une mise en production est presque toujours celui qui survit à l'application, à l'équipe et au prestataire.

Secrets et rotation : Ses identifiants se rangent dans un gestionnaire de secrets et changent à intervalle régulier. Un secret inchangé depuis la mise en service n'est plus un secret, c'est une tradition. Mieux encore : supprimer le secret statique, grâce aux identités gérées par le fournisseur cloud ou à la fédération de jetons.

Un compte par usage : Partager un compte de service entre plusieurs applications rend les journaux muets sur qui a fait quoi. On crée un compte par service : l'audit reste lisible et une révocation ne casse que ce qu'elle doit casser.

Les mêmes sous d'autres noms : Active Directory a ses comptes de service, et ses gMSA dont l'annuaire change le mot de passe tout seul ; Kubernetes ses ServiceAccount et leurs jetons à durée limitée ; les fournisseurs cloud leurs identités gérées et leurs rôles attachés à une machine, une fonction ou un pod ; Unix ses comptes système sans shell de connexion. Le vocabulaire change, la règle ne change pas.

Ce qui arrive si on s'en passe

Sans compte de service, un script ou une application s'authentifie avec le compte d'une personne. Ses identifiants se retrouvent alors dans un fichier de configuration ou une tâche planifiée, et quiconque lit ce fichier obtient l'identité complète de cette personne, avec tous ses droits, bien au-delà de ce que l'automatisme exige. L'authentification multifacteur gêne un processus sans intervention humaine, ce qui pousse à l'exempter de ce compte. Les journaux attribuent à un humain des actions faites par une machine : une action anormale ne se distingue plus de l'activité légitime, et l'enquête perd sa piste. Au départ de la personne, deux issues : désactiver le compte casse les traitements qui en dépendent, le conserver laisse un accès actif sans titulaire. Changer le mot de passe interrompt l'automatisme, si bien que plus personne ne le change.

Explication de la marmotte

Imagine une grande bibliothèque. Chaque visiteur a une carte à son nom. Mais la nuit, un robot range les livres tout seul, et il lui faut aussi un badge pour ouvrir les portes. Ce badge n'appartient à aucune personne : il appartient au robot. Un compte de service, c'est ça, un badge pour un programme qui travaille sans humain à côté. La règle d'or : ne lui ouvrir que les portes dont il a vraiment besoin. Un robot rangeur n'a rien à faire dans le coffre de la directrice. Et si son badge est perdu ou volé, il faut pouvoir le changer très vite, avant que quelqu'un ne s'en serve.

Où ce terme est utilisé

← Tout le glossaire