RBAC, ABAC, PBAC : modèles de contrôle d’accès comparés

Reprenez le contrôle de vos identités

Audit IAM, Zero Trust, MFA, PAM — réduction de la surface d'attaque identitaire.

Audit IAM — Devis gratuit [email protected]

Implémentation Pratique du RBAC dans les Systèmes d'Information d'Entreprise

Le contrôle d'accès basé sur les rôles (RBAC) est le modèle le plus répandu dans les systèmes d'information d'entreprise, notamment dans les annuaires Active Directory, les applications web métier et les plateformes cloud. Sa mise en oeuvre efficace repose sur une conception rigoureuse de la hiérarchie des rôles, en évitant les deux écueils classiques : la prolifération de rôles (role explosion) qui crée des centaines de rôles difficiles à maintenir, et les rôles trop génériques qui accordent des permissions excessives par rapport aux besoins réels des utilisateurs.

La démarche de conception RBAC s'articule en quatre étapes :

• Inventaire des fonctions métier : identifier toutes les actions que les utilisateurs doivent pouvoir effectuer dans le système, regroupées par domaine fonctionnel (facturation, support, administration, etc.) via des interviews avec les responsables métier
• Définition des rôles minimaux : créer les rôles en partant des profils utilisateurs réels plutôt que des permissions techniques, en appliquant le principe du moindre privilège : chaque rôle ne doit inclure que les permissions strictement nécessaires aux responsabilités associées
• Hiérarchisation et héritage : structurer les rôles en hiérarchie pour éviter la duplication, où un rôle Senior hérite des permissions d'un rôle Junior et ajoute des permissions supplémentaires liées à ses responsabilités spécifiques
• Séparation des duties (SoD) : identifier et documenter les contraintes de séparation des tâches empêchant la concentration de permissions incompatibles sur un même utilisateur, comme les rôles de création et de validation de paiement dans un système financier

Dans Kubernetes, le RBAC est le mécanisme central de contrôle d'accès au plan de contrôle et aux ressources du cluster. Une ClusterRole type pour un auditeur de sécurité en lecture seule :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: security-auditor
rules:
- apiGroups: [""]
  resources: ["pods", "services", "secrets", "configmaps", "namespaces"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "daemonsets", "statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
  resources: ["networkpolicies", "ingresses"]
  verbs: ["get", "list", "watch"]

ABAC et PBAC : Implémentation et Comparaison avec RBAC

Le contrôle d'accès basé sur les attributs (ABAC) surmonte les limitations du RBAC en introduisant des politiques d'accès qui évaluent dynamiquement des attributs du sujet (utilisateur), de la ressource, de l'action et de l'environnement (contexte) pour prendre une décision d'autorisation. Cette flexibilité permet d'exprimer des politiques complexes impossibles à modéliser avec le RBAC classique, comme l'accès aux données patient uniquement pour les médecins du même établissement que le patient, pendant les heures ouvrées, depuis des terminaux enregistrés dans l'annuaire de l'hôpital.

XACML (eXtensible Access Control Markup Language) est le standard de l'industrie pour l'expression de politiques ABAC. Un Policy Decision Point (PDP) évalue les requêtes d'accès contre les politiques définies, en interrogeant un Policy Information Point (PIP) pour collecter les attributs nécessaires. La réponse est Permit, Deny, Indeterminate ou NotApplicable selon les politiques applicables. Des solutions open-source comme AuthzForce ou OPA (Open Policy Agent) implémentent ce modèle avec des langages de politique plus modernes et des APIs REST adaptées aux architectures microservices.

OPA avec le langage Rego est particulièrement adapté pour implémenter des politiques ABAC dans les environnements cloud-native, Kubernetes et CI/CD :

package authz
default allow = false
allow {
  input.method == "GET"
  input.path == ["api", "patients", input.user.patient_id]
  input.user.role == "patient"
}
allow {
  input.method == "GET"
  input.user.role == "physician"
  input.user.hospital_id == data.patients[input.path[2]].hospital_id
  is_business_hours
}
is_business_hours {
  hour := time.clock(time.now_ns())[0]
  hour >= 8; hour <= 18
}

Le PBAC (Policy-Based Access Control) est souvent utilisé de façon interchangeable avec ABAC, mais se distingue par son focus sur des politiques d'entreprise de haut niveau traduites en règles d'accès techniques, typiquement utilisé dans les solutions PAM (Privileged Access Management) comme CyberArk ou BeyondTrust pour définir des politiques d'accès aux systèmes privilégiés. La sélection entre RBAC, ABAC et PBAC dépend de la complexité des exigences d'autorisation, du volume d'utilisateurs et de ressources à gérer, et des capacités techniques de l'équipe chargée de la maintenance opérationnelle du système de contrôle d'accès.

Audit et Gouvernance des Modèles de Contrôle d'Accès

Quel que soit le modèle de contrôle d'accès retenu (RBAC, ABAC ou PBAC), sa gouvernance dans le temps est aussi critique que sa conception initiale. Les systèmes de contrôle d'accès dérivent inévitablement vers un état d'accès excessifs si des processus de révision réguliers ne sont pas mis en place : les permissions accordées pour un projet temporaire ne sont jamais révoquées, les employés changent de poste sans que leurs anciens accès soient supprimés, et les rôles s'accumulent par commodité. Cette dérive, appelée privilege creep, crée une surface d'attaque croissante qui peut être exploitée par un attaquant compromettant un compte utilisateur légitime.

Les processus de gouvernance IAM indispensables pour maintenir l'intégrité du modèle de contrôle d'accès dans le temps :

• User Access Reviews (UAR) trimestriels : revue formelle de tous les accès accordés, validée par les managers directs pour confirmer que chaque utilisateur conserve des besoins légitimes pour chaque rôle ou permission, avec révocation automatique à défaut de validation dans le délai imparti
• Role Mining automatisé : analyser les logs d'utilisation réelle des permissions accordées pour identifier les permissions jamais utilisées qui peuvent être retirées sans impact opérationnel, et les patterns d'usage qui suggèrent de nouveaux rôles plus précis
• Détection des conflits de SoD : outils automatisés (SAP GRC, Oracle Identity Governance, SailPoint IQ) qui détectent en temps réel les accumulations de permissions violant les règles de séparation des duties définies, avant que ces violations ne créent des risques de fraude ou de non-conformité
• Just-in-Time (JIT) Access pour les accès privilégiés : plutôt que d'accorder des droits élevés permanents, les accès privilégiés sont accordés temporairement (15 minutes à 8 heures) sur demande approuvée, réduisant drastiquement la fenêtre d'exposition en cas de compromission d'un compte à privilèges
• Certification des rôles techniques : revue annuelle de la définition de chaque rôle par le propriétaire métier du domaine correspondant, pour s'assurer que les permissions associées restent alignées sur les besoins réels et ne se sont pas étendues au-delà du périmètre initialement prévu

Les référentiels de sécurité et de conformité exigent explicitement des contrôles de gouvernance des accès : ISO 27001:2022 via le contrôle A.8.2 (Privileged Access Rights), SOC 2 Type II via le critère CC6.1 (Logical Access Controls), PCI-DSS 4.0 via les exigences 7 et 8 sur la gestion des accès, et RGPD via l'Article 25 (Privacy by Design) et l'Article 32 (Mesures de sécurité techniques). La documentation de ces contrôles de gouvernance constitue une preuve de conformité directement exploitable lors des audits annuels requis par ces référentiels, justifiant l'investissement dans des outils d'automatisation qui génèrent automatiquement les rapports d'audit nécessaires.

Intégration des Modèles de Contrôle d'Accès dans les Architectures Zero Trust

Le modèle Zero Trust, qui postule qu'aucune connexion n'est intrinsèquement digne de confiance quelle que soit son origine (réseau interne ou externe), s'appuie fondamentalement sur des mécanismes robustes de contrôle d'accès pour chaque ressource et chaque transaction. RBAC, ABAC et PBAC constituent les briques de base du pilier "autorisation" du Zero Trust, complémentaires à l'authentification forte (MFA, FIDO2) et à la vérification continue de la posture de sécurité du dispositif accédant. Dans une architecture Zero Trust mature, chaque requête d'accès est évaluée en temps réel par un Policy Decision Point qui prend en compte l'identité de l'utilisateur (rôle RBAC), les attributs contextuels (heure, localisation, posture du dispositif) et les politiques de l'organisation (PBAC) pour décider dynamiquement de l'autorisation ou du refus, sans présumer de la légitimité de la requête sur la base de sa provenance réseau seule. Cette intégration des modèles de contrôle d'accès dans une architecture Zero Trust aboutit au modèle le plus robuste disponible pour sécuriser les ressources d'une organisation distribuée face aux menaces modernes.

L'évolution vers des architectures multi-cloud et edge computing nécessite une adaptation des modèles de contrôle d'accès pour couvrir des ressources distribuées sur des infrastructures hétérogènes. Les standards émergents comme SPIFFE/SPIRE (Secure Production Identity Framework For Everyone) permettent d'étendre les modèles RBAC et ABAC aux identités de workloads (services, conteneurs, fonctions serverless) plutôt qu'aux seules identités humaines, comblant une lacune critique des modèles de contrôle d'accès traditionnels dans les environnements cloud-native où la majorité des accès aux ressources sont effectués par des services automatisés plutôt que par des utilisateurs humains connectés à une console d'administration.