Comment les organisations peuvent-elles appliquer la séparation des tâches dans les contrôles d'accès ?

Séparation des tâches dans les contrôles d'accès

La séparation des tâches et la ségrégation des tâches sont le même contrôle sous deux noms. Les auditeurs ont tendance à dire « ségrégation ». Les équipes informatiques ont tendance à dire « séparation ». Cela signifie la même chose : aucune personne ne doit pouvoir gérer un processus sensible du début à la fin sans une seconde vérification.

Si le même employé peut créer un fournisseur, approuver le paiement de ce fournisseur et rapprocher le compte, rien ne vérifie cette transaction de manière indépendante. SoD rompt la chaîne en attribuant chaque étape à un rôle différent. SOX l'exige pour tout ce qui touche aux rapports financiers, et les auditeurs veulent une preuve que les conflits sont surveillés en continu, pas simplement documentés une fois puis archivés.

Comment appliquer la séparation des tâches

Cartographiez d'abord vos conflits. Créez une matrice des responsabilités listant les paires de rôles ou permissions qui ne devraient pas être attribuées à une seule personne : créer un vendor et approuver les paiements au vendor, créer un bon de commande et approuver cet achat, demander un accès et approuver ce même accès. Une paire est souvent négligée : administrer les contrôles d'accès et administrer les journaux d'audit qui les examinent. Un admin qui peut accorder l'accès et modifier les journaux destinés à détecter les abus a anéanti tout l'intérêt de la journalisation.

Construisez des rôles basés sur la fonction, pas sur les personnes. Une fois que vous connaissez les conflits, attribuez les permissions par rôle plutôt que par individu, et donnez à chaque rôle uniquement ce dont il a besoin. Le principe du moindre privilège fait deux choses ici : il réduit le nombre de combinaisons conflictuelles à suivre et limite l'impact en cas de compromission d'un compte.

Décidez ce que vous allez prévenir versus ce que vous allez détecter. Les contrôles statiques arrêtent une affectation conflictuelle avant qu’elle ne se produise, empêchant quelqu’un d’occuper deux rôles incompatibles. Les contrôles dynamiques laissent passer l’affectation mais la signalent, ou exigent qu’une seconde personne approuve la transaction spécifique ensuite. La plupart des organisations ont besoin des deux. Bloquez d’emblée les conflits évidents. Utilisez une approbation indépendante pour les zones grises qu’une règle générale serait trop brutale pour gérer.

Exigez une seconde personne pour les actions à haut risque. Pour tout ce qui ne peut pas être entièrement séparé par rôle, exigez une approbation indépendante avant la finalisation. Une personne initie, une autre valide. Appliquez cela à la libération des paiements, au déploiement de code ou à tout changement affectant un contrôle financier.

Centralisez où vous pouvez. Plus il y a de systèmes en jeu, plus il est difficile d’appliquer les règles de manière cohérente. Un utilisateur bloqué sur un système par un rôle strict peut toujours avoir un accès actif ailleurs, là où personne n’a pensé à vérifier. Lorsque c’est possible, gérez l’accès via une seule couche afin que la même politique s’applique partout au lieu d’être réinventée système par système.

Examinez les accès selon un calendrier, pas seulement en cas de problème. Les rôles évoluent. Les personnes changent de poste, prennent des responsabilités temporaires, accumulent des accès que personne ne se souvient d’avoir accordés. Planifiez une revue récurrente, confirmez que chaque rôle correspond toujours au poste, et traquez toute dérive.

Documentez les contrôles compensatoires lorsque la séparation réelle n’est pas possible. Les petites équipes ne peuvent parfois pas séparer complètement chaque tâche. Si une personne doit à la fois créer et approuver les bons de commande parce qu’il n’y a personne d’autre, ne vous contentez pas de hausser les épaules et de passer à autre chose. Mettez en place une revue indépendante par un manager et conservez-la dans les archives.

Séparation des tâches dans NetSuite

Le modèle natif de rôles et permissions de NetSuite ne signale pas les conflits SoD pour vous. Vous pouvez créer des rôles et attribuer des niveaux de permission, mais rien dans la plateforme n’indique que deux rôles détenus par la même personne sont en conflit, ni n’empêche l’enregistrement de cette assignation. Ainsi, SoD devient un exercice sur tableur : quelqu’un recoupe chaque rôle, chaque niveau de permission, chaque employé avec la matrice des devoirs, puis recommence à chaque changement de rôle. C’est lent, facile à mal faire, et les auditeurs n’acceptent pas un nettoyage ponctuel comme contrôle continu. Un conflit manqué, une personne pouvant à la fois créer et approuver le même paiement fournisseur, est ce qui transforme un audit propre en liste de remédiation.

StrongpointLe module Advanced SoD de Strongpoint intègre cette application directement dans NetSuite. Commencez avec une bibliothèque de règles prédéfinies construite au fil des années de travail avec des clients et des auditeurs, couvrant les besoins de la plupart des organisations dès le départ. Activez uniquement les règles dont vous avez besoin et créez vos propres règles basées sur les rôles, les permissions, ou les deux, pour un contrôle plus précis des enregistrements personnalisés sensibles lorsqu’il manque quelque chose. Les contrôles de blocage empêchent une affectation incompatible dès que quelqu’un tente de l’enregistrer, la prévention se fait donc en temps réel plutôt qu’à la prochaine revue trimestrielle. Pour les conflits que vous ne pouvez pas bloquer complètement, Strongpoint enregistre l’incident et fait passer toute exemption par une demande de changement et une approbation documentées, de sorte que chaque contrôle compensatoire laisse une trace écrite. Le mode test vous permet de modéliser une nouvelle règle sur des rôles ou employés existants avant sa mise en production, afin de pouvoir l’ajuster avant qu’elle ne soit appliquée. Et Strongpoint enregistre chaque modification de règle, exemption et violation, de sorte que le rapport d’audit SoD et les rapports associés vous fournissent des preuves continues pour les audits SOX au lieu d’une reconstitution de dernière minute de qui avait quel accès et quand.