Contrôle d'accès basé sur les rôles (RBAC)

Qu'est-ce que le contrôle d'accès basé sur les rôles (RBAC) ?

Le contrôle d'accès basé sur les rôles (RBAC, pour Role-Based Access Control) est un modèle où les permissions sont rattachées à des rôles comme administrateur, éditeur ou lecteur, et où les personnes obtiennent leur accès en recevant un rôle. Pour changer ce que peut faire tout un groupe, on modifie un rôle plutôt que des centaines de comptes. Selon le NIST, le modèle formel est dû à Ferraiolo et Kuhn (1992) et il est devenu la norme ANSI/INCITS 359-2004.

Le RBAC répond à la question d'autorisation, que peut faire cette identité, une fois que l'authentification a établi qui elle est. C'est l'un des modèles utilisés dans la gestion des identités et des accès (IAM). L'authentification unique (SSO) décide qui se connecte ; le RBAC décide ce que la personne peut faire ensuite.

Les concepts de base

Exemple : une application SaaS

# Rôles
admin: [users.create, users.delete, billing.view, billing.edit, settings.edit]
editor: [content.create, content.edit, content.publish]
viewer: [content.view]
billing-manager: [billing.view, billing.edit]

# Attributions de rôles
alice@example.com: [admin]
bob@example.com: [editor, billing-manager]
carol@example.com: [viewer]

Bob peut modifier le contenu et gérer la facturation parce qu'il a deux rôles. Quand un nouvel éditeur arrive, vous lui attribuez un rôle et les permissions suivent.

Exemple : Kubernetes

Kubernetes fournit le RBAC sous forme de groupe d'API. Un Role indique quels verbes sont autorisés sur quelles ressources, et un RoleBinding accorde ce Role à des utilisateurs, des groupes ou des comptes de service. Ce Role tiré de la documentation de Kubernetes autorise la lecture des pods dans le namespace default :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Deux détails de la documentation comptent en pratique. Un Role est toujours limité à un namespace, contrairement à un ClusterRole. Et les permissions sont purement additives : il n'existe pas de règles de refus, l'accès d'un utilisateur est donc l'union de tous ses rôles.

RBAC, ABAC et ACL

Le RBAC suffit tant que les permissions dépendent de ce que fait la personne et non des données qu'elle a sous les yeux. Quand les règles dépendent du service, de la région ou de l'heure, ajoutez des contrôles basés sur les attributs. Une liste de contrôle d'accès (ACL) attache des permissions à chaque ressource, ce qui est souple mais difficile à auditer à grande échelle.

Bonnes pratiques RBAC

• Moindre privilège. Donnez à chaque rôle uniquement ce que la fonction exige.
• Séparation des tâches. Faites exiger deux rôles pour les actions sensibles, comme demandeur et approbateur.
• Attribuer par groupes. Rattachez les rôles à des groupes plutôt qu'à des utilisateurs isolés : un départ devient un seul changement.
• Nommer les rôles par fonction. Les intitulés de poste changent, les fonctions durent plus longtemps.
• Documenter chaque rôle. Notez à quoi il sert, qui doit l'avoir et qui le revoit.
• Limiter les comptes à accès total. Beaucoup de personnes avec un accès total représentent déjà un risque.
• Accorder les droits élevés de façon temporaire. Retirez-les automatiquement une fois la tâche terminée.
• Revoir et journaliser. Auditez les attributions régulièrement et conservez qui a accordé quel rôle, et quand.

Erreurs courantes

• Explosion des rôles. Les rôles se multiplient avec l'organisation jusqu'à ce que personne ne sache à quoi ils servent tous. Consolidez régulièrement.
• Accumulation de permissions. Les rôles accumulent des droits avec le temps. Retirez ce qui n'est pas utilisé.
• Trop peu de rôles. Un seul rôle utilisateur laisse tout le monde avec trop ou trop peu de droits.
• Attributions oubliées. Un ancien salarié qui garde le rôle admin signifie que la procédure de départ est défaillante.
• Contrôles de rôle écrits en dur. if user.role == 'admin' éparpillé dans le code est pénible à modifier. Vérifiez des permissions, pas des noms de rôle.
• Mélanger rôles et ACL ponctuelles. Un RBAC à moitié est confus à auditer. Choisissez un modèle par ressource.

Le RBAC dans les équipes LoadFocus et les tests d'API

Les équipes LoadFocus utilisent une version réduite du RBAC. À l'invitation d'un membre, vous choisissez entre Admin, qui peut exécuter, modifier et consulter les tests, et View-only, qui peut seulement les consulter, et vous pouvez limiter une invitation à certains produits comme les tests de charge, JMeter ou la surveillance d'API. Cela couvre le partage habituel : les ingénieurs lancent les tests, les parties prenantes lisent les résultats. Les étapes figurent dans le guide des équipes (en anglais).

Quand vous testez une API dotée de permissions par rôle, utilisez un identifiant par rôle. Un jeton d'administrateur et un jeton de lecteur peuvent emprunter des chemins de code différents et afficher une latence différente sous charge, et un contrôle de permission en échec doit renvoyer un 403 propre, pas un 500. L'accès machine passe en général par une clé d'API. Voir sécurité des API et le guide des tests de performance d'API avec OAuth2 (en anglais) pour les exécutions authentifiées, ainsi que la surveillance d'API pour continuer à vérifier les endpoints protégés après la mise en production.

Questions fréquentes

RBAC ou ABAC : lequel choisir ?

Choisissez le RBAC quand les permissions suivent des fonctions stables, ce qui couvre la plupart des applications. Choisissez l'ABAC quand l'accès dépend d'attributs comme le service, la région ou l'heure. Beaucoup de systèmes combinent les deux : des rôles pour l'essentiel, des attributs pour les exceptions.

Un utilisateur peut-il avoir plusieurs rôles ?

Oui. Dans la plupart des systèmes RBAC, un utilisateur peut détenir plusieurs rôles. Dans Kubernetes, les permissions sont additives : l'utilisateur obtient l'union de tous ses rôles, sans possibilité de soustraire.

Qu'est-ce que l'explosion des rôles ?

C'est ce qui arrive quand on crée un rôle pour chaque exception jusqu'à en avoir trop pour les comprendre ou les auditer. C'est souvent le signe qu'il faut des règles basées sur les attributs pour les exceptions, ou un nettoyage des rôles qui se chevauchent.

Le RBAC remplace-t-il l'authentification ?

Non. L'authentification prouve qui est la personne, le RBAC décide ce que cette identité peut faire. Il faut les deux.

Quels rôles existent dans les équipes LoadFocus ?

Les membres sont invités comme Admin, qui peut exécuter, modifier et consulter les tests, ou comme View-only, qui peut seulement les consulter. Vous pouvez aussi limiter un membre à certains produits LoadFocus.