SoD : Segregation of Duties
Sécurité
SoD : Segregation of Duties. « Séparation des tâches » : aucune identité ne doit pouvoir réaliser seule une chaîne d'actions frauduleuse ou irréversible, par analogie avec le coffre de banque qui s'ouvre avec deux clés détenues par deux personnes différentes.
Cas classique : Créer un fournisseur et approuver son paiement : la première permission prépare la fraude, la seconde la consomme. D'autres couples se retrouvent partout : modifier un pipeline et promouvoir en production, administrer un système et effacer ses journaux, demander un droit et l'approuver.
Modéliser : Les conflits se décrivent en permissions atomiques (fournisseur.creer, paiement.approuver), pas en noms de postes. La règle détecte alors la combinaison interdite quel que soit le chemin d'attribution : droit direct, rôle, groupe imbriqué, délégation ou élévation temporaire.
Prévenir et détecter : Le contrôle à la demande d'accès bloque le conflit avant qu'il existe ; la détection sur les droits effectifs rattrape les erreurs de synchronisation et les changements de modèle. Une exception doit avoir un propriétaire du risque, une mesure compensatoire et une date d'expiration.
Le piège : Un conflit accepté en permanence avec la mention « besoin opérationnel » reste une permission dangereuse, simplement mieux emballée. Dans les petites équipes où la séparation est impossible, on compense par une revue a posteriori et des journaux que la personne concernée ne peut pas modifier.
Ce qui arrive si on s'en passe
Sans séparation des tâches, une seule personne peut créer un fournisseur fictif, modifier ses coordonnées bancaires et approuver le paiement, sans qu'aucun contrôle ne s'interpose. Le même principe vaut en informatique : qui peut à la fois modifier du code et le déployer en production, ou administrer un système et effacer ses journaux, peut aussi masquer ce qu'il a fait. Un seul compte compromis donne alors à un attaquant l'ensemble de la chaîne, pas seulement un maillon. Les contrôles portant sur les seuls rôles visibles laissent passer les cumuls obtenus par groupes imbriqués ou délégations. Enfin, sans matrice de conflits documentée, l'organisation ne peut pas démontrer l'efficacité de ses contrôles financiers lors d'un audit.
Explication de la marmotte
Dans un club, la personne qui garde la caisse n'est pas celle qui vérifie les comptes. Ce n'est pas parce qu'on la soupçonne, mais parce qu'une seule personne qui fait tout pourrait se tromper, ou tricher, sans que personne ne s'en aperçoive. En informatique, c'est pareil : celui qui demande un paiement ne doit pas être celui qui l'accepte, et celui qui installe un programme ne doit pas pouvoir effacer la trace de ce qu'il a fait. Il faut deux personnes pour les actions importantes.
Où ce terme est utilisé
- Mettre en œuvre les revues d’accès IGA et la SoD (6 occurrences)