Rekisteriseloste avainasemassa

Tyypillinen asiakastiedon käytön kehittämisprojekti alkaa kanta-asiakasohjelmien, asiakaspalvelun ja verkkosivujen kautta kerätyn tiedon kartoittamisella. Kerättyjen tietojen yksityiskohdat, käyttötarkoitukset, luovuttaminen ja suojauksen pääperiaatteet tulee dokumentoida rekisteriselosteessa.

Seuraavassa vaiheessa määritetään ja kuvataan nykyiset ja mahdolliset tulevat käyttötapaukset. Rekisteriseloste on avainasemassa asiakasviestinnässä, ja se tulee pitää ajan tasalla. Siitä voidaan kuitenkin rajata pois esimerkiksi oleellisia tiedonkäyttötapauksia, koska asiakastietoja saa käyttää vain rekisteriselosteen mukaisesti.

Kontrolli tiedon luottamuksellisuuden mukaan

Kun asiakastiedot ja niiden käyttö on inventoitu, voidaan aloittaa tietojen suojauksen suunnittelu. Henkilötietolain mukaan asiakastiedot tulee suojata tarvittavilla toimenpiteillä asiattoman pääsyn estämiseksi ja mm. luvatonta luovuttamista vastaan.

Tarvittavien toimenpiteiden määrittely on usein vaikeaa, mutta suojauksen toteuttamiseksi on olemassa useita hyviksi todettuja ratkaisuja. Toimiva identiteetin ja pääsynhallinnan ratkaisu (IAM) on avainasemassa suojauksen suunnittelussa, koska pääsyä asiakastietoon tulee rajoittaa monella eri tasolla (need-to-know -periaate) ja esimerkiksi tiedon käyttöä pitää pystyä seuraamaan ja auditoimaan jälkeenpäin. Pelkkä IAM-järjestelmä ei ole kuitenkaan riittävä väline tarpeellisten toimenpiteiden toteuttamiseksi, vaan erilaisia todennus-, suojaus- ja muita ratkaisuja tulee ottaa käyttöön tiedon määrän mukaan.

         ”Perussääntö on, että mitä enemmän ja mitä luottamuksellisempaa tietoa käsitellään, sitä enemmän kontrolleja tarpeellinen suojaus vaatii.”

Suurissa asiakastietokannoissa kehittyneet ratkaisut, kuten data loss prevention (DLP) ja audit trail, edellyttävät konfiguraation ja haavoittuvuuden seurantaa. Näiden ratkaisujen käyttöönotossa tulee ottaa huomioon organisaation vaatimukset ja muut ympäristöön vaikuttavat tekijät. Tärkeää on kuitenkin määrittää nykyiset kontrollit ja suunnitelma niiden kehittämiseksi.

Viimeisenä vaiheena on vaatimustenmukaisuuden ja kontrollien mittaaminen, joka mahdollistaa myös suojauksen jatkuvan kehittämisen. Erilaiset GRC-tuotteet (governance, risk & compliance) ovat erittäin arvokkaita tässä vaiheessa, koska ne tarjoavat reaaliaikaisen näkymän kontrolleihin ja eliminoivat manuaalisia vaiheita, kuten esimerkiksi itsearviointilomakkeiden ja tarkistuslistojen käsittelyn.

Asiakastiedot ovat yrityksellesi erittäin tärkeää ja arvokasta pääomaa. Pidä siis huolta niiden asianmukaisesta suojaamisesta ja käytön tehokkaasta suunnittelusta.

—–

Tomi Mikkonen toimii Trusteqissa hankejohtajana, jonka vastuualueita ovat erityisesti verkkoturvallisuus, kuluttajatietojen suojaaminen, turvallinen tuote- ja järjestelmäkehitys sekä palvelukehitys.

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.

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ää.

Vaikka esitetty vertaus ei pitäisikään sataprosenttisesti paikkaansa, kaikki jotka ovat olleet mukana käynnistämässä ja muotoilemassa keskivertoa suurempia IT-hankkeita voivat varmasti allekirjoittaa havainnon siitä, että organisaation rakenteen ja organisaatiossa työskentelevien ihmisten välisen dynamiikan ymmärtäminen on yksi hankkeen tärkeimpiä menestystekijöitä. Ihmisiä ei vaan voi sokeasti laittaa lokeroihin ja toivoa, että homma toimii. Muita tällaisia menestystekijöitä ovat luonnollisesti budjetin, kalenteriajan ja työn oikean rajauksen realistinen suhde ja johdon sitoutuminen hankkeeseen. Kirjoitetun tiedon määrä siitä, miten näiden ja muiden vastaavien muuttujien paineessa synnytetään hanke, joka onnistuu, on valtava.

En millään muotoa väheksy kirjatietoa ja jokaisella pitää olla perusymmärrys koulutuksen kautta työhönsä, mutta väitän, että meissä kaikissa on sisäänrakennettuna muutamia ominaisuuksia, joita emme saisi koulutuksemme ja kokemuksemme myötä unohtaa. Kun opiskelemme joko työn tai koulutuksen kautta jotain asiaa, vaikkapa projektin suunnittelua, käy usein niin, että näitä viimeisimpänä opittuja asioita aletaan preferoimaan toimintamalleina vain siksi, että ne ovat uusimpina ja tuoreimpina aivoissamme.

Kykyjä, joita olemme monesti saaneet jo lapsena hiekkalaatikolla usein väheksytään, sillä niitä ei voi kirjoittaa kovin eksaktisti CV:hen ja toisaalta monet C-luokan julkkikset ovat tehokkaasti mustamaalanneet näitä ominaisuuksia. Esimerkiksi eduskuntaan pyritään pitkästyttävän usein peruskoulun jälkeen (pahimmassa tapauksessa reality-tv:ssä) hankitulla “tunneälyllä, positiivisuudella ja ihmisläheisyydellä”.

Hienoimmat menestystarinat mitä olen asiakasorganisaatioissa nähnyt, on rakennettu yhdistämällä määrätietoisesti oikeaan tiimiin, oikeissa ihmisissä ja oikeassa suhteessa rooliin nähden, sekä näitä pehmeitä kykyjä, että toisaalta kovan luokan substanssiosaamista. Niinikään poikkeuksetta ison hankkeen osatavoitteiden saavuttamiseen ei riitä vain kommunikaation tai esimerkiksi tekniikan painottaminen.

Kirjapinon korkeus on oire tästä. Ihmismielen ja motivaation monimutkaisuutta yritetään sovittaa johonkin tiedetyillä muuttujilla ennustettavasti käyttäytyvään kehykseen, joka voidaan yksinkertaistaa lukijalle niin, että lukija kokee oppineensa jotain. Toisaalta taas koulutusinvestointi ei kanna oikeasti hedelmää sen jälkeen kun kirja on luettu tai kurssi käyty, vaan hyöty syntyy vasta siinä vaiheessa kun opittua päästään rauhassa soveltamaan oikeassa hankkeessa, ja tällä aikavälillä tieto jäsentyy ja osittain unohtuu ihmisen päässä. Tämä vaikuttaa siihen mitä valintoja jokapäiväisessä työssä preferoidaan.

Kaikki IAM-alueen ohjelmistotuotteet esimerkiksi toimivat aina jonkin kehysajatuksen mukaan. Jos tuotetta käytetään tätä ajatusta vastaan, tästä seuraa perustavaa laatua olevaa tehottomuutta. Tuotteet itsessään pyritään kouluttamaan niin, että niiden käyttäjät seuraisivat työssään tuotteen ajattelumallia. Tätä kuitenkaan harvoin sanotaan koulutuksessa ääneen, ja tämä johtaa siihen, että koulutetut asiantuntijat soveltavat tietämättään tuotteen toimintamallia IAM-hankkessaan ja levittävät sitä ympärilleen ainoana totuutena. Tämä malli on harvoin, jos koskaan, yksi yhteen sen kanssa, miten IAM-hankkeen ympärillä toimiva organisaatio toimii ja tuottaa tietoa. Jonkun täytyy siis muuttua, jotta tehottomuudelta vältytään ja homma saadaan pakettiin.

Organisaation toimintamallia pystytään muuttamaan, kunhan tämä muutos ymmärretään ja sitä osataan johtaa. Ymmärrys yksittäisen organisaation toiminnasta on puolestaan tyypillisesti jotain sellaista mitä opitaan etupäässä hiekkalaatikolla hankituilla pehmeillä kyvyillä ja pitämällä silmät ja korvat auki. On harvoin niin, että se henkilö, joka tuntee IAM-tuotteen ja sen ajattelumallin, on se henkilö joka on kovin kiinnostunut johtamaan organisaatiomuutosta (muuten kuin ehkä teknisestä näkökulmasta). Tämä varsin triviaali havainto selittää hyvin usein sen miksi IAM-hankkeissa monesti aletaan joko kustomoimaan identiteetinhallintatuotetta vastaamaan organisaatiota tavalla joka luo tehottomuutta tai vaihtoehtoisesti ei vaan yksinkertaisesti päästä mihinkään.

IAM-hanke on organisaation toiminnan muutos, etenkin jos identiteetinhallinta ja pääsynvalvonta ei ole ollut aikaisemmin kovin kypsällä tasolla. Tällä blogikirjoituksella haluaisin vaan muistuttaa, että sitä pitää johtaa sellaisena.

Tapahtuma järjestettiin osana valtakunnallista tietoturvaviikkoa jonka takana on mm. viestintävirasto Ficora. Siinä missä tietoturvaviikko keskittyy enemmänkin kansalaisten ja pk-yritysten ohjeistamiseen turvallisesta netin käytöstä, pureutui Tietoturvatapahtuma yritysten ja organisaatioiden tietoturvastrategioihin.
Ja niistähän riitti puhuttavaa. Kun lasketaan yhteen kaikki 28 ohjelmapuheenvuoroa, vieraiden ja asiantuntijoiden väliset henkilökohtaiset tapaamiset sekä keskustelut tietoturvaständeillä, vaihdettiin tietoturvasta ajatuksia päivän aikana valtava määrä. Haasteena onkin saada nuo ajatukset käytäntöön.

Amazon Kindle –lukulaite, jota aiemmassa blogikirjoituksessamme ”mainostimme” osoittautui tapahtuman, tai ainakin Trusteqin ständin, vetonaulaksi. Samoin Federoijan pikaopas, jota jaoimme tapahtumavieraille. Federointi on aiheena ajankohtainen monessa organisaatiossa, ja tämä näkyi suoraan myös oppaan menekissä.
Jatkoa oppaalle seuraa myöhemmin keväällä, IAM-kirjan muodossa, joten jos aihe kiinnostaa, kannatta pitää silmät auki. Tulevassa opuksessa on tarkoitus syventyä identiteetin ja pääsynhallinnan maailmaan niin teknisestä kuin business –näkökulmasta. Kirja tulee tilattavaksi nettisivuillemme, ja ilmoittelemme siitä tarkemmin blogissamme.

Tutustu Lead Architectimme Juha Kervisen pitämään puheenvuoroon tästä.

Kuten arvata saattoi tilaisuus keskittyi hyvin pitkälle laitteistoihin ja tallennusratkaisuihin, sekä mitä etuja tämä yhteenliittymä tuo. Lisäksi Java:n tulevaisuutta käsiteltiin laajasti ja mitään suuria muutoksia tälle alueelle ei ollut tulossa. Oracle yhdistää omaa ja yrityshankintojen mukana tullutta tekniikkaa, jolloin tuloksena pitäisi olla jotain entistä parempaa ja tehokkaampaa. Myös MySQL tulee jatkamaan olemassa oloaan suurin piirtein kuten tähänkin asti. Myöskään Weppiserverien ja aplikaatioserverien osalta ei tullut yllätyksiä. Kaikki jatkuu kuten tähänkin asti.

IAM sai tilaisuudessa jopa odotettua enemmän huomiota. Osaltaan siksi, että Oracle korosti olevansa talo joka pystyy tarjoamaan kokonaisvaltaisia ratkaisuja ja tietoturva oli yksi tärkeistä osa-alueista kaikilla eri kerroksilla alkeaen käyttöjärjestelmistä loppukäyttäjän sovelluksiin. IAM-tuotteiden osalta tulevaisuuden näkymiä avattiin myös, toki tietyiltä osin jäi avoimia kysymyksiä joihin varmasti myöhemmin tulee lisää vastauksia. Sanoma pääasia toki oli, että SUN:n tuotteiden tukea jatketaan aikasempien suunnitelmien mukaisesti, mutta toki pitkällä tähtäimellä muutoksia on tulossa.

Hakemistojen osalta tilanne oli suoraviivainen. SUN:n ja Oraclen LDAP hakemistot jatkavat rinnakain eloaan. SUN Directory Server hakemistoja kehitetään eteenpäin ja ne tarkoitetaan kevyempiin ratkaisuihin kun Oracle Internet Directory hakemisto pysyy vaativan raskaan sarjan ratkaisuna. Hakemistojen osalta tilanteeseen ei siis tule merkittäviä muutoksia.

Oracle Identity Manager tulee olemaan pääasiallinen IdM tuote tulevaisuudessa. SUN:n tuotteesta otetaan kaikki hyvä ja liitetään Oraclen tuotteeseen. Esimerkkinä tällaisista mainittiin mm. SPML-adapterit/connectorit. Role Management puolella Oraclella on kokonaan oma tuote, mutta SUN:n roolien hallinta on ollut liitettynä Identity Manageriin. Roolien hallinnassa Oracle tulee ottamaan ison osan työvälinesitä ilmeisesti SUN:n tuotteiden puolelta. Mm. roolien analysointiin liittyviä sovellus osuuksia, mutta ilmeisesti merkittäviltä osin koko Oraclen roolien hallintaan tulee SUN:n tuotteiden puolelta.

Access Management puolella Oraclen Access Manager tulee olemaan jatkossakin käytettävä tuote. OpenSSO asema jätettiin hiukan auki, mutta mitä ilmeisimmin sen kehittäminen tulee entistä vahvemmin siirtyhmään Open Source yhteisön harteille. Yhteisö tulee kuitenkin saamaan jonkinlaista tukea Oraclen puolelta, mutta tuen laatu lienee lähinnä taloudellista. Itse tuotetta ei Oraclen toimesta ilmeisestikään kehitetä.

Suurilta osin suunnitelmat esiteltiin hyvin korkealla tasolla ja yksityiskohdat tarkentunevat lähitulevaisuudessa. Yleisestiottaen IAM alueella mitä ilmeisimmin Oraclen omat tuotteet kuitenkin korvaavat suurimmalta osin SUN:n omat tuotteet, siten että kaikki hyödylliset toiminnot irroitetaan ja lisätään Oraclen tuotteisiin. SUN:n tuotteita tuetaan suunnitelmien mukaisesti niiden tuen loppuun asti, mutta monilta osin niiden jatkokehitys pysähtynee ja painopiste siirtyy Oraclen vastaaviin tuotteisiin.

Meitä kiinnostaa tietysti ensisijaisesti käyttäjä- ja käyttöoikeuksien hallinnan tuotekategorioiden tulevaisuus, varsinkin kun molemmat Sun ja Oracle tarjoaa jokseenkin päällekkäiset tuotteet Identity Management -teknologiaan. On varsin epätodennäköistä että identiteetinhallinnan tuotteet saavat tässä tilaisuudessa isompaa huomiota – päähuomio on varmasti Sun Sparc, Solaris ja Java -tekniikoiden integroimisessa osaksi Oraclea. Silti voi palautella mieleen lähes vuoden takaista Kuppinger-Colen toimittamaan analyysiä “How could a future Oracle-Sun Identity Management Stack look like?” jossa kuvataan aika kattavasti molempien organisaatioiden tarjonta Identity and Access Management -alueella.

Niin, ja jos tilaisuutta jaksaa seurata pidempään,  noin kello 23.00 aloittaa Oraclen Larry Ellison. Silloin voi tapahtua mitä tahansa kuten esimerkiksi Cloud Computing -aihealueen haastatteluissa kävi. Esimerkit täällä ja täällä.