Le contrôle d’accès basé sur les rôles (RBAC, Role-Based Access Control) est un modèle d’autorisation au sein de l’IAM qui définit qui peut accéder à quelles ressources dans votre application.

Le contrôle RBAC répond à la question essentielle de l’autorisation, qui est de savoir ce que peut faire un utilisateur authentifié donné, mais au lieu d’attribuer des autorisations individuelles à chaque utilisateur, ces autorisations sont regroupées en rôles. Vous attribuez aux utilisateurs un ou plusieurs rôles, chacun lui conférant un ensemble défini d’autorisations. Cette approche simplifie la gestion des utilisateurs, renforce la sécurité et s’adapte bien aux applications modernes.

Le contrôle RBAC est défini par la relation entre les utilisateurs, les rôles et les autorisations.

• Utilisateur : personne ou entité authentifiée qui cherche à accéder à un système.
• Autorisation (ou privilège) : droit granulaire d’effectuer une action spécifique sur une ressource.
  Les autorisations sont exprimées en tant que paires action-ressource :
  • read:Patients
  • update:Configuration
  • delete:Posts
• Rôle : ensemble d’autorisations qui définissent une fonction spécifique ou un niveau d’accès dans l’application (un même utilisateur pouvant avoir plusieurs rôles).

Comment fonctionne le contrôle RBAC ?

Appliquez le contrôle RBAC en trois étapes logiques :

1. Définir des autorisations : déterminez le niveau d’actions le plus bas qu’un utilisateur peut effectuer dans l’application (par exemple create, read, update, delete pour une ressource donnée).
2. Attribuer des autorisations aux rôles : regroupez les autorisations en rôles logiques (par exemple le rôle « administrateur » peut avoir toutes les autorisations, tandis que le rôle « lecteur » ne dispose que des autorisations read).
3. Attribuer des rôles aux utilisateurs : attribuez aux utilisateurs les rôles correspondant à leurs responsabilités.

Lorsqu’un utilisateur initie l’accès à une ressource, le système vérifie les rôles attribués à l’utilisateur pour déterminer s’ils détiennent collectivement les autorisations requises.

Le contrôle RBAC établit un équilibre entre simplicité et sécurité pour les applications pilotées par API.

• Gestion simplifiée : au lieu de gérer les autorisations de milliers d’utilisateurs individuels, vous gérez un ensemble plus restreint de rôles. La modification des autorisations d’un rôle met immédiatement à jour l’accès de tous les utilisateurs concernés.
• Clarté et auditabilité : le contrôle RBAC permet de définir des privilèges d’accès lisibles par les humains et applicables par les machines, ce qui facilite les audits et le respect du principe du moindre privilège.
• Évolutivité : à mesure qu’une application se développe, l’onboarding de nouveaux utilisateurs est effectué en leur attribuant des rôles existants, plutôt qu’en créant de nouveaux ensembles d’autorisations complexes.

Prenons l’exemple d’une API backend d’e-commerce type avec les ressources clés : Produits, Commandes, Clients et Analyses.

Rôle - Autorisations - Exemples d’utilisateurs

Lorsque Priya (responsable de l’inventaire) tente de réaliser les opérations suivantes :

• Consulter une liste de produits : l’accès est accordé parce que le rôle Responsable de l’inventaire comprend l’autorisation read:Produits.
• Modifier la description d’un produit : l’accès est accordé parce que le rôle Responsable de l’inventaire comprend l’autorisation update:Produits.
• Consulter les données personnelles d’un client : l’accès est refusé car le rôle Responsable de l’inventaire n’inclut pas l’autorisation read:Clients.

Cet exemple illustre comment les autorisations sont automatiquement héritées par le rôle, permettant un contrôle granulaire des accès sans nécessiter un mappage direct utilisateur-autorisations.

Sur les plateformes SaaS B2B où plusieurs organisations clientes partagent la même infrastructure applicative, le contrôle RBAC devient spécifique à l’organisation. Un utilisateur peut avoir différents rôles dans différentes organisations.

Lorsqu’un utilisateur s’authentifie, le système d’autorisation doit évaluer non seulement le rôle de l’utilisateur, mais aussi le rôle de l’utilisateur dans cette organisation spécifique. Le JWT inclut à la fois l’identité de l’utilisateur et un identifiant d’organisation, garantissant l’application des autorisations basées sur les rôles dans les limites des tenants concernés. Cela empêche l’élévation des privilèges entre les organisations clientes et garantit une isolation stricte des données dans les architectures multitenants.

Si le contrôle RBAC fonctionne bien pour la plupart des applications, d’autres modèles d’autorisation peuvent mieux convenir à des scénarios plus complexes.

Le contrôle RBAC fournit une autorisation forte pour la plupart des applications, en particulier lorsque les autorisations des utilisateurs s’alignent sur les rôles organisationnels définis. Pour la majorité des applications SaaS B2B, il permet un contrôle des accès suffisant (éventuellement complété par des contrôles des attributs de base), sans complexité inutile.

Toutefois, le contrôle RBAC atteint ses limites lorsque les décisions d’accès nécessitent un contexte que les rôles seuls ne peuvent pas saisir. Si vous devez appliquer des règles telles que « les utilisateurs ne peuvent modifier que les documents qu’ils ont créés » ou « l’accès est limité en dehors des heures de bureau », ces scénarios impliquent des relations avec des ressources ou des attributs environnementaux spécifiques. Dans ces cas, les modèles ABAC ou ReBAC deviennent nécessaires pour éviter de créer des solutions de contournement complexes en plus du contrôle RBAC.

Dans les architectures modernes pilotées par API, les tokens d’accès appliquent un contrôle RBAC. Sécurisez vos API à l’aide de protocoles tels qu’OAuth 2.0 et OpenID Connect (OIDC). (Dans OAuth 2.0, les champs d’application représentent les autorisations ; traduisez les rôles en champs d’application ou en revendications personnalisées en fonction de l’implémentation IdP).

1. Authentification : l’utilisateur se connecte avec un fournisseur d’identité (IdP).
2. Mappage des autorisations : l’IdP détermine les rôles de l’utilisateur et les autorisations correspondantes sur la base du modèle RBAC défini.
3. Émission de tokens : l’IdP génère un token d’accès JSON Web Token (JWT). La charge utile du JWT contient des revendications, telles que des rôles, des champs d’application ou des attributs personnalisés, que les API en aval utilisent pour appliquer le contrôle RBAC.
4. Application des API (autorisation) : lorsque l’utilisateur effectue un appel d’API, l’API backend valide le JWT. Elle vérifie ensuite les revendications des rôles/autorisations dans le token pour appliquer les règles du contrôle RBAC avant d’accorder l’accès à une ressource ou à une action.

Cette approche par token rend l’API sans état. Les données d’autorisation nécessaires sont contenues dans le token et signées cryptographiquement.

Bien que les JWT constituent un moyen sans état et évolutif d’appliquer le contrôle RBAC en transportant les données de rôle et d’autorisation dans le token d’accès, suivez les pratiques de sécurité suivantes pour éviter les vulnérabilités :

• Principe du moindre privilège : n’attribuez que le minimum de rôles et d’autorisations nécessaires à la fonction d’un utilisateur.
• Durée de vie et révocation des tokens : les tokens d’accès JWT sont difficiles à révoquer immédiatement, car ils sont validés localement.
  • Recommandation : utilisez des tokens d’accès de courte durée (par exemple 15 à 60 minutes) et renouvelez les tokens d’actualisation.
• Validation côté serveur : validez chaque JWT à chaque demande.
  • Intégrité : vérifiez la signature du token.
  • Expiration : vérifiez la revendication exp.
  • Profils cibles : vérifiez que la revendication aud correspond à votre application.
  • Autorité : vérifiez que la revendication iss correspond à l’émetteur attendu.
  • Rotation des clés : validez les tokens par rapport au JSON Web Key Set (JWKS) de l’IdP pour prendre en charge la rotation des clés et préserver l’intégrité des signatures.
• Stockage des rôles et des autorisations : n’incluez que les revendications de rôle et d’autorisation nécessaires. Évitez les données à caractère personnel sensibles.
• Stockage des tokens : ne stockez jamais de tokens sensibles dans localStorage ou sessionStorage, car cela peut entraîner des attaques XSS (Cross-Site Scripting). Utilisez des cookies HttpOnly sécurisés ou le stockage de session backend.
• Traitement clair des erreurs : lorsque l’API reçoit une requête, renvoyez des codes d’état HTTP spécifiques en fonction du type d’échec.
  • 401 Unauthorized : l’utilisateur n’a pas réussi à prouver son identité (échec de l’authentification, par exemple token absent ou invalide).
  • 403 Forbidden : l’identité de l’utilisateur est connue (authentifiée), mais ses rôles/autorisations (RBAC) lui interdisent l’accès à la ressource ou à l’action demandée (échec de l’autorisation).

Quel est le principal avantage du contrôle RBAC ?

Le contrôle RBAC permet de simplifier la gestion des utilisateurs et d’améliorer l’auditabilité. Vous gérez un petit ensemble de rôles plutôt qu’une matrice vaste et complexe d’autorisations d’utilisateurs individuels.

Le contrôle RBAC est-il un modèle de sécurité robuste ?

Oui, le contrôle RBAC est un modèle d’autorisation robuste et fondamental pour les applications où les fonctions et les autorisations des utilisateurs sont statiques et prévisibles.

Le contrôle RBAC gère-t-il les accès conditionnels ?

Non. Pour les accès conditionnels reposant sur des facteurs tels que l’heure, la localisation ou la valeur des ressources, utilisez le contrôle d’accès basé sur les attributs (ABAC). Le contrôle RBAC se concentre sur le rôle assigné à l’utilisateur.

Le contrôle RBAC est un modèle puissant de contrôle des accès, mais ce n’est qu’un composant parmi d’autres d’une stratégie complète de gestion des identités et des accès. Explorez notre série d’articles « Introduction à l’IAM » pour en savoir plus sur la gestion des identités et des accès.

En savoir plus

Le contenu de ce document revêt un caractère purement informatif. Il vous revient de vous adresser à des conseillers professionnels pour obtenir des conseils en matière de sécurité, confidentialité, conformité ou conduite des affaires, et de ne pas vous en remettre aux recommandations formulées dans le présent document.