Contrôle d'accès
Sécurité
Ensemble des mécanismes qui décident si un sujet (utilisateur, service, processus) peut effectuer une action sur une ressource, puis qui appliquent cette décision. On vérifie d'abord l'identité, ensuite les droits, et on ne laisse passer que ce qui est explicitement permis.
Authentifier puis autoriser : L'authentification établit qui fait la demande ; l'autorisation détermine ce que cette identité a le droit de faire. Prouver son identité ne donne aucun droit en soi, et confondre les deux étapes reste une source intarissable de failles.
Modèles de droits : En contrôle discrétionnaire (DAC, Discretionary Access Control), le propriétaire de la ressource accorde lui-même les droits. En contrôle obligatoire (MAC, Mandatory Access Control), une politique centrale les impose, et l'utilisateur ne peut pas y déroger. Le RBAC rattache les droits à des rôles, et l'ABAC évalue des règles sur les attributs du sujet, de la ressource et du contexte (heure, réseau, appareil).
Décision et application : Le point de décision (PDP) évalue la politique, le point d'application (PEP) bloque ou laisse passer la requête. Séparer les deux permet de centraliser les règles au lieu de les recopier dans chaque application.
Portes et réseau : Le même terme désigne le badge qui ouvre une porte, le NAC qui décide si une machine entre sur le réseau et la règle qui laisse une requête atteindre une base : mêmes étapes, autres acteurs. Un badge cloné reste une authentification réussie, et c'est tout le problème.
Moindre privilège : Chaque sujet reçoit les droits strictement nécessaires à sa tâche, pas un de plus, et les droits devenus inutiles se retirent. La seconde moitié de cette phrase est la plus difficile à faire appliquer : accorder un droit prend trois minutes, le reprendre demande une réunion.
Ce qui arrive si on s'en passe
Sans contrôle d'accès, toute requête qui atteint une ressource est exécutée, quelle que soit son origine : la porte de la ruche reste ouverte, et rien ne distingue une ouvrière d'un frelon. Un sujet non authentifié peut lire, modifier ou supprimer des données qu'aucune règle ne lui réserve. Un compte légitime mais limité peut agir au-delà de son rôle : il peut appeler une fonction d'administration ou consulter les enregistrements d'un autre utilisateur en changeant simplement un identifiant dans la requête. Faute de cloisonnement, un seul identifiant compromis ouvre l'ensemble des ressources au lieu d'un périmètre restreint. La détection perd aussi son point d'appui : sans décision explicite d'autoriser ou de refuser, aucun refus n'est enregistré, une tentative anormale ne se distingue pas d'un usage normal, et sans identité vérifiée, il devient impossible d'établir après coup qui a fait quoi.
Explication de la marmotte
Imagine un festival. À l'entrée, un agent vérifie ton billet et ta carte d'identité : il s'assure que tu es bien la personne que tu prétends être. Ensuite, la couleur de ton bracelet décide où tu peux aller : la pelouse pour tout le monde, les coulisses seulement pour les artistes et l'équipe. Sur un ordinateur ou un site, c'est pareil : le système vérifie d'abord qui tu es, puis consulte une liste de règles pour savoir si tu as le droit de lire un fichier, de le modifier ou de l'effacer. La bonne pratique consiste à ne donner à chacun que les bracelets dont il a vraiment besoin.
Où ce terme est utilisé
- CWE-284 : contrôle d'accès défaillant, le pilier venu de l'OWASP (9 occurrences)
- Prévenir les BOLA dans une API métier (6 occurrences)
- Contrôler les accès d’un assistant IA interne (5 occurrences)
- Quand la recherche sémantique contourne les droits (5 occurrences)
- Auditer la couverture réelle du mTLS service mesh (4 occurrences)
- Comment lire un rapport OWASP Top 10 (4 occurrences)
- Comment sécuriser Redis et Memcached distribués (4 occurrences)
- DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir (4 occurrences)
- Modèles Bell-LaPadula, Biba et Clark-Wilson (4 occurrences)
- OWASP Top 10 ASVS ZAP et sécurité applicative (4 occurrences)