Data driven cloud selection - selecția serviciilor de cloud de către instituțiile publice

Securitatea datelor și serviciilor electronice poate fi văzută din două perspective. Cea a instituției publice titulară a datelor și cea a industriei furnizorilor de servicii de cloud. Despre situația încurcată a furnizorilor am scris deja și voi concluziona în postarea următoare, azi focusul va fi pe instituția publică.

Puțină filozofie

Am folosit mai sus expresia „titularul datelor” care poate fi înțeleasă diferit de multe persoane, inclusiv în acest HG la Art.45 există o regretabilă confuzie.

• „titular” înseamnă o persoană căreia i s-a încredințat, de către altcineva, o funcție/sarcină/drept.
• „titularul datelor” este entitatea căreia i s-a acordat dreptul de proprietate/sarcina de administrare a respectivelor date.

O să întrebați cum este cu persoanele fizice și GDPR.

O persoană fizică este, vis-a-vis de datele sale, o „persoană vizată” care are drepturile stabilite de GDPR. Aceste drepturi sunt numeroase dar nu coincid cu dreptul de proprietate. Ele se pot încadra în două mari categorii: dreptul de a fi informat și dreptul de a se opune, în conjunctură cu titularul datelor care este „operator de date” și are inițiativa și decizia în privința prelucrării lor.

Cum ajunge o instituție publică să fie titular de date?

Prin normă legală care reglementează funcționarea instituției. Nivelul acestei norme este un punct de divergență în abordările actuale. Abordarea europeană, prin GDPR și acțiunile ANSPDCP, îmbrățișează normele la nivel de HG și acceptă mărunțișuri la nivel de Ordin. Curtea Constituțională a arătat o viziune prin care doar prin lege se pot împuternicii instituțiile să instituie mari prelucrări de date.

Însă nespecialiștii consideră că datele sunt „ale statului” de unde vin și cererile ca datele să circule fără a mai fi solicitate formal, de la cetățeni sau interinstituțional.

Discuția are și relevanță practică

Cine consideră că datele sunt „ale statului” va ajunge, printr-un raționament logic, să susțină că statul poate împărți responsabilitățile aferente între instituții după cum consideră potrivit. Astfel, în contextul cloudului comercial, cei trei, ADR, STS, SRI, pot și vor fi operatori de date cu decizii independente.

Cine consideră că datele sunt „ale instituției” va susține controlul maximal al respectivei instituții și va ajunge la formula în care ADR este furnizor de servicii de cloud privat iar STS și SRI împuterniciții acestuia.

Se aplică zicala cu prăjitura pe care nu poți să și o mănânci dar să și o ai. Autarhismul instituțional omoară interoperabilitatea și productivitatea.

Să revenim la HG

Pentru că scopul acestei postări este cadrul de management şi stocare a datelor și nu întregul GDPR voi anticipa spunând că instituția utilizatoare de cloud este operator de date, ceilalți sunt împuterniciți, și totul funcționează corect cât timp instituția decide ce i se spune că trebuie să decidă.

Nu este o soluție inovativă, cel mai recent exemplu este Legea 5G în care primul-ministru decide ce-i spune să decidă CSAT. Acest gen de soluție are avantaje certe: pe deoparte răspunde formal solicitărilor publice ca instituțiile să fie operatori de date iar pe de altă parte deciziile propriu-zise nu pot fi atacate în instanță. (vom vedea concret acest lucru cu ocazia procesului Nokia vs gov.ro)

Vicii de formă

Redactarea HG-ului este evident neglijentă. Probabil în urma divergenței cu STS, care aspira la statutul de FSC (furnizor de servicii de cloud) în multe articole apare FSC în loc de ADR însă, prin faptul că tot FSC este și furnizorul de cloud comercial, rezultă un mare număr de nonsensuri. Corect ar fi să avem scris:

• ADR ca „agregator de servicii de cloud” (noțiune definită dar care nu mai apare ulterior în HG) pentru toate prevederile legate de Platforma de Cloud Guvernamental
• ADR ca „furnizor de servicii de cloud” FSC în toate prevederile legate de Cloud Privat Guvernamental
• FSC în toate prevederile legate de cloudurile comerciale
• USCPG (nedefinit) pentru utilizatorii cloudului privat guvernamental și USC pentru utilizatorii cloudului comercial, o diferențiere obligatorie având în vedere diferențele naturale dintre ADR respectiv FSC-ul comercial

În mod normal, în aceste condiții, nu ar trebui emisă o opinie asupra acestui text.

Mă voi concentra totuși asupra :

CAPITOLUL III - Cadrul de management şi stocare a datelor în Platformă, inclusiv stabilirea categoriilor de date prelucrate în Platformă şi găzduite de Cloudul privat guvernamental

Înțeleg că acest capitol este unul dintre cele 7 în 1 HG-uri însă, cu atât mai mult, este vizibilă lipsa de convergență cu alte părți din HG, în special cu Art.17 și CAPITOLUL IV - Planul pentru migrarea și integrarea în CPG.

Să începem cu începutul ..... titlul capitolului.

Care este rostul și impactul menționării CPG ? Sugerează cumva că partea comercială din Platformă poate prelucra date dar acestea pot fi stocate doar în CPG ?

În cuprinsul lui, capitolul este foarte relaxat, conține doar la Art. 29 (2) obligația ca datele către CPG să fie transportate doar pe rețele operate de STS.

USC sunt îndemnate să-și analizeze datele și serviciile, să le catalogheze pe niveluri de risc.

Mai ciudată este prevederea:

Art.31 (2) FSC stabilește criteriile și cerințele minime pentru asigurarea securității și confidențialității datelor prevăzute în fiecare nivel menționat la alin (1).

Practic scrie că furnizorul de cloud, inclusiv cel comercial, stabilește cerințele minime pentru serviciile care vor fi cumpărate de la el. De principiu asta este datoria operatorului nu împuternicitului iar în practică o eroare a sa poate duce fie spre insecuritate fie spre servicii inutil de scumpe. Este relevant de spus că nu este clar momentul acestei decizii, este posibil, din analiza Art.17, să fie după contractarea furnizorului la fel cum pare să sugereze și Art.38 (1).

Iar:

Art.31 (3) Auditul de securitate al FSC stabilește și actualizează o politică și proceduri pentru efectuarea evaluărilor de securitate ale sistemului informatic și ale auditurilor activelor critice, ținând cont de analiza riscurilor actualizată periodic.

este cu atât mai neclar cu cât îl citești mai intens. Cine face menționatul audit ? Furnizorul sau beneficiarul? Care este subiectul auditului? Serviciul furnizorului sau întreaga aplicație de cloud? Se poate interpreta că beneficiarul își ține lista de date și servicii la zi, inclusiv nivelurile de risc asociate, iar furnizorul comercial de cloud are obligația de a audita aplicația de cloud a  instituției publice din perspectiva satisfacerii criteriilor minimale asociate riscului declarat. Mai ales că, conform Art. 10 a), cloudurile comerciale au auditor numai din perspectiva conectării lor cu CPG, iar Art.17 (6) cu privire la contractul dintre FSC și utilizator ne spune că acesta trebuie să conțină și: d. principiile efectuării sau comandării unui audit de către părți asupra modului de implementare a acordului;

Apropo de cele 3 niveluri de risc definite de Art. 31

Nivel 3 - nivel ridicat aplicat în cazul datelor pentru care protecția este stabilită prin lege și pentru care pierderea confidențialității, integrității sau disponibilității datelor sau a aplicațiilor are un impact negativ semnificativ asupra activității, imaginii și siguranței autorităților și instituțiilor publice.

În această definiție se încadrează cu brio orice dată personală însă Art.13 (3) d) din OUG permite explicit prelucrarea datelor personale în cloudul comercial. În discuțiile anterioare, în grupul de lucru de la MCID, s-a înțeles că aceste niveluri sunt baza alegerii tipului de cloud: comercial sau privat. În aceste condiții îmi este foarte greu să-mi imaginez care sunt datele care pot sta doar în CPG și cum vom reuși să avem un ROI pentru cei 500 mil euro.

Aparent instituțiile publice au deplină libertate să aleagă ce cloud poftesc !

Insă ...

Art.17 (4) În vederea contractării unui serviciu de cloud din cadrul Platformei, furnizat de un FSC public sau privat, USC se adresează ADR și stabilește cu acesta, în baza unei analize de business prealabile, tipul de serviciu cloud pe care USC poate să-l contracteze, precum și FSC selectat din marketplace.

Iar dacă este vorba de migrare, ADR ia toate deciziile conform Cap. IV.

Aici ar fi două observații de făcut:

1. migrare în cloud înseamnă, pentru mine, un serviciu deja digital. Un serviciu pe hârtie este transformat și, prin urmare, s-ar putea ca întreg capitolul să nu i se aplice.
2. întreg Capitolul IV se referă la migrarea în CPG. Ce se întâmplă în cazul voinței de a migra în cloudul comercial ? Mai există sprijin din partea ADR, inclusiv din cele 100 mil euro ?

Mai există și Capitolul V – criterii pentru aplicații „SaaS găzduite în Platformă, prin intermediul unui marketplace” însă acesta nu este de mare ajutor pentru aplicațiile bazate pe IaaS sau PaaS , pentru aceste servicii, datorită  Art.3 (8) din OUG, neexistând în marketplace, este greu de înțeles cum s-ar aplica Art.17 (4).

Concluzie

Aparent instituțiile publice au cea mai mare libertate în alegerea serviciilor de cloud. S-a dorit atât de multă libertate încât s-a omis, spre exemplu, din HG menționarea obligației din OUG de a folosi numai servicii certificate.

Voit sau din vicii de redactare, se echivalează pe alocuri atribuțiile ADR ca furnizor de cloud privat guvernamental cu obligațiile contractuale ale oricărui furnizor comercial. O consecință este excedarea contractelor actuale tip specifice cloudul comercial. Încep să cred că dintre marii furnizori internaționali doar unul va rămâne în cărți, și cu două DC în România.

Complexitatea sarcinii puse pe umerii instituțiilor publice doritoare de cloud este nejustificat de mare. Nu va stimula deloc dezvoltarea acestora în cloud în schimb s-ar putea să înflorească firme de consultanță capabile să ofere soluția câștigătoare, în competiție cu ADR și STS.

Mâine discutăm situația (micilor) furnizori de cloud în relația cu această legislație.