GDPR – Tietosuoja ja sovelluskehitys osa 1

Pyydän jo etukäteen anteeksi, tämä jos mikään on TL;DR settiä. Asiaa on vain aika vaikeaa kuvata ytimekkäästi, tahoja on monia. Jos artikkelin pituus haittaa lukemista, asennoidu lukemaan vaikka yksi kappale päivässä. Ota mukaan yhtälöön kupillinen mielijuomaasi, ja hyvää musiikkia taustalle, niin kyllä se siitä. Lupaan että substanssi on rautaa, kuittaa kommentteihin jos olet eri mieltä – saa toki kuitata vaikka olisi samaakin 😉

Totean myös, että en ole lakimies, ja tällä hetkellä tietosuoja-asetuksessa on monia alueita joista edes lakimiehet eivät voi sanoa mitään varmaa. Paras viisaus on jälkiviisaus, ja vuonna 2027 osaan kertoa faktaa. Tässä kohtaa kaikki blogautusten pointit edustavat omia näkemyksiä, jotka ovat ilman muuta ainutlaatuisen arvokkaita ja fiksuja. Mutta osa niistä on väistämättä tässä kohtaa ennustellessa väärin, ja tulkinnat tulevat sen aikanaan todistamaan. Toivon kuitenkin että mahdollisimman pieni osa.

Miksi jotain kannattais tehdä?

Tietosuoja-asetuksen siirtymä-ajan päättyessä 2018, sovellukset jotka eivät tue uusia vaatimuksia ja käyttäjän oikeuksia, muodostavat merkittävän liiketoiminnallisen riskin yrityksille. Olemassaolevien sovellusten, järjestelmien, rekisterien ja infran osalta muutos on kivuliaampi. Helpompi on alkaa tutkailemaan ihannetilaa uusien sovellusten osalta, joita vielä vasta suunnitellaan tai rakennetaan, ja tulevaisuuden sovellusten osalta, joita tullaan rakentamaan jatkossa. Ajatuksena on, että aikaa myöten opitaan ottamaan tietosuojavaatimukset huomioon automaattisesti, ja niistä tulee yhtälailla sisäänrakennettu osa kaikkea tekemistä kuin esim. sovelluksen toimivuuden testauksesta eri selaimissa. Ja tätä myöden myös kuluja saadaan alas/opitaan laskemaan ne luonnolliseksi osaksi tekemistä ja testaamista.

Ok, tylsä johdanto. Terästetäänpä tätä toisin. Kun Harri H Hakkeri eräänä päivänä penetroi systeemin ytimeen, haluamme rajoittaa riskiä siitä miten paljon sakkoja tulee maksettavaksi, ja kuinka laajaa osaa asiakasrekisteriä joudut kontaktoimaan tietosuojamurron osalta, sekä millä sävyllä iltapäivälehdet repostelevat asiaa.

On väärinkäsitys ajatella myös, että tämä koskee vain suuria organisaatioita. Sen verran uskaltaudun ennustamaan tulevaisuutta, että muutamakin keskikokoinen paja tulee ajautumaan konkurssiin jos tietosuojan kanssa ollaan leväperäisiä tai peräti röyhkeitä. Tietämättömyys tai pää puskaan-strutsiefekti ei ole tässä puolustus tai suojautumiskeino, päinvastoin. Se että yrittää vaikkei 100% onnistuisikaan, lasketaan todennäköisesti eduksi ja sakkoja tai sakon uhkaa merkittävästi pienentäväksi tekijäksi.

TL;DR

No, tässä kuitenkin tiivistelmä, mitä tulisi huomioida sovelluskehityksessä vuonna 2017, ja projekti/järjestelmätasolla noin muutenkin. Jos muistan, rupattelen infratason ratkaisuista ja hallinnasta, ja organisaatiotason prosesseista lisää toisella kertaa.

  • Riskilähtöisyys: tunnista, minimoi, dokumentoi
  • Henkilötietojen esiprosessointi: Tunnista, minimoi, dokumentoi
  • Sama juttu 3. osapuolien riippuvuuksien osalta: tunnista, minimoi, dokumentoi
  • Sama juttu henkilötiedon prosessoinnin osalta myös sisäisesti: tunnista, minimoi, dokumentoi
  • Tiedon elinkaari: määrittele,minimoi, toteuta, dokumentoi
  • Varmuuskopiot ja arkistointi, huomioi kaikki edellämainitut
  • Testidata, huomioi kaikki edellämainitut
  • Testiympäristöt, tarkkana myös tämän kautta
  • Verkkoinfra, verkkosegmentointi, minimoidaan vahingot, maksimoidaan jäljet
  • Tietoaineiston suojaus: anonymisointi,pseudonymisointi,salaus
  • Käytön valvonta, monitorointi, hälytykset
  • Kyvykkyys osoittaa tehdyt toimenpiteet, ja prosessien toteutuminen
  • Murtautumistapauksessa: prosessien tuki, forensiikka, hälytykset
  • Tietoturva-ja muut päivitykset
  • CI- ja CD- toimitusputkien suojaus ja tietoturva
  • Huom. Myös availability, saatavuus, on tietosuoja-huolenaihe
  • Henkilön oikeudet uuden tietosuoja-asetuksen alaisuudessa, käytännön toteutus?

 

Oletusarvoinen tietosuoja tähtää aikalailla samaan asiaan kuin itse tietosuoja-asetuskin – riskipohjaiseen lähestymistapaan. Ja se taas tarkoittaa että matalan riskin järjestelmiä voidaan suojata keveämmin kuin korkean riskin järjestelmiä. Eli askel numero 1…

Tunnista henkilötiedot, tunnista riskit

Tietosuoja-asetuksen kannalta riskin näkökulma on vähän eri kuin yrityksen kannalta – mutta riskin kohde on silti sama, henkilötiedot. Aiemmin puhuttiin jo siitä, miten tietoa voidaan tunnistaa, luokitella. Järjestelmissä on paljon tietoa, joka ei ole tietosuoja-asetuksen mielessä kiinnostavaa, mutta on silti ollut – ja tulee olemaan – hyvin tarpeellista suojata, esim. tuotetiedot, strategiat, ennusteet. Se mitä ei tietosuoja-asetus määritä henkilötietoksi, on kuitenkin oman harkinnan mukaan edelleenkin vapaasti suojattavissa ja käytettävissä, miten halutaan. Henkilötiedon suojaamiseen taas löytyy GDPR suunnalta kättä pidempää.

Se, minkä voi rajata pois tietosuojalain tarkoittaman henkilötiedon piiristä, voidaan salata – tai jättää salaamatta – vapaasti miten halutaan.

Tietosuoja-asetuksen välineenä käytetään pitkälti DPIA analyysiä. DPIA, eli Data Protection Impact Analysis, on vaikutusten arvioinnin malli, jolla voidaan analysoida riskikulmaa. Ennestään käytössä on monessa yrityksessä ollut PIA, Privacy Impact Assessment, joka on tähdännyt samalle alueelle, mutta hieman laveammalla pensselillä. Molemmissa on ajatuksena määrämuotoinen ja kattava tarkastelu järjestelmässä kerättävälle tiedolle. Molemmat perustuvat riskien hallinnan ajatukseen. Eli analysoidaan kerättävän tiedon riskien taso, ja sen jälkeen, riskipohjaisesti, sovelletaan sopivia kontrolleja, kunnes riski saadaan laskettua hyväksyttävälle tasolle.

DPIA mallia ei tarvitse soveltaa joka järjestelmään, mutta jonkinmoinen esikarsinta olisi tietysti aina hyvä tehdä. Periaatteessa järjestelmän tavoiteltu tietosuojataso määräytyy aika yksinkertaisesti sen mukaan, mikä on sen sisältämä riskialttein yksittäinen tieto, eli vaikka muu järjestelmä olisi aika tylsä, jos yhdestä taulusta löytyy sairauspoissaolojen syitä, se määrittää aikalailla järeimmän kautta suojaustarpeen.

Tähän väliin on hyvä todeta oma lempiteesini. Sataprosenttista tietoturvaa ei ole. Sataprosenttista tietosuojaakaan ei ole. Jokainen järjestelmä voidaan murtaa, jokaiseen dataan päästä käsiksi, jos tarkastellaan asiaa rajattoman ajan, ja rajattoman budjetin suunnasta. Lisäksi tietojärjestelmät elävät mutatoituvassa maailmassa – järjestelmä joka on tänään 99% turvallinen, kokee muutoksia vuoden aikana, ja voi ensi vuonna ollakin vain 70% turvallinen, koska sen ympäristöön on vuoden aikana tullut uusia komponentteja, avauksia, muutoksia, tai vanhoista komponenteista on löytynyt haavoittuvuuksia. Yksi suurimmista tietoturva-haavoittuvuuksista on security misconfiguration, eli virhe ympäristöjen asetuksissa, ja niitä pujahtaa sisään helposti myös järjestelmiin jotka olivat luotaessa arkkitehtuurisesti kauniita ja täydellisiä. Kun huomioidaan prosessit, ympäristöt, teknologiat, muuttujia on vain niin paljon, ettei kukaan voi väittää hallitsevansa niitä kaikkia, nyt ja aina, ja vaikka istuisit palvelimen päällä haulikko kädessä vahdissa 24 tuntia vuorokaudessa, niin mörkö pujahtaa sisään heti jos herpaannut hetkeksi. Ja ensi vuonna voi olla että istut väärän palvelimen päällä.

Eli, ainoa oikea lähestymistapa on tunnistaa suurin riski, madaltaa sitä sopivin keinoin, ja jatkaa kunnes ollaan hyväksyttävällä riskitasolla. Lisäksi tätä ei voi tehdä kertarysäyksenä, projektina, vaan tietosuojan täytyy olla jatkuva prosessi.

Tai vielä mielummin sisäänrakennettu, läpinäkyvä osa prosesseja, kaikkea tekemistä. Siihen on vielä useimmilla yrityksillä pitkä aika. Valitettavasti monet ottavat lähtölaukauksen tekemiseen vasta ensi kesänä, kun uhat alkavat toden teolla realisoitumaan.

Tietosuoja-asetuksen kannalta erityisriskin muodostavia tietoja, joihin tulee kiinnittää erityistä huomiota, ovat mm.

  • Alaikäisistä rekisteröidyistä kerätyt tiedot (vaikka rekisteröity sittemmin olisi jo täysi-ikäinen)
  • Rotu,uskonto,politiikka,terveydentila,rikosrekisteri eli eiheet jotka monen mielestä eivät ole hyviä ruokapöytäkeskustelun aiheita (mutta omasta mielestäni niitä kiintoisimpia, moukka kun olen!)
  • Biometriset tunnisteet

Eli näitä tietysti suojataan rankimman kautta. Hyvä huomata kuitenkin, että ns kovan ja yksilöivän henkilötiedon ohella, myös identiteettiin liittyvää tietoa koskee moni tietosuoja-vaatimus, esim. henkilön oikeudet. Ja se mikä liittyy identiteettiin voi joissain tapauksissa olla yksilöivää, ’jos yksilöinti voi tapahtua kohtuullisella vaivalla tietoja yhdistelemällä’ – esim. muutama erillinen paikkatieto, tai erityinen tietopaketti harvaan asutulla alueella, jne – eli samalla lailla kuin itse identifioivaa tietoa, voi varautua suojaamaan myös identiteettiin liittyviä tietoja.

Toinen tapa lähestyä riskiä on miettiä ihan terveellä järjellä, miten suuren riskin REKISTERÖIDYLLE muodostaa, jos tämä tieto julkaistaisiin iltapäivälehden etusivulla. On hyvin tärkeää muistaa, että tietosuoja-asetuksen riskianalyysissä riskin näkökulma on aina rekisteröity, ei rekisterinpitäjä. Se näkökulma määrää, miten raskaasti tietoa tulisi suojata ja vartioida.

Toisaalta samoja periaatteita voi myös soveltaa muuhun sensitiiviseen tietoon, vaikka ei henkilötietoa olisikaan. Se ei ole tietosuoja-asetuksen kannalta mielenkiintoista, mutta voi olla liiketoiminnan kannalta hyvinkin mielenkiintoista.

Minimoi ja dokumentoi kerättävä tieto

No niin, nyt tulee se hyvä uutinen. Paras tapa keventää kuluja ja suojauskontrollien tarvetta, on olla keräämättä sitä henkilötietoa alunperinkään. Ennen vanhaan oli tapana keräillä kaikenlaista ihan vain varmuuden vuoksi, ties vaikka sitä jossain raportissa tai analyysissä kaivattaisiin, ja miksikäs ei. Sellainen lähestymistapa ei enää tietosuoja-asetuksen aikana kanna pitkälle.

Nyt kannattaa aloittaa miettimällä, mitä tietoa todella tarvitaan, ja millä oikeudella sitä kerään, varastoin, prosessoin. Tämä osa kannattaa dokumentoida hyvin, ja keskustella niistä harmaista alueista, joista ei olla varmoja. Voi myös miettiä sitä, voiko henkilötietoja eristää esim. omaan erilliseen järjestelmään, palveluun, kantaan, tauluun, jota voidaan suojata järeämmin kuin muita.

Sen ohella että minimoidaan siis ’leveyssuunnassa’ kerättävää tietoa – kyseenalaistamalla jo alun alkaen mitä kenttiä laitetaan, mitä tietoja kysellään – kannattaa myös huomioida aikadimensio, eli minimoida miten pitkään tietoja säilytetään. Minimointi ei tarkoita, että kaikki tieto pitäisi heti pyyhkiä, mutta tiedon elinkaaren suunnittelu on erittäin hyvä käytäntö ottaa mukaan tietomalliin alusta alkaen. Elinkaari voi olla vaikkapa puoli vuotta, tai viisi vuotta, kymmenen vuotta, jne. Mutta kun se ymmärretään, dokumentoidaan, ja toteutetaan, on taas pienennetty merkittävästi hyökkäyspinta-alaa.

Jos tapahtuu se pahin, eli huomataan tietomurto tai väärinkäytös järjestelmän ytimessä, muualle arkistoitu ja erikseen suojattu, tai täysin poistettu tieto voi olla sellaista, jota tietomurron ei katsota koskevan, ja näin ollen joudutaan kontaktoimaan vain niitä, joiden tiedot ovat aktiivisessa kannassa. Lisäksi tämäntyyppinen elinkaariajattelu ja suojauskontrollit lasketaan eduksi jos joudutaan jotain sakkorangaistuksia tai muita sanktioita miettimään.

Mutta siis, vanha tapa kerätä kaikki mahdollinen, ja säilyttää sitä ajan tappiin on huono käytäntö, ja sitä ei enää pitäisi harrastaa. Ja jos tiedon pinta-alaa tai säilytysaikaa ei pysty fiksusti minimoimaan, ainakin se kannattaa dokumentoida. Dokumentaatiota tulisi tuottaa sekä järjestelmäkehityksen ja ylläpidon tarpeisiin, että myös rekisteröidyn selosteeseen, jotta läpinäkyvyyden periaate toteutuu. Ja jos rekisteröity pystyy ymmärtämään kerätyn tiedon laajuuden, syyt, ja elinkaaren sen perusteella, pyynnöt esim. poistaa tietojaan järjestelmästä saattavat harventua.

Varaudu kuvaamaan MITÄ kerätään, MIHIN tarkoitukseen, ja MITEN sitä prosessoidaan (aka keiden toimesta). Varaudu tarjoamaan yhtä helpot keinot myöntää lupia tiedon keruuseen ja käyttöön, kuin lupien tarkistamiseen ja poistamiseen.

Minimoi pääsy

Tietosuojassa ei ole kyse vain ulkoisista tietomurroista, yli 30% väärinkäytöksistä tapahtuu verkon sisäpuolella, usein omien työntekijöiden, nykyisten tai entisten, toimesta. Huonosti suunnitellussa (tai monimutkaisessa, suurikokoisessa, iäkkäässä) verkossa voi olla myös pääsyä partnereilla, ulkoisilla työntekijöillä, konsulteilla, vuokratyöntekijöillä, tai miksei myös sovelluskehittäjillä, ylläpitäjillä, järjestelmätoimittajilla, jne.

Motiiveja voi olla esim. uteliaisuus, pyrkimys hyötyä, vandalismi, jne. Tietosuoja-asetus on tältä osin hyvin yksinkertainen. Henkilötietoon ei tulisi olla pääsyä enempää kuin mitä on tarpeen. Se mitä on tarpeen tulisi olla dokumentoituna. Eli ei ole kiellettyä että ylläpitäjillä on pääsy tietoon, kunhan se on läpinäkyvää. Eri asia on millaisen riskin se muodostaa.

Jos jotain tapahtuu, pääsyn minimointi myös voi rajoittaa vahinkoja, tai parantaa mahdollisuuksia näyttää toteen, mitä osaa tietoja tietomurto tai tietosuojaloukkaus koskee.

Näissä on hyvä suunnata huomiota terveydenhuollon järjestelmien suhteen, Suomessa ja muualla. Niissä on jouduttu jo iät ja ajat huomioimaan potilastietojen luottamuksellisuus, ja sieltä löytyy hyvin ideoita, käytäntöjä, toimintatapoja. Eri asia on, onko niitä terveydenhoidon järjestelmissäkään aina toteutettu ideaalisti. Mutta siellä on jouduttu jo pitkät ajat vastaamaan tällaiseen vaatimukseen.

3. osapuolen prosessointi

Tietosuoja-asetus ei estä sitä että dataa voi nyt ja jatkossakin prosessoida myös 3. osapuoli. Itse asiassa, prosessoijaksi kun lasketaan myös esim. pilvipalvelutarjoajat, kuten Amazon AWS, ja Microsoft Azure, enenevässä määrin toimitaan ympäristössä jossa on useampia osapuolia prosessoijina.

Nyt mennään alueelle joka ei ole omaa vahvinta aluetta: Lakipykälät ja niiden tulkinta. Mutta vapaasti oman ymmärryksen mukaan tärkeää on huomioida tämän osalta dokumentointi, ja sen mukana tulee luonnollisesti muut hyveet, kuten tiedon ja pääsyn minimointi ja suojaus, sekä sopimukset. Sopimustekniikka tulee varmaan tässä vielä kehittymään vuoden sisään, esim. Amazon on luvannut että ensi vuoden kesään mennessä tulee olemaan tietosuoja-asetuksen edellyttämät asiat huomioituna palvelusopimuksissa.

Se missä tulee olla tarkkana, on yhteisen vastuualueen kasvu, ja se missä rajat kulkevat. Moderni tietojärjestelmä on kokonaisuus jossa on aika monia tahoja. Jos nyt sattuisi että esim. AWS vastuunjakomallin mukaisesti tietosuojaloukkaus on tapahtunut 3. osapuolen tontilla, esim. medioiden huolimattoman hävityksen, tai fyysisen tietoturvan puutteen vuoksi, kantaako Amazon myös rahallista vastuuta sakoista, ja minkä firman liikevaihdon mukaan se menee? Entä jos 3. osapuoli ei olekaan AWS, joka sinällään on rutinoitunut ja ison talon koneisto, vaan autotallissa majaileva analytiikkafirma?

Mitä ajan takaa tässä, on pari huomiota. Tulkinnat tulevat elämään ja muotoutumaan vielä vuosia, sitä mukaa kun ikäviä asioita tapahtuu. Ja jatkossa ei riittäne pestä käsiään tietoturvasta ja tietoturvasta siinä kohtaa kun data siirtyy 3. osapuolen käsiin. Yhteisvastuullisuus on päivän sana, ja hyvä niin.

 

Jatkuu ensi numerossa…

No niin, kuten varoittelin, tästä tulee pitkä juttu. Kulmia on monia. Kirjailen lisää ajatuksia toisella kertaa, mennen lähemmäs kehittäjän konkretiaa. Osa näistä asioista, kuten 3. osapuolen sopimukset, eivät ole välttämättä heti toimittajan mielestä ehkä asioita joihin voi vaikuttaa, mutta softaprojektissa tulisi asianmukaisen matkaopastelijan kiinnittää huomiota siihen, miten asiat kokonaisuutena tehdään. Jos joku osa-alue on rempallaan, siitä kannattaa keskustella, ja kiinnittää huomiota, vaikka sieltä voisikin löytyä lisäkuluja.

Osittainen tietoturva on hyödytöntä tietoturvaa.

 

GDPR – henkilön (uudet) oikeudet

Uuden tietosuoja-asetuksen alla henkilöllä on terävöitettyjä oikeuksia, kuten oikeus poistaa tietonsa (right of erasure/right to be forgotten), tai siirtää niitä, ja tietysti myös tarkistaa ja korjata niitä. Tässä voi tulla muutama suorastaan ironinen ongelma vastaan – miten voimme varmuudella yksilöidä ja ennenkaikkea tunnistaa kaiken henkilöön liittyvän tiedon?

Screenshot 2017-06-28 10.01.52

Otetaan skenaario, Harri A Tötteström, asiakkaamme, ottaa yhteyttä ja haluaa 25.5.2018 poistaa tietonsa järjestelmästä. Kehen hän ottaa yhteyttä? Miten prosessi etenee? Vai saako tätä itsepalveluna?

Tunnista

Ensimmäinen temppu on tunnistaa Harri varmasti. Miten sen teemme? Jos käytössä on sähköinen id ja tunnistus jo ennestään, homma hoituu sillä. Jos ei, miten tunnistetaan? Asetus erikseen mainitsee, että tunnistamisen vaikeus ei ole syy evätä pyyntö. Tarvittaessa tulee hyväksyä Harrilta riittävä määrä tietoja, että voidaan varmasti tunnistaa. Tullaanko näyttämään passi paikan päälle? Piisaako lista henkilökohtaisista tiedoista identifioimaan? Tätä pitää terävöittää useimmissa yrityksissä.

Mitä jos meillä ei ole rekisterissä varmaa tunnistetta, vaan vain etunimi+sukunimi-pari?

Tarkista

Seuraava askel on tarkistaa, onko pyyntö validi. Jos kyseessä on esim. asiakassuhde, ja tiedot ovat toiminnan jatkamisen kannalta välttämättömiä, ja Harri ei ole päättämässä asiakassuhdettaan, tietojen poistoa ei voitane tehdä, ja tästä tulee tiedottaa Harrille. Muita syitä evätä pyyntö on jos Harri yrittää poistaa jonkun muun tietoja, tai jos lainsäädäntö vaatii tietojen säilyttämistä. Henkilön oikeudet ovat tässä kuitenkin hyvin vahvat, ja erityisen tärkeää on, että vastaus pyyntöön tulee 1kk kuluessa pyynnön esittämisestä. Kuulostaa että siinä olisi paljonkin aikaa, mutta ellei tätä prosessia ole jo jumpattu hyvissä ajoin, ja aletaan vasta pyynnön tultua pähkäilemään, ollaan pulassa.

Suorita

Päästiinkö tänne asti? Rekisteröity on tunnistettu, pyyntö on validi, ja nyt pitäisi toimittaa. Pari uutta haastetta ratkaistavaksi. Voiko henkilötiedot oikeastaan poistaa järjestelmästä ilman että viite-eheydet kärsivät tai ilmenee bugeja? Useimmissa tapauksissa voi olla turvallisempaa suorittaa poisto päällekirjoittamalla, anonymisoimalla tiedot tarpeeksi vahvasti. Tätäkin tulee järjestelmän tukea, esim. jos anonymisoinnissa poistetaan henkilötunnus, puhelinnumero, jne, järjestelmän tulee siitä huolimatta toimia. Tämä ei välttämättä toimi etenkään vanhoissa järjestelmissä ihan oikein. Jos kylmästi poistetaan tietorivejä, tulee ymmärtää miten ne liittyvät toisiinsa, katsoa että poistetaan tarpeeksi, mutta ei liikaa.

Tässä voi herätä ajatus, että ainakin alkuun palvellaan muutamia pyyntöjä käsin, manuaalisilla prosesseilla. Se on ihan validi ajatus, joskin täytyy tarkistaa, että siinäkin toteutuu muut tietosuojan edellyttämät vaateet, esim. minimointi tietoihin pääsyyn, ja kyky näyttää toteen kuka pääsi tietoon, ja mitä tiedolle on tapahtunut. Jos logataan sql:llä suoraan kantaan, tämä voi toteutua, tai sitten olla toteutumatta.

Tähän kohtaan ei ole mitään fiksua viisasten kiveä jaossa. Manuaalisia prosesseja tullaan tarvitsemaan jossain määrin, mutta niiden kanssa täytyy olla tarkkana, tai ne avaavat lisää tietosuojahaavoittuvuuksia tai riskejä, ja ihan liiketoiminnallisiakin riskejä. Itse vihaan manuaalisia prosesseja, ja jonain päivänä automatisoin ne kaikki, se on minun riskiretkeni. Mutta reaalimaailmassa tähän voi parhaiten vaikuttaa uusien ja tulevien tietojärjestelmien osalta. Muille pitää luoda paras mahdollinen ratkaisu nykytilassa, ja tarpeen vaatiessa laittaa parannuksia roadmapille. Yksi idea voi olla esim. datan virtualisointi abstraktiokerrokseen, jossa valvotaan pääsyä ja tekemisiä. Mutta se ei ole yleensä halpaa.

Jutustelen myöhemmin sovelluskehityksen näkökulmasta miten asiaa kannattaa taklata, mutta tärkeintä on että tietomalli sallii poisto- ja siirtopyynnöt, siitä lähtee kaikki.

Anna mun kaikki tiedot, kiitos

Toinen mielenkiintoa herättävä pyyntö on saada kaikki itsestään kerätyt tiedot konekielisessä yleisessä siirtomuodossa. Tämä on uudistus jo aiemmin voimassaolevaan direktiiviin, jossa oli mukana oikeus tarkistaa tietonsa. Nyt puhutaan tietojen siirtämisestä. Se voi tapahtua siten, että rekisteröity lataa tietonsa, esim. csv, xml, json muodossa itsepalvelukäyttöliittymässä, mutta asetus rohkaisee myöskin kehittämään valmiuksia siirtää tietoja suoraan toisille vastaaville palveluntarjoajille, ilman että rekisteröidyn täytyy toimia välissä. Se, millä toimialoilla tässä on järkeä, tietysti vaihtelee.

Mutta Harri T esittää taas siis pyynnön. Anna mun kaikki tiedot, kiitos. Aikaa kuukausi – tai kolme kuukautta jos pyynnön toteuttaminen on erityisen hankalaa syystä tai toisesta. Mitä tapahtuu?

Samat kuin aiemmin. Tunnista vahvasti. Tarkista pyynnön validiteetti. Jos kaikki näyttää hyvältä, on aika miettiä, mitä tietoa laitetaan pakettiin. Asetuksen mukaan pakettiin pitäisi tulla kaikki henkilöstä suoraan kerätyt ja henkilön itse toimittamat tiedot, mutta pakettiin ei kuulu tiedot jotka on näistä johdettu, analysoitu, tai jotka edustavat liiketoiminnallisia salaisuuksia. (No, asetus ei itseasiassa mene näin tarkkoihin lausuntoihin, mutta Working Party 29 tulkinnat tarkentavat). Hyvä huomata myös artiklan 23 asettamat rajoitukset siihen milloin näitä oikeuksia ei voi harjoittaa.

Mielenkiintoinen kohta tulee, jos henkilön tietopaketti sivuaa toisen henkilön tietoja. Jätän kotitehtäväksi selvittää mitä sitten tapahtuu. Vinkkinä voin kertoa, että se ei ole syy evätä pyyntöä saada tietonsa.

Ai niin, ja tämä oli se kohta josta on tarjolla 20 miljoonan sakko tai suurempi, jos homma ei toimi.

Otetaanpa tuosta vielä maistiainen lakipykälää, tietosuoja-asetuksen peruslausunto (recital) 68:

Jotta voitaisiin edelleen vahvistaa rekisteröityjen oikeutta valvoa henkilötietojaan silloin, kun henkilötietojen käsittely suoritetaan automaattisesti, rekisteröidyn olisi myös voitava saada häntä koskevat henkilötiedot, jotka hän on toimittanut rekisterinpitäjälle, jäsennellyssä, yleisesti käytetyssä, koneellisesti luettavassa ja yhteentoimivassa muodossa ja siirtää ne toiselle rekisterinpitäjälle. Rekisterinpitäjiä olisi kannustettava kehittämään yhteentoimivia muotoja, jotka mahdollistavat tietojen siirtämisen. Tätä oikeutta olisi sovellettava silloin, kun rekisteröity on antanut henkilötiedot oman suostumuksensa perusteella tai kun käsittely on tarpeen sopimuksen täytäntöönpanemiseksi. Sitä ei sovelleta silloin, kun käsittely perustuu muuhun lailliseen perusteeseen kuin suostumukseen tai sopimukseen. Tämä oikeus on luonteeltaan sellainen, ettei sitä olisi käytettävä niitä rekisterinpitäjiä vastaan, joiden julkisiin velvollisuuksiin henkilötietojen käsittely kuuluu. Siksi sitä ei pitäisi soveltaa silloin, kun henkilötietojen käsittely on tarpeen rekisterinpitäjää koskevan lakisääteisen velvoitteen noudattamiseksi tai yleisen edun vuoksi toteutettavan tehtävän suorittamiseksi tai julkisen vallan käyttämiseksi. Rekisteröidyn oikeus siirtää tai vastaanottaa häntä koskevia henkilötietoja ei saisi luoda rekisterinpitäjille velvoitetta hyväksyä tai ylläpitää tietojenkäsittelyjärjestelmiä, jotka ovat teknisesti yhteensopivia. Jos tietyssä henkilötietoja sisältävässä tietojoukossa tiedot koskevat useampia kuin yhtä rekisteröityä, oikeus vastaanottaa henkilötietoja ei saisi rajoittaa toisten rekisteröityjen tämän asetuksen mukaisia oikeuksia ja vapauksia. Tämä oikeus ei saisi myöskään rajoittaa rekisteröidyn oikeutta saada henkilötiedot poistetuiksi eikä tämän asetuksen mukaisia rajoituksia kyseiseen oikeuteen, ja se ei etenkään saisi merkitä niiden rekisteröityä koskevien henkilötietojen poistamista, jotka tämä on antanut sopimuksen täytäntöönpanoa varten, siinä määrin ja niin kauan kuin henkilötiedot ovat tarpeen sopimuksen täytäntöönpanoa varten. Kun se on teknisesti mahdollista, rekisteröidyllä pitäisi olla oikeus saada henkilötiedot siirrettyä suoraan rekisterinpitäjältä toiselle.

Muut oikeudet

No niin, nämä oikeudet ovat saaneet eniten huomiota, mutta ei pidä laiminlyödä muitakaan. Aika pitkälle tosiaan päästään jos muistetaan nämä:

  • Tietojen keruun ja käsittelyn tulee olla läpinäkyvää
  • Henkilöllä tulee olla helppo pääsy siihen mitä tietoja hänestä on kerätty, miksi, ja mikä on niiden elinkaari
  • Pitää olla helpot keinot poistaa tietonsa järjestelmistä, kun niiden säilytykselle ei ole enää perustetta, tai ladata ne itselleen tai kolmannelle osapuolelle käyttöön
  • Kaiken tämän tulee tapahtua tietoturvallisesti ja tietosuojaa kunnioittaen
  • Rekisteröidyllä tulee olla mahdollisuus tarkastaa myös luvituksensa, ja peruuttaa niitä yhtä helposti kuin antaa niitä

Nämä johtavat kohden keskitettyä tunnistamista, ja jonkunmoista identiteetin ja lupienhallinnan näkymää/portaalia, jossa on paljon itsepalveluita. Pakko ei ole moiseen ryhtyä, mutta pitkällä juoksulla homma tulee varmasti halvimmaksi, ja tätä kauttahan ne uudet liiketoimintamahdollisuudet avautuvat. Jos lupien antaminen ja peruuttaminen on helppoa, se rohkaisee antamaan niitä pienemmilläkin täkyillä, ja avaamaan henkilötietojensa käyttöä jopa rohkeammin alueille joille ei ole vielä menty.

Automaattinen poisto

Aika paljon rahaa säästää myös, jos alusta alkaen sovelletaan kerättyjen tietojen minimointia hyvänä periaatteena järjestelmäsuunnittelussa. Minimoinnissa on kaksi tärkeää pointtia: Kerätään vain se mitä on tarpeen, ei tarpeetonta. Ja säilytetään sitä tietoa vain sen verran mitä on tarpeen, sen jälkeen arkistoidaan, ja aikanaan automaattisesti poistetaan. Jos nämä prosessit on myös selkeästi kuvattu tiedon keruun yhteydessä, tarvetta erilliselle tietojen poistolla asiakassuhteen päätyttyä on vähemmän. Arkistointivaihe välissä voi olla tarpeen, ja se voi olla esim. kuudesta kuukaudesta vuosiin, riippuen vähän siitä, millaisia tarpeita kerätylle tiedolle on jälkeenpäin.

Tämä edellyttää kuitenkin prosessijumppaa, ja se on organisaatioille aina paljon kivuliaampi ja hitaampi ratkaisu kuin joku järjestelmähankinta tai koulutus.

Ensi kerralla lisää tiedon suojaamisen keinoista, ja sovelluskehitys/hankintanäkökulmista.

GDPR – Tiedon tunnistaminen ja luokittelu

Kirjailin taannoin blogautuksen yleisesti GDPR tietosuoja-asetusta koskien. Nyt on aika pureutua tarkemmin muutamaan osa-alueeseen. Otetaanpa ensin taklaukseen tiedon dokumentointi, henkilötiedon tunnistaminen, löytäminen, ja luokittelu. Kaikki kiteytyy kysymykseen: Mikä on henkilötietoa?

Perinteisesti organisaatioissa on totuttu suojaamaan sensitiivistä tietoa tarvittavassa määrin, esim. luokittelemalla tiedot neliportaisella mallilla, esim. public, internal, sensitive, confidential/restricted/critical. Tämän ohella on suojattu raskaamman kautta esim. maksutiedot, tilitiedot, luottokorttitiedot, jotka vääriin käsiin joutuessaan voivat aiheuttaa taloudellista vahinkoa ja maineenmenetystä raskaimman kautta (Esim. Sony). Myös terveydenhoito-alalla on totuttu suojaamaan ja valvomaan pääsyä rekisteröityjen terveystietoihin.

Tietosuoja-asetuksessa suojauksen tarve laajenee. Asetuksessa mainitaan henkilötiedon määritelmäksi seuraavaa (artikla 4):

Tässä asetuksessa tarkoitetaan 'henkilötiedoilla' kaikkia tunnistettuun tai tunnistettavissa olevaan luonnolliseen henkilöön, jäljempänä 'rekisteröity', liittyviä tietoja; tunnistettavissa olevana pidetään luonnollista henkilöä, joka voidaan suoraan tai epäsuorasti tunnistaa erityisesti tunnistetietojen, kuten nimen, henkilötunnuksen, sijaintitiedon, verkkotunnistetietojen taikka yhden tai useamman hänelle tunnusomaisen fyysisen, fysiologisen, geneettisen, psyykkisen, taloudellisen, kulttuurillisen tai sosiaalisen tekijän perusteella.

Tässä on pari kiintoisaa huomattavaa kohtaa. Henkilötietoa on luonnollisesti kaikki suoran yksilöivä tieto, esim. henkilötunnus, tai sähköpostiosoite. Tämän ohella ilmiselvästi yhdistelmätiedot identifioivat yksilön ja aiheuttavat datan tulemisen tietosuoja-asetuksen piiriin, esim. etunimi, sukunimi ja syntymäaika.

Uutta on viittaus esim. sijaintitiedon yhdistelmiin. Näistä on käyty jo paljon tulkintakeskusteluja, ja tullaan käymään jatkossakin. Tällä hetkellä näkemys on, että muutama sijaintitietopiste, joka voi olla esim. ostos + ostospaikka, yhdistettynä aikaleimaan, voi jo identifioida henkilön. Eritoten jos otos on niin pieni tai tiedot niin uniikkeja että yksilöinti on triviaalia. Tämän ohella on huomioitu biometriset tunnistetiedot, ja analytiikka. Tästä voimme päätellä, että a) henkilötiedon ja ei-henkilötiedon raja on tilannekohtainen, veteen piirretty viiva, ja b) merkittävä osa kantadatasta voidaan todennäköisesti, jossain olosuhteissa, tulkita henkilötiedoksi. On olemassa hyvin harvoin dataa joka ei varmuudella mitenkään yhdistelemällä identifioi yksilöä, tai liity yksilöön. Ja jos se on henkilötietoa, tai siihen liittyvää tietoa, siihen kohdistuu useampikin GDPR tietosuoja-asetuksen vaatimus.

Hyvä huomata myös verkkotunnistetiedot, ja se että järjestelmän sisäisen id:n käyttö, ja viittaus toisaalla sijaitsevaan kantaan ei varsinaisesti vapauta dataa tietosuojavaatimuksista, joskin se voi keventää riskiä jonkun verran (pseudonymisointi).

Miten olemme tähän asti ajatelleet tiedon sensitiivisyydestä ja suojauksesta, menee tavallaan päälaelleen. Ja on aika selvää, että kun aiemmin riitti suojata muutama sarake koko järjestelmästä erityisen hyvin, nyt on aika harva tietokenttä jota ei tietosuoja-asetuksen joku pykälä koske. Pitäisikö kohottaa suojauskontrolleja kaiken datan osalta samalla vaivalla?

Kotitehtävä: Jos olisi olemassa kuvitteellinen (huonosti suunniteltu) tietokantataulu/excel dumppi, jossa olisi seuraavia kenttiä, mitä niistä pitäisi poistaa, että se olisi varmuudella täysin vapautettu tietosuoja-asetuksen vaatimuksista ja vapaasti liikuteltavissa ja käytettävissä?

  • Id
  • FirstName
  • LastName
  • SocialSecurityCode
  • Birthday
  • PhoneNumber
  • StreetAddress
  • State
  • City
  • Country
  • ZipCode
  • WorkAddress
  • ProductId
  • Price
  • PurchaseDate
  • VisitCount
  • Comment

Yksi haaste on nuo vapaamuotoiset kommentti/kuvauskentät, mikään ei estä arkikäytössä kirjoittamasta niihin jotain henkilötietosisältöä, esim. emailit. Haasteena voi olla, miten löytää kaikki kentät joissa oikeasti on henkilötietoa, versus kentät joissa on suunniteltu olevan henkilötietoa alunperin?

Hyvä huomata että yksilöivän tiedon ohella identiteettiin liittyvät tiedot lasketaan myös suojattavaksi henkilötiedoksi, ja ne nousevat erityisen tärkeiksi esim. tietojen siirron kannalta. Jos rekisteröity tekee validin pyynnön siirtää tietojaan sähköisesti, mitä tietoa pakataan mukaan?

Tiedon luokittelusta

Itse tietosuoja-asetus ei totea tiedon luokittelusta paljoakaan, mutta sieltä löytyy kategoria erityisen arkaluonteiset tiedot. Kategoriaan kuuluu mm:

  • Ala-ikäisiä koskevat henkilötiedot
  • Uskontoa koskevat tiedot
  • Seksuaalista suuntautumista koskevat tiedot
  • Rikoshistoriaa koskevat tiedot
  • Terveydentilaa koskevat tiedot
  • Rotua tai etnistä alkuperää koskevat tiedot
  • Poliittiset mielipiteet, uskonnollinen vakaumus
  • Geneettiset tiedot, biometriikkatiedot

Näitä tulee siis suojata järeämmin kuin ns perustietoja. Tästä saamme kaksi kategoriaa henkilötietojen luokitteluun. Kolmas on luonnollisesti tieto joka ei ole henkilötietoa tietosuoja-asetuksen mielessä. Sitä ei koske mitkään säädökset mistä näissä pakinoissa olen keskustellut, joten sitä voi käyttää ja liikutella vapaasti. Toki hyvä huomata, että tietosuoja-asetuksen kannalta esim. tulevien tuotteiden suunnitelmat eivät ole kiinnostavaa tai suojattavaa tietoa, koska eivät liity henkilöön, mutta yrityssalaisuuksien kannalta voivat olla hyvinkin olennaisia suojata hyvin.

Screenshot 2017-06-29 12.15.51

Tästä saamme siis kolmiportaisen luokittelukategorian: avoin, suojattava, ja arkaluonteinen. Ja liikennevalovärein ilmaistuna: vihreä, keltainen, punainen. Jos ei ole vihreää, on erityisen tärkeää miettiä mitä varmuuskopioita siitä otetaan ja miten niitä säilytetään, miten siitä otetaan ylipäätään kopioita, jne. Huomaa kuitenkin että tässä punainen ei tarkoita STOP! vaan tarkoittaa: Ole erityisen varovainen. 🙂

Tarvitaanko lisää luokittelukategorioita? Mielestäni ei ole perusteita sille. Yksinkertainen on kaunista, tässäkin. On jo muutenkin epäselvää, mitä tarkoittaa järeämpi suojaus arkaluonteisille tiedoille, ja mikä on sopiva taso suojata gdpr asetuksen ulkopuolisia tietoja. Jos tarpeen, tähän voi keksiä väliportaita, tai määritellä uuden kategorian ’public’, julkisesti saatavilla olevat. Aalto yliopistolla on tästä jo näkemyksiä – linkki tämän artikkelin lopussa.

Hyvä huomata myös että luokitteluissa on yleensä ideana tarkistaa voiko jotain muualla käytettyä käyttää, tai tehdä oma. Monessakin liiketoiminnassa on erityispiirteitä jotka voivat tuoda lisäportaita ja näkökulmia mukaan.

Miten näitä voi dokumentoida?

Koska Solitalla tehdään aika hemmetin fiksua analytiikkaa ja koneoppimista, unelmoin ohjelmistosta jolle voi osoittaa kannan, ja joka louhii sen läpi ja tuottaa hienon liikennevaloraportin siitä mitä luokituksia tauluista löytyy. Tämäntapaista voi jo nyt tehdä osalla virtualisointiratkaisuista, ja data warehouse alustoista, mutta ratkaisut pakkaavat olemaan aika järeitä järjestelmähankintoja. Omaan sen verran ennustajan lahjoja että tälle alueelle tulee varmaan jotain nopeampaa täsmälääkitystä lähitulevaisuudessa. Mutta vielä ei ole omissa hyppysissä sellaista. Sellainen olisi hurjan kätevä etenkin olemassaolevien järjestelmien dokumentoinnissa, ja dokumentaation ylläpidossa.

No, joka tapauksessa, tietoa on paljon ja dokumentaatio tarvitaan saraketasolla, joten näppärä tapa ainakin tuottaa dokumentaatio voi olla ihan perinteinen excel muoto, jossa käydään läpi kannan sarakkeet yksi kerrallaan, kerrotaan niiden tyyppi ja säännöt, käyttötarkoitus, ja tietosuojaluokitus. Sitten voidaan luoda laajempi silmäys kokonaisuuksiin, katsoa löytyykö taulujen tai kantojen klustereita jotka voidaan kokonaisuutena luokitella tiettyyn ryhmään, jne. Järjestelmän tietosuojaluokitus määräytyy, noin karkeasti ajatellen, korkeimman tietosuojaluokituksen mukaan joka sarakkeista löytyy.

UML on myös nastaa, monet rakastavat UML:ää. Normaalit tietomallien ja arkkitehtuurien dokumentointitavat käyvät hienosti pohjaksi myös tietosuojatiedon luokitukselle, ja jo nyt monet kaavioiden tuottoon sopivat välineet ja alustat alkavat tarjoamaan tukea tälle ulottuvuudelle.

Jos käytössä on jo kantatyökalu, joka osaa tuottaa fyysisen tason näkymiä hyvin, ja sitä jo käytetään, kenties siitä saa hyvää nostetta tähän?

Näissä kaavioissa ja dokumentaatioissa on peevelisti työtä, mutta voisi ajatella että jatkossa tietosuoja yksinkertaisesti huomioidaan osana uusien tuotettavien sovellusten dokumentaatiota.

Luokittelun ja tiedon ohella tosiaan on syytä tuottaa ainakin kaksi muuta dokumenttia. Aina parempi jos näitä voidaan pitää dynaamisesti yllä jossain muualla kuin pölyttymässä levynnurkalla jossain – sillä dokumentaatio jota ei ylläpidetä on vaarallisempaa kuin dokumentaatio jota ei ole.

Ensimmäinen on tietovirtakuvaus, eli mitä tietoa liikkuu, mihin suuntaan, missä kohden ylitetään järjestelmärajat, organisaatiorajat, tai maiden rajat, tai EU rajat. Nyrkkisääntö on, että monissa rajanylityksissä tarvitaan sopimuksia, ja

Toinen on kuvaus siitä mitä tietoa rekisterissä/järjestelmässä säilytetään, mihin tarkoitukseen sitä kerätään, ja millä oikeutuksella sitä kerätään ja prosessoidaan. Oikeutus voi olla esim. sopimus, lain vaatimus, tai lupa rekisteröidyltä. Tämä on aika olennainen avainkohta tietosuoja-asetuksen toteennäyttämisen mielessä, ja myös tyypillisesti se kohta, josta organisaatioiden kannattaa aloittaa tietosuojajumppa. Kartoitetaan rekisterit, leimataan ne sen mukaan millaista henkilötietoa ne sisältävät, ja selvitetään käsittelyn oikeutukset ja sopimukset.

Ideaalitapauksessa nämä kaikki olisivat dynaamista, elävää dokumentaatiota, jota olisi rekisterin omistajien helppo päivittää, josta saisi generoitua tarvittavat raportit, ja jotka linkittyisivät muodostaen helposti navigoitavan mallin. En ala nyt mainostushommiin mutta kuten sanottua, tässä on kasvavaa tarjontaa. Täytyy toki olla tarkkana ettei osta ongelman ratkaisuun alustaa, järjestelmää tai ratkaisua joka ratkookin ihan muita ongelmia ja tarjoaa vain sivutuotteena apua tähän kulmaan 😉

Loppusanat ja linkit

No niin, siinä taas tämänkertaiset mietelmät. Aiheita piisaa lisää, ja jos aikaa löytyy, palaan vielä esim. dokumentoinnin, sovelluskehityksen, testidatan tiimoilta keräilemään ajatuksiani. Tässä taas linkkivinkkejä:

https://www.vahtiohje.fi/c/document_library/get_file?uuid=ddb05959-40d1-435f-af23-fd20fc21d63f&groupId=10229

http://www.tietosuoja.fi/fi/

 

GDPR – tieto suojatuksi

No niin, pitkästä aikaa. Aika murtaa myyttejä, parantaa moraalia, ja avata uusia mahdollisuuksia.

Ensi vuonna loppuu siirtymäaika EU tietosuoja-asetuksen (EU) 2016/679 osalta. Asetushan on jo voimassa, mutta 25.5.2018 loppuu siirtymäaika, ja siitä alkaen henkilötietojen käsittelyn on oltava asetuksen mukaista, tai muuten…

Mielenkiintoista kyllä liikkeellä on taas monenlaista vipellystä tämän tiimoilta. Tuntuu löytyvän kosolti ääripään reaktioita: Joko taivas putoaa niskaan ja mitään ei saa tehdä, tai sitten ei koske meitä, pää puskaan ja eteenpäin kuin ennenkin.

 

Screenshot 2017-06-28 10.01.52

Olen itsekin viettänyt aikaa kosolti asian parissa ja ajattelin kirjoitella vähän mietintöjä. Oma lähestymistapa on ehkä vähän erilainen: Mitä kannattaa jatkossa huomioida että ollaan sovellus- ja ratkaisukehityksessä yhteensopivia asetuksen hengen kanssa, ja mitä mahdollisuuksia se jatkossa luo.

20 miljoonaa tai 4% vuotuisesta maailmanlaajuisesta liikevaihdosta

Merkittävimpiä uutisaiheita asetuksen suhteen on ensimmäistä kertaa tiukennettu sakkoja, toisin sanoen määritetty uhkasakko joka voidaan asettaa jos tietosuoja-asetuksen vaatimuksia ei ole toteutettu. Sakon yläraja on törkeimmissä rikkomuksissa 20 miljoonaa euroa, tai 4% vuotuisesta maailmanlaajuisesta liikevaihdosta, kumpi onkaan suurempi. Aika monellakin isommalla firmalla, jopa Suomessa tuo 4% voi helposti olla 20 miljoonaa suurempi, moninkertaisestikin, ja vähän pienemmille pajoille 20 miljoonan sakko voi olla aika kova pala.

Tätä vipua on helppo viuhutella pelotteena, ja sillä on puolensakin. Sekä tietosuoja että tietoturva vaativat investointeja järjestelmiin, infraan, palveluihin, ja edellyttävät tarkempaa seurantaa sille missä tieto liikkuu ja miten sitä käsitellään – todennäköisesti huomiointia prosessi ja liiketoiminta-tasolla. Monet sovelluskehitysprojektit ovat sellaisia, että siellä keskitytään vain toimintoihin ja ominaisuuksiin, ja tietoturva tulee siellä jossain perässä, jos tulee. Usein tietoturvaan investoidaan vasta kun jotain tapahtuu – ja se on huonoin mahdollisin hetki investoida. Tämän asetuksen myötä alkaa löytymään rahaa parantaa tietoturvaa ja tietosuojaa, ja se taas laskee riskejä mahdollisen tietomurron tai tietosuojaloukkauksen tapahtuessa.

Niille jotka ajattelivat painaa päänsä puskaan ja jatkaa kuten ennenkin, lienee hyvä huomioida että tuo uhkasakko siis pamahtaa kohdalle esim. sillä hetkellä kun järjestelmiin tapahtuu tietomurto, ja sana siitä kiirii tietosuojaviranomaisille. Sakko voi myös uhata jos tulee jostain syystä muu epäilys siitä että tietoja ei käsitellä asetuksen mukaisesti. Ensimmäinen asia mitä siellä kysytään on miten sensitiivistä ja laajaa tietoa murto koskee, miten laajaa joukkoa, ja mitä toimenpiteitä on tehty tiedon suojaamiseksi suhteessa riskeihin. Sakko tirahtaa rankimman kautta, jos vastaus tähän on: HÄ?

No, niille jotka ajattelivat kieltää kaiken ja vetää paniikkimoodin päälle, sen verran lohtua että sakkoa säädetään sen mukaan mitä toimenpiteitä on tehty tiedon dokumentoimiseksi ja suojaamiseksi, ja miten nopeasti on pystytty reagoimaan, ja miten yhteistyöhaluisia on oltu. Ensi vuonna näemme miten tuota käytännössä tulkitaan viranomaisten toimesta – olisin kuitenkin aika isosti yllättynyt ellei jo ensi vuoden puolella tulisi ainakin muutama tapaus tarkasteluun.

On myös äärimmäisen todennäköistä, että asetuksen siirtymä-ajan päättyessä tulee jonkunmoinen purske ihmisiä harjoittamaan oikeuksiaan, ainakin mielenkiintoisimmissa rekistereissä. Miten pystyt tällä hetkellä vastaamaan esim. pyyntöön tulla unohdetuksi? Tai pyyntöön saada kaikki kerätyt tiedot itsestään konekielisessä siirtomuodossa?

Riskeistä puheenollen

Uusi tietosuoja-asetus puhuu useassakin kohtaa riskeistä, ja riskilähtöisestä lähestymistavasta. Tämä on hyvä pitää mielessä kun tulkitsee asetuksen vaatimuksia suhteessa omiin rekistereihinsä tai järjestelmiin. Ideana ei ole, että kaikki henkilöön liittyvä tieto pitäisi nyt varastoida raskaimmin mahdollisin kontrollein suojattuna holvien uumeniin, tai olla käyttämättä sitä tai tekemättä mitään. Ideana on analysoida millaisen riskin ko henkilötieto muodostaa, mitä uhkia sen varastointiin ja käyttöön voi liittyä, ja valita sopivat kontrollit jotta riski vähenee. Toisin sanoen, on tunnistettavissa selkeästi eri sensitiivisyydellä olevia tietoja joita tulee suojata eri tasoilla.

Tässä kohtaa kukaan ei pysty varmasti sanomaan missä rajat menevät – valitettavasti tietosuoja-asetus ei tätä kerro, ja opimme asiaa vasta tulkintojen kautta. Mutta tietosuoja-asetus määrittelee erikseen sensitiivistä tietoa, esim. alaikäisten tiedot, tiedot joissa käsitellään esim. terveystietoja, sukupuolista suuntautumista, rotua, uskontoa, rikoshistoriaa, jne ovat selkeästi sensitiivisiä. Sen ohella voi tietysti käyttää tervettä järkeä: Jos Harri H Hakkeri murtautuu juuri tähän kantaan, lataa sieltä dumpin tietoa, ja se julkaistaan Internetissä tai iltapäivälehdissä, miten suuri vahinko siitä voi tulla. Suhteessa siihen kannattaa soveltaa kontrolleja.

Toteennäyttäminen

Aika monessa paikkaa asetuksessa puhutaan toteennäyttämisestä. Se tarkoittaa, että tiedon suojaaminen ei riitä, vaan asetuksen toteuttaminen tulee olla näytettävissä toteen, pääpiirteittäin dokumentaation avulla.

Mitä sieltä dokumentaatiosta pitäisi löytyä? No, osapuilleen kaikki. Päätasolla olisi syytä olla jossain muodossa kuvaus järjestelmistä ja rekistereistä, ja siitä mitä tietoa ne sisältävät. Kun on kuvattu mitä tietoa varastoidaan, tietokannoissa ja tiedostoissa (tähän olisi hyvä liittää vähän luokittelua), on tarpeen myös kuvata tietovirrat, eli tässä tapauksessa mihin tieto liikkuu järjestelmissä. Asetuksen kannalta kiinnostaa eritoten, missä ylitetään maiden rajoja, ja kenen käsittelijöiden kautta tieto liikkuu. Tässä käsittelijöitä ovat esim. pilvipalvelualustat. Kokemus on osoittanut, että voi olla tarpeen/hyödyllistä viedä näitä kuvauksia teknisemmällekin tasolle, jotta saadaan näkyviin esim. protokollat ja muut data-in-motion suojaustarpeet.

Sopimukset on toinen alue mihin tulee kiinnittää huomiota. Asetuksessa tullaan hakemaan vastuullisuus-alueita, ja enää ei myöskään riitä että pestään kädet siinä kohtaa kun maa/organisaatioraja ylittyy. Tiedon alunperäinen kerääjä ja varastoija tulee olemaan ensisijainen vastuullinen koko ketjusta. Esim. pilvipalvelualustoilla tulee olla sopimukset kunnossa. Tähän ovatkin jo suurimmat pilvipalvelualustat reagoineet, ja esim. AWS pilvessä tulee olemaan sopimuspäivityksiä vuoden sisään, ja lisäapua vaatimusten täyttämiseen.

Prosessit tulee luultavasti tuoda tarkempaan syyniin. Tietosuoja-asetuksen yksi tärkeä nurkka on oikeutus henkilötiedon käsittelyyn. Aiemmin oikeutusta ei ole niinkään mietitty, monessa paikkaa. On vain kerätty kaikki mitä saadaan, ja käytetty sitä vapaasti miten voidaan. Nyt jos käsittely ja keruu tulee valokeilaan, tai peräti auditin alaiseksi, pitäisi pystyä näyttämään toteen myös minimaalinen pääsy ja minimaalinen keruu, eli kerätään vain mitä tarvitaan, keräämiselle on hyväksyttävä oikeutus (sopimukset, luvat, lain vaatimukset, jne), ja tietoon pääsevät käsiksi vain minimissään ne joille se on tarpeen, ja oikeutettua. Tämä karsii pois kaikki villit uusiokäytöt joille ei ole oikeutusta, tai tuotantodatan dumppaamisen muistitikuille tai tiedostoihin esim. testausta varten. Ja edellyttää prosessien kehittämistä ja dokumentoimista. Ne jotka ovat tätä jo tehneet ovat tietysti jo hyvällä alulla.

Edelleen yksi dokumentoinnin alue on kyetä esittämään, mitä tietoturvakontrolleja on toteutettu, ja miten toteutuu asetuksen edellyttämä data protection-by-default vaade. Tämä lienee alue joka isoimmin hakee muotoaan. Toisaalta tämä on ollut alue jossa perinteisesti on jo tietoturvanäkökulmasta aina dokumentoitu jotain, eli jonkunmoista pohjaa löytyy jo.

Asetuksen henki

Tulkittaessa lakipykäliä ja vaatimuksia, ja väistellessä uhkasakkoja, usein helposti unohtuu, miksi tätä asetusta on alettu puuhailemaan. Sen taustalta löytyy hyvin kauniita ajatuksia, ja potentiaalista liiketoiminnallista hyötyä myös, ei pelkkiä kulueriä. Seuraamalla asetuksen henkeä mennään jo aika pitkälti oikeaan suuntaan.

Mikä sitten on asetuksen henki? Se tiivistyy pariin ajatukseen:

  • Lisää oikeuksia rekisteröidyille, henkilöille joista tietoa kerätään
  • Läpinäkyvä ja oikeudenmukainen tietojen käsittely
  • Lisää valtaa siihen miten ja mihin omia tietoja saa käsitellä
  • Sisäänrakennettu ja oletusarvoinen tietosuoja, aina järjestelmiä rakentaessa ja hankittaessa

Kun nämä ynnää yhteen, hyväähän siitä tulee. Läpinäkyvyys toteutuu kun rekisteröity voi nähdä tarkasti mitä tietoja hänestä kerätään, ja mihin niitä käytetään, ja miksi. Kun rekisteröity voi lisäksi helposti tarkistaa käyttötarkoitukset, ja hallita niitä itse, päättäen esim. mitä tietoja voidaan käyttää profiloinnissa ja analyyseissä, voimaantumisen tunne vain kasvaa. Lopulta kun tiedot voi poistaa rekistereistä kun niitä ei enää tarvita, ja siirtää ne helposti toiselle prosessoijalle tai vaikka itselleen, luulisi henkilökohtaisen tiedon alkavan jo kiinnostaa.

Tässä piilee business mahdollisuuksia, luottamuksen lisääntyessä ja itsepalvelun helpottaessa luvitusta, voidaan saada potentiaalisesti paljonkin enemmän tietoa ja lupia kuin aikaisemmin, läpinäkyvästi. Kun tietosuoja ja tietoturva järjestelmissä kehittyy, niihin liittyvät liiketoiminnallisetkin riskit pienenevät. Viime aikoina on ollut aika massiivisia tietomurtoja, joissa kantoihin varastoituja tietoja on vuotanut maailmalle, esim. salaamattomia luottokorttitietoja, salasanoja, ostoshistoriaa, jne. Tällaiseen tilanteeseen on aina ankeaa herätä, etenkin jos asiaa penkoessa löytyy rumaa aluetta jossa ei ole tehty ollenkaan tarpeeksi eikä oikeastaan edes uskallettu tarkastella.

Yksi kulma miettiä asiaa on että useimmilla firmoilla pitäisi nyt olla ainakin 20 miljoonaa euroa käytettävissään pistää vähän asioita kuntoon. Sillä saa jo ostettua viipaleen jos toisenkin tietoturvaa.

Sähköinen identiteetti

Asetuksessa hiipii sisään yksi piilo-feature joka on sekä uhka että mahdollisuus. Jotta henkilö voi harjoittaa oikeuksiaan, ja esim. vaatia kaikkien tietojensa poistamista järjestelmästä asiakassuhteen päätyttyä, hänet pitää luonnollisesti tunnistaa, ja pystyä liittämään kaikkiin tietoihin.

Miten tunnistetaan riittävän vahvasti, ettei tässä kohtaa tapahdu väärinkäytöksiä? Jos käytössä on jo sähköinen tunnistaminen kaikille rekisteröidyille, tässä ollaan pitkällä. Jos ei ole, nyt taitaa olla aika kehittää. Mitenkäs se kantojen tietosisältö? Mitä varmasti identifioivaa tietoa sieltä löytyy? Voiko email osoitteen perusteella varmasti tunnistaa että pyyntö tuli samalta Matti Möttöseltä joka löytyy rekisteristä? Entä jos se on vanhentunut? Voiko puhelinnumerolla tunnistaa? Voiko tunnistautua tulemalla paikan päälle ja näyttämällä passinsa?

Vastaus kaikkeen tähän: Tunnistamista ja sähköistä identiteettiä pitää luultavasti kehittää. Luultavasti pitää kuvata ja kenties parantaa henkilö/asiakastiedon laatua, sitä miten taulut ja järjestelmät liittyvät toisiinsa. Luultavasti tämän tekeminen on epämiellyttävää jumppaa, johon kuluu rahaa.

Luultavasti kun se on tehty, kyvykkyys tarjota asiakkaalle tehokkaita itsepalveluita on huimasti kasvanut, ja samoin on datan laatu.

Oma odotus on myös, että kun pöly vähän laskeutuu, sekä tietoturvan että tietosuojan oletusarvoinen taso sovelluskehityksessä on taas pykälän korkeammalla, ja kun se on jokapäiväistä, se ei merkittävästi lisää edes tekemisen kustannuksia. Nostetaan vain taso korkeammalle kuin ennen, ajan vaatimusten mukaisesti.

Perästä kuuluu?

Tietosuoja-asetus on massiivinen mittaluokaltaan, se tuo muutoksia aika moneenkin ulottuvuuteen. Tarkoitukseni on käsitellä sitä palasina, sovelluskehityksen vinkkelistä tässä blogissa. Aika näyttää löytyykö siihen aikaa, mutta toivon että palataan asiaan täsmäiskujen merkeissä aiheen tiimoilta.

Tässä vähän linkkivinkkejä sitä odotellessa:

http://eur-lex.europa.eu/legal-content/FI/TXT/HTML/?uri=OJ:L:2016:119:FULL&from=FI

http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

http://www.tietosuoja.fi/material/attachments/tietosuojavaltuutettu/tietosuojavaltuutetuntoimisto/oppaat/1Em8rT7IF/Miten_valmistautua_EUn_tietosuoja-asetukseen.pdf

 

Spring Boot Audit Logging

Jotain backendimpää taas vaihteeksi: Projekteissa tulee melkolailla tiheään vaadetta saada aikaan audit loggausta. Vaikkei tulisikaan, se antaa pitkän elinkaaren projekteissa itsellekin mielenrauhaa, että kykenee vastaamaan kysymykseen kuka teki mitä teki milloin teki (miksi teki ei vielä onnistu mutta ehkä IoT avulla sekin ratkaistavissa).

Audit loggausta voi tehdä villistikin eri tavoin ja eri vaatimuksilla. Joissain projekteissa on tultu nähtyä yksinkertainen audit service jota kutsutaan aina tarvittaessa, halutuista paikoista. Tässä on huonoa se, että pitää muistaa kutsua sitä, eli ei ole taattua että suuremmassa projektissa joka koodaaja on laittanut auditit paikalleen, lisäksi se rikkoo DRY periaatetta aika rumasti. Toisaalta on mahdollista tehdä monellakin tapaa filter/interceptor, joka tulee aina väliin ja loggaa vaikka kaiken. Mutta tässä mallissa voi olla ongelmana suuri hälyn määrä, eli voi olla että logi täyttyy tapahtumista jotka eivät ole oikeasti kiinnostavia mutta joita on paljon.

Kirjoittelen tätä blogia koska löysin mielestäni fiksun ratkaisun Spring Frameworkin puolelta, vieläpä Spring Boot yhteensopivana, eli ei xml:ää vaativana. Ratkaisu on fiksu koska se on mukava kompromissi kahdesta mainitusta ääripään tavasta – sisältäen tavallaan molempien huonoja ja hyviä puolia. Mutta ennenkaikkea se on melko kaunis, esteettinen, eikä riko yhtälailla ikävästi DRY periaatetta. Kirjaan näitä ylös myös ennenkaikkea itselleni muistiin, vähentää kivasti tarvittavaa aikaa soveltaa uudelleen, kun on tiedossa testattua luotettavaa ja (tällä hetkellä) ajantasaista tietoa.

Se mitä halusin on oikeastaan mahdollisuus auditoida metoditasolla on-demand, missä haluan. Ei täysautomaattisesti kaikkea, mutta ei myöskään samaa koodia copy-pasteillen joka paikkaan. Lisäksi halusin että voin halutessani määrittää audit eventille nimen, ja/tai kategorian, ja/tai koodin, pelkän metodi/luokannimen sijasta.

Homma lähtee liikkeelle ihan perinteisistä Spring AOP annotaatioista. Eli tarvitaan ensin Spring Boot projekti. Niistä olen kirjaillut jo aiemmin eli en lähde ihan sillä tasolla asiaa avaamaan tällä kertaa. Mutta sen päälle tarvitaan AOP dependency, näin:

 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-aop</artifactId>
 <version>${spring.boot.version}</version>
 </dependency>

Ja nyt ollaan jo aika pitkällä 😉 Hyvä huomata että Spring Boot on aika herkkä sille mitä kaikkea automatiikkaa olet kytkenyt päälle, itse olen saanut AOP featuret vahingossa joskus pois päältä esim. väärillä annotaatiolla Application/Configuration-luokassa. Mutta yleisin syy silti AOP toimimattomuuteen on rikkinäiset pointcutit. Joten testataanpa ensin iisisti mahdollisimman lavealla interceptorilla:

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class AuditAOP {
@After("execution(* *.*(..))")
 public void logServiceAccess(JoinPoint joinPoint) {
 System.out.println("AuditAOP: Completed : " + joinPoint);
 }
}

Jep, tuossa on AspectJ joinpoint joka tarraa kiinni ihan kaikkeen, niin kauan kuin mennään Springin läpi eli kohteena on Spring-manageroitu komponentti.Tässä kohtaa vain logataan joinpoint. Hyvä katsoa toimiiko, loggaako. Jos loggaa, erinomaista. Tarvittaessa Joinpointilta voidaan louhia lisääkin tietoja:

@After("execution(* *.*(..))")
public void logServiceAccess(JoinPoint joinPoint) {
  System.out.println("AuditAOP: Completed : " + joinPoint);
  Signature signature = joinPoint.getSignature();
  String methodName = signature.getName();
  String arguments = Arrays.toString(joinPoint.getArgs());
  System.out.println("Method: " + methodName + " with arguments "
    + arguments +  " has just been called");
}

Toimiiko tämäkin? Loistavaa. Nyt on sitten aika siirtyä itse pihviin. Voit nimittäin tehdä tästä annotaatiovetoista, annotaatiota voi käyttää halusi mukaan joko kääntämään auditin pois päältä, tai päälle. Itse tykkäisin että on annotaatio audit, jolla voin valita auditoitavan eventin nimen. Sen käyttö tapahtuisi näin:

@Component
class JokuRandomiSpringService {
  @Audit("ACCOUNT_DELETE")
  public void poistaPirunTarkeeTili() {
    // Jotain ihan järkyn fiksua koodia tähän kohtaan
  }
}

Jeah, aika mukava? Joten tehdään tämmöinen:

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Audit {
  String value() default "";
}

Sitten siihen todelliseen taikuuteen. Eli miten aop interceptor aktivoituu vain annotaation havaitessaan? Näin:

@Before("execution(* *.*(..)) && @annotation(audit)")
public void logServiceAccess(JoinPoint joinPoint, Audit audit) {
  String event = audit.value();
  if ("".equals(event)) {
    event = joinPoint.getSignature().getName();
  }
  Principal user = (Principal) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
  String remoteAddress = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes())
    .getRequest().getRemoteAddr();
  auditEventService.createEvent(new AuditEventEntity(user.getName(), event, remoteAddress));
}

Huomaa myös että annotaation mäpätään joinpointtiin muuttujanimellä, ja tulee parametriksi interceptorille. Annotaation sisältä voidaan kaivaa halutut parametrit, tässä tapauksessa value, joka olisi audit eventin nimi.

Tämän esimerkin koodi menee vähän pidemmälle. Jos nimeä ei ole annettu, oletusnimi on kutsuttavan metodin nimi, eli value on valinnainen. Lisäksi kaivellaan käyttäjän identiteetti security contextista, ja ip-osoite request contextista. Huom! Esitetty malli ei ole yksikkötestiystävällisintä, voi olla että on elegantimpiakin tapoja injektoida nämä contextit.

Mitäs vielä? Tuossa koodissa oleva auditEventService on ihan tavallinen Spring komponentti/service, jossa on yksi rivi koodia jolla talletetaan audit eventti kantaan, sopivaan tauluun, jossa on halutut sarakkeet. Samoin auditevententity on yksinkertaisesti Entity Object, jossa on kentät username, event, remoteaddress – id ja aikaleima ovat autogeneroituja. Lisätään tietoa sen mukaan mikä on paranoian taso.

Joskus tuli tehtyä sellaistakin järjestelmää jossa haluttiin mahdollisimman iisi tietoturva – yleinen tietoturvan sääntö kun on, että mitä tiukemmin kiristää käyttäjille näkyvää tietoturvaa, ja vaikeuttaa arkea, sitä luovemmin opitaan kiertämään se tietoturva, luoden usein jopa turvattomampi ratkaisu kuin alunperin (salasanoja muistilapuilla, sama salasana kaikkialla, kulunvalvottujen ovien availu kohteliaisuudesta, jne). Hyviä tietoturvaratkaisuja ovat eritoten ne systeemit joissa tietoturva ei hankaloita käyttäjän arkea. (Tämän takia salasanat ovat helvetistä)

Esim. tarkka auditointi tarkkojen roolilokeroiden sijasta, kaikki saavat tehdä lähes kaikkea mutta kaikesta jää jäljet. Tai jos haluaa niin molemmat päälle. Riippuu ympäristöstä mikä on fiksua, tarpeellista tai lainsäädännön sanelemaa.

Hyvä huomata että tämän tason auditointi ei loggaa virheitä jotka johtivat keskeytymiseen jo aiemmin ketjussa, eli jos haluat vielä laveammalla siveltimellä, voit täydentää esim. servlet tason filttereillä ja virhekäsittelijöillä.

 

First rule of exception handling: Do not do exception handling!

Error: There is no error!

Tästä onkin pitänyt jo hetken aikaa pistää ajatuksia ylös, koulutuksissa aiheesta aina saarnaan mutta yritetään koota ajatuksia enemmän tai vähemmän koherentisti jopa artikkelin muotoon. Lainasin iskevän Fight Club henkisen artikkelin toisesta paikkaa, mutta ajatukset ovat ihan omia. Niissähän voi olla myös mielipiteitä ja jopa väärinkäsityksiä, eli tunne olosi vapaaksi kertoa mielipiteitäsi 😉 😉

NullpointerException at line 5872/Error: There is no error!

Konsulttihommissa ja ihan vain käyttäessä kotimaisia ja ulkomaisia web-sovelluksia on tullut nähtyä mitä kauheampia lähestymistapoja virhekäsittelyyn. Alkaen ohjelmiston kaatumisesta ja stacktrace-virhepinosta ruudulla tai lähdekoodin näkemisestä ihan vain tyhjään valkoiseen sivuun tai klassisiin: generic error, something unexpected happened tyyppisiin. Kun virhekäsittely on tehty huonosti, se luo suunnattomia tietoturva-haavottuvuuksia, ja luo ohjelmistosta myös huonolaatuisen ja epävakaan kuvan käyttäjille – mikä kaiken lisäksi on useimmiten totta.

Takaisin polulle

Miksi sitten virhekäsittelyä ei tehdä oikein? Kun projektin aikataulupaineet puskevat päälle mennään usein kiireen alla koodaamaan ja silloin saattaa olla että keskitytään vain siihen yhteen ainoaan happy-skenaarioon testauksessa, siihen kun kaikki toimii. Yhtä tärkeää olisi myös miettiä polut: Mikä voi mennä pieleen. Testata ne, rakentaa niille käsittelyt jotka mahdollisimman sulavasti ohjaavat käyttäjän taas tuottavalle polulle. Tässä onkin virheiden käsittelyn tärkein oppi (ja hyvä neuvo elämässä noin muutenkin). Älä keskity siihen mikä meni pieleen – keskity siihen miten normaalitoiminta voi taas jatkua.

Sovelluksessa tapahtuvat epänormaalit tilanteet johtuvat tyypillisesti kahdesta eri asiasta: Käyttäjästä, tai olosuhteista. Edelliset eivät ole oikeastaan virheitä, vaan väärinkäsityksiä, jotka pitää lempeästi ohjaten oikaista. Jälkimmäiset taas ovat asioita joista käyttäjälle on tarpeetonta tiedottaa näyttäen poikkeuspinoa ja koodin rivinumeroita: Loggaa niiden tekniset yksityiskohdat talteen, korjaa ne välittömästi jos pystyt, tai jos et pysty, kerro käyttäjälle että järjestelmässä on ongelmaa, anna ohjeet miten tästä voi edetä, ja mielellään tiketti jolla logiviestit voidaan jäljittää.

Opasta käyttäjää lempeästi

Ohjaa siis käyttäjä takaisin tuottavalle polulle. Se tarkoittaa että ennakoit mahdollisia virhetiloja. Tuliko syöte joka ei ole sallittu? Opasta käyttäjää hyvin esimerkein. Älä anna sovelluksen kaatua ylimääräiseen heittomerkkin tai pienempi-kuin merkkiin. Älä tyhjennä syötettyä lomaketta tiedoista ja näytä käyttäjälle virheilmoitusta tyyliin: ”Syötteessä oli virhe. Yritä uudelleen”.  Hyvä virhekäsittely ei hävitä jo syötettyjä tietoja mutta näyttää tarkalleen missä syötevirhe oli ja mieluiten hyvän esimerkin kera millaista syötettä tässä odotetaan. Esim. puhelinnumerot, päivämäärät, numerot menevät herkästi sekaisin, ja väärinkäsityksen vuoksi merkkijono voi olla aivan liian lyhyt tai pitkä. Tarkista myös että syötetyt merkit ovat järkeviä sovelluksen kannalta: Unicodessa on n. 65 000 merkkiä joista periaatteessa jokainen voi olla turvariski väärissä olosuhteissa. Ehkä siis on parempi olla tarkistamatta erikseen vaarallisia merkkejä, ja sensijaan miettiä tarkemmin mikä on sallittua.

Jotain odottamatonta tapahtui – odota hetki ja yritä uudelleen, tai ota yhteys ylläpitoon

Kun jotain odottamatonta menee pieleen se voi johtua esim. odottamattomasta kuormituksesta, verkkoyhteyksien menettämisestä, sähkökatkoksesta, odottamattomasta uudelleenkäynnistyksestä, viiveiden aiheuttamasta timeoutista, siitä että joku kompastui verkko tai sähköjohtoon, kovalevy hajosi, etc. Mikään näistähän ei ole oikeasti odottamatonta, eihän? Näitä tapahtuu, ja näitä voi myös testata. Voit tarkistaa miten sovelluksessasi näkyy kun kantapalvelin ajetaan alas tai joku osakomponentti hajoaa tai sammuu. Kuormitusta voidaan simuloida ja vasteaikoja testata. Toisin sanoen, kun odotettuja odottamattomia virhetiloja ilmenee, hyvin tehty järjestelmä kertoo käyttäjälle riittävästi, loggaa yksityiskohdat talteen, ja tarvittaessa hälyttää ylläpidon jotta jotain voidaan tehdä. Ja kun jotain todella odottamatonta tapahtuu, prosessi on periaatteessa sama mutta ehkä kiireisempi. On mahdollista tehdä geneerinen virhekäsittely joka kattaa loput tilanteet joita ei todellakaan osattu odottaa. Miten nopeasti virheen sattumisesta päästään taas takaisin tuottavalle polulle? Siinä erottuvat jyvät akanoista.

Virheiden käsittelyn Antipatterneja

Sanaa antipattern en edes yritä suomentaa (Vastahahmo? ;), mutta on tullut nähtyä kooditasolla levinneitä turmiollisia lähestymistapoja siihen miten virheitä käsitellään. Mitä vikaa on seuraavissa malleissa?

try {
      // Some code that causes errors here
} catch (NullPointerException npe) {
} catch (ArrayIndexOutOfBoundsException aiooe) {
      aiooe.printStackTrace();
} catch (Exception ex) {
      showErrors("Connection failure, please try again");
}

Hoksaatko mitään turmiollista? Siinä on ainakin kolme antipatternia käytössä. Osa näistä johtui Java kielen valitettavasta visiosta käyttää checked exception mallia eli pakko-käsitellä tyyppisiä poikkeuksia. Se on saanut ohjelmistokehittäjät generoimaan usein tarpeettomia try-catch-lauseita, piilottelemaan poikkeuksia, käsittelemään niitä kun ei ole aika käsitellä, ja käsittelemään niitä huonosti. Mikä meni pieleen?

– Huomasit varmaan tyhjän catch-lohkon. Sellaisia löytyy jopa tuotantokoodista. Oletan että syynä on, että poikkeus laukeaa herkästi mutta on suhteellisen harmiton joten se lakaistaan maton alle. On ehkä 1 tapaus 100:ssa missä on perusteltua tehdä sellainen, eli poikkeus pitää piilottaa. Sellainen poikkeuksellinen tilanne pitäisi kuitenkin dokumentoida ja sen pitäisi olla harvinaisuus, ei yleinen käytäntö. Jos jotain menee pieleen, ja piilotat sen, ongelma ei ole poistunut, ja se tyypillisesti rantautuu myöhemmin jossain muualla mitä mielikuvituksellisimmin tavoin, ja tekee alkuperäisen syyn löytämisen äärettömän vaikeaksi. Se harvinainen tilanne jossa tuo voi olla ok on jos pitää tulla toimeen taustajärjestelmän päällä joka jostain syystä käyttää poikkeuskäsittelyä väärin, ei kerro virhetiloista vaan tekee niillä jotain muuta. Tyhjä catch lohko on paholaisesta.

– Toinen antipattern on äärimmäisen yleinen ex.printStackTrace() kutsu, generoituna suoraan Eclipsestä. Se toimii kehittäjän koneella hienosti, kun virhepino menee konsoliin, mutta asennettuna ei konsolia olekaan. Jos kyseessä on android tai palvelinsofta, virheet tulostuvat logiin. Mutta kukaan ei ehkä koskan katsele logia. Tai jos katselee, merkityksellinen tieto hukkuu sadantuhannen stacktrace tulostuksen alle. Ei näin. Tämä on oikeastaan variaatio edellisestä eli tyhjästä catch lohkosta. Mitä pitää tehdä kun havaitaan poikkeus? Pysähdy, pistä detailit logiin jos virhe todella johtuu ympäristöstä tai on syytä logata. Korjaa ongelma jos se on korjattavissa. Jos ei ole, tiedota niitä jotka pystyvät sen korjaamaan. Ellet pysty tekemään mitään näistä, kuplita virhe eteenpäin tasoon jossa voidaan näin tehdä, yleensä UI taso. Tiedota ylläpitoa jos tarpeen. Tiedota käyttäjää aina. NullPointerException ei kerro mitään käyttäjälle (toivon mukaan), muista kertoa miten tästä päästään eteenpäin eikä sitä mikä meni vikaan.

– Kolmas antipattern yllä on catch-all lohko. Sitä näkee usein ainoana try-catch lohkona, ja usein viimeisenä käsittelynä kuten yllä. Tällekin voi olla joskus perusteensa, mutta useimmiten sitä käytetään aivan liian aikaisin. Catch-all lohkon ongelma on että se todella saa kaikki virheet kiinni, mistä ikinä ne johtuivatkaan. Jos se on liian aikaisin otettu käyttöön, siihen sisältyy röyhkeä oletus että pystyt käsittelemään minkä hyvänsä virheen samalla kaavalla. Mikä voi olla totta, mutta ellei se olekaan, olet taas piilottanut ongelmia muiden alle. Eli käsittely on ok kun todella haluat käsitellä kaikki jäljellä olevat ongelmat, käsittely on väärin kun otat laajasti kiinni mutta sovellat suppeasti virheen näyttöä, kuten yllä.

Mikään ylläolevista ei ole 100% ajasta tuhoisa tai edes väärin, kyse on nyansseista.

Suosituksia poikkeuskäsittelyyn

Älä ota poikkeuksia kiinni liian aikaisin. Jos et ole valmis korjaamaan ongelmaa tai keskustelemaan käyttäjän kanssa, heitä sama poikkeus tai uusi poikkeus uudelleen, kuplita, delegoi seuraavalle kutsupinossa kunnes päästään paikkaan missä voidaan korjata ongelma tai keskustella käyttäjän kanssa siitä miten se korjataan.

Älä loggaa samaa ongelmaa kahdesti tai useammin, kerta riittää. 

Paras tapa saada aikaan hyvä poikkeuskäsittely on hyvä testaus. Kehitä automatisoidut testit käyttöliittymään ja simuloi virheellisiä syötteitä ja muita virhetiloja siinä missä onnistumistakin. Kehitä myös kuormatestausta. Näin näet miten ne ilmenevät käyttöliittymässä, ja bonuksena tällaisten testien uudelleenkäytettävyysarvo on erinomainen. Testaa, testaa, testaa.

– Käyttäjävirheitä jotka johtuvat esim. validoinnista ei yleensä kannata logata (ja tukkia logia tarpeettomalla hälyllä), vaan keskity ohjaamaan käyttäjä oikealle suorituspolulle takaisin. Älä keskity siihen mikä meni pieleen, vaan keskity ohjaamaan käyttäjää miten toimia oikein, hyvän esimerkin kera. Jos käyttöliittymäsi käyttää idioottivarmoja kontrolleja tiedon keruuseen ja omaa hyvän validointilogiikan, voi olla että käyttäjävirheitä ei juuri tapahdu. Pyri siihen että käyttäjän aiheuttamat virheet eivät aiheuta poikkeuksia.

– Järjestelmä ja ympäristövirheet ovat vakavia, ja usein toiminnan pysäyttäviä. Käyttäjä harvoin voi niitä itse korjata. Osa virheistä voi korjautua itselläänkin, mutta tyypillisesti on hyvä logata yksityiskohdat, herätellä joku ylläpidosta tekemään jotain. Jos automatiikka ei siihen riitä, manuaalinen tapa on näyttää käyttäjälle geneerinen sivu jossa on ylläpidon yhteystiedot ja tikettinumero. Tässä tapauksessa älä anna käyttäjälle yksityiskohtia jo tietoturvasyistäkään, mutta loggaa ne huolella, ja pidä huoli että asialle tehdään jotain nopeasti.

– Sitten on ryhmä, todella odottamattomat virheet. Jos näihin yleensä pystyy reagoimaan, lähestymistapa on jotakuinkin sama kuin yllä, sillä erotuksella että nyt on KRIITTISTÄ pistää tietoa ylös virheestä ja nopeasti saada korjausta aikaan. Nämä tulisi myös logissa nostaa selkeästi omaan kategoriaansa että johtolangat löytyvät selkeästi. On ihan ok tehdä koko pinon päälle vielä geneerinen catch-all lohko joka ottaa kiinni kaikki todella odottamattomat virheet – jotta käyttäjän ruudulle ei pauku poikkeuskoodeja ja pinoja. Se ei vain saa olla ainoa poikkeuskäsittelymalli. Pidä myös huoli että käsittely tallettaa riittävästi yksityiskohtaista tietoa siitä mikä meni vikaan.

Siinäpä se. Suorituskyvyn suhteen on myös hyvä muistaa että poikkeuksien heittäminen ja etenkin poikkeuksen ottaminen kiinni ja heittäminen uudelleen on erittäin tehosyöppöä. Mutta sovelluskehityksen ensimmäiset prioriteetit ovat toimivuus ja selkeys, ja kuten opetan kursseilla, optimointia ei pidä lähteä tekemään ellei siihen ole syytä. Jos on, poikkeuskäsittelyn minimointi antaa vastalahjaksi usein suoritusnopeutta lisää. Tästä on kirjoitettu lukemattomia artikkeleita jos aihe kiinnostaa.

Muutamia muita hajatuksia aiheesta:

http://mikehadlow.blogspot.fi/2009/08/first-rule-of-exception-handling-do-not.html

http://today.java.net/article/2006/04/04/exception-handling-antipatterns

AJAX Tietoturvahuolet

Pikkasen olen jo pitkän aikaa uumoillut miten tulevina vuosina tullaan kiroilemaan kaikkia AJAX:in ylikäyttöön liittyviä tietoturvahuolia ja virheitä ja sotkuisia JavaScript mylläköitä. Edes Google ei ole ollut haavoittumaton näiden suhteen. Vietin suurimman osan 2000-luvun alkua saarnaten miten JavaScriptin käyttö on saatanasta koska se johtaa selainriippuvuuksiin ja on lähes mahdotonta testata eri selainyhdistelmillä, ja mitä enemmän JavaScriptiä sitä enemmän myös siirrämme tilatietoa ja vastuuta selainpäähän – päähän johon ei voi luottaa. Mikä sitten on muuttunut niin että AJAX on yllättäen turvallisempaa? Ei oikeastaan mikään..

AJAX oireilee samaa ongelmaa. Käyttäjä kirjautuu sisään – missä käyttäjän autentikointistatus ja id luuraavat? Onko syötteiden validointi sellaista että luotetaan JavaScriptin olevan aina päällä ja toimivan moitteettomasti? Mitä enemmän teet client päässä sitä enemmän kysymyksiä herää. Selain on vihamielistä maaperää. Keskiverrot tietokonekyvyt osaavalle on triviaalia muuttaa kaikki selaimeen lähetetty toimimaan täysin eri tavalla, oli sitten kyse cookieista tai javascript logiikasta. Voimme tietysti siirtää riskialtista tilaa enemmän palvelinpäähän, ja mahdollisesti logiikkaa myös, mutta sitä taas monet frameworkit ja koodit eivät tee.. Eli tulevina vuosina odotettavissa enemmän ja enemmän hauskoja pikku sivuefektejä rikkaita käyttöliittymiä hyödyntäville sovelluksille – no ainakin osille niistä. Aika ajoin törmää ratkaisuihin joissa nämä on tehty fiksummin, ja toki kehnosti tehdynkin sovelluksen voi auditoida ja panssaroida jälkikäteen.

Sitä odotellessa, tässä muidenkin mietteitä, enemmän tuon JavaScriptin puolelta kuin niinkään AJAX:ista: http://www.dzone.com/links/r/javascript_must_die.html

Ja tässä harvinaisen selkeä selitys Scrum:sta: http://www.dzone.com/links/r/presentation_scrum_at_bbv_software_services_ag.html