Visjon IAM

En helhetlig tilgangsstyring er å se på flyten mellom de ulike komponentene som er nødvendige for å produsere autorisasjonsdata, samt ansvaret de ulike komponentene har.

Tilgangsstyring

Hva er egentlig tilgangsstyring? Det er ikke et klart definert begrep – i IT-sammenheng i alle fall – så det er noe risikabelt å forsøke å "løse" tilgangsstyring. Innen IT er tilgangsstyring ofte det rent tekniske man gjør i en tjeneste for å slippe inn kun de riktige brukerne, mens det å definere hva "riktige" er er uklart. Man kan si at tilgangsstyring er metoder for å sikre at tilganger kun gis til de som oppfyller et sett med predefinerte krav. Mer detaljert betyr dette å autentisere og autorisere noen eller noe basert på et sett med regler og ved hjelp av data som sier noe om at den eller det som autentiseres oppfyller reglene.

Plukker man dette fra hverandre så er det komponenter i en tilgangsstyringsprosess:

  • Autentisere  det å verifisere identiteten til en entitet. 
  • Autorisere – det å avgjøre om entiteten skal ha tilgang.
  • Regler – de grensene man setter for en tjeneste. Reglene er det som ligger til grunn for hvordan man autoriserer.
  • Data – for å kunne autentisere og autorisere så må man ha bakgrunnsinformasjon fra en sikker kilde, annet enn de data brukeren gir fra seg.

Tradisjonelt innenfor IT så har autentisering vært et mer tydelig område enn autorisasjon. Autentisering er ofte mer synlig siden brukeren må gi fra seg brukernavn og passord, mens autorisasjon skjer bak kulissene. Av erfaring vet vi at autentisering har vært større fokus på enn autorisasjon (jf. Feide, ID Porten, BankID, etc.), men det er også et faktum at man kan ikke tilgangskontrollere ved autentisering alene. Selv tjenester som ikke har noen regler og ikke gjør noen form for autorisasjon har implisitt autorisasjon i form av at brukergruppen som kan autentisere er begrenset og autorisasjon er satt til "alle som kan autentisere er autoriserte". Slik implisitt autorisasjon er risikabel da brukergruppesammensetningen kan endre seg uten at tjenesteeier er inneforstått med hva konsekvensen vil bli. Ved aktiv autorisasjon, der man kontrollerer om den autentiserte entiteten oppfyller visse krav, er ikke tjenesten sårbar for endringer i brukergruppesammensetningen. Slipper tjenesten inn alle ansatte og studenter så endres ikke dette om brukergruppen utvides med gjester. Det er derfor et mål om at tilgangsstyring skal inneholde eksplisitt autorisasjon

Ser man tilbake på firepunktslisten over så kan man vurdere dekningsgraden hos organisasjonen eller i sektoren:

  • Autentisering – i stadig endring, men godt ivaretatt. Flere løsninger, preget av utvikling og med mål om å konsolidere og forenkle.
  • Autorisere – undervurdert og preget av manglende fokus. Ingen bransjeledende protokoller for å gjøre autorisasjon. Overlatt til tjenestene å implementere.
  • Regler – delvis neglisjert av tjenesteeiere, men antagelig også preget av mangelen på gode og oppdaterte data.
  • Data – preget av dataråte og lite felles forståelse. 

Autentisering er ikke der skoen trykker jf. tilgangsstyring. Sektoren har hatt en sektorløsning i mange år og har egne løsninger innad i organisasjonene. Sentralisert autorisasjon, både i sektoren og innad i organisasjonen, er svært vanskelig å realisere da bransjen ikke har produsert noe rammeverk som er utbredt. Autorisasjon er langt mer enn å slippe inn/avvise etter autorisasjon og det vil være både kostbart og urealistisk å forsøke å løse sentralisert autorisasjon i sektoren. Regler vil være lokale for hver tjeneste og sterkt avhengig og påvirket av kvaliteten av data.

Data er det feltet sektoren har størst potensiale for innovasjon og gevinst. 

Begreper

  • Roller er en egenskap ved en entitet. Dette kan være noe konkret som en stilling, en plassering i organisasjonen, en tittel, deltagelse i en gruppe (som igjen kan være så mangt) eller en faktisk, håndfast rolle i et HR-system. I dette dokumentet brukes begrepet vidt for å favne alle disse egenskapene som kan affektere tilgangskontroll.
  • HR-system er som regel ett system (eller en del av et system) i organisasjonen, men i dette dokumentet benyttes begrepet om systemer som inneholder informasjon om mennesker som er relevante for tilgangsstyring. For BOTT er et slikt eksempel FS som inneholder mye HR-data, men som ikke ansees for å være et HR-system.
  • Autorisasjonsdata er et mer håndgripelig begrep enn tilgangsstyring da førstnevnte ikke omfatter selve handlingen "tilgangsstyring". Autorisasjonsdata vil f.eks. være en leveranse fra IAM, mens tilgangsstyring vil være disse dataene, regler for hvordan tilgangsstyre, samt de ulike systemene som er involvert i tilgangsstyingen. 

Premisser for tilgangsstyring

For aktiviteten tilgangsstyring så ligger det en del premisser til grunn. Enkelte er det konsensus for, andre er nok et emne for videre diskusjon. For å korte ned dette dokumentet så listes premissene her uten for mye bakgrunn.

Tilgangsstyring gjøres best ved at en satt egenskap på en person er det som gir grunnlaget for å tilgangsstyre. Mer konkret så betyr det at HR-systemet bør være kilden for det som blir autorisasjonsdata. Tar man et steg tilbake og ser på tilgangsstyring så er det roller for personer som betyr om konto A eller B skal slippe inn i tjeneste X. Slike roller kan være tilknyttet personen direkte eller personens stilling, for eksempel.

HR-data, som vil bli benyttet til tilgangsstyring, må ansees som virksomhetsdata og ikke interne data for de som jobber med HR og/eller lønn. Data må være i henhold og reflektere virkeligheten. Likeledes må HR være klare for å registrere og forvalte roller som tradisjonelt ikke har vært i HR-systemet eller som man ikke ser en intern nytteverdi i i HR-systemet. HR-systemet skal være autoritativt for HR-data.

HR-systemet er ikke autoritativt eller ansvarlig for for tilgangsstyringsdata eller autorisasjonsdata. HR-systemet er autoritativt for de data som legges til grunn for å regne ut autorisasjonsdata. Distinksjonen er viktig for å holde rede på hvilke systemer som har hvilke roller.

IAM er hovedsaklig et sett med forretningsregler for å oversette fra roller til autorisasjonsdata. Moduler i IAM kan ta seg av det å f.eks. legge til konti til autorisasjonsdata, være et sted for å opprette kortlevde grupper og lignende, men essensen i IAM er at det implementerer logikk for å oversette fra noe organisatorisk til noe maskinelt. Altså oversette roller til autorisasjonsdata.

IAM, akkurat som HR-systemet, er ikke ansvarlig for tilgangsstyring. Det er ansvarlig for å tilby autorisasjonsdata som er nødvendige for å tilgangsstyre. Mangfoldet av systemer, tjenester, behov og fremtidige behov gjør at en singulær tilgangsstyring ikke er gjennomførbart. Gevinsten ligger her i det å skaffe seg en sentral kilde til autorisasjonsdata som gir oss kontroll og oversikt. De tekniske implementasjonene rundt tilgangsskontroll vil variere og endre seg og er i denne kontekst mindre viktig.

Målbilde

Målbildet for BOTT bør være å ha en felles forståelse og overordnet mål. De ulike faktiske systemene de ulike BOTT-institusjonene har vil være ulike, hvordan man realiserer implementasjonen av dem og kanskje også organiseringen av dem. Med så store forskjeller så må målbildet abstraheres til noe som fungerer for BOTT.

Ulike HR-systemer sender HR-data inn til IAM (hvordan dette teknisk løses mtp. push/pull og integrasjon er mindre viktig for diskusjonen), IAM sender autorisasjonsdata til konsumenter. Konsumenter kan være tjenester som trenger data direkte eller oppslagsverk ala LDAP eller AD der tredjeparter slår opp data.

 Ser man på data inn og ut av denne kjeden så ser det slik ut:

En person får satt rollen "IT-ansvarlig" i HR-systemet. Denne handlingen vil utløse automatikk som overfører disse dataene til IAM som igjen oversetter dette til autorisasjonsdata - i dette tilfellet resulterer det i "admin"-tilgang i konsumenten. Likeledes vil det å fjerne slike roller måtte utløse den samme automatikken for å fjerne tilganger. IAM setter ikke tilgangen "admin" ute i konsumenten, men tilbyr data slik at konsumenten kan oppdatere dette selv.

De tre boksene HR, IAM og konsument er svært forenklet i foregående skisser. I realiteten vil IAM være en mer sammensatt tjeneste. Roller i HR-systemene bør være den drivende kraften bak autorisasjonsdata, men vi kan anta med stor grad av sikkerhet at dette ikke vil fungere i 100% av tilfellene. Noen ganger er ikke rollene fra HR entydig det samme som tilgangene man ønsker i en tjeneste:

Som en kilde til logikken som regner ut autorisasjonsdata så inneholder IAM en database med f.eks. temporære grupper/roller, tilganger som ikke kan eller skal representeres som roller eller tilganger som skal overstyres. Et eksempel på et slikt tilfelle kan være innleide konsulenter som skal gis tilgang til en tjeneste i en svært begrenset periode og der konsulentene ikke er kjent i HR-systemene. IAM-databasen bør da inneha egen logikk for å rydde i egne data slik at IAM ikke vokser på seg store og gamle unntak som undergraver hele modellen. 

 

Av Mathias Meisfjordskar
Publisert 4. nov. 2016 13:38 - Sist endret 26. sep. 2017 11:55