Pseudonimizavimas: atskirkite analizės duomenis nuo tapatybės atkūrimo

Pseudonimizavimas naudingas tada, kai darbuotojui ar paslaugų teikėjui reikia palyginti to paties žmogaus įvykius, tačiau jo vardas tam darbui nereikalingas. Vienoje sistemoje lieka užsakymų istorija su atsitiktiniu žymeniu, kitoje saugomas žymens ryšys su klientu. Apsauga atsiranda iš šio atskyrimo ir jo kontrolės. Pervadinus stulpelį „kliento numeris“ į „anoniminis kodas“, duomenų naudojimo galimybės savaime nepasikeičia.

Šiame modelyje parengsite konkrečią dviejų duomenų zonų schemą, prieigos taisykles ir tapatybės atkūrimo užklausą. Pavyzdys skirtas pasikartojančių klientų aptarnavimo problemų analizei. Tai hipotetinė projektavimo situacija, kurią reikia pritaikyti prie savo sistemų, grėsmių ir teisėto tvarkymo tikslo.

Ką teisiškai ir techniškai pakeičia pseudonimas

Pagal BDAR 4 straipsnio 5 punktą pseudonimizuojant duomenų nebegalima priskirti konkrečiam asmeniui be papildomos informacijos, kuri laikoma atskirai ir saugoma techninėmis bei organizacinėmis priemonėmis. Organizacijai, kuri gali atkurti ryšį, tai tebėra asmens duomenys. Todėl lieka aktualūs tvarkymo pagrindas, informavimas, saugojimo trukmė, gavėjų kontrolė ir žmonių teisės. Pseudonimizavimas taip pat minimas tarp galimų saugumo priemonių, tačiau jis nepakeičia rizika pagrįsto priemonių parinkimo. BDAR lietuvių kalba.

Atskirai vertinkite anonimizavimą: ar realiomis aplinkybėmis dar įmanoma išskirti žmogų, susieti įrašus ar jį atpažinti iš kitų požymių. Jei projekto tikslas – paskelbti atvirus duomenis, vien pašalinti ryšių lentelę paprastai nepakanka išvadai pagrįsti. Tokiam sprendimui naudokite anonimizavimo patikrą, kuri vertina ir likusių požymių atpažinimo riziką.

Pseudonimas nesuteikia leidimo jungti visų turimų duomenų. Prieš techninį darbą užrašykite, kokiam klausimui atsakys analizė, kodėl reikalingas pakartotinis susiejimas ir kokie požymiai tam būtini. Jei pakanka bendro užklausų skaičiaus, asmens lygmens žymens gali visai nereikėti. Šią ribą padeda nustatyti duomenų kiekio mažinimo auditas.

Užpildytas duomenų zonų pavyzdys

Tarkime, paslaugų bendrovė nori nustatyti, ar klientai pakartotinai kreipiasi dėl to paties užsakymo pristatymo. Analitikas turi matyti kreipimosi datą, problemos kategoriją, užsakymo būseną ir pastovų to projekto kliento žymenį. Jam nereikia vardo, el. pašto, telefono, tikslaus adreso ar viso laiško teksto.

Pavyzdžio architektūroje susiejimo tarnyba yra atskiroje prieigos zonoje. Analitiko paskyra neturi jos skaitymo teisių, o duomenų eksportavimo procesas nepersiunčia papildomos informacijos kartu su analize. Atsarginės kopijos, administratorių teisės ir techninės pagalbos paskyros taip pat įtraukiamos į schemą. Kitaip kasdienės sistemos atskyrimą gali panaikinti viena bendra atsarginių kopijų saugykla.

Zonų ir perdavimo kryptis pažymėkite informacinių sistemų žemėlapyje. Brėžinyje turi būti matoma, kas generuoja žymenį, kas priima užklausą ir kur atsiranda eksportas. Vien dokumento teiginys „raktai saugomi atskirai“ neatsako, ar tas pats administratorius gali atsisiųsti abu rinkinius.

Kaip pasirinkti žymens sudarymo būdą

Atsitiktinis žymuo su atskira susiejimo lentele tinka, kai reikia kontroliuojamo tapatybės atkūrimo ir galima valdyti papildomą saugyklą. Žymuo neturėtų būti išvedamas iš telefono numerio, gimimo datos ar nuoseklaus klientų numeravimo. Jo pakankamą atsitiktinumą ir susidūrimo tikimybę vertina techninis projektuotojas pagal numatomą įrašų kiekį, o ne pagal tai, ar kodas žmogui atrodo sudėtingas.

Deterministinis HMAC su slaptu raktu gali leisti pakartotinai gauti tą patį projekto žymenį iš to paties identifikatoriaus. Tai nėra leidimas raktą įrašyti į analizės programos failą. Reikia riboti prieigą prie rakto ir pačios žymenų generavimo funkcijos: kas gali pateikti spėjamų identifikatorių sąrašą ir gauti jų žymenis, gali mėginti atpažinti analizės įrašus.

Paprasta neslapta maiša nėra lygiavertė šiam atskyrimui. Jei pradinių reikšmių aibė lengvai nuspėjama, užpuolikas gali iš anksto apskaičiuoti galimus rezultatus. Papildoma druska padeda tik pagal konkrečią schemą ir grėsmių modelį; vieša druska nėra slaptas raktas. ENISA analizuoja pseudonimizavimo metodus, jų dalyvius ir spėjimo bei žodynų atakų rizikas. Šis techninis šaltinis padeda palyginti pasirinkimus, tačiau nenustato vienos visoms organizacijoms privalomos technologijos. ENISA pseudonimizavimo metodų apžvalga.

Grįžtamasis šifravimas gali būti schemos dalis, kai būtinas iššifravimas. Tuomet atskirai numatykite raktų saugojimą, naudojimą, keitimą ir kompromitavimo atvejį. Šifravimo planas padeda aprašyti šias pareigas, bet net ir stiprus šifras neapsaugo, jei analitikas kartu gauna veikiančią iššifravimo paskyrą.

Vienas projektas – apibrėžtos susiejimo ribos

Šiame pavyzdyje klientas gauna vieną žymenį pristatymo analizei, o kitame projekte – kitą. Toks pasirinkimas sumažina galimybę tyliai sujungti skirtingus rinkinius. Visos organizacijos bendras pastovus pseudonimas palengvina analitiką, tačiau kartu tampa universaliu jungimo raktu. Prieš jį pasirinkdami paaiškinkite, kodėl toks mastas reikalingas.

Projektui gali reikėti to paties žymens šešių mėnesių laikotarpiu, kad būtų matomas pasikartojimas. Tuomet nurodykite laikotarpio pradžią, pabaigą ir elgesį jam pasibaigus: ar žymenys keičiami, ar tęsiamas pagrįstas stebėjimas, ar paliekama tik grupinė statistika. Šeši mėnesiai šiame pavyzdyje yra projekto pasirinkimas, o ne teisės aktu nustatytas terminas.

Sujungus rinkinius iš naujo įvertinkite retus požymių derinius. Analitikas gali neturėti ryšių lentelės, bet žinoti vienintelį klientą, kuris konkrečią dieną pateikė viešai aptartą skundą. Todėl generalizuojama data, ribojamas detalumas arba pašalinamos retos kategorijos. Pseudonimo apsauga vertinama kartu su visu likusiu įrašu.

Tapatybės atkūrimas turi turėti siaurą procedūrą

Užpildytos užklausos pavyzdys: „Analizėje nustatytas neišspręstas pristatymo incidentas, žymuo P-7K4; prašome perduoti atsakingai aptarnavimo komandai originalų užsakymo numerį, kad ji galėtų patikrinti būseną. Analitikui kontaktų pateikti nereikia.“ Užklausą patvirtina projekto savininkas, susiejimą atlieka įgaliota tarnyba, o grąžinamas tik užduočiai reikalingas rezultatas.

Užklausos įraše palikite tikslą, prašytoją, patvirtinusį asmenį, laiką, paveiktų įrašų apimtį ir gavėją. Techninis žurnalas neturėtų automatiškai kopijuoti visų kontaktų ar slapto rakto. Kontrolės įrodymai ir patys identifikatoriai turi skirtingas saugojimo bei prieigos reikmes; jas aprašykite saugumo žurnalų politikoje.

Masinis atkūrimas reikalauja atskiro sprendimo: kodėl reikia viso rinkinio, kas priima rezultatą ir kada jis bus pašalintas. Kasdienis patogumas nėra pakankamas motyvas panaikinti projekte suprojektuotą atskyrimą. Skubaus incidento procedūra gali būti greitesnė, tačiau turi likti registruota ir peržiūrima.

Priėmimo patikra prieš perduodant analitikui

Patikrą atlikite su sintetiniais įrašais ir keliomis aiškiomis situacijomis. Analitiko paskyra neturi pasiekti ryšių lentelės tiesiogiai, per atsarginę kopiją ar per bendrą failų paiešką. Eksporto faile neturi atsirasti pradinių identifikatorių paslėptuose stulpeliuose, komentaruose arba klaidų pranešimuose. Du skirtingi projektai neturi gauti vienodo žymens, jeigu pasirinktas projektinis atskyrimas.

Taip pat patikrinkite vieno žmogaus duomenų paiešką, taisymą ir trynimą. Atsakinga komanda turi gebėti įvykdyti taikomą prašymą, neatskleisdama viso susiejimo mechanizmo kiekvienam analitikui. Jei šaltinio įrašas ištrinamas, aprašykite, kas nutinka jo projekto kopijai, ryšio lentelei ir atsarginėms kopijoms. Tai derinama su duomenų trynimo koncepcija.

Pasibaigus bandymui išsaugokite pasirinktą schemą, prieigos įrodymą, atmestą neleistiną užklausą ir patvirtintą teisėtą atkūrimo pavyzdį. Šie keturi įrodymai parodo, kad atskyrimas veikia praktiškai. Jei administratorius bandymo metu lengvai gauna abu rinkinius, dokumentuokite likusią riziką ir spręskite, ar reikia atskirti administravimo vaidmenis, sustiprinti patvirtinimą ar sumažinti duomenų detalumą.

Rakto pakeitimas ir projekto uždarymas

Dar prieš paleidimą suplanuokite, kaip bus pakeistas prarastas arba galbūt atskleistas raktas. Vien naujo rakto sukūrimas nepakeičia jau išsiųstų rinkinių. Reikia nustatyti paveiktas kopijas, sustabdyti seną funkciją, perskaičiuoti leidžiamus žymenis ir pranešti gavėjams, kokią ankstesnę medžiagą pašalinti. Jei ryšių lentelė būtina veiklai, jos atkuriamumas tikrinamas atskirai nuo analitinės duomenų bazės.

Uždarant projektą savininkas patvirtina, ar dar reikia individualių eilučių. Grupinė ataskaita, pseudonimizuotas rinkinys ir tapatybės lentelė nėra vienas saugojimo objektas. Kiekvienam užrašykite atskirą sprendimą. Galutinė projekto byla turi parodyti, kam atskyrimas buvo skirtas, kas galėjo jį panaikinti ir ar ši galimybė tikrai panaikinta pasibaigus pagrįstam poreikiui.

Prieš duomenis perduodant išoriniam analitikui, sutartyje ir perdavimo apraše nurodykite, ar gavėjas gauna tik projekto rinkinį, ar gali užsakyti tapatybės atkūrimą. Paprašykite parodyti, kaip gavėjo aplinkoje ribojami eksportai ir subrangovų prieiga. Siuntėjo pusėje atskirtas raktas nepašalina gavėjo turimų papildomų žinių: jei gavėjas kartu teikia klientų aptarnavimą, jis gali turėti originalius kontaktus kitoje sistemoje. Tokį ryšį vertinkite prieš pirmą perdavimą ir keičiantis paslaugų apimčiai.