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
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « Les domaines d’application »Architecture applicative
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « Comment implémenter la séparation »Identifier les actions critiques
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « Pièges courants »La séparation de façade
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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
Section intitulée « La complexité excessive »Tellement de gardiens que personne ne comprend le processus. La séparation doit être proportionnée au risque.
À retenir
Section intitulée « À 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
Section intitulée « 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