Kas andmelekked on uus reaalsus? Intervjuu Klemens Arroga

Pigem on see uus reaalsus, kus me elame. Andmelekked ei kao kuhugi, samuti nagu ei kao tarkvaraprobleemid ja üha sagenevad küberrünnakud.

Lekete toimumine ei ole tegelikult uus asi, kuid nüüd saadakse rohkem aru andmete väärtusest, samuti on arenenud viisid lekete tuvastamiseks ja neid on hakatud rohkem avalikult raporteerima. Pole halba ilma heata - tänu lekete avalikustamisele kasvab tarbijate ja organisatsioonide teadlikkus, mis muudab e-keskkonna lõpuks turvalisemaks.

Kui me räägime paarist viimasest Eestis toimunud lekkest, siis neil on küll ühine muster olemas. Kui me aga räägime laiemalt ja rahvusvahelisematest leketest, siis seal päris nii ühtset mustrit ei ole.

Kolm kõige sagedasemat põhjust on tahtmatu inimlik viga, puudulikud protsessid andmete käitlemisel ja vead taristu haldamisel. Üldiselt on põhjuseid selleks kaks: kulude kokkuhoid või teadmatus.

Kuigi vaadates, kui palju on muutnud andmete mahud ja nende väärtus, siis peaks olema tänaseks juba selge vana ütlus, et "ma ei ole nii rikas, et osta odavat asja". Ehk olulisi andmeid käitlevate süsteemide arvelt ei ole kindlasti odavam kokku hoida. Mõeldes näiteks uutest seadustest tulenevatele majanduslikele tagajärgedele, siis on selge, et kindlasti on odavam investeerida kohe korraliku süsteemi loomisesse ja protsessidesse selle haldamisel.

Tegelikult muudab ikka. Ja seda juba täna väga mitmetes valdkondades ja süsteemides. Küll aga nii nagu tehisintellekt ei ole imevits kõige jaoks, ei ole ka infolekked ja küberturbe probleemid nii ühesed, kui neid koondav nimetus.

Tehisintellekt ehk AI tegeleb täna spetsiifiliste murekohtade lahendamisega küberturbes ja andmekäitluses, kuid sellist AId, mis lahendaks ära kõik küberturbe probleemid, pole võimalik täna veel luua. Kuid kuna tulevik on sci-fi päralt, siis miski ei ütle, et AI seda tulevikus täies ulatuses teha ei suudaks.

Kuna aina enam rakendatakse ka AId süsteemide loomisel, siis see tähendab, et selle käigus on teoreetiliselt võimalik juba ka AI enda poolt sisse juurutada vajalikud mehhanismid, mis õpivad käigupealt "ise ennast" kaitsma.

Mitmete teiste seas on näiteks Google´il juba mõnda aega olemas tehisintellekt, mis loob ise uusi tehisintellekte. Praegu on see küll veel laborikatsete tasemel, kuid peatselt juba ka laiemalt kasutusel.

Ehk siis mitmetes kohtades tegeleb AI juba tänagi meie andmete kaitsmisega, kuid hetkel veel suhteliselt kitsalt fokusseeritud aspektides ja inimfaktori tähtsus ei ole kaugeltki kadunud.

Kindlasti on see taas koht, kus tuleks tegelda tavakasutaja harimise ja õpetamisega, sest on tõesti suhteliselt keeruline kaitsta kedagi, kes ise ulatab võtme pahalase kätte. Ning selle olukorra teeb kurvemaks see, et keskmise inimese seisukohta on "mida mul ikka varjata on".

Juba ammu ei ole küsimus enam selles, kas midagi on varjata, vaid mida paha saab teha näiteks suunatud rünnakuga ainuüksi tema e-postkastile ligipääsemisega. Rääkimata sellest, et seda inimest saab kasutada "hüppelauana" süsteemide ja inimesteni, kust on võimalik juba suuremat pahandust korda saata.

Teisalt on ka phishing-ründed läinud üha nutikamaks – vahel läheb isegi vilunud spetsialistidel hetk arusaamiseks, et tegemist on tõesti phishinguga. Eriti veel, kui tegemist on suunatud rünnakuga.

Suurte infosüsteemidega on olukord natuke keerulisem, sest andmetele on ligipääs ja neid hallatakse paljudel erinevatel tasemetel erinevate koostööpartnerite poolt.

Uuemate, n-ö cloud-native ja security-first arhitektuurimudelitega püütakse seda erinevate osapoolte riski maandada juba sügavale arhitektuuri juurutatud andmeobjekti tasemel ligipääsude haldamisega.

Lihtsustatult võttes on praegu levinud protsess selline: üks inimene vastutab serverite füüsiliste turvalisuse eest; teine vastutab serverite turvalisuse eest operatsioonisüsteemi, tarkvara ja võrguliikluse tasemel; kolmas vastutab rakenduse eest, millel on ligipääs kasutajate andmebaasile. Lisaks on veel eraldi õiguste ja andmeobjektide ligipääsu kontrollimise ja haldamise kiht.

Uuemates arhitektuurilistes mudelites käib aga andmeobjektide õiguste haldamine juba infrastruktuuri tasemel, sõltumata sellest, kui palju partnereid on süsteemi erinevates kihtides kaasatud.

Loomulikul jääb alles serverite füüsiline turve. Korrektselt seadistatud pilveteenuste puhul on see turvarisk suures osas maandatud, kuna andmed krüpteeritakse enne salvestamist ning jagatakse väikeste kildudena erinevate serverite ja kõvaketaste vahel ära. Tarkvara tasemel puudub ka õiguste või andmeobjektide ligipääsu kontrollimise ja haldamise kiht, mistõttu ei saa isegi tarkvararikke puhul tekkida olukorda, kus keegi saaks ligipääsu kogu andmebaasile – ligipääs on ainult konkreetse autoriseeritud sessiooni andmeobjektidele.

Juriidiliselt võttes jääb vähemalt esialgu vastutus jagatuks. Väga-väga lihtsustatult öeldes: kõik, kellel on ligipääs andmetele, vastutavad nende ligipääsude kaudu liikuvate andmete eest. See on nii alates füüsilise serveri haldajast kuni lõppkasutajani välja.

Kui organisatsioonil puuduvad tugevad teadmised, siis kindlasti tasub teenust sisse osta või kaasata vähemalt väline spetsialist, kes aitab läbi mõelda ja ellu viia lahendused andmete efektiivsemaks kaitsmiseks. Seda siis nii süsteemide ning protsesside loomisel, muutmisel kui olemasolevate andmekogude kaardistamisel.

Sisse ostetud teenus ei vabasta siiski andmeid omavat ettevõtet vastutusest. Lihtsalt on juures kaasvastutaja, kes peaks aitama ka riskide maandamisse panustamisega.

Nende näidete puhul polegi tarbijal oma andmete kaitseks paraku midagi erilist teha. Kui inimesel on mure oma andmete kasutamise pärast, siis on tal seadusest tulenevalt õigus paluda andmeid haldavalt ettevõttelt koopiat kõigist andmetest, mis konkreetselt teda puudutavad. Samuti on tal õigus paluda kõik isikustatud andmed süsteemidest kustutada.

Usun, et enamus inimeste puhul ei ole need andmed väga olulised, sest kes meist ei ostaks kütust ja vahel mõnda kohvi hot dogiga. Kui neid andmeid on aga pikema aja jooksul palju kogunenud, siis on võimalik neist iga inimese kohta üllatavalt palju välja lugeda. Nii, nagu kõigi kasutusharjumusi peegeldavate andmetega.

Kuna andmetele saab konteksti juurde pannes luua uut väärtust, on problemaatiline igasugune andmeleke. Muidugi on ka spetsiifilisi juhtumeid, kus ka ainult üks lekkinud andmerida võib mingis situatsioonis suuri ebamugavusi valmistada.

Kõige esimene asi on teha selgeks, millised andmed ja millistes mahtudes ettevõtte halduses on. Selle alla käib kõik alates suurematest andmeladudest kuni kunagiste turunduskampaaniateni välja, mille andmebaasid võivad veel tänaseni kusagil vanades serverites tiksuda. Seejärel tuleb need kategoriseerida, ebavajalik ja ebaseaduslik ära kustutada ning vajalikud andmed sensitiivsuse järgi erinevatesse gruppidesse jagada.

Seejärel tuleb juba läheneda individuaalsemalt ja leida parimad viisid andmete turvamiseks. Sageli tähendab see andmete ja nende isikustatud seoste lahutamist ning uut riist- ega tarkvara ei peagi soetama. Kui siis peaks juhtuma, et lekib andmebaas näiteks mingite tehingutega, siis pole seal vähemalt isikustatud seoseid juures.

Andmete haldamine on strateegiline otsus ja see peaks olema juhtkonna tasemel otsustatud. Kuid sellega tegelemisest ei pääse ka CIO ja IT-juht. Ideaalis peaks olema kaasatud nii juhtkond, CIO kui ka IT-juht.

Ühelt poolt sõltub see konkreetsest situatsioonist, aga teisalt ka õiguslikest regulatsioonidest, mis võivad seada omad piirangud. Kui võtta näiteks keskmine organisatsioon, siis üldiselt ei suudeta andmeturbesse investeerida samas mahus kui suured pilvteenuste pakkujad.

Kuid ka siin on väga oluline silmas pidada, et ka kõige turvalisem ja parem süsteem on lõpuks ikkagi täpselt nii turvaline, kui see on seadistatud ja kuidas seda kasutatakse. Seetõttu on kindlasti pikas perspektiivis odavam kaasata kohe spetsialist, kes oskab juba eos võimalikke ohukohti näha, otsustada parima lahenduse kasuks ning teha korrektsed seadistused.

Ühte-kahte konkreetset aspekti, mis mingi süsteemi turvalisuse tegeliku taseme kohe ära määravad, on raske välja tuua. Näiteks oleme mõne SaaS teenusepakkuja puhul märganud, et turvalise teenus pähe müüakse krüpteeritud võrguühendust (HTTPS) ja fakti, et serverid on Amazon Web Service´i ehk AWS poolt hallatud.

Kuigi mõlemad on head näitajad, ei ütle need mitte midagi tegeliku turvalisuse kohta – HTTPS peaks olema iga veebiteenuse puhul minimaalne baastase ning AWSi olemasolu ei tähenda automaatselt selle turvalist kasutamist.

Teiselt on aga mõne SaaS teenuse turvapoliitika nii detailne, et annab päris selge pildi tehniliste turvalahenduste, protsesside jms kohta. Kindlasti tasub tutvuda teenust pakkuva ettevõttega, nende ajalooga, päritoluga (vältige ettevõtteid riikidest, kes ei pea lugu inimõigustest), millised on nende turva- ja privaatsuspoliitikad, kas, kes ja kuidas neid auditeerib.

Kui on teada, et andmed asuvad tugevate andmekaitseseadustega Euroopa Liidus, ei ole konkreetsel asukohal keskmise ettevõtte jaoks suur tähtsust. Tänu GDPRile peavad sellest tulenevaid nõudeid järgima ka väljaspool ELi asuvad ettevõtted, kui nad haldavad ELi liikmesriigi kodaniku andmeid.

Kuid sellegipoolest on tõenäolisem, et ELis asuv andmekeskus järgib siinset seadusandlust rohkem kui näiteks USA teenusepakkuja, kes halvemal juhul isegi ei tea GDPRi olemasolust.

Lisaks on ka olukordi, kus meie seadusandlus nõuab, et andmed peavad asuma ainult Eesti riigi territooriumil või olema siia replikeeritud. Seetõttu ei ole mõnel Eesti organisatsioonil võimalik kasutada näiteks Amazoni või Google´i pilveteenuseid. Õnneks muutub see peatselt, kui tekib võimekus pakkuda olulisemaid AWSi teenuseid Eestis asuvatest andmekeskustest.

Ühenduse turvalisus nii sise- kui välisvõrgus on loomulikult äärmiselt oluline, sest selle kaudu liiguvad kõik andmed olenemata nende sensitiivsusest. Pahatihti pööratakse aga põhitähelepanu välisvõrgule ja unustatakse, et ka sisevõrgus peab ühendus krüpteeritud olema ja sealgi peab järgima kõrgeid turvameetmeid.

Esiteks peab olema ülevaade, milliseid andmeid ja kus ettevõte haldab. Ilma selleta ei saa luua korrektseid protsesse ega võtta kasutusele meetmeid sensitiivsete andmete lekkimise vältimiseks.

Teiseks tuleb läbi mõelda andmete talletamise ja ligipääsude protsessid. Kui mõelda veebiteenuste peale, siis kolmandaks tuleb luua turvaline protsess arendus- ja tootekeskkonna vahele, et rakenduse või selle uuenduste avaldamine kasu asemel suurt kahju ei tooks.

Mis on ja mis ei ole delikaatsed andmed?

Isikuandmete kaitse üldmäärus kirjeldab erililiigilisi isikuandmeid vastavalt allolevale loetelule (varasema määratluse kohaselt nimetati selliseid andmeid delikaatseteks).

1. poliitilisi vaateid, usulisi ja maailmavaatelisi veendumusi kirjeldavad andmed, välja arvatud andmed seadusega ettenähtud korras registreeritud eraõiguslike juriidiliste isikute liikmeks olemise kohta;

2. etnilist päritolu ja rassilist kuuluvust kirjeldavad andmed;

3. andmed terviseseisundi või puude kohta;

4. andmed pärilikkuse informatsiooni kohta;

5. biomeetrilised andmed (eelkõige sõrmejälje-, peopesajälje- ja silmaiirisekujutis ning geeniandmed);

6. andmed seksuaalelu kohta;

7. andmed ametiühingu liikmelisuse kohta;

8. andmed süüteo toimepanemise või selle ohvriks langemise kohta enne avalikku kohtuistungit või õigusrikkumise asjas otsuse langetamist või asja menetluse lõpetamist.

1. kollektiivi madal teadlikkus küberhügieenist

2. puudulik ülevaade andmetest

3. ebapädev teenuste seadistus

4. taristu, serverite või tarkvara puudulik turvalisus

5. nõrk või puudulik ligipääsude poliitika

Selle aasta jaanuarist hakkas kehtima uus isikuandmete kaitse seadus.