Confidențialitate reală vs aparentă: întrebările pe care merită să ni le punem

Diferența dintre confidențialitatea arhitecturală și confidențialitatea declarativă

De-a lungul celor șapte articole anterioare ale acestui ciclu am traversat straturi diferite ale aceleiași chestiuni. Dreptul transferurilor internaționale cu Schrems II. Ideea matematică a hash-ului criptografic care sigilează fiecare Cuaderno. Alegerea arhitecturală a kill switch-ului și capturarea instituțională care aproape întotdeauna îl însoțește. Mecanismul criptării end-to-end și întrebarea operativă despre locul unde se află cheile. Alinierea stimulentelor în funcție de modelul de afaceri. Identitatea criptografică autosuverană. Self-hosting-ul ca strategie proporțională. Fiecare articol s-a ocupat de un unghi. Acesta, ultimul din ciclu, le reunește într-un chestionar.

Distincția care merită reținută este simplă: există servicii a căror confidențialitate este arhitecturală și există servicii a căror confidențialitate este declarativă. Prima este încorporată în designul tehnic: anumite încălcări ale angajamentului de confidențialitate sunt tehnic dificile sau imposibile pentru că arhitectura nu le permite. A doua este depusă în textul notei legale: anumite încălcări ar fi sancționabile contractual dacă ar avea loc, dar tehnic nimic nu le împiedică. Cele două modele pot respecta RGPD; dar unul protejează prin construcție și celălalt protejează prin promisiune, iar diferența este operativ enormă.

Întrebările care urmează sunt concepute pentru a distinge un caz de celălalt. Nu sunt întrebări tehnice avansate. Sunt întrebările la care orice furnizor onest poate răspunde în documentația sa publică. Calitatea și precizia răspunsului spun la fel de mult despre produs cât și răspunsul însuși. Întrebările se grupează în șase straturi; merită să se pună toate înainte de a adopta serviciul pentru date sensibile, nu doar acelea pe care primul instinct le identifică.

Stratul 1: arhitectura

Să fixăm un termen înainte de a continua. Prin operator înțelegem compania care furnizează serviciul: entitatea care controlează serverele și software-ul, nu o persoană anume. Odată clarificat acest lucru, întrebarea arhitecturală fundamentală este: ce face operatorul cu conținutul dintre expeditor și destinatar? Există trei răspunsuri posibile și e bine să știi să le deosebești, fiindcă toate trei sunt uneori promovate cu un vocabular asemănător.

• Primul: conținutul trece printr-un server al operatorului în clar, unde operatorul îl poate citi chiar dacă promite să n-o facă.
• Al doilea: conținutul trece printr-un server al operatorului criptat, unde operatorul nu îl poate citi dacă cheile se află exclusiv pe dispozitivele utilizatorilor.
• Al treilea: conținutul nu trece prin niciun server al operatorului, pentru că nu există server al operatorului în acel flux concret.

Diferența dintre acestea trei nu este de grad: este de tip.

Întrebarea complementară —deja formulată în Cuaderno despre criptare— este: cine deține cheile criptografice care permit citirea conținutului? Dacă le deține utilizatorul și doar utilizatorul, criptarea este reală. Dacă le deține în plus și operatorul sub orice formă —chiar sub numele de «recuperare a contului» sau «sincronizare între dispozitive»—, criptarea este nominală. Întrebarea nu admite un răspuns intermediar onest.

Stratul 2: modelul de afaceri

Întrebarea despre modelul de afaceri contează la fel de mult ca întrebarea arhitecturală, și din același motiv substanțial: stimulentele produc, de-a lungul timpului, produse sistematic diferite chiar și cu scopuri declarate identice. Cum câștigă bani astăzi operatorul? O singură sursă, două, un amestec? Dacă finanțarea include publicitate sau monetizarea datelor, ce date se monetizează și pe ce bază juridică a RGPD se face? Acoperă scopul declarat în nota legală datele terților pe care profesionistul intenționează să le încredințeze serviciului?

Și întrebarea de ordinul al doilea, nu întotdeauna formulată: care este situația financiară a operatorului în perspectiva de trei sau cinci ani? O companie în faza de capital de risc operează sub presiuni diferite față de o companie cu rentabilitate stabilă. Schimbarea modelului de finanțare este, în mod repetat, momentul în care contractul implicit cu utilizatorii se rescrie fără negociere.

Stratul 3: jurisdicția

Pentru profesionistul european, întrebarea jurisdicției nu este retorică. În ce jurisdicție este înregistrat operatorul? În ce țară sunt fizic serverele care prelucrează datele? Răspunsul la cele două întrebări anterioare este același sau diferit, și dacă diferă, ce legislație se aplică? O regiune europeană operată de o companie americană nu este, în sensul Schrems II, un răspuns european: compania este supusă FISA 702 indiferent de locul unde se află serverele.

Întrebarea complementară operativă este: dacă ar sosi mâine un ordin de informații valid în jurisdicția operatorului cerând predarea datelor mele sau ale clienților mei, ce s-ar întâmpla? Dacă răspunsul onest începe cu «compania ar fi obligată să le predea», serviciul nu protejează împotriva acelui ordin oricât ar sugera publicitatea contrariul. Dacă răspunsul onest începe cu «compania nu le-ar putea preda pentru că nu le are în clar», serviciul chiar protejează; iar diferența depinde aproape în întregime de primele două straturi, nu de calitatea politicii de confidențialitate.

Stratul 4: operatorul și kill switch

Ce capacitate tehnică păstrează operatorul pentru a suspenda, bloca, șterge sau degrada serviciul de la distanță? Întrebarea nu este paranoică: este operativă. Platformele digitale au exercitat această capacitate în mod repetat în ultimii ani, uneori din proprie inițiativă, alteori sub ordinul guvernelor, alteori după schimbări de proprietate sau de politică. Dacă capacitatea există, merită să se știe în ce condiții declarate contractual se exercită și să se rezerve o marjă pentru condițiile nedeclarate pe care practica ultimilor ani le-a arătat la fel de relevante: ordin judecătoresc neașteptat, sancțiune internațională, schimbare de conducere corporativă, achiziție de către o entitate cu altă politică.

Întrebarea soră este cea a planului de continuitate: dacă operatorul ar exercita capacitatea împotriva profesionistului — din orice motiv, just sau nu —, ce timp de activitate ar rămâne disponibil, ce procedură de export al datelor există și către ce furnizor alternativ s-ar putea migra? Dacă răspunsul începe cu «n-ar trebui să se întâmple», nu este un răspuns operativ; este o promisiune.

Stratul 5: identitatea și accesul

Cine controlează acreditările de acces la serviciu? Dacă operatorul poate reseta accesul utilizatorului fără participarea utilizatorului — procedură numită de obicei «recuperarea contului» —, operatorul este, tehnic, custodele contului și îl poate, de asemenea, ceda celui care îl solicită prin procedura adecvată. Dacă operatorul nu poate reseta accesul pentru că identitatea se află criptografic pe dispozitivul utilizatorului, operatorul nu o poate nici ceda, nici măcar sub ordin. Cele două modalități sunt legitime în funcție de context; dar, încă o dată, sunt diferite și merită să se știe care anume se adoptă.

Ce se întâmplă cu datele profesionistului dacă profesionistul pierde accesul? Există mecanisme de recuperare — de cont, de fișier, de sesiune — care depind de operator? Sunt aceste mecanisme compatibile cu deontologia profesională a sectorului dacă operatorul este constrâns să le folosească?

Stratul 6: viitorul

Acest ultim strat este de obicei neglijat pentru că cere proiecție. Ce s-ar întâmpla dacă serviciul ar fi achiziționat de o altă companie? Aproape toate achizițiile aduc cu ele o revizuire a termenilor serviciului în lunile următoare. Ce s-ar întâmpla dacă cerințele de reglementare s-ar schimba? Dreptul european a crescut obligațiile de retragere și blocare din 2022, nu le-a redus. Ce s-ar întâmpla dacă operatorul ar dispărea? O parte semnificativă a serviciilor cloud nu are un plan de ieșire documentat pentru scenariul închiderii operatorului; profesionistul descoperă problema când nu mai e timp să o pregătească.

Există o formulare care merită reținută pentru acest strat: arhitecturile care depind mai puțin de operator sunt mai reziliente la schimbările operatorului. Self-hosting-ul în oricare dintre modalitățile sale, identitatea criptografică autosuverană, comunicațiile fără server la mijloc, toate acestea reduc suprafața de risc viitoare prin procedura de a reduce suprafața de dependență prezentă. Nu o elimină; o reduc.

Diferența dintre structură și promisiune

Dacă ar trebui să distilăm ciclul într-o singură frază, ar fi aceasta: răspunsurile structurale se mențin chiar dacă operatorul, administrația sau legislația se schimbă; răspunsurile prin promisiune se mențin atâta timp cât cel care promite poate și vrea să le mențină. Amândouă pot fi corecte în momentul adoptării. Doar unul dintre cele două se susține independent de trecerea timpului și de schimbarea împrejurărilor.

Asta nu înseamnă că fiecare profesionist trebuie să ceară răspunsuri structurale tuturor serviciilor pe care le adoptă. Proporționalitatea rămâne legitimă: o foaie de calcul pentru contabilitate internă nu are nevoie de același răspuns ca dosarul clinic al unui pacient. Înseamnă, da, că profesionalismul constă în a ști ce fel de răspuns s-a acceptat în fiecare caz și în a fi decis conștient că acel tip de răspuns este proporțional cu datul concret.

Chestionarul, ordonat

Douăsprezece întrebări concrete care sintetizează ciclul, ordonate astfel încât răspunsul la fiecare să informeze pe următoarea:

1. Trece conținutul printr-un server al operatorului? Dacă trece: în clar, criptat cu cheile operatorului sau criptat cu chei exclusive ale utilizatorului?
2. Dacă se invocă criptarea end-to-end, unde se află cheile criptografice? Cunoaște sau păstrează operatorul vreo parte din ele sub orice formă, inclusiv «recuperarea»?
3. Ce metadate generează și păstrează serviciul? Cât timp? Cui îi sunt vizibile?
4. Cum se finanțează operatorul? Dacă finanțarea include publicitate sau monetizarea datelor, acoperă scopul declarat datele terților încredințate de profesionist?
5. Care este situația financiară a operatorului în perspectiva de trei sau cinci ani? Există factori care sugerează o schimbare iminentă de model (listare la bursă în așteptare, rundă de finanțare pe terminate, achiziție probabilă)?
6. În ce jurisdicție este înregistrat operatorul? În ce țară sunt fizic serverele? Dacă diferă, ce legislație națională se aplică prelucrării?
7. Ce s-ar întâmpla dacă un ordin de informații valid în jurisdicția operatorului ar cere predarea datelor mele? Ar putea compania să-l îndeplinească tehnic?
8. Ce capacitate tehnică păstrează operatorul pentru a suspenda, bloca sau șterge serviciul? În ce condiții contractuale? În ce condiții necontractuale documentate istoric?
9. Ce plan de ieșire există dacă operatorul ar exercita această capacitate împotriva mea, just sau injust? Există o procedură documentată de export al datelor către un furnizor alternativ?
10. Cine controlează acreditările de acces? Poate operatorul să le reseteze fără participarea mea? Asta mă protejează sau mă expune?
11. Există o alternativă europeană, autogăzduită sau fără server la mijloc pentru această funcție concretă? Care este costul ei real, comparat cu riscul evaluat?
12. Dacă decizia de azi ar fi examinată peste cinci ani de un inspector, un auditor sau un client afectat de o breșă, ar fi alegerea actuală apărabilă cu argumentele disponibile azi sau ar necesita scuze pentru că nu s-au pus întrebări rezonabile?

Întrebările nu așteaptă răspunsuri perfecte. Așteaptă răspunsuri oneste, pe care operatorul onest știe să le dea și pe care operatorul mai puțin onest evită să le formuleze cu precizie. Diferența operativă dintre cele două tipuri de operator, o spunem fără dramatism, se percepe de obicei citind încet răspunsurile pe care le oferă voluntar, chiar înainte de a fi nevoie să se ceară mai mult.

---

Cu acest articol închidem al doilea ciclu al Cuadernos Lacre. Am început cu datoria editorială moștenită de la Schrems II și terminăm cu un chestionar operativ. Pe parcurs am traversat concepte — hash, criptare, identitate — și analize aplicate — kill switch, model de afaceri, self-hosting. Intenția editorială declarată a publicației nu a fost să copleșească cititorul cu lista exhaustivă a problemelor, ci să-i ofere instrumente pentru a distinge, în fața oricărui serviciu nou, ce fel de răspuns acceptă. Această distincție — între arhitectură și promisiune — este instrumentul. Restul fiecare profesionist îl va pune în slujba datelor pe care le consideră, în practica sa, demne de întrebare.