Identitetsforvaltning i Møre og Romsdal fylkeskommune Identity Management
Hva er identitetsforvaltning? Administrasjon av livsløpet til elektroniske brukere Kontrollert oppretting, vedlikehold og fjerning/arkivering av brukerobjekter i alle datasystemer som forvaltes av Møre og Romsdal fylkeskommune
Hva er en bruker? Brukerobjekt: IT-teknisk begrep som blir brukt i brukerkataloger (LDAP-katalog som f.eks. Active Directory) som representerer en bruker (ofte en fysisk person) i et datasystem. Brukerattributter: Egenskaper til et brukerobjekt. Dette kan være grunndata knyttet til brukeren (fornavn, etternavn, adresse, epost, mobil) eller «metadata» («er ansatt», «er elev», «er arkivert», «er aktiv», «rektor», «leder» osv.) Summen av verdiene i brukerattributtene danner grunnlaget for hvilke systemer brukeren skal ha tilgang til og hvilke verdier som skal legges inn i de ulike datasystemene.
Hvorfor identitetsforvaltning Sikkerhet: Sikre at brukere slettes/arkiveres/deaktiveres når personer slutter i organisasjonen. Sikre at rettigheter og tilganger endres ved endring av ansettelsesforhold Sikre at systemer oppdateres med korrekte data - ikke inneholder personer som ikke skal ligge der. f.eks. i «epostgrupper» Sikre mulighet for innsyn. La brukerne få mulighet til å korrigere data Forenkle rutiner sikre at riktig informasjon kommer fram til riktig person Logging av endringer i tilgagner Datakvalitet: Sikre at datakvaliteten er tilfredsstillende. Brukerdata er lik og korrekt i alle systemer
Programvare for å løse oppgaven Novell Identity Manager (IDM) Fase 1: Lage knytninger mot hvert enkelt system (drivere/connectorer) fra en felles brukerkatalog (som vi kaller «Metakatalogen»). Dette er en teknisk del av prosjektet. Fase 2: utvikle «rollebaserte tjenester» / arbeidsflyt.
Skisse: IDM i Møre og Romsdal fylkeskommune
Faser i prosjektet: 1. Lage knytninger mot systemene Innebærer å lage en knytning mellom metakatalogen og hvert enkelt fagsystem og støttesystemer. Til dette brukes IDM connetorer / drivere som er tilpasset hvert enkelt fagsystem. Her må man avgjøre hvilke systemer som skal være «autorative» for hvert enkelt brukerattributt. Systemer vi har: Metakatalog (ok) Active Directory (ok) Ephorte (delvis ok) Visma Enterprise (ok januar 2012) Lotus Domino (på vent) Skole: ldapat (FEIDE), skoleldap (trådløse nett), brukeradmin
Faser i prosjektet: 2. Sette opp dataflyt og logiske roller Innebærer å analysere hvilke manuelle arbeidsprosesser som går i dag i forbindelse med forvaltning av brukere. Hvordan vil vi ha det i framtiden? Et eksempel... Hva skal en nyansatt få? Brukerkonto for innlogging på PC Nøkkelkort og nøkler Kontor og telefon Programvare og tilganger til områder for å gjøre jobben i den avdelingen han tilhører Tilgang til Visma Tilgang til ephorte Bruker i Lotus Domino Osv...
Faser i prosjektet: 2. Sette opp dataflyt og logiske roller (side 2) Forvaltning av ressurser til brukere Fysiske ressurser (adgangskort, nøkler, PC, kontor) Tilganger til lagringsressurser Tilganger til applikasjoner Tilganger til kursopplegg, seminarer, møter Hvilke ressurser er avhengig av hva den ansatte er «knyttet» til? Knyttet til fysisk lokasjon (fylkeshuset, skole, tannhelseklinikk) Knyttet til avdeling eller seksjon (kultur, IT, regional og næring, avdeling på en skole) Knyttet til rolle (rektor, avdelingsleder) Knyttet til stilling (renhold, vaktmester, lærer, rådgiver) Knyttet til alder (opplegg for de under 30 eller over 60 osv.)
Faser i prosjektet: 2. Sette opp dataflyt og logiske roller (side 3) Portal for administrasjon av dataflyt: «Novell User application» Denne portalen brukes til Administrasjon av egne data Administrasjon av andres data (hvis man har rettigheter til det) Administrere godkjenninger i dataflyt Spørre om tilganger til applikasjoner eller tjenester m.m
Autorativ datakilde Hvilke systemer skal være «autorativ datakilde» for ulike brukerattributter (f.eks.) Visma Enterprise Navn (fornavn og etternavn) Adresse Personnummer Ansattnummer Roller Tittel Metakatalog Brukernavn (generert) Epost (generert) Mobil (manuelt) Attributter som kan endres flere steder Passord (Metakatalog, Active Directory)
Avklare policy ved forvaltning og regler ved konflikter Hvis man kan redigere samme verdien i flere systemer, hvilket system skal være autorativ datakilde? Skal det åpnes for at visse systemer har avvik? - altså, har andre verdier enn det som IDM-systemet legger opp til. Kan være aktuelt for passord i systemer med spesielt sensitive data e.l. Hva skal skje med en bruker (med tilhørende data) i et fagsystem når brukeren slutter? (slettes, arkiveres, deaktiveres, vent før sletting osv.) Hva skal skje med en bruker i et fagsystem når brukeren går ut i permisjon? Hva skal gjelde for brukere som har ulike roller (både «lærer og rektor», eller «lærer og 40% vaktmester», «lærer på ulike skoler» Praktisk bruk er i konflikt med det logisk riktige. (epost bør være jobbepost-adressen, men lønnslipp ønskes sendt til privat epost adresse)
Informasjonsarbeid Identitetsforvaltning vil endre data i ulike systemer på grunn av avhengigheter: Endring av passord vil endre passord i flere andre systemer (men kanskje ikke alle). Fjerning av brukere fra en gruppe vil endre tilganger til ulike ressurser «Grunndata» i Visma Enterprise blir viktig for hvilke tilganger en bruker får (setter krav til registrering) Brukere må vite hvor de kan få innsyn i brukerdataene Ledere og mellomledere får ansvar for å godkjenne tilganger til sine ansatte
Videre framdrift... Fase 1: januar 2012: Visma Enterprise (januar-februar) Fase 2: Start januar 2012 Organisatoriske rutiner Teknisk implementering av arbeidsflyt