DORA et Axiomatics : appliquer le moindre privilège au moment de l'action

L'article 21(a) impose que l'accès aux actifs TIC repose sur les principes du besoin d'en connaître, du besoin d'en disposer et du moindre privilège, y compris pour les accès distants et d'urgence. Un modèle RBAC peut répondre à une partie de cette exigence en donnant à une personne les droits associés à son rôle, mais il atteint ses limites lorsque la décision dépend simultanément de plusieurs caractéristiques de l'utilisateur, de la ressource et de l'action demandée.

Prenons le cas de Claire, Senior Analyst au sein de la direction Finance France. Son IGA peut légitimement lui attribuer le rôle « Analyste Finance », mais ce rôle ne permet pas à lui seul de décider si Claire doit pouvoir consulter tous les dossiers financiers, modifier certaines informations ou effectuer une opération portant sur une autre entité du groupe.

Axiomatics permet de construire une décision à partir d'attributs appartenant à quatre catégories : le sujet, l'action, la ressource et l'environnement. La documentation de l'éditeur cite par exemple, pour le sujet, le rôle, le département ou le niveau d'habilitation ; pour l'action, la consultation ou la modification ; pour la ressource, le dossier ou l'objet concerné ; et pour l'environnement, des éléments tels que le lieu, l'heure ou le type de terminal. Ces attributs sont évalués dynamiquement au moment de la demande.

Dans notre exemple, la politique pourrait donc prendre en compte le fait que Claire appartient à Finance France, demande à consulter le dossier FIN-2026-00452, que ce dossier appartient à l'entité France et possède une classification donnée. Le rôle reste une information utile, mais il devient l'un des éléments de la décision plutôt que la totalité de la politique.

Cette approche évite également de créer un nouveau rôle pour chaque combinaison possible de fonction, entité, type de donnée ou action. Axiomatics présente précisément PBAC comme une alternative aux modèles d'autorisation trop statiques : les politiques sont centralisées et utilisent des attributs pour adapter les autorisations sans devoir modifier l'ensemble du modèle de rôles ou coder chaque règle directement dans les applications.

L'article 21(d) demande que les restrictions d'accès aux actifs TIC comportent des contrôles et outils permettant d'empêcher les accès non autorisés. Pour Axiomatics, cette exigence se traduit par une architecture dans laquelle la politique et la décision sont séparées de l'application qui applique le résultat.

Axiomatics s'appuie notamment sur le modèle XACML. Lorsqu'une requête arrive, un Policy Enforcement Point (PEP) l'intercepte et transmet les informations nécessaires au Policy Decision Point (PDP). Le PDP évalue les politiques et les attributs disponibles, puis renvoie une décision, généralement Permit ou Deny. Le PEP applique ensuite cette décision sur la ressource protégée. Les politiques sont administrées via un Policy Administration Point (PAP) et les informations nécessaires à leur évaluation peuvent provenir de Policy Information Points (PIP) tels qu'un annuaire, une base de données ou une autre source de référence.

Pour Claire, l'application n'a donc pas besoin de contenir une succession de conditions du type « si Finance France, si classification X, si action Y, alors autoriser ». Elle demande au moteur d'autorisation si Claire peut consulter FIN-2026-00452. Le PDP évalue la politique avec les attributs nécessaires et renvoie sa décision au PEP.

Cette externalisation permet surtout d'appliquer une même politique d'autorisation à plusieurs points du système d'information. Axiomatics documente ce fonctionnement pour les applications, les microservices et les API Gateways ; dans ce dernier cas, la gateway peut jouer directement le rôle de PEP tandis qu'Axiomatics reste le PDP.

DORA demande également que les événements relatifs au contrôle d'accès logique et à la gestion des identités soient journalisés. L'article 12 impose que le niveau de détail des journaux soit adapté à leur finalité et permette notamment la détection d'activités anormales.

Axiomatics peut contribuer à cette chaîne de preuve en journalisant les décisions d'autorisation. L'éditeur distingue notamment l'audit administratif des politiques et les journaux d'autorisation produits au runtime, qui permettent de suivre les décisions prises lors des demandes d'accès.

Dans notre exemple, l'intérêt n'est donc pas uniquement de savoir que Claire a tenté de consulter un dossier. Il devient possible de conserver également la décision d'autorisation prise à ce moment-là et de la relier à la politique utilisée.

Cette trace ne remplace toutefois pas le dispositif complet de journalisation demandé par DORA. L'article 12 couvre également les activités des systèmes TIC, la gestion des changements, le trafic réseau et d'autres événements. Axiomatics apporte la preuve de sa décision d'autorisation ; les autres briques de journalisation et de sécurité restent nécessaires pour restituer l'activité globale du système.