Toxic Policies

Wat zijn Toxic Policies?

HelloID ondersteunt je identity governance met onder andere Toxic Policies functionaliteit. Hiermee kunnen we het uitgeven van toegangsrechten aan iemand voorkomen als die persoon ook andere rechten heeft die conflicterend zijn. Zo kunnen we er onder andere voor zorgen dat we geen dure, overbodige licenties gaan verstrekken. Ook helpt het bij de preventie tegen fraude en ander ongewenst gedrag omdat mensen niet ongemerkt teveel rechten kunnen verzamelen.

Aanleiding voor onze Toxic Policies functionaliteit

De aanleiding voor de Toxic Policies functionaliteit zit in het feit dat we binnen HelloID voor de uitgifte en het beheer van accounts en toegangsrechten gebruik maken van Role Based Access Control (RBAC). Het basisprincipe daarbij is dat iemands rol in de organisatie bepaalt welke accounts en toegangsrechten hij of zij nodig heeft. Wij gebruiken binnen HelloID daarvoor bewust een geavanceerde aanpak. In plaats van een rigide raamwerk waarin per rol alle rechten worden vastgelegd, gebruiken wij zogeheten business rules. Dat zijn hanteerbare regels waarin we bijvoorbeeld in een zorginstelling eenvoudig kunnen vastleggen dat iedereen met de functie ‘Helpende niveau 4’ toegang krijgt tot het Elektronisch Cliënten Dossier.

Voordeel hiervan is dat je beheerders kunnen werken met dit soort begrijpelijke beleidsregels zonder zich te hoeven verdiepen in de achterliggende technische structuur met rollen, attributen en rechten. Je hoeft ook niet ieder toegangsrecht te koppelen aan individuele rollen. Je kunt bijvoorbeeld simpelweg instellen dat iedereen binnen je bedrijf een Microsoft 365 account krijgt, ongeacht zijn of haar specifieke rol. En ook zijn er veel rechten die gelden voor alle medewerkers in een bepaalde afdeling of per locatie. Uiteindelijk is er vaak maar een beperkt aantal rechten die echt rol-specifiek ingevuld moeten worden. Bij een traditioneel RBAC model moeten alle rechten aan rollen worden gekoppeld en ontstaat er zo al snel een explosie van rollen en wordt het onderhoud erg ingewikkeld. Bij business rules houden we het eenvoudig en beheersbaar; je kunt je richten op je beleidsregels en HelloID vertaalt die regels naar een consistente, samenhangende ‘piramide van rechten’.

Er is daarbij wel een aandachtspunt. Voor iedere individuele medewerker kunnen in de praktijk meerdere business rules gelden. We gaven al het voorbeeld van een business rule die algemeen bepaalt dat iedere medewerker een Microsoft 365 licentie moet krijgen. Vervolgens kun je als medewerker van een specifiek afdeling ook toegang krijgen tot de afdelingsshare (een aanvullende business rule). En afhankelijk van iemands rol (of rollen) in de organisatie kunnen ook nog andere rules van toepassing zijn om de bijbehorende toegangsrechten te verstrekken. En waar iedere individuele business rule op zichzelf correct is, kunnen door de combinaties van regels soms dubbelingen of tegenstrijdigheden ontstaan. Die wil je uiteraard voorkomen en daarbij is de Toxic Policies functionaliteit het ideale hulpmiddel.

Voorbeelden van Toxic Policies

Laten we het voorgaande concreet maken met twee voorbeelden. Bij de het eerste voorbeeld zorgen twee tegenstrijdige business rules dat er onnodige licenties worden uitgegeven. Bij het andere voorbeeld zorgen de business rules dat conflicterende toegangsrechten worden verstrekt:

• Voorbeeld 1: Microsoft biedt verschillende Enterprise licenties zoals E1 en E3. Daarbij beschikt iemand met een E3 licentie over extra mogelijkheden ten opzichte van E1. Terwijl iedereen in de organisatie standaard een E1 licentie krijgt (business rule 1) zijn er medewerkers met een specifieke rol die een E3 licentie moeten krijgen (business rule 2). De business rules op zichzelf kloppen maar sommige medewerker ontvangen dus zowel een E1 als een E3 licentie; dat is nodeloos kostbaar.
• Voorbeeld 2: In een organisatie heb je een functionaliteit om facturen in te voeren en een functionaliteit om deze goed te keuren. Als er een rule is waarmee iemand de mogelijkheid krijgt om facturen in te voeren, mag diezelfde medewerker niet ook de mogelijkheid krijgen om ze te accorderen. Als dat onverhoopt wel gebeurt – omdat iemand per ongeluk beide rollen heeft gekregen – doorbreekt die combinatie van business rules de rolscheiding binnen je organisatie.

De Toxic Policies functionaliteit kan helpen zulke ongewenste combinaties te voorkomen en zo kosten te besparen en de risico’s op fraude te beperken.

Hoe beheren we Toxic Rules binnen HelloID?

We tonen hoe dit werkt in de HelloID Provisioning module waarin we zulke business rules toepassen. Laten we het voorbeeld nemen met de E1 en E3 licenties waarbij iedereen in de organisatie standaard een E1 licentie krijgt maar waar de IT-medewerkers een E3 licentie moeten krijgen:

• Zonder Toxic Policies functionaliteit zie je dat als we een evaluatie draaien van de uitgegeven licenties op basis van de business rules dat iedereen een E1 licentie heeft ontvangen en dat de IT-medewerkers daarnaast ook een E3 licentie hebben ontvangen. Een dure dubbeling dus.
• Je kunt nu je Toxic Policies functionaliteit activeren en daarbinnen een nieuwe toxic combination configureren. Daarin configureer je dat als iemand zowel rechten krijgt voor een E1 als een E3 licentie, in dat geval alleen de E3 licentie moet worden toegekend.
• Als je die toxic combination activeert, zie je vervolgens dat alle gebruikers die daarvoor beide licenties toegekend hadden gekregen, nu nog alleen een E3 licentie toegekend krijgen. Ook zie je bij de betreffende gebruikers een melding dat hen een recht is geweigerd (namelijk de E1 licentie).
• Uiteraard worden die instellingen ook doorgevoerd in de betreffende doelsystemen. Mochten de strijdige rechten eerder al wel zijn verstrekt, dan worden die overbodige E1 licenties weer ingetrokken na het activeren van deze toxic combination.

Hulp bij je compliance

Met het bovenstaande voorbeeld voorkom je overbodige licentiekosten, maar je kunt de Toxic Policies functionaliteit dus ook gebruiken om de Separation of Duties (functiescheiding) binnen je organisatie te ondersteunen.

Functiescheiding is belangrijk in het beleid van organisaties en ook een eis in veel informatiebeveiligingsrichtlijnen. In de BIO (Baseline Informatiebeveiliging Overheid) staat bijvoorbeeld dat ‘conflicterende taken en verantwoordelijkheden behoren te worden gescheiden om de kans op onbevoegd of onbedoeld wijzigen of misbruik van de bedrijfsmiddelen van de organisatie te verminderen’. We noemden hiervoor al het voorbeeld van de medewerker die facturen uitgeeft en ze dus niet ook mag goedkeuren.

Deze rolscheiding wordt veelal op een hoger niveau in de organisatie al bepaald en vertaalt naar functies per medewerker die wordt geregistreerd in bijvoorbeeld het HR systeem; het IAM platform zorgt er vervolgens voor dat iedereen afhankelijk van die rol – en andere attributen zoals afdeling en locatie – de juiste rechten krijgt. Daarmee is je IAM omgeving dus bij uitstek geschikt om de laatste details van deze rolscheiding te implementeren of erop te controleren. Dat doe je door toxic combinations te configureren die bij ongewenste combinaties de juiste oplossing doorvoert; in het eerder genoemde voorbeeld is er dus een toxic combination met daarin het recht om facturen aan te maken versus het recht om facturen te accorderen.

Met behulp van de HelloID Provisioning module kunnen we dus toegangsrechten geautomatiseerd verstrekken op basis van attributen zoals iemands rol, competenties, afdeling en/of werkplek. En met behulp van de Toxic Policies functionaliteit kunnen we daarbij voorkomen dat we te veel rechten geven aan een individuele gebruiker.

Toxic Policies gebruiken? Of gewoon business rules?

Waarom zou je die Toxic Policies functionaliteit eigenlijk gebruiken? Onze business rules kunnen we toch ook heel flexibel configureren? Kunnen we dan niet hetzelfde bereiken door onze business rules wat verder te detailleren met bijvoorbeeld extra condities? Soms kan dat inderdaad maar het probleem is dat je dan de kracht van het business rule concept ondermijnt. Je wilt je business rules zo helder en eenvoudig mogelijk houden en ze niet nodeloos ingewikkeld maken met allerlei uitzonderingen. Daarom vormt de Toxic Policies functionaliteit een perfecte aanvulling want daarmee kun je juist die uitzonderingen eenvoudig herkennen en oplossen.

We illustreren dat weer aan de hand van het eerder gebruikte voorbeeld van de Microsoft licenties. Bij die E1/E3 licenties gaat het feitelijk om de details van de Microsoft licenties. Een E3 licentie is een superset van E1; heb je E3, dan heb je E1 niet nodig. Bij een andere leverancier kan dat weer helemaal anders werken; daar kunnen twee licenties juist aanvullend zijn en heb je ze beide nodig. Dit soort licentiedetails hebben niets te maken met iemands rol, afdeling, competenties etc. en verwarren je rollenmodel en business rules. Dat lossen we op door de business rules alleen te laten bepalen wie welke rechten en functies nodig heeft aan de hand van rol(len) en andere attributen. En blijkt er dan vervolgens dat er eigenlijk een overbodige licentie dreigt te worden uitgegeven dan voorkomen we dat dankzij de Toxic Policies.

Kortom, de kracht van business rules zijn hun relatieve eenvoud. Dankzij Toxic Policies kun je die eenvoud behouden en tegelijkertijd toch ruimte geven voor uitzonderingen. De uitzondering bevestigt de regel. Bij HelloID doen we dat met Toxic Policies.

Meer weten over onze Toxic Policies functionaliteit?

Je ziet dat je op deze manier aan de hand van Toxic Policies functionaliteit je account- en rechtenbeheer verder kunt professionaliseren, licentiekosten besparen en je compliance bewaken. Zo vormt het een belangrijk onderdeel van je HelloID governance functionaliteit. Wil je meer weten over het gebruik van de governance module in het algemeen of specifiek de Toxic Policies functionaliteit? Bekijk hier dan ons webinar of onze governance pagina.