În spatele fiecărui site live există și câteva copii mai discrete. Un dezvoltator rulează una pe propriul calculator ca să construiască o funcționalitate nouă. Un mediu de staging găzduiește următoarea lansare, ca să poată fi verificată înainte să o vadă altcineva. În aceste copii se face munca propriu-zisă, iar ca să fie utile, ele trebuie să semene cu site-ul real: același cod, aceeași structură, același tip de conținut. De aici, o întrebare pe care majoritatea proprietarilor de site-uri nu au avut niciodată motiv să și-o pună, dar la care ar trebui să știe să răspundă: când site-ul tău e copiat pentru dezvoltare, ce se întâmplă cu datele personale ale clienților tăi?
E o întrebare legitimă, pentru că o bază de date de producție e plină de oameni. Nume și adrese de e-mail din formularele de contact, istoricul comenzilor, abonări la newsletter, conturi de utilizator. Site-ul live le păzește pe toate cu mai multe straturi de siguranță. O copie pe un laptop, sau într-un mediu de test care există doar ca să poți încerca lucruri în voie, nu se bucură de la sine de aceeași protecție, decât dacă cineva decide că trebuie. Noi am decis că trebuie și, mai important, am construit sistemul astfel încât nimeni să nu mai trebuiască să țină minte asta.
Prin copii se scurg datele, pe tăcute
Iată tiparul incomod, spus fără dramatism: datele personale sunt rareori gestionate greșit pe site-ul live, unde toată lumea e atentă. Riscul se concentrează în copii, unde nu e nimeni atent. Un export al bazei de date făcut pentru depanare și uitat într-un folder de descărcări. Un mediu de test cu adrese reale de clienți și o parolă de acces pe care o știe toată echipa. Nimic din toate acestea nu implică rea intenție. E muncă obișnuită, făcută sub presiunea termenelor, cu date care s-au nimerit să vină la pachet.
Răspunsul tradițional e o regulă: ai grijă cu datele de producție. Noi nu punem mare preț pe reguli ca primă linie de apărare, nu pentru că oamenii ar fi neglijenți, ci pentru că regulile le cer tuturor să fie atenți de fiecare dată, la nesfârșit, iar "de fiecare dată" înseamnă de foarte multe ori. Răspunsul mai bun e să faci din calea sigură singura cale, astfel încât grija să nu mai fie un act zilnic de disciplină, ci o proprietate a sistemului. Asta înțelegem prin confidențialitate prin construcție.
Curățate înainte să ajungă
Pe platforma noastră de găzduire administrată, când o copie a bazei de date e adusă din producție în orice mediu din afara producției, datele personale sunt curățate chiar în timpul transferului. Numele, adresele de e-mail, numerele de telefon și celelalte câmpuri personale sunt înlocuite cu substitute realiste înainte ca datele să ajungă acolo unde lucrează un dezvoltator. Nu e un pas separat de curățenie pe care îl rulează cineva după aceea, dacă își aduce aminte. E integrat în singura cale pe care o parcurg datele, așa că nu există niciun scenariu de lucru în care date personale reale să ajungă din greșeală pe un laptop.
Copia curățată păstrează tot ce e cu adevărat nevoie la dezvoltare. Structura e identică, volumul e realist, conținutul e real, iar cazurile-limită care ies la iveală doar pe date cu forma celor din producție ies în continuare la iveală. Ce nu îi trebuie niciodată unui dezvoltator e identitatea adevărată din spatele rândului patru mii, așa că exact asta lipsește din copie. Site-ul de pe staging arată și se comportă ca cel live în toate privințele care contează, doar că oamenii din baza de date live pur și simplu nu sunt în el.
Staging-ul nu poate trimite e-mailuri absolut nimănui
Datele stocate sunt jumătate din poveste. Cealaltă jumătate e ce ar putea face un mediu de test, iar incidentul clasic sună așa: un site copiat mai conține pe undeva adrese reale, un dezvoltator testează un flux de notificări, iar sistemul trimite conștiincios e-mailuri cât se poate de reale unor oameni cât se poate de reali, despre lucruri care nu s-au întâmplat. O resetare de parolă pe care nu a cerut-o nimeni. O confirmare pentru o comandă care nu există. Pentru clientul care le primește e derutant în cel mai bun caz și alarmant în cel mai rău, și e complet evitabil.
Așa că prevenim asta sub nivelul aplicației, acolo unde chiar ține. Pe platforma noastră, mediile din afara producției nu au cum, fizic, să livreze e-mail în exterior; trimiterea e blocată la nivelul mediului, punct. Tot ce încearcă site-ul să trimită ajunge în schimb într-un colector de e-mailuri, unde echipa poate deschide fiecare mesaj, îi poate verifica conținutul și formatarea și poate confirma că fluxul se comportă corect, fără ca nimic să iasă din mediu. Fii atent la felul în care e formulată garanția. Ea nu spune că avem grijă să nu trimitem e-mailuri clienților de pe staging. Spune că staging-ul nu poate trimite e-mailuri clienților, ceea ce e o afirmație mult mai puternică, iar datorită curățării nici măcar adresele nu mai sunt acolo, deci nu ar avea cui trimite. Două straturi independente, care ar trebui să cedeze amândouă înainte ca un om real să fie afectat, și niciunul nu depinde de memoria cuiva.
Ce înseamnă asta pentru conformitatea ta cu GDPR
Dacă organizația ta operează în Europa, porți responsabilitatea pentru datele personale pe care le colectează site-ul tău, iar responsabilitatea asta însoțește datele în fiecare copie. Când cineva întreabă unde stau datele personale și cine are acces la ele, un răspuns care se termină cu "plus un număr necunoscut de copii ale bazei de date pe calculatoarele dezvoltatorilor" nu e un răspuns pe care să-l dai cu plăcere.
Cu construcția de mai sus, răspunsul sincer devine scurt: datele personale stau în producție și nu ajung în dezvoltare sau în staging, pentru că procesul de copiere le elimină pe drum. Mai puține locuri care dețin date personale înseamnă mai puțin de securizat, mai puțin de inventariat și mai puține griji în scenariile pe care nimănui nu îi place să și le imagineze, cum ar fi un laptop furat. Nu oferim consultanță juridică, iar o protecție bună a datelor nu se rezumă la medii. Dar mediile sunt un loc unde poți reduce riscul real, structural, iar odată ce o faci, orice altă discuție despre datele tale devine mai ușoară și mai scurtă.
Libertatea e celălalt beneficiu
Ar fi ușor să trecem toate astea la capitolul precauție, dar experiența de zi cu zi e mai degrabă opusul. Barierele de siguranță, puse cum trebuie, aduc viteză. Un dezvoltator care știe că mediul nu poate trimite e-mailuri reale și nu conține oameni reali poate testa fără nicio reținere: să declanșeze fiecare notificare, să ruleze întregul flux de înregistrare, să strice lucruri intenționat ca să vadă cum cedează. Nimeni nu mai stă pe gânduri înainte să încerce ceva, pentru că cel mai rău scenariu e ținut sub control prin construcție.
Ezitarea costă. Munca încetinește când fiecare experiment începe cu "stai, e sigur aici?". Când întrebarea asta dispare, nu doar că îți protejezi clienții: munca pe site-ul tău devine mai rapidă și mai temeinică, pentru că testarea temeinică nu mai vine cu riscuri. Câștigă toată lumea, dintr-o dată, și ăsta e semnul unei garanții bine plasate.
O întrebare pe care merită să o pui oricui îți administrează site-ul
Nu trebuie să auditezi infrastructura nimănui ca să ridici standardul. Două întrebări simple fac aproape toată treaba. Când site-ul meu e copiat pentru dezvoltare, se elimină datele personale, și se întâmplă automat sau trebuie să țină cineva minte? Și poate un mediu de test să trimită e-mailuri unor oameni reali, sau e imposibil din construcție? Răspunsurile pe care le vrei sunt "automat" și "imposibil", iar cuvântul de urmărit în ambele nu e "grijă", ci "construcție". Grija e o calitate frumoasă într-o echipă. Doar că nu de ea ar trebui să depindă datele clienților tăi.