RBAC, ABAC et politiques d'autorisation

L’autorisation détermine ce qu’un utilisateur authentifié peut faire. Trois modèles dominent : RBAC (rôles), ABAC (attributs contextuels) et ReBAC (relations entre objets). Le bon choix dépend de votre cas : RBAC suffit pour “admin/éditeur/lecteur”, ABAC permet des règles dynamiques (“accès si même département + heures ouvrées”), ReBAC gère les partages complexes (“éditeurs de ce document”).

Ce que vous allez apprendre

Ce guide vous donne les clés pour modéliser l’autorisation dans vos systèmes. À la fin, vous saurez :

• Distinguer RBAC, ABAC et ReBAC — et quand utiliser chaque modèle
• Concevoir une architecture PDP/PEP découplée
• Écrire des politiques testables avec Policy-as-Code
• Éviter les erreurs classiques (explosion de rôles, ABAC trop complexe)

Prérequis : avoir lu Les bases de l’IAM et OAuth 2.x.

Authentification vs Autorisation

Ces deux concepts sont souvent confondus. Pourtant, ils répondent à des questions différentes et interviennent à des moments distincts du flux de sécurité.

Étape	Question	Résultat
Authentification (AuthN)	Qui es-tu ?	Identité vérifiée
Autorisation (AuthZ)	Que peux-tu faire ?	Permissions accordées ou refusées

Glissez pour voir

L’authentification vient avant l’autorisation. Vous ne pouvez pas autoriser quelqu’un que vous ne connaissez pas.

Les modèles d’autorisation

RBAC : Role-Based Access Control

Le RBAC attribue des permissions via des rôles.

Utilisateur  →  Rôle  →  Permissions
                  │
                  ├── "admin"     → [read, write, delete]
                  ├── "editor"    → [read, write]
                  └── "viewer"    → [read]

Avantages :

• Simple à comprendre et implémenter
• Facile à auditer (qui a quel rôle ?)
• Bien supporté par tous les systèmes

Inconvénients :

• Explosion de rôles : admin-us, admin-eu, admin-project-x, admin-project-y-read-only…
• Pas de contexte dynamique (heure, localisation, sensibilité des données)

Quand utiliser RBAC

Situation	RBAC adapté ?
Permissions statiques par fonction métier	✅ Oui
Équipe < 100 personnes	✅ Oui
Multi-tenant avec isolation stricte	⚠️ Peut marcher
Accès contextuel (heure, geo, risque)	❌ Non

Glissez pour voir

ABAC : Attribute-Based Access Control

Le ABAC décide selon des attributs :

Type d’attribut	Exemples
Sujet	département, niveau de clearance, fonction
Ressource	classification, propriétaire, date création
Action	read, write, delete, approve
Contexte	heure, IP, géolocalisation, device

Glissez pour voir

Exemple de règle ABAC :

ALLOW read document
WHERE subject.department == resource.department
AND   resource.classification <= subject.clearance
AND   context.time BETWEEN 08:00 AND 18:00
AND   context.geo IN ['FR', 'DE', 'ES']

Avantages :

• Très flexible, gère les cas complexes
• Pas d’explosion de rôles
• Décisions contextuelles

Inconvénients :

• Plus complexe à implémenter et débugger
• Collecte des attributs peut être coûteuse
• Difficile à auditer (“pourquoi cet accès ?”)

ReBAC : Relationship-Based Access Control

Le ReBAC modélise les permissions comme des relations entre objets.

Règle : “Les viewers d’un dossier peuvent lire les documents qu’il contient”

Les systèmes ReBAC (Google Zanzibar, OpenFGA, SpiceDB) traversent le graphe de relations pour calculer les permissions.

Avantages :

• Naturel pour les hiérarchies (org, dossiers, projets)
• Permissions héritées automatiquement
• Modèle puissant pour le sharing/collaboration

Inconvénients :

• Complexité du graphe
• Performance (traversée de graphe)
• Moins intuitif que RBAC

Comparatif des modèles

Critère	RBAC	ABAC	ReBAC
Complexité	Faible	Élevée	Moyenne-Élevée
Flexibilité	Faible	Très élevée	Élevée
Contexte dynamique	❌	✅	Partiel
Auditabilité	✅ Facile	⚠️ Complexe	⚠️ Graphe
Cas d’usage	Apps métier classiques	Défense, santé, finance	Collaboration, SaaS multi-tenant
Exemples systèmes	AWS IAM, Kubernetes RBAC	XACML, OPA	Google Zanzibar, OpenFGA

Glissez pour voir

En pratique : hybride

La plupart des systèmes combinent les modèles :

• RBAC pour la structure de base (admin, user, guest)
• ABAC pour les règles contextuelles (horaires, geo, classification)
• ReBAC pour la collaboration (propriétaire, éditeur, viewer)

Architecture PDP / PEP

Pour découpler l’autorisation du code métier, utilisez l’architecture PEP + PDP :

Composant	Rôle
PEP (Policy Enforcement Point)	Intercepte la requête, demande une décision, applique le résultat
PDP (Policy Decision Point)	Évalue la politique, retourne ALLOW/DENY
PAP (Policy Administration Point)	Interface d’administration des politiques
PIP (Policy Information Point)	Fournit les attributs (user, resource, context)

Glissez pour voir

Flux d’une décision

Avantages du découplage

Avantage	Description
Cohérence	Une seule source de vérité pour les politiques
Testabilité	Politiques testées indépendamment du code
Évolutivité	Changer les règles sans redéployer l’app
Auditabilité	Log centralisé des décisions

Glissez pour voir

Policy-as-Code avec OPA

OPA (Open Policy Agent) est un moteur de politiques générique. Les politiques sont écrites en Rego.

Exemple de politique Rego

package authz

# Permet aux admins de tout faire
allow {
  input.user.roles[_] == "admin"
}

# Permet aux owners de modifier leurs ressources
allow {
  input.action == "write"
  input.resource.owner == input.user.id
}

# Lecture autorisée si même département
allow {
  input.action == "read"
  input.user.department == input.resource.department
}

Évaluation d’une requête

Input (JSON) :

{
  "user": {
    "id": "alice",
    "roles": ["user"],
    "department": "engineering"
  },
  "action": "read",
  "resource": {
    "id": "doc-123",
    "department": "engineering",
    "owner": "bob"
  }
}

Résultat : allow = true (même département)

Tester les politiques

OPA permet d’écrire des tests unitaires :

package authz

test_admin_allowed {
  allow with input as {
    "user": {"roles": ["admin"]},
    "action": "delete",
    "resource": {}
  }
}

test_user_cannot_delete {
  not allow with input as {
    "user": {"roles": ["user"]},
    "action": "delete",
    "resource": {}
  }
}

test_owner_can_write {
  allow with input as {
    "user": {"id": "alice", "roles": ["user"]},
    "action": "write",
    "resource": {"owner": "alice"}
  }
}

Exécution :

opa test policy.rego policy_test.rego

CI/CD

Intégrez les tests de politiques dans votre pipeline CI. Une politique mal écrite = faille de sécurité ou blocage utilisateur.

Kubernetes RBAC : exemple concret

Kubernetes utilise un RBAC natif pour contrôler l’accès à l’API.

Composants

Ressource	Description
Role	Permissions dans un namespace
ClusterRole	Permissions cluster-wide
RoleBinding	Lie un Role à un sujet (user, group, SA)
ClusterRoleBinding	Lie un ClusterRole cluster-wide

Glissez pour voir

Exemple : read-only sur un namespace

# Role : permissions de lecture
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

# RoleBinding : lie le role à Alice
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: alice-pod-reader
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Vérification

# Tester si Alice peut lister les pods
kubectl auth can-i list pods --namespace production --as alice
# yes

# Tester si Alice peut supprimer les pods
kubectl auth can-i delete pods --namespace production --as alice
# no

Erreurs fréquentes

Explosion de rôles (RBAC)

Problème : Vous créez un rôle pour chaque combinaison de permissions.

admin-us-east-project-alpha
admin-us-west-project-alpha
viewer-eu-project-beta
editor-apac-project-gamma
...

Solution : Passez à ABAC pour les dimensions dynamiques (région, projet), gardez RBAC pour les niveaux (admin, editor, viewer).

Politiques trop permissives

Problème : “On verra plus tard” → allow = true partout.

Solution :

• Deny by default : aucun accès sauf règle explicite
• Revue régulière des politiques
• Tests automatisés

Attributs non fiables

Problème : L’attribut vient du client, sans vérification.

# DANGEREUX : le client peut mentir sur son rôle
allow {
  input.user_claims.role == "admin"
}

Solution :

• Les attributs doivent venir de sources fiables (IdP, base interne)
• Valider les claims du token avec le PIP

Pas de logging des décisions

Problème : “Pourquoi Bob a-t-il pu accéder ?” → aucune trace.

Solution :

• Logger chaque décision (entrée, résultat, politique matchée)
• Conserver les logs pour l’audit

Checklist de conception

1. Identifier les sujets

   Qui demande l’accès ? Users, services, machines, groupes.

2. Identifier les ressources

   Sur quoi porte l’accès ? APIs, documents, base de données, environnements.

3. Identifier les actions

   Que peut-on faire ? CRUD, approve, deploy, transfer…

4. Choisir le modèle

   RBAC si simple, ABAC si contexte dynamique, ReBAC si hiérarchies/sharing.

5. Définir les politiques

   Règles explicites, deny by default, versionned.

6. Implémenter PEP/PDP

   Découpler la décision de l’enforcement.

7. Tester

   Tests unitaires pour chaque politique, cas nominaux et limites.

8. Auditer

   Logs, revues régulières, alertes sur anomalies.

À retenir

Les 8 points clés

1. RBAC = permissions via rôles — simple mais peut exploser
2. ABAC = permissions via attributs — flexible mais complexe
3. ReBAC = permissions via relations — idéal pour hiérarchies et sharing
4. Hybride est souvent la meilleure approche en production
5. PDP/PEP découple la décision de l’enforcement
6. Policy-as-Code (OPA, Rego) permet de tester et versionner les politiques
7. Deny by default : aucun accès sans règle explicite
8. Loggez chaque décision pour l’audit et le troubleshooting

Références

• NIST ABAC Guide
• OPA Documentation
• Kubernetes RBAC
• Google Zanzibar Paper
• OpenFGA

Prochaines étapes

Sécurité opérationnelle IAM Opérez un système d'identité en production : hardening, observabilité, incident response.

×

📖 Voir la documentation →