Ce guide s'adresse aux responsables informatiques et sécurité d'entreprises de 50 à 500 personnes à qui un auditeur, ou un client grand compte, vient de demander de prouver qu'une même personne ne peut pas à la fois demander un accès et l'accorder. Si vous cherchez la séparation des tâches en comptabilité fournisseurs ou sur le cycle achats, ce n'est pas cette page qu'il vous faut.
La séparation des tâches en IAM est le contrôle qui empêche une même personne de détenir une combinaison de permissions lui permettant de mener seule un processus sensible, par exemple créer un fournisseur et valider son paiement, ou demander un accès et se l'accorder. Dans un environnement SaaS de PME, le conflit se loge rarement dans une seule application : il est réparti entre le SIRH, l'outil de facturation, le dépôt de code et le fournisseur d'identité, ce qui explique pourquoi une revue manuelle passe à côté. L'appliquer consiste à écrire quelles paires de permissions sont interdites, à détecter qui les détient aujourd'hui sur l'ensemble du parc connecté et non connecté, puis à prouver à un auditeur que vous les avez trouvées et corrigées. Le contrôle d'accès basé sur les rôles et les revues d'accès planifiées sont ce qui rend cela opérationnel.
À retenir
- Séparation des tâches et ségrégation des tâches désignent le même contrôle : les publications du NIST parlent de separation of duties, la série ISO 27000 et les référentiels comptables parlent de segregation of duties.
- Un conflit SoD dans un parc SaaS est un problème inter applicatif, et aucun des huit guides classés sur ce sujet en août 2026 ne mentionne SCIM, l'offboarding ou le cycle joiner-mover-leaver une seule fois.
- La CNIL est plus explicite que le RGPD lui-même : sa fiche sur la gestion des habilitations demande de définir les profils en séparant les tâches et de mener une revue des habilitations a minima annuelle, avec les métiers.
- Une équipe IT de deux personnes ne peut pas séparer toutes les tâches, et les Trust Services Criteria derrière SOC 2 le disent explicitement : là où la séparation n'est pas praticable, la direction retient des contrôles alternatifs.
- Le contrôle nommé se trouve dans l'annexe A 5.3 de la norme ISO/IEC 27001:2022. NIS2 et le RGPD n'emploient jamais l'expression, ce qui change ce que vous avez réellement à prouver.
Qu'est-ce que la séparation des tâches en IAM, et est-ce la même chose que la ségrégation des tâches ?
Oui, c'est le même contrôle, et la différence de nom tient à la famille normative, pas au sens. Le glossaire du Computer Security Resource Center du NIST référence SoD comme abréviation de separation of duty et le définit, en citant la publication NIST SP 800-192, comme le principe selon lequel aucun utilisateur ne doit disposer d'assez de privilèges pour détourner le système à lui seul. La norme ISO/IEC 27001:2022 nomme la même idée segregation of duties dans son contrôle 5.3 de l'annexe A. Le référentiel comptable COSO dit également segregation. En français, séparation des tâches, ségrégation des tâches et séparation des fonctions circulent indifféremment. Rien ne se joue sur le choix du mot, et toute page qui vous vend une distinction entre les deux vous vend une distinction que les organismes de normalisation ne font pas.
Ce qui se joue en revanche, c'est l'écart entre la version comptable du contrôle et sa version IAM. Elles partagent un principe et presque rien d'autre à l'exécution.
Le même principe, deux surfaces de contrôle très différentes
| Dimension | SoD comptable | SoD en IAM |
|---|---|---|
| Unité de séparation | Quatre fonctions : autorisation, garde des actifs, enregistrement, rapprochement | Paires de permissions détenues par une identité, à travers plusieurs systèmes |
| Où se loge le conflit | Dans un processus, généralement dans un seul grand livre ou un seul ERP | Entre applications, souvent entre une application et le fournisseur d'identité |
| Qui est concerné | Les collaborateurs qui exécutent des transactions financières | Toutes les identités, y compris prestataires, comptes de service et agents IA |
| Comment on détecte l'écart | Rapprochement et échantillonnage par un auditeur interne | Analyse des habilitations sur tout le parc, ce qui n'est pas échantillonnable à la main |
| Comment on corrige | Réattribuer la tâche à une autre personne | Modifier le rôle, révoquer l'habilitation, ou insérer une étape de validation |
Le NIST fournit également les deux modes d'application sur lesquels vous serez interrogé. L'application statique définit des rôles en conflit qui ne peuvent pas être exécutés par le même utilisateur, ce qui rend le conflit impossible par construction. L'application dynamique impose le contrôle au moment de l'accès, et sa forme la plus connue est la règle des quatre yeux, où le second validateur peut être n'importe quel utilisateur autorisé autre que le premier. La plupart des parcs de PME finissent avec un mélange des deux : le statique là où le fournisseur d'identité sait l'exprimer, le dynamique là où seule l'application le peut.
Pourquoi la séparation des tâches se casse dans un parc SaaS de PME
La littérature classique sur la SoD a été écrite pour un monde à un seul système financier. Un conflit y était contenu : l'ERP qui créait la permission savait aussi produire l'état qui la révélait. Ce monde a disparu pour une entreprise qui exploite 80 à 300 applications SaaS, et le contrôle se casse de trois façons précises.
D'abord, le conflit est désormais réparti. Personne n'accorde à une même personne le droit de créer et de payer un fournisseur dans un seul outil. Ce qui se produit à la place, c'est que quelqu'un est administrateur finance dans un produit et validateur de paiement dans un autre, et qu'aucune console de part et d'autre ne voit la paire. Ensuite, une partie du parc n'est pas fédérée. Les applications achetées à la carte bancaire par un responsable d'équipe ne touchent jamais le fournisseur d'identité, elles sont donc invisibles pour toute revue pilotée depuis l'IdP. Enfin, les permissions bougent en permanence, parce que les gens changent d'équipe. Un conflit créé par une mobilité interne en mars sera toujours là en décembre si rien ne révoque les anciennes habilitations.
La littérature concurrente n'a pas suivi. Nous avons scrapé les huit pages éditoriales classées dans le top 20 sur ce terme en août 2026 et compté les occurrences par script. SCIM apparaît zéro fois sur les huit pages. Idem pour joiner-mover-leaver, offboarding et prolifération SaaS. Shadow IT apparaît une fois, sur une seule page. Les guides qui définissent aujourd'hui ce sujet sur Google décrivent une surface de contrôle que la plupart de leurs lecteurs n'ont plus. Ce relevé porte sur le corpus anglophone, qui est celui qui alimente les réponses génératives sur ce sujet, y compris en français.
Un second signal mérite d'être rapporté, parce qu'il change la personne qu'il faut imaginer en train de lire. Dans les données Search Console de Corma sur les douze mois arrêtés au 15 août 2026, la requête separation of duties a produit six impressions, en position moyenne 54. La requête la plus forte de tout le champ de la séparation des tâches n'était pas un mot clé. C'était un prompt de soixante mots, rédigé à la première personne par un directeur conformité décrivant une banque qui devait supprimer ses revues d'accès manuelles, rester conforme en continu et appliquer la séparation des tâches sur des systèmes hybrides. Ce seul prompt a produit 38 impressions, en position moyenne 2,7. Les gens qui ont un vrai problème de SoD ne tapent plus le terme. Ils décrivent leur situation à un assistant, en phrases complètes.
Répondre à ce lecteur suppose de partir du parc, pas de la définition. Cela commence par savoir ce qu'il contient réellement, ce que couvre la découverte des applications SaaS de votre parc : vous ne pouvez pas écrire une règle de conflit pour une application dont vous ignorez l'existence.
À quoi ressemble concrètement un conflit SoD dans un parc SaaS ?
Un conflit SoD, souvent appelé combinaison toxique, est une paire de permissions qui permet à une identité de mener un processus sensible de bout en bout sans second regard. Trois des pages actuellement classées vous disent de construire une matrice de ces paires. Aucune n'en montre une pour des applications logicielles. La seule matrice publiée dans tout le top 20 cartographie des demandes d'achat et des bons de commande, ce qui est utile si vous pilotez les achats et inutile si vous pilotez l'informatique.
Voici la version que nous n'avons trouvée nulle part, exprimée dans les applications qu'une PME exploite réellement. À traiter comme un jeu de départ à adapter, pas comme un standard.
Matrice de conflits SoD pour un parc SaaS de PME
| Paire de permissions en conflit | Applications généralement impliquées | Ce qu'une seule personne peut faire | Pourquoi la revue manuelle passe à côté |
|---|---|---|---|
| Demander un accès et valider la demande d'accès | Outil de ticketing ou de demande d'accès, et fournisseur d'identité | S'accorder n'importe quelle habilitation du parc, administrateur compris | La demande vit dans un outil et l'octroi dans un autre, aucun des deux journaux ne montre la boucle |
| Créer ou modifier un fournisseur et valider ou exécuter un paiement | Outil comptable ou de gestion des dépenses, et plateforme bancaire | Inventer un fournisseur et le payer | La finance possède une application, l'IT possède l'autre, et personne ne possède la paire |
| Créer une fiche collaborateur et attribuer les rôles dans l'IdP | SIRH, et Google Workspace, Microsoft Entra ID ou Okta | Créer une personne qui n'existe pas et lui donner des identifiants fonctionnels | La donnée RH est traitée comme source de vérité, donc personne ne revoit qui peut y écrire |
| Écrire du code et déployer en production | Hébergeur Git, et pipeline CI/CD et console cloud | Livrer une modification non relue sur les systèmes en production | Les permissions d'ingénierie sont gérées par l'ingénierie, hors du périmètre de revue IAM |
| Administrer une application et configurer son journal d'audit | Toute console d'administration SaaS avec réglage de rétention | Agir, puis effacer la preuve qu'elle a agi | Les réglages de journalisation ne sont presque jamais traités comme une habilitation à revoir |
| Exécuter la paie et modifier les coordonnées bancaires | Plateforme de paie, parfois seule | Détourner un versement de salaire | Le conflit tient dans une seule application, il ressemble donc à un rôle unique |
| Valider un achat de SaaS et détenir le contrat et ses renouvellements | Outil d'achat ou de gestion des dépenses, et portail éditeur | Engager de la dépense et la reconduire sans contradiction | Les renouvellements sont silencieux par défaut, le conflit ne produit donc jamais d'événement |
Relisez la dernière colonne, c'est tout l'objet du tableau. Chacun de ces conflits est invisible depuis l'intérieur de l'une ou l'autre application. Ce n'est pas un problème de discipline ni de politique interne. C'est un problème de donnée, et c'est la raison pour laquelle le contrôle échoue en pratique bien avant que quiconque devienne négligent.
Il vaut aussi la peine de nommer ce qu'est devenu le risque. La littérature classique sur la SoD est construite autour de la fraude financière, et deux des paires ci-dessus relèvent encore exactement de cela : le faux fournisseur et le salaire détourné. Les cinq autres non. Ce sont de l'escalade de privilèges, de la modification non journalisée et des identités fantômes, c'est-à-dire des défaillances de sécurité et non de comptabilité. Cet écart a une conséquence organisationnelle : un programme SoD entièrement porté par la direction financière attrapera les deux conflits que la finance comprend déjà, et ratera les cinq qui vivent dans l'informatique.
Comment appliquer la SoD avec une équipe IT de deux personnes ?
C'est la question que les guides classés évitent, et c'est celle qui est réellement posée. Sur les forums d'administrateurs système, un administrateur qui pilote une équipe de deux personnes pour environ 160 utilisateurs demande comment structurer les comptes pour satisfaire la séparation des tâches. Sur un autre fil, un petit prestataire en cours d'audit SOC 2 de type II rapporte que les exigences SoD de son client sont quasiment impossibles à tenir à sa taille. Aucun des deux fils n'obtient de réponse nette, et les huit pages que nous avons mesurées n'emploient jamais les mots mid-market, PME ou petite et moyenne entreprise.
La réponse honnête est que vous ne pouvez pas séparer toutes les tâches, et que les référentiels le savent déjà. Les Trust Services Criteria de 2017, qui structurent SOC 2, portent un point of focus sous le critère d'activités de contrôle indiquant que la direction sépare les tâches incompatibles et que, là où cette séparation n'est pas praticable, elle sélectionne et développe des activités de contrôle alternatives. C'est le référentiel lui-même qui vous donne la porte de sortie. La question d'audit n'est donc pas de savoir si vous avez tout séparé. Elle est de savoir si vous avez identifié ce que vous ne pouviez pas séparer, documenté cette décision, et placé un contrôle de détection derrière.
En pratique, cela tient en quatre mouvements. Écrivez les conflits que vous acceptez et pourquoi, en nommant la contrainte plutôt qu'en la masquant. Remplacez la prévention par la détection là où vous n'avez pas de seconde personne, par exemple une revue mensuelle de toutes les actions menées avec un compte à privilèges plutôt qu'une règle qui les bloque. Sortez la validation de l'IT partout où le responsable métier existe, pour que le directeur financier valide les habilitations financières au lieu que l'administrateur système valide les siennes. Et rendez le risque résiduel visible vers le haut, parce qu'un risque accepté que la direction n'a jamais vu n'est pas un risque accepté.
Le coût de réorganisation est réel, et il tombe d'abord sur l'onboarding et l'offboarding. Adrien Guichard, PDG de Citel, industriel français de 400 personnes fondé en 1937, décrit le résultat recherché par son équipe dans le cas client gouvernance IT chez CITEL Guichard : fluidifier l'arrivée et le départ des collaborateurs tout en renforçant la sécurité par des contrôles d'accès fins, depuis un système unifié. Fin est le mot opérant. On n'applique pas une paire de permissions avec un rôle qui en accorde quarante d'un coup.
Comment appliquer la SoD avec le RBAC, les demandes d'accès et les revues d'accès
L'application est une séquence, et sauter une étape est la raison pour laquelle la plupart des programmes SoD s'arrêtent au document de politique. Voici l'ordre qui fonctionne.
- Inventorier le parc, y compris ce qui n'est pas fédéré. Toute application hors du fournisseur d'identité est hors du contrôle. La découverte doit couvrir ce qui a été adopté dans le navigateur et sur les postes, pas seulement ce qui dispose d'un connecteur SSO.
- Écrire les règles de conflit avant les rôles. Prenez la matrice ci-dessus, retirez ce qui ne s'applique pas, ajoutez ce qui manque. Dix paires bien choisies valent mieux que cent héritées d'un gabarit ERP.
- Exprimer en statique tout ce qui peut l'être, dans les rôles. C'est là que le contrôle d'accès basé sur les rôles justifie son existence : si deux habilitations ne peuvent jamais coexister, elles ne doivent jamais figurer dans le même rôle. Définissez les rôles assez finement pour qu'un conflit soit exprimable.
- Faire passer le reste par une validation au moment de la demande. L'application dynamique signifie que la demande part vers quelqu'un qui n'est pas le demandeur. Les demandes d'accès automatisées en self-service sont ce qui empêche le message Slack informel de tenir lieu de piste de validation.
- Détecter les conflits que vous n'avez pas pu prévenir, à échéance régulière. C'est la revue d'accès, et c'est la seule étape qui attrape les conflits créés par une mobilité interne, par une application non fédérée, ou par une règle écrite après l'octroi de l'habilitation.
- Boucler avec la révocation et la preuve. Une revue qui identifie un conflit sans rien révoquer produit un constat d'audit au lieu de l'éviter.
C'est à l'étape cinq que l'approche manuelle s'effondre, et ceux qui font le travail le disent sans détour. Alex Reintjes, IT Support Engineer chez Robovision, décrit le gain de l'automatisation en temps passé sur des tâches manuelles comme les revues d'accès, et non en posture de sécurité. C'est le cadrage honnête : le contrôle n'est pas difficile à comprendre, il est difficile à tenir à échéance régulière avec une petite équipe. Le basculer sur des revues d'accès automatisées et conformes est ce qui transforme une course annuelle en un contrôle qui fonctionne réellement.
Ce que le RGPD, la CNIL, ISO 27001, SOC 2 et NIS2 exigent vraiment sur la SoD
Presque tous les guides sur ce sujet affirment que la SoD est exigée par SOX, ISO 27001, SOC 2 et, dans au moins un cas que nous avons vérifié, par le RGPD. Cette dernière affirmation est fausse au sens strict : le règlement impose des mesures techniques et organisationnelles appropriées à l'article 32 et ne contient nulle part l'expression séparation des tâches ni ségrégation des tâches.
Sauf qu'en France, l'histoire ne s'arrête pas au texte, et c'est le point que les guides anglophones ne peuvent pas voir. La fiche Gérer les habilitations du guide de la sécurité des données personnelles de la CNIL demande, en précaution élémentaire, de définir des profils d'habilitation dans les systèmes en séparant les tâches et les domaines de responsabilité. La même fiche demande de réaliser une revue des habilitations a minima annuelle, en associant les métiers pour qu'ils confirment la légitimité opérationnelle des droits attribués, et de supprimer les permissions dès qu'un collaborateur change de mission ou quitte l'organisation. Le régulateur qui vous contrôlera en France a donc écrit noir sur blanc les deux contrôles que le règlement ne nomme pas.
Ce que chaque cadre dit réellement de la séparation des tâches
| Cadre | Nomme-t-il le contrôle ? | Ce qu'il exige réellement | La preuve attendue par un auditeur |
|---|---|---|---|
| ISO/IEC 27001:2022 | Oui, directement | Contrôle 5.3 de l'annexe A, intitulé segregation of duties, avec les recommandations de mise en oeuvre dans ISO/IEC 27002 sous le même numéro | Le contrôle dans votre déclaration d'applicabilité, les règles de conflit, et les traces montrant que les conflits ont été revus et traités |
| RGPD et doctrine CNIL | Non dans le règlement, oui dans la doctrine | L'article 32 impose des mesures appropriées. La fiche CNIL sur les habilitations demande explicitement de séparer les tâches et de réaliser une revue au moins annuelle avec les métiers | Les profils d'habilitation documentés, et la trace des revues annuelles avec la participation des métiers |
| SOC 2 | Pas comme critère, oui comme point of focus | Les Trust Services Criteria portent la séparation des tâches en point of focus sous CC1.3 et sous le critère d'activités de contrôle, avec une provision explicite pour des contrôles alternatifs quand elle n'est pas praticable | La preuve que le contrôle a fonctionné sur toute la période, pas une photographie : campagnes de revue, validations, révocations |
| NIS2 | Non | La directive (UE) 2022/2555 impose des politiques de contrôle d'accès appropriées au titre des mesures de gestion des risques, et renvoie à la série ISO/IEC 27000, où siège le contrôle nommé | La politique de contrôle d'accès, et la responsabilité de la direction sur les mesures adoptées |
| SOX | Pas dans le texte de loi | La section 404 impose à la direction d'évaluer le contrôle interne relatif à l'information financière. L'attente SoD vient du référentiel COSO utilisé pour y répondre | Ne vous concerne que si votre société est cotée aux États-Unis ou consolidée par une société qui l'est |
Lisez la première colonne en pensant à votre propre entreprise. Si vous êtes une société européenne de 50 à 500 personnes, SOX ne s'applique très probablement pas à vous, tandis qu'ISO/IEC 27001, SOC 2, NIS2 et la doctrine CNIL vous concernent. C'est presque l'inverse de la hiérarchie que vous trouverez dans la plupart des guides sur ce sujet, qui ouvrent sur SOX parce que la littérature a été écrite pour des sociétés cotées américaines. Pour une vue plus large de la couche gouvernance, notre panorama des meilleures solutions IGA pour le mid-market traite le volet plateforme de la même question, et la page rester conforme et gérer les SaaS pour les équipes sécurité en traite le volet opérationnel.
Produire la preuve SoD qu'un auditeur acceptera
Un auditeur n'évalue pas vos intentions, il évalue des artefacts. Quatre d'entre eux portent un contrôle SoD, et chacun a un mode de défaillance qu'il vaut mieux connaître.
- Le registre des conflits. Votre liste nommée de paires de permissions interdites, avec un responsable et une date. Défaillance typique : il existe sous forme de diapositive et non de document tenu à jour.
- Le journal des conflits acceptés. Les conflits que vous ne pouvez pas séparer, chacun avec sa contrainte, son contrôle compensatoire et son validateur. Défaillance typique : le silence, qui se lit comme un écart non détecté plutôt que comme un risque accepté.
- Les traces de revue avec leurs suites. Qui a revu quelles habilitations, quand, et ce qui a été révoqué en conséquence. Défaillance typique : une revue avec cent pour cent de validations, que les auditeurs lisent comme un tamponnage.
- La piste d'audit des changements. Chaque octroi, modification et révocation, horodaté, idéalement non modifiable par la personne qui a effectué le changement. Défaillance typique : des journaux conservés dans l'application dont l'administrateur est justement l'objet de la revue.
Notez que trois de ces quatre artefacts sont des traces du fonctionnement du contrôle dans la durée, et non des descriptions du contrôle. C'est la raison la plus fréquente pour laquelle un premier audit SOC 2 ou ISO 27001 se passe mal sur le volet accès : la politique est correcte et rien ne démontre que quelqu'un l'a appliquée.
Comment Corma vous aide à appliquer la séparation des tâches
Corma est une plateforme européenne de SaaS Management et de gouvernance des identités pour les entreprises de 50 à 500 personnes, construite pour que la couche de contrôle des accès et l'inventaire applicatif vivent dans le même système. Cela compte spécifiquement pour la SoD, parce que les conflits de la matrice ci-dessus ne deviennent visibles que lorsque les deux moitiés de la paire figurent dans la même vue.
Concrètement, Corma construit un inventaire tenu à jour en continu des applications, des identités et des habilitations, couvrant les applications fédérées, non fédérées et le shadow IT, pour que les règles de conflit atteignent des applications qui ne touchent jamais le fournisseur d'identité. Corma achemine les demandes d'accès vers un validateur autre que le demandeur, ce qui constitue la moitié dynamique du contrôle. Corma oriente les demandes vers le moindre privilège et applique le contrôle d'accès basé sur les rôles, ce qui en constitue la moitié statique. Corma automatise les changements du cycle joiner-mover-leaver, ce qui empêche une mobilité interne de créer silencieusement un conflit. Et Corma exécute des revues d'accès planifiées avec le contexte d'habilitation dont les relecteurs ont besoin, produisant les traces de revue et la piste d'audit qu'un évaluateur demandera. Corma est certifiée ISO/IEC 27001:2022 et hébergée dans l'Union européenne, ce qui est la même question de preuve, un cran au dessus.
Vous pouvez voir comment les briques s'assemblent sur la page gouvernance des identités, et la définition courte du contrôle vit dans notre fiche SoD du glossaire IT. Si vous voulez voir vos propres conflits plutôt qu'une matrice générique, demandez une démo et nous parcourrons votre parc.
Questions fréquentes
Quelle est la différence entre séparation des tâches et ségrégation des tâches ?
Il n'y en a aucune sur le fond. Les publications du NIST emploient separation of duties, tandis qu'ISO/IEC 27001 et les référentiels comptables emploient segregation of duties. En français, séparation des tâches, ségrégation des tâches et séparation des fonctions désignent le même contrôle : celui qui empêche une personne de détenir assez de privilèges pour mener seule un processus sensible.
Quels sont les principes clés de la séparation des tâches ?
Aucune identité ne détient une paire de permissions en conflit. Les conflits sont définis à l'avance plutôt que découverts pendant un audit. La prévention s'applique là où les systèmes savent l'exprimer, la détection là où ils ne le savent pas. Et tout conflit qui ne peut pas être séparé est documenté et doté d'un contrôle compensatoire.
Une petite entreprise peut-elle mettre en place une séparation des tâches ?
Oui, mais pas intégralement, et les référentiels le prévoient. Les Trust Services Criteria indiquent que là où la séparation n'est pas praticable, la direction sélectionne et développe des activités de contrôle alternatives. Une petite équipe satisfait un audit en documentant les tâches qu'elle ne peut pas séparer et en surveillant ces activités, pas en faisant semblant de les avoir séparées.
La norme ISO 27001 exige-t-elle la séparation des tâches ?
Oui. ISO/IEC 27001:2022 intègre la ségrégation des tâches comme contrôle 5.3 de l'annexe A, avec les recommandations de mise en oeuvre dans ISO/IEC 27002 sous le même numéro. Son applicabilité dépend de votre déclaration d'applicabilité, et l'exclure suppose une justification documentée.
Que demande la CNIL en matière de gestion des habilitations ?
Sa fiche sur la gestion des habilitations demande de définir des profils en séparant les tâches et les domaines de responsabilité, de réaliser une revue des habilitations a minima annuelle en associant les métiers, et de supprimer les permissions dès qu'un collaborateur change de mission ou quitte l'organisation. Ces recommandations sont plus explicites que le texte du RGPD lui-même.
Quel rôle joue la séparation des tâches dans la gestion des accès à privilèges ?
C'est là qu'elle compte le plus, parce que les comptes à privilèges sont ceux qui peuvent à la fois exécuter une action et modifier la trace de cette action. Les contrôles usuels sont la séparation entre l'administration et la configuration des journaux d'audit, et l'exigence d'un second validateur pour les opérations à privilèges à fort risque, ce que le NIST décrit comme l'application dynamique.
Comment appliquer la SoD sur un grand nombre d'applications SaaS ?
En analysant les habilitations sur l'ensemble du parc plutôt qu'application par application, parce que les permissions en conflit se trouvent généralement dans deux produits différents. Cela suppose un inventaire incluant les applications non fédérées et le shadow IT, des règles de conflit exprimées au niveau de l'habilitation, et des revues planifiées qui produisent des traces de révocation.
