Dezbaterea HG Cloud

A avut loc dezbaterea publică a HG-ului pentru Platforma de Cloud Guvernamental. Tot în sala INS, dar cu un alt vibe.

Echipa MCID părea să aibă în comun un grad avansat de oboseală în fața căreia reacționau diferit, dar totuși clar lipsit de entuziasm. În prezidiu au fost pentru o perioadă de timp conducătorii MCID și STS, președintele ADR online iar SRI invizibil. 

Nu a mai existat dialogul alert, idee cu idee, doar intervenții periodice cu răspunsuri selective.

Mai interesanți au fost invitații.

ANIS și-a pierdut N-ul și a vorbit doar din perspectiva marilor furnizori de cloud comercial. Au cerut să nu existe limitări geografice, toate datele să poată fi prelucrate în US pentru că acolo este vârful tehnologic. Au mai cerut să nu fie necesar niciun fel de aviz pentru ca o instituție publică să folosească cloudul comercial.

Microsoft România s-a plâns că politica cloud first este slabă, că se aplică doar în viitor când va fi gata cloudul privat guvernamental. A cerut să dispară avizele de la CTE și ADR. A observat că nu sunt clare părțile contractante aferente serviciilor comerciale.

Eu am spart bugetul de timp și am vorbit despre ce am scris deja.

Bogdan Manolea de la APTI a avut o intervenție pe zona GDPR surprinzător de placidă față de așteptările mele.

Radu Puchiu a vorbit despre necesitatea orientării HG-ului spre persoane, despre câștigarea încrederii, despre faptul că este foarte alambicat și greu de înțeles de instituțiile publice.

Senzația mea este că ne-am atins cu toții limitele. Am propus chiar să fie HG-ul periat de greșelile evidente și apoi să reluăm discuția asupra unor idei clare, pe care să le putem dezbate. Am însă senzația că toată lumea vrea să scape odată de el.

Am pus în descrierea de pe Youtube marcări de timp astfel încât să puteți trece direct la vorbitorul dorit. Atunci când apare a doua oară un vorbitor este momentul în care se dau unele răspunsuri. 

Decizie CNSC proiect PKI CEI (eIDAS #60)

A fost emisă decizia CNSC cu privire la contestația Trans Sped la procedura de achiziție PKI pentru Cartea Electronică de Identitate.

Unele susțineri au fost admise, altele nu, concluzia este că trebuie refăcută documentația.

Motivația este subțire, spre exemplu pe subiectul migrării certificatelor emise la Cluj decizia de a solicita migrarea este considerată corectă însă se reproșează că nu sunt declarate numărul de certificate de migrat și furnizorul platformei respective.

Procedura este suspendată, va exista un nou termen pentru solicitările de participare.

Altfel, am reținut despre MAI că „că din analiza derulării achiziţiei, remarcă faptul că, până la data actuală, contestatoarea nu a formulat nicio solicitare de clarificări adresată autorităţii contractante cu scopul de a informa eventualele neconformităţi sesizate, rezumându-se strict la depunerea prezentei contestaţii, în scopul vădit de a suspenda procedura de atribuire până la soluţionarea acesteia.”

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!

Impactul asupra furnizorilor privati de cloud

Există 3 categorii de furnizori de cloud pentru instituțiile publice iar in acest articol vom discuta impactul acestui HG asupra lor. Există două tipuri de consecințe, blocante și schimbătoare de reguli de joc.

Avem active astfel următoarele tipuri de furnizori de cloud:

·      marii furnizori de cloud internaționali (ex. Microsoft, Google). Consistența prezenței lor românești variază semnificativ, se implică la nivel de lobby dar vând exclusiv prin alte firme, de obicei locale.

·      furnizori locali de cloud, de obicei ca linie de business din cadrul unui telecom (ex. Orange) sau, mai nou, ca afacere principală (ex. ClusterPower). Au obiceiul să participe ca asociați în consorții care depun oferte în achizițiile publice. Sunt dispuși să se muleze pe cerințele locale (ex. certificarea data-centerului pentru arhivare electronică sau jocuri de noroc)

·      furnizori locali de SaaS care dezvoltă respectiva aplicație (ex. Regista, ConnectX). De cele mai multe ori folosesc servicii de cloud pe care le cumpără de la celelalte două categorii. Sunt în contact direct și permanent cu administrația publică.

Din perspectiva administrație publice furnizorii de SaaS sunt cei mai importanți. Pe de o parte oferă servicii direct integrate în funcționarea instituției publice iar pe de altă parte aduc expertiza tehnică exact în locul unde poate face cea mai mare diferență. OUG-ul le-a oferit gratis aceleași servicii în cloudul privat guvernamental ca cele pe cere le cumpără de la furnizorii lor actuali sub condiția unui management responsabil al serviciului SaaS. Vor fi prezenți în marketplace cât timp aplicațiile lor vor corespunde criteriilor de calitate din zona de securitate și management date.

În discuțiile anterioare am avut o coliziune cu interesele ADR care nu dorește să fie în competiție cu acești furnizori în cazul aplicațiilor SaaS  dezvoltate de ADR, din cei 100 mil euro și a fost exprimată dorința ca să existe anumite categorii de servicii SaaS interzise ofertanților privați. Această viziune nu se regăsește explicit în HG. Există prevederi care stabilesc criterii pentru acceptarea de către ADR în marketplace legate de securitatea aplicației, respectarea GDPR și transparența furnizorului.

Lipsește un mandat explicit pentru ADR de a negocia această listare contra unor condiții mai bune, inclusiv de natură comercială. Similar unui contract cadru guvernamental.

Lipsește o prevedere explicită care să interzică aranjamente comerciale în afara condițiilor listate în marketplace. Astfel administrația publică este lipsită de beneficiul discountului de volum pe care l-ar obține natural din partea furnizorului. Nu în ultimul rând nu sunt prevenite aranjamente de tipul Mândruțescu / Oracle care distorsionează grav competiția în piața guvernamentală.

Ambele lipsuri își au originea în lipsa de voință din OUG.

În schimb HG-ul nu ezită să creeze în alte zone drepturi noi pentru ADR. Aș fi foarte interesat să văd, dacă există, tabelul de mapare dintre HG și OUG.

Concluzie în privința furnizorilor de SaaS

Raportându-ne la textul OUG putem observa următoarele lipsuri și adăugiri la lege:

• Art.3 (8) din OUG nu este satisfăcut de HG din perspectiva existenței criteriilor și măsurilor cu privire la impunerea adaptării la standarde tehnice și semantice care ar fi trebuit să existe în Art.39 (3) din HG.
• Asigurarea interoperabilității aplicațiilor de cloud cerută de același Art.3 (8) din OUG este abordată doar la nivel de transport date și este deturnată într-un pretext pentru Art.26 din HG care vorbește despre o platformă de tip API Gateway ca infrastructură informatică dedicată, deci în afara CPG. Este o viziune mercantilă, orientată spre mari proiecte tehnice, în locul unei abordări sistemice menită a facilita interoperabilitatea nativă (care nu este numai la nivel de date ci include și servicii PaaS și IaaS interschimbabile), fără prea multe transformări de date sau refaceri de aplicații.
• Conform Art.46 (4) din HG toate instituțiile publice centrale au obligația de a migra către varianta de cloud a aplicației on-prem existente. Achiziția unei aplicații noi ar trebui să aibă ca și condiției de calificare disponibilitatea în cloud 46 (2). Însă oricât de bine sună, forța acestor prevederi este iluzorie întrucât Art. 8 (2) din OUG are un „sau” care permite minimal interconectarea aplicațiilor așadar „cloudificarea” rămâne legată de (bună)voința conducătorului instituției.

Furnizorilor de SaaS găzduiți de Cloudul privat guvernamental li se oferă, în concluzie, o reducere semnificativă de costuri (care ar fi mers către platformele mari de cloud) și li se cere colaborarea în zona securității cibernetice atât pe zona de analiza de risc / proiectare / bune practici în realizarea aplicațiilor cât și în zona operațională cu adresabilitate către factorul uman și zona de helpdesk, ticketing și callcenter. În toate celelalte aspecte nu există prevăzute schimbări legale cu consecințe semnificative. Există însă o zonă de risc, modul în care ADR va înțelege să-și construiască o relație cu această comunitate, dacă pe unii îi va migra direct în cloud iar altora le va pierde câte o hârtie din dosarul cu șină.

 

Concluzie în privința furnizorilor locali de cloud

Din perspectiva activității lor de furnizare SaaS, dacă există, se aplică cele aferente. Altfel, prin flexibilitatea pe care o au, ar putea fi avantajați de aceste prevederi prin preluarea clienților cloudurilor internaționale care nu doresc să meargă în CPG. Spre deosebire de micii furnizori de SaaS aceștia sunt deja obișnuiți cu statutul de „infrastructură critică” fiind deja sprijin pentru activitatea de comunicații și au deci obișnuința dialogului și colaborării cu autoritățile din domeniu.

Concluzie în privința furnizorilor internaționali de cloud

Pentru că în marketplace vor fi listate doar servicii SaaS iar construcția acestor norme se bazează pe o abordare bazată pe această listare, tot ce nu este listabil, adică serviciile IaaS și PaaS, sunt libere, astfel afacerea PaaS, care este esența acestor furnizori, va continua nestingherită. Mai mult, un wrapper peste un serviciu SaaS, să zicem peste Office 365, îl downgradează formal ca fiind PaaS, un aranjament posibil tehnic și comercial cu o firmă românească care să asigure listarea în marketplace.

Lipsa de recursivitate a prevederilor legii pentru toți furnizorii implicați, la fel ca și în cazul legii 5G, va duce la un joc de-a șoarecele și pisica. În aplicarea Art.24 (1) b) este datoria instituției publice să argumenteze că serviciul de cloud comercial este legitim, o abordare nerealistă, chiar ridicolă, care nu atrage responsabilități reale pentru operatorul cloudului.

Elefantul din încăpere pe care îl ignoră toți

Art.16 (2) din OUG este singura prevedere cu adresabilitate directă (call to action) pentru operatorii de cloud comercial. A fost o liniște asurzitoare în legătură cu aceasta pe parcursul discuțiilor despre HG. Este formal corect, aplicarea ei va fi detaliată prin Ordin MCID.

Am scris deja cum ar fi interpretabil acest articol și imposibilitatea furnizorilor internaționali de cloud de a-l satisface ad-literam.

Nu-mi pot opri o digresiune ... cariera politică este decisă de capacitatea de a găsi soluții productive în situații de conflict, atât cu legea cât și între mai multe părți interesate. A satisface conducerea partidului implică, de cele mai multe ori, încă un schelet în dulap. Va fi interesant să vedem în ce măsură dl Burduja va naviga Art.16 (2) cu succes între Scila și Caribda și câți marinari va pierde pe drum.

Următoarea postare, ultima, va fi mai puțin tehnică dar dedicată câtorva intenții greu de explicat celor care dau atenție democrației sau au, ca mine, sechele din perioada comunistă.

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.

HG cloud - puterea alocării resurselor din cloudul guvernamental

Dacă publicul este interesat în primul rând de securitatea datelor, pentru instituțiile publice prioritatea este alocarea resurselor. O instituție publică caută întotdeauna să obțină cât mai multă resursă de calitate, respectiv ca aceasta:

• să fie predictibilă
• să fie fungibilă (bani)
• să fie sub control discreționar
• să fie definitivă (nerevocabilă)
• să fie liberă de KPI

... la fel și nevasta 😊

Evident realitatea nu poate fi atât de dulce, există diverse mecanisme, bugetare sau legale, care îngrădesc disponibilitatea și utilizarea resurselor.

Aceste mecanisme sunt departe de iubirea conducătorilor instituțiilor care le „joacă” după posibilități, de multe ori cu cele mai bune intenții. Există însă riscuri și consecințe.

Externalizarea serviciilor IT către furnizorii comerciali a fost, istoric, modalitatea perfectă de cheltuire a resurselor până când, în funcție de perspectivă, furnizorii au devenit prea scumpi sau resursele prea puține. Banii erau pe masă, KPI-urile se transferau cu copy/paste în contractul comercial.

Externalizarea serviciilor IT către o altă instituție publică este privită cu bucurie sau tristețe de conducătorul unei instituții în funcție de percepția sa de sine cu privire la capacitatea de a juca pe cont propriu. Însă este tot un joc al alocării, chiar dacă resursa nu este direct monetară ci un serviciu.

Dacă ne uităm la anii de ascensiune a STS ca furnizor de soluții ITC pentru mediul public putem observa câteva reguli de joc:

1. instituția publică care îi devine beneficiar suferă în timp o atrofiere a capacității proprii IT
2. STS începe să contribuie, sub egida securității sau a consultanței colegiale, la formarea strategică a respectivei instituții
3. rata de dezvoltare / transformare a respectivei instituții depinde de resursele alocate de STS
4. per total fiabilitatea instituției crește iar dacă apar accidente STS își asumă stoic, chiar dacă nu a fost implicat direct
5. Pentru majoritatea instituțiilor este benefic să fie deservite de STS.

Însă și STS are jocul său, alege din coada de solicitanți de la poarta sa, după două criterii:

1. relevanța instituției ca trofeu în portofoliu
2. capacitatea instituției de a asigura, direct sau indirect, fonduri pentru funcționarea STS

Când am menționat coada de solicitanți cred că a devenit clar cine are asul. Să nu uităm că jocul nu poate fi măsluit decât de Președinte, STS nu se află în subordinea prim-ministrului.

Guvernul a avut un Joker, cei 500 de milioane de euro din PNRR dar nu a știut să-l joace.

Ar fi trebuit ca deciziile din acest HG să fie luate înainte de alocarea banilor. Nu s-a putut, min Teleman s-a retras pe aliniamentul deciziei ulterioare bazată pe un consultant independent cu menționarea STS ca posibil constructor (nu operator) al cloudului comercial.

Nici această poziție nu a ținut. Min Boloș a fost victima placidă a unei manevre de învăluire, STS,  SRI și ADR s-au auto-declarat a fi consultanții independenți asumați prin PNRR și și-au împărțit opac între ei bugetul și atribuțiile.

La final a apărut presiunea societății civile (stimulată de angoase proprii și nu de buna funcționare a administrației publice) care a cerut ca ADR să fie „șeful pe cloud”. Eroic, în lupte crâncene nocturne, au fost propuse documente și i s-a dat aparentă satisfacție.

Am spus despre OUG că este bun, că sunt mulțumit că permite buna direcție.

În acest HG însă cărțile sunt decartate, este ultimul joc. Acum vedem concret realul participanților.

Să închei însă această digresiune dedicată viitoarele articole de analiză a HG-ului de cloud.

Revenind la resurse și puterea alocării lor.

Conform HG Art.5 (3) coroborat cu (2) stabilirea instituțiilor acceptate ca utilizator de cloud este făcută prin „acorduri de administrare încheiate de ADR cu STS și SRI.”

Mai mult,

Conform Art.14 (1) f) STS alocă resursele tehnice din CPG ... în limita constrângerilor tehnice, operaționale și financiare.

Noi înțelesesem din OUG că STS pune la dispoziția ADR întreaga capacitate urmând ca ADR să o împartă. Nu numai că nu este așa dar începe să devină necesară o prevedere care să garanteze că întreaga capacitate tehnică achiziționată prin PNRR va fi utilizată în beneficiul cloudului guvernamental și nu și pentru alte scopuri.

Ca să nu mai spun că, din OUG, orice instituție eligibilă, inclusiv administrația locală, ar fi avut dreptul să acceseze direct măcar aplicațiile SaaS.

Spuneam de bătălia continuă ... hai să vedem ce s-a întâmplat în 2022

Martie, Legea 242 – platforma de interoperabilitate care va fi migrată în cloudul guvernamental asap.

Art.9 (6) si (7) – pentru conectarea in platforma se asigura rețeaua de transmisii de date securizată, asigurată, în limita resurselor disponibile de STS. Dacă STS nu poate, vor fi utilizate rețele de transmisii de date furnizate de către furnizorii de rețele publice

Iunie, OUG 89 -  Platforma de cloud (care include platforma de interoperabilitate)

Art.5 (3) STS asigură accesul securizat, conectivitatea și interconectarea la serviciile specifice cloudului privat guvernamental pentru entitățile găzduite sau interconectate în cloud.

Nu mai exista varianta de rezervă, dacă STS spune că nu poate.

Septembrie, proiect HG

Art. 29. (2) Serviciile de cloud furnizate în cadrul CPG sunt oferite prin intermediul rețelelor de comunicații aflate în administrarea STS, prin canale securizate de acces şi transport de date.

Pentru cine nu este foarte tehnic, este de reținut că securizarea datelor se poate face la capete, prin echipamente de criptare.

Așadar în 6 luni condiția de a fi parte din viitorul e-guvernării a evoluat așa:

1. Echipamente proprii și internet comercial setate conform cerințelor STS
2. Echipamente STS  și internet comercial
3. Echipamente STS și fibră STS

 

Concluzie

Pentru a putea accesa cloudul privat guvernamental o instituție publică trebuie să fie agreată de ADR, STS și SRI și să nu fie amânată ulterior deciziei de către STS din lipsă de conectivitate.

Noi aprobări 5G

A mai fost aprobat un lot de producători de echipamente asociate 5G și lucrurile devin interesante!

Aceștia (HP, IBM, Oracle, Motorola, Maguay și Cloudbase) sunt aprobați „în vederea utilizării echipamentelor de infrastructură 5G, în condițiile în care tehnologiile, echipamentele sau produsele software comercializate sub numele sau marca acesteia provin de la operatori economici avizați în temeiul Legii nr. 163/2021”

Însă furnizorii aprobați anterior (Starc4Sys, Compania de Pază R.O și Concept Electronics) au fost autorizați „în vederea utilizării de tehnologii, echipamente și programe software în cadrul infrastructurilor informatice și de comunicații de  interes național, precum și în rețelele 5G”.

Există două observații de făcut:

1️⃣ Deși criteriile de evaluare sunt identice acest nou lot este autorizat doar pentru rețelele 5G, nu și pentru infrastructuri informatice precum cloudul guvernamental. Foarte surprinzător având în vedere că vorbim de HP și Oracle.

2️⃣ A apărut o clauză suspensivă, 👉 în condițiile în care … [subansamblele și componentele] … provin de la operatori economici avizați în temeiul Legii nr. 163/2021.👈 Este închiderea unei portițe despre care se știa dinainte de adoptarea legii.

Așadar există și două întrebări de pus:

1️⃣ Nu este această clauză suspensivă o adăugare la lege?

2️⃣ Cumva Starc4Sys, Compania de Pază R.O și Concept Electronics, în lipsa clauzei suspensive, pot să rebrănduiască produse OEM însă au un management de încredere, care va face într-un mod responsabil acest lucru de altfel foarte necesar în cazul unor proiecte complexe?

Politica cloud first – cel mai departe de perfecțiune aspect din HG

500 de milioane de euro sunt un munte de bani! Și-i cheltuim, sper, nu ca să-i cheltuim ci pentru a obține câteva avantaje. În cadrul platformei de cloud hibrid, noțiune care acoperă orice tip de cloud utilizat de administrația publică, aceste avantaje sunt următoarele:

pentru cloudul privat guvernamental:

• securitatea serviciilor de e-guvernare și a datelor aferente. Cu ambele componente: confidențialitate și disponibilitate.
• standardizarea datelor și reutilizarea blocurilor funcționale ca PaaS – baza interoperabilității

pentru cloudul comercial:

• Tehnologii state of the art: AI, ML, etc.
• Prețuri bune (dacă sunt negociate corespunzător)

Din însăși faptul că vom construi un cloud privat guvernamental rezultă că securitatea și standardizarea sunt de primă importanță însă și costul și performanța sunt foarte tentante, așadar trebuie să stabilim o regulă a deciziei pe cale drum mergem. Această decizie se încadrează în conceptul de „cloud first”.

Cum cloudul privat este plătit de PNRR aspectul economic devine presant doar după ce resursele procurate astfel vor fi fost epuizate, rămâne ca argument actual de partea cloudului comercial nivel său tehnologic ridicat.

Politica de cloud first este, în esență, algoritmul de alegere a tipului de cloud potrivit pentru fiecare nevoie a instituției publice.

Această decizie poate avea doar unul dintre următoarele rezultate:

a)      Servicii oferite în cloudul privat guvernamental de către ADR

b)     Servicii oferite în cloudul privat guvernamental de către entități private

c)      Servicii oferite în cloudul privat al unei entități publice pentru satisfacerea nevoilor proprii și a nevoilor entităților publice aflate în coordonarea, subordonarea  sau răspunderea sa organizatorică.

d)     Servicii oferite conform lit. c.) în situația în care caracterul privat al cloudului este obținut prin măsuri tehnice de izolare față de cloudul public cu care împarte aceeași tehnologie și administrator tehnic.

e)     Servicii oferite în cloudul public comercial

f)       Servicii oferite în cloud hibrid furnizate prin agregarea mai multor alte tipuri de servicii de cloud

g)      Aplicație cloud ready

h)     Aplicație  non-cloud

Evident, abordarea non-cloud este nomina odiosa.

Ordinea a) – g) este ordinea de preferință, a) este prima opțiune, pentru celelalte ar trebui aduse argumente specifice proiectului în cauză.

Nu cred că instituțiile publice pot fi lăsate să ia singure această decizie, istoria ne învață că vor dori o colaborare netransparentă cu furnizorul de casă, adică o aplicație on-prem cloud ready.

Să vedem ce ni se propune în HG.

Un singur articol, Art.46 !

E atât de puțin încât poate fi citat în întregime. Însă pe cei mai mulți cititori îi sfătuiesc să sară direct la concluzii.

Art. 46.

(1) Politica cloud first promovează serviciile cloud computing ca tehnologie prioritară pentru administrarea și furnizarea de servicii publice la nivel central și local.

O definiție explicativă fără valoare practică

(2) Autoritățile și instituțiile publice utilizează Platforma ca primă opțiune pentru implementarea de noi aplicații și servicii.

Sau nu, dacă apelează la Art.47 (1) și obțin o derogare de la CTE în baza unor nenumite criterii.

(3) Autoritățile și instituțiile publice, la elaborarea strategiei de investiții în domeniul TIC, vor include în criteriile de analiză care determină introducerea în programul de investiții a obiectivelor noi de investiții TIC următoarele cerințe:

Spre deosebire de mediul corporatist „strategia de investiții” a unei autorități publice este un document foarte rar care, dacă există, nu influențează direct „Programul anual de achiziții publice” . Această abordare este fără o adresare clară, fără impact.

a) prioritizarea opțiunii de cloud ready sau cloud nativ;

Cloud ready nu trebuie să fie o prioritate ci o obligație derogabilă doar de CTE

b) respectarea prevederilor Hotărârii Guvernului nr. 941 din 27 noiembrie 2013 privind organizarea și funcționarea Comitetului Tehnico-Economic pentru Societatea informațională, cu modificările și completările ulterioare pentru obținerea avizului conform.

Parcă respectarea legii este nu un obiectiv ci o obligație ?

(4) Începând cu data de la care este operațional CPG, autoritățile și instituțiile publice centrale, cu excepția celor prevăzute în Ordonanță, au obligația utilizării serviciilor de cloud disponibile, conform catalogului de servicii.

Despre utilizarea platformei de cloud (2) ne spune că este „primă opțiune” acest (4) că este „obligație”. Este o clauză tranzitorie scrisă și amplasată greșit, ar fi trebuit o referire directă către obligație, „prima opțiune” fiind temporară până la lansarea CPG.

(5) În aplicarea prevederilor art. 1 alin. (7) din Ordonanță, toate aplicațiile informatice dezvoltate de autoritățile și instituțiile publice centrale cu finanțare din fonduri publice sunt de tip cloud ready sau cloud nativ.

Există tipuri de aplicații, de exemplu IoT, care, prin natura lor, nu pot fi nici măcar cloud ready. Aici este nevoie de granularitate sau trimitere către CTE.

(6) Autoritățile și instituțiile publice actualizează componenta TIC din strategia proprie pentru adoptarea serviciilor de cloud.

Pline sertarele de strategii ... oare MCID a modificat strategia SIPOCA20 în zecile de pagini în care vorbește despre un cloud guvernamental care nu are nicio asemănare cu cel actual ?

Concluzii

Atât în dezbaterea publică a OUG-ului cât și pentru acest HG, furnizorii comerciali de cloud au avut ca primă prioritate menționarea serviciilor lor în lege ca o alternativă valabilă pentru instituțiile publice. Pe principiul .... până s-o face cloudul privat guvernamental, cloudul suntem noi iar toate instituțiile publice să fie obligate să-l consume.

Iată că propunerea MCID face mai mult decât atât. Perpetuu cloudul comercial este egal cu cel privat guvernamental urmând a fi limitat doar de considerente punctuale, legate de natura aplicației/datelor ce urmează a sta în acel cloud. (Criterii importante care vor face obiectul altui articol).

Dând la o parte toate chestiile inutile această formă de HG ne spune așa:

Orice investiți care face obiectul HG-ului va fi cloud ready sau cloud nativ. Aplicațiile native se folosesc doar de servicii de cloud aprobate în marketplaceul guvernamental. Acest marketplace oferă atât servicii comerciale preaprobate cât și servicii private guvernamentale.

Ce probleme are această abordare ?

Rolul CTE există specific doar tranzitoriu, până la lansarea Cloudului Privat Guvernamental! În această perioadă limitată CTE nu are rolul de a deroga „cloud ready” deși în unele cazuri este necesar.

Rolul CTE general poate include verificarea utilizării cloudului dar numai pentru proiectele care ajung la el, adică cele de peste 500.000 euro. Este un buget anual uriaș din perspectiva serviciilor de cloud, nu știu câte instituții publice l-ar atinge.

Diferențiatorul bazat pe securitate între cloudul privat și cloudul comercial nu este îndestulător. Standardizarea datelor, convergența aplicațiilor, toate sunt în egală măsură relevante. Chiar și calculul economic nu poate fi ignorat. Variantele de la a) la f) nu sunt nicicum echivalente și nu poate fi lăsată alegerea lor în seama unui proces administrativ intern, fără control ante (CTE) și post (Curtea de conturi ?). Este o decizie care trebuie să aibă un default, o ordine de precedență prestabilită urmând a se discuta nu toate valențele fiecărei variante ci doar acel aspect care produce trecerea la evaluarea variantei următoare.

Concluzia concluziei

Forma actuală nu promovează Cloudul Privat Guvernamental și nu urmărește valorificarea investiției în acesta.

DESHub - Septembrie 2022

 

A avut loc prima întâlnire DESHub, proiect inițiat de Asociația HappyCities, având ca partener MCID și dedicat dialogului dintre părțile care pot contribui la îmbunătățirea poziției României în DESI.

DESI - The Digital Economy and Society Index – este o evaluare anuală a CE cu privire la stadiul de dezvoltare a statelor membre în zona comunicațiilor și tehnologiilor digitale, iar România este tradițional pe ultimul loc.

Unii consideră DESI doar o știre de o zi în fiecare an, muniție în războiul politic. Alții poate văd în DESI povestea care însoțește mâna întinsă către banii europeni. Alții îl ignoră chiar dacă (in)acțiunea lor contribuie la rezultatul anual.

Noi credem că România merită și poate mai mult.

Este doar nevoie de atenție și coordonare. Vom încerca să contribuim - eu, Radu Puchiu și Mirela Mărcuţ, PhD – prin organizarea dialogului și sămânța primelor idei. Apoi credem că există oameni, inclusiv în administrația publică, care le pot duce mai departe, spre realitate.

Am fost impresionat de numărul și calitatea participanților.

Evenimentul a avut 2 părți, prima cu vorbitorii Radu Puchiu și Sebastian Burduja, a doua cu noi 3 și numeroase intervenții, în special din partea instituțiilor publice dar și din societatea civilă.

Ne vedem peste o lună discutând despre Capital Uman (digital) ! #DESHUB


Partea I: https://youtu.be/S8u23UqjeQY
Partea II: https://youtu.be/LTangzcja6c

Draft HG Cloud

A fost publicat proiectul HG-ului ca normă de implementare a cloudului guvernamental. Sunt destul de multe de spus despre el, sunt necesare mai multe și mai bine organizate postări, dar cred că trebuie să încep cu o imagine de context.

Este un document foarte ambițios, de tip 7 HG în 1. A fost creat în mai multe etape, una a fost de consultare la nivel de idei cu zona non-guvernamentală, în mai multe ședințe.

Au fost invitați toți cei care s-au implicat în dezbaterea OUG-ului însă, pe timp de vară, s-au rarefiat doar la mediul comercial și eu, singurul vorbitor fără interese economice.

Au fost dezbateri aprinse.

Unele idei mi-au fost acceptate, cele mai multe nu. Nu-i bai, de abia acum începe dezbaterea obligatorie. Voi face câte o postare în fiecare zi pentru câte o problemă controversabilă.

link draft Hg: https://www.research.gov.ro/uploads/sistemul-de-cercetare/legislatie-organizare-si-functionare/proiecte-de-acte-normative/2022/hota-ra-re.pdf

Au corectat legea anti Kaspersky

Taxam în 10 Mai (https://www.facebook.com/raudaradev.../posts/330057019211641) propunerea MCID de interzicere a produselor Kaspersky.  Nu era cu răutate, este inevitabil ca o echipă nouă să aibă mai mult entuziasm decât pricepere.

După 5 luni proiectul care a ajuns pe masa guvernului a fost corectat de instituțiile avizatoare.

Nu mai impune condițiile păcii din Ucraina ci are ca dată fixă 31 decembrie 2026.

Nu mai instituie o poteră care să vâneze produsele incriminate prin instituțiile publice.

Și noul text ar fi putut fi îmbunătățit.

S-ar putea renunța la condiția cumulativă a utilizării produsului pentru definirea contravenției - achiziționarea lui este îndeajuns, utilizarea necesită un flagrant greu de realizat.

S-ar putea folosi expertiza Consiliului Concurenței care face același tip de analiză asupra unei companii în aplicarea legii cu privire la investițiile străine. (coerența instituțională este chiar benefică!)

Rămâne pentru Parlament.

OUG cloud - mișcări de învăluire

Partea a doua a acestei zile, dedicată cloudului guvernamental, este mai greu de descris. Pe scurt, a fost raport pozitiv unanim, fără amendamente. Însă am senzația că discursurile au avut două planuri de înțelegere, diferite în funcție de cât de ancorat în context era publicul.

⚠️Nu mă pot abține să nu vă spun percepția mea, caveat!

Context: umblă zvonul că, de două săptămâni, procesul de elaborare a normelor, HG, aferente cloudului guvernamental este blocat de neînțelegeri între cei patru parteneri.

Această situație poate fi deblocată în mai multe moduri, în opinia mea cel mai democratic ar fi printr-o direcție dată de Parlament. Ar fi putut fi propuse amendamente în acest scop, dar nu s-a întâmplat.

Să o luăm cronologic:

Dl. gen ROG, șeful CyberInt, a deschis discuția afirmând apăsat că viziunea instituției sale este că decizia administrativă și coordonarea cloudului trebuie să fie în totalitate în zona civilă (n.b. care nu include STS). SRI ar trebui să fie „într-un plan secundar”.

A insistat să ne spună că, apropo de DNSC, i-au predat acestuia toate cooperările internaționale în care, de nevoie, SRI reprezenta România.

Reprezentantul STS a subliniat că în OUG îi sunt clar stabilite atribuțiile și că nu ar fi de acord, la nivel de exprimare, cu gen. ROG cu privire la „statul în spate” atât timp cât are, prin legea proprie, atribuții de oferire servicii către toate autoritățile publice din România.

MCID susține ordonanța în forma actuală.

ADR, prin vocea d-lui Dragoș Vlad, a insistat că instituția trebuie sprijinită în rolul ei de unic ofertant guvernamental de servicii (se înțelege SaaS) în cloudul privat guvernamental.

Toți ce de mai sus au avut și asigurări de dat cu privire la deplina confidențialitate a datelor.

Apoi au întrebat senatorii:

Un sen PNL a întrebat cine este proprietarul cloudului și dacă vor putea fi folosite și clouduri comerciale (exemplu Amazon folosit de o Universitate)? STS i-a povestit generalități despre interconectarea tehnică a diverselor clouduri concluzionând că va fi posibilă. (n.b. a vorbit de interoperabilitate tehnică, de marketplace, nimic despre certificarea obligatorie pentru Amazon)

Un sen USR a pus o întrebare despre un subiect mult discutat în dezbaterea publică dar rezolvat ulterior în textul OUG – dacă statul vrea sa fie proprietarul softwareului și dacă va fi folosit open source? Pe scurt STS a explicat că puținele aplicații care vor fi proprietatea statului sunt din zona de SaaS iar acestea vor fi comandate către industria IT.

Apoi gen ROG a luat cuvântul și ne-a livrat cea mai importantă parte a zilei.

A spus că, conform PNRR, toate serviciile trebuie să fie gratuite timp de 5 ani. (o afirmație extrem de importantă dar care trebuie analizată cu atenție. Eu nu îmi aduc aminte să existe o astfel de prevedere în Regulamentul UE, ar fi și greu, poate, de aplicat pentru toate tipurile de investiții din PNRR însă nu exclud ca, la nivelul contractului de finanțare, chiar și din inerție, să nu apară astfel de prevederi).

A mai spus că SRI sprijină, în limitele competențelor sale, instalarea unui datacenter public (comercial) în România. Acesta ar putea oferi servicii către administrație prin intermediul cloudului guvernamental (adică cloudul guvernamental nu dublează aceste servicii ci este un fel de proxy prin care sunt acestea consumate). 

‼️Senzația mea este că teritoriul național este o condiție fermă pentru certificarea cloudurilor comerciale.

S-a contrazis cu reprezentantul MCID care spunea că obiectivul cloudului privat este reducerea costurilor argumentând că obiectivul principal este atingerea gradului de sofisticare 5 (oare unde era când la CDEP amendamentul AMR în această direcție a fost scos de Sabin Sărmaș din legea interoperabilității ?)

Am ajuns și eu la cuvânt, mi-am exprimat mirarea că nu există amendamente propuse în vederea deblocării HG-ului ceea ce a generat o reacție din partea unui invitat pe care încă o internalizez.

Vot pentru, în unanimitate! 1 oră pentru DNSC+cloud

Salariile DNSC ok la Senat

Salariile DNSC au primit un raport unanim favorabil din partea Comisiei IT a Senatului. Sunt însă lucruri de spus despre cum răsplătesc invitații ospitalitatea și deschiderea arătată de senatori.

Eu am fost primul abuzator, am vorbit în nume personal ceea ce nu este chiar ok din perspectiva regulamentului. Noroc că dl președinte al comisiei sen. Humelnicu m-a iertat după ce m-a mustrat.🙏

⚠️Sunt însă probleme mai serioase în relația dintre cele două ramuri constituționale.

Deși Guvernul avea aprobat un punct de vedere scris de respingere a inițiativei am avut surpriza ca dl. SGA al SGG GHELBERE să ne vorbească despre „rugămintea d-lui SG al SGG Marian NEACȘU ca acest proiect să fie aprobat”‼️

Din discursul DNSC care a urmat rețin afirmația că „OUG-ul nu a reușit să rezolve problema salariilor” și că acum este o necesară corecție.

⚠️Realitatea este alta.

OUG-ul  DNSC a avut două variante. Prima conținea tratament preferențial salarial, varianta finală nu. Acest lucru s-a întâmplat pentru că pe circuitul de avizare Munca și Finanțele s-au opus. Tot ele au determinat si poziția scrisă a Guvernului.

Astăzi la masă au fost prezente doar instituții „digitale”, cu un interes direct în mărirea acestor salarii dat de o perspectivă profesională și secreta dorință de a crea un precedent.

Nu cred că SGG are dreptul legal de a exprima opinii contrare celor rezultate în ședința de guvern cum nici nu am crezut că a fost ok, cu ani în urmă, abordarea similară a MCSI care s-a opus verbal proiectului de lege adoptat de guvern cu privire la CEI.

În cele spuse de mine, printre altele, am sugerat și că forma actuală nu este „o omisiune” ci rezultatul unui proces instituțional de decizie. Am fost ascultat cu atenție și ... i s-a atras atenția d-lui Cîmpean că senatorii îl consideră responsabil să păstreze  în timp nivelul profesional al angajaților DNSC.🤪

Cu alte cuvinte, când va concedia un angajat prins dormind cu capul pe birou, dl. Cîmpean va explica la proces că este mandatat verbal de Parlament să facă acest lucru .... Postez o poză cu posibili martori la care să apeleze DNSC, pentru că nu va exista un transcript oficial.

Cred că mai avem mult de îngurgitat democrație până să avem acele instincte care o țin în putere în marile țări occidentale.

Salariile DNSC - don't fly too close to the sun

Mâine, la Senat, comisia IT va discuta raportul pentru legea care mărește salariile DNSC. L422/2022 nu are o bună perspectivă, chiar Guvernul i se opune argumentând că ocolește Legea Unică a Salarizării iar salariile sunt mult prea mari, mult peste Curtea de Conturi.

Totuși merită discutat despre care ar fi abordarea corectă.

În primul rând ar trebui abandonată tactica cuvintelor mari fără suport în realitate. Spre exemplu Nota de Fundamentare ne spune că:

„Odată cu invazia Ucrainei de către Federaţia Rusă la 24 Februarie 2022, actori cibernetici afiliaţi intereselor Federaţiei Ruse au iniţiat atacuri cibernetice intense, repetate şi de amploare asupra infrastructurilor cibernetice din ţara noastră şi a statelor aliate.”

... un paragraf care ignoră faptul că, legal, atacurile inițiate de actori statali fac obiectul de activitate al SRI, nu DNSC !

Aceeași notă ne spune că:

Funcţiile specifice de conducere şi de execuţie din cadrul Directoratului pot fi ocupate doar de specialişti de securitate cibernetică cu o înţelegere detaliată a modului în care riscurile şi  ameninţările cibernetice pot fi identificate, evaluate şi contracarate, a modului în care sistemele IT sau reţelele / infrastructura şi lanţul de furnizori digitali al unei organizaţii funcţionează, a modului în care tehnicile şi protocoalele de răspuns la incidente cibernetice pot fi aplicate, acestea implicând un set complex şi nou de cunoştinţe şi abilităţi.

... o afirmație plauzibilă de la care putem porni o analiză.

Să vedem întâi la ce funcții se referă în proiectul de lege:

Expert securitate cibernetică; Expert preluare, analiză primară şi răspuns la incidente securitate cibernetică; Expert investigaţii digitale şi analiză malware; Expert dezvoltare, implementare şi administrare infrastructuri securitate cibernetică; Expert analiză surse deschise, riscuri şi ameninţări securitate cibernetică; Expert accesare fonduri, implementare şi administrare proiecte securitate cibernetică; Expert legal politici, standardizare de securitate cibernetică; Expert evaluare şi impact financiar securitate cibernetică; Expert politici, strategii şi cooperare securitate cibernetică; Expert dezvoltare competenţe, aptitudini şi cunoştinţe specifice de securitate cibernetică

Observăm că pentru 1/2 dintre poziții este greu de susținut necesitatea unor cunoștințe tehnice de top.

Reținem necesitatea expertizei de înalt nivel pentru restul pozițiilor, dar cum garantăm existența ei?

Răspunsul ni-l dă tot DNSC în regulamentul pentru atestarea și verificarea auditorilor de securitate cibernetică - este necesar să ai minim 2 certificări internaționale (din Anexa 5) și ești reevaluat la fiecare 3 ani.

Însă abordarea propunerii curente implică existența statutului de funcționari publici pentru acești angajați. Adică își pot alege în fiecare an un curs de perfecționare, de la INA sau o companie specializată, la munte sau la mare. Și este nevoie de 2 ani de evaluări negative succesive pentru a fi demis, desigur după finalizarea procesului în justiție.

Adică plătim între 1500 -2000 euro net unor oameni care, când vor fi ieșit la pensie, poate erau la curent cu provocările tehnice din urmă cu 20 de ani, de la data angajării, presupunând desigur că concursul a fost pe bune.

Nu cred că această abordare este oportună.

Ar fi mai bine să se meargă în altă direcție pentru acești angajați:

• prin derogare de la Codul Administrativ, nu sunt funcționari publici
• contractul lor de muncă este pe durată determinată - perioada de valabilitate a celor 2 certificări internaționale
• li se pot încheia succesiv oricâte contracte de muncă cu durată determinată - derogare de la Codul Muncii pe modelul CNIF
• Pot fi adăugate condiții de integritate/incompatibilitate după cum este necesar.

Aceasta ar fi o abordare realistă, care răspunde obiectiv nevoilor DNSC și acomodează principiile asociate aparatului bugetar.

Cliffhanger la Senat pe OUG cloud

A început nouă sesiune parlamentară cu o provocare interesantă ... Legea 428 de aprobare a OUG Cloud Guvernamental. În special Comisia de Apărare a Senatului va avea o primă analiză mâine - cartoful este mare, fierbinte și chiar ironic pentru noi, observatorii din exterior.

Administrația SUA, prin Memorandumul 5G semnat cu România, a reușit să-și excludă marile companii americane de cloud dintre furnizorii administrației publice românești.

Să o luăm metodic.

În aplicarea memorandumului a fost adoptată, cu multe zbateri, Legea 163/2021 „privind adoptarea unor măsuri referitoare la infrastructuri informatice și de comunicații de interes național și condițiile implementării rețelelor 5G”. Deși scrie clar în titlu lumea a rămas doar cu ideea aplicării ei în rețelele operatorilor 5G. În realitate se aplică egal și pentru:

d) infrastructura informatică și de comunicații de interes național - infrastructura informatică și de comunicații esențială pentru menținerea funcțiilor vitale ale societății, a sănătății, siguranței, securității, bunăstării sociale ori economice a persoanelor și a cărei perturbare sau distrugere are un impact semnificativ la nivel național ca urmare a incapacității de a menține respectivele funcții;

cu observația că pentru această zonă nu există sancțiuni în cazul neaplicării ei. (Pentru operatorii de comunicații ANCOM poate amenda cu 1%-5% din cifra de afaceri.)

Aplicarea legii înseamnă că respectiva infrastructură informatică poate conține doar echipamente produse de producători de pe lista aprobată de CSAT. Așa cum este scrisă legea, intră la echipamente și cele de HVAC, ba chiar și simple rack-uri metalice (a fost o discuție cu ANCOM despre autorizarea producătorilor de antene pasive).

Încă din Februarie, când au demarat consultarea pieței, STS și SRI au anunțat că ce vor cumpăra se va supune acestei legi – vor fi acceptați doar producători autorizați. Nimic deosebit până aici.

Ajungem la celebra dezbatere publică din Iunie în urmă căreia, peste noapte, textul OUG-ului a fost schimbat substanțial. O parte dintre schimbări a fost generată de insistența mediului privat, a marilor furnizori de cloud, ca utilizarea cloudului comercial de către instituțiile publice să fie acoperită de OUG pentru a da credibilitate acestor servicii. Așa că s-a abordat și certificarea de securitate a acestora și a apărut:

Art.16 (2) Procedurile de certificare a securității serviciilor de tip cloud public pentru utilizare de către autoritățile publice se stabilesc prin ordin al ministrului cercetării, inovării și digitalizării, cu consultarea prealabilă a SRI și a Directoratului Național de Securitate Cibernetică, denumit în continuare DNSC, cu respectarea prevederilor Legii nr.  163/2021.

Adică un furnizor de cloud care vinde către o autoritate publică trebuie să prezinte o listă cu toți producătorii echipamentelor utilizate iar toți de pe această listă trebuie să fi fost autorizați anterior de România. Îmi este teribil de greu să cred că Microsoft, Google sau Amazon vor face asta. Nici măcar nu ar avea perioada de tranziție de 7 ani pe care o au cei din telecom.

Să recapitulăm:

Art.16 (2) din OUG nu face decât să afirme că autoritățile publice sunt esențiale pentru societate iar blocarea activității lor ar avea un impact semnificativ. Nu este singura afirmație în acest sens, și directiva NIS2 le dă aceeași importanță.

Dacă nu ar exista Art.16, nici viitoarea transpunere a NIS2, atunci o autoritate publică s-ar putea declara ne-esențială și lipsită de semnificație și ar putea utiliza cloud comercial internațional – cumva îmi vine greu să cred asta.

Cloudul comercial internațional nu cred că poate, sau vrea, să se certifice după cerințele legii românești.

Companii de cloud românești ar putea să o facă, lista producătorilor autorizați se va extinde stimulată fiind de achizițiile STS și SRI.

Autoritățile românești care vor continua să consume cloudurile internaționale sunt și mai clar în ilegalitate, dar încă nu există sancțiuni specifice.

Revenind la sesiunea parlamentară.

În infantilismul meu mă așteptam ca acest subiect să producă lupte la baionetă în cadrul excelentelor consultări publice desfășurate pentru normele de aplicare ale OUG-ului. Nu a fost așa, l-au ocolit toți, inclusiv furnizorii de cloud.

Desigur că acestor companii le-ar fi foarte greu să declare ideea autorizării producătorilor de echipamente ca fiind abuzivă cât timp vine de peste ocean, de la ei de acasă.

Desigur că autorităților le-ar fi greu să-i favorizeze cât timp au agresat deja operatorii mobili – cu o cifră de afaceri mult mai mare în România.

Singura soluție îmi pare a fi un amendament de la vreun „parlamentar izolat”. Ar trebui să fie la Senat, care este prima cameră. Poate o lungă perioadă de tranziție.

Să vedem, mai cred și că Comisia Europeană ne privește cu interes, curioasă să vadă dacă favorizăm companiile americane după ce am sugrumat operatorii europeni.

Sau poate nimic nu a fost întâmplător, nici greșit, nici lipsit de viziune și vom extinde această extraordinar de scumpă abordare și către cloudurile comerciale. Singura diferență este că, de această dată, impactul va fi substanțial nu numai pe costuri ci și pe experiența de utilizare.

Contestație proiect PKI CEI (eIDAS #59)

Achiziția infrastructurii PKI care va emite certificatele de pe Cartea Electronică de Identitate este în continuare suspendată.

Joi 1 Septembrie ar fi expirat termenul de manifestare a intenției de a participa în procedura de dialog competitiv.

Însă în 10 August compania TransSped a depus o contestație pentru care încă se luptă chiar dacă a fost respinsă prin decizia CNSC. Remarcabile în contestație sunt următoarele idei:

1️⃣Pentru că la Cluj au fost emise doar 200 de CEI nu are sens să ceri migrarea certificatelor, o problemă complicată pentru un ofertant care nu a furnizat tehnologia aferentă celor 200.

2️⃣MAI & Imprimeria Națională nu spun clar în cât timp se așteaptă să recepționeze instalația, descurajand astfel potențiali participanți. Este adevărat că termenul poate rezulta din dialog însă o valoare maximă ar fi fost dorită.