Note de l’auteur: Le sujet abordé étant plutôt complexe, j’ai scindé mon propos en deux posts, l’un consacré à l’aspect technique, l’autre à l’aspect stratégique et commercial. Le post qui suit est le traitement technique. Pour en savoir plus sur l’analyse de la politique des APIs qui sous-tend cette approche, lire ce post.

Nous tentons ici de formaliser la définition du « Contrôle d’Accès Basé sur la Fonction » (Function-Based Access Control ou FBAC), un cadre général de Système de Contrôle d’Accès, dont la complexité peut s’adapter, sans discontinuités, à des usages simples (application mobile ou web, CMS) comme à des utilisations par des organisations de grande taille (grandes entreprises, agences gouvernementales etc.).

La politique est ce que la politique fait

Comme je l’ai expliqué dans un post précédent, je crois que ni le RBAC ni l’ABAC ne peuvent s’adapter à tous les cas d’utilisation nécehttps://www.hubrix.fr/2017/03/les-apis-toxiques-ou-don-quichotte-2-0/ssaires aujourd’hui pour le contrôle d’accès. Ils ne vont pas assez loin a fortiori pour servir dans des secteurs émergents comme les microservices, les Objets Connectés (IoT), les architectures « Serverless », les véhicules autonomes… et j’en passe.

La création d’un contrôle d’accès extensible commence par l’aveu de la très grande divergences des exigences requises d’une organisation à une autre. Un entrepreneur freelance, une PME, une ONG, une entreprise du Fortune 500 ou un ministère ont des besoins radicalement différents en termes de :

  • Conformité aux règlements
  • Charge de travail acceptable pour l’administration et la maintenance
  • Taux de changement de politique
  • Besoin d’intégration

La différence majeure entre ces différents acteurs vient de la définition même d’une « politique ». Un freelance peut improviser une nouvelle politique de contrôle d’accès sous sa douche. Une agence gouvernementale suivra sans doute un processus un peu plus structuré pour réaliser la même tâche, alternant propositions, révisions et approbations avant qu’une politique ne soit approuvée et implémentée. De ce simple constat, on peut déduire notre première exigence fonctionnelle.

Routage « Instance vs. Sorte »

Il nous faut distinguer entre une demande conjoncturelle, comme Georges demandant le droit d’imprimer des factures, et les demandes de changement de politique, comme Georges demandant que toute son équipe commerciale aient ce même droit. Le Système de Contrôle d’Accès (SCA) n’a pas besoin de détecter cette différence, mais il doit laisser au développeur la possibilité d’exprimer cette situation et de la traiter.

Function-Based Access Control: Ontologie

Notre deuxième exigence est de fournir une définition suffisamment flexible d’une « politique » pour qu’elle permette de traiter tous les cas d’utilisations que nous avons évoqué.

Pour cela, le politique et les rôles deviennent des effets secondaires de notre SCA; les acteurs et leurs activités, définies par des verbes, jouent le premier rôle. Les politiques deviennent ainsi des résultats des règles managériales et des conditions traitées, et non plus le point de départ pour l’administrateur.

La conformité (aux règlements, par exemple) est observée et validée a posteriori. L’administrateur n’a donc plus la tâche d’exprimer correctement toutes les règles à l’avance ni du premier coup, tout comme un compilateur de code source signale les erreurs de syntaxe plutôt que d’exiger d’emblée une syntaxe parfaite.

Dans le FBAC, nous appelons « Fonction » une activité (humaine ou non), représentée par un Verbe. Ce terme n’a donc rien à voir dans ce contexte avec ses connotations mathématiques ou informatiques.

L’ontologie du FBAC est simple :

Ontologie FBAC Hurima(tm)

Un Acteur est une entité qui peut accomplir une action, formalisée par un verbe. Il peut s’agir d’un utilisateur humain, d’un appareil (serveur, routeur, drone, smartphone etc.) ou d’une application logicielle.

Un Verbe ou une Fonction est une action qu’un acteur peut accomplir. Vous pouvez représenter des actions simples et prédéfinies: Créer, Lire, Mettre à Jour, Effacer, mais aussi des actions aussi diverses que courir, danser, redémarrer, nager, sauter, installer etc.

Une Cible est l’objet auquel s’applique le Verbe ou Fonction. Les acteurs, les verbes, les Fabriques et les Contraintes sont tous des cibles légitimes. Une Cible peut ainsi être quelque chose d’ordinaire tel qu’un fichier, une URL ou une adresse IP.

Une Fabrique est un processus qui produit des entités énumérables, quel que soit leur type. Ce concept sera familier aux développeurs orienté-objet et aux fans des Design Patterns. Quelques exemples :

  • Tous mes amis Facebook — « mes » est une Contrainte (voir ci-dessous), et la Fabrique produit un ensemble d’entités qui peut être utilisé comme Acteur ou Cible
  • Un Groupe — une liste d’Acteurs (tous les serveurs localisés en Irlande, tous ceux dans /etc/sudoers ou « Tous les utilisateurs de GSuite » etc.)

Une Contrainte est un type de Fabrique qui limite, filtre ou recherche une liste d’entités de toute sorte. Toutes les Contraintes sont des Fabriques, mais toutes les Fabriques ne sont pas des Contraintes. Les contraintes peuvent s’appliquer à toute liste de 0+ entités (y compris à des Fabriques ou à d’autres Contraintes). Elles renvoient en sortie un sous-ensemble de cette liste.

Exemples de contrainte :

  • Dans un rayon de 100 mètres (peut s’appliquer à toute liste d’Entités avec un attribut statique ou dynamique de Lieu)
  • Tous les jeudi (peut s’appliquer à toute liste d’entités avec un attribut de Date)

Dans le FBAC, un Privilège est un couple Verbe + Cible. En français, c’est le droit de réaliser une action (Verbe) portant sur une Cible.

Le FBAC implémente les Rôles comme une Fabrique de Privilèges, et les Groupes comme une Contrainte de Rôles. Les acteurs sont assignés à des Groupes par une Fabrique. Ces constructions (facultatives) permettent au FBAC d’implémenter un sur-ensemble du RBAC.

Les Fabriques et les Contraintes pouvant implémenter des règles booléennes complexes, le FBAC peut fournir aussi un sur-ensemble du ABAC.

Mais les choses deviennent intéressantes quand on s’intéresse non plus au RBAC ou ABAC, mais à ce que seul le FBAC peut faire.

Ce framework permet une implémentation rapide de cas d’utilisations triviaux. L’implémentation d’une Fabrique peut être simple, par exemple une requête dans une base de données. De telles Fabriques pourraient être clonées ou sous-classées, pour adresser rapidement les besoins de contrôle d’accès dans un CMS par exemple.

Le FBAC simplifie également l’expression de ce qui est possible, par opposition à ce qui est permis. En développant des contraintes basées sur des technologies sémantiques, on peut définir des limites globales : un « Drone » peut « Danser » (peut-être) mais un « Serveur » ne peut pas. Des limitations pratiques pour que les administrateurs ne puissent pas attribuer par erreur des privilèges inutiles ou absurdes.

L’objectif principal du FBAC est de permettre une évolution fluide de la politique d’accès au cours du temps, permettant de passer de cas d’utilisation simples à d’autres de plus en plus complexes, tout en conservant la même structure logicielle.

Opérations FBAC

Maintenant que nous avons ce modèle, qu’en faire? Commençons par tenir nos promesses du début à propos des Politiques. En FBAC, une Politique est un sur-ensemble de tous les Privilèges exprimables (Acteurs X Verbes X Cibles). Ce qui veut dire que la politique est observée, et non définie. Cette pratique représente un changement d’état d‘esprit par rapport au RBAC et à l’ABAC. Elle permet tout de même de vérifier la conformité à un ensemble arbitraire de règles (Sarbanes-Oxley par exemple).

Les Contraintes pouvant s’appliquer aux Acteurs, Rôles, Groupes et Privilèges, l’implémentation d’une Séparation des Tâches, statique ou dynamique, est aussi relativement simple.

La Billetterie ou le Tamis

Le point critique de tout framework de contrôle d’accès est l’approbation des transactions, ou « test des droits ». Quand Anna essaye d’imprimer une facture, l’application doit valider son droit à le faire.

Deux approches sont possibles: la « Billetterie », un appel explicite vers une fonction ou méthode qui teste la permission; ou le « Tamis, » une couche applicative qui teste les permissions et renvoie des erreurs ou des exceptions quand une action interdite est demandée. Des CMS tels WordPress ou Drupal adoptent l’approche du « Billetterie », alors que les serveurs comme Apache, ou des logiciels pare-feu comme iptables sous Linux, préfèrent le système du « Tamis »..

La plupart des systèmes RBAC/ABAC que j’ai utilisé reposent sur le système du Billeterie — mais il s’agit probablement d’un biais lié à ma propre expérience, puisque j’ai surtout développé des logiciels interactifs. Je préfère pour ma part le Tamis, car il donne quelque chose de plus propre au niveau de l’application : les développeurs n’ont pas besoin d’invoquer explicitement User->CanDoThis(…) chaque fois qu’on accède à une fonctionnalité. Mais cette décision ne m’appartient pas. Ce doit être celle des architectes et développeurs de l’application. Si vous vous demandez pourquoi l’ontologie du FBAC ressemble autant à celle d’un pare-feu de réseau, en voilà la raison. Nous voulons un système qui laisse les développeurs utiliser n’importe quelle combinaison de tests de permissions, explicites ou implicites.

Un avantage de la politique de la Billetterie, quand on travaille sur une application destinée à un public humain, est de permettre à l’utilisateur de demander un privilège qui lui a été refusé, et d’orienter cette requête vers un administrateur compétent. Ce serait un exemple du « routage d’Instance » évoqué au début du post. Mais pour ce faire la logique de « demande de droit » doit être présente dans l’interface, et une « conscience » du contrôle d’accès doit donc être codée au niveau applicatif.

Implémenter un Tamis en FBAC demande de définir des contraintes sur un ensemble de Cibles qui correspondent aux fonctionnalités de l’application. Dans ce cas, le Verbe peut simplement être « Exécuter ». Un usage plus intéressant pour le Tamis est de réaménager une application ayant déjà un SCA pour utiliser du FBAC. Ceci permettrait d’unifier le contrôle d’accès entre différents systèmes. Certes, plusieurs systèmes ABAC offrent un système de gestion centralisé. Mais ils ne peuvent pas étendre leur utilisation aux cas où les politiques elles-même sont hétérogènes.

Les Tamis FBAC ouvrent la porte au « routage de Sorte », dans lequel un nombre seuil d’accès refusés à un ensemble d’acteurs déclenche une demande de privilège. Ainsi, les politiques de contrôle d’accès peuvent s’adapter de manière dynamique à l’activité réelle des humains et des machines, plutôt que de suivre des politiques prédéfinies qui prennent un retard croissant sur ces activités.

Nous ne savons si notre approche au contrôle d’accès est juste ou fausse, mais nous pensons en tout cas qu’elle apporte des éléments véritablement nouveaux. Elle propose trois notions inhabituelles:

  1. Une politique de contrôle d’accès peut être observable a posteriori, obtenue comme un résultat de règles individuelles, plutôt que d’être définie a priori.
  2. Le contrôle d’accès doit pouvoir être généralisable à des écosystèmes hétérogènes de systèmes humains ou automatisés, sans que les gestionnaires de contrôle d’accès ne se voient obligés de définir à plusieurs reprises la même politique dans différents systèmes et interfaces..
  3. Les systèmes de contrôle d’accès doivent pouvoir exprimer des cas d’utilisations plus riches que la mise en vigueur de politiques prédéfinies, et pour cela, les tests de permission doivent être repensés.

Dans mon prochain post, je décrirai certains défis posés pour l’implémentation d’Hurima™, notre solution RESTful API de FBAC, et les solutions que nous avons pu implémenter jusqu’à présent. Vous pouvez en apprendre plus sur Hurima™ ici.

Nous attendons vos réactions et critiques. Ces posts n’ont pas pour but de prouver que nous avons raison, mais plutôt de démarrer une conversation avec nos lecteurs, pour que nous puissions comprendre et découvrir la vérité ensemble.

Share This