Tietosuojan ja henkilörekisterien käsittelyn sudenkuopat tietovarastoinnissa

Tietovaraston tietosuojan suunnittelu ei ole yksinkertainen tehtävä, ja tähän liittyvien virheiden korjaaminen jälkikäteen voi osoittautua hyvin hankalaksi ja kalliiksi. Tämän vuoksi päätimme Goforella ottaa tietosuojan yhdeksi keskeiseksi tietovaraston suunnittelua ohjaavaksi tekijäksi asiakasprojekteissamme. Tämän periaatteen johdattamina loimme kriittisempääkin tarkastelua kestävän, mutta kuitenkin selkeän ja ketterän tietovaraston tietosuojauksen mallin, joka käsittää arkkitehtuurin ja mallinnuksen lisäksi mm. roolitukset ja rekisteritietojen käsittelyyn ja raportointiin liittyvät hallintaprosessit. Malli ei kuitenkaan syntynyt nopeasti itsestään, vaan sitä edelsi lukuisia keskusteluja toimialojen lakimiesten, tietosuojavaltuutetun ja tietosuoja-asiantuntijoiden kanssa. Tässä blogissa käsittelen kahta melko yleistä sudenkuoppaa, jotka luomamme malli kiertää, mutta joiden vaarallisuudesta kertoo paljon se, kuinka moni organisaatio on niihin astunut.
Sudenkuopista ensimmäinen on ajatus henkilötietojen anonymisoinnista, niin ettei yksilötasoista tietoa sisältävästä tietovarastosta muodostu henkilötietolain ja toimialakohtaisten lainsäädäntöjen mukaisia henkilörekisterejä. Tätä toteutustapaa on usein kuitenkin lähes mahdotonta toteuttaa lainmukaisesti, koska rekisterin syntyyn voi riittää se, että yksikin henkilö tietovarastossa on tavalla tai toisella tunnistettavissa. Käytännössä tähän voi riittää pelkkä syntymävuosi, eikä henkilö saa olla tunnistettavissa myöskään eri tietoja yhdistelemällä. Koosteisessa tiedossa, esimerkiksi alueellisessa raportoinnissa, henkilöt harvemmin ovat tunnistettavissa, mutta yksilötason tietojen osalta tämä on erittäin haastavaa ja usein mahdotonta hukkaamatta raportoinnin kannalta keskeistä tietoa.
Toinen sudenkuoppa liittyy siihen, kuinka lain määrittelemät henkilörekisterit ja tietojärjestelmät kytketään toisiinsa. Välillä tietovaraston toteutushankkeissa erehdytään ajattelemaan, että yksittäinen tietojärjestelmä tai sen tietokanta vastaavat yhtä rekisteriä. Rekisterin tiedot voivat jakautua kuitenkin eri tietojärjestelmien kesken ja yksittäinen tietojärjestelmä voi sisältää suuren määrä eri rekisterejä, joiden sisältämiä tietoja ei saa yhdistää ilman lain määrittelemiä perusteita. Esimerkiksi yksittäinen sosiaalihuollon tietojärjestelmä sisältää usein jopa yli kaksikymmentä erillistä rekisteriä. Mikäli tiedot tuodaan perinteisen tietovarastoinnin mukaisesti lähdejärjestelmistä edustakannan kautta suoraan tietovaraston raportointirakenteisiin, on suuri riski, että rekisteritietoja käytetään ja valvotaan lain vastaisesti. Koska perinteisessä tavassa tietojen yhdistäminen tapahtuu latausprosesseissa, tulee rekisterinpitäjän pystyä arvioimaan tähän liittyviä yhdistely- ja liiketoimintasääntöjä integraatiologiikan seasta. Koska eri rekisterien tiedot voivat lähdejärjestelmissä sijaita fyysisesti yhdessä, jopa samoissa kantatauluissa, pitäisi rekisterinpitäjän vielä tietää lähdejärjestelmien sisäiset toteutustavat ja kantarakenteet varmistuakseen rekisteritietojen lainmukaisesta käytöstä. Onneksi rekisterinpitäjää ei ole pakko saattaa edellä kuvattuun tilanteeseen.
Edellä kuvattuihin sudenkuoppiin ei kannata lähteä hakemaan parannusta pienillä korjausliikkeillä, vaan ottaa iso leka käteen ja korjata tietosuojan kannalta keskeiset suunnitteluvirheet jo arkkitehtuuritasolta. Ensimmäinen korjausliike on hylätä perinteinen kaksitasoinen tietovarastoinnin arkkitehtuurimalli ja siirtyä esim. Data Vault 2.0 -mukaiseen arkkitehtuuriin. Seuraava keskeinen askel on erottaa lain määrittämät henkilörekisterit Data Vault -kerroksella fyysisesti toisistaan. Eri henkilörekisterien tiedot on syytä jakaa omiin fyysisiin kantarakenteisiinsa myös siinä tapauksessa, että lähdejärjestelmissä näin ei ole toimittu. Data Vault -kerroksella, tästä erillisellä tiedon saantikerroksella ja raportointirakenteiden luontiin liittyvillä hallintaprosesseilla mahdollistetaan selkeä vastuujako, roolitus ja varmistetaan, että päätösvalta rekisteritietojen käytöstä ja raportointitasoista säilyvät rekisterivastaavilla. Tällä tavoin tietojen käyttöä on myös helppo valvoa, eikä raportointityökalun käyttäjät pääse edes suoraan kantaa käyttäessään tarkempaan tietoon käsiksi kuin, mitä rekisterivastaava on määritellyt. Valvonnan osalta keskeisin ero perinteiseen tietovarastoinnin malliin on, että perinteisessä mallissa valvonta voidaan ulottaa vain raportointirakenteiden sisältämiin prosessoituihin tietoihin, ei näiden pohjana oleviin rekisteritietoihin. Edellä kuvatussa arkkitehtuurissa valvonta voidaan puolestaan kohdistaa suoraan rekisteritietojen käyttöön, koska toisin kuin perinteisessä mallissa, rekisterit ovat osa tietovarastoa.
Tietovarastoinnissa eri henkilörekisterien tiedot on yleensä kustannustehokkainta tallentaa yhteiseen fyysiseen tietokantaan. Tämä on mahdollista, vaikka rekisterit olisikin edellä kuvatuista syistä erotettu toisistaan fyysisellä tasolla eri kantarakenteisiin. Laissa henkilörekisterillä tarkoitetaan loogista, ei fyysistä tietojoukkoa. Lain näkökulmasta fyysinen tietokanta ja rekisteri eivät siis liity mitenkään toisiinsa. Eri rekisterien sisältämiä henkilötietoja ei yleensä saa eikä ole tarkoituksenmukaista yhdistää toisiinsa. Eri tietolähteet sisältävät kuitenkin paljon muutakin tietovarastoinnissa hyödynnettävää tietoa kuin henkilötietoja. Näitä tietoja, kuten esimerkiksi palvelu- ja aluetietoja, voidaan tuoda muista tietojärjestelmistä ja yhdistää yleensä melko vapaasti rekisteritietoihin. Riippumatta siitä, miten tiedot on tietovarastossa jaoteltu, tietojen yhdistely onnistuu yleensä varsin helposti Data Vault 2.0 -mallinnuksen mukaisilla avaimilla, jotka ovat 2.0 version myötä päivitetty huomioimaan erityisesti big datan vaatimukset tietovarastoinnille.