Člen 32 GDPR in varnost spletnih strani: kaj dejansko zahtevajo 'ustrezni tehnični ukrepi'

Člen 32(1) od upravljavcev in obdelovalcev zahteva uvedbo tehničnih in organizacijskih ukrepov za zagotovitev ravni varnosti, "ustrezne tveganju", ob upoštevanju najnovejšega tehnološkega razvoja, stroškov izvajanja ter narave, obsega in namenov obdelave. Navede štiri neizčrpne primere: psevdonimizacijo in šifriranje osebnih podatkov; zmožnost zagotavljanja stalne zaupnosti, celovitosti, razpoložljivosti in odpornosti sistemov za obdelavo; zmožnost pravočasne obnovitve razpoložljivosti in dostopa po incidentu; ter postopek za redno testiranje in ocenjevanje učinkovitosti ukrepov.

Opazite, česa na tem seznamu ni: nobene omembe HTTPS, nobene omembe HTTP glav, nobene omembe zastavic piškotkov. Člen 32 je namerno tehnološko nevtralen in temelji na tveganju — pove vam zahtevani rezultat (zaupnost, celovitost, razpoložljivost, odpornost), ne da bi predpisal konkreten mehanizem, ker mora isti zakon veljati tako za petstransko predstavitveno stran kot za bolnišnični portal za paciente.

Sta konkretna izvedba "zaupnosti ... sistemov za obdelavo" za najpogostejši primer: spletno stran, ki prenaša osebne podatke (kontaktni obrazec, prijava, nakup, celo zgolj IP-naslov v dnevniku strežnika) med obiskovalčevim brskalnikom in vašim strežnikom. Šifriranje med prenosom — HTTPS z veljavnim certifikatom, brez vračanja na navaden HTTP — je osnovni mehanizem za ta rezultat in je verjetno najbližje temu, da je konfiguracija spletne strani izrecno omenjena v samem besedilu člena 32 ("šifriranje osebnih podatkov").

HTTP varnostne glave so korak dlje od besedila zakona, a jih varnostne smernice (OWASP, ponudniki brskalnikov, nacionalne agencije za kibernetsko varnost) na splošno obravnavajo kot standardne, poceni ukrepe, ki zmanjšujejo pogoste razrede napadov — clickjacking, uganjevanje vrste vsebine (MIME-sniffing), degradacijo protokola — ki bi sicer ogrozili zaupnost ali celovitost sistema za obdelavo. Regulator, ki preiskuje vdor, ne bo kot edino ugotovitev navedel "manjkala vam je glava Content-Security-Policy", vendar je vzorec manjkajoče osnovne utrditve ravno tisto, na kar se sklicujejo pri presoji, ali so bili ukrepi "ustrezni".

Ne poimensko, pravila o piškotkih pa v glavnem izhajajo iz Direktive o zasebnosti in elektronskih komunikacijah (soglasje, razkritje namena), ne neposredno iz GDPR. A ko piškotek nosi identifikator seje ali kateri koli osebni podatek, zanj veljajo obveznosti zaupnosti in celovitosti iz člena 32 enako kot za katerikoli drug osebni podatek med prenosom ali shranjevanjem. Zastavica Secure prepreči, da bi bil piškotek poslan prek navadnega HTTP; HttpOnly onemogoči skriptom na strani odjemalca (vključno z vrinjenimi zlonamernimi), da ga preberejo; SameSite omeji izpostavljenost ponarejanju zahtev med spletnimi mesti (CSRF). Manjkanje vseh treh ne oslabi le "varnosti" v abstraktnem smislu — oslabi konkretno zagotovilo zaupnosti, ki ga člen 32 zahteva za vsak piškotek, ki se dotika osebnih podatkov.

Ti trije zapisi DNS avtenticirajo e-pošto, poslano z vaše domene, in nekomu otežijo pošiljanje prepričljivega lažnega e-poštnega sporočila, ki je videti, kot da prihaja od vas. Povezava z GDPR je posredna, a resnična: kontaktni obrazci, zahteve posameznikov za dostop do podatkov in obvestila o kršitvah običajno potekajo prek e-pošte, domena, ki jo je lahko ponarediti, pa je lažje uporabljena za napade s socialnim inženiringom na vaše zaposlene ali stranke — napade, ki pogosto predhodijo prav tisti vrsti varnostnega incidenta, ki naj bi ga člen 32 preprečeval.

Nobenega od teh treh ni mogoče popolno zanesljivo odkriti od zunaj. SPF in DMARC se nahajata na predvidljivih lokacijah DNS (zapis TXT na domeni in eden na `_dmarc.<domena>`), zato ju je mogoče preveriti neposredno. DKIM nima ene same standardne lokacije — odvisna je od selektorja, ki ga izbere storitev, ki pošilja vašo pošto — zato je vsako zunanje preverjanje DKIM nujno le iskanje pogostih selektorjev po najboljših močeh, ne dokončna ugotovitev odsotnosti.

Ne, in obravnavanje tega tako bi preveč poudarilo, kaj preverjanje konfiguracije dejansko zmore. Skladnost s členom 32 je dokumentirana, na tveganju temelječa odločitev — zahteva, da ste dejansko ocenili tveganje svoje konkretne obdelave in izbrali ukrepe, sorazmerne temu tveganju, ne le, da imate zeleno kljukico ob fiksnem seznamu tehničnih nastavitev. Blog s petimi zaposlenimi in stran, ki obdeluje posebne vrste zdravstvenih podatkov, se soočata z zelo različnima mejama "ustreznosti", tudi če oba opravita isto preverjanje glav.

Kaj preverjanje konfiguracije resnično koristno naredi, je zapiranje vrzeli med "predpostavljali smo, da je to pravilno nastavljeno" in "preverili smo". Manjkajoče uveljavljanje HTTPS, odsotne varnostne glave ali neavtenticirana e-pošta za domeno, ki obdeluje osebne podatke, so ravno tista vrsta preprečljivih, lahko odpravljivih vrzeli, ki jih je težko upravičiti kot "ustrezne" pri kateri koli oceni tveganja — zato je njihova izključitev razumen prvi korak, ne pa celotna vaja.

Zgoraj opisani deli — HTTPS/TLS, standardne varnostne glave, zastavice piškotkov in SPF/DMARC/DKIM — so vsi navzven opazni z vidika brskalnika ali razreševalnika DNS, zaradi česar so primerni za samodejno preverjanje, ki se izvede v nekaj sekundah, namesto za ročno revizijo. Kar tovrstno preverjanje ne zmore, je oceniti vašo notranjo dokumentacijo tveganj, nadzor dostopa ali postopek odzivanja na incidente — to so organizacijski ukrepi po členu 32 in jih je treba oceniti na njihov način, običajno s pravnim vložkom ali vložkom pooblaščene osebe za varstvo podatkov, ne s pregledovalnikom.