À retenir

• La séparation des tâches (SoD, Segregation of Duties) empêche qu’une seule personne cumule les droits permettant à la fois de commettre et de dissimuler une action sensible — c’est un contrôle clé en gouvernance des habilitations.
• Elle est formalisée comme contrôle dans l’ISO/IEC 27001:2022 (contrôle 5.3) et déclinée techniquement dans le standard RBAC sous deux formes : statique (interdiction d’attribution) et dynamique (interdiction d’activation simultanée).
• Son moteur opérationnel est la matrice SoD, définie avec le métier, qui liste les couples de tâches incompatibles.
• Sa réussite repose moins sur l’outil que sur la qualité de la matrice, le traitement explicite des conflits et une gouvernance des exceptions documentée.

Introduction

Une même personne qui peut créer un fournisseur dans le système financier et approuver ses paiements détient un pouvoir difficilement contrôlable. C’est le type de cumul que la séparation des tâches cherche à empêcher : structurer les droits pour qu’aucun individu, à lui seul, ne puisse exécuter de bout en bout une opération sensible sans contrôle.

Sujet ancien du contrôle interne (audit, finance), la SoD s’est imposée comme un contrôle central de la gouvernance des identités. Cet article la traite du côté IAM/IGA : ce que recouvre exactement le contrôle, comment il est formalisé techniquement, et comment l’opérationnaliser dans un projet d’habilitations.

Qu’est-ce que la séparation des tâches ?

La séparation des tâches consiste à répartir entre plusieurs personnes les étapes d’un processus sensible, de telle sorte qu’aucune ne puisse, seule, mener le processus à terme. L’objectif est double : prévenir la fraude (un acteur seul ne peut commettre et dissimuler) et réduire les erreurs (le passage par un tiers crée un contrôle naturel).

Le principe précède l’IAM : il est issu du contrôle interne et de l’audit financier. Avec la généralisation des systèmes d’information, sa mise en œuvre est devenue indissociable de la gestion des droits d’accès — d’où sa place centrale en gouvernance des identités.

L’ISO/IEC 27001:2022 le formalise comme un contrôle à part entière dans son Annexe A, sous le numéro 5.3 (séparation des tâches). Il s’agit de l’un des socles normatifs sur lesquels une démarche IGA peut s’appuyer pour justifier l’exigence.

SoD statique et SoD dynamique : deux variantes formalisées

Le standard RBAC (ANSI/INCITS 359) distingue deux modes de mise en œuvre, distinction utile pour concevoir le contrôle.

La SoD statique (Static Separation of Duties, SSoD) interdit à un même utilisateur de se voir attribuer simultanément des rôles déclarés incompatibles. La vérification a lieu au moment de l’octroi : si l’on tente de donner à une personne un rôle qui entre en conflit avec un autre rôle déjà détenu, l’opération est bloquée.

La SoD dynamique (Dynamic Separation of Duties, DSoD) est plus souple : l’utilisateur peut détenir les deux rôles, mais ne peut pas les activer en même temps dans une même session. Concrètement, lorsqu’il prend l’un, il ne peut prendre l’autre qu’après l’avoir abandonné.

La SSoD est plus stricte et plus auditable ; la DSoD ouvre une flexibilité utile quand les fonctions se chevauchent légitimement (par exemple un responsable qui occasionnellement remplace l’un de ses collaborateurs). Dans les deux cas, la règle d’incompatibilité reste la même — c’est l’instant de son application qui diffère.

La matrice SoD : la pierre angulaire

Tout contrôle SoD repose sur une matrice qui formalise les couples de tâches incompatibles. Pour chaque processus sensible, on liste les responsabilités qui ne doivent pas être cumulées : créer un fournisseur / approuver les paiements ; saisir une commande / valider la réception ; ouvrir un compte / valider les transactions ; développer une application / la déployer en production ; et ainsi de suite selon les processus de l’organisation.

Trois principes pour qu’une matrice soit exploitable :

D’abord, elle se définit avec le métier, pas par l’IT seule. Les responsables des processus financiers, commerciaux, opérationnels ou techniques sont les seuls à pouvoir juger des incompatibilités réelles. Une matrice imposée par la DSI sans le métier n’a aucune autorité et finit par être ignorée.

Ensuite, elle s’exprime au niveau des tâches ou des rôles métier, pas des permissions techniques. La granularité « créer un fournisseur » est compréhensible et stable ; la granularité « transaction SAP FK01 » ne l’est pas pour un responsable métier et change avec l’outil. Les règles techniques sont ensuite dérivées de la matrice métier. La démarche de role mining peut aider à structurer ces rôles métier à partir des permissions existantes.

Enfin, la matrice évolue. Nouveaux processus, réorganisations, changements de système, retours d’audit : un projet SoD prévoit la gouvernance de cette matrice dans la durée, pas seulement sa création initiale.

Opérationnaliser la SoD dans un projet IGA

Une fois la matrice établie, la mise en œuvre suit en général ces étapes :

1. Traduire la matrice en règles techniques. Les incompatibilités exprimées au niveau métier sont converties en couples de rôles ou de permissions interdits dans les systèmes.
2. Détecter les conflits dans l’existant. Sur des organisations matures qui n’ont jamais structuré leur SoD, la première analyse révèle généralement de nombreux conflits hérités. C’est attendu : la valeur n’est pas dans le décompte, elle est dans le traitement.
3. Traiter les conflits. Trois options s’offrent pour chacun : supprimer l’un des droits, recomposer les rôles pour que l’incompatibilité disparaisse, ou accepter explicitement le conflit avec un contrôle compensatoire documenté (par exemple, double validation, revue rapprochée des opérations concernées). L’acceptation tacite, en revanche, est ce qu’il faut absolument éviter.
4. Prévenir les conflits futurs. Intégrer la vérification SoD aux processus d’attribution (workflow de demande d’accès), aux mobilités internes (JML) et aux campagnes de recertification.
5. Gouverner les exceptions. Toute exception (contrôle compensatoire) a un propriétaire, une justification, une date de revue. Sans cette discipline, les exceptions se multiplient jusqu’à vider la SoD de son sens.

Cas particuliers et limites

Dans une petite structure, la séparation effective des tâches peut être impossible : il n’y a tout simplement pas assez de personnes pour répartir certaines responsabilités. La réponse n’est pas de feindre une SoD inexistante mais de mettre en place des contrôles compensatoires explicites — typiquement la revue régulière des opérations par un tiers (responsable, comptable externe, auditeur).

La SoD inter-applications est le cas le plus difficile. Tant que les incompatibilités restent dans un même système (par exemple un ERP), la détection est techniquement abordable. Quand elles s’étendent entre plusieurs systèmes (un ERP, un outil bancaire et un outil de gestion des contrats par exemple), il faut une vue consolidée des droits, ce que vise précisément une plateforme IGA.

Enfin, la SoD ne se confond pas avec le principe du moindre privilège. Le moindre privilège consiste à ne donner que ce qui est strictement nécessaire ; la SoD interdit certains cumuls, même si chaque droit pris isolément est légitime. Les deux principes se combinent : on applique le moindre privilège pour chaque rôle, et la SoD entre les rôles.

Erreurs fréquentes

• Une matrice définie par l’IT seule. Sans légitimité métier, elle n’est ni respectée, ni défendable en audit.
• Une matrice trop fine. Vouloir tout couvrir produit des règles ingérables et beaucoup de faux conflits. Mieux vaut couvrir solidement les processus à haut risque que recouvrir toute l’organisation à demi.
• Une détection ponctuelle. Vérifier les conflits une fois par an, pour l’audit, manque l’objectif : la SoD doit être vérifiée au plus près des événements (attribution, mobilité, recertification).
• Pas de gouvernance des exceptions. Les contrôles compensatoires sans propriétaire et sans revue se transforment en cumuls de droits non contrôlés.
• Confondre SoD et conformité documentaire. Une matrice bien rangée dans un classeur ne protège de rien si elle n’est ni appliquée techniquement, ni surveillée.

FAQ

Quelle différence entre SoD statique et SoD dynamique ? La SoD statique interdit d’attribuer simultanément des rôles incompatibles ; la SoD dynamique autorise leur détention mais interdit leur activation simultanée dans une même session. Les deux variantes sont formalisées dans le standard RBAC.

La SoD est-elle obligatoire ? Elle est exigée explicitement ou implicitement par de nombreux cadres : ISO/IEC 27001:2022 (contrôle 5.3), réglementations financières et sectorielles, exigences d’audit interne. Au-delà de l’obligation, elle reste un des contrôles les plus efficaces contre la fraude et l’erreur.

Peut-on faire de la SoD sans outil dédié ? À petite échelle et dans un seul système, oui — par revue manuelle et contrôles compensatoires. Dès que l’on couvre plusieurs systèmes et un volume significatif d’utilisateurs, un outil (généralement intégré à une plateforme IGA) devient nécessaire pour détecter les conflits à l’attribution et lors des recertifications.

Que faire des conflits hérités, parfois nombreux ? Les prioriser par risque, puis pour chacun trancher : supprimer, recomposer les rôles, ou accepter explicitement avec un contrôle compensatoire documenté. L’objectif n’est pas zéro conflit mais zéro conflit non géré.

Conclusion

La séparation des tâches n’est pas un contrôle administratif de plus : c’est l’un des plus efficaces pour limiter la fraude et l’erreur, et il est inscrit en clair dans les référentiels que les organisations doivent respecter. Sa réussite ne tient pas à la sophistication de l’outil mais à la qualité de la matrice définie avec le métier, au traitement explicite des conflits, et à une gouvernance des exceptions tenue dans la durée. Pour démarrer concrètement, le plus utile est d’identifier les trois ou quatre processus à plus haut risque, d’y construire une matrice solide avec leurs responsables, et d’en faire un contrôle systématique des attributions et recertifications avant d’élargir.

Sources

• ISO/IEC 27001:2022, Annexe A — contrôle 5.3, Séparation des tâches.
• ANSI/INCITS 359, Information Technology – Role Based Access Control (édition 2004 ; révision INCITS 359-2012, reconduite R2022). Standard formalisant les variantes statique (SSoD) et dynamique (DSoD) de la séparation des tâches dans un modèle RBAC.