Rôle
Sécurité
Ensemble nommé de permissions qu'on attribue à une identité (utilisateur, groupe, compte de service) plutôt que de lui accorder chaque droit un par un. Le contrôle d'accès vérifie le rôle détenu, pas la personne qui le porte.
Principe : On attache les permissions au rôle, puis on attribue le rôle aux identités. Arrivée, mutation ou départ se gèrent en ajoutant ou en retirant un rôle, sans toucher aux droits eux-mêmes.
Moindre privilège : Un rôle décrit une fonction, pas une personne ni un dépannage. Celui qu'on taille pour quelqu'un en particulier porte son nom, survit à son départ, et finit attribué à trois successeurs qui n'ont jamais exercé le même métier.
Le même mot, trois objets : Kubernetes sépare le rôle, qui dit ce qui est permis, de sa liaison, qui dit à qui ; PostgreSQL ne distingue pas rôle, utilisateur et groupe, un rôle autorisé à se connecter étant un utilisateur ; dans le cloud, un service endosse un rôle et reçoit des jetons temporaires plutôt qu'un secret permanent à stocker dans le code. Avant de lire une politique, savoir lequel des trois on a sous les yeux.
Explosion des rôles : Créer un rôle par cas particulier produit des centaines de rôles quasi identiques que plus personne ne sait auditer. Au-delà d'un certain seuil, un contrôle fondé sur des attributs (ABAC) prend souvent le relais.
Ce qui arrive si on s'en passe
Sans rôles, chaque permission est accordée directement à chaque identité, une par une. Les droits s'accumulent au fil des changements de fonction et des besoins ponctuels, et rien ne les retire : une identité conserve des accès dont elle n'a plus l'usage, et un compte compromis donne accès à tout ce qui lui a été accordé un jour. Pour savoir qui peut faire quoi, il faut alors inventorier les droits identité par identité, ce qui rend l'audit lent et incomplet. Au départ d'une personne, chaque droit doit être retrouvé et révoqué séparément ; un seul oubli laisse un accès actif. Deux identités censées avoir le même périmètre finissent par diverger sans que rien ne le signale, et une règle de séparation des tâches ne peut plus être vérifiée sur un ensemble nommé, puisque cet ensemble n'existe pas.
Explication de la marmotte
Dans un lycée, on ne distribue pas les clés une par une à chaque personne. On décide plutôt que les profs ouvrent les salles de classe, que la cantinière ouvre la cuisine et que le concierge ouvre tout le bâtiment. Ces étiquettes « prof », « cantinière » et « concierge » sont des rôles. Quand une nouvelle prof arrive, on lui donne l'étiquette « prof » et elle reçoit d'un coup tous les accès qui vont avec. Quand elle part, on lui retire l'étiquette et tous ses accès disparaissent. Un ordinateur ou un site web fonctionne de la même façon : il classe les gens par rôles pour savoir qui a le droit de faire quoi, sans devoir régler chaque personne à la main.
Où ce terme est utilisé
- Installer et sécuriser PostgreSQL auto-hébergé sur Debian (27 occurrences)
- SSRF vers IMDS et vol d’identifiants IAM (22 occurrences)
- Mettre en place la fédération d’identité de charge (18 occurrences)
- AI Act : fournisseur, déployeur, importateur et requalification en fournisseur (16 occurrences)
- Détecter la persistance IAM dans AWS (15 occurrences)
- OIDC pour sécuriser les identifiants CI/CD (13 occurrences)
- Accès juste-à-temps et privilèges temporaires (12 occurrences)
- Mettre en place un accès JIT AWS pour comptes à privilèges (12 occurrences)
- Configurer GitHub Actions OIDC vers AWS sans clé statique (11 occurrences)
- AI Act : réclamation et droit à l'explication (articles 85 et 86) (10 occurrences)