Personas dati ievainojamību izpētē: ko darīt, ja pētnieks piekļūst datiem, kurus nemaz nemeklēja?

Piekļuves kontroles ievainojamība var radīt tehnisku iespēju apskatīt tūkstošiem personas ierakstu.

No tā neizriet, ka pētniekam tie jāapskata.

Ir vismaz četri atšķirīgi stāvokļi:

1. tehniski redzams, ka piekļuve būtu iespējama;
2. minimāls datu fragments faktiski parādās ekrānā vai atbildē;
3. dati tiek saglabāti ekrānattēlā, HTTP atbildē, video vai citā pierādījumā;
4. dati tiek kopēti, sistemātiski izgūti, analizēti vai nodoti tālāk.

GDPR 4. panta 2. punkts personas datu apstrādi definē ļoti plaši — tajā ietilpst vākšana, aplūkošana, izgūšana, glabāšana, izmantošana, izpaušana un dzēšana.1

Tāpēc drošības izpētē ir vērts domāt nevis par vienu abstraktu “piekļuvi datiem”, bet par datu dzīves ciklu.

Katrs nākamais solis var palielināt apstrādes apjomu un risku.

Viens no interesantākajiem DVI atbildes punktiem bija atteikšanās automātiski piešķirt pētniekam vienu GDPR lomu.

Ja pētnieks strādā informācijas sistēmas pārziņa uzdevumā un rīkojas saskaņā ar pārziņa noteiktajām pilnvarām un norādījumiem, DVI norādīja, ka šādā situācijā pētnieks būtu uzskatāms par apstrādātāju un aktualizētos GDPR 28. panta pienākumi.2

Savukārt, ja pētnieks pats izvēlas, kuru sistēmu pārbaudīt, kādam nolūkam un ar kādiem līdzekļiem personas datus apstrādāt, viņš attiecībā uz šo apstrādi var tikt uzskatīts par pārzini.2

Tas saskan ar EDPB pieeju: pārziņa un apstrādātāja statuss nav tikai līguma vai pašnosaukuma jautājums; tas jānosaka pēc faktiskās lēmumu pieņemšanas par apstrādes nolūkiem un būtiskajiem līdzekļiem.3

Praktiski tas nozīmē, ka frāze “es esmu tikai security researcher” neatbild uz GDPR jautājumu.

Arī frāze “programma mani sauc par researcher” neatbild.

Jāskatās, kurš īstenībā izlemj, kāpēc un kā personas dati tiek apstrādāti.

Šī ir viena no biežākajām konceptuālajām kļūdām.

Drošības pētnieks var rīkoties ļoti piesardzīgi: apskatīt tikai vienu lauku, aizklāt vārdu, izmantot šifrētu disku un pēc ziņošanas pierādījumu izdzēst.

Tas viss var būt pareizi.

Taču GDPR 5. panta datu minimizācijas princips neatbild uz atsevišķu jautājumu: uz kāda pamata apstrāde vispār ir tiesiska?

GDPR 6. pants prasa atbilstošu tiesisko pamatu personas datu apstrādei.1 DVI savā atbildē tieši norādīja, ka neatkarīgam pētniekam, kurš sistēmu pārbauda pēc savas iniciatīvas, tiesiskā pamata noteikšana var būt sarežģīta. Tas ir vēl sarežģītāk, ja parādās īpašu kategoriju dati, kuriem papildus jāvērtē GDPR 9. pants.2

Tāpēc šīs divas pārbaudes nedrīkst sapludināt:

1. Vai apstrādei ir piemērojams tiesiskais pamats?

2. Ja ir — kāds ir minimālais datu apjoms, kas objektīvi vajadzīgs konkrētajam nolūkam?

Minimizācija nevar izārstēt apstrādi, kurai nav tiesiska pamata.

Iedomāsimies IDOR/BOLA tipa kļūdu.

Pētniekam ir savs testa konts ar objekta ID 1001.

Pieprasījums uz 1002 atgriež cita konta objektu.

Bieži vien ar to jau pietiek, lai pierādītu galveno tehnisko faktu: serveris nepareizi autorizē piekļuvi objektam, kas nepieder autentificētajam lietotājam.

Vai vajag mēģināt 1003, 1004, 1005?

Dažreiz papildu tests var būt objektīvi vajadzīgs, piemēram, lai atšķirtu vienu kļūdaini piešķirtu testa objektu no sistemātiskas autorizācijas problēmas.

Taču argumentam jābūt tehniskam, nevis ziņkārības vadītam.

Labs iekšējais jautājums ir:

Kādu jaunu drošības faktu nākamais pieprasījums pierādīs, kuru es vēl nezinu?

Ja atbilde ir tikai “parādīs, ka pieejami vēl vairāk cilvēku dati”, iespējams, tehniskais pierādījums jau ir sasniegts.

Drošības izpētē nav viena universāla PoC formāta. Tomēr pierādījumu var mēģināt iegūt no mazāk invazīvā uz invazīvāko.

Šī nav GDPR noteikta juridiska hierarhija. Tā ir praktiska metode, kā pirms katra nākamā soļa pajautāt, vai mazāk invazīvs pierādījums jau ir pietiekams.

CERT.LV 2026. gada platformas FAQ iet tajā pašā virzienā: pētniekam nav atļauts izgūt, saglabāt vai citādi apstrādāt ievainojamības izpētes rezultātā iegūtos datus plašāk par apjomu, kas nepieciešams PoC demonstrēšanai.6

Dažkārt tiek mēģināts vilkt robežu starp “es datus nesaglabāju” un “es datus neapstrādāju”.

GDPR izpratnē tā ir pārāk šaura pieeja.

Ja personas dati faktiski parādījās un pētnieks tos aplūkoja vai izgūva, var būt notikusi personas datu apstrāde arī tad, ja ekrānattēls netika saglabāts.1

Taču riska un nepieciešamības ziņā īslaicīga minimāla aplūkošana nav tas pats, kas lejupielādēt datubāzes fragmentu un glabāt to nedēļu.

Tāpēc ir jēga dokumentēt arī apstrādes intensitāti:

• vai dati tikai īslaicīgi parādījās;
• vai tie tika apzināti atvērti;
• vai tika saglabāta kopija;
• cik personas bija skartas;
• kādi datu lauki bija redzami;
• cik ilgi kopija tika glabāta;
• kam tā tika nodota.

Šis konteksts vēlāk var būt svarīgāks par vienu bināru “bija/nebija personas dati”.

Ekrānattēls ir ērts, tāpēc tas kļūst par noklusējuma PoC.

Taču tas var fiksēt daudz vairāk, nekā vajag:

• pilnu vārdu;
• adresi;
• tālruņa numuru;
• e-pastu;
• konta atlikumu;
• veselības informāciju;
• sesijas identifikatoru;
• autentifikācijas tokenu;
• blakus esošus citu personu ierakstus.

Pirms saglabāt ekrānattēlu, labāk uzdot jautājumu: vai tehnisko faktu var pierādīt bez šiem datiem?

Dažkārt pietiek ar:

• objektu ID neatbilstību;
• rediģētu atbildes fragmentu;
• paša kontrolētu testa datu pāri;
• response metadata;
• reproducēšanas soļiem, kurus resursa pārzinis var atkārtot savā vidē.

Ja ekrānattēls tomēr vajadzīgs, saglabājamā kopija var būt aizklāta. Oriģināla saglabāšana būtu atsevišķi jāpamato.

Pseidonimizācija arī nav tas pats, kas anonimizācija. Ja personu vēl iespējams identificēt ar papildu informāciju, dati joprojām ir personas dati.1

Ne visi personas dati rada vienādu risku.

GDPR 9. pants nosaka īpašu režīmu tādiem datiem kā veselības informācija, biometriskie dati identifikācijas nolūkā, politiskie uzskati, reliģiskā pārliecība vai seksuālās dzīves un orientācijas dati.1

Atsevišķs režīms ir arī datiem par sodāmību un pārkāpumiem saskaņā ar 10. pantu.1

DVI savā atbildē īpaši norādīja, ka neatkarīga pētnieka tiesiskā pamata jautājums šādos gadījumos kļūst vēl sarežģītāks.2

Praktiski šeit “apskatīsim vēl dažus ierakstus, lai saprastu apjomu” kļūst īpaši grūti aizstāvams.

Ja ievainojamība jau ir pierādāma un negaidīti parādās, piemēram, veselības dati, saprātīgs drošības princips ir:

• nepalielināt datu apjomu;
• nefiksēt vairāk, nekā vajag tehniskajam pierādījumam;
• nepublicēt reālos datus;
• pēc iespējas ātri pāriet uz drošu koordināciju ar resursa pārzini vai CVD koordinatoru;
• turpmāku padziļinātu pārbaudi veikt tikai ar skaidru papildu pamatu un kontrolētu vidi.

Tas nav universāls juridisks “stop rule”, bet tas ir daudz drošāks noklusējums nekā turpināt tāpēc, ka sistēma tehniski ļauj.

Šo robežu ir vērts pateikt ļoti skaidri.

CERT.LV personas datu apstrādes kārtība Ievainojamību ziņošanas platformā norāda, ka CERT.LV kā platformas pārzinis koordinētas ievainojamību atklāšanas procesā personas datus apstrādā, pamatojoties uz Nacionālās kiberdrošības likumā noteiktajiem uzdevumiem un GDPR 6. panta 1. punkta e) apakšpunktu.5

Tas izskaidro CERT.LV apstrādi pēc tam, kad informācija nonāk CVD koordinācijas procesā.

Tas pats par sevi neatbild uz citu jautājumu:

Kāds ir neatkarīga pētnieka tiesiskais pamats brīdī, kad viņš pirms ziņošanas pats tehniski nonāk pie citas personas datiem?

Tieši šo atšķirību aktualizēju DVI iesniegumā, un DVI atbildē norādīja, ka konkrēta tiesiskā pamata izvērtējums ir atkarīgs no precīzi definēta izpētes procesa, pētnieka lomas, nolūka un nepieciešamajām darbībām ar datiem.2

Tas nozīmē, ka nav korekti teikt:

“CERT.LV drīkst apstrādāt ziņojumu, tātad pētnieks automātiski drīkst iegūt jebkādus datus, kas vajadzīgi ziņojumam.”

Tās ir divas atsevišķas apstrādes situācijas.

Ja minimāls personas datu fragments objektīvi vajadzīgs, nākamais risks sākas pēc ievainojamības atrašanas.

Pierādījumam ir dzīves cikls.

1. Samazini

Izgriez visu, kas nav vajadzīgs ievainojamības izskaidrošanai.

Ja pietiek ar vienu lauku, nesaglabā pilnu profilu.

2. Aizklāj

Ja identitāte nav pierādījuma daļa, aizklāj vārdu, e-pastu, adresi, konta numuru vai citu identifikatoru.

3. Saglabā kontrolēti

Nepamet PoC nejaušā Downloads mapē, publiskā issue trackerī vai sinhronizētā personīgā foto bibliotēkā.

Pierādījuma aizsardzībai jāatbilst tā saturam un riskam.

4. Ierobežo kopijas

Katrs ekrānattēla pārsūtījums Slack, e-pastā, ticketā un telefonā rada jaunu datu kopiju un jaunu dzēšanas problēmu.

5. Nodod minimālo

Ziņojuma saņēmējam ne vienmēr vajag pilnu oriģinālo datu fragmentu. Dažkārt pietiek ar aizklātu kopiju un precīziem reprodukcijas soļiem.

CERT.LV personas datu apstrādes kārtība arī paredz, ka ziņojumā var būt ar ievainojamību saistīti personas dati, vienlaikus platformas process ir jālieto konkrētajam koordinācijas nolūkam.5

6. Pārskati glabāšanas nepieciešamību

“Varbūt kādreiz vajadzēs” nav labs beztermiņa glabāšanas pamatojums.

Pēc ziņojuma apstiprināšanas, remediation vai koordinācijas noslēguma ir jāizvērtē, vai personu identificējošais pierādījums vēl ir vajadzīgs.

Dažkārt vajadzēs saglabāt tehnisko pierādījumu ilgāk juridiskas aizsardzības vai strīda dēļ. Tas ir atsevišķs nolūks, kas arī jāspēj pamatot.

Ievainojamība un personas datu aizsardzības pārkāpums ir saistīti, bet tie nav sinonīmi.

GDPR 4. panta 12. punkts personas datu aizsardzības pārkāpumu sasaista ar drošības pārkāpumu, kura rezultātā notikusi personas datu nejauša vai nelikumīga iznīcināšana, nozaudēšana, pārveidošana, neatļauta izpaušana vai piekļuve.1

Tāpēc tikai fakts, ka sistēmā eksistē ievainojamība, vēl automātiski nenozīmē, ka jau ir noticis personas datu aizsardzības pārkāpums.

Savukārt, ja pētījums atklāj, ka personas datiem faktiski ir bijusi neatļauta piekļuve vai tie ir izpausti, pārzinim jāveic atsevišķs breach izvērtējums.

GDPR 33. pants noteiktos gadījumos paredz paziņošanu uzraudzības iestādei bez nepamatotas kavēšanās un, ja iespējams, 72 stundu laikā; 34. pants noteiktos augsta riska gadījumos paredz arī datu subjektu informēšanu.1 EDPB vadlīnijas uzsver, ka paziņošanas pienākums ir atkarīgs no konkrētā incidenta un riska, nevis tikai no drošības problēmas nosaukuma.4

CVD ziņojums neaizstāj breach assessment.

Un otrādi: tas, ka organizācija sāk GDPR breach procesu, neatceļ vajadzību tehniski novērst pašu ievainojamību.

Šeit var rasties īpaši bīstams pārpratums.

Organizācijai var būt jānoskaidro, cik personu dati bijuši pieejami vai vai ievainojamība jau izmantota ļaunprātīgi.

No tā neizriet, ka neatkarīgam pētniekam pašam jālejupielādē simtiem ierakstu, lai organizācijai sagatavotu incidenta statistiku.

Pētnieka PoC un organizācijas incidenta izmeklēšana ir divi dažādi uzdevumi.

Organizācijai ir pieeja logiem, datubāzēm, SIEM, auditācijas pēdām un citiem avotiem, ar kuriem apjomu var noteikt bez jaunas datu ekspozīcijas radīšanas.

Labs ziņojums pasaka:

“Šajā kontrolētajā pieprasījumā bija iespējams saņemt citas personas objektu.”

Tas nav tas pats, kas:

“Es izgāju cauri 5000 ID un konstatēju 4387 personas.”

Otrais apgalvojums var būt informatīvi bagātāks un juridiski daudz problemātiskāks.

Tas, ka noteikts datu fragments bija nepieciešams konfidenciālā CVD ziņojumā, nenozīmē, ka tas ir nepieciešams blogā, konferences prezentācijā vai publiskā advisory.

Publiskošana ir jauns konteksts ar citu auditoriju un citu risku.

Publiskā tehniskā aprakstā gandrīz vienmēr var izmantot:

• sintētiskus datus;
• pārveidotu piemēru;
• aizklātu ekrānattēlu;
• tehnisko pieprasījuma struktūru bez īstā satura;
• PoC pret pētnieka kontrolētu testa kontu.

Cilvēka īstais vārds nepadara SQL injection, IDOR vai broken access control aprakstu tehniski precīzāku.

Ja reālie personas dati nav nepieciešami publiskā secinājuma izpratnei, tiem tur nav jābūt.

Multi-vendor ievainojamībās ziņojums var ceļot starp resursa pārzini, CERT/CSIRT, programmatūras piegādātāju, mākoņpakalpojuma sniedzēju un ārvalstu pētnieku.

Tas nenozīmē, ka katrai pusei vajag identisku izejas materiālu ar visiem personas datiem.

Pirms nodošanas ārpus ES/EEZ var aktualizēties arī GDPR V nodaļas nosacījumi par personas datu starptautisku nodošanu.1

Praktiski der divi jautājumi:

Kam tieši vajag šo personas datu fragmentu, lai veiktu savu lomu CVD procesā?

Vai to pašu rezultātu var sasniegt ar aizklātu vai sintētisku pierādījumu?

Koordinācija nav attaisnojums datu dublēšanai.

Ja drošības izpētē parādās personas dati, es izmantotu šādu darba modeli.

Šī nav juridiska safe-harbour formula.

Tā ir darba disciplīna, kas samazina iespēju, ka pētnieks pats ar savu PoC rada otru problēmu.

Atbildību nevar uzlikt tikai pētniekam.

Ja organizācija aicina ārējos pētniekus pārbaudīt sistēmu, tai pašai būtu jāpasaka, kā rīkoties ar personas datiem.

Programmas noteikumos ir vērts skaidri noteikt:

• lietot paša kontrolētus testa kontus, kur tas iespējams;
• neizgūt vairāk datu par minimumu, kas vajadzīgs PoC;
• nekopēt datubāzes vai lietotāju sarakstus “ietekmes pierādīšanai”;
• īpašu kategoriju vai autentifikācijas datu gadījumā nekavējoties pārtraukt nevajadzīgu tālāku piekļuvi;
• izmantot noteiktu drošu pierādījumu iesniegšanas kanālu;
• norādīt, vai un cik ilgi pētniekam jāsaglabā pierādījuma kopija;
• aizliegt publiskot reālos personas datus;
• nodrošināt ātru eskalācijas kontaktu gadījumam, kad bez papildu piekļuves nav iespējams saprast ievainojamības raksturu.

CERT.LV pašreizējie platformas noteikumi un FAQ jau satur būtisku minimumu par datu izgūšanas ierobežošanu PoC vajadzībām.6 Organizāciju individuālajās programmās šo principu var padarīt vēl konkrētāku.

DVI neatbildēja ar vienu jaunu universālu formulu.

Tā nepasludināja visus drošības pētniekus par pārziņiem.

Tā nepasludināja visus pētniekus par apstrādātājiem.

Tā nepasludināja CVD par GDPR izņēmumu.

Un tā nenosauca vienu 6. panta pamatu, kas automātiski legalizētu jebkuru neatkarīga pētnieka personas datu apstrādi.

Tā vietā Inspekcija sasaistīja atbildi ar faktisko procesu: pētnieka lomu, nolūku, datu veidu un apjomu, objektīvo nepieciešamību un rīcību pēc ievainojamības atklāšanas.2

Manuprāt, tas ir pareizais virziens arī turpmākai metodikai.

Drošības izpētē robežu nevajag būvēt ap profesijas nosaukumu.

To vajag būvēt ap konkrētu darbību un pierādāmu nepieciešamību.

Personas dati ievainojamību izpētē bieži parādās nevis tāpēc, ka pētnieks tos meklēja, bet tāpēc, ka tieši datu neatļauta ekspozīcija ir ievainojamības būtība.

Tas neatceļ datu aizsardzības prasības.

Labs pētnieks mēģina pierādīt drošības defektu ar mazāko datu apjomu, kas tiešām vajadzīgs, un pārtrauc papildu datu iegūšanu brīdī, kad tā vairs nepievieno jaunu tehnisku faktu.

Labs CVD process savukārt neapstājas pie “atsūti screenshotu”. Tas palīdz pētniekam saprast, kādu pierādījumu vajag, kā to droši nodot un ko darīt ar kopiju pēc tam.

Galvenā robeža ir vienkārša formulējumā, bet ne vienmēr vienkārša praksē:

ievainojamība ir jāpierāda; cilvēku dati nav jāvāc tikai tāpēc, ka ievainojamība tos ļauj savākt.

Juridiskais un institucionālais konteksts pārbaudīts 2026. gada 25. septembrī. DVI atbilde ir konkrēta institucionāla atbilde uz autora 2026. gada 10. augusta iesniegumu; tā nav pasniegta kā vispārsaistoša tiesību norma. Rakstā piedāvātās “minimālā pierādījuma kāpnes” un “stop and escalate” tabula ir autora praktiska metode.

Šis raksts ir tehniskas un datu aizsardzības prakses analīze, nevis individuāla juridiska konsultācija.