RBAC (Role-Based Access Control)

Introduction

RBAC, ou contrôle d’accès basé sur les rôles, est un modèle de gestion des autorisations …​

RBAC simplifie la gestion : au lieu d’attribuer des permissions à chaque utilisateur, on les attribue à des rôles — puis on assigne les rôles.

…​

dans lequel l’accès aux ressources est déterminé par les rôles assignés aux utilisateurs.

…​

Ce modèle est largement utilisé dans les systèmes informatiques et les applications pour gérer efficacement les permissions, réduire les erreurs humaines et améliorer la sécurité.

1. Concepts clés :

a. Rôles :

Un rôle est une collection d’autorisations ou de privilèges.

Exemple :

Administrateur, Utilisateur, Modérateur, Analyste.

b. Permissions :

Les permissions sont des droits spécifiques accordés pour effectuer une action sur une ressource.

Exemple :

Lire, Écrire, Supprimer, Modifier.

c. Utilisateurs :

Les utilisateurs sont des entités (personnes ou systèmes) auxquelles des rôles sont assignés.

Exemple :

  • Alice est un "Administrateur",

  • Bob est un "Utilisateur".

…​

Les objets auxquels les utilisateurs peuvent accéder.

Exemple :

Fichiers, bases de données, API, systèmes.

e. Relations entre les concepts :

Rôles → Permissions :

Chaque rôle est associé à une ou plusieurs permissions.

Utilisateurs → Rôles :

Les utilisateurs se voient attribuer des rôles en fonction de leur fonction ou position.

2. Types d’implémentations RBAC :

a. RBAC de base (Core RBAC) :

  • Les permissions sont directement associées aux rôles.

  • Les utilisateurs obtiennent des permissions via leurs rôles.

b. Hiérarchique RBAC :

Implémente des relations hiérarchiques entre les rôles.

Exemple :

Un rôle "Manager" hérite des permissions du rôle "Employé".

c. Contrainte RBAC :

Permet de définir des restrictions supplémentaires, comme la séparation des responsabilités (SoD - Segregation of Duties).

…​

Exemple :

Un utilisateur ne peut pas être à la fois "Auditeur" et "Finance Manager".

3. Avantages du RBAC :

Simplicité de gestion :

Les autorisations sont gérées au niveau des rôles, et non des utilisateurs individuels.

Réduction des erreurs :

Moins de risques d’accorder accidentellement des permissions excessives.

Conformité :

Facilite la mise en conformité avec des réglementations comme GDPR, HIPAA, ou PCI-DSS. === Évolutivité :

Pratique pour les grandes organisations avec des milliers d’utilisateurs et de ressources.

Sécurité renforcée :

Réduit l’exposition aux attaques grâce à un contrôle précis des permissions.

4. Étapes de mise en œuvre :

a. Identification des ressources :

Listez toutes les ressources nécessitant un contrôle d’accès (fichiers, services, API, etc.).

b. Définition des rôles :

Identifiez les rôles nécessaires à l’organisation.

Exemple :

Administrateur, Utilisateur, Responsable, Analyste.

c. Attribution des permissions :

Déterminez quelles actions chaque rôle peut effectuer sur les ressources.

Exemple :

Un rôle "Utilisateur" peut lire des fichiers, mais ne peut pas les supprimer.

d. Assignation des rôles aux utilisateurs :

Attribuez des rôles en fonction des responsabilités de chaque utilisateur.

e. Gestion continue :

Mettez à jour les rôles, permissions et assignations en fonction des évolutions organisationnelles.

5. Exemples d’implémentation RBAC :

a. Dans les bases de données :

MySQL :

Rôles assignés pour gérer les accès aux tables et colonnes.

CREATE ROLE 'manager';
GRANT SELECT, INSERT ON database.* TO 'manager';
GRANT 'manager' TO 'alice';

b. Dans les systèmes d’exploitation :

Linux :

Utilisation des groupes d’utilisateurs pour gérer les permissions.

useradd alice
groupadd managers
usermod -aG managers alice

c. Dans le cloud (AWS IAM) :

Les rôles IAM (Identity and Access Management) gèrent les permissions sur les services AWS.

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

d. Frameworks et outils RBAC :

Django :

Middleware pour gérer les permissions basées sur les rôles.

Keycloak :

Solution d’identité et d’accès avec gestion des rôles.

Kubernetes :

RBAC intégré pour contrôler l’accès aux ressources du cluster.

7. Bonnes pratiques pour RBAC :

Principe du moindre privilège :

Accordez uniquement les permissions nécessaires à un rôle pour accomplir ses tâches.

Évitez les permissions directes :

Assignez les permissions aux rôles, et non directement aux utilisateurs.

Audits réguliers :

Vérifiez régulièrement les rôles et permissions pour détecter les anomalies.

Modularité :

Créez des rôles granulaires qui peuvent être combinés pour des cas d’utilisation spécifiques.

Gestion des utilisateurs inactifs :

Révoquez les rôles des utilisateurs qui quittent l’organisation ou changent de poste.

8. Cas d’utilisation RBAC :

Entreprises :

Gérer les accès aux applications métiers en fonction des fonctions des employés.

Éducation :

Contrôler les accès aux ressources numériques des étudiants et professeurs.

Santé :

Restreindre l’accès aux données des patients aux rôles autorisés (médecins, infirmiers).

Cloud :

Gérer les permissions pour les ressources cloud (AWS, Azure, GCP).

RLS — Row-Level Security

Le RLS (Row-Level Security) étend le principe RBAC au niveau des lignes d’une table de base de données.

RBAC contrôle quelles tables/colonnes un utilisateur peut voir. RLS va plus loin : il filtre les lignes visibles selon l’identité ou le rôle de l’utilisateur.

Principe

  • Chaque utilisateur ne voit que les lignes qui le concernent

  • Le filtrage est appliqué automatiquement par le moteur SQL

  • Transparent pour les applications — les requêtes restent les mêmes

RLS — Cas d’usage typiques

  • Multi-tenant SaaS — chaque client ne voit que ses propres données

  • Données médicales — médecins voient leurs patients uniquement

  • RH — managers voient leur équipe, employés se voient eux-mêmes

  • Finance — chaque commercial voit ses propres ventes

  • RGPD — accès strictement minimal aux données personnelles

RLS = mise en œuvre pratique du moindre privilège au niveau données.

RLS — Implémentation

PostgreSQL

-- Activer RLS sur une table
ALTER TABLE commandes ENABLE ROW LEVEL SECURITY;

-- Politique : un commercial voit ses propres commandes
CREATE POLICY mes_commandes ON commandes
  FOR SELECT
  USING (commercial_id = current_user_id());

SQL Server

CREATE FUNCTION dbo.fn_securitypredicate(@CommercialId int)
  RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS result
   WHERE @CommercialId = USER_ID();

CREATE SECURITY POLICY CommandesFilter
  ADD FILTER PREDICATE dbo.fn_securitypredicate(commercial_id)
  ON dbo.commandes;

Oracle / MySQL

  • Oracle : VPD (Virtual Private Database) — équivalent RLS

  • MySQL : pas de RLS natif, simulé via vues + current_user()

RLS — Avantages & limites

Avantages

  • Sécurité au plus près de la donnée (defense in depth)

  • Indépendant de la couche applicative (un bug applicatif ne contourne pas RLS)

  • Audit simplifié : la politique est centralisée

  • Transparent pour l’application

Limites

  • Performance : chaque requête doit appliquer le prédicat → coût CPU

  • Complexité : politiques mal conçues = comportements imprévus

  • Pas une protection contre l’admin DB : un superutilisateur peut bypass

  • Trous classiques : les fonctions stockées non sécurisées peuvent contourner RLS

RLS — Bonnes pratiques

  • Tester avec différents profils utilisateurs

  • Auditer régulièrement les politiques

  • Combiner avec RBAC applicatif

  • Defense in depth : RLS + chiffrement + audit

  • Documenter les politiques pour les futurs DBA

Conclusion

RBAC est la mise en œuvre concrète du moindre privilège — incontournable pour toute organisation moderne.

Voir aussi : Moindre privilège · ACL · Active Directory · Sécuriser ses accès