Différences entre RBAC, ABAC et PBAC

RBAC, ABAC et PBAC sont trois méthodes distinctes de contrôle d’accès qui, dans le domaine de la gestion des identités et des accès (GIA), peuvent être perçues comme des évolutions successives. Ces approches servent à automatiser la détermination des droits d’accès des employés, chacune ayant sa propre logique. L’automatisation du contrôle d’accès est essentielle, car il serait peu pratique et chronophage de gérer manuellement les droits d’accès individuels au sein d’une organisation. Une approche structurée est donc nécessaire, et c’est exactement ce que proposent les solutions de RBAC, ABAC et PBAC.

Dans cet article, nous expliquons comment ces méthodes fonctionnent, leurs différences, ainsi que les avantages spécifiques à chacune. Nous fournirons également des exemples concrets de leur utilisation, notamment dans un environnement de GIA moderne comme HelloID. Mais commençons par un bref historique de ces méthodes.

Origine du RBAC, ABAC et PBAC

Pour comprendre les différences entre ces approches, il est utile d’examiner leur origine et leur évolution.

Les débuts : IBAC

La méthode la plus élémentaire pour gérer les accès est l’IBAC (Identity-Based Access Control – Gestion des accès basée sur l’identité). Avec l’IBAC, une liste de droits d’accès est associée à chaque utilisateur individuel. Ce besoin est apparu à l’époque des ordinateurs centraux (mainframes), où plusieurs utilisateurs avaient accès à un même système informatique centralisé. Les administrateurs cherchaient à éviter que les utilisateurs n’interfèrent entre eux sur ce système. Cette approche simple fonctionnait bien lorsque le nombre d’utilisateurs était limité et que les ressources partagées étaient peu nombreuses.

La transition vers le RBAC

Avec l’augmentation du nombre d’utilisateurs et de ressources dans les réseaux, la gestion individuelle des droits d’accès est devenue ingérable. C’est ainsi qu’a été introduit, vers 1992, le RBAC (Role-Based Access Control – Gestion des accès basée sur le rôle). Cette méthode attribue des droits d’accès en fonction des rôles des utilisateurs au sein de l’organisation. Elle simplifie considérablement la gestion, car tous les utilisateurs ayant un rôle donné obtiennent les mêmes droits. Ainsi, au lieu de gérer les droits individuellement pour chaque utilisateur, ils sont définis et gérés par rôle.

L’émergence de l’ABAC

Le RBAC est efficace dans les organisations où il existe une relation claire et directe entre les rôles et les droits. Cependant, certaines entreprises ont exprimé le besoin d’une plus grande flexibilité. C’est ainsi qu’a été développé, à la fin des années 1990, l’ABAC (Attribute-Based Access Control – Gestion des accès basée sur l’attribut). Avec ABAC, les droits d’accès sont attribués en fonction de divers attributs (ou caractéristiques). Ces attributs peuvent inclure le rôle, mais aussi des éléments comme le service, la localisation ou les compétences spécifiques d’un utilisateur. Sous cet angle, le RBAC peut être considéré comme un sous-ensemble d’ABAC, ce dernier étant plus large, flexible et puissant.

L’évolution vers le PBAC

L’ABAC offre une plus grande flexibilité, mais il devient rapidement complexe de structurer et de gérer toutes les dépendances entre les différents attributs et les droits d’accès des utilisateurs. Cela a conduit au développement du PBAC (Policy-Based Access Control – Contrôle des accès basée sur les politiques). Le PBAC met l’accent sur la simplicité d’utilisation en permettant de définir les politiques d’accès dans un langage compréhensible, plutôt que dans des structures ou des codes complexes. Cela permet aux organisations de créer et de modifier plus facilement et rapidement des règles d’accès. Les droits sont toujours attribués en fonction d’attributs, mais sont gérés via des règles de politique simples. De plus, le PBAC facilite l’ajout de règles de processus et de workflows.[1]

Attributs utilisés pour le contrôle d’accès

Les attributs représentent des caractéristiques liées aux utilisateurs et à leurs sessions. Généralement, on distingue trois types d’attributs :

• Attributs utilisateur : Ces attributs concernent directement l’utilisateur. Exemples : le nom, le service, la localisation habituelle de travail, ou encore des compétences spécifiques.
• Attributs d’objet : Ces attributs décrivent les propriétés ou les caractéristiques des ressources auxquelles un utilisateur souhaite accéder, comme des applications, des services web ou des données. Par exemple, le niveau de sensibilité (public/confidentiel/secret) d’un document.
• Attributs contextuels : Ces attributs se rapportent au contexte opérationnel, technique ou se situation dans lequel l’accès est demandé. Exemples : la date et l’heure de la tentative d’accès, la localisation géographique, le réseau utilisé, l’état du système ou l’appareil employé.[2]

Exemples pratiques : RBAC vs ABAC vs PBAC

Voici des exemples concrets pour illustrer l’application du RBAC, de l’ABAC et du PBAC dans la gestion des droits d’accès.

Exemple RBAC (Role-Based Access Control)

Le RBAC accorde des droits d’accès en fonction des rôles des utilisateurs au sein de l’organisation. Les utilisateurs sont affectés à des rôles spécifiques, chacun ayant des droits et des autorisations prédéfinis :

• Définition et structure : Les rôles comme « Responsable financier », « Employé RH », « Administrateur IT » ou « Infirmier » sont définis. Les utilisateurs, tels que Jean, Sarah, Marc et Lisa, sont affectés à ces rôles, et obtiennent les droits associés.
• Exemple concret :

Jean, Responsable financier, peut modifier les rapports financiers et consulter les dossiers du personnel.

Sarah, Employée RH, peut consulter les dossiers du personnel mais pas les modifier.

Marc, Administrateur IT, a accès aux systèmes informatiques mais pas aux rapports financiers ni aux dossiers du personnel.

Lisa, Infirmière, peut consulter les dossiers des patients et mettre à jour leurs données vitales.

• Avantages : Ce modèle est facile à comprendre et à mettre en œuvre, particulièrement dans des organisations avec une structure stable. Il offre une clarté sur les droits d’accès.
• Inconvénients : Le RBAC manque de flexibilité face à des besoins d’accès complexes ou changeants. En cas de modifications, il est nécessaire d’ajuster les rôles ou d’en créer de nouveaux, ce qui peut entraîner une prolifération des rôles et compliquer la gestion.[3]

Exemple ABAC (Attribute-Based Access Control)

L’ABAC accorde l’accès en fonction de divers attributs ou caractéristiques des utilisateurs, des ressources, des actions et de l’environnement. Ces attributs sont évalués pour déterminer si l’accès doit être accordé :

• Définition et structure : Les attributs peuvent se rapporter à la fonction, au service et au lieu de travail de l’utilisateur (attributs utilisateur), au type de fichier et à la sensibilité des informations (attributs des ressources), ainsi qu’à l’heure et au lieu de l’accès (attributs contextuels). Des règles métier sont ensuite établies pour combiner ces attributs et déterminer les décisions d’accès.
• Exemple concret :

Jean peut modifier des rapports financiers confidentiels uniquement s’il travaille au département Finance, occupe le poste de Manager et accède pendant les heures de bureau.

Les employés RH comme Sarah peuvent consulter, mais pas modifier, les dossiers du personnel, indépendamment de l’heure.

Lisa, infirmière, peut accéder au dossier d’un patient uniquement si elle est sa soignante attitrée, pendant ses heures de service, et depuis le réseau de l’hôpital.

• Avantages : L’ABAC offre une flexibilité et un contrôle précis. Les accès peuvent être ajustés dynamiquement en fonction des attributs en temps réel, ce qui le rend adapté aux organisations avec des besoins complexes et changeants.
• Inconvénients : Le système est plus complexe à mettre en œuvre et à gérer. Il nécessite une gestion approfondie des attributs et l’élaboration minutieuse de règles, souvent avec un langage comme XACML, demandant davantage de temps et d’expertise technique.

Exemple PBAC (Policy-Based Access Control)

Le PBAC accorde l’accès en fonction de règles de politique centralisées qui combinent des attributs et des logiques. Ces politiques sont rédigées dans un langage clair et naturel, rendant leur gestion plus simple et accessible :

• Définition et structure : Les politiques spécifient clairement qui peut accéder à quoi, dans quelles circonstances. Elles combinent des attributs avec des conditions spécifiques et sont gérées de manière centralisée.
• Exemple concret :

Politique 1 : Les managers financiers peuvent modifier des rapports financiers confidentiels pendant les heures de bureau.

Politique 2 : Les employés RH peuvent consulter, mais pas modifier, les dossiers du personnel.

Politique 3 : Les soignants attitrés peuvent consulter et mettre à jour les dossiers médicaux des patients assignés pendant leurs heures de service.

Politique 4 : Tout accès aux dossiers médicaux doit être effectué via le réseau de l’hôpital.

Ces politiques sont écrites en langage naturel et gérées de manière centralisée, ce qui les rend faciles à comprendre et à adapter.

• Avantages : Le PBAC combine la flexibilité de l’ABAC avec une gestion simplifiée. Grâce à des politiques en langage naturel, elles peuvent être créées et modifiées rapidement, même par des non-techniciens. La gestion centralisée garantit une meilleure cohérence et une réponse rapide aux changements.
• Inconvénients : Cela nécessite un système de gestion des politiques bien structuré et bien entretenu. Si les politiques deviennent trop nombreuses ou mal gérées, le système peut devenir complexe et difficile à surveiller.

RBAC vs ABAC

Quelle est la différence entre RBAC et ABAC ?

La principale différence entre RBAC et ABAC réside dans la manière dont chaque méthode attribue les droits d’accès. Avec le RBAC, l’accès est accordé en attribuant directement un rôle à un utilisateur. Avec l’ABAC, l’accès est déterminé de manière dynamique en fonction des caractéristiques de l’utilisateur, des objets et du contexte.

ABAC vs PBAC

Quelle est la différence entre ABAC et PBAC ?

La différence entre ABAC et PBAC réside dans la façon dont les modèles d’autorisation sont configurés. Avec l’ABAC, les attributs de rôle sont configurés via des langages de balisage spécialisés tels que XACML. En revanche, le PBAC permet de définir des règles d’accès sous forme de politiques simples et compréhensibles, exprimées dans un langage naturel. Le PBAC n’est donc pas nécessairement plus puissant que l’ABAC, mais il est beaucoup plus facile à utiliser.

Résumé

En résumé, voici les principales différences :

Le RBAC est adapté aux environnements simples et stables, mais manque de flexibilité.

L’ABAC offre une grande flexibilité et un contrôle granulaire, mais il est plus complexe à gérer.

Le PBAC combine la flexibilité d’ABAC avec une gestion simplifiée grâce à des politiques centralisées, rédigées dans un langage compréhensible.

Il est important de noter que les différences entre l’ABAC et le PBAC ne résident pas dans l’utilisation des attributs. Le PBAC utilise également un ou plusieurs attributs, mais avec une approche plus conviviale pour gérer les droits d’accès. Cela est illustré ci-dessous avec le fonctionnement de la plateforme HelloID.

RBAC, ABAC et PBAC dans votre plateforme de GIA

De nombreuses plateformes de GIA prennent en charge le RBAC, mais comme mentionné, cela comporte des limitations. C’est pourquoi HelloID intègre un mécanisme avancé combinant RBAC, ABAC et PBAC. Cette combinaison permet d’exploiter toutes les informations disponibles sur les utilisateurs, leur contexte et leurs demandes. Pour rendre cela accessible et efficace, HelloID différencie les attributs des utilisateurs de ceux liés au contexte et aux ressources :

• Les attributs utilisateur ont des valeurs relativement statiques. Par exemple, la fonction ou le service d’un utilisateur ne changent pas quotidiennement. Ces attributs sont donc idéaux pour le module de provisioning HelloID, qui détermine automatiquement quels comptes et droits d’accès sont nécessaires pour chaque employé. Le système actualise ces droits une à deux fois par jour et applique les modifications dans les systèmes cibles, tels qu’Active Directory, La messagerie, GLPI, et les applications métier.
• Les attributs contextuels et attributs des ressources concernent les sessions utilisateur individuelles, et leurs valeurs varient d’une session à l’autre. Ces attributs ne sont pas utilisés pour le provisioning des comptes utilisateurs et de leurs droits. En revanche, ils permettent de peaufiner les droits d’accès en fonction de critères spécifiques. Par exemple, une condition peut être ajoutée à un droit d’accès pour limiter son utilisation aux horaires de bureau. Cela permet de rendre l’accès dépendant du contexte et des ressources.

En résumé, l’attribution automatique des comptes utilisateurs et de leurs droits dans les systèmes cibles repose sur les attributs utilisateur. Le raffinement des droits d’accès spécifiques s’appuie, quant à lui, sur les attributs contextuels et des ressources. Ainsi, HelloID prend en charge l’intégralité des approches ABAC et PBAC. Nous expliquons cela plus en détail ci-dessous.

Provisioning basé sur des attributs utilisateur

Dans le cadre du provisioning, la grande différence entre RBAC et ABAC réside dans les attributs utilisateur disponibles. Le RBAC pur fonctionne uniquement avec des rôles, tandis que l’ABAC permet d’utiliser de nombreux autres attributs, tels que le service, la fonction, le lieu de travail ou les compétences, qui peuvent être combinés. Cela offre une approche bien plus intelligente et efficace pour organiser la gestion des droits. Par exemple, vous pouvez construire une « pyramide des droits » :

• Droits universels : Certains droits sont nécessaires à tous les employés. Dans de nombreuses organisations, par exemple, tout le monde dispose d’un compte e-mail et d’une licence Microsoft 365. Avec l’ABAC, ces droits peuvent être attribués automatiquement à l’ensemble des utilisateurs, sans avoir besoin de les associer à chaque rôle individuel comme avec le RBAC.
• Droits spécifiques à une équipe ou un service : d’autres droits peuvent être accordés en fonction du service ou de l’équipe. Par exemple, un espace partagé SharePoint peut être attribué en fonction du service auquel appartient un utilisateur, sans tenir compte des rôles individuels.
• Droits spécifiques aux rôles : enfin, il reste un nombre limité de droits spécifiques qui doivent être directement liés aux rôles individuels, comme un soignant nécessitant un accès particulier dans un système de gestion des soins. Ces droits sont donc attribués en fonction des rôles spécifiques.

Cette approche illustre la puissance de l’ABAC. En utilisant des attributs tels que les rôles, les service, les équipes, les lieux, les fonctions ou les compétences, il devient possible de sélectionner facilement différents groupes d’utilisateurs dans l’organisation et de leur attribuer les mêmes droits en une seule fois. Avec le RBAC, cela serait complexe, voire impraticable.

Passer de l’ABAC au PBAC avec des règles métier

Comment configurer et gérer facilement un modèle basé sur des attributs ? Plutôt que d’utiliser des outils de scripting ou d’autres méthodes complexes pour gérer les configurations ABAC, HelloID s’appuie sur des règles métier (business rules).

Une règle métier permet de définir simplement quelles permissions ou droits doivent être attribués en fonction de conditions spécifiques liées aux utilisateurs. Dans un établissement de soins, par exemple, une règle métier pourrait être formulée ainsi :

Si un employé occupe le poste « Aide-soignant Niveau 4 » et travaille dans le département Soins A (condition), il reçoit automatiquement un compte Entra ID et un accès au dossier électronique des patients avec des permissions pour les clients de Soins A (droits associés).

Ces permissions peuvent également être affinées grâce à des attributs contextuels et des attributs de ressource. Par exemple, dans un système de gestion des soins, vous pouvez configurer quels groupes de patients sont accessibles, si l’utilisateur peut uniquement consulter ou aussi modifier les données, et depuis quel réseau l’accès est autorisé. HelloID dispose d’un catalogue étendu de connecteurs pour connecter différents systèmes cibles et attribuer automatiquement les bons droits.

Avec ces règles métier, un modèle PBAC (Policy-Based Access Control) est mis en place, offrant des avantages significatifs. Les politiques sont faciles à comprendre et le gestionnaire n’a pas besoin de s’attarder sur les structures complexes entre attributs et droits. Il suffit d’ajouter des règles qui s’appliquent à tous les utilisateurs, à des départements spécifiques, à des rôles ou à d’autres attributs utilisateur. Il est également possible d’ajouter facilement des conditions aux permissions.

Le système gère les éventuels chevauchements entre les règles métier, en traduisant toutes les politiques en une structure cohérente et homogène de gestion des droits. De plus, ces règles permettent d’ajouter des workflows et des politiques supplémentaires. Par exemple, une règle peut prévoir que les comptes des nouveaux employés soient activés une semaine avant leur arrivée, ou que certains droits applicatifs ne soient actifs qu’après l’acceptation des conditions d’utilisation par l’utilisateur.

En savoir plus sur le RBAC, l’ABAC et le PBAC

Vous souhaitez savoir comment appliquer ces concepts à la gestion des identités et des accès dans votre organisation ? Lors de notre webinaire, nous expliquons en détail comment construire une structure de droits à partir des rôles et autres attributs. Nous montrons également comment utiliser le role mining pour analyser et optimiser votre structure actuelle de droits.

Sources:

[1] https://www.jstor.org/stable/10.2307/26486786

[2] https://dl.acm.org/doi/abs/10.1145/3007204

[3] https://link.springer.com/chapter/10.1007/978-3-030-04834-1_2