Un moteur d'autorisation ne connaît pas votre métier
Ce que les démonstrations d'autorisation fine ne montrent pas toujours. Une politique lisible ne devient un contrôle opérationnel que lorsque l'architecture qui l'entoure sait, à temps, où trouver la donnée métier et comment appliquer la réponse. Nous parlons ici uniquement des identités humaines — collaborateurs, agents, prestataires, partenaires, utilisateurs externes connus de l'organisation.
Claire, un document et une règle qui paraît simple
Claire travaille à la direction juridique d'une grande organisation. Son identité est bien gérée. Netwrix Identity Manager connaît son employeur, son statut, sa direction, son manager, ses missions, ses habilitations et ses éventuelles exceptions temporaires. Son compte est créé, provisionné, gouverné. Elle accède à une plateforme documentaire à travers le SSO et une authentification forte.
L'organisation souhaite appliquer une règle qui, formulée oralement, tient en une phrase. Claire peut consulter les documents des dossiers suivis par son équipe. Elle ne peut télécharger un document classifié « Diffusion restreinte » que si elle est explicitement désignée sur le dossier. Sur une présentation commerciale, la règle paraît immédiate. Un sujet — Claire. Une ressource — le document. Une action — consulter ou télécharger. Une politique — autoriser ou refuser.
Nous commençons alors à poser des questions. Où se trouve la classification du document ? Dans une étiquette Microsoft Purview, dans une métadonnée SharePoint, dans la GED, dans une base métier, dans le nom du fichier, dans une propriété du document Word ? Où se trouve la liste des personnes désignées sur le dossier ? L'application expose-t-elle cette information ? Comment le moteur de décision récupère-t-il ces données ? Comment l'application lui transmet-elle le document concerné ? Où le refus sera-t-il réellement appliqué ? Ces questions constituent le véritable projet.
Avant d'aller plus loin, un point de cadrage. Pour beaucoup d'accès humains, le PBAC et l'autorisation fine ne sont pas nécessaires. Un cycle de vie fiable, des habilitations gouvernées, des rôles ou patterns cohérents, des groupes, des demandes d'accès, des recertifications, une authentification forte et quelques contrôles applicatifs simples suffisent souvent. L'autorisation fine devient utile lorsque la décision dépend de la ressource précise, de l'action demandée, d'une relation métier, d'une donnée réglementaire ou d'un contexte qui ne peut pas être correctement matérialisé à l'avance.
Trois décisions distinctes, trois moments distincts
Beaucoup de discussions dérivent parce que trois fonctions sont mélangées dans une même conversation. La première est la gouvernance — Identity Governance. Netwrix Identity Manager peut déterminer que Claire, en tant que juriste rattachée à cette direction, doit disposer d'un compte et d'un accès à l'application documentaire. Cette décision repose sur son identité, son cycle de vie, son organisation et les règles d'attribution. Elle répond à la question : Claire doit-elle pouvoir entrer dans cette application ?
La deuxième est l'authentification — Authentication. Ping Identity, Microsoft Entra ID ou Keycloak vérifient que la personne qui se présente est bien Claire. Ils gèrent le SSO, le MFA, la fédération, les sessions, les tokens, les Identity Claims et certains contrôles contextuels. Cette fonction répond à la question : la personne connectée est-elle bien Claire, et dans quelles conditions s'est-elle authentifiée ?
La troisième est l'autorisation — Authorization, et plus précisément la Fine-Grained Authorization lorsque la décision descend au niveau de la ressource. Une fois Claire dans l'application, une décision beaucoup plus précise doit parfois être prise. Peut-elle télécharger ce document particulier ? La réponse dépend alors de Claire, mais aussi du document, du dossier, de l'action, de la classification, de la relation entre Claire et le dossier, et parfois du contexte réglementaire. Cette décision peut être prise par un moteur comme Axiomatics, à condition que les informations nécessaires lui soient réellement fournies au moment où la question est posée.
Sept promesses entendues en démonstration, sept questions
Nous ne cherchons pas à discréditer les éditeurs. Nous décrivons simplement les questions que nous posons pendant les démonstrations, parce que ce sont les questions dont dépend la réussite du projet. À chaque promesse, nous ramenons la conversation à Claire et à son document.
- 01
« Notre plateforme fait du PBAC »
Le démonstrateur affiche une politique lisible : un collaborateur peut télécharger un document s'il appartient au bon projet et si le document n'est pas confidentiel. L'interface est convaincante. Nous posons une seule question. Comment la plateforme connaît-elle la classification du document Word ? La réponse ne peut pas être « grâce au PBAC ». Le PBAC évalue une information, il ne la crée pas. La classification doit être récupérée dans une étiquette de sensibilité, une métadonnée SharePoint, une GED, une base métier, une API ou un outil de classification documentaire. C'est le rôle du Policy Information Point. Un produit entièrement SaaS ne parcourt pas magiquement l'ensemble du système d'information ; il lui faut un moyen de s'accrocher à la donnée. Un moteur qui ne reçoit que les attributs de Claire connaît Claire. Il ne connaît pas encore le document. Une capacité PBAC peut être techniquement réelle et rester inutilisable pour le cas métier tant que les Resource Attributes ne sont pas raccordés.
- 02
« Toute la décision est dynamique »
Le démonstrateur modifie le département de Claire dans son environnement de test. La politique produit immédiatement une réponse différente. Nous demandons alors si la donnée métier a réellement été mise à jour en temps réel. Une Runtime Decision peut parfaitement être calculée à partir d'une information synchronisée la veille. Prenons un exemple. Claire quitte le projet à 10 heures. La base projet est mise à jour dans la seconde. Le moteur, lui, utilise une copie synchronisée chaque nuit. Claire reste considérée comme membre du projet jusqu'au traitement suivant. La politique est dynamique, la donnée ne l'est pas. Nous distinguons systématiquement le moment où la donnée métier change, le moment où le moteur la reçoit, le moment où une décision déjà en cache est invalidée et le moment où l'application applique la nouvelle réponse. « Décision en temps réel » ne signifie pas nécessairement « donnée à jour en temps réel ».
- 03
« Notre autorisation fonctionne au runtime »
Le mot runtime est souvent utilisé comme une preuve de modernité. Nous le ramenons à un cas mesurable. Claire ouvre une page contenant dix dossiers, plusieurs documents par dossier, des boutons de consultation, des boutons de téléchargement, une fonction de partage et une fonction d'export. L'application peut avoir besoin de vérifier plusieurs autorisations pour afficher correctement cette seule page. Supposons — à titre d'exemple de raisonnement — que dix décisions soient interrogées successivement et que chaque appel distant ajoute 500 millisecondes ; la page accumule cinq secondes d'attente uniquement pour l'autorisation. Ce chiffre n'est pas une performance de produit, c'est une hypothèse de test. Même si les appels sont parallélisés, la Latency du service le plus lent reste visible et la plateforme doit absorber le volume global. Nous demandons combien de décisions sont prises pour afficher une page, si une décision est prise par ressource, par action ou par écran, si les appels sont séquentiels ou parallèles, quelle est la latence médiane, quelle est celle au 95e et au 99e percentile, ce qui se passe sous charge, si le moteur est appelé depuis le navigateur, l'API ou le backend, et où il est physiquement hébergé par rapport à l'application. Le mot « runtime » ne donne ni le nombre d'appels, ni leur latence, ni leur emplacement dans le parcours utilisateur.
- 04
« La mise en cache règle la question de la latence »
Le cache peut être une excellente réponse. Il crée néanmoins de nouvelles questions. Supposons que Claire ait reçu l'autorisation de télécharger les documents d'un dossier, réponse mise en cache pendant quinze minutes. À 10 h 05, elle est retirée du dossier. Que devient la décision déjà en cache ? Nous demandons où se trouve le cache — dans l'application, dans un proxy ou dans le moteur —, quelle est sa durée de vie, s'il est indexé par utilisateur, ressource et action, si une modification des attributs invalide immédiatement la décision, comment la Revocation est propagée, et combien de temps Claire peut conserver un accès après la modification. Il n'existe pas de réponse universelle. Pour un bouton de consultation sans enjeu critique, quelques minutes peuvent être acceptables. Pour une opération réglementée, le même délai peut être trop long. Le cache réduit la latence en acceptant qu'une décision reste valable pendant un certain temps. Ce temps doit être choisi, pas dissimulé — et la Cache Invalidation doit être décrite, pas supposée.
- 05
« Le service est hautement disponible »
Nous demandons ce qui se passe lorsque le moteur d'autorisation n'est plus joignable. Deux comportements principaux sont possibles. En Fail Closed, l'application refuse l'action. La sécurité reste stricte, mais Claire peut se retrouver incapable de travailler. En Fail Open, l'application autorise l'action ou réutilise une décision antérieure. Le service reste disponible, le contrôle est temporairement affaibli. Reprenons le cas de Claire. Si le moteur devient indisponible, peut-elle encore consulter un document, modifier un contrat, télécharger un document classifié, partager une pièce avec un tiers ? La réponse n'a pas à être identique pour toutes les actions. Une architecture peut autoriser la consultation de données déjà accessibles tout en bloquant les téléchargements et les partages. Nous demandons quel est le comportement par défaut, s'il peut varier selon l'action, qui a validé ce choix, comment l'indisponibilité est détectée, comment les décisions prises en mode dégradé sont tracées, et comment le système revient à son fonctionnement nominal. La haute disponibilité d'un service ne répond pas à la question de ce que fait l'application lorsqu'elle ne reçoit aucune décision.
- 06
« Les politiques sont centralisées »
Centraliser l'écriture et l'administration des politiques apporte une réelle cohérence. Cela ne signifie pas que toutes les décisions ou tous les contrôles sont physiquement centralisés. Nous distinguons quatre points classiques : le Policy Administration Point, où les politiques sont définies ; le Policy Decision Point, où les décisions sont calculées ; le Policy Information Point, qui fournit les informations nécessaires ; le Policy Enforcement Point, qui applique la réponse. La politique peut être administrée dans un service SaaS. Le moteur de décision peut être distant ou local. Le point d'application peut se trouver dans l'application elle-même, dans une API Gateway, dans un proxy, dans un service backend, dans un composant intégré au client. Nous demandons à voir cette architecture, tracée sur un schéma, pour le cas de Claire. Une politique centralisée ne signifie pas que la donnée, la décision et son application se trouvent au même endroit.
- 07
« L'intégration est sans code »
L'interface permet parfois d'écrire une politique sans code. Cela ne supprime pas l'intégration applicative. Pour contrôler le téléchargement d'un document, l'application doit au minimum transmettre l'identité de Claire, l'identifiant du document, l'action demandée et le contexte utile ; elle doit ensuite appliquer la réponse. Si l'application historique ne possède aucun point d'extension, aucun proxy compatible et aucune API exploitable, l'élégance de l'éditeur de politiques ne suffit pas. Nous demandons comment l'action est interceptée, qui construit la requête d'autorisation, comment la ressource est identifiée, où le code d'intégration est installé, qui le maintient, ce qu'il faut modifier dans l'application, et si cette intégration relève réellement du standard produit. « Sans code » peut décrire l'écriture de la politique sans décrire le raccordement de l'application.
Aucune de ces questions ne cherche à piéger le fournisseur. Elles décrivent simplement ce qu'il faudra concevoir, câbler, maintenir et auditer une fois la démonstration terminée.
Le test Ariovis et le rôle de chaque composant
Un prospect ne demande pas naturellement « montrez-nous votre Policy Information Point ». Il exprime un besoin métier : un juriste ne doit pas pouvoir télécharger un document confidentiel en dehors des dossiers dont il a la charge. Nous transformons ce besoin en scénario de démonstration et nous demandons au fournisseur de dérouler la chaîne complète : l'identité de Claire, les attributs utilisés pour la décrire, le document concerné, la source de sa classification, le lien entre Claire et le dossier, la politique, la requête envoyée au moteur, la réponse obtenue, le temps de réponse, l'application effective du refus, la trace produite, et le comportement lorsque la source métier ou le moteur est indisponible. Nous demandons ensuite de modifier une donnée — retirer Claire du dossier, changer la classification, retirer temporairement l'accès au projet — et nous observons le délai nécessaire pour que la nouvelle situation soit réellement appliquée. Une démonstration PBAC ne doit pas seulement montrer une politique qui répond « autorisé » ou « refusé ». Elle doit montrer le chemin complet de la donnée jusqu'au contrôle.
- Netwrix Identity Manager
- Netwrix Identity Manager gouverne l'identité humaine dans la durée. Il consolide les données, pilote le cycle de vie, applique les règles d'attribution, traite les demandes d'accès, formalise les rôles et les patterns, provisionne, recertifie, remonte les écarts et conserve les preuves d'audit. Il peut déterminer que Claire appartient à la direction juridique et doit accéder à l'application documentaire. Il n'a pas vocation à ouvrir chaque document au moment où Claire clique sur « Télécharger ». Ce n'est ni sa mission, ni son rythme.
- Ping Identity, Microsoft Entra ID ou Keycloak
- Ces plateformes d'Access Management prennent en charge, selon le contexte, l'Authentication, le SSO, le MFA, la fédération, les sessions, les tokens et les Identity Claims. Elles établissent que la personne connectée est bien Claire et transmettent certaines informations sur son identité et son contexte de connexion. Un claim indiquant « département juridique » ne fournit pas à lui seul la classification du document, le propriétaire du dossier, l'action demandée ou la relation entre Claire et la ressource. Ce sont d'autres données, portées par d'autres sources.
- Axiomatics
- Axiomatics peut porter la décision d'autorisation fine. Il évalue une politique — RBAC, ABAC ou PBAC — à partir d'informations concernant Claire, la ressource, l'action et le contexte. La pertinence de la réponse dépend de la qualité des informations reçues, de leur fraîcheur, de la Latency de leur récupération et de l'intégration avec le Policy Enforcement Point. Le moteur de politique ne remplace ni les sources métier ni l'application. Il constitue un composant central de la chaîne, pas la chaîne entière.
- L'application métier
- L'application connaît souvent ce que les autres composants ignorent : l'objet consulté, le statut du dossier, l'action exacte, les relations métier, l'endroit où le refus doit être appliqué. Elle n'est donc pas une cible passive de l'autorisation ; elle est une partie essentielle du dispositif. Une architecture d'autorisation fine réussie reconnaît cette contribution, prévoit un point d'application clair dans l'application, et n'espère pas qu'un composant externe devine ce que seul le code applicatif sait.
- Le test représentatif
- Nous refusons de conclure sur une décision isolée montrée en démonstration. Nous demandons un test représentant une page ou une transaction réelle, avec la volumétrie et les Data Classifications attendues en production. C'est le seul moyen de mesurer la latence perçue, la charge sur le moteur, la fraîcheur effective de la donnée et le comportement en mode dégradé. Une matrice fonctionnelle peut indiquer que toutes les capacités sont couvertes ; seule une démonstration technique permet de vérifier qu'elles fonctionnent ensemble.
Une position simple, deux simplifications à refuser
Nous ne cherchons pas à construire la « Rolls-Royce » de l'IAM, et nous ne recommandons pas de multiplier les solutions sans nécessité. Pour de nombreux accès humains, une combinaison faite d'une gouvernance IGA, d'un annuaire, d'un Access Management et des contrôles applicatifs existants suffit à couvrir la demande. Une brique spécialisée d'autorisation fine devient pertinente lorsque les cas d'usage l'exigent réellement — décisions dépendant de la ressource, du contexte, d'une relation métier ou d'une donnée réglementaire.
Le pragmatisme consiste alors à refuser deux simplifications. La première consiste à supposer qu'un seul produit connaît spontanément toutes les données du système d'information ; il ne les connaît que si l'architecture les lui apporte. La seconde consiste à supposer qu'une politique affichée dans une belle interface constitue déjà un contrôle opérationnel ; ce n'en est un que lorsque la donnée métier, la décision et le point d'application se rejoignent, à temps, sur la ressource concernée.
Nous ne refusons pas les promesses ambitieuses. Nous demandons simplement à voir où se trouve la donnée, combien de temps prend la décision et comment son résultat est appliqué. Ces trois questions transforment une démonstration en projet.
Revenir à Claire, et à la chaîne qui la protège
Pour les identités humaines, le PBAC n'est pas nécessaire partout. Lorsqu'il l'est, il ne constitue pas une fonctionnalité isolée. Il constitue une chaîne composée d'une identité gouvernée, d'une authentification fiable, d'une ressource identifiable, d'une donnée métier accessible, d'une politique, d'un moteur de décision, d'un point d'application, d'une stratégie de cache et de révocation, d'un mode dégradé et d'une preuve d'audit.
Revenons à Claire une dernière fois. Netwrix Identity Manager gouverne son identité et son accès à l'application. La plateforme d'Access Management vérifie son identité et transmet ses claims. L'application identifie le document et l'action demandée. La source métier fournit la classification et la relation avec le dossier. Le moteur d'autorisation évalue la politique. Le point d'application fait respecter la réponse. La trace permet, plus tard, d'expliquer la décision. Aucun composant ne réalise seul l'ensemble de la chaîne.
Lorsque nous évaluons une promesse d'autorisation fine, nous ne demandons pas seulement si le produit sait répondre « autorisé » ou « refusé ». Nous vérifions ce qu'il sait réellement de la ressource, le temps nécessaire pour décider et ce qui se passe lorsque la réponse n'arrive pas.