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

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s