Hvorfor er identitetsforvaltning og tilgangsstyring så vanskelig?

Identitetsforvaltning (IdM) ses som regel i forbindelse med tilgangskontroll (AM), og disse to begrepene er det som utgjør IAM, som står for “Identity and Access Management”.

Historien viser at IAM-prosjekter ofte feiler, faktisk feiler de oftere enn andre IT-prosjekt, og det er som regel IdM-delen av prosjektet som går galt. Hvorfor er det slik? La oss se på et typisk IAM-prosjektforløp.

Et IAM-prosjekt starter veldig ofte med et behov for bedre tilgangskontroll, og fordi tilgangskontroll er en veldig teknisk øvelse å implementere havner dette gjerne hos IT, som et IT-prosjekt. Dette er naturlig, da ord som “system-integrasjon” og “kryptering” ikke er en del av dagligtale hos organisasjonen ellers.

La oss stoppe der, og se på hva tilgangskontroll egentlig er. Det ligger i ordet at det er kontroll av en tilgang, altså det å håndheve en tilgang. Selve administrasjonen av en tilgang, og alt som skjer rundt dette ikke en del av kontrollen. Så hvordan har denne tilgangen blitt gitt? Det ligger ikke noen stor verdi i å kontrollere en tilgang dersom man ikke vet hvordan, og til hvem (og gjerne av hvem) en tilgang er blitt gitt.

Det å faktisk gi tilganger bringer oss over på et eget fagområde innenfor IAM, nemlig tilgangsstyring. Dette området omhandler blant annet ting som å knytte tilganger til en persons brukerkonto i virksomhetens brukerkatalog, for eksempel Active Directory eller et fagsystem. Og fordi det kreves IT-administrative rettigheter til å gjennomføre slike inngrep er det veldig ofte IT som utfører dette. Men hvordan vet IT-medarbeidere hvilke tilganger som skal gis, og til hvilken brukerkonto? Dette er informasjon de er blitt gitt fra forretning, enten som en generell regel eller etter individuelle behov. Allerede her er det en kløft mellom de som definerer de nødvendige tilgangene (forretningssiden) og de som kan gi disse tilgangene (IT-siden).

Det er altså forretningen som definerer reglene for hvem som skal ha tilgang til informasjon i IT-systemene. Forretningen har som regel behov for å gi en bestemt person de nødvendige tilganger, men ikke som person, men heller i form av hvilken rolle eller funksjon denne personen har i virksomheten. La oss derfor se litt nærmere på dette. Det er nemlig slik at systemene ikke har begrep på hva en person er, langt mindre hvilken funksjon en person har. IT-systemer knytter sine regler for tilgang til en brukerkonto. Når en person logger seg inn på et IT-system skjer det en knytning mellom en person og en brukerkonto ved at personen kjenner brukernavnet og passordet til brukerkontoen.

Hvordan vet man så at en spesifikk konto er tilknyttet riktig person, og at brukernavnet og passordet er distribuert til denne? Og hvordan vet man at personen har riktig funksjon eller rolle som gjør at de trenger disse tilgangene? For å samle disse trådene må vi forstå at funksjonen er er knyttet opp mot stillingen til en ansatt eller innleid og at det er HR som forvalter denne informasjonen, vanligvis på vegne av ledere i avdelingen der funksjonen skal finnes. Altså enda en informasjonskløft som må forseres.

Det er derfor nødvendig å samle informasjon om en person (f.eks. navn og personnummer, e-postadresse) og informasjon om stillingen (forretningsrolle, stilling og avdeling). Og hvis denne informasjonen skal kunne brukes effektivt av automatiserte prosesser må denne informasjonen lagres digitalt. La oss kalle denne digitale informasjonen en “ePerson”.

Vi får da følgende informasjon som er knyttet sammen:

Person -> Stilling -> ePerson -> Konto -> Tilgang

De to første elementene forvaltes av HR gjennom prosesser for ansettelse og endring av ansettelsesforhold. Det er gjennom disse prosessene informasjon oppstår eller endres.

Opprettelse av ePerson, konto og tilganger basert på informasjon fra HR er det vi kaller Identitetsforvaltning og Tilgangsstyring. Når vi legger til Tilgangskontroll har man etablert IAM, og først nå mulighet til å gi svar på spørsmålene IT-revisjonen gjerne stiller, “Hvem har tilgang til hva?”, og “Hvem har aksessert hva?”.

Så hvorfor er det vanskelig å lykkes?

• HR er sjelden involvert i prosjektet, og prosessene de kjører er ikke kjent for deltagere i prosjektet.

• Informasjonen om ansatte eksisterer- og flyter gjennom flere IT-systemer og fagmiljøer uten at det er utarbeidet felles begrep for informasjonen eller regler for hva den kan brukes til.

• Dersom manuelle rutiner er brukt for opprettelse og vedlikehold av brukerinformasjon er informasjonen sannsynligvis av langt dårligere kvalitet enn antatt.

• Forretningen føler sjelden ansvar og har ikke dokumentert regler for tilgangsstyring
• Veldig ofte gis det tilgang gjennom uformelle prosesser, særlig fordi det er IT som som regel gjennomfører tilgangsendringer

• Automatisering av prosesser medfører endringer i organisasjonen.
• Ledere får ofte mer ansvar for å styre sine medarbeideres tilganger
• Endringer utført av HR får helt andre konsekvenser enn de er vant med.

• IT har sjelden mandat i forretningen til å ta nødvendige beslutninger

Så hvordan lykkes?

• Fokuser på prosesser, og kartlegg og dokumenter de man har. Å definere eier(e) av prosesser er viktig, og disse er naturlige interessenter i prosjektet.

• Definer et informasjonselement (en "mal") for ansatt og innleid som inneholder den informasjonen de mest opplagte eller dominerende IT-systemene krever.

• Analyser kvaliteten på informasjonen tilknyttet brukerkonti i IT-systemene tidlig. Da har man tid til å iverksette tiltak for å bedre kvaliteten i tide til prosjektets lansering.

• Fokuser prosjektleveranser rundt prosess-støtte, ikke teknologikomponenter. Det er ikke installasjon, konfigurasjon eller integrasjon som er mest tidkrevende i IAM-prosjekt.

• Pass på å ha mandatet til prosjektet forankret godt nok oppover i organisasjonen, og sørg for at det finnes en sponsor med nok gjennomslagskraft. Husk at prosjektets leveranse kan resultere i omorganiseringer, og dette har sjelden IT nødvendig myndighet til å gjennomføre.

• Gjør prosjektet med å etablere IAM så enkelt og konkret som mulig, og inkluder ett eksisterende system som brukes av mange. På denne måten kan man vise til verdi, uten å risikere for mye. Husk, IAM-prosjekter har en dårlig statistikk.

• Når etableringen er satt i produksjon legges en plan for videre integrasjoner som leveres iterativt.

Vi håper at våre erfaringer kan brukes til å sikre at nettopp ditt prosjekt kan lykkes bedre!