Identitymanagement ten onrechte geen kerncompetentie
Het aantal beschikbare services is omvangrijk, variërend van directory-integratie en provisioning tot single sign-on en role-based access control (RBAC). De materie is ingewikkeld: behalve van de techniek is kennis vereist van bedrijfsprocessen, organisatiestructuren en regelgevingen en standaards.
Maar juist doordat identitymanagement zo’n effectief instrument is en zulke grote voordelen biedt, gaan organisaties nogal eens gehaast en daarmee niet altijd doordacht te werk bij het invoeren van een identitymanagementomgeving. Omdat identitymanagementtrajecten gecompliceerd zijn en een langdurig – en daarmee kostbaar – karakter hebben, is het van belang dat de benodigde services en bijbehorende producten met zorg worden geselecteerd, dat de juiste volgorde wordt aangehouden bij het implementeren ervan en dat de omgevingsfactoren voldoende worden onderkend.
Op de stoep
Een factor die een verstorende rol kan spelen bij het invoeren van een identitymanagementomgeving wordt gevormd door de leveranciers van identitymanagementproducten. Zodra zij lucht krijgen van een project, staan zij – overigens met de beste bedoelingen – op de stoep om een gratis proof of concept aan te bieden of om door middel van een demo de kwaliteit van de producten aan te tonen. Afgezien van het feit dat een proof of concept of demo nauwelijks garandeert of de producten geschikt zijn voor een productieomgeving, kan een productsuite pas worden geselecteerd nadat de vele selectiecriteria zijn vastgesteld, van een wegingsfactor zijn voorzien en de producten van meerdere leveranciers hieraan zijn getoetst.
Dat vaststellen van die selectiecriteria is geen detail, want er moet niet alleen naar de functionaliteit van de productsuite worden gekeken, maar ook naar allerlei andere aspecten. Zo is het belangrijk om te weten of de betreffende leverancier in staat is de business van de organisatie te begrijpen, op een adequate wijze support kan leveren en of er voldoende kennis en expertise van de productsuite in de markt beschikbaar is. Omdat bijna altijd meerdere identitymanagementproducten nodig zijn om de vereiste functionaliteit te kunnen invullen, is een belangrijke vraag of de leverancier alle noodzakelijke tooling kan leveren of dat producten van meerdere leveranciers moeten worden betrokken. In het laatste geval moet worden bekeken of de producten compatibel zijn met elkaar. De grote leveranciers van identitymanagementproducten leveren bijvoorbeeld geen tool waarmee businessrollen kunnen worden gemodelleerd en geadministreerd – nodig voor role-based access control – waardoor deze van een andere leverancier moet worden betrokken.
Omdat bij de productselectie heel wat om de hoek komt kijken, is het bijna altijd af te raden om – wat nogal eens voorkomt – op voorhand een leverancier en een productsuite te kiezen, bijvoorbeeld omdat men al producten van dezelfde leverancier gebruikt. Keer op keer komt het voor dat een productsuite niet de functionaliteit biedt die nodig is, of niet goed aansluit op andere producten.
De selectiecriteria voor een productsuite kunnen pas worden vastgesteld, nadat de functionele specificaties voor de toekomstige identitymanagementomgeving zijn opgesteld en als services in een architectuur zijn beschreven. Ook bij het opstellen van deze functionele specificaties wordt nog wel eens wat over het hoofd gezien. Zo is niet alleen het beschrijven van de relevante processen van belang, zoals het in dienst nemen van nieuwe medewerkers en het toekennen van autorisaties, maar ook het definiëren van alle benodigde identiteitsgegevens (zie kader). Het bepalen van die gegevens en het identificeren van de bronnen hiervan is een wezenlijk aspect van het identitymanagementtraject – vooral bij directory-integratie en provisioning is het nodig om te weten welke gegevens waar gelokaliseerd, gesynchroniseerd of aangemaakt moeten worden.
Zekerheid
Sommige identitymanagementservices kunnen andere als basis vereisen. Voor het automatiseren van de toekenning van op businessrollen gebaseerde autorisaties is het nodig om een provisioningservice te implementeren. Ook voor single sign-on is het nuttig – maar niet strikt noodzakelijk – dat eerst een provisioningservice wordt geïmplementeerd, omdat dan meer zekerheid wordt verkregen dat de accountgegevens waartoe single sign-on toegang biedt, actueel zijn. Indien een organisatie sterke authenticatie wil toepassen voor de interne omgeving, dan is het een goed idee om hierbij single sign-on als infrastructuur te gebruiken, omdat dit niet alleen de technische implementatie vergemakkelijkt, maar ook de acceptatie door gebruikers van de inherent gebruiksonvriendelijke sterke authenticatie bevordert. Andersom geldt ook: single sign-on biedt een potentiële hacker de mogelijkheid om met één user ID en wachtwoord toegang te verkrijgen tot een veelheid aan applicaties en vereist daarom sterke authenticatie voor extra beveiliging.
Maar elk identitymanagementtraject begint met het vaststellen en prioriteren van de businessrequirements of businessdrivers (zie kader). Want zonder dat deze in kaart zijn gebracht is het niet mogelijk om de functionele specificaties en daarmee weer de identitymanagementservices te bepalen waarmee aan de businessrequirements tegemoet wordt gekomen. Wil een organisatie bijvoorbeeld de kosten terugbrengen die gemoeid zijn met het beheer van accountgegevens, of de risico’s verminderen die gerelateerd zijn aan het achterblijven van accountgegevens van ex-medewerkers, dan ligt een provisioningservice voor de hand. Moeten daarentegen, bijvoorbeeld vanuit het oogpunt van wet- en regelgeving, autorisaties meer transparant en controleerbaar worden ingericht, dan komen role-based access control en audit- en rapportageservices in aanmerking. Klagen gebruikers over de vele wachtwoorden die zij moeten onthouden, dan is een passwordmanagementservice hierop een van de mogelijke antwoorden.
Eigen initiatief
Het bovenstaande laat zien dat een identitymanagementproject aan de kant van de business begint en pas in latere instantie bij de ICT-afdeling aanlandt, zelfs al zijn de businessdrivers ICT-gerelateerd. In de praktijk zien we echter dat het dikwijls de ICT-afdeling is, die het eerst de problemen met betrekking tot identitymanagement signaleert en op eigen initiatief het identitymanagementproject aanzwengelt. Vaak verzanden dergelijke initiatieven, doordat het ontbreekt aan steun vanuit de business en daarmee ook aan budget. Daarom moet de ICT-afdeling bij het signaleren van knelpunten in een vroegtijdig stadium steun zoeken bij vertegenwoordigers van de business en samen met hen een businesscase opstellen. Wanneer de businessdrivers gerelateerd zijn aan risicomanagement of wet- en regelgeving, moeten ook vertegenwoordigers van de security- of auditafdeling betrokken worden.
Door wie ook de eerste stap gezet wordt, identitymanagementprojecten vereisen samenspraak en samenwerking tussen diverse partijen binnen de organisatie. Daar komt nog bij dat meestal ook de nodige weerstanden overwonnen moeten worden (zie kader). Een en ander wordt nog eens extra gehinderd door het feit dat identitymanagement geen kerncompetentie is binnen de meeste organisaties. Dat is wat dergelijke projecten complex maakt.
Dr. Rob van der Staaij (rob.vander.staaij@capgemini.com) is werkzaam bij Capgemini