Broasca și scorpionul în norul guvernamental

Este a treia versiune de text. Primul a fost centrat pe politicienii mincinoși, al doilea pe goana după bugete. Acesta va fi o simplă informare.

În discuțiile anterioare publicării acestei propuneri de HG a fost pusă pe masă o variantă în care Platforma Națională de Interoperabilitate nu mai era un concept arhitectural peer-2-peer ci o aplicație de tip Data Hub care concentra la ADR toate schimburile de date între instituții.

Dincolo de o reacție destul de agresivă am depus o adresă oficială în care am arătat că Legea 242/2022 – Legea interoperabilității - nu împuternicește guvernul să reglementeze interoperabilitatea prin HG ci trebuie un ordin MCID.

A dispărut platforma de interoperabilitate. A dispărut platforma de interconectare care concentra conectările dintre aplicațiile guvernamentale aflate în diferite clouduri comerciale.

A rămas însă Art.26 Platforma de tip API Gateway și sunt câteva lucruri importante de spus despre ea.

Conform Art.26 (2) funcționează pe o „o infrastructură informatică dedicată”, adică în afara Cloudului Privat Guvernamental. Un bun prilej pentru ADR să mai cumpere câteva camioane de hardware în cadrul unui proiect distinct, care practic nu poate fi corect dimensionat.

Avem atât definiția din Art.2:

q) platforma API gateway – instrument care reprezintă punctul de intrare unică pentru API-uri și microservicii back-end definite atât interne, cât și externe folosit pentru interconectarea aplicațiilor și serviciilor informatice. Are rol protector, impunând securitatea și asigurând scalabilitate și disponibilitate ridicată;

dar și  Art.26 (5):

 a) asigură interconectarea la nivel de servicii a aplicațiilor din cloudul privat guvernamental

Este o mare diferență între  serviciul de aplicație și microserviciul din care este compusă o aplicație containerizată. Pentru microservicii ideea de a nu folosi orchestrarea proprie ci să treci totul printr-o aplicație externă, administrată de altcineva, merită comentariile unor persoane mai competente decât mine.

Iar perspectiva obligării de Art.26 (6) b) a conectării microserviciilor aferente unor clouduri private precum cel de la Justiție sau MAI la această platformă, care desigur transformă și loghează aceste date, desfide însăși rațiunea existenței independente a acestora.

 

Spuneam de Art.26 (5):

f) asigură jurnalizarea accesului la date;

o idee mult lăudată de Sabin Sărmaș apropo de platforma de interoperabilitate, acum avem ocazia să înțelegem exact ce înseamnă asta din Art.13 (4):

h) FSC asigură monitorizarea evenimentelor de prelucrare a datelor cu caracter personal prin intermediul componentei de jurnalizare și notifică USC cu privire la încălcarea protecției datelor cu caracter personal, fără întârzieri nejustificate, pentru ca USC să poată notifica, dacă este necesar, persoanele vizate afectate.

cu alte cuvinte asupra datelor colectate în log vor fi aplicate proceduri de BI pentru a se identifica eventuale încălcări ale GDPR. Sunt necesare următoarele observații:

GDPR este o plapumă largă care acoperă extrem de multe tipuri de acțiuni

principala „crimă” potențială este prelucrarea fără drept a datelor persoanelor vizate. Este o chestiune de natură juridică sau bazată pe alte informații (existența informării sau a consimțământului) care nu există în log și nu sunt accesibile ADR. Iar dacă toate informațiile sunt disponibile singura instituție abilitată să judece activitatea altei instituții este ANSPDCP, în nici un caz ADR. Este o reinterpretare grosolană a obligației împuternicitului de a anunța operatorul sau chiar autoritatea atunci când apar incidente în activitatea sa prestată pentru operator. Colectarea logului nu este direct generatoare de incidente GDPR.

Mai observăm că prin FSC se înțeleg și operatorii comerciali de cloud, iată unul dintre non-sensurile produse de confuziile de termeni despre care am mai scris.

Nu în ultimul rând avem Art. 42:

(3) Scopul jurnalizării este de a pune la dispoziția cetățeanului sau instituțiilor autorizate, la cerere, istoricul privind acțiunile asupra datelor cu caracter personal găzduite în CPG derulate de o persoană, entitate sau sistem.

Mă simt obligat să remarc Art. 26 (3):

(3) În vederea asigurării securității cibernetice a Platformei de tip API Gateway, ADR colaborează cu Directoratul Național de Securitate Cibernetică și cu SRI.

Este singura sarcină directă pentru DNSC și poate fi explicația excluderii API Gateway din cloud. În mod normal API Gateway ar fi fost infrastructură PaaS în administrarea STS și cu implicare minimă din partea SRI. Dar hei, valorează și camioanele alea de hardware ceva!