RBAC et ABAC : Les modèles de contrôle d'accès que vous devez connaître

Introduction#

Le contrôle d'accès est un aspect critique de la sécurité dans tout système. Il garantit que seuls les utilisateurs autorisés peuvent accéder aux ressources et effectuer des actions. Le contrôle d'accès basé sur les rôles (RBAC) et le contrôle d'accès basé sur les attributs (ABAC) sont deux des modèles de contrôle d'accès les plus populaires utilisés dans les systèmes modernes. Les deux modèles sont largement adoptés et peuvent être utilisés pour appliquer efficacement les politiques de contrôle d'accès. Mais que sont-ils et comment diffèrent-ils ?

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

Le contrôle d'accès basé sur les rôles (RBAC) a été introduit pour la première fois au début des années 1990. La formalisation du modèle est attribuée à David Ferraiolo et Rick Kuhn dans un article publié en 1992. Depuis lors, le RBAC est devenu l'un des modèles de contrôle d'accès les plus utilisés dans l'industrie.

Dans le RBAC, les politiques de contrôle d'accès sont basées sur des rôles, qui sont des collections d'autorisations. Les utilisateurs se voient attribuer des rôles (par exemple, administrateur, éditeur, spectateur), et leurs droits d'accès sont déterminés par les permissions (par exemple, créer, éditer, supprimer) pour des ressources spécifiques (par exemple, fichiers, bases de données, applications). Cela simplifie la gestion des politiques de contrôle d'accès en regroupant les utilisateurs selon leurs rôles et en attribuant des permissions aux rôles. Il est facile d'ajouter ou de supprimer des utilisateurs à des rôles, et les modifications seront automatiquement reflétées dans les politiques de contrôle d'accès.

Composants clés du RBAC#

• Ressource : Une ressource est une entité à laquelle un utilisateur peut accéder. Les ressources peuvent être n'importe quoi, des fichiers, des bases de données, des API, ou toute autre entité système qui doit être protégée.
• Permission : Une permission est une action spécifique qu'un utilisateur peut effectuer sur une ressource. Par exemple, créer, éditer, supprimer, visualiser. La définition des permissions peut varier selon le système. Dans la plupart des cas, les permissions sont définies au niveau de la ressource avec une granularité minimale.
• Rôle : Un rôle est une collection de permissions qui définit un ensemble d'actions qu'un utilisateur peut effectuer. Par exemple, un rôle d'administrateur peut avoir la permission de créer, éditer et supprimer des ressources, tandis qu'un rôle de spectateur peut avoir la permission de visualiser des ressources.
• Utilisateur : Un utilisateur est une entité à laquelle on peut attribuer un ou plusieurs rôles. Les utilisateurs se voient accorder l'accès à des ressources en fonction des permissions associées aux rôles qui leur sont attribués.

Variantes du RBAC#

Il existe plusieurs variantes du RBAC qui étendent le modèle de base pour répondre à des exigences de contrôle d'accès plus complexes :

• RBAC0 : Le modèle de base où les utilisateurs se voient attribuer des rôles et les rôles se voient attribuer des permissions.
• RBAC1 : Ajoute le concept de hiérarchies de rôles. Les rôles peuvent hériter des permissions d'autres rôles. On parle également de RBAC hiérarchique.
• RBAC2 : Ajoute des contraintes aux rôles. Les contraintes peuvent être utilisées pour définir des conditions supplémentaires qui doivent être remplies pour qu'un utilisateur se voit attribuer un rôle. On parle également de RBAC basé sur les contraintes.
• RBAC3 : Combine les fonctionnalités du RBAC1 et du RBAC2. Il prend en charge à la fois les hiérarchies de rôles et les contraintes.

Pour plus d'informations sur ces variantes, reportez-vous à modèles RBAC et leur évolution.

Avantages du RBAC#

• Simplicité : Le RBAC est facile à comprendre et à mettre en œuvre. Attribuer des permissions aux rôles et des rôles aux utilisateurs est simple.
• Efficacité : Il simplifie la gestion des politiques de contrôle d'accès en regroupant les utilisateurs selon leurs rôles. Il est facile d'ajouter ou de supprimer des utilisateurs aux rôles sans changer les politiques de contrôle d'accès. Surtout dans les grandes organisations avec des structures de permissions bien définies, le RBAC peut être très efficace.
• Transparence : Le RBAC fournit une cartographie claire entre les rôles, les permissions et les utilisateurs. Il est facile d'auditer et de réviser les politiques de contrôle d'accès.

Inconvénients du RBAC#

• Rigidité : Le RBAC peut être rigide lorsqu'il s'agit de définir des politiques de contrôle d'accès complexes. Il peut ne pas convenir aux systèmes où les politiques de contrôle d'accès doivent être plus dynamiques et contextuelles.
• Granularité : Le RBAC peut manquer de la granularité nécessaire pour un contrôle d'accès fin. Les politiques de contrôle d'accès sont liées à des rôles bien définis et il peut être nécessaire de fournir des efforts supplémentaires pour définir des permissions à un niveau plus granulaire.
• Explosion des rôles : Dans les grandes organisations avec des structures de permissions complexes, le nombre de rôles peut croître de façon exponentielle, entraînant une explosion des rôles. Gérer un grand nombre de rôles peut être difficile.

Contrôle d'accès basé sur les attributs (ABAC)#

À la fin des années 2000, à mesure que les systèmes devenaient plus complexes et dynamiques, de plus en plus d'organisations ont commencé à adopter le contrôle d'accès basé sur les attributs (ABAC) comme alternative au RBAC. Un jalon notable dans la formalisation de l'ABAC est la publication de la Publication Spéciale NIST 800-162 en 2014.

L'ABAC est un modèle de contrôle d'accès plus flexible comparé au RBAC. C'est un modèle d'autorisation qui définit les politiques de contrôle d'accès basées sur les attributs de l'utilisateur, de la ressource, de l'action et de l'environnement. Il permet aux organisations de définir des politiques de contrôle d'accès fines qui peuvent s'adapter à différents contextes et conditions.

Composants clés de l'ABAC#

• Sujet : Un sujet est une entité qui demande l'accès à une ressource. Il peut s'agir d'un utilisateur, d'un appareil, d'une application, ou de toute autre entité qui doit accéder à des ressources.
• Ressource : Tout comme dans le RBAC, une ressource est une entité à laquelle un sujet peut accéder. Les ressources peuvent être des fichiers, des bases de données, des API, ou toute autre entité système.
• Action : Une action est une opération spécifique qu'un sujet peut effectuer sur une ressource. Il peut s'agir de créer, lire, mettre à jour, supprimer, ou tout autre opération qui doit être contrôlée.
• Environnement : L'environnement est le contexte dans lequel la demande d'accès est faite. Il peut inclure des attributs tels que l'heure de la journée, le lieu, le réseau, l'appareil, etc.
• Attribut : Un attribut est une caractéristique d'un sujet, d'une ressource, d'une action ou d'un environnement. Les attributs peuvent être n'importe quoi, des rôles d'utilisateur, du département, du lieu, de l'adresse IP, du type d'appareil, etc.
• Politique : Une politique est une règle qui définit les conditions dans lesquelles l'accès est accordé ou refusé. Les politiques sont définies en fonction des attributs.

Avantages de l'ABAC#

• Flexibilité : L'ABAC peut accueillir des politiques de contrôle d'accès complexes qui sont basées sur de multiples attributs. Il permet aux organisations de définir des politiques fines qui peuvent s'adapter à différents contextes et conditions.
• Dynamique : Les politiques ABAC peuvent être dynamiques et contextuelles. Les décisions de contrôle d'accès peuvent être prises en fonction d'attributs en temps réel tels que le lieu, l'heure de la journée, le type d'appareil, etc.
• Granularité : L'ABAC fournit un contrôle d'accès fin en permettant aux organisations de définir des politiques basées sur de multiples attributs. Contrairement à la définition de rôles et de permissions, les politiques basées sur les attributs peuvent être plus granulaires.

Inconvénients de l'ABAC#

• Complexité : L'ABAC peut être plus complexe à mettre en œuvre et à gérer par rapport au RBAC. La définition des attributs et des politiques peut nécessiter plus d'efforts et d'expertise. Contrairement au RBAC, où les rôles et les permissions sont bien structurés, les attributs peuvent être plus dynamiques, et donc les politiques aussi. Gérer un grand nombre d'attributs et de politiques dans un système complexe peut être difficile. Un moteur centralisé d'évaluation des politiques est souvent nécessaire pour évaluer les politiques.
• Performance : L'évaluation des attributs peut impacter la performance, surtout dans des environnements en temps réel. Les politiques basées sur de multiples attributs et des conditions en temps réel peuvent introduire des latences dans les décisions de contrôle d'accès.

Tableau de comparaison#

D'après le tableau de comparaison, il est clair que le RBAC convient mieux aux systèmes avec des structures de permissions bien définies et où les politiques de contrôle d'accès sont relativement statiques. D'autre part, l'ABAC est mieux adapté aux systèmes où les politiques de contrôle d'accès doivent être dynamiques, contextuelles et fines.

Exemples#

Scénario : Un système hospitalier doit gérer l'accès aux dossiers des patients pour différents membres du personnel.

• Personnel : Médecins, Infirmières, Administrateurs
• Ressources : Dossiers des patients
• Permissions : Lire, Écrire, Supprimer

Cas 1#

Les politiques de contrôle d'accès sont relativement simples :

1. Les médecins peuvent lire et écrire les dossiers des patients.
2. Les infirmières peuvent lire les dossiers des patients.
3. Les administrateurs peuvent lire, écrire et supprimer les dossiers des patients.

Modèle RBAC#

Dans ce cas, le RBAC est simple et efficace. Nous pouvons définir des rôles pour les médecins, les infirmières et les administrateurs, et attribuer les permissions appropriées à chaque rôle.

L'évaluation du contrôle d'accès est simple :

• GET /patient-records : user.permission.includes('read')
• POST /patient-records : user.permission.includes('write')
• DELETE /patient-records : user.permission.includes('delete')

Modèle ABAC#

Dans ce cas, l'ABAC peut être excessif, mais il peut encore être utilisé pour définir des politiques fines basées sur des attributs tels que le département, le rôle, etc.

Attributs :

• user.role : doctor, nurse, admin
• resource.name : patient-record
• action : read, write, delete

Politiques :

• Politique 1 : Autoriser l'accès en lecture sur la base de user.role et resource.name
  • sujet : Utilisateur avec le rôle doctor, nurse, admin
  • ressource : Ressource avec le nom patient-record
  • action : read
  • effet : autoriser
  • raisonnement : "Autoriser l'accès en lecture aux dossiers des patients pour tous les rôles"
• Politique 2 : Accès en modification pour les médecins et les administrateurs
  • sujet : Utilisateur avec le rôle doctor, admin
  • ressource : Ressource avec le nom patient-record
  • action : write
  • effet : autoriser
  • raisonnement : "Autoriser l'accès en modification aux dossiers des patients pour les médecins et les administrateurs"
• Politique 3 : Accès en suppression pour les administrateurs
  • sujet : Utilisateur avec le rôle admin
  • ressource : Ressource avec le nom patient-record
  • action : delete
  • effet : autoriser
  • raisonnement : "Autoriser l'accès en suppression aux dossiers des patients pour les administrateurs"

Pour chaque demande de lecture/écriture/suppression, le moteur de politique évalue toutes les politiques pertinentes en fonction des attributs et prend une décision de contrôle d'accès.

Comparaison#

Dans ce cas, les politiques de contrôle d'accès sont simples et bien structurées. Il ne nécessite qu'une vérification de permission de niveau unique pour déterminer si un utilisateur a accès à une ressource. Imaginez que le système hospitalier ait une structure plus complexe avec plusieurs départements, rôles et permissions :

• Dans un modèle RBAC, le processus d'évaluation du contrôle d'accès à la ressource des dossiers des patients restera simple et direct, que l'utilisateur ait la permission de read, write ou delete ;
• L'ABAC, en revanche, devra impliquer des attributs supplémentaires comme department-id et doctor-id. Que se passe-t-il si un appareil IoT doit accéder aux dossiers des patients ? Cela nécessitera l'introduction d'un nouvel attribut device-id dans l'évaluation des politiques. Comment accorder temporairement la permission de read à un médecin stagiaire ?

En conclusion, le RBAC est un meilleur choix. Le RBAC est simple et efficace pour les systèmes avec des structures de permissions bien définies et où les politiques de contrôle d'accès sont statiques.

Cas 2#

Le même système hospitalier, ajoutons maintenant un nouveau rôle patient et un nouvel attribut patient-id.

Les politiques de contrôle d'accès sont :

1. Les médecins peuvent lire et écrire les dossiers des patients.
2. Les infirmières peuvent lire les dossiers des patients.
3. Les administrateurs peuvent lire, écrire et supprimer les dossiers des patients.
4. Les patients peuvent lire leurs propres dossiers.

Modèle RBAC#

Dans ce cas, en dehors de l'ancienne permission read, nous devons introduire une nouvelle permission read-own. Nous pouvons définir des rôles pour les médecins, les infirmières, les administrateurs, et les patients, et attribuer les permissions appropriées à chaque rôle.

Maintenant, l'évaluation du contrôle d'accès est un peu plus complexe, surtout pour l'action de lecture des dossiers des patients :

• GET /patient-records : user.permission.includes('read')
• POST /patient-records : user.permission.includes('write')
• DELETE /patient-records : user.permission.includes('delete')
• GET /patient-records/:patient-id : user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

Modèle ABAC#

Mettons à jour les attributs et les politiques dans le modèle ABAC pour répondre aux nouvelles exigences.

Attributs :

• user.role : doctor, nurse, admin, patient
• user.id : patient-id
• resource.name : patient-record
• resource.patient-id : patient-id
• action : read, write, delete

Politiques :

• Politique 1 : Permettre l'accès en lecture à tous les dossiers des patients
  • sujet : Utilisateur avec le rôle doctor, nurse, admin
  • ressource : Ressource avec le nom patient-record
  • action : read
  • effet : autoriser
  • raisonnement : "Permettre l'accès en lecture aux dossiers des patients pour tout le personnel et le patient lui-même"
• Politique 2 : Permettre l'accès en écriture à tous les dossiers des patients pour les médecins et les administrateurs
  • sujet : Utilisateur avec le rôle doctor, admin
  • ressource : Ressource avec le nom patient-record
  • action : write
  • effet : autoriser
  • raisonnement : "Permettre l'accès en écriture aux dossiers des patients pour les médecins et les administrateurs"
• Politique 3 : Permettre l'accès en suppression à tous les dossiers des patients pour les administrateurs
  • sujet : Utilisateur avec le rôle admin
  • ressource : Ressource avec le nom patient-record
  • action : delete
  • effet : autoriser
  • raisonnement : "Permettre l'accès en suppression aux dossiers des patients pour les administrateurs"
• Politique 4 : Permettre l'accès en lecture à ses propres dossiers des patients
  • sujet : Utilisateur avec le rôle patient
  • ressource : Ressource avec le nom patient-record
  • action : read
  • condition : user.id === resource.patient-id
  • effet : autoriser
  • raisonnement : "Permettre l'accès en lecture à ses propres dossiers des patients"

Comparaison#

Dans ce cas, les politiques de contrôle d'accès sont plus complexes et contextuelles. Le processus d'évaluation du contrôle d'accès à la ressource des dossiers des patients nécessitera plusieurs niveaux de vérification des permissions pour déterminer si un utilisateur a accès à une ressource.

• Dans un modèle RBAC, le processus d'évaluation du contrôle d'accès à la ressource des dossiers des patients nécessitera plusieurs niveaux de vérification des permissions pour déterminer si un utilisateur a accès à une ressource. Par exemple, pour déterminer si un patient a accès à ses propres dossiers, le système doit vérifier si l'utilisateur a la permission de read-own et si l'ID de l'utilisateur correspond à l'ID du patient.
• Dans un modèle ABAC, le processus d'évaluation du contrôle d'accès peut être plus direct. Les politiques peuvent être définies sur la base des attributs de l'utilisateur, de la ressource et de l'action. Par exemple, pour déterminer si un patient a accès à ses propres dossiers, le moteur de politiques peut évaluer la politique sur la base de l'ID de l'utilisateur et de l'ID du patient.

Dans ce cas, l'ABAC peut être un meilleur choix. L'ABAC est plus adapté aux systèmes où les politiques de contrôle d'accès doivent être dynamiques, contextuelles et fines.

Conclusion#

Le choix entre le RBAC et l'ABAC dépend des exigences spécifiques du système. Le RBAC convient mieux aux systèmes avec des structures de permissions bien définies et où les politiques de contrôle d'accès sont statiques. L'ABAC est plus adapté aux systèmes où les politiques de contrôle d'accès doivent être dynamiques, contextuelles et fines. En pratique, les organisations peuvent choisir d'utiliser une combinaison des deux modèles pour atteindre le niveau de contrôle d'accès souhaité.