Kategorian ‘Blogi’ artikkelit

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.

Kirjoitin maaliskuussa edellisen blogimerkinnän muutosjohtamisesta. Tässä aikaisemmassa kirjoituksessa oli kaksi pääteemaa.

Ensimmäinen oli, että muutosjohtaminen vaatii paljon johtamistaitoja, joita on vaikea oppia muuten kuin tekemällä, kokemalla ja kuuntelemalla. Toinen teema oli, että erilaiset ohjelmistotuotteet, jotka ratkaisevat identiteettien ja käyttövaltuuksien hallinnan ongelmia, tulevat parhaiten hyödynnetyksi kun ne otetaan käyttöön tavalla, joka on yhteensopiva organisaation muutoskyvyn ja -edellytysten kanssa.

Olen saanut eri tahoilta palautetta, joka viittaa siihen, että jälkimmäinen teema ei ole selkeästi argumentoitu ja olen samaa mieltä. Tästä syystä ajattelinkin, että edellinen merkintä ansaitsee jatko-osan. Maalaisjärjellä selitettynä ajatus on aivan selvä: Ei kannata ottaa käyttöön tuotetta joka on suunniteltu ratkaisemaan yksinkertaisempaa ongelmaa kuin mitä IAM-hankkeessa vaatimusten nojalla tulisi ratkaista. Niin ikään ei kannata alkaa ratkaista vaikeampaa ongelmaa jos vaatimusten ja analyysin mukaan näyttää, että vähempikin riittäisi. Jos hanke tekee eri asioita kuin se viestii ulospäin, hankkeen ympärillä oleva suunnittelu vaikeutuu.

Maalaisjärjessä on kuitenkin se ongelma, että se ei kovin usein toimi kaupallisten ja poliittisten voimien puristuksissa joita jokainen organisaatio ja hanke on pullollaan. Tästä syystä selitykseksi ei riitä edellinen argumentti vaan vaaditaan jotain määrämuotoisempaa ja konkreettisempaa.

Esitin Management Eventsin IAM-seminaarissa syyskuussa Crowne Plazassa erään ajatusmallin, joka voisi toimia konkretisoivana mallina ja haluaisinkin jatkaa keskustelua tämän mallin tiimoilta muiden ammattilaisten kanssa, joten tervetuloa kommentoimaan. Malli lähtee siitä, että pyrkisimme ymmärtämään IAM-hankkeen luomasta muutostilanteesta määrämuotoisesti seuraavan kuvan esittämiä suhteita.

Malli väittää seuraavia asioita:

1. Yrityskulttuurilla on vaikutussuhde organisaation tekemiin teknologiavalintoihin. Dynaaminen haastajayritys, joka haluaa olla edelläkävijä ja myös investoi tähän asemaan rahaa ja aikaa, valitsee todennäköisemmin teknologioita joilla on paljon potentiaalia vaikka kaikelle ei voisi laskeakkaan heti business casea. Edelläkävijäyrityksiä myös leimaa usein rohkeus tehdä päätöksiä perustuen enemmän intuitioon kuin tarkasti analysoituihin vaihtoehtoihin. Toisaalta taas yritys, jonka kulttuuri on henkeen ja vereen välttää kaikkia riskejä, tulee todennäköisesti tekemään teknologiavalintoja sen suhteen, mikä on aikaisemmin toiminut mutta ei välttämättä tue uusimpia mahdollisuuksia, etenkään niitä joita on vaikea argumentoida.
2. Teknologiavalinnat puolestaan vaikuttavat (triviaalisti) teknisiin rajoitteisiin, eli siihen, mitä ylipäätään on mahdollista. Jos esimerkiksi valitaan suljetun lähdekoodin tuote ilman laajennusmahdollisuuksia, on joko elettävä tämän tuotteen kanssa tai sitten vaihdettava koko tuote.
3. Tekniset rajoitteet ovat jotain, mitä pitää ajatella luonnonvakioina projektinäkökulmasta. Jos jokin asia ei ole käytettävissä olevien resurssien puitteissa mahdollista, se vain ei ole mahdollista. Organisaatiomuutoksen ja teknisten rajoitteiden välinen nuoli kuvaa tätä suhdetta. Muutokseen tähtäävä projekti ei voi luoda edellytyksiä organisaatiomuutokselle, jos jokin tekninen asia konkreettisesti estää muutoksen toteutumisen. Esimerkkinä tästä voidaan ottaa erään yrityksen hanke, missä yhdistettiin yritysostojen tuloksena syntynyttä toimintoryvästä. Tässä hankkeessa otettiin teemaksi toimitamallien yhtenäistäminen, joka oli tavoite numero yksi. Ei liene mitenkään yllättävää, että toimintamallien muutos osoittautui kalliiksi ja hankalaksi, siellä jokaisessa ostetussa yrityksessä käytettiin eri tavoilla toimivia ohjemistoratkaisuja liiketoimintojen pyörittämiseen. Jälkiviisaus tästä oli se, että hanketta ei kannata brändätä vain toimintamallien yhdistämiseksi jos kyseessä on oikeasti järjestelmien konsolidaatio ja käyttäjien uudelleenkoulutus.
4. Viimeinen nuoli mallissa (organisaatiomuutoksesta yrityskulttuuriin) puhuu tilanteesta, missä hanke on saatu valmiiksi ja organisaatiomuutos jalkautuu osaksi yrityskulttuuria. Tämä tapahtuu joka tapauksessa, ja onnellisesti päättyvissä tapauksissa tämä jalkautuminen on hallittu toimenpide. Huonosti muutosjohdetuissa tapauksissa tämä on kaoottinen luonnonvalinta joka ei ole kenenkään hallinnassa. Esimerkki jälkimmäisestä tapauksesta on erään toimijan SAP-migraatio, missä hanke saatiin maaliin maalin määritelmiä jatkuvasti muuttamalla ilman, että muutoksilla oli mitään vaikutuksia ymäristöön. Lopullinen jalkautuminen tapahtui, kun henkilöstö- ja asiakashallinnan prosessit muuttuivat joka päivä kallispalkkaisten konsulttien integroidessa kiireellä keskenään epäyhteensopivia järjestelmiä SAP-alustaan.

Tätä dynamiikkaa ymmärtämällä voidaan etukäteen pyrkiä hallitsemaan lopullista organisaatiomuutosta ja sen jalkautumista yrityskulttuuriin. Tyypillisellä IAM-hankkeella on etupäässä vaikutusmahdollisuuksia teknologiavalintoihin ja niiden aiheuttamiin teknisiin rajoitteisiin. Me Trusteqilla pyrimme siihen, että homma hoidetaan kunnolla loppuun asti ja teknisen työn ohella avustamme asiakkaitamme hallitsemaan tuotteiden luomien teknisten rajoitteiden ja mahdollisuuksien vaikutuksia organisaatioon ja sen muutokseen.

IAM haltuun – miksi ja miten?

IAM, nuo kolme suurta kirjainta, tarkoittavat käyttäjätietojen- ja pääsynhallintaa. Se on niin kovaa erikoisosaamista vaativa alue, että Suomessa IAM-hankkeet keskimäärin epäonnistuvat. Tämä johtuu siitä, että IAM-hankkeet ovat haastavia. Niissä kokeneenkin tietohallintojohtajan kannattaa kysyä meiltä apua. Olen nähnyt, kuinka Trusteqin IAM-kyvykkyysmalliin perustuva työskentelytapa varmistaa hankkeen onnistumisen.

Miksi IAM on niin haastavaa?

IAM-hankkeista on kokemuksemme mukaan vain 20 % tekniikkaa ja jopa 80 % hallinnollisia asioita. Tästä syystä ei auta, että vain ostat ”hyvän ohjelmistotuotteen”. Ohjelmiston valinnalla aloitetut projektit kun harvoin onnistuvat täyttämään suuria odotuksia. Silloin on lähdetty liikkeelle väärästä päästä.

Identiteetin- ja pääsynhallinta (IAM) on tietoturvallisuuden ja IT-hallinnon osa-alue, joka integroituu parhaimmillaan kaikkiin organisaation tietojärjestelmiin. Painotan: kaikkiin. Kun me opastamme asiakkaitamme IAM:ssä, kaikki tietojärjestelmät tulee otettua huomioon.

Myös henkilöasiat ovat merkittävässä asemassa. Pienessäkin IAM-hankkeessa voi olla enemmän kuin yksi hankkeen onnistumiseen vaikuttava henkilö, ja usein onkin. Mukana on monesti ammattilaisia sekä IT- että liiketoimintapuolelta. Tietojärjestelmien käyttäjiä voi yrityksessä olla puolestaan tuhansia, jopa kymmeniä tuhansia. Käyttäjien ja käyttöoikeuksien hallinnan prosesseissa on mukana useita osapuolia: esimiehet, sovellusomistajat, palvelukeskuksen väki, vain muutamia tärkeimpiä mainitakseni.

Miten hallita IAM?

IAM:ää hallitessa täytyy hallita nimenomaan kokonaisuus. Koska yritys koostuu monenlaisista liiketoiminta-alueista ja organisatorisista vastuualueista, IAM:ää kehitettäessä on huomioitava yhteen kyvykkyysalueeseen keskittyvien hankkeiden vaikutus muihin alueisiin – ja myös vaatimukset muilta alueilta. Ratkaisu vain yksittäiseen ongelmaan voi olla joskus paikallaan, jos ongelma on merkittävä liiketoiminnan vaateiden tai tietoturvan varmistamisen kannalta. Silti siinäkin tapauksessa on varmistettava ratkaisun soveltuvuus IAM-alueen kokonaisarkkitehtuurin kannalta.

Me Trusteqilla lähestymme tätä ongelmakenttää IAM-kyvykkyysmallin avulla. Siinä IAM jaetaan seitsemään merkittävään alueeseen, joita tarkastellaan syvällisesti. Kyvykkyysmallin avulla voit selvittää meidän kanssamme tarkasti ja luotettavasti, millä tasolla yrityksessänne nyt ollaan IAM-asioissa. Sen avulla voit myös määrittää kanssamme sen, millä tasolla haluatte jatkossa olla. IAM-kyvykkyysmalli näyttää kaiken oleellisen tiedon näistä asioista havainnollisessa ja helposti toimenpiteiksi ja prioriteeteiksi saatettavassa muodossa.

Suurikin, koko organisaation kattava IAM-kehityshanke saadaan ruotuun jakamalla se osiin IAM-kyvykkyysmallin mukaisesti ja tunnistamalla osien riippuvuudet. Pienemmissä kehityshankkeissa puolestaan ymmärretään ratkaisun soveltuvuus olemassa olevaan infrastruktuuriin ja prosesseihin, sekä tunnistetaan vaikutukset organisaation IAM-ohjelmaan.

Trusteqin määrätietoinen kasvu on taas noteerattu mediassa. Keskiviikkona 1.9.2010 Tietoviikko julkaisi listan 14 haastajayrityksestä jotka tulevat todennäköisesti esiintymään lähivuosina 250 suurimman ICT -yrityksen joukossa. Olemme nyt toista vuotta haastajalistalla ja liikevaihto, tulos ja henkilöstö on edelleen kasvanut ja kehittynyt odotusten mukaisesti.

Tämän vuoden haastajalistan nimet olivat vaihtuneet kahta lukuun ottamatta. (lähde: tivi.fi)

Näiden kahden vuoden jälkeen Trusteqin tavoitteena on poistua haastajalistalta ja siirtyä 200 suurimman joukkoon tuonne 250 -listalle.

Julkishallinnon federoinnin Virtu-speksi on ollut nyt olemassa vajaan vuoden. Suurta innokkuutta Virtun käyttöönottoon ei ole tullut valtiohallinnon organisaatioiden parissa. Miksi näin?

Virtu-speksi on derivoitu yliopistojen käyttämästä Haka-speksistä. Julkishallinnon toimintaympäristö on kuitenkin kovin erilainen kuin yliopistojen välinen avoin yhteistyö. Haka:ssa kaikki käyttäjästä tarvittavat tiedot (= attribuutit) ovat mukana federointiviestissä ja järjestelmät poimivat siitä tiedot tarpeen mukaan käyttöönsä. Businessmaailmassa, jossa julkishallintokin käytännössä elää, asia on kuitenkin kovin erilainen. Iso osa sovellutuksista, joiden käyttöä juuri Virtu helpottaisi, pyörii kolmansien osapuolien ylläpitäminä tai omistamina. Ja usein näille kolmansille osapuolille on tarpeen tietää tarkka käyttäjämäärä esim. laskutusperusteeksi. Lisäksi osalla sovellutuksista on pitkä historia ja sovellus on pultattu kiinni käyttäjädataan niin tiivisti, ettei sitä pystytä purkamaan. Näissä tapauksissa käyttäjädata siis pyörii sovellutuksessa ja sitä ei voida federoida “lennossa” sovellukseen. Tällaisille sovelluksille federointi on vain puolet ratkaisusta ja käytännössä täyttää vain SSO:n vaatimukset. Käyttäjähallinnan haasteet jäävät kuitenkin jäljelle. Tällaisia ovat esimerkiksi käyttäjätilien perustaminen sovellukseen (provisioiminen) ja niiden poistaminen (deprovisiointi) ja nämä ovat usein vähintäänkin yhtä iso ongelma automatisoida kuin itse federoinnin toteutus.

Virtuun liittymisen vaatimuksiin on listattu myös valtiohallinnon tietoturvatasojen mukaiset auditoinnit. Auditointi on varsin raskas prosessi ja mielestäni jokseenkin turha vaihe pakottaa tehtäväksi tässä yhteydessä. Olisi hyvä, että auditointiin kannustettaisiin organisaatioiden oman parhaan vuoksi, eikä sitä asetettaisi rasitteeksi uusien tekniikoiden käyttöönotolle. Lisäksi sovellusten vaatimat tietoturvatasot tulisi olla määriteltyinä ennen kuin vaaditaan IdP-järjestelmille jotain tiettyä tasoa, muuten tietoturvatasot menettävät merkitystään.

Yleisesti on suositeltava, että julkishallinnon organisaatioiden olisi hyvä omistaa oma IdP tai sitten olla mukana jossakin yhteisessä IdP:ssä. IdP:n hankinta ei nykypäivänä ole ongelma, tarjontaa löytyy niin Open Source kuin kaupalliseltakin puolelta ja myös Virtuun erikoistuneita konsulttitaloja löytyy. IdP:n voi myös hankkia SaaS-palveluna, jolloin oma investointikin on minimaalinen. Viralliseen Virtuun liittyminenkään ei aina ole pakollista (tietoturva-auditoinnit) vaan tarvittaessa IdP – SP tahojen välillä voidaan tehdä kahden väliset sopimukset vaikkakin itse federointiviesti olisi Virtun mukainen. Tällöin organisaatio voisi joustavasti liittyä Virtuun suorittamalla tietoturvatasojen mukaisen auditoinnin, infra kuitenkin olisi jo yhteensopiva siihen. Jos organisaatiolla ei kuitenkaan ole perus IAM-infra kunnossa, niin IdP:n täysimittainen käyttäminen voi olla vaikeaa.

Suurimpana ongelmana näen käyttäjätietojen hallinnan (provisiointi ja deprovisiointi). Niin kauan kuin tähän problematiikkaan ei tule malliratkaisuja, joita julkishallinnon piirissä käytettäisiin, federoinnin leviäminen on hidasta ja siitä ei saada täyttä hyötyä irti. Myös tietoturva-aspektista tilanne on haastava niin kauan kun esim. deprovisioinnin laadusta ei voida mennä varmuuteen. Tätä problematiikkaa käsittelee mm. Gartnerin raportti “The Emerging Architecture of Identity Management“.

Kun miettii tarkemmin yllämainittuja seikkoja ja myöntää sen faktan, että federoinnista on turhalla jargonilla tehty hyvin monimutkainen asia ymmärtää, niin Virtun käyttöönoton innostuksen puutetta on helppo ymmärtää.

Nyt kun kesälomat alkavat olla pikkuhiljaa ohi, on hyvä hetki pysähtyä miettimään kesän tuomia haasteita.

Perinteisesti tietoturvanäkökohdista nostetaan esiin tiedon hakeminen ja yrityksen resursseihin muodostetut yhteydet ei-luotetuista lähteistä. Yrityksen työntekijöistä seikkailija-Pete, jonka kesäloman kohokohta on nettiin pääseminen Bagdadin Bunker Bar:in julkiselta koneelta, nostetaan esiin, ja ratkaisuna yrityksen access management -laitteistoista käännetään tietoturvanupit kaakkoon. Tällä saadaan luonnollisesti ratkottua kiusallinen ongelma, jossa yrityksen resursseja käsitellään epämääräisellä kioski-linux/windows -koneella. Mielestäni tämän ongelman ratkomisesta on puhuttu tarpeeksi, ja suurimmasta osasta tietoturvalaitteiden powerpoint-suosta löytyy joku ehdoitelma tai ratkaisu ongelmaan.

Tässä blogikirjoituksessa onkin tarkoitus puuttua mielestäni paljon kiinnostavampaa ongelmaan. Nimittäin oikeuksien myöntämiseen ja hallinnointiin lomien aikana. Governance -mallissa oikeuksien myöntäminen voidaan yksinkertaistaa oikeuksien hallintaan ja oikeuksien hallinan seuraamiseen.
Otetaan leikkisä esimerkki, jossa edellä mainittu Pete toimii osa-aikaisena työntekijänä koulun ohella, ja joka talvella on puuhastellut projekti A:n parissa. Kesällä, projekti A:n pysähtyessä, halutaan Peten luova panos siirtää projekti B:n käyttöön. Kiusallisesti projekti B:n oikeuksien myöntäminen tapahtuu projekti B:n esimiehen toimesta, joka istuskelee mökillään, josta myrsky on katkonut sähköt ja kalja lämpenee kaapissa. Petelle oikeuksien saaminen vaatisi kaksi erillistä vaihetta. Lomien alkaessa voidaan delegoida oikeus antaa oikeuksia projektin resursseihin, ja myönnetyistä oikeuksista pitää jäädä selvä ja näkyvä audit trail jota voidaan myöhemmin seurata ja varmistaa että oikeuksien antamisessa käytettiin valmista myöntämismallia. Tähän löytyy runsaasti ratkaisuita, mutta helppona esimerkkinä voidaan mainita Microsoft Forefront Identity Managerin ryhmienhallintatyökalut. Valmiiksi kuvatut prosessit ja integroidut hallintatyökalut mahdollistavat joustavan ja seurattavan vastuuiden siirron ja auttavat yritystä säilyttämään ketteryytensä ilman heikkenevää tietoturvaa.

Kevään hiihtolomat ovat jo kulman takana, joten ei muuta kuin suunnittelemaan.

Ajattelin kirjoitella kesähelteitä odotellessa muutaman artikkelin rooleista keskisuuren tai suuren yrityksen tai muun kookkaan organisaation tiedonhallinnallisena haasteena. Tämä siksi, että roolitiedon ottaminen haltuun näyttää olevan toisaalta vaikeaa, mutta myös toisaalta asia, jota ei ole totuttu lähestymään tiedonhallintaongelmana. Teoriani on, että se on vaikeaa juuri siksi, että lähestymistapa ongelman ratkaisuun on väärä.

Tässä ensimmäisessä kirjoituksessa käyn läpi sitä, mitä roolitieto on ja mihin sitä käytetään, sekä miksi sen haltuunottoon lähdetään usein väärästä päästä, eli softatuotteen ostamisesta.

Käytännönläheisen tekijäfirman, kuten Trusteqin, kannalta asia on erittäin mielenkiintoinen, mutta minusta perusymmärryksen haltuunotto on suositeltavaa kaikille tietoturvasta kiinnostuneille, sillä kuten kaikki tiedämme, on olemassa oikeaa tietoturvaa ja sitten valitettavasti paljon valohoitoa, jolla ei välttämättä ole tietoturvan kanssa mitään tekemistä.

Niinikään minusta on hieman epämiellyttävä ajatus, että toistaiseksi yksikään roolienhallintaan käytettävän ohjelmistotuotteen edustaja ole juurikaan ymmärtänyt mistä olen heille puhunut kun avaan keskustelua roolitiedonhallinnasta. Tässä asiassa ostajan on helppo olla myyjää fiksumpi ja näin saada itselleen onnistunut hanke.

Tiedonhallintamielessä asia on minusta päivänselvä. Roolitietoa tarvitaan kaikissa organisaation osissa ja kaikkien organisaation osien olisi hyvä ymmärtää roolitieto samalla tavalla, oli sitten kyse ihmisistä tai tietojärjestelmästä. Mitä sitten tämä roolitieto on? No, kaikissa organisaatioissa esitetään jatkuvasti seuraavia kysymyksiä osana yrityksen jokapäivästä toimintaa:

• Kuka on kenenkin esimies?
• Mikä osasto on vastuussa mistäkin?
• Mikä on työntekijän A toimenkuva?
• Mihin järjestelmiin pitäisi A:n päästä toimenkuvansa puolesta?

Roolitieto siis toimii tienviittana, kun organisaatiossa jaetaan vastuita ja velvollisuuksia. Ja näiden vastuiden ja velvollisuuksien toisaalta pitäisi kohtuullisen tarkasti heijastella pääsyä tietojärjestelmiin, jotta voidaan puhua hallitusta ja turvallisesta järjestelmästä. Roolitieto kuvaa siis osaltaan sitä loogista rakennetta, mitä organisaatio on ja mitä sen sisällä tulisi tapahtua vastuumielessä kun jotain työtä tehdään.

Eli meillä on tietoa, joka toisaalta pitäisi ymmärtää samalla tavalla joka puolella organisaatiota ja joka toisaalta pistäisi olla jotenkin hallittu siten, että sekä liiketoiminta että IT-järjestelmät voisivat toimia yhteen tehokkaalla tavalla. Mitä tämä tieto siis tiedonhallinnallisesti on?  Tämä on se kysymys mihin roolienhallintasovellusten valmistajat minusta eivät ymmärrä vastata oikein. Aivan oikein, kysymys on organisaation master datasta. Keskimäärin kuitenkaan role management-hanke ei ole lähelläkään master data management-hanketta lähestymistavan, resursoinnin tai käytettyjen menetelmien kannalta katsottuna.

Olen myös synkkänä päivänä miettinyt, että voiko tämän melko itsestäänselvän havainnon sivuuttaminen olla tarkoitusellista? Jokainen master data- tai data management hankkeita läpikäynyt tietää, että kyseessä ei ole helppo homma. Ensimmäinen tapa mokata ko. hanke on ostaa softatuote, jonka sitten toivotaan ratkaisevan ongelman. Roolien hallinta, kuten data management yleensäkin, on lopulta hyvin prosessi- ja ajatusintensiivistä puuhaa johon toki tarvitaan työkaluja, mutta itse ongelma ei työkaluilla ratkea.

Jos ajatellaan vaikkapa tietoa joka on yleisesti hyväksytty master dataksi, huomataan miksi näin on. Valitaan esimerkiksi tuotedata, eli mitä tuotteita yritys myy ja mitä tietoa näihin liittyy (versioriippuvuudet, dokumentaatio, hinta, vastuullinen osasto jne). Uskooko joku, että on olemassa ohjelmistotuote, joka automaattisesti selvittää mitä tuotteita yritys valmistaa ja keräilee näistä kaiken niihin liittyvän tiedon? Ei varmasti. Toisin sanoen, tarvitaan ihmisiä muokkaamaan dataa informaatioksi, joka sitten syötetään tietojärjestelmään, joka toimii tuotetiedon master-järjestelmänä.

Tilanne ei muutu juuri mitenkään kun tuotetieto vaihdetaan roolitiedoksi. Edelleenkään softa ei sitä automaattisesti muodosta, vaan roolitiedon hallintahankkeeseen tarvitaan mukaan osaavia ihmisiä, jotka tutkimalla organisaatiota ja tallennettua tietoa selvittävät, mitä rooleja firmassa oikeasti on ja miten nämä parhaiten organisoidaan rooleiksi.

Toinen, jopa ehkä vahvempi argumentti sen puolesta, miksi roolienhallinta tulisi tehdä ennemmin tiedonhallintahankkeena on, että roolit muuttuvat organisaation muuttuessa ja niiden luonti, muutos ja poisto tulisi tehdä osana jotain ei-teknistä (esim. HR) prosessia ennemmin kuin IT-osaston toimesta. Loogisella tasolla tiedonhallinta on lähempänä business arkkitehtuuria kuin IT-arkkitehtuuria ja prosessien mallinnus on osa business arkkitehtuuria eikä niinkään IT-työ. Varsinaiset vastuut prosessien ja informaation mallintamisesta toki vaihtelevat yrityksittäin, joten tätä on vaikeampi perustella. Tärkeää kuitenkin on, että oikean alan osaajat tekevät työn ja prosessien pyörittämisen vastuu luovutetaan sinne, missä se parhaiten pystytään hoitamaan.

Loppuyhteenvetona: Roolitieto, eli mitä kenenkin on tarkoitus tehdä firmassa ja kuka kantaa vastuun, on minusta selvästi organisaation master dataa. Tästä syystä roolienhallintahankkeita, jotka usein ovat osana IAM-hanketta, tulisi suunnitella, johtaa ja toteuttaa tiedonhallintahankkeina. Kun roolitieto on muodostettu ja hallittu oikein organisaatiossa, IAM-hankkeessa on suhteellisen helppo muodostaa näistä pääsynvalvonnan kannalta merkityksellisiä järjestelmärooleja, jotka sitten edelleen myöntävät oikeuksia eri tietojärjestelmiin.

Seuraavassa kirjoituksessa ajattelin pureutua tarkemmin siihen, miten roolitiedon mallinnus sitten oikeastaan pitää sisällään. Jatketaan harjoituksia pian!

Olemme uudistuneet sekä sisäisesti että ulkoisesti:

1.6.2010 alkaen olemme entistä monipuolisempi tietoturvatalo.

Uudistuksemme liittyy 1.6.2010 voimaan tulleeseen yrityskauppaan, jonka seurauksena tietoturvatalo Optisec Oy siirtyi osaksi Trusteq Oy:tä. Yrityskaupan tavoitteena on tarjota entistä parempaa ja monipuolisempaa osaamista nykyisille ja tuleville asiakkaille.

Optisec Oy jatkaa toimintaansa Trusteq Consulting -nimen alla, tarjoten organisaatioille korkeatasoista asiantuntijaosaamista tietoturvaan ja tietoliikenteeseen liittyvissä hankkeissa ja projekteissa: hankejohto, projektijohto, riskienhallinta, -arkkitehtuurisuunnittelu ja konsultointi

Trusteq Solutions on keskittynyt erityisesti pääsyn- ja käyttäjätiedon hallintaan sekä web-tietoturvaan. Se tarjoaa koulutusta, konsultointi, teknistä tukea sekä valmisohjelmistoja. Palvelutarjontaamme pääset tutustumaan helpoiten Palvelut -osion kautta.

Lisätietoja palveluistamme saat tarvittaessa myös myynnistämme. Ota siis rohkeasti yhteyttä! Asiantuntijamme vastaavat mielellään kaikkiin  sinua askarruttaviin kysymyksiin ja auttavat sopivan ratkaisun löytämisessä.

Ethän unohda Blogiamme. Viimeisimmät uutiset ja arviot tietoturva-alan ratkaisuista, tuotteista, palveluista ja tapahtumista päivitetään juuri sinne.