Acasă/Metode

Aplicații · Conformitate

Cum răspunzi la chestionarele de confidențialitate, GDPR și securitate pentru aplicațiile din marketplace-uri

Fiecare marketplace de aplicații întreabă ce date atinge aplicația, unde ajung, cine le mai prelucrează și ce le protejează. Răspundem la toate formularele dintr-o singură hartă de date per aplicație, susținem fiecare „Da” cu o pagină publică sau cu un contract și tratăm un „Nu” care blochează aprobarea ca pe un motiv să construim, nu să reformulăm.

Actualizat 2026-10-11

Ce întreabă de fapt chestionarele

Ca să răspunzi la un chestionar de confidențialitate sau de securitate dintr-un marketplace, notează întâi, pentru fiecare aplicație, ce date ale utilizatorilor citește, unde le păstrează și ce iese din platformă și către cine. Apoi completează fiecare formular din acea evidență și publică documentele care decurg din ea: politica de confidențialitate, o pagină de securitate și, dacă ajung la tine date personale, un acord de prelucrare a datelor. Toate formularele verifică, de fapt, dacă declarațiile tale se potrivesc cu ce face codul.

Un acord de prelucrare a datelor (DPA, din engleză) este contractul cerut de articolul 28 din GDPR între operator, clientul care decide de ce se prelucrează datele personale, și persoana împuternicită, furnizorul care le prelucrează în numele lui. Fără el, clientul încalcă legea, așa că juriștii unui cumpărător din UE nu aprobă instalarea.

Primul pas: harta datelor pentru fiecare aplicație, pe grupe

1. Descrie ce face codul, nu ce îți amintești. Listăm scope-urile cerute, ce se păstrează și unde și fiecare cerere externă, din manifest și din cod. Un URL de logo în manifest e o cerere externă; un server cu cache pe disc stochează date.

2. Grupează aplicațiile după setul de răspunsuri. Aplicațiile noastre Forge intră în trei grupe: cele care nu stochează și nu trimit nimic, cele care stochează doar în spațiul platformei și aplicațiile AI care trimit promptul utilizatorului la un furnizor de modele. Grupa AI răspunde „Da” la prelucrarea datelor în afara platformei, pentru că promptul scris de utilizator este conținutul lui; a-l redefini ca să iasă un formular mai curat ar fi necinstit.

3. Numește lanțul de prelucrare. Clientul este operatorul, firma noastră este persoana împuternicită, iar platforma și furnizorul modelului AI sunt subcontractanți. Transferurile în afara Spațiului Economic European (SEE) sunt acoperite de DPA-ul furnizorului de model, care include Clauzele Contractuale Standard ale UE (Modulul 2, Decizia de punere în aplicare (UE) 2021/914) în condițiile comerciale. Acel contract existent face ca „Da” la întrebarea despre transfer să fie adevărat.

Un DPA care se aplică singur, pentru fiecare aplicație

Publicăm câte o pagină DPA pentru fiecare aplicație, în două variante: aplicațiile AI numesc furnizorul modelului ca subcontractant, iar cele fără trafic extern spun că la noi nu ajung deloc date personale. Fiecare DPA se aplică singur: este inclus în termenii de utilizare și intră în vigoare la instalare, fără semnătură, cu oferta de a-l contrasemna la cerere.

Un DPA este o listă de obligații, așa că am scris doar ce putem respecta: prelucrăm datele numai pe baza instrucțiunilor documentate ale clientului; notificăm o încălcare a securității datelor în 48 de ore de când aflăm de ea; ștergem sau returnăm datele în 30 de zile de la dezinstalare sau de la o cerere scrisă; anunțăm cu 30 de zile înainte orice schimbare de subcontractant, cu drept de opoziție; acceptăm un audit cel mult o dată pe an, pe costul clientului; ajutăm la cererile persoanelor vizate și la obligațiile din articolele 32-36.

Paginile spun și ce nu avem: SOC 2, ISO 27001, test de penetrare independent sau responsabil cu protecția datelor, pe care articolul 37 nu ni-l cere. O absență spusă clar se citește mai ușor decât o formulare vagă.

Atlassian: tabul Privacy & Security și încă două formulare

Fiecare listare din Atlassian Marketplace are un tab Privacy & Security. Pentru o aplicație AI, „Da” la prelucrarea în afara Atlassian deschide patru câmpuri obligatorii ascunse, fiecare apărând abia după răspunsul precedent: tipurile de date accesate, tehnicile de protecție a confidențialității, dacă datele ies din SEE și ce mecanism de transfer se aplică. Dacă te declari persoană împuternicită, apar tipurile de date și întrebarea dacă oferi un DPA.

Din clipa în care declari prelucrare în afara Atlassian, linkul către o politică de securitate publică devine obligatoriu. Pagina noastră de securitate pentru fiecare aplicație spune unde rulează, ce scope-uri are, cum autorizează, ce iese din Atlassian și cum se raportează o vulnerabilitate, cu angajamentul de a confirma în 2 zile lucrătoare și de a repara, sau de a da un plan, în 10.

Atlassian are trei formulare de securitate: acest tab, chestionarul de securitate Forge și un chestionar pentru parteneri, despre firmă. Cel pentru parteneri se deschide dintr-un buton de pe tichetul de review al unei aplicații. În cele două chestionare am răspuns la 33 de întrebări.

Shopify: nivelurile datelor protejate ale clienților

Shopify împarte aplicațiile după datele protejate ale clienților (PCD, din engleză). O aplicație care folosește date de client fără câmpurile de identificare este la nivelul 1; una care păstrează numele, emailul, telefonul sau adresa clientului e la nivelul 2. Majoritatea aplicațiilor noastre Shopify sunt la nivelul 0 sau 1 și au trecut ușor; precedentul nu ține pentru o aplicație care păstrează destinatarul unui colet.

În cererea PCD declari întâi câmpurile pe care le păstrezi; declararea în plus pică la fel de sigur ca cea în minus, așa că verifică modelul și fiecare cale de intrare a datelor, inclusiv webhook-urile. Nivelul 2 aduce apoi 16 întrebări despre protecția datelor, care sunt declarații juridice. Criptarea datelor stocate, backup-urile criptate și o politică de răspuns la incidente sunt obligatorii, iar un „Nu” înseamnă că aplicația nu poate fi lansată.

Pentru aplicația noastră de nivel 2, drumul cinstit a fost cel ingineresc. Am criptat la nivel de aplicație coloanele de identificare cu AES-256-GCM și am adăugat indecși orbi, valori HMAC cu cheie ale telefonului și emailului normalizate, ca să meargă căutarea exactă; căutarea după un fragment din numele criptat nu are cum să meargă, așa că am scos-o. Backup-urile nocturne criptate, o pagină de confidențialitate corectă și o politică scrisă de răspuns la incidente au făcut adevărate celelalte răspunsuri. Alegerea distribuției publice nu se poate anula, iar unele verificări pornesc abia după acel clic.

Google Workspace: verificarea OAuth și verificarea de branding

Un add-on Google Workspace care cere orice scope OAuth sensibil trebuie să treacă de verificarea OAuth, separată de review-ul listării, înainte ca Marketplace-ul să-l aprobe. Ordinea noastră: scope-uri identice în trei locuri (manifestul Apps Script, configurația Marketplace SDK și ecranul de consimțământ OAuth), apoi branding verificat și publicat, apoi verificarea accesului la date și abia la final trimiterea în Marketplace.

Verificarea accesului la date cere o justificare de cel mult 1000 de caractere pe proiect și un link YouTube către un video care arată folosirea fiecărui scope; proprietarul proiectului nu vede ecranul de aplicație neverificată, așa că filmăm o instalare din Marketplace cu un cont din afară. Din cele trei respingeri la verificare, două au fost pe politica de confidențialitate, nu pe cod: nu descria mecanismele de protecție a datelor și nu spunea cu cine sunt partajate datele Google ale utilizatorului. Să pomenești terțul în treacăt nu ajunge; evaluatorii caută o secțiune dedicată, care numește destinatarul, spune ce se trimite și îi exclude pe ceilalți.

Verificarea de branding e separată și fragilă. Redenumirea ecranului de consimțământ o resetează în tăcere; un rezultat pozitiv nu apare utilizatorilor până nu îl publici și expiră după 7 zile. Un logo din 15 a fost respins: un motiv generic nu ne identifica marca, iar un semn care spune ce face aplicația a trecut din prima. Un audit a găsit și 5 din 11 add-on-uri publicate fără logo pe ecranul de consimțământ.

O capcană de consimțământ a ajuns la utilizatori: ecranul nostru de autorizare dădea propriul URL, fără indiciu de cont, așa că oamenii conectați la mai multe conturi Google ajungeau pe o pagină care îi invita să ceară acces la scriptul însuși. În două zile am primit 12 cereri de la 7 utilizatori, pe 5 aplicații. Reparația a fost să-l lăsăm pe Google să dea URL-ul legat de cont.

Unde am greșit

Primele noastre justificări pentru accesul la date sunau bine și conțineau afirmații contrazise de cod: că nimic nu iese din contul utilizatorului, la o aplicație care trimite email; că nu se stochează nimic, pe un server care pune în cache pe disc. Le-a prins un audit adversarial care a citit codul ca un evaluator. Acum textele finale sunt versionate și refolosite, nu rescrise din memorie.

La început am răspuns „Nu” în tabul Atlassian la întrebarea despre DPA, pentru că nu aveam unul. Era cinstit și bloca vânzarea; DPA-ul scris l-a făcut „Da” pentru 11 aplicații AI.

Am tratat un formular salvat ca pe unul trimis: tabul Atlassian spunea că ciorna e salvată, dar cât timp aplicațiile erau în review nu exista nicio acțiune de trimitere. Acum lipim răspunsurile și în tichetul de review. Iar reparația indiciului de cont am raportat-o ca făcută când exista doar local, și add-on-urile au rămas stricate încă o zi.

Limite

Metoda ține declarațiile în acord cu codul. Nu este consultanță juridică, iar o aplicație cu date de sănătate, financiare sau despre copii are nevoie de un avocat. Nu este nici certificare. Unele comportamente descrise sunt ciudățenii observate de noi, nu reguli documentate, iar formularele se schimbă.

Dacă o aplicație include un model generativ, citește devreme termenii furnizorului despre minori: termenii Google pentru serviciile de AI generativ interzic folosirea lor într-un serviciu adresat persoanelor sub 18 ani sau probabil accesat de acestea, fără excepții nici cu acordul părinților.

Listă de verificare

Înainte de orice formular: harta datelor din cod pentru fiecare aplicație; lanțul de prelucrare numit; o politică de confidențialitate cu secțiuni despre protecție, partajare și antrenarea AI; o pagină de securitate și, dacă ajung la tine date personale, un DPA care se aplică singur.

Pe platforme: la Atlassian, tabul completat pe grupe, ambele chestionare, răspunsurile lipite și în tichet; la Shopify, câmpurile PCD potrivite cu modelul și webhook-urile, fiecare control cerut real; la Google, scope-uri identice în trei locuri, branding verificat, publicat și reverificat după orice redenumire.

Întrebări și răspunsuri

Ce este un DPA care se aplică singur pentru o aplicație din marketplace?

Este un acord de prelucrare a datelor inclus în termenii de utilizare ai aplicației, care intră în vigoare când clientul instalează aplicația, fără semnătură. Păstrează obligațiile din articolul 28 GDPR: prelucrare doar pe baza instrucțiunilor documentate, notificarea încălcărilor de securitate, ștergerea sau returnarea datelor după dezinstalare, anunț înainte de schimbarea subcontractanților și drept de audit. Oferta de contrasemnare la cerere ajută departamentele juridice care vor o copie semnată.

Ce aplicații Shopify au nevoie de criptarea datelor stocate pentru datele protejate ale clienților?

Aplicațiile de nivelul 2, adică cele care păstrează numele, emailul, telefonul sau adresa clientului. Pentru nivelul 2, întrebările Shopify despre protecția datelor cer criptarea datelor stocate, backup-uri criptate și o politică de răspuns la incidente, iar un „Nu” blochează aprobarea. Aplicațiile care folosesc date de client fără aceste câmpuri de identificare sunt la nivelul 1. Verifică ce păstrează efectiv baza de date și webhook-urile înainte să declari nivelul.

De ce mi-a respins Google add-on-ul Workspace pentru lipsa verificării OAuth?

Pentru că add-on-ul cere cel puțin un scope OAuth sensibil sau restricționat și nu a trecut de verificarea OAuth, care e separată de review-ul listării. Fă scope-urile identice în manifestul Apps Script, în Marketplace SDK și pe ecranul de consimțământ, verifică și publică brandingul, trimite verificarea accesului la date cu o justificare scrisă și un video pe YouTube și abia apoi trimite add-on-ul în Marketplace.

De ce nu mai este verificat brandingul meu OAuth la Google?

Orice schimbare în configurația ecranului de consimțământ OAuth, inclusiv o redenumire, resetează verificarea de branding, iar Google nu trimite niciun email; starea apare doar în Verification Center. În plus, un branding verificat trebuie publicat separat și expiră după 7 zile dacă nu e publicat. Reverifică și republică brandingul după fiecare schimbare a ecranului de consimțământ.

Ce întreabă tabul Privacy & Security de la Atlassian o aplicație AI?

Dacă aplicația trimite date ale utilizatorilor, de exemplu promptul scris de aceștia, în afara Atlassian, răspunsul „Da” deschide câmpuri obligatorii ascunse: tipurile de date accesate, tehnicile de protecție a confidențialității, dacă datele ies din SEE și ce mecanism de transfer le acoperă. Dacă te declari persoană împuternicită, apar tipurile de date și întrebarea despre DPA, iar linkul către o politică de securitate publică devine obligatoriu.

Toate metodele