‘Met één druk op de knop alle deuren dicht’

Daar zorgt de medewerker zelf wel voor. Ook het omgekeerde is belangrijk: individuen die geen toegang meer nodig hebben, dienen ook geen toegang te krijgen.
Vaak zijn individuen (of het nu werknemers, externe medewerkers, partners, leveranciers of klanten zijn) op verschillende plaatsen geregistreerd. Naast het bedrijfsnetwerk nog op applicaties van het bedrijfsnetwerk: in CRM-, personeels-, salaris- en leaseadministraties en in verschillende IT-systemen (bijvoorbeeld een Oracle-database waar je apart op moet inloggen). En tegenwoordig ook steeds vaker in (mobiele)telefoniesystemen en in allerhande administraties voor diverse resources (bijvoorbeeld toegangscontrolesystemen). Deze registraties staan in de meeste gevallen los van elkaar. Daardoor is het lastig om de integriteit van een registratie vast te stellen.
Het probleem is dat de autorisaties van de relatie niet integraal geblokkeerd/verwijderd worden bij overplaatsing (doorstroom) of vertrek (uitstroom). Hier komt integraal identiteitsbeheer (zie kader) om de hoek kijken. Bij overplaatsing blijven de identiteitsgegevens wel bestaan, maar is het voor wat betreft functiescheiding en ‘least privilege’ (alleen de strikt noodzakelijke autorisaties voor het uitoefenen van de nieuwe functie) niet gewenst om de ‘oude’ autorisaties (logisch én fysiek) nog te hebben.
Neem bijvoorbeeld een user-id. Hoe vaak komt het niet voor dat user-id’s van vertrekkende medewerkers nog ‘in leven’ worden gehouden door andere medewerkers of nieuwe medewerkers. In veel organisaties bestaat geen beleid om user-id’s die lang niet gebruikt worden, te controleren. Of ze worden standaard na negentig dagen geblokkeerd en daarna verwijderd, terwijl de desbetreffende persoon op zwangerschapsverlof is of een ‘sabbatical’ heeft. Of de user-id’s worden simpelweg vergeten. Wanneer een medewerker de organisatie verlaat, worden user-id’s vaak illegaal hergebruikt, omdat het aanvraagproces van een nieuwe autorisatie te lang duurt. Dit is overigens in de meeste gevallen in strijd met de beleidsregels, die stellen dat een user-id persoonlijk is. En wat gebeurt er met andere functionele accounts waarvan de medewerker eigenaar was?

Rode knop
Hoewel binnen veel organisaties (impliciete) identiteitsbeheerprocessen aanwezig zijn, zijn deze vaak niet efficiënt en effectief geïmplementeerd. In een recent onderzoek van het Genootschap van Informatiebeveiligers (GvIB) wordt zelfs aangegeven dat de meeste organisaties geen inzicht hebben in de huidige autorisaties. Met de implementatie van identiteitsbeheer wordt niet alleen het aanvraagproces sneller, waardoor user-id’s niet hergebruikt hóeven te worden door anderen, ook wordt een ‘rode knop’ geïmplementeerd voor de manager. Met één druk op de knop gaan alle (logische) deuren dicht. Gebruik wordt gemaakt van het mechanisme van ‘provisioning’ (zie kader).
Identiteitsmanagementsystemen (inclusief provisioning; IDMS), die tegenwoordig op verschillende systemen aanwezig zijn, functioneren technisch goed. Het IDMS is echter wel afhankelijk van een betrouwbare toelevering van gegevens. Zo moeten bij een overplaatsing of vertrek de brongegevens worden aangepast, zodat het IDMS z’n werk kan doen. Als deze gegevens niet worden aangeleverd (vaak procedureel ingeregeld), zal het mechanisme niets doen. Aan de andere kant is ‘opvolging’ ook belangrijk, zeker wanneer het niet volledig geautomatiseerd is. Als bijvoorbeeld een beheerder het bericht van het provisioningsysteem niet verwerkt, zal het beveiligingsstelselsysteem alsnog niet werken.

Parkeren
Ook fysieke beveiligingssystemen (zoals fysieke toegangssystemen, sleuteladministraties, pasjessystemen) zijn een belangrijk onderdeel bij identiteitsbeheer, want het is een van de eerste beveiligingsschillen. Deze worden vaak niet meegenomen, omdat er alleen vanuit de IT gekeken wordt. Met fysieke toegang worden overigens niet alleen de toegang tot een gebouw en de compartimenten (ruimten) binnen een gebouw bedoeld, maar ook de toegang tot alle resources van een organisatie, zoals de toegang tot (fysieke en elektronische) dossiers, materiaal, installaties, auto’s, telefoons en pda’s.
Een praktijkvoorbeeld is de toegang tot een parkeergelegenheid door middel van nummerbordherkenning; een innovatief systeem, maar de procedures eromheen waren niet goed ingericht. Een collega kon vier maanden na het einde van zijn opdracht nog gewoon doorrijden om te parkeren. Een ander voorbeeld is de bedrijfsspecifieke id-kaart die zichtbaar gedragen moet worden. Bij veel organisaties is het innameproces wel beschreven, maar door diverse uitzonderingssituaties komt het vaak voor dat het pasje niet wordt ingeleverd. Na maanden kun je met je pasje nog een aardig eind komen. Wanneer het pasje dan ook nog eens niet uit de toegangscontrole-administratie wordt gehaald, kunnen zelfs zonder toezicht, deuren worden geopend. Om deze systemen aan te kunnen sluiten is het overigens wel noodzakelijk dat er een fysieke koppeling is met het provisioningsysteem of een berichtensysteem met procedurele opvolging.
Al deze lagen hebben een eigen beheer nodig. Hier komt de architect om de hoek kijken, die de identiteitenregistraties op conceptueel niveau aan elkaar kan koppelen en daarbij rekening kan houden met (wettelijke) kaders, bijvoorbeeld de wet bescherming persoonsgegevens. Het is namelijk noodzakelijk dat de beveiligingslagen dezelfde (informatiebeveiligings) beleidsregels toepassen en integraal samenwerken. Daarbij wel rekening houdend met de functiescheiding. Het heeft niet alleen geen zin, het werkt ook frustrerend, wanneer je wel toegang krijgt tot de eerste ‘deur’, maar daarna niet kan werken omdat de tweede ‘deur’ dicht zit. Daarmee is niet gezegd dat alle deuren automatisch open moeten gaan (een grove vorm van single-sign-on). De verschillende lagen kunnen bewust gescheiden zijn. Maar de beheerloketten van de deuren dienen wel allemaal op de hoogte te zijn (al dan niet geautomatiseerd) van een mutatie in het personeels-, partners-, klanten- en leveranciersbestand.
Daarnaast moet er natuurlijk een beleid zijn over de te nemen acties. Eventueel kan een aantal afgesproken acties al gerealiseerd worden. Men kan preventief blokkeren. Zo kan men een tankpasje (tijdelijk) of een toegangspasje blokkeren, of een laptop weigeren aan te sluiten op het netwerk.

Inzicht
Doordat inzicht ontstaat in wie welke resources in gebruik heeft, is het tevens beter mogelijk om aan licentiebeheer en portfoliomanagement te doen. Welke resources worden niet meer gebruikt en kunnen dus worden afgevoerd? Hoeveel voorraad heb ik van een resource nodig? Et cetera.
Het is overigens aan te raden bij de initiële implementatie van een provisioningsysteem niet meteen het hele arsenaal aan administraties te koppelen. Wel is het goed om te weten welke administraties er allemaal zijn, wat de onderlinge verbanden zijn, en te beslissen welke administratie wordt meegenomen. Dat kan dus al bij de architectuur.

Drs. ing. Jan-Roel Löwenthal CISSP is senior adviseur informatiebeveiliging bij de discipline Technology Services van Capgemini Nederland B.V. (janroel.lowenthal@capgemini.com).