Contrôle d'accès et principe du moindre privilège
Donner à chacun uniquement les droits nécessaires, pour la durée nécessaire : un principe simple, difficile à tenir dans la durée. Modèles de contrôle d'accès, AAA, rôles, comptes de service et revues régulières.
Le principe du moindre privilège stipule qu'un utilisateur, un programme ou un système ne doit disposer que des droits strictement nécessaires à sa mission, et seulement pendant le temps nécessaire. Son objectif est double : limiter les erreurs (on ne peut pas supprimer par mégarde ce à quoi l'on n'a pas accès) et limiter l'impact d'une compromission (un compte volé ne donne accès qu'à un périmètre restreint).
Objectif : comprendre les modèles de contrôle d'accès, appliquer le moindre privilège aux comptes, aux équipements réseau et aux services, et maintenir ces droits dans le temps.
Identification, authentification, autorisation, traçabilité
Le contrôle d'accès s'articule autour de quatre étapes :
- Identification : qui prétendez-vous être ? (un identifiant)
- Authentification : prouvez-le (mot de passe, clé, certificat, second facteur).
- Autorisation : que pouvez-vous faire ?
- Traçabilité (accounting) : qu'avez-vous fait ?
Le moindre privilège concerne l'autorisation, mais il ne vaut rien sans une authentification robuste et une traçabilité fiable.
Les modèles de contrôle d'accès
| Modèle | Principe | Usage |
|---|---|---|
| DAC (discrétionnaire) | Le propriétaire d'une ressource décide qui y accède | Permissions de fichiers classiques |
| MAC (obligatoire) | Une politique centrale impose les accès selon des niveaux de sensibilité | Systèmes très sensibles, SELinux |
| RBAC (par rôles) | Les droits sont attribués à des rôles ; les utilisateurs reçoivent des rôles | Le plus répandu en entreprise |
| ABAC (par attributs) | La décision dépend d'attributs : utilisateur, ressource, contexte (heure, appareil, lieu) | Accès conditionnel, Zero Trust |
Le RBAC est le point de départ pragmatique : définir des rôles alignés sur les fonctions (exploitant réseau niveau 1, administrateur réseau, administrateur systèmes, auditeur), leur associer des droits, puis affecter les personnes aux rôles. On n'attribue jamais de droits directement à un individu.
Appliquer le moindre privilège aux comptes
Séparer les usages
Un administrateur dispose de deux comptes au minimum :
- un compte standard pour la messagerie, la navigation et la bureautique ;
- un compte d'administration, utilisé uniquement pour les tâches d'administration, idéalement depuis un poste dédié.
Ainsi, un courriel piégé ouvert avec le compte standard ne donne pas directement des droits d'administration.
Hiérarchiser les privilèges
Le modèle de niveaux d'administration (souvent appelé tiering) sépare l'administration des éléments les plus critiques (annuaire, PKI, hyperviseurs) de celle des serveurs, puis de celle des postes. Un compte qui administre les postes ne doit jamais se connecter sur un contrôleur de domaine, et inversement un compte de niveau supérieur ne doit pas se connecter sur des postes de niveau inférieur, où ses identifiants pourraient être dérobés.
Limiter dans le temps
L'accès juste-à-temps (just-in-time) accorde des privilèges élevés pour une durée limitée, après demande et éventuellement validation, puis les retire automatiquement. Les solutions de gestion des accès privilégiés (PAM) et certaines fonctions des annuaires modernes le permettent. Les certificats SSH à courte durée suivent la même logique : voir Durcissement SSH et gestion des accès administratifs.
Équipements réseau : AAA avec TACACS+ ou RADIUS
Sur les routeurs, commutateurs et pare-feu, le cadre AAA (Authentication, Authorization, Accounting) centralise les accès :
| Critère | TACACS+ (RFC 8907) | RADIUS (RFC 2865) |
|---|---|---|
| Transport | TCP 49 | UDP 1812/1813 |
| Chiffrement | Corps du paquet chiffré (avec un algorithme ancien ; TLS en cours de normalisation) | Seul le mot de passe est masqué |
| Séparation AAA | Authentification, autorisation et comptabilité séparées | Authentification et autorisation combinées |
| Autorisation par commande | Oui | Limitée |
| Usage typique | Administration des équipements réseau | Accès réseau (802.1X, VPN, Wi-Fi) |
Avec TACACS+, on peut autoriser un exploitant à exécuter les commandes show mais pas configure terminal, et journaliser chaque commande exécutée.
Exemple Cisco IOS (laboratoire) :
aaa new-model
tacacs server TACACS-1
address ipv4 10.10.99.60
key <secret-partage>
aaa group server tacacs+ GRP-TACACS
server name TACACS-1
aaa authentication login default group GRP-TACACS local
aaa authorization exec default group GRP-TACACS local
aaa authorization commands 15 default group GRP-TACACS local
aaa accounting commands 15 default start-stop group GRP-TACACS
username secours privilege 15 algorithm-type scrypt secret <mot-de-passe-fort>
Testez la configuration AAA avec une session de secours ouverte : une erreur peut verrouiller tous les accès. Le compte local secours ne doit servir qu'en cas d'indisponibilité du serveur, et son mot de passe doit être conservé dans un coffre.
Sur Cisco IOS, des niveaux de privilège (0 à 15) et des vues (parser views) permettent aussi de restreindre localement les commandes accessibles.
Les comptes de service
Les comptes utilisés par les applications, les outils de sauvegarde, de supervision ou d'automatisation sont souvent sur-privilégiés et oubliés.
- Un compte par service, jamais partagé entre applications.
- Droits minimaux : un compte de supervision SNMP en lecture, un compte de sauvegarde des configurations sans droit d'écriture.
- Interdiction d'ouverture de session interactive lorsque c'est possible.
- Secrets longs, aléatoires, renouvelés, stockés dans un coffre, jamais en clair dans des scripts. Dans un domaine Windows, les comptes de service gérés (gMSA) assurent une rotation automatique des mots de passe.
- Inventaire : propriétaire, usage, date de revue.
Le réseau au service du moindre privilège
Le moindre privilège ne s'applique pas qu'aux comptes : il s'applique aux flux. Un serveur web n'a besoin de joindre que sa base de données et ses dépôts de mises à jour ; un poste utilisateur n'a pas besoin d'atteindre les interfaces d'administration. C'est l'objet de la segmentation réseau et du filtrage.
Revues des droits
Les droits s'accumulent avec le temps : changement de poste, projets terminés, prestataires partis. Planifiez :
- Une revue périodique (par exemple semestrielle) des membres des groupes à privilèges, réalisée par les responsables métiers et techniques.
- Un processus d'arrivée, de mobilité et de départ relié aux ressources humaines : désactivation immédiate des accès au départ.
- Une détection des comptes inactifs, à désactiver puis supprimer.
- Un contrôle des comptes à privilèges : toute ajout à un groupe d'administration déclenche une alerte.
Erreurs courantes
- Comptes d'administration partagés.
- Droits accordés « temporairement » et jamais retirés.
- Administrateurs qui naviguent et lisent leur messagerie avec leur compte privilégié.
- Comptes de service membres des groupes d'administration par facilité.
- Absence de journalisation des actions privilégiées.
Conclusion
Le moindre privilège se construit avec des rôles clairs, des comptes séparés, une centralisation AAA, des comptes de service maîtrisés et des revues régulières. Il se prolonge naturellement dans le réseau par la segmentation et le filtrage, et constitue l'un des piliers du Zero Trust.
Références
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls (contrôle AC-6 Least Privilege)
- RFC 8907 — The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol
- RFC 2865 — Remote Authentication Dial In User Service (RADIUS)
- Microsoft Learn — Comptes de service administrés de groupe (gMSA)
- ANSSI — Recommandations relatives à l'administration sécurisée des SI (version anglaise, PDF)
