Aiheen ‘PKI’ sisältävät artikkelit

Tänä keväänä d-vitamiinin puutteen lisäksi voivat väsyttää Microsoft Office 365:een liittyvät haasteet identiteetin hallinnan ymmärtämisessä. Microsoft pakottaa käsittelemään laajoja tietoturvakysymyksiä osana palvelusuunnittelua. Hyvänä esimerkkinä on julkisen avaimen infrastruktuurin (PKI, Public Key Infrastructure) vaatimus suurimpaan osaan loppukäyttäjäpalveluista.

Exchange, SharePoint ja Office Communicator tarvitsevat varmenteita toimiakseen oikein ja muodostaakseen tietoturvallisen toimintaympäristön. Tämä on lisännyt PKI:n tunnettavuutta, ja siitä on muodostunut osa suurempia infrastruktuurihankkeita.

Nyt Microsoft tuo markkinoille seuraavan keskeisen teknologian. Blogissammekin paljon puhuttu federointi on valittu tehokkaimmaksi tavaksi toteuttaa saumaton loppukäyttäjäkokemus kun kirjaudutaan Microsoftin pilvipalveluihin.

Federointi helpottaa pilvipalveluun siirtymistä

Federointi ei varsinaisesti ole vaatimus Office 365 käyttöönottoon, mutta ratkaisee suuren osan juuri niistä pahimmista kipukynnyksistä, joita on pilvipalveluun siirtymisessä. Tästä hyvänä esimerkkinä on kertakirjautuminen, vahvatunnistautuminen tai pragmaattinen esimerkki mahdollisuudesta siirtää loppukäyttäjän postilaatikko pilveen ilman tarvetta Outlook-profiilin uusimiseen.

Se, mikä näkyy loppukäyttäjälle sähköpostilaatikon saumattomana siirtymisenä, tarkoittaa pellin alla saman identiteetin säilymistä. Tämä saattaa kuulostaa joko todella huimalta tai merkityksettömältä. Eron ratkaisee se kuinka vahvasti identiteetin merkitys on sisäistetty.

Samoin kuin PKI:n käyttöönoton suunnittelussa myös federoinnin yhteydessä on hyvä ymmärtää, mitä mahdollisuuksia se tarjoaa, ja mitä ollaan varsinaisesti tekemässä. Kun siirrytään Microsoftin pilvipalveluihin tavoitteena voi olla säilyttää käyttäjähallinta aidosti paikallisessa aktiivihakemistossa tietojen replikoimisen sijaan.

Palvelimiin investointi maksaa itsensä takaisin

Tavoitteen saavuttamiseksi vikasietoiseen federointiympäristöön joutuu investoimaan neljän palvelimen verran (vikasietoinen federointi – ja vikasietoinen federointi proxy -palvelin). Palvelimet antavat lisää levytilaa sekä laskentatehoa ja palvelut helpottavat käyttöä, eikä käyttäjän tarvitse esimerkiksi kirjautua useaan järjestelmään vaan kertakirjautuminen riittää.

Jotta palvelimiin investoimisesta saataisiin kaikki hyöty irti, on hyvä miettiä mitä muita tekniikoita vaadittu AD FS 2.0 mahdollistaa. Esimerkiksi voidaan mainita seuraavat hyödyt:

• kumppanit voivat federoitua yrityksen itse tuottamaan sisältöön
• tiedon suojaamiseen käytettyjen RMS-palveluiden federointi
• mahdollisuus federoitua muihin pilvipalveluihin (matkalaskut, jne), ja
• mahdollisuus toteuttaa hallittuja ympäristöjä oman aktiivihakemiston ulkopuolelle, joihin federoidaan omien työntekijöiden identiteetit.

Federointistrategiasta paljon hyötyä

Blogin tarkoituksena on herättää keskustelua siitä, miten yhden ongelman ratkaisuun vaadittua teknologiaa voidaan hyödyntää laajemmin, mutta vaatimuksena on teknologian ymmärrys. Federointi ei itsessään tarkoita mitään vaan on lähinnä kattotermi useammalle toteutustavalle, kilpaileville standardeille, ja toisestaan hyvin poikkeaville tuotteille.

Vaikka federointi tai pilvipalvelut eivät tuntuisikaan vielä ajankohtaiselta, suosittelen että yrityksen kannattaisi tehdä federointistrategia. Tällä strategialla voidaan varmistaa, että käyttöönotetut ratkaisut tukevat valittuja teknologioita sekä vaadittuja tietoturva- ja toiminnallisuusvaatimuksia.

Strategian avulla voidaan palveluita ostaessa varmistaa, että yhdellä hankitulla ratkaisulla voidaan ratkaista ostettujen palveluiden identiteettivaatimukset. Lisäksi voidaan varmistaa, että yhteistyöyritysten kanssa rakennettaviin palveluihin valitaan ratkaisuja, jotka myös tukevat valittua linjaa.

Edellisissä blogikirjoituksissa kerrotaan tunnistuksenhallinnasta ja sen prosesseista.

Todentamiseen liittyvät kustannukset muodostuvat alla olevan taulukon tekijöistä. Taulukossa on esimerkinomaisesti arvioitu kahden eri teknologian kustannuksia.

-       Token: Perinteinen fyysisen tunnistevälineen ratkaisu, jossa                 kertakustannuksille on käytetty kolmen vuoden kuolettamisaikaa

-       PKI: Vaativampi varmennepohjainen ratkaisu, jossa kertakustannuksille on käytetty viiden vuoden kuolettamisaikaa

Taulukon kustannusarviot ovat euroissa per kuukausi per käyttäjä.

Käyttäjätunnistuksessa tunnistetaan kuusi eri prosessia: rekisteröinti-, toimitus-, uusimis-, palautus-, käyttö- ja vian selvitykseen liittyvät prosessit. Edellisessä blogikirjoituksessa kerrotaan tunnistuksenhallinnasta ja seuraavassa kustannuksista.

1) Rekisteröintiprosessi

Rekisteröintiprosessi on käyttäjätunnistuksen kannalta tärkein prosessi. Rekisteröintiprosessiin kohdistuvat vaatimukset saadaan määrittelemällä tunnistamisen eri käyttötapaukset ja niihin kohdistuvat vahvan tunnistamisen vaatimukset. Tunnistamisen käyttötapauksina on esimerkiksi asiakassuhteen sopimuksen muuttaminen kesken asiakassuhteen ja tämä käyttötapaus halutaan automatisoida tehtäväksi web-pohjaisesti. Tällöin sopimuksen muuttamisen hyväksyntään liittyvä käyttäjän tunnistaminen tulee olla sellainen, missä kiistattomasti voidaan jälkeenpäin osoittaa hyväksyjän identiteetti. Toisin sanoen vahvan tunnistamisen välineen rekisteröinnin yhteydessä on käyttäjän identiteetti todennettava esimerkiksi henkilön passista.

Jos oletetaan, että organisaatiolla on satoja tai tuhansia työntekijöitä ja vahvan tunnistamisen rekisteröintiprosessi suunnitellaan alun perin niin, että yllä mainittua käyttötapausta ei oteta huomioon niin silloin voidaan ajautua tilanteeseen, jossa organisaatiolla on vahvan todentamisen välineet jaettu, mutta ei kuitenkaan voida kiistämättömästi osoittaa että tietty tunnisteväline on tietyllä käyttäjällä.

Yllä olevasta esimerkkeinä ovat pankin asiakkaat, jotka tiliä avatessaan ovat todistaneet pankin henkilökunnalle oman henkilöllisyytensä. Pankki voi tähän rekisteröintiin liittyen perustaa myöhemmin nettipankin vahvan tunnistamisen.

2) Toimitusprosessi

Käyttäjien tunnistamiseen liittyvän fyysisen välineen (esim. toimikortti tai token) toimittaminen on etenkin useammassa maassa toimivalle organisaatiolle haastava hanke. Tällöin toimitukseen liittyy viiveitä ja lähettämiseen liittyviä kustannuksia kuten lähetys-, tulli-, ja veromaksuja. Nämä kustannukset voivat olla hyvinkin merkittäviä, sillä tulli- ja veromaksut tyypillisesti perustuvat kohdemaan viranomaisten arvioihin, jotka eivät välttämättä vastaa todellisia hankintakustannuksia. Esimerkiksi hankintaan liittyvät alennukset jäävät huomioitta. Esimerkkinä:

-       fyysisen välineen hankintahinta: 30 €

-       fyysisen välineen listahinta: 100 €

-       toimituskustannus per väline: 0.2 €

-       tulli- ja veromaksut: 25 % listahinnasta eli 25 €

-       fyysiseen toimittamiseen liittyvä manuaalityö: 40 €

Ylläolevasssa esimerkissä toimituskustannukset lisäsivät hankintahintaa 217 %:lla. Jos toimituskustannukset ovat merkittävä osa, niin organisaation kannattaa harkita vaihtoehtoisten tunnistustapojen käyttöönottoa, kuten esimerkiksi SMS-pohjainen kertakäyttösalasana tai ohjelmistopohjainen token.

3) Uusimisprosessi

Useilla vahvan käyttäjätunnistuksen tunnistusvälineillä on oma elinikänsä; varmenteet ovat tyypillisesti 1-3 vuoden eliniän omaavia ja fyysiset tokenit ovat joko lisenssimielessä rajoitettuja tai esimerkiksi niiden paristot tulevat jossain vaiheessa elinikänsä päähän. Uusimisprosessissa tulee miettiä:

-       kuinka käyttäjiä muistutetaan ennakkoon tunnistevälineen uusimisen tarpeesta

-       tuleeko uusiminen tehdä niin että käytetään vanhentuvaa tunnistevälinettä todentamiseen

-       tarvitaanko tunnistevälineen uusimiseen esimiehen tai palvelun omistajan hyväksyntä (esimerkiksi siitä generoituvan kustannuksen hyväksymisestä)

4) Palautusprosessi

Tunnistevälineen palautusprosessissa tulee huomioida kaksi erilaista seikkaa:

-       organisaatiosta poistuvan työntekijän tunnisteväline kerätään talteen ja poistetaan käyttäjän käytöstä

-       kerätyt tunnistevälineet palautetaan uudelleen käyttöön mikäli niillä on edelleen elinkaarta jäljellä.

5) Käyttöprosessi

Tunnistevälineen käyttöön liittyy ensisijaisesti tunnistevälineen käyttö käyttäjäntodentamistilanteessa. Tällaisia tapauksia ovat esimerkiksi vpn-yhteyden luonti tai etäsähköpostin lukemisen. Käyttäjille suunnattava ohjeistus ja koulutus ovat tämän prosessin tehostamisen kannalta kaikkein merkittävimmät tekijät. Lisäksi teknologiavalinnalla voidaan vaikuttaa käytön helppouteen, esimerkiksi valitsemalla yksi yhteinen käyttäjäntodentamisjärjestelmä, joka soveltuu riittävän hyvin eri käyttötapauksiin sen sijaan, että käytetään kahta tai jopa useampaa teknologiaa eri tarkoituksiin.

6) Vian selvitykseen liittyvät prosessit

Käyttäjätuen ohjeistus ja koulutus eri vikatilanteisiin tuo tehokkuutta ja kustannussäästöjä, kun yleisemmät vikatilanteet pystytään ratkaisemaan välittömästi. Vikatilanteita tulisi seurata ja raportoida säännöllisesti, jotta saadaan selville tyypillisimmät viat. Nykyisin eri tuotteilla on kattava valikoima erilaisia itsepalvelutoiminteita, joilla jopa osa vianselvityksestä voidaan suorittaa itsepalveluna.

Nykyisin etenkin puhelinalustoilla toimivat niin sanotut mobiilitoken-sovellukset voivat generoida huomattavan määrän vianselvityspyyntöjä verrattuna perinteisempiin fyysisiin token-ratkaisuihin.

Käyttäjien ja erilaisten sovellusten tunnistamiseen liittyy itse tunnistustapahtuma, siinä käytettävä teknologia sekä tunnistevälineiden hallinta. Tunnistaminen jaetaan tavanomaiseen ja vahvaan tunnistamiseen. Seuraavissa blogikirjoituksissa kerrotaan tunnistuksenhallinnan prosesseista ja sen kustannuksista.

Tavanomainen tunnistaminen

Tavanomainen tunnistaminen on tyypillisesti käyttäjätunnus ja salasana -pari, joka on halpa hankkia, mutta saattaa olla käyttökustannuksiltaan kallis jos mukaan lasketaan teknologian heikkoudesta aiheutuvat riskit. Lisäksi salasanojen unohtamisesta aiheutuvat käyttäjätuki-puhelut saattavat aiheuttaa yllättävänkin suuren kuluerän. Eri raporttien mukaan salasanan uusiminen (engl. resetting) aiheuttaa 15-30 euron kustannukset.

Vahva tunnistaminen

Vahva tunnistaminen määritellään niin, että käytössä on vähintään kaksi eri käyttäjätunnistuksen pääluokan komponenttia, jotka kuvataan kappaleessa Teknologia. Yleisempiä vahvan käyttäjätunnistuksen ratkaisuja ovat:

-       pankkikortti ja tunnusluku

-       fyysinen token ja tunnusluku

-       Toimikortti ja tunnusluku (Henkilön sähköinen tunnistaminen, HST)

Hieman harvinaisempia vahvan tunnistamisen ratkaisuja ovat seuraavat esimerkit:

-       Kulkukortti ja sormenjälki

-       Kasvojentunnistus ja tunnusluku

-       Varmenne puhelimessa (SIM-kortilla) ja tunnusluku

Teknologia

Käyttäjätunnistamisen komponentit voidaan jakaa kolmeen eri tekijään:

1) Jotain mitä käyttäjällä on

• Kulkukortti, puhelin, toimikortti, varmenne, fyysinen tunnisteväline, ohjelmistoperusteinen tunnisteväline

2) Jotain mitä käyttäjä tietää

• Salasana, tunnusluku (pin)

3) Jotain mitä käyttäjä on tai tekee

• Sormenjälki, iiris, dna, allekirjoitus, kasvot, ääni, käyttäytyminen

Yllä oleviin teknologioihin voidaan myös liittää erilaisia lisäominaisuuksia, joilla parannetaan ratkaisun tehokkuutta tai helpotetaan käyttökokemusta. Tällaisia ominaisuuksia ovat:

-       Mukautuva tunnistus; tunnistustapa valitaan esim. käyttäjäryhmän perusteella     sen sijaan, että kaikilla käyttäjillä on sama tunnistustapa.

-      Riskipohjainen tunnistus; ratkaisu laskee riskikertoimen tunnistustapahtumalle.

Microsoft -tuotteissa korostuu jatkuvasti varmennesuunnittelun keskeisyys. Hyviä esimerkkejä teknologioista, joissa olennaista on hallita varmenne-elinikää ja toiminnallisuutta ovat Direct Access ja Right Management Services. Näissä korostuu koko varmennesuunnittelun moninaisuus.

Keskustelin varmennesuunnittelusta tostaina 11.2.2010 Tietoturvatapahtumassa messukeskuksessa, ja huomasin että varmenteiden toiminnallisuus tunnetaan. Mikä on jäänyt merkittävästi vähemmälle keskustelulle, on mitä asioita pitää ottaa huomioon suunniteltaessa varmenteiden käyttöönottoa. Jos yritykselläsi on prosessi varmenteiden julkaisuun ja suunniteltuna sulkulistojen julkaisupaikat varmennekäyttötarkoituksen mukaan, tai varmenteita myöntävät palvelimet ovat luokiteltu myönntettyjen varmenteiden turvallisuusvaatimusten mukaan, olet selvästi paremmassa asemassa kuin suurin osa varmenteita käyttävistä yrityksistä.

Varmenteiden käyttöönotossa lähtökohta on tietoturvan kasvattaminen ja hallitseminen. Tämä asettaa suunnittelulle melkoisen vaateen. Varmenteet tulevat jatkossa muodostamaan merkittävän osan yrityksen tietoturvasta. Asiaa ei siis pidä ottaa kevyesti ja antaa asennusvelhon tehdä valintoja.

Varmennehierarkian toteutus ja suunnittelu on kuuma peruna, joka ei tunnu mukavalta paljaassa kädessä. Ratkaisukin löytyy. Patalapun sijaan suosittelen perusteiden haltuunottoa. Ainakin seuraavat peruskäsitteet tulisi olla näpeissä: varmenteiden käyttötarkoituksen kuvaaminen, hierarkiatasot varmennepalveluissa sekä sulkulistojen julkaisu. Tämän lisäksi on hyvä kuvata esimerkiksi valmiita pohjia hyödyntäen varmenteiden hallinta, ja varmenteiden myöntämisperusteet.

Hyvänä yleiskatsauksena toimii esim:
Designing a Public Key Infrastructure

Hiukan kevyempi kalvo show:
Tell me how PKI works in Plain English

Ja ei muuta kuin varmentamaan