ABAC (Attribute-Based Access Control)

ABAC vs RBAC — complémentarité et limites

RBAC et ABAC sont complémentaires plutôt qu'opposés. RBAC est simple à implémenter et à comprendre (les utilisateurs comprennent intuitivement les rôles) et est adapté aux décisions d'accès stables et peu contextuelles. ABAC est plus complexe mais permet des politiques que RBAC ne peut pas exprimer : accès conditionnel selon l'heure, la localisation, l'état de sécurité de l'appareil, le niveau de classification des données. En pratique, les systèmes d'entreprise combinent souvent les deux : RBAC pour définir les droits de base selon le poste, et ABAC pour les conditions contextuelles supplémentaires (restriction horaire, restriction géographique, exigence de MFA pour les ressources sensibles). Azure AD Conditional Access est un exemple d'ABAC en pratique : les politiques d'accès évaluent des attributs multiples (identité, groupe, risque utilisateur, conformité appareil, localisation) pour autoriser ou refuser l'accès.

XACML — standard des politiques ABAC

XACML (eXtensible Access Control Markup Language) est le standard OASIS pour définir, partager, et évaluer les politiques ABAC en XML. L'architecture XACML comprend : PAP (Policy Administration Point — où les politiques sont créées), PDP (Policy Decision Point — où les politiques sont évaluées), PEP (Policy Enforcement Point — où les décisions sont appliquées), PIP (Policy Information Point — source des attributs). XACML est verbeux en XML — ALFA (Abbreviated Language for Authorization) est une syntaxe plus lisible qui compile vers XACML. Axiomatics, Otka, et plusieurs plateformes IAM enterprise supportent XACML. Pour les environnements cloud-native, OPA (Open Policy Agent) avec le langage Rego est une alternative moderne plus légère qui implémente des principes ABAC sans la complexité XACML.

OPA (Open Policy Agent) — ABAC cloud-native

OPA (Open Policy Agent) est un moteur de politiques open-source adopté dans les environnements cloud-native pour implémenter ABAC. Les politiques OPA sont écrites en Rego (langage déclaratif) et évaluées par le daemon OPA, interrogeable via une API HTTP. OPA est intégré dans Kubernetes (via GatekeeperOPA pour les politiques d'admission), Envoy (sidecar pour les politiques réseau des microservices), Terraform (Conftest pour valider les configurations), et les pipelines CI/CD. Exemple de politique Rego : `allow { input.user.department == "finance" input.resource.classification == "confidential" time.clock(input.env.timestamp)[0] >= 8 time.clock(input.env.timestamp)[0] <= 18 }` — cette politique autorise l'accès si le département est Finance, la classification Confidentiel, et l'heure entre 8h et 18h. OPA est le standard de facto pour l'ABAC dans les environnements Kubernetes/microservices.