Rôle -Based Access Control (RBAC) décrit une approche de la sécurité du système dans laquelle les utilisateurs se voient attribuer un ou plusieurs rôles distincts. Les rôles attribués déterminent les fonctions d'application disponibles pour l'utilisateur.
RBAC est un moyen populaire d'appliquer des contraintes d'accès utilisateur, car il permet d'accorder des autorisations granulaires qui correspondent aux responsabilités de chaque individu. De nombreux systèmes exigent que certains utilisateurs puissent créer des données, que d'autres puissent les consulter et que les administrateurs obtiennent un accès illimité. RBAC peut mettre en œuvre toutes ces exigences.
Que sont les rôles RBAC ?
Un rôle RABC est un ensemble d'autorisations. Les autorisations représentent les actions uniques que les utilisateurs peuvent effectuer dans votre système. Ils peuvent être aussi spécifiques que vous le souhaitez. Votre base de code doit protéger les points de terminaison protégés à l'aide d'une vérification des autorisations.
Les rôles regroupent les autorisations afin qu'elles puissent être attribuées plus facilement aux utilisateurs. Voici un exemple rapide de la différence entre un rôle et une autorisation :
Autorisations
- Créer un nouvel article .
- Publier un article.
- Supprimer un article.
Rôles
- < li>Auteur : Autorisation 1.
- Éditeur : autorisation 1 et autorisation 2.
- Administrateur : toutes les autorisations.
Utilisateurs
- Utilisateur A : Rôle d'auteur.
- Utilisateur B : Rôle d'éditeur.
Ce modèle signifie que l'utilisateur A peut uniquement créer des articles tandis que l'utilisateur B peut créer et publier.
Dans une application réelle, vous pourriez avoir beaucoup plus d'autorisations. Les attribuer directement aux utilisateurs serait fastidieux. Le concept de rôle fait le lien entre des contrôles d'autorisation précis et une expression claire des responsabilités de l'utilisateur.
La plupart des implémentations RBAC permettent aux utilisateurs d'avoir n'importe quel nombre de rôles. Les rôles peuvent se chevaucher si nécessaire. Si la même autorisation existe dans deux des rôles de l'utilisateur, son compte satisfera toujours les vérifications de contrôle d'accès dans le code.
Mise en œuvre de RBAC
< p>RBAC peut être relativement compliqué à mettre en œuvre dans un système. Vous devez évaluer le nombre d'autorisations dont vous avez besoin, la manière dont elles seront appliquées et la manière dont les rôles seront créés et attribués aux utilisateurs. Vous pourrez peut-être gérer un nombre fixe de rôles pour commencer, mais de nombreuses applications plus importantes permettront aux utilisateurs de créer leurs propres rôles pour des cas d'utilisation spécifiques.
Il est préférable de planifier soigneusement vos besoins avant de vous lancer dans l'intégration de RBAC. Réduire autant que possible la portée de votre implémentation peut aider à réduire la complexité. Commencez par les contrôles d'accès minimaux sans lesquels votre application ne peut pas fonctionner, puis ajoutez des rôles et des contrôles supplémentaires au fil du temps.
Un autre aspect du RBAC est lorsque les rôles s'appliquent par rapport à une ressource spécifique. Par exemple, un utilisateur peut être autorisé à soumettre de nouveaux articles au “Blog” catégorie mais pas “Études de cas.” Désormais, vos vérifications d'autorisation devront tenir compte de la catégorie avec laquelle l'utilisateur interagit. Vous pouvez gérer ce flux en créant dynamiquement de nouvelles autorisations pour chaque catégorie et en leur attribuant un identifiant prévisible.
Vous pourrez peut-être simplifier vos contrôles d'autorisation en utilisant un système externe pour la gestion et l'autorisation des identités. Les systèmes de contrôle d'accès basés sur des politiques qui prennent en charge RBAC, tels que Auth0 et Cerbos, peuvent vous aider à configurer une logique d'autorisation complexe sans modifier en profondeur votre propre code. Ces plates-formes peuvent également offrir un moyen plus simple de réaliser des vérifications d'autorisation liées aux ressources.
Un système externe est souvent exagéré pour les petits projets qui fonctionnent avec un nombre limité de rôles et d'autorisations. Dans ces cas, vous pouvez créer une implémentation RBAC à partir de deux tables de base de données : une qui associe les autorisations aux rôles et une autre qui lie les rôles aux utilisateurs. Pour vérifier si un utilisateur peut effectuer une action, parcourez ses rôles et voyez si un rôle inclut l'autorisation requise.
Inconvénients RBAC
RBAC offre une sécurité accrue et des octrois d'autorisations plus flexibles lorsqu'il est correctement implémenté. Cependant, il présente également certains inconvénients qu'il convient de reconnaître avant de l'utiliser pour protéger votre système.
Le plus important d'entre eux est sans doute la facilité avec laquelle les applications basées sur RBAC peuvent être encombrées de rôles inutilisés et dupliquées. autorisations. Les rôles ne doivent être créés que lorsqu'ils satisfont à une nouvelle exigence ou reflètent une responsabilité d'utilisateur distincte. Avoir trop de rôles rendra votre système plus difficile à maintenir et réduira la visibilité sur les subventions dont chaque utilisateur a besoin.
Il est également important de revoir régulièrement les attributions de rôle à utilisateur. Les rôles doivent être précis afin que les utilisateurs puissent se voir attribuer l'ensemble minimal de rôles dont ils ont besoin pour leur travail. L'attribution d'un trop grand nombre de rôles ou la mise en place d'un grand nombre d'autorisations dans chaque rôle peut rendre les comptes trop privilégiés. Cela augmente le risque pour votre application si un compte est compromis.
Le RBAC nécessite également une connaissance préalable du fonctionnement de votre système et des limites entre les responsabilités. Essayer d'implémenter RBAC sans cette compréhension sera normalement sous-optimal car vos autorisations et vos rôles seront soit trop larges, soit trop précis. La taille et la forme de votre solution RBAC doivent normalement refléter le fonctionnement de vos opérations internes.
Résumé
Le contrôle d'accès basé sur les rôles est l'une des formes les plus courantes de contrainte d'accès utilisateur dans les applications logicielles. Il vous permet de configurer des autorisations granulaires qui sont ensuite combinées en rôles à attribuer aux utilisateurs. L'approche offre un degré élevé de flexibilité et de personnalisation, mais peut également entraîner des ballonnements si vous n'auditez pas activement les rôles utilisés.
Les alternatives au RBAC incluent des listes de contrôle d'accès, qui agissent comme des règles qui accorder ou refuser l'accès en fonction des conditions et le contrôle d'accès basé sur les attributs (ABAC) qui protège l'accès en fonction des attributs de l'utilisateur demandeur. ABAC peut offrir une flexibilité encore plus grande lorsque les utilisateurs ont de nombreux rôles, mais RBAC est un meilleur choix lorsque vous souhaitez que votre système de contrôle d'accès représente étroitement la structure de votre organisation.
LIRE LA SUITE
- < li>&rsaquo ; 10 fonctionnalités iPhone que vous devriez utiliser
- › 10 fonctionnalités du casque VR Quest que vous devriez utiliser
- &rsaquo ; Examen de la chaise de jeu Vertagear SL5000 : confortable, réglable, imparfaite
- &rsaquo ; Examen du chargeur UGREEN Nexode 100 W : plus qu'assez de puissance
- &rsaquo ; Le Samsung Galaxy Z Flip 4 a des mises à niveau internes, pas des modifications de conception
- › Les 5 plus grands mythes sur Android