Identity Management i Drammensregionen IKT

Transkript

1 Revisjon: 1.0 Dato: Forfatter: Astrid Elise Magistad, Acondo AS Klassifisering: ÅPEN

2 Innhold 1. Innledning Relaterte dokumenter Hvem er dokumentet ment for Identity Management Å kjøre et IDM-prosjekt Overordnet skisse Komponenter og programvare Provisjonering Autoritative kilder Mapping av brukerkontoer og attributter Arbeidsflyter Regler og roller og tilganger Overvåkning og rapporter Selvbetjening Gevinstrealisering... 17

3 Dette dokumentet er ment som en overordnet beskrivelse av en mulig arkitektur for Identity Management i D-IKT. Dokumentet beskriver også en overordnet IDM-strategi for kommunene generelt. 1. Innledning 1.1 Relaterte dokumenter ID Navn Skrevet av Beskrivelse 1 Access Management i Kommune- Norge Astrid Magistad, Acando Beskriver en mulig arkitektur for Access Management i kommune-norge 1.2 Hvem er dokumentet ment for Dokumentet er et arbeidsdokument og er ment brukt internt i Drammensregionen IKT. 2. Identity Management Identity Management handler om å håndtere brukerne i IT-systemene i en organisasjon. Ved å sentralisere denne håndteringen kan det oppnås bedre kontroll på hvilke kontoer som hører til hvilke personer, og sikre at alle kontoer som tilhører en person blir behandlet på en enhetlig måte. Det handler samtidig om å få kontroll over og styre personens tilganger i organisasjonens systemer. Ved å koble disse kontoene sammen med informasjon om personen som når han ble ansatt, når han slutter og i hvilken avdeling han er ansatt vil man kunne automatisere en del av prosessene med tanke på opprettelse, endring og sletting av brukerkontoer. Man vil kunne sikre at kontoer blir automatisk opprettet i det en person starter i bedriften, nødvendige endringer kan gjøres hvis ansettelsesforholdet endrer seg på noen måte, og kontoer kan deaktiveres eller slettes i det en person slutter eller går ut i permisjon. Ved å implementere IDM i organisasjonen kan det oppnås at informasjon som er duplisert ut i flere systemer som navn og epostadresse er konsistent. Samtidig vil det ved å automatisere disse opprettelsene og endringene av brukerkontoer lette hverdagen for systemadministratorer. Dette blir i dagens tjenesteorienterte hverdag enda viktigere enn før siden det ofte lages tjenester på tvers av dagens systemer og det derfor må opprettes brukerkontoer i alle systemene en tjeneste benytter seg av. Identity Management ses ofte sammen med Access Management. Access Management handler om autentisering og autorisasjon av brukere. Se relatert dokument om Access Management. Rev: ÅPEN 3/17

4 3. Å kjøre et IDM-prosjekt Det å kjøre et IDM-prosjekt er en mye større prosess i organisasjonen enn det de fleste tror. Et IDM-prosjekt handler nesten mer om å kartlegge og endre rutiner og arbeidsprosesser i en organisasjon enn akkurat den jobben det tar å implementere det. Et IDM-prosjekt handler om å kartlegge en arbeidstakers brukerkontoers livsløp i ansettelsesperioden. Det må stilles spørsmål som: - I hvilket system opprettes det først informasjon om brukeren? - Hva slags brukerinformasjon ligger lagret i flere systemer? - I hvilket system er det naturlig at informasjonen som er dobbeltlagret legges inn først? - Hvem legger denne informasjonen inn? - Fins det systemer som alle skal ha tilgang til? - Basert på den informasjonen som initielt blir lagt inn om en ny ansatt, er det mulig å avgjøre hva slags type tilganger brukeren skal ha? (F.eks. ved hjelp av avdeling eller arbeidstittel, eller om den er ansatt eller innleid?) - Hva skal skje med brukerens tilganger når han slutter eller går ut i permisjon? - Hvem har oppgaver i forbindelse med at det blir ansatt en ny person? - Hvem har oppgaver i forbindelse med at det skjer endringer i en persons arbeidsforhold, at han bytter avdeling f.eks.? - Hvem har oppgaver i forbindelse med at en person går ut i eller kommer tilbake fra permisjon? - Hvem har oppgaver i forbindelse med at en person slutter? Identity Management-prosjektet må da prøve å sammenstille denne informasjonen og prøve å komme frem til en prosessbeskrivelse som beskriver livsløpet og hva som i dag gjøres i forhold til en ansatts digitale liv i organisasjonen. Mye av det som blir gjort kan antakelig automatiseres, og det kan også antakeligvis gjøres effektiviseringer og endringer på de prosessene som fins i dag. Et eksempel på en naturlig endring i rutiner kan være at de tradisjonelle drifterne av systemene ikke lenger har like mye rådighet over informasjonen i systemene, og at brukerne derfor må kontakte andre personer enn de er vant til hvis det har blitt lagt inn feil informasjon. Innleide blir for eksempel ofte tildelt kontoer som har relativt kort varighet for å sikre at de ikke har evig tilgang fordi de en gang har vært innom organisasjonen. De er antakelig vant til å måtte ta kontakt med IT drift hvis de ikke lenger får logget seg på eposten sin fordi AD-kontoen har blitt deaktivert og personen som deler ut adgangskort hvis dette har sluttet å virke. Etter at IDM-prosjektet har blitt implementert vil disse deaktiveringene antakelig styres av sluttdatoen som er satt i HR-systemet. Det er derfor HR som må kontaktes hvis tilganger mangler, og ikke administratorene for de forskjellige systemene. Gjøres endringen lokalt i AD eller i systemet for adgangskort blir dette skrevet over neste gang det skjer en endring på brukeren i HR-systemet, så endringen må i stedet gjøres der. Avsnittet over tyder på at selv om et IDM-prosjekt er et IT-prosjekt, må andre deler av organisasjonen involveres for at dette skal bli et suksessfullt prosjekt. Det kreves en ganske betydelig involvering fra andre deler av organisasjonen under design og utvikling av løsningen for å sikre at prosessene blir angitt så riktig som mulig. 4. I IDM-prosjekter skal et IDM-produkt være en sentral enhet som sammenstiller alle en persons brukerkonti i organisasjonen. Her implementeres også arbeidsflyter som synkroniserer inn data og oppretter, endrer og deaktiverer og sletter kontoer i tilkoblede systemer. IDM sørger for at alle data som i utgangspunktet er Rev: ÅPEN 4/17

5 samme informasjon er konsistent i alle systemene denne informasjonen er lagret. Endrer en person f.eks. navn vil det bli endret i alle systemer, det er ikke nødvendig å legge det inn mer enn ett sted. IDM forholder seg til to forskjellige typer systemer eller ressurser: Autoritative kilder Systemer som er mottakere av data En autoritativ kilde er et system som er master for en type data. Data legges inn i dette systemet og det overføres til andre systemer. Det kan finnes en eller flere autoritative kilder, men det fins bare en autoritativ kilde for en gitt type informasjon. For eksempel defineres det hvilket system brukerens navn skal legges inn i. Legges det inn i andre systemer vil det bli overskrevet av informasjon fra den autoritative kilden. HRsystemet er kanskje autoritativ kilde for data som navn og adresse og slike ting, mens kanskje det finnes et annet system hvor det er mer naturlig at romnr og telefonnr. Registreres. Da blir dette autoritativ kilde for disse attributtene. Resten av systemene er bare mottakere av data og ingenting synkroniseres inn i IDMsystemet fra disse systemene. 4.1 Overordnet skisse Dette avsnittet inneholder overordnede skisser for IDM innad i en organisasjon, og IDM i kontekst av kommunalt samarbeid med applikasjoner som brukes av brukere fra flere kommuner og IDM i sammenheng med AM-arkitekturen som er beskrevet i dokumentet Access Management i Kommune-Norge (se kapittel 1.1 Relaterte dokumenter). Figur 1 - innenfor en organisasjon beskriver, som navnet tilsier, arkitekturen overordnet innenfor en organisasajon. Her ser vi at OpenIDM er sentral, og henter/får informasjon om nye brukere fra et initielt system, og provisjonerer (Se kapittel 5 - Provisjonering) på basis av dette brukerinformasjon til andre tilknyttede systemer. De tilknyttede systemene kan være så mange systemer man ønsker, aller helst alle andre systemer som i organisasjonen som håndterer brukere. Løsningen kan utvides ved å legge til ett og ett system. Det er også mulig å få input fra flere systemer. Rev: ÅPEN 5/17

6 Figur 1 - innenfor en organisasjon Figur 2 - Samarbeid mellom kommuner viser to vanlige kommuner som både provisjonerer brukere til interne applikasjoner og til en kommunal og en statlig felleskomponent slik at kommunens brukere kan bruke også disse tjenestene. Den kommunale og statlige felleskomponenten har et eget IDM-system som provisjonerer brukere ut til systemene innenfor sin organisasjon. Integrasjonen mellom de to IDMsystemene går via SPML-protokollen. SPML er et XML-basert rammeverk laget av samme organisasjon som har laget SAML2 som brukes til å kommunisere mellom AM-systemer i forskjellige domener (se AMdokumentet). SPML er laget for akkurat det formålet å provisjonere bruker- og ressursdata innenfor og på tvers av organisasjoner. Rev: ÅPEN 6/17

7 Figur 2 - Samarbeid mellom kommuner Figur 3 viser IDM-arkitekturen i kontekst av AM-arkitekturen inndelt i soner fra AM-dokumentet. HRsystemet legger informasjon om nye og endrede brukere på bussen, og IDM-systemet plukker opp dataene derfra. IDM-systemet provisjonerer deretter brukere til systemene som håndeterer brukere, enten ved hjelp Rev: ÅPEN 7/17

8 av bussen eller direkte til systemenes brukerlagre. IDM-systemet har her blitt lagt i åpen sone fordi det skal provisjoneres brukere både til internt og eksternt. Provisjonering mot sikker sone går via bussen. Sikker sone Åpen sone DMZ OpenAM med brukerlager OpenAM med brukerlager OpenAM med brukerlager Policy agent Policy agent Policy agent Applikasjoner OpenIDM Applikasjoner Portal Bruker Policy agent ESB E S B Tjenester for eksterne MinSide Figur 3 - IDM i AM-arkitektur 4.2 Komponenter og programvare Komponentene som inngår i en IDM-arkitektur er foruten alle systemer i organisasjonen i dag, en ny sentral komponent: et IDM-system. I vårt eksempel tenkes ForgeRock sin OpenIDM brukt. Figur 4 OpenIDM arkitektur viser arkitekturen på produktet. Vi ser av figuren at OpenICF-rammeverket blir brukt til å lage connectorer til å koble til andre systemer. På grunn av dette skal det være relativt enkelt å lage sine egne connectorer hvis det ikke skulle finnes en ferdig connector som passer til det systemet som ønskes tilkoblet. De har et integrert repository for interne brukere og en kjerne som dekker basisfunksjonalitet for et IDM-produkt. Tjenester i kjernen kan aksesseres ved hjelp av REST-kall. Løsningen i dag baserer seg på å bruke eksterne systemer for arbeidsflytmotor, sluttbrukergrensesnitt og rapportgenerator. Dette er imidlertid tenkt implementert i produktet i løpet av kommende år (2012). Figur 5 - Roadmap 2011 og Figur 6 - Roadmap 2012 viser et sammendrag av planene for videreutvikling av OpenIDM i henholdsvis 2011 og Rev: ÅPEN 8/17

9 Figur 4 OpenIDM arkitektur Rev: ÅPEN 9/17

10 Figur 5 - Roadmap 2011 Rev: ÅPEN 10/17

11 Figur 6 - Roadmap Provisjonering Provisjonering av brukere består i at informasjon om en bruker kun blir opprettet et sted, og at det på basis av denne informasjonen blir ved hjelp av en sentral enhet, et IDM-system, opprettet og endret brukerkontoer i andre systemer. På denne måten oppnås det at informasjon om en person er konsistent og det er mulig å automatisere mye som tidligere har vært gjort manuelt. Figur 1 - viser at brukere blir provisjonert fra en kilde til de andre målsystemene. Denne funksjonaliteten dekkes av OpenIDMs kjerne. 6. Autoritative kilder En autoritativ kilde er et system som er master for en type informasjon. IDM-systemet henter informasjon fra dette systemet og populerer andre systemer på basis av den innhentede informasjonen. Hvis denne informasjon blir lagt inn manuelt i andre systemer enn det som er autoritativt blir dette overskrevet neste gang det skjer en endring på attributtet i den autoritative kilden. Det vil jo heller ikke bli provisjonert til andre systemer hvis endringer skjer i andre kilder enn den autoritative. Det kan finnes flere enn et autoritativt system i arkitekturen, men hvert attributt som provisjoneres til flere systemer har alltid kun en autoritativ kilde. 7. Mapping av brukerkontoer og attributter En person har mange brukerkontoer i systemer hos organisasjonen. Eksempelet nedenfor viser en ansatt Rune. I de fire systemene som er illustrert nedenfor i har han disse fire brukerkontoene: Rev: ÅPEN 11/17

12 Runsan rsa Runes I utgangspunktet er det vanskelig å se at disse brukerkontoene tilhører samme person. I et vanlig driftsscenario er det derfor vanskelig å vedlikeholde alle en persons konti ved at det skjer noe i forhold til hans ansettelsesforhold. Ofte har også disse systemene forskjellige personer som er ansvarlig for drift, og det er ikke sikkert disse en gang er informert den dagen Rune velger å slutte slik at de får ryddet opp og fjernet tilganger. Det vanlige er derfor at det ligger mange brukerkontoer rundt omkring som er fullt operative lenge etter at brukeren ikke lenger burde hatt tilgang. Figur 7 - En person, flere brukerkontoer viser at en person kan ha mange kontoer i forskjellige systemer i en organisasjon, og at det kan være vanskelig å se ut fra brukernavnet at disse kontoene tilhører samme person. IDM linker alle en brukers brukerkontoer opp mot personen, slik at det skal på en enkel måte gå an å administrere en brukers tilganger på en helhetlig måte. Rev: ÅPEN 12/17

13 Figur 7 - En person, flere brukerkontoer Rev: ÅPEN 13/17

14 I tillegg til at en person har mange kontoer rundt i de forskjellige systemene, er også mye av den samme informajsonen lagret i flere av systemene. Dette betyr mye dobbeltarbeid for de som er ansvarlige for å legge inn informasjon, både ved nyopprettelse og ved eventuell endring. Siden det er såpass mye manuell jobb som skal til så er det også stor sjanse for data ikke blir oppdatert riktig i alle systemer, og at innholdet blir ukonsistent. IDM-systemet sørger for å koble disse attributtene sammen slik at de kan bli opprettet og oppdatert samtidig med samme verdi. I Runes tilfelle kan vi tenke oss at han har disse attributtene i de forskjellige systemene: I HR-systemenet: Fornavn = Rune Etternavn = Sandland Kortnavn = runsan I Active Directory: Sn = Sandland givenname = Rune displayname = Rune Sandland samaccountname runsan mail = runsan@d-ikt.no Mange av attributtene i Active Directory som er listet opp her inneholder samme informasjon som feltene i HR-systemet. I stedet for å legge informasjonen inn to ganger legges det kun inn i HR-systemet, IDM mapper til tilsvarende attributter i Active Directory, og opprettelse og oppdatering av konto i Active Directory skjer etter at det blir lagt inn i HR-systemet. På denne måten oppnås det at samme type data blir lagt inn mange steder, og det blir mindre dobbeltarbeid. Mapping av brukerattributter støttes av OpenIDMs kjerne. Logikk legges til i hooks for scripts. For øyeblikket støttes kun javascript, men det kommer støtte for flere språk senere. 8. Arbeidsflyter Vi har i hovedsak 3 arbeidsflyter: Opprett bruker, oppdater bruker og slett/deaktiver bruker. Opprett bruker settes i gang i det en ny bruker blir registrert i den autoritative kilden (f.eks. HR-systemet)., oppdater bruker settes i gang hver gang det skjer en endring på en bruker, mens slett/deaktiver bruker settes i gang når personen slutter i organisasjonen. I tillegg til å definere hvilke systemer det skal opprettes kontoer i, og hvilke attributter i de forskjellige systemene som mapper til hverandre kan man også her definere andre ting som skal skje i forbindelse med opprettelse av bruker, f.eks. at det kanskje skal sendes en epost til lederen til personen som nettopp har blitt registrert, med påminnelse om rutiner ved nyansettelse. Kanskje skal det også sendes en mail til personen Rev: ÅPEN 14/17

15 som er ansvarlige for å legge inn telefonnummer og romnummer i sentralbordsystemet når denne informasjonen er klar. Denne informasjonen er ofte ikke til stede i det personen blir lagt inn i HR-systemet, og kanskje er ikke dette noe som skal inn i HR-systemet i det hele tatt, så det kan være hensiktsmessig å la et annet system være autoritativt for disse attributtene. Figur 8 - Arbeidsflyt ny bruker viser et eksempel på en slik arbeidsflyt. Send epost til nyansatt Opprett OpenAM brukerlager Ny data ESB data Registrator Kildesystem Identity Manager Opprett Send epost til ansvarlig for registrering av romnr. Og telefon Målsystem Figur 8 - Arbeidsflyt ny bruker Ved endring av bruker kan det være så enkelt som å populere de nye systemene med nye verdier, men det kan også være endring på et attributt som trigger større endringer. For eksempel kan det hende at en ansatt endrer avdeling eller stilling. Kanskje dette trigger endringer i hvilke rettigheter personen skal ha. Kanskje en innleid går over til å bli en ansatt og skal ha rettigheter lik andre ansatte. Ved sånne litt mer kompliserte tilfeller må man alltid vurdere hvor ofte disse endringene skjer opp mot kompleksiteten det medfører å implementere noe slikt. Hvis slike endringer skjer to ganger i året kan man kanskje vurdere å gjøre disse endringene manuelt i stedet for å implementere det i IDM-systemet. I det en person slutter skal han miste tilganger. Det kan likevel ofte være hensiktsmessig å ikke slette kontoer brutalt med en gang, sånn i tilfelle sluttdatoen f.eks. ikke er satt riktig, eller at personen har fått utvidet engasjement uten at dette har blitt registrert i systemet. Dette kan skje med innleide og midlertidig ansatte som ofte opererer med korte engasjement som ofte blir fornyet. Det kan derfor være hensiktsmessig å kun deaktivere kontoer i det personen slutter, slik at de enkelt kan reaktiveres igjen i samme tilstand som tidligere hvis sluttdatoen endres igjen til noe i fremtiden. Noen ønsker å holde gamle kontoer der av historikkens skyld, men hvis det er ønskelig å rydde ordentlig opp kan det settes opp en batchjobb som sletter gamle brukere etter en viss tid. 9. Regler og roller og tilganger Modell for adgangskontroll er også beskrevet i dokumentet om Access Management (se kapittel 1.1 Relaterte dokumenter). Det handler om å lage en modell for hvem som skal ha tilgang til hva. Dette kan Rev: ÅPEN 15/17

16 styres av roller (f.eks. kan en person være saksbehandler innenfor et gitt felt eller utvikler i et IT-prosjekt.) eller av regler. Reglene kan være tidsstyrte regler eller regler i forhold til attributter på brukeren som hvilken avdeling han tilhører. Som beskrevet i AM-dokumentet kan det ofte være hensiktsmessig å benytte en modell som kombinerer disse to strategiene. I det brukere blir opprettet og endret av IDM-systemet kan det settes opp regler som f.eks. gir alle brukerne i en gitt avdeling tilganger som er spesifikt for denne avdelingen. Det kan også settes opp regler som gir tilganger ut fra om en person er innleid eller ansatt. Disse reglene kan implementeres direkte inn i arbeidsflyten som oppretter og oppdaterer brukere, og det blir derfor gitt et sett med tilganger automatisk. Det er viktig at disse tilgangen ikke blir for vide, slik at mange brukere får tilgang til mer enn de skal ha. Det kan bestemmes et sett med basistilganger ut fra brukerattributtene. For ting man ikke kan lese ut fra brukerens attributter i HR-systemet, kan det opprettes roller. Eksempler på dette kan være at en bruker er saksbehandler i et spesifikt prosjekt, hvor det trengs spesifikke tilganger. Rollene kan administreres sentralt i IDM-systemet. I OpenIDM slik produktet er i dag støttes kun regelbasert provisjonering. Rollebasert provisjonering skal etter planen utvikles i løpet av Overvåkning og rapporter Siden et IDM-system automatiserer en del prosesser som tidligere har vært gjort manuelt, og integrerer med mange systemer i organisasjonen kan det være et ønske å kunne få ut rapporter om det som har skjedd. Man kan tenke seg å få ut rapporter om hvilke brukere som har blitt opprettet og oppdatert, hva som har blitt oppdatert og om det har skjedd noen feil. Det bør også være mulig å finne frem til hvem som har vært inne i konsollet og hvilke prosesser som er utført av hvem. OpenIDM logger alt som skjer inne i OpenIDM. De har ikke selv noe rapporteringsverktøy ennå, dette skal etter planen utvikles i løpet av I mellomtiden tilbyr OpenIDM et grensesnitt som skal gjøre det enkelt å integrere med eksterne rapporteringsverktøy. Det kan vurderes å benytte seg av et rapporteringsverktøy som allerede blir brukt i organisasjonen hvis dette lar seg integrere. Da kan rapportadministratorene forholde seg til et system de allerede kjenner fra før. Det kan lages noen ferdige standardrapporter som kan settes opp til å kjøres ved jevne mellomrom. I tillegg til disse autogenererte rapportene bør det være mulig for brukere å gå inn og generere enkle rapporter selv hvis det dukker opp et behov for rapportering som ikke dekkes av standardrapportene. 11. Selvbetjening En slik sentral enhet som kobles mot andre systemer, som IDM-systemet er gjør det enkelt å sette opp et grensesnitt for vanlige brukere hvor de kan administrere sine egne tilganger til systemer, sitt eget passord og eventuelt også andre ting som hjemmeadresse. OpenIDM har ikke dette innebygget i produktet i dag, men et eksempel-gui er planlagt levert i en release av produktet i Q3/Q4 i år, mens en forbedring av dette er planlagt ferdig i Q1/Q2 neste år. I et slikt grensesnitt kan ansatte selv administrere passordet sitt, slik at helpdesk får minimert tiden de bruker på at folk har glemt passordene sine. I dette grensesnittet kan de også bestille tilganger til systemene som er koblet til IDM-systemet. Det som trengs for å gi tilgang kan automatisk gjøres av IDM-systemet, for eksempel å opprette konto eller legge til grupper på brukeren i AD. Her vil det ofte ønskes en kontroll på hvem som får tilganger. Det kan derfor implementeres slik at en person må godkjenne eller nekte at disse tilgangene blir gitt ved å for eksempel trykke på en knapp inne i grensesnittet til IDM-systemet. Denne personen kan enten være systemeier av systemet det ønskes tilgang til eller den ansattes leder eller begge to. For at det skal være mulig å implementere arbeidsflyten beskrevet i forrige avsnitt trengs både et brukergrensesnitt som holder på å utvikles, samt en arbeidsflytmotor. Arbeidsflytmotoren er heller ikke implementert i produktet ennå, men skal ifølge planen utvikles i løpet av Inntil da må eksterne produkter benyttes for dette formålet. Rev: ÅPEN 16/17

17 Figur 9 - Eksempel på arbeidsflyt ved forespørsel på tilgang viser et eksempel på hvordan arbeidsflyten kan gå i det en ansatt ønsker og ber og tilgang til en ny tjeneste. Arbeidsflyten viser at den ansatte selv går inn og ber om tilgang i IDM-systemet. Dette trigger en mail til en annen ansatt som har ansvar for å godkjenne eller ikke godkjenne forespørselen. Eposten inneholder informasjon om at en ansatt ber om tilgang og en link til IDM-systemet hvor attestanten kan foreta attestasjonen. Når tilgangen enten er godkjent eller nektet går det en mail tilbake til den ansatte som ba om tilgang om at attestasjonen er fullført og hva resultatet ble. Figur 9 - Eksempel på arbeidsflyt ved forespørsel på tilgang 12. Gevinstrealisering Ved å implementere IDM i en organisasjon vil det oppnås store besparelser når det gjelder IT support, siden mye av administrasjonen av brukerkontoer vil gå automatisk. Spørsmål angående passord vil omtrent forsvinne. Men den største gevinsten vil være at det oppnås kontroll på hvem som har tilgang til hva, og at tilganger blir fjernet når ansatte slutter. De sier at de fleste angrep mot organisasjoner skjer fra innsiden, fra nåværende eller tidligere ansatte. Ved å eliminere tilganger som ikke bør være der minimeres sjansen for slike angrep. Rev: ÅPEN 17/17