Comment les applications modernes gèrent les rôles et les permissions
Votre utilisateur peut consulter un document. Mais peut-il le partager ? Peut-il le partager avec n’importe qui, ou uniquement au sein de son organisation ? Peut-il révoquer l’accès qu’il a accordé ? Ces questions révèlent pourquoi le contrôle d’accès traditionnel basé sur les rôles ne fonctionne plus dans les applications modernes.
Les rôles statiques comme « admin », « éditeur » et « lecteur » fonctionnaient lorsque les applications étaient plus simples. Les produits SaaS collaboratifs et multi-tenants d’aujourd’hui nécessitent quelque chose de plus flexible. Cet article explique comment les modèles d’autorisation modernes résolvent ces défis et pourquoi le secteur a dépassé la logique basée uniquement sur les rôles pour adopter une autorisation à granularité fine.
Points clés à retenir
- Le RBAC traditionnel peine avec les permissions dynamiques basées sur les relations et conduit à une explosion des rôles dans les applications complexes
- Le ReBAC détermine l’accès via les relations entre entités, faisant du partage et de la collaboration des concepts de première classe
- L’ABAC évalue l’accès en fonction des attributs de l’utilisateur, de la ressource et du contexte pour des règles dépendantes du contexte
- La plupart des systèmes en production combinent le RBAC pour les catégories générales avec le ReBAC pour les permissions au niveau des ressources
- Les approches de type « policy-as-code » rendent la logique d’autorisation testable, auditable et versionnée
Pourquoi le RBAC traditionnel est insuffisant
Le contrôle d’accès basé sur les rôles (RBAC) attribue des permissions via des rôles. Un utilisateur obtient le rôle « éditeur », qui accorde un ensemble prédéfini de permissions. Simple et intuitif.
Le problème apparaît à mesure que les applications se développent. Prenons l’exemple d’un outil de gestion de projet où les utilisateurs ont besoin de différents niveaux d’accès par projet, par espace de travail et par type de document. Vous commencez à créer des rôles comme « éditeur-projet-A » et « admin-espace-B ». Cette explosion de rôles rend le système ingérable.
Le RBAC peine également avec les questions basées sur les relations. « Cet utilisateur peut-il modifier ce document ? » dépend de s’il en est propriétaire, si quelqu’un l’a partagé avec lui, ou s’il appartient à une équipe qui y a accès. Les rôles statiques ne peuvent pas exprimer ces conditions de manière élégante.
Modèles d’autorisation modernes
Contrôle d’accès basé sur les relations (ReBAC)
Le ReBAC détermine l’accès via les relations entre entités. Au lieu de demander « cet utilisateur a-t-il le rôle d’éditeur ? », vous demandez « cet utilisateur a-t-il une relation d’éditeur avec ce document ? »
Le système Zanzibar de Google a été pionnier de cette approche à grande échelle. Lorsque vous partagez un Google Doc, vous créez une relation. Le système parcourt ensuite ces relations pour répondre aux questions de permissions. Des outils comme OpenFGA, SpiceDB et Permify implémentent des modèles inspirés de Zanzibar pour des applications de toute taille.
Le ReBAC gère naturellement les scénarios collaboratifs. Le partage, l’appartenance à une équipe et les hiérarchies organisationnelles deviennent des concepts de première classe plutôt que des contournements maladroits de rôles.
Contrôle d’accès basé sur les attributs (ABAC)
L’ABAC évalue l’accès en fonction des attributs des utilisateurs, des ressources et du contexte. Une politique pourrait stipuler : « les utilisateurs peuvent accéder aux documents si leur département correspond au département du document et si la requête a lieu pendant les heures de bureau ».
Ce modèle excelle dans les règles dépendantes du contexte. Les applications de santé utilisent l’ABAC pour appliquer les exigences HIPAA : l’accès dépend de la relation patient-prestataire, de la sensibilité des données et du contexte d’accès.
RBAC vs ReBAC : quand utiliser chacun
Le RBAC reste approprié pour les applications avec des frontières de permissions claires et statiques. Les outils internes avec des types d’utilisateurs bien définis bénéficient de sa simplicité.
Le ReBAC convient mieux lorsque les permissions dépendent de la propriété des ressources, du partage ou de la structure organisationnelle. Toute application avec une fonctionnalité de « partage » ou multi-tenant devrait envisager le ReBAC.
La plupart des systèmes en production combinent les deux. Le RBAC gère les catégories générales (administrateur vs. utilisateur standard), tandis que le ReBAC gère les permissions au niveau des ressources.
Discover how at OpenReplay.com.
Modèles architecturaux pour le contrôle d’accès dans les applications web
Séparer l’authentification de l’autorisation
L’authentification répond à « qui est cet utilisateur ? » L’autorisation répond à « que peut-il faire ? » Les architectures modernes traitent ces aspects comme des préoccupations distinctes avec des services dédiés pour chacun.
Votre fournisseur d’identité gère l’authentification. Un service d’autorisation séparé — qu’il soit développé en interne ou géré — gère les décisions de permissions. Cette séparation permet à chaque système d’évoluer indépendamment.
Les politiques en tant que code
Les modèles d’autorisation modernes privilégient l’expression des règles sous forme de code plutôt que de configurations en base de données. « Policy-as-code » signifie que votre logique d’autorisation vit dans le contrôle de version, est révisée dans les pull requests et se déploie via votre pipeline standard.
Open Policy Agent (OPA) utilise Rego pour les définitions de politiques. Cedar, développé par AWS, fournit un autre langage de politique. Ces outils rendent la logique d’autorisation testable et auditable.
Politique centralisée, application distribuée
Le modèle qui passe à l’échelle : définir les politiques de manière centralisée, les appliquer au niveau de chaque service. Votre moteur de politiques maintient les règles. Chaque microservice interroge le moteur pour les décisions de permissions, en mettant souvent en cache les résultats pour des raisons de performance.
Cette architecture maintient l’autorisation cohérente entre les services tout en évitant un point unique de défaillance.
Implications côté frontend
Le backend reste la source de vérité pour toutes les décisions de permissions. Ne faites jamais confiance au frontend pour la sécurité.
Cela dit, les frontends ont besoin d’informations sur les permissions pour une bonne UX. Le « feature gating » — masquer les boutons que les utilisateurs ne peuvent pas cliquer, désactiver les formulaires qu’ils ne peuvent pas soumettre — nécessite de connaître les permissions côté client. Le modèle est simple : utilisez les vérifications de permissions (par exemple, « cet utilisateur peut-il effectuer cette action ? ») pour les décisions d’interface, mais validez toujours côté serveur.
Des bibliothèques comme CASL aident à gérer la logique de permissions côté client tout en maintenant l’application réelle côté serveur.
Conclusion
L’autorisation à granularité fine n’est pas expérimentale — c’est ainsi que fonctionnent les applications modernes. Google, GitHub et Notion utilisent tous des modèles basés sur les relations. Les moteurs de politiques alimentent l’autorisation dans des entreprises de toutes tailles.
Commencez par identifier où votre RBAC actuel rencontre des difficultés. Si vous créez des rôles pour chaque combinaison de permissions, ou si le partage et la collaboration semblent ajoutés après coup, les modèles d’autorisation modernes simplifieront votre système tout en le rendant plus performant.
Le passage de « quel rôle cet utilisateur a-t-il ? » à « quelle relation cet utilisateur a-t-il avec cette ressource ? » change la façon dont vous pensez les permissions. C’est un meilleur modèle mental pour la manière dont les utilisateurs interagissent réellement avec les applications modernes.
FAQ
Le RBAC attribue des permissions via des rôles statiques comme administrateur ou éditeur. Le ReBAC détermine l'accès via les relations entre utilisateurs et ressources. Alors que le RBAC demande « cet utilisateur a-t-il le rôle d'éditeur », le ReBAC demande « cet utilisateur a-t-il une relation d'éditeur avec ce document spécifique ». Le ReBAC gère plus naturellement le partage dynamique et la collaboration.
Oui, la plupart des systèmes en production combinent les deux approches. Le RBAC gère généralement les catégories de permissions générales comme la distinction entre administrateurs et utilisateurs standards. Le ReBAC gère les permissions au niveau des ressources comme le partage de documents et l'accès aux équipes. Cette approche hybride vous offre la simplicité pour les permissions globales et la flexibilité pour le contrôle d'accès spécifique aux ressources.
L'authentification identifie qui est l'utilisateur tandis que l'autorisation détermine ce qu'il peut faire. Séparer ces préoccupations permet à chaque système d'évoluer indépendamment. Votre fournisseur d'identité gère la connexion et la vérification d'identité. Un service d'autorisation dédié gère les décisions de permissions. Cette séparation améliore la maintenabilité et vous permet de remplacer ou de mettre à niveau l'un ou l'autre composant sans affecter l'autre.
Appliquez toujours les permissions côté backend. Le serveur est la source de vérité pour toutes les décisions de contrôle d'accès. Cependant, les frontends ont besoin de données de permissions pour une bonne expérience utilisateur, comme masquer les boutons indisponibles ou désactiver les formulaires restreints. Récupérez les permissions effectives au chargement de la page pour les décisions d'interface, mais validez chaque action côté serveur.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
