Qu’est-ce que RBAC et quand l’utiliser ?

Le contrôle d’accès basé sur les rôles (RBAC) décrit une approche de la sécurité du système où les utilisateurs se voient attribuer un ou plusieurs rôles discrets. Les rôles attribués déterminent les fonctions d’application disponibles pour l’utilisateur.

Le RBAC est un moyen populaire de faire respecter les contraintes d’accès des utilisateurs 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 examiner et que les administrateurs aient un accès illimité. RBAC peut mettre en œuvre toutes ces exigences.

Que sont les rôles RBAC ?

Un rôle RABC est une collection de permissions. Les permissions représentent les actions uniques que les utilisateurs peuvent effectuer dans votre système. Elles peuvent être aussi spécifiques que vous le souhaitez. Votre base de code devrait protéger les points de terminaison à l’aide d’un contrôle de permission.

Les rôles regroupent les permissions afin qu’elles puissent être attribuées aux utilisateurs de manière plus pratique. Voici un exemple rapide de la différence entre un rôle et une permission :

Permissions

  1. Créer un nouvel article.
  2. Publier un article.
  3. Supprimer un article.

Rôles

  1. Auteur : Permission 1.
  2. Éditeur : Permission 1 et Permission 2.
  3. Administrateur : Toutes les permissions.

Utilisateurs

  1. Utilisateur A : rôle d’auteur.
  2. 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 du monde réel, vous pourriez avoir beaucoup plus de permissions. Les attribuer directement aux utilisateurs serait fastidieux. Le concept de rôle permet de faire le lien entre les contrôles précis des autorisations et l’expression claire des responsabilités des utilisateurs.

La plupart des implémentations RBAC permettent aux utilisateurs d’avoir un nombre quelconque de rôles. Les rôles peuvent se chevaucher si nécessaire. Si la même permission existe dans deux des rôles de l’utilisateur, son compte satisfera toujours les contrôles d’accès en code.

Mise en œuvre de RBAC

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 comment les rôles seront créés et attribués aux utilisateurs. Vous pourrez peut-être vous contenter d’un nombre fixe de rôles au départ, 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 le champ d’application de votre mise en œuvre peut contribuer à réduire la complexité. Commencez par les contrôles d’accès minimums 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 le cas où les rôles s’appliquent à une ressource spécifique. Par exemple, un utilisateur peut être autorisé à soumettre de nouveaux articles dans la catégorie « Blog » mais pas dans la catégorie « Études de cas ». Vos contrôles d’autorisation devront alors tenir compte de la catégorie avec laquelle l’utilisateur interagit. Vous pourriez gérer ce flux en créant dynamiquement de nouvelles permissions pour chaque catégorie et en leur attribuant un identifiant prévisible.

Vous pourriez simplifier vos contrôles d’autorisation en utilisant un système externe pour la gestion des identités et des autorisations. 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 à mettre en place une logique d’autorisation complexe sans modifier en profondeur votre propre code. Ces plateformes peuvent également offrir une voie plus simple pour réussir les contrôles d’autorisation liés aux ressources.

Un système externe est souvent excessif pour les petits projets qui travaillent avec un nombre limité de rôles et de permissions. Dans ces cas, vous pouvez construire une implémentation RBAC à partir de quelques tables de base de données : une qui associe les permissions aux rôles, et une autre qui relie les rôles aux utilisateurs. Pour vérifier si un utilisateur peut effectuer une action, itérez sur ses rôles et voyez si l’un d’entre eux inclut l’autorisation requise.

Inconvénients de RBAC

Le système RBAC offre une sécurité accrue et des autorisations plus flexibles lorsqu’il est correctement mis en œuvre. Cependant, il est également doté de 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 la facilité avec laquelle les applications basées sur le RBAC peuvent être encombrées de rôles inutilisés et d’autorisations dupliquées. Les rôles ne devraient être créés que lorsqu’ils répondent à une nouvelle exigence ou reflètent une responsabilité distincte de l’utilisateur. Le fait de disposer d’un trop grand nombre 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 l’attribution des rôles aux utilisateurs. Les rôles doivent être précis afin que les utilisateurs puissent recevoir 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 faire en sorte que les comptes deviennent sur-privilégiés. Cela augmente le risque pour votre application si un compte est compromis.

RBAC exige é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 permissions et vos rôles seront soit trop larges, soit d’une précision fastidieuse. 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 des utilisateurs dans les applications logicielles. Il vous permet de définir des autorisations granulaires qui sont ensuite combinées en rôles pour être attribuées aux utilisateurs. Cette approche offre un haut degré de flexibilité et de personnalisation, mais peut également conduire à un engorgement si vous ne vérifiez pas activement quels rôles sont utilisés.

Les alternatives au RBAC comprennent les listes de contrôle d’accès, qui agissent comme des règles qui accordent ou refusent l’accès en fonction de 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. L’ABAC peut offrir encore plus de flexibilité lorsque les utilisateurs ont plusieurs rôles, mais le 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.

Myriam
Myriam

Myriam est passionnée par les technologies grand public et aime bricoler avec les smartphones, les ordinateurs. Elle bidoullait son premier ordinateur à 12 ans, quelques années plus tard c'était au tour des télephones avec le Nokia 3310, le Sony Ericsson et bien d'autres model qui ont disparu de nos jours.


Laisser un commentaire