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.

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.

Cet article Refondre son modèle d’habilitation : les questions essentielles (1/2) est apparu en premier sur RiskInsight.

Le lieu de travail et ses outils de collaboration

C’est formidable de pouvoir travailler de n’importe où, avec n’importe quel appareil et de disposer de la technologie nécessaire quand on en a besoin. Plus qu’un luxe, c’est une nécessité dans la situation actuelle de travail à distance intensifié, ou pour les organisations internationales dont les utilisateurs sont très mobiles, répartis et fluides. Alors que tant de changements se produisent pendant la crise, votre lieu de travail devrait soutenir la reconfiguration de votre entreprise en permettant au personnel, aux partenaires, aux fournisseurs de travailler avec différentes applications, différentes équipes, etc.

Le mot « lieu de travail » utilisé dans ce contexte ne se limite pas aux postes de travail et aux outils de collaboration. Il s’étend à des domaines plus larges tels que l’architecture d’entreprise, la sécurité des applications et la gestion des identités et des accès. On peut dire que nous parlons de la base informatique plus large et des capacités numériques, pour soutenir et répondre aux besoins des entreprises – le lieu de travail n’est peut-être que la partie visible de l’iceberg.

L’héritage sur l’héritage ajoute de la complexité

Du côté de l’utilisateur, dès que vous passez par plusieurs cas d’utilisation, par exemple l’accès à un système existant sur place ou à une application Software as a Service, vous êtes susceptible d’avoir besoin de plusieurs comptes et donc d’une expérience utilisateur lourde.

Du côté de l’exploitation informatique, c’est également un fardeau de la faire fonctionner : les postes de travail sont encore la plupart du temps un dispositif physique lié à un domaine rigide de l’entreprise ; ils doivent être configurés, puis expédiés au personnel distant ou à des parties externes, et les comptes doivent encore être approvisionnés dans des environnements cibles, avec des droits d’accès définis de manière appropriée. Tous les éléments ci-dessus sont généralement des processus différents qui se répètent pour chaque fournisseur ou partenaire, ce qui entraîne autant de dispositifs et de configurations.

Plus important encore, dans quelle mesure cette situation désorganisée et chevauchante est-elle sûre ? Avoir une visibilité et un contrôle sur qui a accès à quoi, de bout en bout et pour tous les environnements, est un défi en raison des cas d’utilisation cloisonnés. Et à mesure que les utilisateurs rejoignent et quittent l’entreprise, que les applications évoluent, le niveau de sécurité diminue probablement en raison du manque de précision des comptes et des droits.

D’après notre expérience chez Wavestone, tous ces défis découlent de l’accumulation de nouveaux cas d’utilisation et de nouvelles technologies, mis en œuvre en silo, pour leur propre usage ou pour un groupe limité de cas d’utilisation. La plateforme, qui a d’abord été conçue pour une utilisation principale, s’est maintenant transformée en une plateforme à utilisations multiples avec un modèle et des processus mal adaptés. De nombreuses organisations peuvent aujourd’hui être fières de pouvoir compter sur une plate-forme fédérée et une expérience d’accès moderne pour les applications en nuage d’un côté – et sur une expérience différente, mais raisonnablement bonne, du côté des applications internes. Cependant, souvent, les deux ne sont pas intégrés et ne bénéficient donc pas des avantages que nous avons décrits dans l’introduction. Nous pensons que cela est dû à l’absence d’un modèle/architecture véritablement partagé pour soutenir une expérience moderne, dans tous les cas d’utilisation.

Figure 1 – Exemple de modèle d’entreprise dans lequel chaque entité gère séparément les identités et leur accès : duplication des processus

Un modèle pour une expérience de rationalisation

Pour cette raison et pour l’avenir de l’expérience utilisateur, chez Wavestone, nous croyons en un modèle basé sur la ou les Tours de Contrôle d’Identité.

Une tour de contrôle d’identité est une plate-forme permettant de faire respecter vos politiques d’accès. Son but est de vérifier les demandes d’accès provenant de sources d’identité fiables et de déterminer si cette identité est autorisée à accéder à une ressource numérique cible. Pour reprendre la métaphore, un pilote désireux d’obtenir une autorisation de décollage soumettra son plan de vol en utilisant un canal de confiance, et après son approbation et d’autres vérifications par les contrôleurs, le pilote pourra procéder au décollage. Si nous devions transposer cette métaphore en numérique, nous parlerions d’un utilisateur : pour que ledit utilisateur puisse accéder à la plate-forme X, il devrait utiliser un processus d’entreprise qui est lui-même fiable par une tour de contrôle d’identité. Cet utilisateur fournit son « plan d’accès » (par exemple, un jeton de session) à la tour de contrôle d’identité. Après que la tour de contrôle d’identité a vérifié l’authenticité du « plan d’accès » par rapport à ses politiques d’accès, elle effectuera d’autres vérifications de contexte, telles que : l’heure de la demande, le lieu d’origine de l’accès, le niveau de confiance du dispositif, etc. Si ces vérifications mettent en évidence quelque chose d’inhabituel ou d’incohérent dans l’authentification de l’utilisateur, des demandes supplémentaires peuvent être faites pour permettre à l’utilisateur d’entrer (ré-authentification ou renforcement).

La tour de contrôle d’identité est sous votre contrôle et détient les conditions d’accès, c’est-à-dire les politiques d’accès et accepte les utilisateurs de sources spécifiques grâce à une relation de confiance préétablie entre les organisations.

Par exemple, dans le schéma ci-dessous, imaginez une situation dans laquelle un fournisseur développe un nouveau service dans votre environnement en nuage. Les utilisateurs du fournisseur conserveraient leur dispositif et le processus d’authentification qu’ils utilisent dans leur environnement d’entreprise, tandis que la tour de contrôle d’identité (TIC) imposerait un contrôle d’accès à l’environnement en nuage – sans avoir à utiliser et à gérer un compte différent et à se ré-authentifier. Pour les environnements avec des privilèges très granulaires comme AWS, construire une TIC découplée n’est peut-être pas une approche réaliste et la TIC est alors probablement la plateforme d’identité d’Amazon qui est gérée par votre organisation et liée au fournisseur d’identité du fournisseur. Le modèle de la tour de contrôle d’identité est essentiellement une extension de la fédération, mise en œuvre pour couvrir tous les cas d’utilisation.

Figure 2 – Accès d’un utilisateur partenaire à une ressource du fournisseur de services dans le nuage via une tour de contrôle d’identité

Dans un autre scénario, comme le montre ce schéma, considérons un candidat qui postule à un emploi dans votre organisation, grâce à un portail de recrutement que vous proposez. Il déposerait une candidature sur votre portail en utilisant son identité numérique soutenue par le gouvernement, et une fois qu’il aurait donné son accord pour accéder à son profil LinkedIn, vous pourriez obtenir un CV numérique. Pour le candidat, il suffit de montrer sa pièce d’identité et de donner une copie de son CV, plutôt que de remplir le(s) formulaire(s) d’inscription en demandant une nouvelle fois les mêmes informations d’identité standard et en risquant de faire une faute de frappe dans ses coordonnées – ou même de devoir envoyer des copies de documents sensibles comme son passeport.

Figure 3 – Un scénario alternatif présentant la relation de confiance entre une plateforme d’identification gouvernementale et l’entreprise

Un modèle, trois piliers clés

Forts de nos connaissances et de notre expérience, nous pensons que ce modèle devrait reposer sur trois piliers clés : une identité unique dans tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360°.

Une Architecture d’Identité Unique : elle est réalisée en suivant une règle simple : ne pas dupliquer les données d’identité. Moins vous créez de fiches d’identité pour une même personne physique, plus l’expérience numérique sera simplifiée – car des étapes lourdes commencent à apparaître lorsqu’un compte, un dispositif ou une action d’authentification supplémentaire est nécessaire pour que l’utilisateur accède à la ressource cible. La clé d’une donnée d’identité unique est d’essayer de réutiliser les données de sa source (qui fait autorité) au lieu de les dupliquer/copier dans vos propres systèmes. Par exemple, les fournisseurs ou partenaires travaillant avec votre organisation ont probablement déjà des identités numériques professionnelles pour leur propre usage informatique – quelles seraient les conditions pour les exploiter au lieu de les recréer ?  Les deux piliers suivants contribuent à répondre à cette question.

Un modèle commun et flexible : Le deuxième pilier consiste à utiliser un modèle commun et flexible pour permettre/restreindre l’accès à l’information. Pour assurer la flexibilité, un modèle de contrôle d’accès basé sur les attributs (ABAC) permet des règles granulaires et est bien adapté à une approche adaptative et basée sur les risques. Pour que cela fonctionne, il est toutefois essentiel de définir la « grammaire » du modèle d’autorisation : quels sont les attributs réels utilisés pour fournir des accès qui ont un sens au niveau de l’entreprise ? Comment se traduisent-ils en « privilèges » ? Quels sont leurs formats/valeurs ? Lorsque la tour de contrôle d’identité est fournie par un fournisseur de cloud (par exemple, par un fournisseur de cloud comme Azure ou AWS), la grammaire est souvent déterminée par ledit service. En outre, pour que ce modèle soit le plus répandu possible dans les cas d’utilisation, tant du côté de la source d’identité que de la fourniture d’accès du côté du service cible, nous recommandons de mettre en œuvre votre plate-forme en suivant les normes du marché afin de maximiser l’interopérabilité (SAML, OpenID Connect, OAuth, FIDO, etc.).

Une relation de confiance à 360° : Enfin, le dernier pilier consiste à assurer l’établissement d’une relation de confiance à 360°. En d’autres termes, il faut faire preuve de diligence raisonnable et établir des seuils de confiance pour accepter l’interconnexion (« confiance technique ») des plateformes d’identité. La diligence raisonnable doit s’étendre à tous les processus en amont qui permettent d’alimenter la plateforme en identités, par exemple les processus RH/achats pour vérifier les identités, jusqu’au processus d’intégration informatique lui-même – parce que la confiance dans une plateforme d’identité est une première étape pour que ces identités puissent accéder à vos ressources numériques, vous devez être dans la tolérance du risque qu’elle comporte. Cette relation de confiance doit ensuite être mise en œuvre par le biais des attentes en matière de niveau de sécurité, de l’auditabilité des clauses contractuelles, et être appliquée par le biais de la gouvernance de la gestion des services des fournisseurs. Avec des exigences aussi strictes, une organisation doit être prête à intégrer temporairement des fournisseurs ou des partenaires au sein de sa propre plate-forme, pendant que les fournisseurs ou partenaires remettent leurs processus et plates-formes en conformité.

Deux facteurs clés de succès

Afin de mettre en œuvre ces trois piliers clés, Wavestone a identifié deux facteurs clés de succès : être parrainé par un niveau de gestion approprié et renforcer la résilience et la protection de la vie privée dès la conception. Un programme de transformation visant à établir ce modèle aurait des implications et des exigences dans plusieurs départements de votre organisation (RH, approvisionnement, juridique, informatique, risques, sécurité, etc.), et devrait donc être parrainé par la direction générale et mené avec une approche panorganisationnelle.

En outre, comme toujours, la plateforme de support doit être conçue et construite en tenant compte dès le départ des questions de sécurité, de confidentialité et de résilience.

Réflexions finales

Comme vous avez pu le comprendre tout au long de cet article, il est essentiel d’examiner l’expérience de l’utilisateur de bout en bout et d’un cas d’utilisation à l’autre pour vraiment rationaliser les services numériques. Cela peut être réalisé grâce à un changement d’organisation pour imposer une identité unique à tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360° avec les tiers.

Pour aller plus loin dans votre réflexion sur le sujet et comprendre l’état actuel de votre organisation, réfléchissez à ces questions et essayez d’y répondre : en choisissant des utilisateurs de différents services, à quoi ressemble l’expérience numérique quotidienne typique ? Combien de temps faut-il à mon organisation pour embarquer des sous-traitants et des tiers ? Comment mon organisation donne-t-elle effectivement accès à ses données et ressources aux utilisateurs externes ? Combien d’identités doubles existe-t-il dans mon parc informatique ? 

Cet article Les facteurs clés pour créer une expérience utilisateur transparente et sécurisée est apparu en premier sur RiskInsight.