Étude State of IAM

Démo gratuite Contactez-nous
Toxic Policies

Toxic Policies

Qu'est-ce que les Toxic Policies ?

HelloID prend en charge votre gouvernance des identités, notamment grâce à la fonctionnalité Toxic Policies. Celle-ci permet d'empêcher l'attribution de droits d'accès à une personne si elle dispose déjà d'autres droits conflictuels. Cela évite ainsi l'octroi de licences coûteuses et superflues. La fonctionnalité contribue également à la prévention de la fraude et d'autres comportements indésirables, car les utilisateurs ne peuvent pas accumuler discrètement trop de droits.

Motivation à l'origine de notre fonctionnalité Toxic Policies

La raison d'être de la fonctionnalité Toxic Policies tient au fait que, dans HelloID, l'émission et la gestion des comptes et des droits d'accès reposent sur le contrôle d'accès basé sur les rôles (RBAC). Le principe de base est que le rôle d'une personne dans l'organisation détermine les comptes et les droits d'accès dont elle a besoin. Nous appliquons à cet égard une approche avancée. Au lieu d'un cadre rigide où tous les droits sont définis par rôle, nous utilisons des business rules. Il s'agit de règles exploitables qui permettent, par exemple dans un établissement de santé, de définir simplement que toute personne ayant la fonction « Aide-soignant niveau 4 » obtient l'accès au Dossier électronique du client.

L'avantage est que vos administrateurs peuvent travailler avec ce type de règles de politique compréhensibles sans devoir se plonger dans la structure technique sous-jacente avec rôles, attributs et droits. Il n'est pas nécessaire non plus de lier chaque droit d'accès à des rôles individuels. Vous pouvez par exemple définir simplement que toute personne au sein de votre entreprise obtient un compte Microsoft 365, quelle que soit sa fonction spécifique. De nombreux droits s'appliquent aussi à tous les employés d'un même service ou par site. Au final, il existe souvent un nombre limité de droits qui doivent réellement être définis de manière spécifique au rôle. Dans un modèle RBAC traditionnel, tous les droits doivent être associés aux rôles, ce qui entraîne rapidement une explosion du nombre de rôles et rend la maintenance très complexe. Avec les business rules, nous gardons le tout simple et maîtrisable; vous pouvez vous concentrer sur vos règles de politique et HelloID traduit ces règles en une « pyramide de droits » cohérente et consistante.

Il existe toutefois un point d'attention. Pour chaque collaborateur, plusieurs business rules peuvent s'appliquer en pratique. Nous avions déjà donné l'exemple d'une business rule qui définit de manière générale que chaque collaborateur doit obtenir une licence Microsoft 365. En tant que membre d'un service spécifique, vous pouvez ensuite obtenir l'accès au partage de ce service, ce qui constitue une business rule supplémentaire. Et selon le rôle ou les rôles de la personne dans l'organisation, d'autres règles peuvent s'appliquer pour attribuer les droits d'accès associés. Bien que chaque business rule individuelle soit correcte en soi, des doublons ou des contradictions peuvent parfois apparaître en raison de combinaisons de règles. Il convient évidemment de les éviter et, pour cela, la fonctionnalité Toxic Policies est l'outil idéal.

Exemples de Toxic Policies

Rendons ce qui précède concret avec deux exemples. Dans le premier exemple, deux business rules (règles métier) contradictoires entraînent l'émission de licences inutiles. Dans l'autre exemple, les business rules attribuent des droits d'accès conflictuels:

  • Exemple 1: Microsoft propose différentes licences Enterprise telles que E1 et E3. Une personne disposant d'une licence E3 bénéficie de fonctionnalités supplémentaires par rapport à E1. Tandis que tout le monde dans l'organisation reçoit par défaut une licence E1, business rule 1, certains collaborateurs ayant un rôle spécifique doivent recevoir une licence E3, business rule 2. Les business rules sont correctes en elles-mêmes, mais certains collaborateurs reçoivent à la fois une licence E1 et une licence E3; c'est inutilement coûteux.

  • Exemple 2: Dans une organisation, vous disposez d'un logiciel pour saisir des commandes et d'une fonctionnalité pour approuver les factures. S'il existe une règle qui accorde à quelqu'un la possibilité de saisir des commandes, ce même collaborateur ne doit pas aussi avoir la possibilité d'approuver les factures correspondantes. Si cela se produit malgré tout, parce que la personne a reçu par erreur les deux rôles, cette combinaison de business rules rompt la séparation des tâches au sein de votre organisation.

La fonctionnalité Toxic Policies peut aider à éviter de telles combinaisons indésirables, à réduire les coûts et à limiter les risques de fraude.

Comment gérons-nous les Toxic Rules dans HelloID ?

Nous montrons le fonctionnement dans le module HelloID Provisioning, dans lequel nous appliquons ces business rules. Prenons l'exemple des licences E1 et E3, où tout le monde dans l'organisation reçoit par défaut une licence E1, mais où les collaborateurs IT doivent recevoir une licence E3:

  • Sans la fonctionnalité Toxic Policies, une évaluation des licences attribuées sur la base des business rules montre que tout le monde a reçu une licence E1 et que les collaborateurs IT ont également reçu une licence E3. Il s'agit donc d'un doublon coûteux.

  • Vous pouvez maintenant activer la fonctionnalité Toxic Policies et configurer une nouvelle toxic combination. Vous y définissez que si quelqu'un obtient à la fois des droits pour une licence E1 et une licence E3, seule la licence E3 doit être attribuée.

  • Après l'activation de cette "toxic combination", vous constatez que tous les utilisateurs à qui les deux licences avaient été attribuées ne reçoivent plus qu'une licence E3. Vous voyez également pour les utilisateurs concernés un message indiquant qu'un droit leur a été refusé, à savoir la licence E1.

  • Ces paramètres sont évidemment également appliqués dans les systèmes cibles concernés. Si les droits conflictuels avaient déjà été accordés auparavant, les licences E1 devenues redondantes sont révoquées après l'activation de cette toxic combination.

Aide à la conformité

Avec l'exemple ci-dessus, vous évitez des coûts de licences superflus, mais vous pouvez également utiliser la fonctionnalité Toxic Policies pour soutenir la Séparation des tâches au sein de votre organisation.

La séparation des tâches est importante dans la politique des organisations et constitue aussi une exigence de nombreuses directives de sécurité de l'information. Dans certaines certifications, il est par exemple indiqué que « les tâches et responsabilités conflictuelles doivent être séparées afin de réduire la probabilité de modification non autorisée ou involontaire ou d'abus des actifs de l'organisation ». Nous avons déjà cité l'exemple du collaborateur qui émet des devis et qui ne doit donc pas non plus être autorisé à approuver les factures.

Cette séparation des rôles est souvent définie à un niveau plus élevé dans l'organisation puis traduite en fonctions par collaborateur, qui sont enregistrées par exemple dans le système RH. La plateforme IAM veille ensuite à ce que chacun obtienne les droits appropriés en fonction de son rôle et d'autres attributs tels que le service et le site. Votre environnement IAM est par conséquent particulièrement adapté pour implémenter les derniers détails de cette séparation des rôles ou pour en assurer le contrôle. Vous le faites en configurant des toxic combinations qui appliquent la bonne solution en cas de combinaisons indésirables; dans l'exemple mentionné, il existe donc une toxic combination comprenant le droit de créer des factures face au droit d'approuver des factures.

Avec le module HelloID Provisioning, nous pouvons donc attribuer des droits d'accès de manière automatisée sur la base d'attributs tels que le rôle d'une personne, ses compétences, son service et ou son poste de travail. Et avec la fonctionnalité Toxic Policies, nous pouvons éviter d'accorder trop de droits à un utilisateur individuel.

Faut-il utiliser les Toxic Policies ou uniquement les business rules ?

Pourquoi utiliser la fonctionnalité Toxic Policies. Nos business rules peuvent aussi être configurées de manière très flexible. Ne pouvons-nous pas atteindre le même résultat en détaillant davantage nos business rules avec par exemple des conditions supplémentaires. Parfois, c'est possible, mais le problème est que vous affaiblissez alors la force du concept de business rule. Vous souhaitez garder vos business rules aussi claires et simples que possible et ne pas les compliquer inutilement avec toutes sortes d'exceptions. C'est pourquoi la fonctionnalité Toxic Policies constitue un complément parfait, car elle permet justement d'identifier et de traiter ces exceptions de manière simple.

Illustrons-le à nouveau avec l'exemple des licences Microsoft. Pour les licences E1 et E3, il s'agit en réalité des détails des licences Microsoft. Une licence E3 est un super-ensemble de E1; si vous avez E3, vous n'avez pas besoin de E1. Chez un autre éditeur, cela peut fonctionner de manière totalement différente; deux licences peuvent être complémentaires et vous en aurez besoin des deux. Ce type de détails de licences n'a rien à voir avec le rôle, le service, les compétences, etc., et perturbe votre modèle de rôles et vos business rules. Nous résolvons cela en laissant uniquement les business rules déterminer qui a besoin de quels droits et fonctions sur la base des rôles et d'autres attributs. Et s'il apparaît ensuite qu'une licence superflue risque d'être attribuée, nous l'évitons grâce aux Toxic Policies.

En bref, la force des business rules réside dans leur relative simplicité. Grâce aux Toxic Policies, vous conservez cette simplicité tout en laissant de la place aux exceptions. L'exception confirme la règle. Avec HelloID, nous le faisons grâce aux Toxic Policies.

En savoir plus sur notre fonctionnalité Toxic Policies ?

Vous voyez qu'avec la fonctionnalité Toxic Policies, vous pouvez professionnaliser davantage la gestion des comptes et des droits, réduire les coûts de licences et veiller à votre conformité. Elle constitue ainsi un élément important de votre gouvernance dans HelloID. Vous souhaitez en savoir plus sur l'utilisation du module de gouvernance en général ou spécifiquement sur la fonctionnalité Toxic Policies. Contactez nous ou consultez notre page gouvernance.

Articles associés

Qu'est-ce que la fonctionnalité Toxic Policies ?

Avec la fonctionnalité Toxic Policies de HelloID, vous pouvez détecter et supprimer des droits conflictuels, les toxic policies, en définissant des règles qui déterminent quels droits doivent être conservés en cas de conflit. Cela vous aide à améliorer la sécurité et à éviter des coûts de licences inutiles.

Qu'est-ce qu'une règle de politique ?

Une règle de politique est une directive claire, formalisée au sein d'une organisation, qui précise par exemple comment un processus est exécuté, qui détient quelles autorisations ou selon quels critères une décision est prise. Les règles de politique font partie de votre politique d'entreprise ou en sont dérivées et garantissent une collaboration cohérente et transparente.

Qu'est-ce qu'une business rule (ou règle métier) ?

Une business rule, en français règle métier, est en général un accord sur la manière dont un processus ou une activité spécifique est exécuté au sein d'une organisation. Dans notre contexte IAM HelloID, c'est une règle qui permet de formaliser notre modèle de rôles. Vous pouvez par exemple définir dans une business rule que toute personne ayant le rôle « Aide-soignant niveau 3 » obtient toujours l'accès à l'application de soins.