Séparation des privilèges : diviser pour mieux protéger
Mise à jour :
Un système où une seule entité détient tous les pouvoirs est fragile : si cette entité est compromise, tout l’est. La séparation des privilèges consiste à diviser les responsabilités et les droits entre plusieurs acteurs, de sorte qu’aucun ne puisse agir seul pour effectuer une action critique.
En résumé : La séparation des privilèges impose que plusieurs entités distinctes collaborent pour réaliser une opération sensible. Compromettre une seule entité ne suffit plus à compromettre le système.
L’erreur du compte tout-puissant
Une erreur fréquente consiste à centraliser tous les pouvoirs dans une seule entité par commodité.
Exemples de raisonnements dangereux :
- “Un seul compte admin pour tout, c’est plus simple à gérer”
- “Le pipeline CI/CD a tous les droits, sinon ça bloque”
- “Le développeur senior peut tout faire, il est de confiance”
- “On utilise le même token pour le déploiement et la production”
- “L’application a accès à toutes les bases de données, au cas où”
Chaque concentration de privilèges représente :
- Un point unique de défaillance (single point of failure)
- Un impact maximal en cas de compromission
- Une impossibilité de traçabilité (qui a fait quoi ?)
- Une violation du principe de moindre privilège
Le principe de séparation des privilèges
La séparation des privilèges (privilege separation) exige que les opérations sensibles nécessitent l’intervention de plusieurs entités indépendantes.
Origines : le modèle Unix
Le concept vient des systèmes Unix où les programmes privilégiés sont découpés en plusieurs processus :
- Un processus privilégié minimal qui effectue les opérations root
- Un processus non privilégié qui gère la logique métier
- Communication contrôlée entre les deux
OpenSSH est l’exemple canonique : le daemon sshd fork un processus non privilégié pour gérer la session utilisateur, limitant l’impact d’une vulnérabilité.
La métaphore du coffre-fort bancaire
Un coffre-fort de banque ne s’ouvre pas avec une seule clé. Il faut :
- La clé du directeur
- La clé du responsable sécurité
- Un code temporel
Aucune personne seule ne peut accéder au contenu. C’est le même principe appliqué aux systèmes informatiques.
Les domaines d’application
Architecture applicative
Séparer les composants d’une application selon leurs besoins de privilèges :
| Composant | Privilèges | Isolation |
|---|---|---|
| Frontend | Aucun accès direct aux données | Conteneur dédié |
| API Gateway | Authentification uniquement | Réseau DMZ |
| Service métier | Lecture/écriture données métier | Réseau interne |
| Service admin | Opérations privilégiées | Réseau restreint |
| Base de données | Stockage uniquement | Réseau isolé |
Chaque composant ne peut faire que ce pour quoi il est conçu. Un frontend compromis ne donne pas accès à la base de données.
Pipelines CI/CD
Les pipelines concentrent souvent trop de privilèges. Séparez-les :
| Étape | Responsabilité | Credentials |
|---|---|---|
| Build | Compiler le code | Accès registre en lecture |
| Test | Exécuter les tests | Aucun accès production |
| Scan | Analyser la sécurité | Lecture code uniquement |
| Deploy staging | Déployer en staging | Token staging uniquement |
| Deploy prod | Déployer en production | Token prod (avec approbation) |
Le job de build ne doit jamais avoir les credentials de production. Le déploiement en production doit nécessiter une approbation humaine distincte.
Gestion des secrets
Les secrets critiques doivent être protégés par plusieurs gardiens :
- Chiffrement : une clé pour chiffrer
- Stockage : un système pour stocker (Vault, Secret Manager)
- Accès : une politique pour autoriser
- Audit : un système pour tracer
Compromettre un seul élément ne suffit pas à obtenir le secret en clair.
Cloud et IAM
Dans le cloud, séparez les rôles IAM :
| Rôle | Peut faire | Ne peut pas faire |
|---|---|---|
| Développeur | Lire les logs, déployer en dev | Accéder à la prod |
| Ops | Gérer l’infra, pas les données | Lire les données métier |
| DBA | Gérer les bases | Modifier l’infra réseau |
| Security | Auditer, configurer les policies | Déployer du code |
| Admin | Gérer les comptes | Actions sans approbation |
Aucun rôle unique ne peut faire tout. Les actions critiques (suppression, modification IAM) nécessitent plusieurs approbations.
Scénario 1 : Le pipeline compromis
Un attaquant compromet le repository Git d’une application.
Sans séparation des privilèges :
- Le pipeline CI/CD a un token avec tous les droits
- L’attaquant modifie le code et le pipeline
- Le build et le déploiement s’exécutent automatiquement
- Code malveillant déployé en production
- L’attaquant a accès aux secrets du pipeline
- Compromission totale
Avec séparation des privilèges :
- Le job de build ne peut que compiler (pas de secrets prod)
- Le déploiement staging est automatique mais isolé
- Le déploiement production nécessite :
- Approbation d’un reviewer (personne différente)
- Validation des scans de sécurité (système automatisé)
- Token limité dans le temps (système de secrets)
Résultat : L’attaquant peut compromettre le build, mais le déploiement en production est bloqué par les autres gardiens.
Scénario 2 : L’administrateur malveillant
Un administrateur système décide d’exfiltrer des données sensibles.
Sans séparation des privilèges :
- L’admin a accès root sur tous les serveurs
- Il peut lire toutes les bases de données
- Il peut désactiver les logs
- Il exfiltre les données sans trace
- Découverte des mois plus tard (si jamais)
Avec séparation des privilèges :
- L’admin système gère l’infrastructure (pas les données)
- L’accès aux données nécessite le DBA + une justification
- Les logs sont envoyés vers un système qu’il ne contrôle pas
- La modification des policies IAM nécessite le security + validation
- L’export de données massif déclenche une alerte
Résultat : L’admin ne peut pas agir seul. Chaque action sensible implique d’autres acteurs ou systèmes qu’il ne contrôle pas.
Comment implémenter la séparation
Identifier les actions critiques
Listez les opérations qui nécessitent une protection renforcée :
- Déploiement en production
- Accès aux données sensibles (PII, secrets, financier)
- Modification des droits et policies
- Suppression de ressources
- Export de données en masse
- Modification des configurations de sécurité
Définir les gardiens
Pour chaque action critique, identifiez au moins deux gardiens :
| Action | Gardien 1 | Gardien 2 | Gardien 3 |
|---|---|---|---|
| Deploy prod | Développeur (PR) | Reviewer (approbation) | CI (tests OK) |
| Accès données | Demandeur | Manager (validation) | Système (audit) |
| Modifier IAM | Admin | Security (review) | Système (MFA) |
| Supprimer ressource | Ops | Confirmation différée | Backup vérifié |
Implémenter les contrôles techniques
Traduisez les gardiens en mécanismes techniques :
- Branch protection : PR + review obligatoire
- Environment protection : approbations pour les environnements
- MFA : validation humaine pour les actions critiques
- Separation of duties dans IAM : policies distinctes
- Break-glass procedures : processus d’urgence documentés et audités
Auditer et alerter
La séparation des privilèges ne vaut que si elle est surveillée :
- Logger toutes les actions privilégiées
- Alerter sur les tentatives de contournement
- Réviser régulièrement les accès et les gardiens
- Tester les procédures (exercices red team)
Pièges courants
La séparation de façade
Créer des rôles séparés mais accorder des exceptions permanentes qui les vident de leur sens. “L’admin a tous les rôles pour simplifier.”
Le gardien unique
Mettre plusieurs contrôles mais tous contrôlés par la même personne ou le même système. Si ce gardien est compromis, tous les contrôles tombent.
L’oubli du break-glass
Une séparation si stricte qu’elle bloque les opérations légitimes en cas d’urgence. Prévoir des procédures d’exception auditées.
La complexité excessive
Tellement de gardiens que personne ne comprend le processus. La séparation doit être proportionnée au risque.
À retenir
-
Aucune entité ne doit pouvoir agir seule pour les opérations critiques — imposer plusieurs gardiens indépendants.
-
Séparation ≠ moindre privilège — le moindre privilège limite les droits, la séparation impose la coopération.
-
Les pipelines CI/CD sont des cibles prioritaires — séparer build, test, deploy avec des credentials distincts.
-
Les gardiens doivent être indépendants — si une personne contrôle tous les gardiens, la séparation est illusoire.
-
Prévoir les urgences — des procédures break-glass documentées et auditées pour les cas exceptionnels.
-
Auditer en continu — la séparation sans surveillance ne protège pas contre les attaquants patients.
Liens utiles
- Moindre privilège — Limiter les droits de chaque entité
- Défense en profondeur — Plusieurs couches de protection
- Zero Trust — Ne jamais faire confiance par défaut
- Gestion des secrets — Protéger les credentials avec plusieurs gardiens