Teini-ikäinen identiteetinhallinta: Kapinointia ja tavaroiden heittelyä!

04/03/2016 | Kirjoittanut: Petteri Aatola | Aihe: IAM, Identiteetinhallinta (IdM), IoT

Identiteetinhallinta (Identity Management, IdM) on ehtinyt jo teini-ikään, joten nyt on hyvä hetki katsoa hieman taaksepäin. 2000-luvun taitteessa voimistui huoli siitä, että uudella työntekijällä saattaa mennä viikkoja saada sopivia käyttöoikeuksia oikeisiin järjestelmiin, ja kun ne viimein ovat kunnossa, työntekijä onkin jo siirtynyt seuraavaan projektiin, jossa tarvitaan taas lisää tai erilaisia oikeuksia.

Loogisena seurauksena oli se, että pitkään yrityksessä työskennelleelle kerääntyi erilaisia käyttöoikeuksia mitä mielenkiintoisempiin paikkoihin – tarvitsipa hän kaikkia niitä enää tai ei. Tällainen käyttöoikeuksien kasaantuminen rikkoo ”pienimmän oikeuden periaatetta” (principle of least privilege) mikä puolestaan aiheuttaa harmaita hiuksia tietoturvajohtajille (jollei kaikkia hiuksia ole tullut revittyä pois jo ennen tätä).

Least privilege? Harmaat hiukset? Peruutetaanpa hiukan.

Itsepalvelukulttuurin esiinmarssi

Identiteetinhallinnan ytimessä on sallia käyttäjille oikeanlainen pääsy juuri niihin järjestelmiin, joihin heidän kuuluu työnsä puolesta sillä hetkellä päästä – ja vain niihin. Jos organisaatio tai projekti vaihtuu, käyttöoikeuksienkin tulisi vaihtua sen mukaisesti. Näin syntyi käsite roolipohjaisista käyttöoikeuksista (Role Based Access Control, RBAC), joiden mukaan käyttöoikeuksia yrityksen IT-järjestelmiin annettaisiin sen perusteella, mitä rooleja käyttäjällä on.

Roolien ja käyttöoikeuksien toisiinsa linkittäminen osoittautui kuitenkin monessa organisaatiossa erittäin haasteelliseksi: Rooleja voi olla useita (linjaorganisaatio-, kustannuspaikka-, sijainti-, projektirooli jne.), ja käyttöoikeuksia vieläkin enemmän. Monessa organisaatiossa pelkästään Active Directoryn ryhmäjäsenyyksiä voi olla jopa enemmän kuin käyttäjiä. Haaveet täydellisestä RBAC-mallista haudattiin ja tilalle haettiin hybridimallia, jossa peruskäyttöoikeudet hoidetaan roolien kautta, jonka lisäksi on mahdollisuus hakea käyttöoikeuksia suoraan järjestelmiin.

Syntyi tarve itsepalvelulle, joka mahdollisti unohtuneiden salasanojen vaihtamisen, omien tietojen ylläpitämisen ja lisäoikeuksien hakemisen.

Villiä koodia palvelinkomerossa

Kysyntää vastaamaan innokkaimmat organisaatiot lähtivät kehittämään räätälöityjä, ns. in-house -järjestelmiä omiin IdM-tarpeisiinsa. Eri ohjelmistotoimittajat puolestaan marssittivat omia, enemmän tai vähemmän kypsiä ratkaisuja markkinoille tiuhaan tahtiin. Ohjelmistovalmistajat lähestyivät haasteita hieman eri näkökulmista: Siinä missä toisissa ratkaisuissa painotettiin enemmän käyttöliittymää ja käytettävyyttä, toisissa tarjottiin hyviä rajapintoja erilaisiin kohdejärjestelmiin.

Tiedon jäljitettävyyden kannalta on selvää, että käyttöoikeudet täytyy luoda IdM-järjestelmästä automaattisesti suoraan kohdejärjestelmään ilman välikäsiä (lue: ihmistä). Ainakin paperilla näin. Jotta IdM-järjestelmä kykenee luomaan käyttöoikeuksia eri kohdejärjestelmiin, tarvitaan rajapintoja joihin kytkeytyä. Kehitys kehittyy, ja jo 1990-luvulla alettiin kiinnittää entistä enemmän huomiota siihen, että itsenäisten sovellusten sijaan eri tietojärjestelmien tulisi kyetä juttelemaan toisilleen ilman, että joku painaa nappia välissä.

2000-luvun taitteessa SOA:sta ei kukaan puhunut vielä mitään, mutta pinnan alla tapahtui paljon. Vuonna 1999 julkaistiin ensimmäinen versio DSML:stä (Directory Service Markup Language), joka rakensi sillan perinteisten hakemistopohjaisten järjestelmien ja uudempien XML:ää hyödyntävien ratkaisujen välille. Lisää seurasi hieman myöhemmin, kun OASIS esitteli SPML:n (Service Provisioning Markup Language). Sen myötä esiteltiin XML-framework, joka mahdollistaa identiteetin provisioinnin järjestelmästä toiseen – yhdessä organisaatiossa tai monen organisaation välillä.

SPML ei kuitenkaan koskaan saavuttanut kriittistä massaa, ja nykyään se vaikuttaa olevan yksi historiallinen kirjainlyhenne muiden joukossa. Miksi näin? Ehkäpä siksi, että vielä 2000-luvun puolivälin aikaan organisaatioiden provisiointitarpeet kohdistuivat lähes yksinomaan omissa tiloissa pyöriviin järjestelmiin. Järjestelmien tietokantoihin tai hakemistoihin pystyi kirjoittamaan suoraan, ja joskus toteutettiin jopa ”pull-provisiointia”, jossa kohdejärjestelmän aliprosessit lukivat käyttäjä- ja käyttöoikeustietoja suoraan IdM-järjestelmästä. IT-osastojen propellihatut ovat rakentaneet vuosien varrella monen monta rautalankaviritystä eri järjestelmien välille – eikä tämä koske vain IdM-aluetta.

Pistääkö pilvi viimein standardoimaan?

2010-luvulla pilvipalveluiden kysyntä räjähti, ja sen vaikutukset levisivät nopeasti myös IdM-järjestelmien omistajien pöydille. Yhtäkkiä olikin tarve kirjoittaa identiteettidataa ”tuonne jonnekin”; paikkaan, jonka tietokantaan ei päässyt kirjoittamaan suoraan tai joka ei tarjonnutkaan LDAP-rajapintaa TCP-portissa 389. Paikallinen järjestelmäylläpitäjä oli vaihtunut kasvottomaan, usein yhdysvaltalaiseen, toimittajaan, jolle ei voinut soittaa.

Eri pilvipalvelutoimittajat kehittivät kilpaa omia integrointirajapintojaan, ja standardit unohtuivat matkalle. CSV-tiedosto ja FTP-palvelin tekivät väkevän paluun. Toimivaa kyllä, mutta ei ehkä niin siistiä. Eräajoja ajettiin/ajetaan parhaimmillaankin vain muutaman kerran vuorokaudessa; yhtäkkiä reaaliaikaisista ja tapahtumapohjaisista vaatimuksista olikin päästettävä irti vain siksi, että uusin teknologia ei tukenut niitä.

Periaatteessa SPML olisi voinut jopa taipua pilvipalveluiden provisiointistandardiksi, mutta koska samanaikaisesti www-maailmassa notaatiopuolella JSON jyräsi XML:n ja REST SOAPin, näin ei käynyt. XML-perusteinen SPML jäi käsitteeksi, ja tilalle tuli SCIM (System for Cross-domain Identity Management), jonka ovat ottaneet käyttöönsä jo ainakin Google ja Salesforce. Nähtäväksi jää, onko SCIM ratkaisu identiteettidatan siirtämiseen pilvipalveluihin.

Käyttäjäprovisiointia tehdään myös SAML-standardia (Security Assertion Markup Language) hyödyntäen. Vaikka SAML yhdistetään enemmän kertakirjautumiseen, jotkin pilvipalveluntarjoajat tarjoavat just-in-time –provisiointia (SAML JIT), jossa käyttäjän tiedot siirretään palveluun kirjautumisen yhteydessä. Mitä enemmän erilaisia pilvipalveluja lanseerataan, sitä tärkeämpää olisi, että palveluntarjoajat siirtyisivät kohti standardiratkaisuja. Erityisesti näin IdM-toimittajan näkökulmasta toivottavaa olisi, että pilvipalveluiden valintaperusteeksi yrityksissä asetettaisiin, monen muun perusteen lisäksi, provisiointirajapinnat.

Seuraavaksi: Identity of Things

Siinä missä identiteetinhallinta tarkoittaa nykyään useimmille yrityksille ja organisaatioille organisaation omien käyttäjien tai asiakkaiden käyttöoikeuksien hallintaa, tulevaisuudessa se voi olla ihan jotain muuta. Yhä useammasta organisaatiosta voi tulla identiteettipalveluntarjoaja laitteille – tai ”asioille”.

Miten moottorisahavalmistaja ratkaisee sahojen identieetinhallinnan, kun ne halutaan kytkeä verkkoon jonain päivänä? Kuka omistaa sahan identiteetin, ja mistä identiteettitieto tulee? Sahojen HR:stä? Entä miten huolehditaan tietoturvasta ja yksityisyydensuojasta, kun moottorisahaan halutaan asentaa mahdollisimman yksinkertainen tietokone, joka ei suoriudu nykyaikaisesta salausalgoritmien laskennasta? Ja jos joku varastaa metsurin moottorisahan mukana sahan identiteetin, onko se identiteettivarkaus? Vuotavatko omistajan tiedot varkaan käsiin, jolloin laitteen kautta omistaja joutuu identiteettivarkauden uhriksi? Mitä kauemmas perinteisestä yritystoiminnasta identiteetinhallinnan käsitteitä ja teknologioita viedään, sitä kauempana ovat myös nykyiset prosessit, toimintatavat ja tekniikat.

Tekniikoiden ja standardien syntymiseen ja vakiintumiseen menee aikaa, mutta niiden tarve korostuu siinä vaiheessa, kun kymmenet miljardit laitteet ja asiat rynnistävät internetiin. Kehittyvätpä asiat mihin suuntaan tahansa, Spellpoint on etujoukoissa ratkaisemassa niitä.

Panu Mälkki
Senior IAM Consultant