PBAC (Policy-Based Access Control)

general

Définition

Le PBAC (Policy-Based Access Control — Contrôle d'Accès Basé sur les Politiques) est un modèle de contrôle d'accès dans lequel les décisions d'autorisation sont prises en évaluant des politiques centralisées qui combinent des règles basées sur les rôles, les attributs, et le contexte. Le PBAC est parfois considéré comme une évolution d'ABAC (Attribute-Based Access Control), avec une emphase supplémentaire sur la centralisation et la gestion des politiques. Le PBAC formalise la séparation entre la définition des politiques et leur évaluation. Les politiques sont définies centralement par les équipes sécurité et conformité, stockées dans un référentiel de politiques (Policy Store), et évaluées par un moteur de politiques (Policy Decision Point — PDP) à chaque demande d'accès. Les applications ne gèrent plus leur logique d'autorisation en interne — elles délèguent au PDP qui retourne une décision "Permit" ou "Deny". Le PBAC est particulièrement adapté aux environnements complexes avec des exigences de conformité strictes (SOX, RGPD, HIPAA) où les politiques d'accès doivent être auditables, cohérentes, et gérables à grande échelle. Plutôt que d'avoir des règles d'accès dispersées dans des dizaines d'applications, un PBAC centralise toutes les règles en un endroit unique. Les composants d'une architecture PBAC incluent : le PAP (Policy Administration Point — interface d'administration des politiques), le PDP (Policy Decision Point — moteur d'évaluation), le PEP (Policy Enforcement Point — point d'application dans l'application ou le proxy), et le PIP (Policy Information Point — source des attributs comme LDAP, CMDB, IAM). OPA (Open Policy Agent) avec le langage Rego est l'implémentation PBAC open-source la plus populaire dans les environnements cloud-native et Kubernetes.

OPA en pratique — Rego et intégration Kubernetes

OPA (Open Policy Agent) est le moteur de politiques open-source de facto pour les environnements cloud-native. Les politiques OPA sont écrites en Rego, un langage déclaratif basé sur Datalog. OPA peut s'intégrer dans Kubernetes via Gatekeeper (webhook d'admission qui valide toutes les ressources Kubernetes contre les politiques OPA avant leur création), dans Envoy (sidecar proxy qui évalue les politiques d'autorisation pour chaque requête HTTP entre microservices), et dans les pipelines CI/CD via Conftest (validate les configurations Terraform, Helm, Dockerfile). Un exemple de politique Rego pour Kubernetes : forcer que tous les containers aient des resource limits définies, interdire les pods s'exécutant en root, ou interdire les images Docker sans tag de version explicite (pas de :latest).

PBAC et conformité — auditabilité centralisée

L'un des avantages majeurs du PBAC pour la conformité est la centralisation des politiques. Lors d'un audit ISO 27001 ou SOC 2, les auditeurs demandent de démontrer que les droits d'accès sont contrôlés et cohérents. Avec un PBAC centralisé, une seule interface montre toutes les politiques en vigueur — bien plus facile à auditer que des règles d'accès dispersées dans 50 applications différentes. La traçabilité des décisions (logs du PDP enregistrant chaque décision Permit/Deny avec les attributs évalués) fournit un audit trail exhaustif. Les changements de politique sont versionnés et approuvés (GitOps pour les politiques OPA dans Kubernetes). Cette centralisation est particulièrement valorisée par les certifications de sécurité et les audits réglementaires.

PBAC vs RBAC vs ABAC — quel modèle choisir

Le choix du modèle de contrôle d'accès dépend de la complexité des besoins. RBAC (Role-Based) : simple à implémenter, bien compris, adapté aux décisions stables basées uniquement sur le rôle. Limite : impossibilité d'exprimer des conditions contextuelles. ABAC (Attribute-Based) : plus flexible, permet des conditions contextuelles, mais plus complexe à gérer. PBAC (Policy-Based) : le plus flexible, centralisation maximale, mais requiert une infrastructure dédiée (PDP). En pratique, les organisations utilisent souvent une combinaison : RBAC pour les droits de base (décision de provisioning des accès), ABAC/PBAC pour les conditions contextuelles supplémentaires (évaluation à chaque accès via OPA ou Azure Conditional Access). La migration progressive de RBAC vers PBAC se justifie quand la complexité des règles d'autorisation dépasse ce que RBAC peut exprimer proprement.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis