Qu’est-ce que la séparation des tâches (SoD) en matière de cybersécurité ?

Les contrôles et les contre-mesures de cybersécurité dépendent souvent de la volonté d’empêcher une personne de disposer de privilèges étendus lui permettant d’utiliser le système à mauvais escient. Par exemple, la personne qui octroie l’accès à des données sensibles ne doit pas être la même que celle qui demande cet accès. De même, un designer de l’équipe marketing ne doit pas se voir accorder des privilèges étendus sur les systèmes internes, y compris l’accès aux données des clients. 

La clé : veiller à ce que l’accès des utilisateurs à l’information soit adapté à leur fonction et aussi limité que possible. 

Pour atteindre cet objectif, il faut appliquer un principe connu dans la cybersécurité sous le nom de séparation des tâches, ou Separation of Duties (SoD) voire parfois Segregation of Duties. La SoD est également essentielle au respect de nombreuses réglementations et bonnes pratiques métiers.

Qu’est-ce que la séparation des tâches (SoD) en matière de cybersécurité ?

La séparation des tâches (SoD) est un principe de sécurité fondamental qui garantit qu’aucune personne n’a la capacité d’exécuter toutes les parties d’un processus critique. En répartissant les responsabilités entre plusieurs rôles, la SoD réduit le risque d’erreurs accidentelles, de menaces internes et d’utilisation malveillante des systèmes. Elle est particulièrement importante dans les environnements où des données sensibles et des accès privilégiés sont impliqués (finance, santé, informatique d’entreprise, etc.).

Dans le domaine de la cybersécurité, la SoD permet d’éviter les modifications non autorisées, les compromissions de données et les abus de privilèges, et ce en demandant à plusieurs personnes d’effectuer ou d’approuver des actions sensibles. Il s’agit également d’une exigence clé pour certains cadres réglementaires tels que le RGPD, SOX et HIPAA. Lorsqu’elle est implémentée de manière efficace, la SoD renforce la posture de sécurité globale d’une organisation et favorise la transparence, la responsabilité et l’intégrité opérationnelle.

Comprendre la séparation des tâches dans le domaine de la cybersécurité

Selon le National Institute of Standards (NIST), qui publie les principaux frameworks de cybersécurité en vigueur, la SoD fait référence au "principe selon lequel aucun utilisateur ne devrait avoir suffisamment de privilèges pour utiliser à lui seul le système à mauvais escient".

Le concept de contrôle de la cybersécurité est consubstantiel au principe de la SoD. Un contrôle est un mécanisme ou une politique qui empêche une cybermenace d’aboutir. (Il ne fait pas que cela, mais pour notre propos, cela suffira). En ce sens, la SoD fait partie de nombreux contrôles. Chaque contrôle a un objectif précis, par exemple empêcher quelqu’un de supprimer des données sans autorisation. 

Dans ce cas, la SoD rend plus difficile l’accès, la modification ou la suppression de données par un utilisateur non autorisé. La SoD prévient à la fois les abus internes et externes. Elle implique également la décomposition des tâches de gestion informatique et des opérations de cybersécurité en plusieurs étapes pouvant être confiées à plusieurs personnes différentes.

Cependant, les abus en interne ne sont pas les seuls risques associés à de mauvaises politiques SoD. Un acteur externe malveillant pourrait notamment exploiter une SoD déficiente, s’introduire dans un réseau, puis élever ses privilèges au point de pouvoir causer des ravages dans l’environnement.

La SoD est présente dans de nombreux domaines, et pas seulement dans l’informatique et la cybersécurité. Dans le secteur financier, par exemple, une même personne ne peut pas demander l’autorisation d’exécuter une transaction financière risquée, puis l’approuver elle-même. Dans le domaine de la santé, un médecin rédige une ordonnance, mais c’est un pharmacien qui dispense le médicament. 

L’importance de la séparation des tâches en matière de cybersécurité

Lorsqu’elle est appliquée à la lettre, la SoD confère un certain nombre d’avantages aux organisations, notamment :

• Atténuer la menace interne : les acteurs internes peuvent aussi être mal intentionnés. C’est une réalité malheureuse du monde de l’entreprise et des pouvoirs publics. Afin d’atténuer les menaces internes, la SoD stipule souvent la manière dont les administrateurs doivent gérer les approbations pour les modifications de données et l’accès au système.

• Prévention des erreurs et des accidents : la SOD peut prévenir les erreurs et les accidents qui affectent directement la sécurité. Par exemple, la SoD peut autoriser ou obliger un administrateur système à examiner les actions entreprises par un collègue. Cela peut s’avérer utile pour les mises à niveau ou les migrations de systèmes importantes, où une erreur peut provoquer une panne ou exposer un système à un risque cyber. La réduction de l’empreinte d’accès peut également permettre d’atteindre des objectifs similaires en termes de contrôle,  car elle limite l’accès des utilisateurs aux systèmes et réduit les possibilités d’erreur.

• Conformité réglementaire : la SoD est partie intégrante de nombreux cadres réglementaires, en particulier dans les domaines de la finance et de la comptabilité. Par exemple, la loi américaine Sarbanes Oxley (SOX), qui régit la manière dont les sociétés cotées en bourse documentent et auditent leurs contrôles comptables, exige une séparation vérifiable de tâches telles que l’approbation des achats, l’évaluation des actifs, la comptabilisation des recettes et la préparation des états financiers. Toutes ces limites doivent également se refléter dans les contrôles relatifs à l’accès des utilisateurs et aux audits dans ce domaine. Par exemple, un système d’approvisionnement ne permet pas à un utilisateur d’approuver sa propre demande d’achat au-delà d’un certain montant budgétaire, conformément aux règles de la SoD. 

• Renforcer l’intégrité et la disponibilité des données : la DoS devrait renforcer l’intégrité et la disponibilité des données en appliquant le « principe des quatre yeux », qui exige qu’au moins deux personnes examinent certaines actions critiques ou sensibles.

Concepts connexes et bonnes pratiques

La séparation des tâches se recoupe avec d’autres contre-mesures et modes de contrôle rattachés au domaine de la cybersécurité. Il est conseillé de prendre un moment pour les étudier et examiner en quoi ces éléments diffèrent de la SoD :

• Principe du moindre privilège (PoLP) : le PoLP est un principe de limitation d’accès qui restreint les privilèges d’un utilisateur du système au strict minimum. Il permet d’éviter les situations dans lesquelles un acteur malveillant peut exploiter des privilèges, tels que l’accès aux données. Par exemple, si vous avez deux bases de données, l’une pour les données clients et l’autre pour les données financières, les membres de l’équipe de vente ne devraient avoir le droit d’accéder qu’aux données clients. C’est le moindre privilège possible. La PoLP peut s’inscrire dans le cadre de la SoD, comme dans le cas du partage des privilèges et de leur attribution à différentes personnes. Le Zero Trust est un concept connexe, dans lequel aucun utilisateur ne peut être considéré comme digne de confiance par défaut. Dans le cas des données Zero Trust dans le cloud, par exemple, les utilisateurs n’ont accès aux données qu’après vérification et n’obtiennent alors que l’accès le plus limité possible.

• Contrôle d’accès basé sur les rôles (RBAC) : la séparation des rôles est inhérente à la SoD, par exemple en répartissant les utilisateurs par classes de privilèges allant de simple utilisateur à administrateur, voire « super administrateur ». Chaque niveau d’utilisateur possède des privilèges de plus en plus importants. Le contrôle d’accès basé sur les rôles (RBAC) est un concept voisin, dans lequel les privilèges d’un utilisateur sont déterminés par son rôle au sein de l’organisation. Par exemple, une personne occupant un rôle d’encadrement peut être habilitée à approuver les demandes de privilèges d’accès.

•  Séparation des environnements : une bonne pratique IT et de sécurité consiste à séparer les environnements, tels que le développement, les tests et la production. Cette pratique permet d’éviter les dommages volontaires ou involontaires aux données et aux systèmes en production. La SoD s’applique également dans ce domaine, où les utilisateurs doivent être approuvés séparément pour l’accès à chaque environnement.

• Intégrité à deux personnes (TPI) : cette mesure de contrôle exige l’intervention de deux personnes pour accomplir une tâche. L’un des exemples emblématiques peut être la nécessité pour deux hauts gradés de tourner chacun une clé simultanément pour lancer un missile à tête nucléaire. Le TPI s’apparente à la SoD en ce sens que la tâche est répartie entre deux personnes, mais il diffère de la SoD qui, elle, sépare la tâche en deux parties.

• Logiciel de gestion des informations et des événements de sécurité (SIEM) : une solution SIEM permet aux analystes sécurité d’analyser et d’interpréter de grandes quantités de journaux et d’autres flux de données pour y déceler des événements de sécurité. Certains SIEM peuvent détecter d’éventuelles infractions aux politiques SoD, par exemple si le même identifiant d’appareil est utilisé pour demander et approuver une élévation des privilèges.  

Les défis de la séparation des tâches

L’implémentation de la SoD peut poser des problèmes, dont certains sont liés au décalage entre les principes intrinsèques et la capacité de certaines solutions à les mettre en œuvre. Un système comptable, par exemple, peut permettre aux administrateurs de paramétrer des workflows dépourvus de contrôles SoD, même si ces contrôles constituent une obligation réglementaire.

Un problème plus important est tout simplement le processus manuel de mapping des règles SoD, des rôles et des utilisateurs, puis leur implémentation. Avec les arrivées/départs de collaborateurs et l’évolution des workflows, la SoD peut vite présenter des défaillances. Il y a aussi la simple question de la paresse. Si un manager partage son mot de passe à ses N-1 parce qu’il ne veut pas être dérangé à chaque fois que quelqu’un a besoin d’une dérogation, c’est toute la SoD qui s’effondre.

Ces difficultés peuvent s’aggraver lorsqu’il s’agit de gérer des données cloud ou multicloud. Dans ce type de scénario, le mapping des contrôles SoD, des rôles et des autorisations associées peut s’avérer plus complexe et difficile que dans le cas des systèmes traditionnels sur site.

Bonnes pratiques d’implémentation de la SoD

Pour atteindre ses objectifs, la SoD doit suivre un ensemble de bonnes pratiques. Des audits réguliers et des mises à jour des rôles sont essentiels à cet égard. Il est impératif de bien maîtriser l’évolution des contrôles et des workflows soumis à SoD, tout en restant informé des situations dans lesquelles la SoD a cessé de fonctionner. Des outils d’audit spécialisés permettent d’y parvenir. Il peut être difficile d’assurer un suivi des contrôles qui couvrent plusieurs systèmes et rôles d’utilisateurs. En ce sens, le monitoring des données peut s’inscrire dans cette pratique. Pour savoir où se trouvent des données sensibles, il faut d’abord déterminer qui peut y accéder et si des contrôles SoD doivent être mis en place pour les protéger.

Une bonne pratique consiste également à définir clairement les rôles de chacun. Il s’agit en partie d’une question d’organisation, qui touche au management plutôt qu’aux technologies. Plus la réflexion et la planification sont approfondies, meilleurs seront les résultats de la SoD. Rubrik, par exemple, sous-tend ce processus par ses fonctionnalités de contrôle et de reporting des accès.

La sensibilisation et la formation sont également importantes. La SoD est d’abord une question de personnes et d’organisation. D’où l’importance de sensibiliser les collaborateurs à son fonctionnement. En effet, la plupart d’entre eux ne sont probablement pas familiers avec ce concept. Mais s’ils comprennent qu’une seule personne ne peut pas approuver toutes les autorisations, par exemple, alors cela aidera la SoD à remplir sa mission.

Comment implémenter la SOD

Le principe de la séparation des tâches est à la base de nombreux contrôles et contre-mesures de cybersécurité essentiels. Contrôles d’accès, sécurité réseau, sécurité des données… ces trois domaines, pour ne citer qu’eux, présenteront des failles dès lors qu’une personne peut s’auto-attribuer de multiples privilèges. Quatre yeux valent presque toujours mieux que deux. 

Une SoD efficace passe par de bonnes pratiques et de bons outils. Les solutions SoD se composent de logiciels spécialisés qui permettent de suivre les rôles et les tâches, auxquels doivent s’ajouter des solutions de gestion des données, de contrôle d’accès et d’autres aspects de la sécurité. Le suivi et l’audit sont également essentiels. Lorsque tous ces éléments sont réunis, le principe de la SoD peut s’étendre à l’ensemble de l’écosystème informatique.

Foire aux questions

Qu’est-ce que la séparation des tâches (SoD) dans le domaine de la cybersécurité ?

La SoD est un système de contrôle qui empêche les utilisateurs d’obtenir des privilèges qui leur permettraient d’utiliser un système à mauvais escient, par exemple en permettant à un utilisateur d’élever ses privilèges d’accès.

Quels sont les principaux avantages de la séparation des tâches en matière de cybersécurité ?

Dès lors qu’elle est implémentée dans les règles, la SoD réduit le risque de compromission de données et d’autres risques causés par un accès non autorisé et des privilèges excessifs permettant d’exécuter des tâches système, par exemple la création de comptes d’utilisateurs.

Comment implémenter la séparation des tâches pour renforcer la cybersécurité ?

L’implémentation de la SoD commence par une définition claire des politiques régissant chaque tâche et chaque utilisateur autorisé à l’accomplir. À partir de là, l’implémentation de la SoD consiste à appliquer ces politiques par le biais de systèmes sous-jacents, notamment des solutions de gestion des identités et des accès (IAM) et de gestion des accès privilégiés (PAM), ainsi que les applications qu’elles protègent.