Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Outils open source — Gratuits, portables, hors ligne
Caractéristiques communes
100 % hors ligne — aucune donnée transmise
Portables — un seul fichier exécutable
Gratuits — MIT ou GPL v3
Code source ouvert sur GitHub
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Academy Contact

RBAC (Role-Based Access Control)

general

Définition

Le RBAC (Role-Based Access Control — Contrôle d'Accès Basé sur les Rôles) est le modèle de contrôle d'accès le plus répandu dans les systèmes d'information. Il organise les permissions autour de rôles fonctionnels plutôt que de les attribuer directement à des utilisateurs individuels, simplifiant considérablement la gestion des droits dans les grandes organisations. Le modèle RBAC repose sur trois entités fondamentales : les utilisateurs (subjects), les rôles (abstractions de fonctions métier), et les permissions (droits sur des ressources). L'association utilisateur-rôle est administrative (un RH peut attribuer un rôle "Développeur Back-end" à un nouvel employé), et l'association rôle-permission est technique (le rôle "Développeur Back-end" donne accès aux repos Git, aux environnements de développement, et aux outils de monitoring). Un utilisateur acquiert les permissions de tous ses rôles. RBAC simplifie l'administration : plutôt que de gérer des milliers de permissions individuelles, les administrateurs gèrent un nombre limité de rôles bien définis. L'onboarding d'un nouvel employé se réduit à l'attribution des rôles correspondant à sa fonction. Les revues d'accès portent sur les affectations rôle-utilisateur. La révocation lors d'un départ consiste à retirer tous les rôles de l'utilisateur. Les variantes du RBAC incluent : RBAC0 (modèle de base — utilisateurs, rôles, permissions), RBAC1 (avec héritage de rôles — un rôle "Développeur Senior" hérite des permissions de "Développeur"), RBAC2 (avec contraintes — interdire les combinaisons de rôles conflictuels pour la SoD), et RBAC3 (combinaison de RBAC1 et RBAC2, le plus complet). Les implémentations modernes de RBAC incluent les IAM roles AWS (policies JSON attachées aux rôles, assumables par les services et utilisateurs), Azure RBAC (roles prédéfinis comme Owner/Contributor/Reader et rôles personnalisés), Kubernetes RBAC (roles et clusterroles avec verbs sur les resources), les frameworks applicatifs (Spring Security RBAC, Django Groups, Keycloak Realm Roles), et les bases de données (GRANT/REVOKE sur des rôles dans PostgreSQL, SQL Server, Oracle). Les limites du RBAC simple sont adressées par l'ABAC (Attribute-Based Access Control) qui permet des politiques d'accès plus contextuelles : "ce médecin peut accéder au dossier de ce patient uniquement s'il est son médecin traitant et si l'accès se fait depuis le réseau interne pendant les heures ouvrables".

RBAC vs ABAC — choisir le bon modèle

Le RBAC est simple, scalable, et facile à auditer — idéal pour les accès structurés par fonction (accès aux applications selon le département). L'ABAC (Attribute-Based Access Control) offre plus de granularité via des politiques évaluées dynamiquement en fonction d'attributs contextuels (département, localisation, heure, sensibilité de la donnée, posture du device). ABAC permet des règles comme "accès aux données confidentielles uniquement depuis des appareils managés en dehors des heures de nuit". Les systèmes XACML (eXtensible Access Control Markup Language) et OPA (Open Policy Agent) implémentent l'ABAC. En pratique, la majorité des organisations utilise RBAC comme fondation avec des contraintes ABAC pour les accès les plus sensibles (modèle hybride RBAC + ABAC).

RBAC Kubernetes — sécurisation du cluster

Kubernetes RBAC est un composant critique de la sécurité des clusters. Il définit des Roles (namespace-scoped) et ClusterRoles (cluster-wide) avec des verbs (get, list, watch, create, update, patch, delete) sur des resources (pods, deployments, secrets, etc.). Les RoleBindings et ClusterRoleBindings associent ces rôles aux utilisateurs, groupes, ou ServiceAccounts. Les erreurs courantes incluent : utilisation de ClusterRoles trop larges (cluster-admin pour des CI/CD), création de Roles avec des wildcards (*, permettant tous les verbs sur toutes les resources), et Service Accounts avec droits excessifs. Un audit RBAC avec kubectl-rbac-tool ou rbac-audit identifie les chemins d'escalade et les permissions excessives dans le cluster.

RBAC et certifications des accès

Le RBAC facilite les revues d'accès périodiques exigées par ISO 27001, SOX, et PCI-DSS. Plutôt que de vérifier des milliers de permissions individuelles, les auditeurs vérifient : (1) que les rôles sont bien définis et alignés sur les fonctions métier, (2) que les affectations utilisateur-rôle sont correctes et à jour, (3) que les rôles ne violent pas les contraintes SoD (Separation of Duties). Les outils IGA (SailPoint, Saviynt) automatisent l'analyse des violations RBAC/SoD et facilitent les campagnes de recertification. Un rapport de conformité RBAC bien structuré simplifie considérablement les audits de sécurité en fournissant une vue claire de qui a accès à quoi et pourquoi.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis