Autor Daniel Suciu

Acest material se adresează în special dezvoltatorilor din firmele mici, fără o structură organizatorică, funcții de suport dedicate sau o metodologie complexă in ajutor.

O să încep menționând că pentru a respecta cu adevărat principul de „Privacy by design and by default” pentru orice aplicție sau sistem not, trebuie avut în vedere scopul pentru care sunt folosite datele (personale), modul de prelucrare, de la acces, la prelucrările interne, stocare și distribuire precum și procesele operaționale, de operare, administrare și de suport, licențiere, actualizările aplicației, instruirea celor ce o operează și administrează…

Mai jos găsiți câteva exemple de cerințe sau doar bune practici, din experiența mea personală – de fost programator, tester, business analyst,  QA, admin, PM, manager… și acum consultant GDPR- care pot ajuta la dezvoltarea unei aplicații în acord cu aceste principii. Nu este o listă exhustivă și nici obligatorie, dar poate fi un punct de plecare pentru analiză. Evident ca lista poate fi mult mai lungă sau mai bine organizată. La final o să incerc să creez și să mențin o listă cu materialele mai formale pe aceasta temă, pe baza recomandărilor si sugestiilor primite.

Câteva considerații generale

• Atât GDPR-ul cât și recomandările specifice implică necesitatea demonstrării respectării acestor principii din faza de design considerând toata durata de viață a produsului (SLC) nu doar dezvoltarea, iar dezvoltarea ar fi indicat să conțină și partea de analiză, cerințe, design, testare… stiu, pare evident
• Trebuie să existe documentație – nu doar cea de produs (pentru useri și administrare/mentenanță) ci și pentru proiect/ development, incepând de la cerințe)
• Cerințele inițiale ale aplicației/serviciului trebuie să conțină referințe la principiile GDPR ce trebuie avute in vedere de la bun început (câteva articole din GDPR ce pot avea legătură și ar merita citite sunt 5,7,11, 12, 15-22, 25,32,35,44…)
• Trebuie să existe o trasabilitate pentru modul in care acestea sunt implementate in produs… sau proces, prin care să se poata demonstra ce funcțiune implementează o anumită cerință
• Ar fi bine să existe evidente ca este urmata o metodologie (incluzând toate activitatile de dezvoltare). Se acceptă și Agile și DevOps, dar nu varianta fară arhitectură/design și documentație…

Acum, mai la concret:

–          despre Baze de date

• Separarea informațiilor despre utilizatori de cele de business, eventual și cu criptarea celor ce pot identifica utilizatorii este utilă;
• Normalizarea datelor ajută atât la consisten,a datelor, cât și la minimizarea impactului in cazul breșelor de securitate. Posibilitatea de a utiliza datele ca întreg și a identifica subiecții scade;
• Normalizarea ajută și la implementarea unor măsuri de siguranță sau chiar de acces granular pentru anumite date considerate sensibile;
• Ar fi indicat să existe un Data dictionary , cu descrierea datelor – ajută la identificare și mapare și este util în definirea scopului acestora de la început și la demonstrarea atât a minimizării datelor cât și a limitării scopului;
• Stergerea și arhivarea automată a datelor, bazate pe anumite reguli, ar trebui avută in vedere din stadiul de design. Sigur va fi nevoie.

–          despre Managementul utilizatorilor și drepturilor

• Managementul utilizatorilor ar trebui facut pe baza de roluri, cu drepturi bine definite pentru fiecare rol , luând în cosiderare și datele, nu doar funcțiile;
• Managementul utilizatorilor și a drepturilor nu ar trebui limitat doar la utilizatorii finali, ci și la cei ce se vor ocupa de administrare, mentenanță…
• Definirea utilizatorilor de la nivel de sistem de operare, baze de date, aplicație și utilizarea lor de la bun inceput pot face posibile operațiile de mentenanță sau administrare fără drepturi de a acces la continuțul bazelor de date și pot limita riscul de a produce incidente din greșeală (acordâdu-se drepturi doar pentru nevoile funcțiilor respective);
• Folosind doar conturi de „root”/ „admin” pentru instalare, dezvoltare, administrare și mentenanță face inutile eforturile de „securizare” a aplicației;
• Nu mai pomenesc de „utilizatorii” la nivel de aplicatie/modul, de care nu se prea știe, care in multe aplicații folosesc tehnologii ce necesită numele de utilizator și parola in clar;
• Bănuiesc că schimbarea parolelor inițiale ale tuturor produselor COTS folosite este evidentă… nu că nu se uită de multe ori.

–          despre Corectitudinea datelor

• Validarea tranzacțiilor end2end pentru a preîntâmpina erorile sau inconsistențele în date datorită prelucrărilor incomplete;
• Ar trebui avute in vedere validări ale acestora (atât ca tip de date, valori căt și ca reguli de business, în relație cu alte date) începând de la colectare, pentru a preveni introducerile greșite;
• Baza de date ar trebui să conțină informatii atât despre vechimea datelor, cât și a ultimelor operații efectuate pe ele = problema este de a determina pentru ce entități este nevoie și pentru ce operațiuni.

–          despre Securitate

• Managementul sesiunilor e unul din aspectele de securitate ce poate preveni problemele;
• Autentificarea utilizatorilor folosind cele mai potrivite metode (acum au apărut multe dar tot username-ul și parola „rules”), dar măcar existența unor politici minime pentru parole (care ar fi chiar indicat să nu se pastreze in clar… evident, nu?) și utilizarea a doi factori pentru autentificare ar fi bune;
• Managementul licențelor produselor COTS folosite și a update-urilor acestora este un alt aspect de avut in vedere;
• Nu uitati cerintele de infrastructură (hardware, software, retea) necesare funcționării aplicației, care pot introduce vulnerabilități, oricât de securizată ar fi aplicația;
• Pentru administrare, pe lângă utilizarea conturilor dedicate, cu permisiuni specifice și limitate, ar fi indicat să fie identificate modalități de lucru la distanță printr-un canal sigur – aspect care mi se pare cel mai neglijat;
• Auditarea operațiilor efectuate de clienți asupra datelor este un factor ce permite o analiză mult mai ușoară in caz de breșe de securitate, plus responsabilizarea celor ce utilizează aplicația. Pentru cei ce nu fac diferența, spre deosebire de log-urile tehnice, auditarea este un proces similar dar informațiile stocate sunt altele, de genul ce utilizator a efecutuat o anumită operație și când. Salvarea acestor informații la nivel de bază de date face utilizarea lor mai ușoara, dar nu este obligatorie.

–          Back-up & restore

• In primul rând să nu se uite de procesul de restaurare, nu doar de back-up… ceea ce in general (macar 99%) nu inseamnă doar să pui baza de date veche in locul celei corupte, pierdute…;
• In cel de-al doilea rând, back-upul ar trebui să nu fie limitat la date, ci și la aplicatie, fișierele de configurare, log-uri… pentru a permite restaurarea SERVICIILOR in caz de probleme și analiza incidentelor atunci cândva fi cazul (sigur va fi);
• Combinarea mai multor tipuri de back-up pentru diferite tipuri de informații este o alternativă de considerat, de exemplu back-ul frecvent al log-urilor permite obținerea datelor despre tranzacțiile efectuate de la ultimul back-up al datelor (care de multe ori nu se poate face foarte des);
• Daca datele sunt distribuite sau unele pot fi salvate in dispozitivele clientilor, o metoda de back-up pentru aceasta trebuie luată in considerare.

Alte chestii specifice GDPR

care nu tin neapărat de bune practici generale in dezvolatarea, administrarea și operarea unei aplicatii:

• Introducerea in aplicație a functiilor ce permit exercitarea drepturilor persoanelor vizate, accesul la informatii (istoricul datelr și tranzactiilor), actualizarea informatiilor, exportul datelor, stergerea datelor- și chiar a contului;
• Cel mai delicat drept este cel de restrictionare a prelucrării, in care datele trebuie marcate ca restricționate – nu șterse, dar să nu se permita nicio prelucrare. Atentie, accesul la date este o prelucrare. Implementarea drepturilor de acces la date cât mai granular face mai usoara implementarea – datele pentru un anumit client marcat nu vor avea nici dreptul de „view”, permițând doar accesul administratorului pentru taskurile de mentenanță;
• Pentru a ușura exercitarea drepturilor, sau obținerea consimțământului, acolo unde este nevoie, o metodă ar fi utilizarea unor soluții dedicate, sau introducerea acestora in functionalitățile aplicației, la nivelul customizării preferințelor conturilor, care oricum există în majoritatea aplicațiilor;
• Un amănunt important este obligativitatea ca retragerea unui consimțământ trebuie să fie la fel de ușoară ca acordarea lui. Pentru aceasta pozitionarea celor două opțiuni în același loc este o metoda bună de a rezolva problema;
• A nu se uita că toate operațiile de exercitare ale drepturilor clienților, obținerea și retragerea consimțământului, obiecțiile la prelucrare… trebuie să fie salvate pentru a le putea demonstra oricând.

Alte matriale utile

GDPR explicitat (9): Data protection by design and by default – de la Cloudmania

THE CNIL’S GUIDES – 2018 EDITION- SECURITY OF PERSONAL DATA  – de la CNIL –autoritatea Franceză in domeniu ( document în Engleză)

Software development with Data Protection by Design and by Default – de la Datatilsynet

Notă: materialele au fost primite după redactarea articolului, și conțin informații suplimentare utile, ce nu au fost adresate în acest material

Despre autor: Daniel SUCIU este specialist în managementul proceselor, managementul schimbării, managementul riscului, auditul intern, guvernanța și administrarea datelor, dezvoltarea de software, operarea și suportul IT, securitatea informațiilor dar și managementul proiectelor și al echipelor crossfunționale, cu rezultate măsurabile la intersecția sistemelor, tehnologiei, proceselor, oamenilor și datelor. 30 de ani de experiențe de lucru între IT / tehnologie si echipele de business, între clienți, parteneri / furnizori, angajați și conducere. Nu în ultimul rând, certificat ca ofițer cu protecția datelor, fiind implicat în conformarea la GDPR a mai multor organizații, din diferite domenii: învățământ, ONG, turism, medical, servicii IT, afaceri sau comerț online.