Principle of Least Privilege
Pas de droit « au cas où ». Chaque accès est explicite, justifié, expiré, audité. Le bouton « admin » n'existe pas — il y a des rôles précis.
Problème
Une compromission (cred volée, container piraté, RCE) hérite de tous les droits du compte concerné. Si ce compte a des droits larges (admin, root, super-user, IAM PowerUser), l'attaquant accède à tout. Le coût d'un incident est proportionnel à la taille du périmètre du compte compromis. Comment réduire ce périmètre par défaut ?
Forces
- Donner un droit pour « débloquer rapidement » est tentant et durable.
- Les droits non-utilisés ne sont jamais révoqués spontanément.
- Les comptes humains et machines partagent souvent les mêmes rôles, qui finissent over-privileged.
- L'audit régulier des droits a un coût mais c'est le seul moyen de détecter la dérive.
- Le principe est énoncé en 1975 (Saltzer & Schroeder) — sa permanence prouve sa difficulté de mise en œuvre.
Solution
Chaque identité (utilisateur, service account, rôle IAM) ne reçoit que les permissions strictement nécessaires à sa fonction connue à ce jour. Si des droits supplémentaires sont nécessaires temporairement (incident, migration), on les accorde en just-in-time avec expiration. Les rôles sont segmentés par fonction (lecteur, opérateur, admin), pas par personne. On audite régulièrement les permissions effectives vs utilisées (cf. AWS IAM Access Analyzer, GCP Recommender). On préfère interdire par défaut (deny-by-default) puis autoriser explicitement.
Mécanismes
- RBAC — Role-Based Access Control : on n'accorde pas de droits aux humains mais à des rôles.
- ABAC — Attribute-Based Access Control : la décision prend en compte des attributs (heure, IP, sensibilité).
- JIT access — Just-in-Time : élévation temporaire approuvée, audit log.
- Workload Identity — Kubernetes ServiceAccount, AWS IRSA, GCP Workload Identity — pas de credentials longue durée sur les pods.
- Permissions boundary (AWS IAM) — plafond hard de ce qu'un rôle peut faire, même si on lui accorde plus.
Implémentation EDI
Un hub EDI multi-tenants applique LP partout : (a) le compte d'API du partenaire Walmart ne peut envoyer que des INVOIC AS4 et lire que ses propres MDN ; (b) le rôle IAM de Lambda « parse-edifact » a accès en lecture au bucket S3 d'entrée mais aucun droit en écriture ailleurs ; (c) l'opérateur d'astreinte a un rôle « DataOps » distinct de « PlatformAdmin » — il peut rejouer un message échoué mais pas modifier les politiques IAM ; (d) les credentials AS2 (clé privée signature) sont scopées à un seul partenaire — pas de master key. Conséquence : un certificat partenaire compromis ne donne accès qu'à ses propres flux ; un crash de Lambda ne peut pas effacer les archives.
Anti-patterns
- Rôle « PowerUser » accordé par défaut à tous les devs — la première compromission donne tout.
- Service accounts Kubernetes avec
cluster-admin— un pod compromis = cluster compromis. - Wildcard
"*"en IAM Action — droit non borné. - Pas d'audit annuel des droits — dérive silencieuse.
- Élévation permanente au lieu de just-in-time — l'audit log perd son sens.
Patterns liés
- Zero Trust Architecture — Least Privilege en est le pilier 3.
- Defense in Depth — Least Privilege est une couche.
- Secrets Management — la mise en œuvre côté credentials.
- Bulkhead — isolement opérationnel équivalent en résilience.
Sources
- Saltzer J., Schroeder M. — The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9), 1975. cs.virginia.edu/~evans/cs551/saltzer/
- NIST SP 800-53 — Contrôle AC-6 « Least Privilege ».
- AWS IAM Best Practices — Apply least-privilege permissions. docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html