Big ACL pour les architectes
Cette page explique comment Big ACL s'intègre dans une architecture moderne et comment il répond aux préoccupations architecturales telles que la cohérence, l'analyse d'impact et la maintenabilité à long terme.
Les architectures d'autorisation modernes fonctionnent mieux lorsque les responsabilités sont clairement séparées. Big ACL se concentre sur le Point d'Administration des Politiques (PAP), tout en s'intégrant avec les Points de Décision des Politiques (PDP) et en laissant les Points d'Application des Politiques (PEP) au sein des applications.
Le PAP est l'endroit où les politiques sont conçues, modélisées, revues, versionnées et déployées. C'est le rôle de Big ACL. Il encode les concepts métier tels que les ressources, les rôles, les relations, la propriété et les contraintes de manière explicite et analysable.
En pratique, cela signifie que les choix de modélisation résident en un seul endroit au lieu d'être dispersés entre les services, les fichiers de configuration et les scripts personnalisés. Les politiques peuvent être validées, testées et comparées avant d'atteindre un moteur d'exécution.
Le PDP évalue les politiques en temps réel. Les exemples typiques incluent Rego / Open Policy Agent, Cedar / Amazon Verified Permissions, ou des moteurs de décision personnalisés. Un PDP répond uniquement à une question précise : étant donné un principal, une action, une ressource et un contexte, est-ce autorisé ?
Big ACL génère des politiques pour ces moteurs, de sorte que la logique de décision est cohérente entre les différentes implémentations de PDP.
Le PEP réside dans chaque application, passerelle API ou service. Il extrait le contexte d'identité des tokens ou sessions, construit une requête d'autorisation, appelle le PDP et applique la décision.
Big ACL ne remplace pas les PEP. Au contraire, il garantit que tous les PEP communiquent avec des PDP qui partagent la même sémantique sous-jacente, évitant ainsi une logique métier dupliquée et incohérente dans chaque application.
Les référentiels d'architecture d'entreprise contiennent des données directement pertinentes pour l'autorisation : applications, propriété, domaines, capacités et dépendances. Au lieu d'être une couche de documentation externe, ces informations peuvent alimenter le modèle de politiques.
Big ACL peut consommer des données provenant d'outils d'architecture pour ancrer les politiques dans les systèmes et équipes réels. Cela rend les règles plus stables que les définitions de rôles ad-hoc par application.
Exemples de règles pilotées par l'architecture :
Lorsque les politiques sont ancrées dans les données architecturales, les changements de propriété ou de périmètres systèmes peuvent être reflétés systématiquement dans les règles d'autorisation, au lieu de compter sur un nettoyage manuel dans chaque application.
Les plateformes IGA et les fournisseurs d'identité gèrent les identités, les rôles, les droits et les événements de cycle de vie. Big ACL n'essaie pas de remplacer ces systèmes. Au contraire, il consomme leurs données en entrée du modèle de politiques.
Cela permet aux architectes de maintenir une séparation claire des responsabilités : l'IGA gère qui existe et quels rôles de haut niveau ils ont, tandis que Big ACL définit comment ces rôles se traduisent en permissions concrètes sur les ressources, en fonction de l'architecture et des limites de domaines.
Le bénéfice est une vision plus cohérente de « qui peut faire quoi », combinant le cycle de vie des identités, la propriété des applications et les règles d'autorisation en un modèle unique et cohérent.
Les architectes ont souvent besoin de comprendre l'impact des changements avant leur déploiement. Déplacer un service, changer la propriété, introduire un nouveau PDP ou refactorer une limite de domaine ont tous des conséquences sur les accès.
Parce que Big ACL stocke les politiques comme des artefacts structurés et versionnés, il devient possible de comparer les versions, d'exécuter des vérifications et d'attacher les politiques aux applications, domaines et capacités. Cela fait de l'analyse d'impact une étape reproductible plutôt qu'une discussion informelle.
Questions typiques :
Avoir un modèle de politiques unique rend ces questions résolvables avec des données, pas des suppositions.