ABAC, les Anémones et Vous

Les systèmes et produits de Virtru sont construits et architecturés autour d'un modèle de contrôle d'accès basé sur les attributs (ABAC). La protection des données est notre pain et notre beurre, et le type d'approche que nous choisissons pour modéliser comment et quand les données sont accessibles est d'une importance capitale.

Mais qu'est-ce que l'ABAC et comment fonctionne-t-il ? 

Il existe de nombreux modèles de contrôle d'accès, et vous en avez probablement utilisé un au cours de la dernière heure sans vous en rendre compte ! En fait, il est généralement utile d'expliquer quelque chose en le reliant à quelque chose d'autre que tout le monde connaît mieux. C'est ce que nous allons faire !

Les inconvénients du RBAC

L'un des modèles traditionnels les plus courants que vous connaissez probablement est le contrôle d'accès basé sur les rôles (RBAC). Dans un modèle RBAC, les acteurs du système sont affectés à des groupes - ou "rôles" - et ces groupes ou rôles ont des autorisations pour faire des choses spécifiques. 

Si vous avez déjà demandé à quelqu'un de vous "ajouter en tant qu'administrateur" ou si vous avez téléchargé un document sur Sharepoint et l'avez partagé avec le groupe de votre équipe, vous opériez dans un modèle RBAC.

Le RBAC est assez courant, mais il présente plusieurs défauts et inconvénients spécifiques, bien compris et bien étudiés, surtout à grande échelle :

• Le RBAC souffre d'une "explosion des rôles". Les systèmes RBAC, quelle que soit leur taille, ont tendance à se transformer en un fouillis de nombreux rôles - trop nombreux pour en garder la trace.
• RBAC ne prend en charge que les décisions d'accès statiques. RBAC est fondamentalement incapable de prendre des décisions d'accès dynamiques basées sur des données environnementales et contextuelles (par exemple, "Vous avez accès pendant une heure si la lune est pleine à votre emplacement"). 
• Le RBAC ne peut pas prendre en charge la séparation dynamique des tâches. Toute personne ayant le bon rôle peut faire tout ce que ce rôle est autorisé à faire, sans aucune contrainte. La modélisation d'exigences d'accès complexes telles que "Le réacteur ne peut être ouvert que par deux personnes d'organisations différentes se tenant à 15 pieds l'une de l'autre" ne peut pas être facilement réalisée avec RBAC.
• RBAC est tout simplement inadapté à la gestion des droits et des accès individuels. RBAC n'attribue des permissions qu'à des groupes et à des rôles, pas à des individus. Et les rôles ne sont pas les mêmes choses que les identités. Dans un monde où les données personnelles sont de l'or et où la confiance zéro est un enjeu majeur, il ne suffit plus de dire que nous protégeons les données et l'accès en fonction du rôle d'une personne. Nous devons être en mesure de protéger les données en fonction de l'identité d'une personne. 

Ces défauts et inconvénients se résument à un simple fait : le RBAC est fondamentalement incompatible avec l'architecture Zero Trust et n'est pas naturellement centré sur les données. C'est pourquoi nous ne l'utilisons pas comme base architecturale pour nos produits : Il ne répond tout simplement pas aux deux exigences les plus fondamentales de Virtru !

Entrez dans le dragon (ABAC)

C'est le RBAC, mais qu'est-ce que le contrôle d'accès basé sur les attributs (ABAC) ? 

• ABAC prend en charge les décisions d'accès dynamiques.
• ABAC prend en charge la séparation dynamique des tâches. 
• ABAC est parfaitement adapté à la gestion des droits et des accès individuels.
• ABAC est une norme du National Institute of Standards and Technology (NIST).

La différence la plus importante entre RBAC et ABAC est qu'ABAC n'a fondamentalement aucun rôle ou groupe. Pas du tout.

ABAC a plutôt des attributs, qui peuvent être appliqués à différentes "choses" (données, personnes) dans différents contextes.

ABAC peut être utilisé pour émuler les "rôles" et les "groupes" et les concepts RBAC - mais cela annulerait les avantages d'ABAC par rapport à RBAC.

Par conséquent, abordons les bases d'ABAC.

Qu'est-ce que ABAC ? 

Il y a trois "types de choses" fondamentales dans un système ABAC dont vous devez vous souvenir :

• Les données
• Entités
• Attributs

Si vous avez besoin d'un moyen mnémotechnique pour ces trois choses, je vous suggère :

Répétez-vous cela plusieurs fois en regardant cette image. Je vous promets que cela vous aidera à comprendre le concept.

Données

Les données sont les informations qui sont créées et/ou auxquelles on accède dans un système ABAC.

Définissons certains de ces éléments essentiels du monde de l'ABAC. Tout d'abord, il y a les données. Les données sont n'importe quel élément d'information qu'un acteur du système crée ou auquel il accède. En termes de Virtru, il s'agit de la charge utile de l'utilisateur que nous chiffrons et enveloppons dans un TDF. Virtru est spécialisé dans la protection des données, c'est donc, en pratique, la principale chose qui nous intéresse pour protéger et prendre des décisions. Parfois, d'autres systèmes ABAC appellent cela une "ressource" au lieu de "données".

Lorsque les données sont créées, des attributs leur sont attribués. L'ensemble des attributs attribués aux données est appelé attributs de données. Les attributs de données attribués aux données déterminent quand, où et par qui les données sont accessibles.

Les attributs de données doivent décrire exclusivement les caractéristiques des données auxquelles ils sont attachés, et non les caractéristiques du système qui les consomme.

Entités

Les entités sont les éléments qui créent des données ou accèdent à des données dans un système ABAC. 

Une entité est tout "acteur" dans le système ABAC. En général, les acteurs créent des données ou y accèdent. Une entité peut être un utilisateur humain, une machine agissant pour le compte d'un utilisateur humain ou une machine agissant pour son propre compte - le terme général pour tous ces éléments est entité.

Il existe deux types d'entités de base :

• Les entités personnes (EP) : Les utilisateurs humains. Vous êtes une entité personne. Je suis une entité personne.
• Entités non personnelles (ENP) : Tout ce qui crée et accède aux données - machines, services, etc. 

Les entités se voient attribuer des attributs, tout comme les données. En général, les systèmes ABAC doivent éviter de faire la distinction entre les entités non personnelles et les entités personnes : Elles doivent être traitées de la même manière en termes d'architecture et de logique de conception. La seule différence réelle entre les sous-types d'entités est la manière dont elles sont intitulées, c'est-à-dire les attributs d'entité qui leur sont attribués. Rien d'autre.

Il est tentant de dire que l'ensemble des attributs d'entité attribués à une entité "autorise l'entité", mais c'est incorrect. Rappelez-vous que les attributs décrivent simplement la chose à laquelle ils sont attachés et qu'ils n'ont aucune signification jusqu'à ce qu'ils soient interprétés au moment de l'accès aux données. Pour le savoir, vous devez également connaître les "règles commerciales" ou la logique qui seront utilisées pour interpréter les attributs de l'entité.

Notez que souvent, dans les flux d'authentification, les NPE et les PE s'authentifient ensemble. Imaginez qu'un utilisateur (PE) utilise un client mobile (NPE) pour s'authentifier auprès d'un backend. Lorsque cet utilisateur crée des données dans une application mobile, c'est l'application mobile qui gère les données, les traite, contacte les serveurs en votre nom et les télécharge. L'utilisateur et l'application mobile sont tous deux des entités distinctes et identifiées de manière unique dans le système d'authentification, mais ils sont en réalité authentifiés ensemble comme une seule et même chose - c'est en fait l'union d'un PE et d'un NPE que nous authentifions et autorisons.

Il s'agit d'une distinction importante et nécessaire pour la protection des données dans le cadre du Zero Trust. Un utilisateur peut avoir accès à des données, mais uniquement à partir d'un poste de travail client spécifique, et non à partir de son téléphone client, par exemple.

L'utilisateur et le client sont tous deux des entités, distinctes et identifiées de manière unique dans le système d'authentification, mais nous les autorisons en réalité comme une seule et même chose : nous authentifions et autorisons en réalité l'union du PE et du NPE, si vous voulez.

Attributs

Un attribut est un simple bout de texte qui décrit une caractéristique de la chose à laquelle il est attaché. On pourrait les considérer de manière informelle comme des balises uniques au monde.

Les attributs se composent d'un nom, qui est généralement espacé d'une manière ou d'une autre pour garantir l'unicité globale, et d'une valeur. Les attributs sont généralement codés sous forme de simples paires clé-valeur.

Par exemple, un attribut nommé "username" avec la valeur "hortense" peut être attaché à une entité Person sous la forme d'une paire clé-valeur :

Clé : "https://virtru.com/username"

Valeur : "hortense"

Comme indiqué, les attributs sont affectés à la fois aux données et aux entités. Les attributs sont sous-catégorisés selon qu'ils sont attachés à une entité ou à une donnée. Dans les deux cas, il s'agit toujours de paires de noms et de valeurs. Ils sont simplement interprétés différemment en fonction de ce à quoi ils sont attachés.

Les attributs ne signifient rien, ou n'ont aucune signification en termes de logique métier, tant qu'ils ne sont pas interprétés lors d'une décision d'accès. Il n'y a pas d'attributs "spéciaux" ou "plus importants" ou "codés en dur" dans un système ABAC. L'attribut "username" ci-dessus ne peut et ne doit pas avoir de signification spéciale pour le système. C'est juste une caractéristique descriptive comme "bleu", "chaud" ou "fantaisie", jusqu'à ce que quelque chose l'interprète dans le contexte de l'entité ou des données auxquelles il est attaché, et lui donne une "signification" au sens de la logique d'entreprise.

Une pièce de plus : Le point de décision politique

Rappelez-vous : Il y a trois "types de choses" fondamentales dans un système ABAC :

• Les données
• Entités
• Attributs

Et vous vous dites peut-être :

 "Alors je comprends...

- Les attributs affectés aux données sont des attributs de données.

- Les attributs assignés aux Entités sont des Attributs d'Entités

...mais qu'est-ce qui ASSIGNE réellement ces attributs ? Et qu'est-ce qui compare réellement les attributs d'entité et les attributs de données ?"

Il existe un autre type de composant essentiel dans un système ABAC qui gère l'interaction de ces trois éléments fondamentaux : un point de décision politique (PDP).

Chaque système ABAC possède plusieurs PDP qui gèrent différents aspects de la politique, ou ce que vous pourriez appeler la logique commerciale ou les règles commerciales. Les PDP sont l'endroit où se trouve la "logique métier" ou les "règles métier".

Les points de décision de politique (PDP) regroupent les données, les entités et les attributs dans une politique. 

Un PDP est un service qui compare ou attribue des attributs - en substance, il prend des décisions de politique.

• Un PDP de marquage des données attribue des attributs aux données, sur la base d'une logique commerciale.

• Un PDP d'habilitation attribue des attributs aux entités, sur la base d'une logique métier : c'est-à-dire qu'il habilite une entité.

• Un PDP d'accès :
• Regarde les attributs d'entité de l'entité qui demande les données
• Regarder les attributs de données des données
• Compare les deux pour déterminer si l'entité peut accéder aux données.

Récapitulation : 3 éléments clés d'ABAC 

Donc pour récapituler les concepts clés de l'ABAC. N'oubliez pas l'anémone ! 

Anémone Erotique Dank

Données - Entités - Attributs

Et la dernière chose qui lie ces trois composants fondamentaux d'un système ABAC tous ensemble : Les points de décision politique.

For a visual aid, here’s a basic diagram of the ABAC system we’re describing:

(Source: Imgur)

Construisez votre stratégie de confiance zéro avec ABAC

Pour résumer, ABAC vous donne un contrôle beaucoup plus granulaire que RBAC. Parce qu'il est véritablement centré sur les données, ABAC prend en charge le Zero Trust et est également suffisamment flexible pour répondre aux différents besoins d'accès au fur et à mesure que votre entreprise se développe et change à l'avenir. 

Nous sommes tous dans l'ABAC ici chez Virtru. Pour en savoir plus, consultez l'architecture de notre plateforme ou explorez nos outils de développement.