Access 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 Access Management Overordnet skisse Kommuneprofiler Kommune Kommune Kommune Komponenter og programvare OpenAM Agent OpenDJ Access Management og soneinndeling En OpenAM i hver sone ID-Porten kun i ytterste sone Single Sign On og autentisering SSO mellom interne tjenester SSO til tjenester hos andre kommuner: Autentiseringsmoduler Windows Desktop SSO Føderering LDAP Autorisasjon Sporbarhet Modell for adgangskontroll Relevante begreper Single Sign On Single Log Out Føderasjon Circle of Trust Identity Provider og Service Provider... 10

3 Access Management i Drammensregionen IKT Dette dokumentet er ment som en overordnet beskrivelse av en mulig arkitektur for Access Management i Drammensregionen IKT. Dokumentet beskriver også en overordnet IAM-strategi for kommunene generelt. 1. Innledning 1.1 Relaterte dokumenter ID Navn Skrevet av Beskrivelse 1 Identity Management i Drammensregionen IKT Astrid Magistad, Acando Beskriver en mulig arkitektur for Identity Management i kommune-norge 1.2 Hvem er dokumentet ment for Dokumentet er et arbeidsdokument og er ment brukt internt i Drammensregionen IKT. 2. Access Management Access Management er en samlebegrep for det som har med tilgangsstyring å gjøre. Det som inngår i begrepet Access Management er autentisering, autorisasjon og sporbarhet. Autentisering handler om å kunne være sikker på hvem som aksesserer en tjeneste, autorisasjon handler om å finne ut om den som prøver å aksessere en tjeneste faktisk har lov til å gjøre det han prøver på. Sporbarhet handler om å logge og lagre hvem som har vært inne hvor og når slik at det er mulig å finne ut av dette i etterkant. Access Management ses ofte sammen med Identity Management. Identity Management handler om håndtering av brukere i en organisasjon. Mer om dette i dokumentet Identity Management i Kommune- Norge (se kapittel 1.1 Relaterte dokumenter). 3. Kommuner har ofte en sone-inndelt infrastruktur. Dette må vi ta hensyn til og følge de sikkerhetsregler som ligger bak dette prinsippet. Vi tenker oss derfor at hver sone får hver sin OpenAM-server med brukere som skal ha tilgang til en eller flere applikasjoner i sonen. Rev: ÅPEN 3/10

4 Det deployes Agenter foran appliksjonene, og disse blir koblet til OpenAM-serveren i sonen de er deployet i. Hver OpenAM-server er koblet til en instans av OpenDJ som briukes som. 3.1 Overordnet skisse Figur 1 - Det interne livet i en kommune med AM beskriver arkitekturen overordnet slik den ser ut innenfor en enkelt kommune, med grensesnittet ut mot omverdenen. Figuren viser 3 soner, en sikker sone, en åpen sone og en DMZ-sone innenfor kommunen. Utenfor fins eksterne systemer som kommunens systemer kommuniserer med, som ID-Porten, andre kommuner eller samarbeidspartnere og MinSide. Error! Reference source not found. beskriver hvordan arkitekturen kan se ut med flere kommuner og hvordan de kommuniserer med hverandre og omverdenen. Vi tenker oss at vi kan ha en sentral autentiseringsløsning for alle kommunene, samt at noen kommuner i tillegg har sine egne autentiseringsløsninger. Kommunikasjonen til eksterne systemer i Access Management-sammenheng går via SAML2-protokollen. Figur 1 - Det interne livet i en kommune med AM Rev: ÅPEN 4/10

5 Kommune 3 SAML2 Portal Bruker Kommune 1 Sikker sone Åpen sone DMZ Applikasjoner Applikasjoner Portal ESB ESB Tjenester for eksterne KommIT SAML2 SAML2 SAML2 SAML2 Tiltrodde Tredjeparter (Eks: ID-Porten) Bruker MinSide Eksterne systemer DMZ Portal Tjenester for eksterne Kommune 2 Åpen sone Sikker sone Applikasjoner Applikasjoner ESB ESB Figur 2 - AM i og mellom forskjellige kommuner Rev: ÅPEN 5/10

6 3.2 Kommuneprofiler Figur 2 - AM i og mellom forskjellige kommuner beskriver 3 forskjellige kommuneprofiler, og hvordan de kan kobles sammen i en felles AM-strategi. Her følger en beskrivelse av de forskjellige kommuneprofilene: Kommune 1 Kommune 1 er en stor kommune som både har tjenester tilgjengelig for innbyggere og andre kommuner i DMZ, og interne tjenester for kommunens ansatte i åpen sone, og en sikker sone for applikasjoner med spesielt sensitive opplysninger som helseopplysninger og hemmelige adresser osv. Kommune 1 har en OpenAM-instans innstallert for hver sone Kommune 2 Kommune 2 er også en stor kommune, men her har du kun valgt å implementere AM i ytterste sone for å gi tilgang til eksterne brukere, og for samarbeid mellom kommuner Kommune 3 Kommune 3 er en liten kommune, og har innstallert en OpenAM som kan integreres mot andre kommuner eller felleskomponenter. 3.3 Komponenter og programvare Programvaren som er tenkt brukt i prosjektet: ForgeRock OpenAM ForgeRock OpenDJ (Brukerlager) ForgeRock OpenAM Agent ForgeRock er et globalt firma med avdelinger i USA og Europa. De ble startet opp med visjonen om å lage en full Open Source plattform for å lage interaktive web- og cloud-løsninger med fokus på identitet. ForgeRock har videreutviklet Sun s OpenSSO som har blitt til ForgeRocks OpenAM, Sun s OpenDS har blitt ti ForgeRocks OpenDJ. I tillegg har de produktet OpenIDM som blir beskrevet mer i dokumentet om Identity Management OpenAM OpenAM er en videreutvikling av Suns OpenSSO og skal tilby autentisering, autorisasjon og føderering. OpenAM tilbyr en sentral enhet for håndtering av tilgangsgangskontroll og skal gjøre det lettere å implementere Single Sign On mellom forskjellige systemer. OpenAM kan integrere mange forskjellige webapplikasjoner som typisk har vært sitt og ligger på forskjellige plattformer Agent OpenAMs Agenter er en liten applikasjon som deployes på samme applikasjonsserver som applikasjonene som skal beskyttes, eller på en Proxy foran. Disse er bindeleddet mellom OpenAM og applikasjonen. I applikasjonen spesifiseres det at brukeren må innom Agenten før den kan få tilgang til applikasjonen. Agenten håndterer sesjonsinformasjon for applikasjonen og er tett integrert med OpenAM og enten slipper brukeren videre til applikasjonen hvis han allerede er autentisert eller redirigerer brukeren til OpenAM for autentisering OpenDJ OpenDJ er en videreutvikling av Suns OpenDS, en Directory Server som er tenkt brukt som til OpenAM. Rev: ÅPEN 6/10

7 4. Access Management og soneinndeling Infrastrukturen til kommunesektoren er ofte soneinndelt. Med dette fører det med seg en del sikkerhetskrav som må overholdes. Blant annet ønsker man minst mulig kommunikajon mellom sonene og at kommunikasjon med omverdenen (utenfor det interne nettverket) kun foregår fra ytterste sone. Dette avsnittet beskriver hvordan dette har innvirkning på AM-arkitekturen. 4.1 En OpenAM i hver sone For å ta hensyn til sikkerhetskravene som følger med en soneinndeling, vil vi deploye en OpenAM i hver sone. Alternativet kunne vært å ha en sentral OpenAM som lå i ytre sone. Ved å ha en OpenAM i hver sone vil man minimere trafikken mellom sonene. Dette vil øke sikkerheten. Et annet aspekt ved å legge brukerene som skal ha tilgang til sikker sone i sikker sone er at det da ved å ha OpenAM med liggende i sikker sone, vil det være flere barrierer en som må forseres for å klare å hacke brukeren ved å f.eks. endre passord eller ved å gi brukeren flere rettigheter vha roller. 4.2 ID-Porten kun i ytterste sone I ytterste sone ligger tjenestene som er tilgjengelig for folk utenfor det interne nettverket. Dette gjelder f.eks. innbyggerne i kommunene, lærere, elever osv. Fordi vi ønsker å minimere trafikken inn til åpen og sikker sone vil vi ikke der åpne for trafikk til ID-Porten. Interne brukere må derfor bruke andre måter å autentisere seg på når de skal nå de interne systemene. Innbyggerne vil kunne nå sine tjenester med ID-Porten. 5. Single Sign On og autentisering Autentisering handler om å identifisere hvilken bruker som forsøker å logge seg på. Ved å sette OpenAM opp til å beskytte flere tjenester, kan en bruker slippe å autentisere seg flere ganger. Så lenge en bruker allerede har autentisert seg en gang i en tjeneste som er koblet opp mot OpenAM vil OpenAM finne ut av dette og derfor også gi brukeren tilgang til en annen tjeneste på basis av autentiseringsinformasjonen som ble gitt ved første pålogging. Brukere har ofte ikke samme brukerid i de forskjellige systemene, så OpenAM må også ha en mapping over brukerider i de forskjellige systemene som innehas av samme person. 5.1 SSO mellom interne tjenester Det vil oppnås SSO mellom alle tjenester som er koblet til samme OpenAM, og også til de tjenestene beskyttet av den instansen den er føderert med. Det betyr at det vil oppnås Single Sign On mellom tjenestene innenfor samme sone. Det vil ikke være en kobling mellom OpenAM-instansene i de forskjellige sonene, men brukeren vil likevel oppleve SSO ved å bevege seg mellom sonene fordi man i intern og sikker sone er nødt til åvære logget på Windows og dermed vil få sesjon i OpenAM pga sesjonen i Windows. Det samme gjelder hvis brukeren aksesserer en applikasjon i ytre sone fra indre eller sikker sone. 5.2 SSO til tjenester hos andre kommuner: Vi tenker oss at dette kan løses med en sentral enhet som fødereres med OpenAM i de forskjellige kommunenes ytre soner. Dette kan være ID-Porten, eller det kan være en egen sentral OpenAM for kommune-norge hvis det ikke er ønskelig å bruke sin personlige bruker i ID-Porten til å logge seg på tjenester i jobbsammenheng. En slik sentral enhet vil fungere slik at du vil kunne få SSO til alle tjenester som er føderert med denne sentrale enheten så lenge du har en bruker og tilstrekkelige rettigheter i det systemet du prøver å aksessere. Rev: ÅPEN 7/10

8 Et annet alternativ kan være at alle kommunene fødererer med de kommunene de skal samarbeide med, og at brukere på denne måten kan gå sømløst mellom applikasjoner hostet av de forskjellige kommunene. Dette er kun et alternativ hvis det ikke skulle være et utstrekt samarbeid mellom kommunene på den måten at brukere i en kommune skal kunne aksessere applikasjoner hos andre kommuner. Hvis dette samarbeidet er stort vil det bli et virvar av føderasjoner på kryss og tvers, og da burde en sentral enhet vurderes. 5.3 Autentiseringsmoduler OpenAM kan settes opp med en rekke autentiseringmoduler. Vi tenker oss at disse autentiseringsmodulene blir brukt: Windows Desktop SSO Føderering LDAP Disse er standard moduler i OpenAM-produktet. Disse vil på ulike måter autentisere brukeren og gi den en gyldig sesjon i OpenAM som gjør at brukeren kan bevege seg sømløst mellom applikasjonene som er beskyttet av OpenAM uten å måtte gjøre en ny innlogging. I tillegg til disse modulene kan også OpenAM settes opp med autentisering med sertifikater eller mot RADIUS, Safeword eller SecurID. Det finnes også støtte for å lage sin egen autentiseringsmodul. MinID er et eksempel på en slik autentiseringsmodul. OpenAM har støtte for autentiseringskjeder, det vil si at det kan defineres et sett med mulige autentiseringsmåter hvor man kan bestemme hvilke av metodene som er påkrevd og hvilke som er valgfrie Windows Desktop SSO Ved å enable Windows Desktop SSO i OpenAM kan en bruker aksessere alle applikasjoner som er beskyttet av OpenAM uten å måtte logge seg på flere ganger enn på pc en sin. Ved Windows Desktop SSO plukker OpenAM opp Kerberos token som ble generert da brukeren logget seg på Windows og bruker dette til å autentisere brukeren i OpenAM. Denne vil slå inn hver gang brukeren befinner seg i det interne nettverket i kommunen. Dette vil si hvis han sitter på kontoret, har logget seg på nettverket via vpn eller andre tuneller, eller om han er logget på intern eller sikker sone Føderering En bruker kan også bli autentisert fordi han er autentisert av en annen Identity Provider som OpenAM stoler på. Eksempler på dette kan være ID-Porten eller om man velger å bruke en annen felles autentiseringsløsning for kommunene. Etter at man er autentisert her en gang kan man gå sømløst fra applikasjon til applikasjon uten å autentisere seg på nytt LDAP Vanlig LDAP-autentisering vil bli brukt hvis en av de andre autentiseringsmetodene av en eller annen grunn ikke fungerer. Dette vil være for brukere som ikke befinner seg i det interne nettverket slik at Windows Desktop SSO kan bli brukt, og at de velger å bruke en tjeneste som er beskyttet ikke er beskyttet av ID- Porten eller andre eksterne IdPer. 6. Autorisasjon Autorisasjon handler om å kontrollere at brukere har tilgang til det området de forsøker å aksessere. Mange systemer har innebygde autorisasjonsregler med roller og grupper som beskriver hva brukerne har tilgang til i applikasjonen. Dette er også roller og grupper som ikke så lett lar seg gjenbruke i andre applikasjoner. Det er derfor ofte uhensiktsmessig å flytte dette ut i Access Management-løsningen selv om det er fullt mulig. Autorisasjon vil derfor bli gjort i de enkelte applikasjonene. Selv om autorisasjonen i seg selv gjøres av applikasjonen kan den likevel på et nivå styres utenfra. Hvis det fins en enkel måte ved hjelp av å på brukerens attributter eller tilhørighet i organisasjonen at en bruker skal Rev: ÅPEN 8/10

9 ha visse rettigheter i et system, kan det være hensiktsmessig å styre opprettelsen av slike brukere utenfra. Systemet selv tar seg av autorisasjonen, men kontrollen av hvem som får hvilke rettigheter gjøres utenfra. F.eks. vil naturlig driftsavdelingen ha flere rettigheter enn en vanlig saksbehandler. På basis av at brukere befinner seg i Driftsavdelingen vil de derfor bli tildelt en bruker i systemet med ekstra rettigheter. Opprettelsen av disse brukerene og tildelingen av rettigheter gjøres av Identity Management-delen av prosjektet. Ved å styre dette utenfra oppnår vi det at denne rettigheten enkelt kan fjernes igjen hvis brukeren ikke lenger har en drifts-rolle i organisasjonen, og får derfor bedre kontroll på hvem som har utvidede rettigheter. 7. Sporbarhet Det er ønskelig med så mye kontroll som mulig på hvem som har vært inne når og hva som har blitt gjort. En forutsetning for å få til dette er at det i størst mulig grad blir benyttet personlige brukere. Det ønskes i størst mulig grad at vanlige brukere blir gitt administratorrettigheter i stedet for at det brukes en admnistratorbruker som brukes av alle. Ved å bruke en systembruker alle har tilgang til vil man ikke ha kontroll på hvem som har vært inne. OpenAM har mange logger som kan settes opp til å logge på flere nivåer. Det kan i tillegg til vanlige fillogger logges til database eller til en ekstern OpenAM-instans. Loggene er delt inn i vanlige access og errorlogger og debug-logger. Access-loggen skal gi informasjon om alle som har forsøkt å logge seg inn, mens debug-loggene kan gi mye mer detaljert informasjon, avhengig av hva slags nivå logginen er satt opp på. Det fins også egne logger avhengig av hva slags innloggingsmetode som er brukt, f.eks. om brukeren har logget seg på adminkonsollet eller om han er logget på ved hjelp av føderering til en annen Identity Provider. Agenten og Directory Server har også egne logger. 8. Modell for adgangskontroll Det må lages en modell for hvem som skal få tilgang til hva. Som tidligere beskrevet gjøres autorisasjon i de enkelte applikasjonene, så denne modellen skal kun gjenspeile hvem som skal ha tilgang til de forskjellige tjenestene og applikasjonene. Denne modellen skal både sikre at brukere får tilgang til det de skal og ikke så mye mer, og den skal ikke være uoverkommelig å administrere. Dette er litt motstridende interesser, så det er ofte ikke veldig lett å komme opp med en bra modell. For å komme frem til en slik modell må man komme frem til hvilke roller man har i organisasjonen. Eksempler på slike roller kan være: Systemadministrator/Systemansvarlig Drifter Utvikler Ansatt Innleid Saksbehandler Det gjelder å komme frem til en rollefordeling som fanger opp grupper av mennesker som har omtrent samme behov for tilganger og dele dem inn i grupper eller roller. På den måten kan alle med en gitt rolle få tilgangene denne rollen skal ha, og man slipper å gi hver enkelt de samme tilgangene. Samtidig fins det regler i organisasjonen som ikke så lett kan beskrives ved hjelp av roller. Eksempler på slike regler kan være: Tidsstyrte regler Rev: ÅPEN 9/10

10 Regler basert på brukerattributter som avdeling eller lokasjon Ofte kan det beste være å lage en adgangskontrollmodell hvor både roller og regler blir brukt. 9. Relevante begreper I dette avsnittet blir det beskrevet en del begreper brukt ellers i dokumentet. 9.1 Single Sign On Single Sing On handler om at en applikasjon skal klare å nyttiggjøre seg av at en bruker allerede har autentisert seg I en annen applikasjon, og på basis av det gi brukeren tilgang også til sin applikasjon uten ny autentisering. 9.2 Single Log Out Single Logout skal gjøre det mulig at en utlogging fra en applikasjon skal sette i gang utlogging også fra de andre tjenestene brukeren har vært logget inn på. Dette fordrer at disse applikasjonene er i samme Circle of Trust (se nedenfor). 9.3 Føderasjon Føderasjon i denne sammenhengen betyr en avtale mellom to organisasjoner at de stoler på hverandre. Når Drammen IKT fødererer med ID-Porten betyr det at de stoler på at hvis brukerne er autentisert i ID-Porten, betyr det at de også er autentisert til å aksessere Drammen IKTs tjenester og kan derfor slippe dem inn i applikasjonene sine. 9.4 Circle of Trust Tjenester som er i samme Circle of Trust stoler på hverandre med tanke på at hvis en bruker er logget inn i en av dem får den også aksess til de andre tjenestene. Det samme gjelder at hvis brukeren velger å avslutte sesjonen i en av tjenestene blir han også logget av de andre. 9.5 Identity Provider og Service Provider I en føderasjon snakker man om en Identity Provider og en Service Provider. Service Provider beskytter en tjeneste, mens Identity Provider administrerer identitetene som skal ha tilgang til applikasjonen som beskyttes. I konteksten hvor en applikasjon hos Drammen kommune bruker ID-Porten vil AM-løsningen foran tjenesten hos Drammen kommune være en Service Provider, mens ID-Porten vil være Identity Provider. ID-Porten inneholder alle brukerne som skal ha tilgang til tjenesten, og Service Provider stoler på at brukeren er autentisert når den er autentisert i ID-Porten. Rev: ÅPEN 10/10