Chapitre 2 — Modèles de Contrôle d'Accès (RBAC, MAC, DAC, ABAC)
Les modèles de contrôle d'accès définissent comment les décisions d'autorisation sont prises. Ce module couvre les quatre modèles principaux avec leurs cas d'usage, avantages et limitations.
Dans le DAC, le propriétaire de la ressource contrôle qui peut y accéder. L'OS expose des ACL (Access Control Lists) que le propriétaire peut modifier à sa discrétion.
- Avantages : flexibilité, délégation de contrôle aux propriétaires.
- Inconvénients : difficile à auditer centralement, risque de sur-partage, "trojan horse" attack possible (un programme malveillant hérite des droits du propriétaire).
- Exemples : NTFS permissions Windows, permissions Unix (chmod), partages de fichiers réseau.
Dans le MAC, les décisions d'accès sont prises par le système selon des politiques centralisées — ni l'utilisateur ni le propriétaire ne peuvent les modifier. Chaque objet a un label de classification (Confidentiel, Secret, Top Secret) et chaque sujet un niveau d'habilitation.
Règles Bell-LaPadula (confidentialité)
- No read up : un sujet ne peut pas lire un objet de niveau supérieur (top secret ne peut pas lire des documents ultra-secret sans habilitation)
- No write down : un sujet ne peut pas écrire dans un objet de niveau inférieur (évite la fuite de données classifiées vers des zones moins sécurisées)
- Avantages : très strict, résistant aux trojans (même si infecté, le programme ne peut pas accéder à des données au-delà du niveau de l'utilisateur).
- Inconvénients : très rigide, administrativement lourd, pas adapté aux environnements commerciaux.
- Exemples : SELinux, systèmes militaires, gouvernements.
Dans le RBAC, les permissions sont attribuées aux rôles, pas aux individus. Les utilisateurs reçoivent des rôles selon leur fonction dans l'organisation.
- Avantages : facile à administrer à grande échelle, aligné sur l'organigramme, audit simplifié.
- Inconvénients : "role explosion" possible (trop de rôles granulaires), difficile à adapter à des cas particuliers.
- Exemples : Active Directory Groups, AWS IAM Roles, bases de données (GRANT SELECT TO role_readonly).
ABAC prend les décisions d'accès basées sur des attributs du sujet, de l'objet et de l'environnement. Offre une granularité maximale.
- Attributs du sujet : département, localisation, niveau de certification, heure de la journée.
- Attributs de l'objet : classification du document, propriétaire, projet.
- Attributs d'environnement : heure, localisation de l'accès, appareil utilisé.
- Exemple de règle ABAC : "Un employé du département Finance peut accéder aux rapports financiaux classifiés 'confidentiel' uniquement depuis un poste géré par l'entreprise, pendant les heures ouvrables."
- Avantages : très flexible, politique zero trust naturelle.
- Inconvénients : complexe à configurer, moteur de politique requis.
- Aussi appelé PBAC (Policy-Based Access Control).
| Modèle | Qui décide | Granularité | Contexte type |
|---|---|---|---|
| DAC | Propriétaire | Moyenne | OS, partages de fichiers |
| MAC | Système/Politique centralisée | Faible (labels) | Militaire, gouvernement |
| RBAC | Administrateur (via rôles) | Bonne | Entreprise, ERP, cloud |
| ABAC | Moteur de politique (règles) | Très haute | Zero Trust, cloud, API |
Questions types : "Quel modèle est le plus strict ?" → MAC. "Quel modèle est le plus flexible ?" → ABAC. "Quel modèle aligne les accès sur les fonctions dans l'organigramme ?" → RBAC. "Quel modèle laisse le propriétaire décider ?" → DAC.