De 5 meest gemaakte fouten bij IAM-implementaties

De meeste IAM-implementaties die vastlopen, hebben geen technisch probleem. De software werkt zoals bedoeld. Wat mis is gegaan, zit eerder in het traject: een keuze die aan het begin logisch leek en pas maanden later blijkt te knellen. Vijf van die keuzes komen telkens terug.

1. Beginnen bij de techniek in plaats van bij de organisatie

Het patroon is herkenbaar. Er wordt een platform geselecteerd, een implementatiepartner aangetrokken, en de eerste sprint gaat over koppelingen. Ergens in maand drie stelt iemand de vraag welke rollen er eigenlijk moeten komen. Dan blijkt dat niemand weet wie daarover gaat.

Een IAM-platform is een uitvoeringsmechanisme. Het voert uit wat u erin stopt. Als u niet weet welke rollen uw organisatie kent, wie ze mag goedkeuren en wanneer ze vervallen, dan automatiseert u die onduidelijkheid — en wordt het sneller onoverzichtelijk dan voorheen.

Beter: begin met het beantwoorden van organisatorische vragen. Wie is eigenaar van welk systeem? Wie keurt toegang goed? Wat gebeurt er bij functiewisseling? Die antwoorden hebt u nodig voordat een tool ze kan uitvoeren. Ze kosten weken, geen maanden.

2. Het rollenmodel te fijnmazig maken

Bij het ontwerpen van rollen ontstaat vrijwel altijd de neiging naar volledigheid. Elke uitzondering krijgt een eigen rol. Het resultaat is een model met honderden rollen dat theoretisch perfect het principe van minimale rechten volgt.

In de praktijk gebeurt dan dit: een leidinggevende moet toegang aanvragen, ziet veertig vergelijkbare rollen, weet niet welke de juiste is, en kiest de ruimste — want daarmee kan de medewerker in elk geval werken. Het fijnmazige model levert ruimere toegang op dan een grof model zou hebben gedaan.

Beter: mik op een beperkte set basisrollen die het merendeel van de gevallen dekt, met begrijpelijke namen. Uitzonderingen regelt u als losse toekenning met een einddatum. Een rol die niemand begrijpt, wordt niet correct gebruikt, hoe zuiver het model op papier ook is.

3. Uitstroom niet automatiseren

Vrijwel elke organisatie heeft een uitdienstprocedure. In vrijwel elke organisatie is die procedure handmatig, en daarmee afhankelijk van iemand die eraan denkt op een dag waarop veel gebeurt.

Bij een vertrekkende vaste medewerker gaat het meestal goed — er is een afscheid, er is aandacht. Bij een ingehuurde kracht wiens opdracht stilletjes afliep, of iemand die van de ene afdeling naar de andere ging, ontbreekt dat moment. En niemand meldt zich, want ontbrekende toegang tot een systeem dat je niet meer gebruikt, valt niet op.

Beter: koppel uw HR-systeem aan uw identiteitsbeheer, zodat een uitdienstmelding automatisch tot intrekking leidt. Dit is doorgaans de maatregel met de gunstigste verhouding tussen inspanning en risicoreductie. Geef externen bovendien standaard een einddatum die actief verlengd moet worden, in plaats van accounts die tot wederopzegging doorlopen.

4. Serviceaccounts overslaan

IAM-trajecten richten zich vrijwel altijd op medewerkers. Serviceaccounts, koppelingen en geautomatiseerde processen worden doorgeschoven naar een latere fase — die zelden komt.

Dat is precies verkeerd om. Deze accounts hebben doorgaans bredere rechten dan welke medewerker ook, geen eigenaar, geen verlopend wachtwoord, en ze staan op geen enkele uitdienstlijst. Ze draaien jaren door zonder dat iemand ernaar kijkt.

Beter: inventariseer ze vóórdat u aan het grote rollenmodel begint. Wijs elk account een menselijke eigenaar toe die verantwoordelijk is. Breng de rechten terug tot wat het proces daadwerkelijk nodig heeft, en breng de geheimen onder in een beheerde kluis met rotatie. Het zijn er meestal minder dan verwacht, en de risicoreductie per account is groot.

5. Denken dat het traject eindigt bij oplevering

De implementatie is klaar, het rollenmodel staat, het projectteam wordt ontbonden. Twee jaar later is het model niet meer actueel: de organisatie is gereorganiseerd, er zijn systemen bijgekomen, en de uitzonderingen zijn weer opgestapeld.

Toegangsbeheer is geen project met een einddatum, maar een proces dat blijft draaien omdat uw organisatie blijft veranderen. Zonder eigenaarschap na oplevering vervalt elk model binnen enkele jaren naar de situatie van vóór het traject — alleen met duurdere software eronder.

Beter: beleg het eigenaarschap voordat het project eindigt. Wie beoordeelt nieuwe rolaanvragen? Wie voert de access reviews uit en volgt de bevindingen op? Wie kijkt jaarlijks of het model nog past bij de organisatie? Zonder namen bij die vragen is oplevering het begin van verval.