Pourquoi nous avons besoin du « contrôle d’accès verbal »

Pas de mise-à-jour automatique pour les méthodologies

À la fin des années 1980, les développeurs de logiciels ont commencé à employer l'expression « Role-Based Access Control » (RBAC) pour décrire l'exigence fonctionnelle qui-peut-faire-quoi dans les applications. Au début des années 1990, le National Institute of Standards & Technology a formalisé les avantages techniques et économiques du RBAC. Le RBAC était sans doute le meilleur modèle conceptuel possible auquel nous pouvions nous attendre pour la gestion des droits et permissions à cette époque.

Cependant, beaucoup des choses ont changé depuis l’invention du RBAC. Le RBAC est né à une époque où de nombreux salariés restaient 20 ans dans le même emploi — le « rôle » était par conséquent un pivot raisonnable pour les fonctions de sécurité. La programmation orientée-objet était encore pré-adolescente. Le Web avait un an. Et les téléphones étaient intelligents ou portables, mais pas les deux en même temps.

Une nouvelle génération de gens astucieux nous ont donné le « Attribute-Based Access Control », ou ABAC, en vue de mettre à jour les prémisses fondamentaux du contrôle d’accès pour le présent. Avec l’ABAC, le rôle n’est plus le pivot, et les attributs — qui peuvent être considérés comme des contraintes ou conditions logiques — peuvent s’appliquer soit au sujet (la personne qui peut faire quelque chose, ou non) ou à l'objet (les objets, données ou ressources auxquels ils peuvent ou ne peuvent pas avoir accès).

L’ABAC est un pas en avant, et offre de nombreuses améliorations par rapport au RBAC, mais présente néanmoins des problèmes. En voici quelques-uns:

  • En éliminant le rôle comme pivot, l’ABAC laisse un vide. Les systèmes ABAC n’ont aucun pivot central — idéal pour les politiques réglementaires, moins pour l’administration soutenable au fil des mois et années de changements de personnel, et les évolutions des flux de travail.
  • Comme son prédécesseur le RBAC, l’ABAC ne tient pas suffisamment compte du temps comme un facteur critique du contrôle d'accès (nous avions déjà évoqué ce problème).
  • Les implémentations ABAC existantes ne vont pas assez loin pour faire face aux nouvelles réalités du monde logiciel tel le « cloud computing », les containers, l’architecture « serverless », ou plus généralement, l'inévitable (voire même l’imminente) disparition des applications monolithiques.

 

Être partout, mais avec le pas léger

La mise en œuvre du contrôle d’accès présente des défis semblables à ceux de l’authentification et l’identification des utilisateurs. Tout le monde bénéficie des avancées telles que la connexion unique ( ou SSO ): les utilisateurs n’ont plus besoin de se souvenir de douzaines de mots de passe différents; les développeurs d'applications peuvent identifier de manière fiable un seul utilisateur de façon transversale sur plusieurs applications; et les responsables informatiques peuvent mettre en place des critères de complexité pour les mots de passe lorsqu'il n'y a qu'un seul mot de passe à retenir.

Le contrôle d'accès doit ressembler davantage au SSO. Il doit être un service, comme le presse-papiers numérique ou le système de fichiers, qui peut:

  • être partagé entre applications,
  • fonctionner de la même manière dans chacune d'elles, et
  • permettre aux politiques d’accès d’être exprimées de manière centralisées, d’un point de vue humain, et non pas selon les perspectives de chaque application.

 

L’ABAC est trop centré sur le développeur

Le fléau des applications, depuis qu’elles existent, est que les développeurs et utilisateurs se retrouvent souvent en quiproquo, car ils parlent deux langues très distinctes. Mais il y a eu des progrès de part et d’autre au cours des vingt dernières années. L'avènement du Web et des applications mobiles, sans parler d’une génération de jeunes adultes qui n’ont jamais connu un monde sans Facebook, a produit une grande population de lettrés du numérique.

Les nouvelles méthodologies de développement et de gestion de projet tels que l’Agile et le Scrum, et les catégories d'applications émergentes telles que le Business Process Management (BPM), ont créé une grande population de « développeurs avec des compétences humaines ». Ces développeurs respectent l'importance du design (visuel et comportemental) dans les applications; ils se concentrent davantage sur les cas d'utilisation que sur les exigences fonctionnelles; et ils montrent généralement plus d’empathie envers les utilisateurs dans la création de leurs produits.

Mais une plus grande population d'utilisateurs reste numériquement analphabètes, et parmi les lettrés, le niveau de sensibilisation est très variable selon les domaines. Les médias traditionnels couvrent désormais les grandes cyberattaques, et Edward Snowden a fait du bruit avec ses révélations cyber-intel; du coup un nombre croissant de gens comprennent au moins l’intérêt du chiffrement etc. Pourtant même parmi ces digi-literati, la compréhension du contrôle d'accès reste rare.

Un problème similaire existe du côté des développeurs. Les développeurs qui se sont « humanisés » (ou l’ont toujours été) cherchent à créer des applications séduisantes, et se concentrent donc sur les cas d'utilisation les plus sexy. Et le contrôle d'accès, par sa nature, propose des fonctionnalités pas sexy du tout.

Dure vérité: en termes de sexy, le contrôle d'accès est la brosse à WC des exigences fonctionnelles.

Ce serait un mal nécessaire, sauf qu'il est trop ennuyeux même pour être un mal. Il est juste ennuyeux.

Le résultat de tout cela: lorsqu’il s’agit du contrôle d’accès, même ceux bien imprégnés de la culture numérique sont comme les « utilisateurs désemparés » des années 1980; et les développeurs avec un fort kung fu dans le contrôle d’accès ont tendance à être moins anthropophiles que la moyenne.

Voici mon argument résumé dans un petit diagramme de Venn:


Ça donne envie juste de casser ces œufs et faire une omelette, n’est-ce pas?

Ne pourrait-on pas simplement s’entendre?

Pour résumer mon analyse sociologique amateur : dans le monde entier, un nombre toujours croissant de personnes sont de plus en plus averties sur le numérique, et un nombre toujours croissant de développeurs sont plus pro-humain dans leurs approches d’architecture, de conception et de mise-en-œuvre d’applications. Mais les « zones marginales » — des cas d’utilisation et les fonctionnalités qui rôdent aux bords de la (r)évolution numérique — n’ont pas encore bénéficié de ce rapprochement..

Le contrôle d’accès est le patient zéro de ce problème, et l’ABAC en est le symptôme.

Les systèmes de contrôle d’accès d'aujourd'hui, pour la plupart, sont construits par des développeurs qui ne se soucient guère des gens, pour des gens qui ne se soucient guère du contrôle d'accès.

« We Seem to Need a Verb » : le FBAC

Nous a-do-rons Buckminster Fuller. Nous rêvons de mobiles Dymaxion avec Android Marshmallow préinstallé.

L'ambition de l'équipe Hubrix est de résoudre le problème du contrôle d'accès, à trois niveaux:

  • Technique (il faut que ça fonctionne, à petite ou grande échelle, et rester flexible)
  • Expérience Développeur (courbe d’apprentissage, facilité d'intégration, capacité d’adaptation)
  • Expérience Humaine (courbe d’apprentissage, facilité d’utilisation au fil du temps, diversité de cas d’utilisation)

Nous proposons de le faire en construisant un système qui place les actions ou « verbes » au centre du système, là où on trouve le « rôle » dans le RBAC. Oui, c’est plutôt ambitieux. Mais nous savourons ce défi.

Pour le baptême de ce concept, nous avons joué avec « Verb-Based Access Control » mais cela nous semblait un chouia trop poétique. Nous aimons bien «Action-Based Access Control » mais l'acronyme ABAC est déjà pris.

Nous nous sommes donc contentés de « Function-Based Access Control », phrase un peu ordinaire, mais qui communique clairement notre intention.

Qu'est-ce que cela signifie concrètement? Pratiquement? Techniquement?

Il vous faudra lire le prochain post pour le savoir.

OU…

Vous pouvez simplement nous parler tout de suite !

Share This