Gestandaardiseerd identity management
Enkele jaren geleden heb ik voor een opdracht onderzocht of het mogelijk zou zijn om een identity managementsysteem te ontwikkelen voor hoger onderwijsinstellingen dat goedkoper zou zijn om te implementeren en ‘as a service’ zou kunnen worden aangeboden.
Een behoorlijk aantal hoger onderwijsinstellingen vond een dergelijk systeem namelijk (te) duur qua implementatie en beheer. En terecht. Maar niets aan identity management doen betekent vaak dat de veiligheid van de ICT diensten in het geding is en is ook geen optie.
De conclusie van het onderzoek was dat het ten dele zou kunnen, maar dat ook een deel specifiek zou blijven voor iedere implementatie. Echte eenheidsworst zal het nooit worden. Of je het dan ‘as a service’ afneemt of zelf beheert, is niet zo relevant voor de mate van standaardisatie. In hoeverre standaardisatie mogelijk is, wordt hieronder uitgelegd.
Als u nu denkt, leuk artikel, maar ik heb geen idee wat identity management is, dan verwijs ik u graag naar andere bronnen voor uitleg. Heel in het kort komt het erop neer dat identity management bestaat uit processen de ondersteunende techniek daarvoor, die het beheer en gebruik van accounts (gebruikersnamen en wachtwoorden) en rechten van gebruikers in meerdere ICT-systemen veiliger, gebruiksvriendelijker en vaak ook goedkoper maken. Resultaten van de invoering van een identitymanagementsysteem zijn:
- gebruikers hebben dezelfde gebruikersnaam en wachtwoord voor meerdere aplicaties en kunnen via selfservice veel regelen dat voorheen via een service desk liep.
- beheerders hebben minder handwerk te verrichten bij het aanmaken van accounts.
- een uniforme oplossing voor alle applicaties, waardoor het zicht op wie wanneer welke rechten heeft veel groter is.
- bewuster omgaan met wachtwoorden (want een gebruiker hoeft er nog maar een te onthouden).
De processen hebben te maken met uitgifte en weer intrekken van accounts en rechten in applicaties, op het netwerk en eventueel ook voor fysieke toegang, het wijzigen en opnieuw uitgeven van wachtwoorden, het wijzigen van rechten en de rapportages over alles wat bij het voornoemde mis gaat. Het streven is om dit zoveel mogelijk geautomatiseerd te doen en dat streven leidt er vaak toe dat de systemen die hiervoor worden ingezet ook worden gebruikt om het verspreiden en, waar mogelijk, genereren van zaken die te maken hebben met communicatie (telefoonnummers, emailadressen, personeelsnummers, etc.), direct mee te automatiseren. Het inzetten van een identity managementsysteem heeft alleen nut als er een diversiteit van systemen gebruik maakt van accounts, rechten en communicatiegegevens. Maar dat is bij een organisatie van enige omvang, zoals een hogeschool of universiteit al snel het geval.
Omdat elke applicatie technisch anders om gaat met deze aspecten, is het vaak ook technisch een uitdaging om dit te bewerkstelligen. Maar de echte angel zit hem in de processen en daarna in de technische detailuitwerking ervan. Het implementeren van de techniek is dan niet zo heel lastig meer. Dus lijkt het zaak om de processen en de technische uitwerking goed te beschrijven. Maar identity management is geen app op een iPad die je even kunt laten zien, het is vaak weerbarstige materie die voor de vele betrokkenen, want dat zijn namelijk de voor de verschillende ICT-systemen verantwoordelijke personen, de HR-afdeling (die bepalen wie überhaupt accounts krijgen), een veiligheidsfunctionaris, de CIO, de lijnmanagers en eindgebruikers (die de gevolgen gaan ondervinden) en vaak nog meer mensen, lastig voor de geest te halen is, laat staan dat zij de impact kunnen inschatten.
Kortom de problemen met een identitymanagement-implementatie, voordat aan de technische uitwerking wordt begonnen, zijn evident:
- De vele betrokkenen moeten het eens worden over de inhoud van de processen.
- Zij moeten zich kunnen voorstellen waar de technische implementatie toe leidt.
De ervaring met implementatietrajecten is dan ook dat er voortdurend en ook tijdens de technische realisatie voortschrijdend inzicht is bij de betrokkenen. Dit maakt een implementatie natuurlijk erg duur.
Sommige leveranciers zijn de uit de softwareontwikkeling populaire ‘agile’ projectmethoden gaan toepassen op de implementatie van identity management. Daarbij wordt steeds een stukje functionaliteit gedefinieerd en gebouwd en vervolgens getoond aan de klant. Die kan dan wijzigingen doorgeven die nog worden geïmplementeerd. Door limieten qua menskracht en tijd te stellen aan ieder stukje implementatie, kan een project dan vaak in de hand worden gehouden, hoewel de project managementoverhead per definitie aanzienlijk is door de gegeven beperkingen.
In het hoger onderwijs zag ik echter een andere mogelijkheid. Na meerdere implementaties te hebben gedaan, ben ik er van overtuigd geraakt dat de processen op hoofdlijnen hetzelfde zijn voor alle hoger onderwijsorganisaties. Dat bleek ook uit de feedback bij presentaties over dit onderwerp. In detail verschillen ze wel. Maar stel nu dat een een bepaalde uitwerking van de processen wordt voorgelegd en aan de organisatie de keuze wordt gelaten om zich aan te passen aan deze processen (meestal geen erg ingrijpende aanpassingen) of om de uitwerking zelf te gaan doen? En stel dat een implementatie die aan de voorgelegde processen voldoet, ook getoond kan worden? En stel dat je kunt voorrekenen dat een implementatie volgens zelf gedefinieerde processen gemiddeld twee keer zo duur is? Dan zullen een aantal organisaties kiezen voor de standaardprocessen. Dit idee is succesvol uitgewerkt en in die uitwerking is ook bedacht dat de technische uitwerking van de standaardprocessen en de technische implementatie zelf, die helaas door de diversiteit van ICT-systemen en de inrichting daarvan overal anders zijn, toch voor een vast bedrag gedaan kunnen worden. Een ervaren leverancier weet immers best hoeveel tijd die twee zaken kosten, want op dat moment ben je de discussie en politiek al grotendeels voorbij, maar komt het aan op inventariseren, vastleggen en implementeren. ‘Standaard maatwerk’ is hier een mooie term voor, die feitelijk betekent: een stukje maatwerk voor een standaard prijs.
Daarmee kwam een propositie tot stand die helaas nog niet tot veel implementaties heeft geleid, maar wel tot het inzicht dat in enige mate gestandaardiseerd identity management mogelijk is.
Uiteraard zijn hier niet alle aspecten van een identity managementsysteem belicht. Functioneel niet en ook niet qua governance en beheer. Maar een standaard aanpak kan ook daarbij veel hulp bieden.