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/

 

Mainokset

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