Introduction
DAC, RBAC, OrBAC, ABAC ou encore GraphBAC ? Les modèles d’habilitation phares évoluent régulièrement et apportent chacun leur lot d’enjeux, de promesses et de complexité.
Depuis une vingtaine d’années au cours desquelles les modèles RBAC/OrBAC semblent s’être imposés, les difficultés de conception, d’implémentation et de maintenance d’un modèle d’habilitation sont restées les mêmes, et rares sont les exemples de réalisation parfaitement satisfaisants.
Vouloir refondre son modèle d’habilitation amène à se poser beaucoup de questions. Nous essayons au travers de deux articles de répondre aux plus fréquentes.
Mais avant cela, revenons sur quelques notions de base concernant les modèles d’habilitation.
Qu’est-ce qu’un modèle d’habilitation ?
Une couche d’abstraction…
Un modèle d’habilitation est une couche d’abstraction qui vient se placer au-dessus des permissions techniques (droits applicatifs, transactions, groupes…). Elle est constituée d’objets soigneusement définis (rôles, permissions…), disposant d’un nom en langage naturel, et souvent organisés hiérarchiquement.
…qui simplifie la gestion des habilitations…
Cette couche d’abstraction permet notamment de rationaliser le nombre d’objets à manier.
Pour le Métier, il devient plus facile de comprendre les habilitations disponibles et de demander ou valider les droits adéquats.
Pour les équipes IT et le support, la charge d’attribution des habilitations s’en retrouve globalement réduite. La mise en place d’outils d’automatisation peut prendre en charge une grande partie des demandes quotidiennes, ce qui permet de traiter les demandes spécifiques avec plus d’attention.
… et améliore la sécurité
Au-delà de la dimension réglementaire et normative de la maîtrise des habilitations, souvent rappelée par les Commissaires aux Comptes lors de leurs audits, le manque de contrôle des habilitations est une porte ouverte aux intrusions et aux mauvaises utilisations du SI.
La connaissance de ses habilitations est un prérequis à leur sécurisation, et la mise en place d’un modèle permet de simplifier les contrôles, notamment lors des campagnes de revue. Il est en effet bien plus aisé pour un manager de valider l’attribution d’un rôle métier parlant, que celle d’une transaction à la dénomination très technique.
Panorama des modèles possibles
DAC : Discretionary Access Control, ou pas de modèle !
Et si le meilleur modèle était l’absence de modèle ? Dans certains cas limités, en particulier si le nombre de permissions ou d’utilisateurs est très restreint, on peut très bien se passer de concevoir un modèle qui viendrait ajouter une couche de complexité non nécessaire. Cela suppose néanmoins que les permissions applicatives soient suffisamment explicites.
RBAC : Role-Based Access Control
Le modèle RBAC permet de regrouper en « rôles » les habilitations nécessaires à l’exercice d’une fonction au sein une entreprise (métier, mission, projet…). Ces rôles sont alors attribués en lieu et place des habilitations discrétionnaires. Ils peuvent être organisés hiérarchiquement, par exemple en subdivisant des « rôles métier » en « rôles applicatifs ».
OrBAC : Organization-Based Access Control
Le modèle OrBAC est une variante du modèle RBAC dans laquelle les entités qui composent une entreprise sont un des axes de modélisation. Chaque utilisateur a alors un ou plusieurs rôles en fonction de son appartenance à une direction, un service ou une équipe.
ABAC : Attribute-Based Access Control
L’attribution des habilitations via le modèle ABAC se fait grâce à un ensemble de règles qui se basent sur des attributs liés aux utilisateurs, aux ressources elles-mêmes, ou bien à l’environnement. Cette attribution est souvent « dynamique », c’est-à-dire que l’autorisation ou non d’accéder à une application ou une partie d’une application est évaluée au moment où l’utilisateur tente d’y accéder. Dans les faits, il est possible de mettre en place un modèle ABAC tirant parti des rôles d’un utilisateur, comme dans le modèle RBAC.
GraphBAC : Graph-Based Access Control
Le modèle GraphBAC ou GBAC repose sur la représentation des habilitations à l’aide d’un graphe liant entre eux des objets (fichier, compte utilisateur, …) grâce à des relations diverses (lien entre manager et managé, appartenance à une structure, possession d’un fichier…). Les habilitations sont alors le résultat de requêtes sur ce graphe, ce qui permet de donner accès à une ressource suivant sa relation avec d’autres objets.
Vision du marché
Le tableau ci-dessous compare de manière très synthétique les différents modèles d’habilitation que nous venons de voir.
| Modèle d’habilitation | Facilité de mise en œuvre et de gestion du modèle | Possibilités | Présence sur le marché | Tendance |
| Aucun modèle | n/a | — | Marginale | ⇓ |
| RBAC | + | + | Très fréquente | ⇒ |
| OrBAC | + | + | Fréquente | ⇒ |
| ABAC | – | ++ | Rare | ⇑ |
| GraphBAC | – | ++ | Très rare | ⇑ |
Les questions les plus fréquentes sur les modèles d’habilitation
À quoi doit servir mon modèle d’habilitation ?
La mise en place d’un modèle d’habilitation peut s’avérer complexe, coûteuse et chronophage. Il est donc crucial d’étudier en profondeur les besoins et de définir clairement ses attentes. Comme évoqué en introduction, la mise en place d’un modèle d’habilitation peut permettre de répondre aux enjeux de sécurité des accès, aux enjeux réglementaires, mais également de simplifier l’expérience utilisateur et d’améliorer l’efficacité des processus IAM (Identity & Access Management). Un des facteurs clés de succès d’un projet de modélisation des habilitations réside dans la capacité à exprimer ses attentes précisément, à l’aide d’indicateurs chiffrés le cas échéant : réduire le temps nécessaire à la création des accès par un manager lors de l’arrivée d’un collaborateur à 15 min, atténuer 90% des risques considérés critiques, etc.
Qui impliquer pour construire, instancier et faire vivre mon modèle ?
Vu le caractère transversal et l’ampleur de la transformation induite par un changement ou une création de modèle d’habilitation, il est nécessaire de prévoir une gouvernance forte.
Il est préférable d’impliquer un sponsor à forte visibilité auprès du COMEX, qui saura apporter son appui, et qui permettra d’obtenir une adhésion forte de la part du Métier, premier concerné par les changements, et des responsables applicatifs, qui seront fortement sollicités lors de la conception et de la mise en œuvre. On peut également identifier des relais clés, qui viendront apporter leur aide au sein des différentes équipes de l’organisation (RH, DSI, Contrôle Interne…).
Au-delà de la phase projet, il faut également identifier les acteurs qui seront en charge de faire vivre le modèle. Un facteur clé de succès de la mise en place d’un modèle d’habilitation est l’identification des propriétaires des rôles. Si chaque rôle ne comprend que des permissions d’une seule application, on peut facilement se tourner vers le responsable d’application, mais dans la plupart des cas, chaque rôle est composé de permissions provenant d’applications diverses.
L’idéal est de trouver une personne qui a à la fois la connaissance des processus métiers, de l’organisation de l’entreprise, des applications, et une compréhension des règles de sécurité : c’est un exercice difficile ! À défaut, une petite équipe combinant les différentes expertises doit permettre d’assurer cette fonction.
Dois-je couvrir les « droits fins » ? Les « périmètres » ? Quelle granularité pour mon modèle ?
Le monde des habilitations est aussi vaste que la multitude des applications existantes, et les cas d’usage qu’un modèle d’habilitation doit couvrir sont nombreux.
La question des droits fins et de la gestion des périmètres revient régulièrement sur la table lors de la phase de conception. Faut-il, ou non, les inclure dans son modèle ? Il n’existe pas de réponse prédéfinie.
Il est parfaitement envisageable dans certains cas de n’inclure dans le modèle que l’accès à l’application, et de laisser la gestion des droits fins et des périmètres à la main du responsable applicatif et de son équipe, en précisant uniquement les accès demandés dans un champ libre lors de la demande. On perd alors en auditabilité, mais on gagne en simplification de la gestion des demandes.
Si l’on décide d’inclure la notion de périmètre, il faut alors choisir entre une implémentation croisée, dans laquelle on crée autant de droits que de croisements permission-périmètre, ce qui risque de créer un nombre important de rôles, et une implémentation séparée, où on crée d’une part les permissions, et d’autre part les périmètres.
Il est probablement préférable d’aborder le problème séparément, quitte à créer les rôles combinés avec leur périmètre dans un second temps, en fonction des usages identifiés : le modèle qui en découle a ainsi une volumétrie plus limitée.
Que dois-je inclure dans mon modèle ? Quid des accès physiques et des assets physiques ?
Inclure l’ensemble des habilitations au sein de son modèle est extrêmement difficile, voire impossible, d’une part au vu de la grande diversité des cas existants, d’autre part pour des raisons d’efficacité du projet.
Il faut sans cesse garder en ligne de mire l’objectif de la mise en place d’un modèle. Ainsi par exemple, si le but est l’amélioration de l’expérience utilisateur lors des demandes de droits, il vaut mieux prioriser le traitement des permissions orientées vers le métier, qui seront susceptibles d’être attribuées fréquemment, par rapport à des permissions techniques peu utilisées.
Par ailleurs, il peut être tentant d’inclure dans son modèle d’habilitation les accès physiques (locaux, salles spécifiques…) ou les assets physiques (badge, PC, téléphone…) car ils font partie – au même titre que les accès logiques – des moyens dont doivent disposer les collaborateurs pour travailler.
Ici encore, il n’y a pas d’interdit majeur, et des sociétés gèrent par exemple les accès à leurs locaux au sein de leur modèle d’habilitation. Néanmoins, en règle générale, les accès et assets physiques n’en font pas partie en tant que telles.
Pour autant, la solution IAM peut contribuer à leur bonne gestion avec par exemple :
- Un rôle de centralisateur de demandes, envoyées à différents acteurs ou systèmes lors de l’arrivée d’un collaborateur. Ce « package d’arrivée » comporte alors aussi bien des accès logiques (comptes et droits par défaut) que des ressources physiques.
- Un rôle de référent des données et évènements relatifs à une personne. Ces informations, en particulier les dates d’arrivée/départ sont partagées avec les systèmes de gestion des badges pour en gérer le cycle de vie.
Nous venons d’aborder quatre premières questions pour mener à bien un projet de refonte de modèle d’habilitation. D’autres questions seront détaillées dans un second article, à venir très prochainement.
