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.

 

Mainokset

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.