Cet article présente les concepts de base sur l’autorisation dans la gestion des identités et des accès (GIA). Son objectif est d’introduire les modèles de contrôle d’accès couramment utilisés aujourd’hui, avec une exploration plus approfondie du modèle de contrôle d’accès basé sur les attributs (attribute based access control – ABAC). Ce modèle qui gagne de plus en plus de popularité dans l’industrie est souvent mal compris.

Avant de commencer, voici quelques concepts clés référencés tout au long de l’article.

Sujet

L’entité qui accède à un objet. Le sujet peut être, par exemple, un utilisateur ou un processus automatique.

Object

La ressource qui est accédée. Cela peut inclure un fichier dans un système d’exploitation, un champ dans un dossier personnel, une API, etc.

Modèles de contrôle d’accès

Cette section couvre les principaux modèles de contrôle d’accès que l’on peut rencontrer dans les solutions d’autorisation.

Liste de contrôle d’accès (access control list – ACL)

Ce modèle de contrôle d’accès fut l’un des premiers qui fut conçu. La première implémentation de ce modèle remonte à 1965 avec le système d’exploitation Multics.

Dans ce modèle, le propriétaire d’une ressource maintient une liste des sujets (des utilisateurs, des comptes, etc.) qui peuvent accéder à ses ressources et les actions qu’ils sont autorisés à effectuer.

Ce modèle est utilisé dans divers contextes. Par exemple, dans un système d’exploitation, un fichier est associé à une liste de sujets. Ces sujets qui peuvent lire le fichier, le modifier ou le supprimer. Dans un annuaire LDAP, une ACL définit comment un sujet peut interagir avec les objets de l’annuaire.

Contrôle d’accès basé sur les rôles (role-based access control – RBAC)

Ce modèle, développé par des chercheurs du NIST en 1992, introduit une distinction clé par rapport au modèle ACL en rompant la relation directe entre sujets et objets.

Dans le modèle RBAC, les permissions ne sont pas directement attribuées aux sujets. Les sujets sont plutôt assignés à des rôles. Ces rôles se voient ensuite accorder des permissions sur des objets spécifiques.

Ces rôles peuvent représenter plusieurs concepts, tels que la fonction du sujet ou son département dans une organisation. Un rôle peut être utilisé pour regrouper les sujets et les privilèges, simplifiant ainsi leur gestion. Cependant, en pratique, la plupart des organisations sont confrontées à une “explosion des rôles”. Cette situation survient lorsqu’une multitude de rôles distincts est créée pour tenir compte de chaque exception ou nuance dans les privilèges. Ceci complique considérablement la gestion des rôles.

Contrôle d’accès basé sur les attributs (attribute based access control – ABAC)

ABAC peut être considéré comme une généralisation plus flexible du modèle RBAC. Dans le modèle RBAC, les privilèges d’un sujet sur un objet sont déterminés par les rôles qui lui sont assignés. En revanche, avec le modèle ABAC, les privilèges peuvent dépendre de n’importe quel attribut du sujet, et pas seulement de son rôle. Parmi les exemples d’attributs, on peut inclure l’unité commerciale du sujet, son niveau de séniorité dans une organisation, son niveau d’habilitation de sécurité, etc.

Le modèle ABAC incorpore également la notion d’attributs d’objets et d’attributs contextuels. Les attributs d’objets définissent les ressources accessibles, tandis que les attributs contextuels définissent le contexte dans lequel une demande d’autorisation est effectuée. Ces trois niveaux d’attributs permettent d’établir des politiques complexes et flexibles. Par exemple, une politique pourrait être :

Un employé d’une banque travaillant à la succursale de Montréal peut accéder aux comptes d’un client VIP, uniquement lors des heures de bureau et uniquement si la demande est effectuée depuis l’Amérique du Nord.

Il est important de noter que nous considérons ABAC et le contrôle d’accès basé sur les politiques (policy-based access control – PBAC) comme synonymes. PBAC est parfois utilisé comme un terme alternatif pour les solutions qui implémentent en fait le modèle ABAC. Les solutions ABAC et PBAC permettent la création de politiques d’autorisation basées sur les attributs des sujets, des objets et du contexte.

Contrôle d’accès basé sur les relations (relationship-based access control – ReBAC)

L’idée d’un modèle d’autorisation basé sur les relations a été formalisée pour la première fois en 2006 dans le contexte du partage d’informations dans les réseaux sociaux. Une des applications de ce modèle est de permettre à un individu de partager diverses informations avec d’autres individus en fonction de leur relation.

Le modèle ReBAC est similaire à ABAC en ce sens que les deux peuvent définir des politiques d’autorisation complexes et granulaires. La principale différence entre les deux modèles réside dans la manière dont les politiques sont conçues et évaluées. Dans le modèle ABAC, les attributs du sujet, de l’objet et du contexte sont évalués. Dans le modèle ReBAC, ce qui est évalué est la relation entre le sujet et l’objet.

Par exemple, dans le modèle ReBAC, un document pourrait avoir une relation d’éditeur avec un sujet spécifique. Si ce sujet tente de modifier le document, le système ReBAC vérifie que la relation d’éditeur existe entre le sujet et l’objet. Si une telle relation n’existe pas, la demande de modification est refusée.

Modèle ABAC

Cette section se concentre sur l’architecture et les composants du modèle ABAC.

Architecture ABAC

Les divers composants d’une architecture ABAC ont été initialement définis dans le cadre d’autorisation AAA (RFC 2904), publié en 2000. Ce RFC a établi les bases des politiques distribuées qui sont désormais utilisées dans les solutions ABAC modernes.

Voici un schéma illustrant les différents composants du modèle ABAC et la manière dont ils interagissent entre eux.

Le déroulement d’une requête suit les étapes suivantes :

1. Une requête est envoyée à un système pour un objet (ressource), tel que la récupération de dossiers dans une base de données ou l’appel d’une API. Cette requête est interceptée par le point d’application de politiques (Policy Enforcement Point – PEP), qui fait généralement partie du système qui retourne la réponse à la requête. Le PEP peut prendre différentes formes : un plugin de base de données, un sidecar pour un service mesh, du code intégré à l’application, etc.
2. Le PEP transfère la requête au point de décision des politiques (Policy Decision Point – PDP). Le PDP est chargé de prendre la décision d’autorisation. Le PEP peut également fournir des informations supplémentaires pertinentes qui n’étaient pas incluses dans la requête initiale. Ces informations supplémentaires peuvent être spécifiques à l’application ou provenir du contexte dans lequel la requête a été effectuée.
   Le PDP est un composant qui peut facilement être centralisé et potentiellement déployé en infonuagique. Une stratégie de déploiement valide consiste à avoir plusieurs PEP déployés dans des applications métiers sur site. Tous ces PEP peuvent ensuite se connecter à un seul PDP déployé en infonuagique.
3. Le PDP peut s’appuyer sur des sources de données supplémentaires pour prendre une décision d’autorisation. Ceci est nécessaire lorsque le PDP ne dispose pas de suffisamment d’informations avec la seule requête d’autorisation ou des informations supplémentaires fournies par le PEP. Lorsque le PDP a besoin d’informations supplémentaires, il peut interroger un ou plusieurs points d’information de politiques (Policy Information Point – PIP). Un PIP est un composant qui se connecte à diverses sources de données (bases de données, LDAP, etc.) afin de fournir des informations au PDP pour qu’il puisse prendre une décision d’autorisation. Les informations fournies par un PIP peuvent être relatives au sujet effectuant la requête ou à l’objet auquel le sujet souhaite accéder.
4. Une fois que le PDP dispose de toutes les informations nécessaires, il évalue les politiques pertinentes afin de prendre une décision d’autorisation.
5. Le PDP retourne ensuite la décision d’autorisation au PEP, qui est chargé d’appliquer cette décision. 
6. Le PEP applique la décision d’autorisation. Cette étape dépend de l’implémentation et de l’objet auquel le sujet tente d’accéder. Par exemple, si un sujet souhaite effectuer une requête GET sur une API, le PEP peut autoriser ou refuser la requête. Si un sujet souhaite exécuter une requête SQL SELECT sur une base de données, le PEP peut filtrer les lignes et colonnes auxquelles le sujet a accès.
7. Si l’accès est accordé au sujet, le PEP retourne l’objet demandé.

En parallèle à la requête effectuée par les sujets sur les objets, des tâches administratives sont également effectuées dans le système.

1. Un administrateur utilise le point d’administration des politiques (Policy Administration Point – PAP) pour gérer les différentes politiques du système. Comme le PDP, le PAP est un composant qui peut facilement être centralisé.
2. Le PAP, le PDP et les politiques gérées et lues par ces deux composants peuvent être déployés en un lieu centralisé.
   Le PAP met à jour les politiques qui sont lues par le PDP lors de son processus d’évaluation des politiques.

Politiques de contrôle d’accès ABAC et meilleures pratiques

Format des politiques

Les politiques dans le modèle ABAC suivent le format suivant :

Qui

Le sujet effectuant la requête. Le sujet peut représenter un compte utilisateur, un employé, un client, un système non humain, etc.

Quoi

L’objet ou la ressource à laquelle on accède. Une ressource peut être une API, une colonne dans une base de données, un microservice, etc. La partie “quoi” d’une politique décrit également les actions qui peuvent être effectuées sur l’objet. Par exemple, la partie “quoi” de la politique peut spécifier qu’un sujet donné peut effectuer un GET sur une API pour récupérer un document, mais ne peut pas effectuer un POST sur cette même API pour ce même document.

Quand

Le contexte dans lequel la demande peut être effectuée. Les facteurs contextuels peuvent inclure l’heure et la date de la demande, la géolocalisation d’où provient la requête, ou toute autre information contextuelle que le PEP peut fournir au PDP lors de la demande d’évaluation de la politique.

Meilleures pratiques pour la création de politiques

Voici une vue d’ensemble du processus de création d’une politique ABAC suit ces étapes :

1. Définir les actifs et les ressources à protéger. Dans le modèle ABAC, il s’agit des objets à protéger et ils représentent le quoi des politiques en cours de conception. Il est recommandé de commencer par définir les objets plutôt que les sujets. Commencer en définissant les sujets peut entraîner des définitions de sujets non pertinents ou qui se chevauchent.
2. Identifier les divers attributs d’objets qui sont pertinents lors de la prise d’une décision d’autorisation. Il est également important d’identifier la source de ces attributs. La source pourrait être dans la demande elle-même, provenir d’un PEP, ou l’attribut pourrait être stocké dans un PIP.
3. Identifier les actions et les cas d’utilisation des différents objets. Ceci inclut la conception et la mise en œuvre de l’autorisation en se concentrant sur le parcours utilisateur, en tenant compte de l’infrastructure d’authentification et des dépendances de données inhérentes à l’écosystème de sécurité protégeant l’accès aux objets.
4. Une fois les actions sur les objets et les cas d’utilisation définis, déterminer quels sujets devraient pouvoir les effectuer.
5. Identifier les attributs de sujets qui peuvent être utilisés pour les identifier correctement. Comme pour les attributs des objets, il est également important de déterminer la source des attributs des sujets (la demande, des informations supplémentaires du PEP ou du PIP).
6. Identifier tout attribut contextuel supplémentaire qui devrait être pris en compte lorsqu’un sujet effectue une action sur un objet. Des exemples d’informations contextuelles supplémentaires peuvent inclure : seulement pendant les heures d’ouverture, seulement en Amérique du Nord, etc.
7. Après avoir rassemblé toutes les données nécessaires, il est possible de concevoir des politiques ABAC appropriées. Pour ce faire, il faut identifier les points de contrôle entre les utilisateurs et les ressources où les données de contexte et d’attributs se croisent avec suffisamment d’informations pour prendre des décisions d’autorisation efficaces.

Principes de conception des politiques

Voici quelques principes à prendre en considération lors de l’élaboration des politiques. Tous ces principes ne sont pas applicables à tous les contextes, mais il est bon de les garder à l’esprit.

• Additif : Les nouvelles règles et attributs s’ajoutent, plutôt que de remplacer ceux existants.
• Encapsulation : Les règles sont encapsulées dans leur propre couche ou module. Les changements dans les règles avancées d’une intégration n’affectent pas les mises en œuvre des autres.
• Fondation partagée : Construire sur une fondation commune cohérente sans la modifier.
• Compatibilité rétroactive : Utiliser l’autorisation de base si les couches avancées ne sont pas utilisables.
• Adoption progressive : Introduire des capacités avancées à un rythme adapté à l’évolution des cas d’utilisation ou des exigences.
• Mécanisme de secours : Si une règle avancée échoue ou est inapplicable, le système peut se replier sur des règles plus basiques. Cela garantit le bon fonctionnement du système même si certains composants avancés sont compromis.

Conclusion

Nous espérons que cet article vous a permis de mieux comprendre les concepts de base de l’autorisation, et plus particulièrement le modèle d’autorisation ABAC.

Dans les systèmes ayant des cas d’utilisation et des exigences de contrôle d’accès avancés, il est essentiel de comprendre les détails des modèles de contrôle d’accès avancés. Cet article devrait vous avoir donné la compréhension nécessaire pour mettre en œuvre des contrôles d’autorisation plus complexes dans vos projets.