RBAC vs ABAC : différences et choix en 2026

RBAC (Role-Based Access Control) et ABAC (Attribute-Based Access Control) sont les deux modèles d'autorisation dominants dans les systèmes IAM en 2026. RBAC, formalisé par NIST RBAC standard ANSI INCITS 359-2012, attribue les permissions à des rôles intermédiaires : un utilisateur reçoit des rôles, chaque rôle porte des permissions. Modèle simple, statique, prévisible, adopté massivement (Active Directory, AWS IAM, Kubernetes, Keycloak, GitHub teams). ABAC, formalisé par NIST SP 800-162 (janvier 2014), évalue dynamiquement les autorisations via des policies qui combinent les attributs du sujet (utilisateur, rôles, MFA récent), de la ressource (type, classification, propriétaire), de l'action (read, write, delete) et de l'environnement (heure, IP source, géolocalisation). Modèle flexible, expressif, plus complexe à raisonner. En 2026, le pattern dominant n'est plus le choix exclusif RBAC ou ABAC mais l'hybride : RBAC comme socle simple, ABAC comme couche contextuelle additionnelle, ReBAC (Relationship-Based, popularisé par le paper Google Zanzibar 2019) pour les SaaS multi-tenant complexes. Cet article détaille les deux modèles avec exemples concrets (AWS IAM, Kubernetes RBAC, Keycloak Authorization Services), les outils dominants (OPA Rego, Cedar AWS, XACML 3.0), les implémentations ReBAC (OpenFGA, SpiceDB, Permify), les critères de décision pragmatiques et le pattern hybride recommandé.

RBAC : définition formelle et mécanique

Role-Based Access Control est formalisé par le standard ANSI INCITS 359-2012 (révision du NIST RBAC standard 1992). Le modèle organise les autorisations autour de quatre éléments.

Mécanique de base

Le flow type :

1. Administrateur définit les permissions atomiques (par exemple : read:product, write:product, delete:order).
2. Administrateur regroupe permissions en rôles (par exemple : product-viewer = [read:product], product-manager = [read:product, write:product]).
3. Administrateur attribue rôles aux utilisateurs (par exemple : Alice → product-manager, Bob → product-viewer).
4. Au moment d'une action, le système vérifie : l'utilisateur a-t-il un rôle qui contient la permission requise ?

Hiérarchie de rôles (RBAC1)

Le modèle RBAC1 introduit l'héritage : un rôle peut hériter d'un autre. Exemple :

Role: admin
  inherits: manager
  inherits: viewer
  permissions: [+ delete:everything]
 
Role: manager
  inherits: viewer
  permissions: [+ write:product, write:order]
 
Role: viewer
  permissions: [read:product, read:order]

Avantages : factorise les permissions communes, simplifie la gestion. Inconvénient : les hiérarchies profondes deviennent difficiles à raisonner.

Constraints (RBAC2)

Le modèle RBAC2 ajoute des contraintes :

• Separation of Duty : un utilisateur ne peut pas avoir simultanément certains rôles incompatibles (par exemple accountant et auditor).
• Cardinality : limite du nombre d'utilisateurs ayant un rôle critique.
• Temporal constraints : un rôle n'est actif qu'à certaines heures.

Exemples concrets

AWS IAM Roles

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::company-data-bucket/*",
        "arn:aws:s3:::company-data-bucket"
      ]
    }
  ]
}

Ce policy AWS définit les permissions d'un Role IAM : lecture sur un bucket S3 spécifique. Les utilisateurs qui assument ce rôle héritent de ces permissions.

Kubernetes RBAC

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
 
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Le Role pod-reader permet de lire les Pods dans le namespace production. Le RoleBinding attache ce Role à l'utilisateur Alice.

Forces et limites RBAC

Forces :

• Simple à comprendre, raisonnable, auditable.
• Bien outillé : tous les IdP majeurs (AWS, Azure, GCP, Keycloak, Okta) supportent RBAC nativement.
• Performant : décision d'autorisation rapide (lookup table).
• Aligné avec les structures organisationnelles humaines (rôles correspondent aux fonctions métier).

Limites :

• Explosion combinatoire des rôles : organisation complexe peut nécessiter des centaines de rôles.
• Pas de prise en compte du contexte (heure, IP, MFA récent).
• Difficile pour les permissions temporaires ou exceptionnelles.
• Ne gère pas naturellement les permissions hiérarchiques sur ressources (org > project > document).

ABAC : définition formelle et mécanique

Attribute-Based Access Control est formalisé par NIST SP 800-162 (janvier 2014, mis à jour en 2019). Le modèle évalue les autorisations dynamiquement via des policies qui combinent attributs.

Les 4 catégories d'attributs

Architecture conceptuelle ABAC

┌──────────────────────────────────────────────────┐
│ POLICY DECISION POINT (PDP)                      │
│ Évalue les policies contre la requête             │
│                                                  │
│ Inputs:                                          │
│ - Subject attributes                             │
│ - Resource attributes                            │
│ - Action                                         │
│ - Environment attributes                         │
│                                                  │
│ Output: PERMIT / DENY / NOT_APPLICABLE          │
└──────────────────────────────────────────────────┘
       ▲                            │
       │ Decision request           │ Decision
       │                            ▼
┌──────────────────────────────────────────────────┐
│ POLICY ENFORCEMENT POINT (PEP)                   │
│ Application qui demande l'autorisation           │
│ Et applique la décision (allow ou block)         │
└──────────────────────────────────────────────────┘

Exemple de policy ABAC en Rego (OPA)

package authz
 
default allow := false
 
# Permettre lecture document si :
# - Utilisateur a le rôle 'reader' OU est propriétaire du document
# - Document n'est pas classifié 'restricted' (sauf si user a clearance)
# - Requête vient depuis IP corporate (pas Internet brut)
# - MFA récent (moins de 4 heures)
 
allow if {
    input.action == "read"
    input.resource.type == "document"
    user_can_read
    document_accessible
    request_from_corporate_network
    mfa_recent
}
 
user_can_read if {
    input.subject.roles[_] == "reader"
}
 
user_can_read if {
    input.resource.owner == input.subject.id
}
 
document_accessible if {
    input.resource.classification != "restricted"
}
 
document_accessible if {
    input.resource.classification == "restricted"
    input.subject.clearance == "secret"
}
 
request_from_corporate_network if {
    net.cidr_contains("10.0.0.0/8", input.environment.source_ip)
}
 
mfa_recent if {
    time.now_ns() - input.subject.mfa_timestamp_ns < 14400000000000
}

Exemple de policy ABAC en Cedar (AWS)

permit (
    principal in Group::"Engineering",
    action == Action::"viewLogs",
    resource is LogStream
)
when {
    resource.environment == "production" &&
    principal.mfaUsed == true &&
    context.requestTime.hour() >= 8 &&
    context.requestTime.hour() <= 20
};

Exemple AWS IAM avec Conditions (ABAC hybride)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::company-data/*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "DateGreaterThan": {
          "aws:MultiFactorAuthAge": "0"
        },
        "NumericLessThan": {
          "aws:MultiFactorAuthAge": "14400"
        },
        "IpAddress": {
          "aws:SourceIp": ["10.0.0.0/8"]
        },
        "StringEquals": {
          "aws:RequestTag/Environment": "${aws:PrincipalTag/Department}"
        }
      }
    }
  ]
}

Forces et limites ABAC

Forces :

• Expressif : modélise des règles métier complexes sans multiplier les rôles.
• Contextuel : prise en compte heure, IP, MFA, classification ressource.
• Centralisable : politique externalisée du code applicatif (PDP séparé).
• Fine-grained : décisions par requête plutôt que par session.

Limites :

• Complexité de raisonnement : impossible d'auditer mentalement quelles permissions un utilisateur a sans simulation.
• Performance : évaluation policy par requête (vs lookup RBAC).
• Courbe d'apprentissage du langage de policy (Rego, XACML, Cedar).
• Tooling et debugging plus complexes que RBAC.

Comparaison côte à côte

Synthèse des différences clés.

ReBAC : le troisième modèle moderne

Relationship-Based Access Control (ReBAC) modélise les autorisations comme des relations entre objets, formalisé par le paper Google Zanzibar publié à USENIX en 2019.

Concept fondamental

Plutôt que "Alice a le rôle reader sur le document X", ReBAC modélise "Alice est member of org Y, qui owns project Z, qui contains document X". L'autorisation se calcule en remontant les relations.

Implémentations open source 2026

Exemple OpenFGA

Définition d'un modèle :

model
  schema 1.1
 
type user
 
type document
  relations
    define owner: [user]
    define editor: [user] or owner
    define viewer: [user] or editor
 
type folder
  relations
    define parent: [folder]
    define viewer: [user] or viewer from parent

Une permission "viewer sur document X" peut être héritée d'un viewer sur le folder parent. Cette modélisation est impossible en RBAC sans dupliquer massivement les rôles.

Cas d'usage ReBAC

• SaaS multi-tenant complexe : Notion, GitHub, Carta, Asana ont tous des modèles d'autorisation hiérarchiques (organization → workspace → project → document) où ReBAC excelle.
• Document collaboration : Google Docs, Dropbox.
• Healthcare : permissions sur dossiers patients via hiérarchie médicale.
• Identity governance complexe : qui peut approuver les accès de qui, basé sur la hiérarchie organisationnelle.

Quand utiliser quoi : critères de décision

Trois axes de décision pragmatiques.

Axe 1 — Nombre de rôles requis

Axe 2 — Importance du contexte

Si la décision d'autorisation dépend de :

• Uniquement qui (user) et quoi (resource) = RBAC suffit.
• Quand (heure, MFA récent), où (IP, géo), comment (device) = ABAC nécessaire.
• Relations entre ressources hiérarchiques = ReBAC adapté.

Axe 3 — Complexité du modèle de données

Pattern hybride dominant 2026

L'écrasante majorité des systèmes en production combinent les modèles plutôt que choisir exclusivement.

Pattern 1 — RBAC + ABAC (le plus fréquent)

RBAC pour la base, ABAC pour la couche contextuelle. Exemple AWS IAM :

• Roles IAM (RBAC) : developer, admin, read-only.
• Conditions IAM (ABAC) : MFA required, IP corporate only, requested tag matches user tag.

Decision = (User has matching Role) AND (All Conditions evaluate True)

Pattern 2 — RBAC + Admission Controllers

Kubernetes 2026 typique :

• RBAC natif pour les permissions de base (qui peut create/get/list les Pods).
• Admission Controllers (OPA Gatekeeper, Kyverno, ValidatingAdmissionPolicy) pour ABAC : refuser les Pods non conformes (privileged, hostPath, image non signée).

Pattern 3 — RBAC global + ReBAC granulaire

SaaS moderne type Notion :

• RBAC pour les permissions globales (admin organisation, billing).
• ReBAC pour les permissions granulaires sur le contenu (qui peut éditer ce document précis).

Pattern 4 — Externaliser la décision via OPA

Architecture moderne où l'application délègue toutes les décisions d'autorisation à OPA (sidecar ou central) :

Application (PEP) ──── Decision request ────→ OPA (PDP)
                ←──── Allow / Deny ────────────

Avantages : politique versionnée en Git, modification sans redéploiement de l'application, auditabilité, cohérence cross-services.

# Exemple service-mesh policy avec OPA
package envoy.authz
 
default allow := false
 
allow if {
    input.attributes.request.http.method == "GET"
    input.parsed_path[0] == "api"
    user_can_read[input.parsed_path[1]]
}
 
user_can_read[resource] if {
    input.attributes.metadataContext.filterMetadata["envoy.filters.http.jwt_authn"]
        .verified_jwt.payload.roles[_] == sprintf("%s-reader", [resource])
}

Outils et standards 2026

Vue récapitulative de l'écosystème.

Pièges fréquents en implémentation

Cinq écueils observés sur les projets RBAC/ABAC en France 2024-2026.

Sur-modeling RBAC. Création de centaines de rôles ultra-spécifiques pour chaque combinaison cas d'usage. Solution : revoir périodiquement les rôles, fusionner les rôles à faible cardinalité, basculer en hybride ABAC pour les besoins contextuels.

Couplage policy / code applicatif. Politiques codées en dur dans le code Java/Python/Go. Modification = redéploiement. Solution : externaliser via OPA ou Cedar, policy as code versionnée Git séparément.

Performance non testée. Migration vers ABAC sans benchmarker la latence d'évaluation. Cas extrême : OPA central avec 10 000+ requêtes/seconde devient goulot. Solution : OPA en sidecar, cache local des décisions répétitives, mesure systématique de la latence p99 d'autorisation.

Audit oublié. Pas de logs des décisions d'autorisation (allow / deny avec raison). Empêche analyse forensique post-incident. Solution : audit logging activé sur chaque décision PDP, ingestion SIEM.

Pas de séparation des duties. Mêmes utilisateurs peuvent créer rôles et s'attribuer rôles, ouvrant la voie à privilege escalation. Solution : Separation of Duty (SoD) explicite dans les policies, peer review obligatoire pour les modifications de policies critiques.

Points clés à retenir

• RBAC attribue les permissions via rôles statiques (User → Role → Permission), formalisé NIST ANSI INCITS 359-2012. Simple, rapide, universellement supporté. Limite : explosion combinatoire des rôles, pas de contexte.
• ABAC évalue dynamiquement les autorisations via policies combinant attributs (Subject, Resource, Action, Environment), formalisé NIST SP 800-162. Expressif, contextuel. Limite : complexité de raisonnement.
• ReBAC (Google Zanzibar 2019) modélise les permissions comme relations entre objets. Adapté aux SaaS multi-tenant avec hiérarchies complexes. OpenFGA et SpiceDB sont les implémentations open source de référence.
• Le pattern dominant 2026 est l'hybride : RBAC comme socle + ABAC pour la couche contextuelle (AWS IAM Conditions, K8s admission controllers). ReBAC en complément pour SaaS multi-tenant.
• OPA Rego (CNCF Graduated) est l'outil ABAC dominant en 2026. Cedar (AWS, 2023) gagne en cloud-native AWS. XACML reste niche legacy. Choisir selon contexte et compétences équipe.

Pour aller plus loin

• Qu'est-ce que l'IAM - définition fondamentale et concepts de base IAM.
• Qu'est-ce que Keycloak - implémentation concrète RBAC + ABAC dans un IdP open source.
• Pourquoi l'identité est centrale en cybersécurité - pillar IAM moderne.
• IAM expliqué simplement - perspective cloud-native IAM.