Contrôle d'accès basé sur les rôles

Dans le domaine de la sécurité des systèmes informatiques, le contrôle d'accès basé sur les rôles ( RBAC ) ou la sécurité basée sur les rôles est une approche visant à restreindre l'accès au système aux utilisateurs autorisés et à mettre en œuvre un contrôle d'accès obligatoire (MAC) ou un contrôle d'accès discrétionnaire (DAC) .

Le contrôle d'accès basé sur les rôles est un mécanisme de contrôle d'accès neutre en termes de politique défini autour des rôles et des privilèges. Les composants du RBAC tels que les rôles-autorisations, les relations utilisateur-rôle et rôle-rôle simplifient l'exécution des affectations d'utilisateurs. Une étude du NIST a démontré que le RBAC répond à de nombreux besoins des organisations commerciales et gouvernementales. Le RBAC peut être utilisé pour faciliter l'administration de la sécurité dans les grandes organisations comptant des centaines d'utilisateurs et des milliers d'autorisations. Bien que le RBAC soit différent des cadres de contrôle d'accès MAC et DAC, il peut appliquer ces politiques sans aucune complication.

Au sein d'une organisation, des rôles sont créés pour différentes fonctions. Les autorisations permettant d'effectuer certaines opérations sont attribuées à des rôles spécifiques. Étant donné que les autorisations ne sont pas attribuées directement aux utilisateurs, mais qu'elles ne peuvent être acquises que par le biais de leur rôle (ou de leurs rôles), la gestion des droits d'utilisateur individuels devient une simple question d'attribution de rôles appropriés au compte de l'utilisateur ; cela simplifie les opérations courantes, telles que l'ajout d'un utilisateur ou le changement de service d'un utilisateur.

Trois règles principales sont définies pour RBAC :

1. Attribution de rôle : un sujet peut exercer une autorisation uniquement s'il a sélectionné ou s'est vu attribuer un rôle.
2. Autorisation de rôle : le rôle actif d'un sujet doit être autorisé pour le sujet. Avec la règle 1 ci-dessus, cette règle garantit que les utilisateurs ne peuvent assumer que les rôles pour lesquels ils sont autorisés.
3. Autorisation d'autorisation : un sujet ne peut exercer une autorisation que si celle-ci est autorisée pour le rôle actif du sujet. Avec les règles 1 et 2, cette règle garantit que les utilisateurs ne peuvent exercer que les autorisations pour lesquelles ils sont autorisés.

Des contraintes supplémentaires peuvent également être appliquées et les rôles peuvent être combinés dans une hiérarchie où les rôles de niveau supérieur englobent les autorisations détenues par les sous-rôles.

Grâce aux concepts de hiérarchie des rôles et de contraintes, il est possible de contrôler le RBAC pour créer ou simuler un contrôle d'accès basé sur un réseau (LBAC). Le RBAC peut donc être considéré comme un sur-ensemble du LBAC.

Lors de la définition d'un modèle RBAC, les conventions suivantes sont utiles :

• S = Sujet = Une personne ou un agent automatisé
• R = Rôle = Fonction ou titre de poste qui définit un niveau d'autorité
• P = Permissions = Une approbation d'un mode d'accès à une ressource
• SE = Session = Une application impliquant S, R et/ou P
• SA = Affectation de sujet
• PA = Cession d'autorisation
• RH = Hiérarchie des rôles partiellement ordonnée. RH peut également s'écrire : ≥ (La notation : x ≥ y signifie que x hérite des permissions de y.)
  • Un sujet peut avoir plusieurs rôles.
  • Un rôle peut avoir plusieurs sujets.
  • Un rôle peut avoir plusieurs autorisations.
  • Une autorisation peut être attribuée à plusieurs rôles.
  • Une opération peut être attribuée à plusieurs autorisations.
  • Une autorisation peut être attribuée à plusieurs opérations.

Une contrainte impose une règle restrictive sur l'héritage potentiel des autorisations de rôles opposés. Elle peut ainsi être utilisée pour obtenir une séparation appropriée des tâches . Par exemple, la même personne ne doit pas être autorisée à la fois à créer un compte de connexion et à autoriser la création du compte.

Ainsi, en utilisant la notation de la théorie des ensembles :

Un sujet peut avoir plusieurs séances simultanées avec/dans des rôles différents.

La norme NIST/ANSI/ INCITS RBAC (2004) reconnaît trois niveaux de RBAC :

1. RBAC de base
2. RBAC hiérarchique, qui ajoute la prise en charge de l'héritage entre les rôles
3. RBAC contraint, qui ajoute une séparation des tâches

RBAC est une technologie de contrôle d'accès flexible dont la flexibilité lui permet d'implémenter DAC ou MAC . DAC avec des groupes (par exemple, comme implémenté dans les systèmes de fichiers POSIX) peut émuler RBAC. MAC peut simuler RBAC si le graphe de rôle est limité à un arbre plutôt qu'à un ensemble partiellement ordonné .

Avant le développement du RBAC, le modèle Bell-LaPadula (BLP) était synonyme de MAC et les autorisations du système de fichiers étaient synonymes de DAC. Ces modèles étaient considérés comme les seuls modèles connus de contrôle d'accès : si un modèle n'était pas BLP, il était considéré comme un modèle DAC, et vice versa. Des recherches menées à la fin des années 1990 ont démontré que le RBAC n'appartient à aucune de ces deux catégories. Contrairement au contrôle d'accès basé sur le contexte (CBAC), le RBAC ne tient pas compte du contexte du message (comme la source d'une connexion). Le RBAC a également été critiqué pour avoir conduit à une explosion des rôles, un problème dans les grands systèmes d'entreprise qui nécessitent un contrôle d'accès d'une granularité plus fine que ce que le RBAC peut fournir, car les rôles sont intrinsèquement attribués aux opérations et aux types de données. À la manière du CBAC, un système de contrôle d'accès basé sur les relations entre entités (ERBAC, bien que le même acronyme soit également utilisé pour les systèmes RBAC modifiés, tels que le contrôle d'accès basé sur les rôles étendus ) est capable de sécuriser des instances de données en considérant leur association au sujet d'exécution.

Les listes de contrôle d'accès (ACL) sont utilisées dans les systèmes traditionnels de contrôle d'accès discrétionnaire (DAC) pour affecter des objets de données de bas niveau. Le RBAC diffère du ACL dans l'attribution d'autorisations aux opérations qui modifient les relations directes entre plusieurs entités (voir : ACLg ci-dessous). Par exemple, un ACL peut être utilisé pour accorder ou refuser l'accès en écriture à un fichier système particulier, mais il ne dicte pas comment ce fichier peut être modifié. Dans un système basé sur le RBAC, une opération peut consister à « créer une transaction de compte de crédit » dans une application financière ou à « remplir un enregistrement de test de glycémie » dans une application médicale. Un rôle est donc une séquence d'opérations au sein d'une activité plus vaste. Le RBAC s'est avéré particulièrement bien adapté aux exigences de séparation des tâches (SoD), qui garantissent que deux personnes ou plus doivent être impliquées dans l'autorisation d'opérations critiques. Les conditions nécessaires et suffisantes pour la sécurité du SoD dans le RBAC ont été analysées. Un principe sous-jacent du SoD est qu'aucun individu ne devrait être en mesure de provoquer une violation de la sécurité par le biais d'un double privilège. Par extension, aucune personne ne peut occuper un poste qui exerce une autorité d’audit, de contrôle ou d’examen sur un autre poste occupé simultanément.

De plus, un « modèle RBAC minimal », RBACm , peut être comparé à un mécanisme ACL, ACLg , où seuls les groupes sont autorisés comme entrées dans l'ACL. Barkley (1997) a montré que RBACm et ACLg sont équivalents.

Dans les implémentations SQL modernes , comme ACL du framework CakePHP , les ACL gèrent également les groupes et l'héritage dans une hiérarchie de groupes. Sous cet aspect, les implémentations spécifiques « ACL modernes » peuvent être comparées à des implémentations spécifiques « RBAC modernes », meilleures que les « anciennes implémentations (système de fichiers) ».

Pour l'échange de données et pour les « comparaisons de haut niveau », les données ACL peuvent être traduites en XACML .

Le contrôle d'accès basé sur les attributs ou ABAC est un modèle qui évolue à partir du RBAC pour prendre en compte des attributs supplémentaires en plus des rôles et des groupes. Dans ABAC, il est possible d'utiliser des attributs de :

• l'utilisateur, par exemple la citoyenneté, l'habilitation,
• la ressource, par exemple la classification, le service, le propriétaire,
• l'action, et
• le contexte, par exemple l'heure, le lieu, l'IP.

ABAC est basé sur des politiques dans le sens où il utilise des politiques plutôt que des autorisations statiques pour définir ce qui est autorisé ou ce qui n'est pas autorisé.

Le contrôle d'accès basé sur les relations ou ReBAC est un modèle qui évolue à partir du RBAC. Dans ReBAC, l'autorisation d'un sujet à accéder à une ressource est définie par la présence de relations entre ces sujets et les ressources.

L’avantage de ce modèle est qu’il permet des autorisations très précises ; par exemple, dans un réseau social où les utilisateurs peuvent partager des publications avec d’autres utilisateurs spécifiques.

L'utilisation de RBAC pour gérer les privilèges des utilisateurs (autorisations d'ordinateur) au sein d'un système ou d'une application unique est largement reconnue comme une bonne pratique. Un rapport de 2010 préparé pour le NIST par le Research Triangle Institute a analysé la valeur économique de RBAC pour les entreprises et a estimé les avantages par employé en termes de temps d'arrêt réduits, de provisionnement plus efficace et d'administration plus efficace des politiques de contrôle d'accès.

Dans une organisation dotée d'une infrastructure informatique hétérogène et d'exigences qui s'étendent sur des dizaines ou des centaines de systèmes et d'applications, l'utilisation de RBAC pour gérer un nombre suffisant de rôles et attribuer des appartenances de rôle adéquates devient extrêmement complexe sans création hiérarchique de rôles et d'attributions de privilèges. Les systèmes plus récents étendent l'ancien modèle RBAC du NIST pour répondre aux limitations du RBAC pour les déploiements à l'échelle de l'entreprise. Le modèle du NIST a été adopté comme norme par l'INCITS sous la référence ANSI/INCITS 359-2004. Une discussion sur certains des choix de conception du modèle du NIST a également été publiée.

L'interférence du contrôle d'accès basé sur les rôles est un problème relativement nouveau dans les applications de sécurité, où plusieurs comptes d'utilisateurs avec des niveaux d'accès dynamiques peuvent conduire à une instabilité de la clé de chiffrement, permettant à un utilisateur extérieur d'exploiter la faiblesse pour un accès non autorisé. Les applications de partage de clés dans des environnements virtualisés dynamiques ont montré un certain succès dans la résolution de ce problème.