Cloudul Guvernamental dispune de elemente foarte bune de guvernanță cloud, guvernanță a securității cibernetice, guvernanță a migrării și guvernanță a infrastructurii. Ceea ce este mult mai puțin vizibil în informațiile publice pe care le-am citit este existența unui model integrator de guvernanță IT la nivelul întregului stat/guvernanță a produselor digitale.

ADR descrie CPG drept o platformă națională destinată centralizării și modernizării serviciilor digitale, îmbunătățirii interoperabilității, scalabilității, securității și eficienței.

OUG 89/2022 stabilește responsabilități, prevede un ghid de guvernanță, definește IaaS/PaaS/SaaS, interconectarea prin API-uri, managementul datelor, jurnalizarea/auditul, certificarea de securitate, regulile de migrare și proprietatea/administrarea de către stat a unor componente software importante.

Guvernanța cloud versus guvernanța IT la nivelul întregului stat

În declarația pentru Ziarul Fianciar am spus că un CIO guvernamental ar fi util dacă răspunde de arhitectura şi guvernanţa tehnologică a statului.

Proiectul ADR de migrare ilustrează foarte bine această problemă. Obiectivul CPG este selectarea, modernizarea și migrarea aplicațiilor/sistemelor utilizate de instituțiile publice; cel puțin 30 de aplicații trebuie să devină „cloud-ready”/virtualizate și să fie migrate în cloud. Este o abordare perfect justificată ca program de modernizare. Dar, din perspectiva guvernanței IT la nivel de întreprindere (EGIT), există o întrebare care ar trebui pusă înaintea migrării:

Ar trebui ca această aplicație să continue să existe ca aplicație independentă?

Realitatea este că în instituțiile publice din aceeași categorie, procesele economice sînt aceleași. Să presupunem că 42 de instituții utilizează 25 de aplicații diferite pentru implementarea, în esență, a aceluiași proces economic. Un program de migrare ar putea moderniza și migra cu succes toate cele 25 de aplicații. Din punct de vedere tehnic, proiectul ar fi un succes. Din perspectiva guvernanței IT, însă, statul va rata oportunitatea mult mai importantă: să determine dacă avea nevoie, de fapt, de 25 de aplicații.

Ce lipsește

Să luăm următorul proces ca exemplu: angajament bugetar-recepție-factură-CFP-ordonanțare-plată-contabilizare.

Au nevoie 100 de instituții de 100 de sisteme pentru gestionarea mijloacelor fixe? Au nevoie de aplicații contabile separate? De sisteme bugetare separate? De implementări separate pentru managementul documentelor? De motoare separate pentru fluxurile de achiziții?

În unele cazuri, răspunsul legitim va fi „da”. În multe altele, probabil că nu.

Legislația conține deja unele dintre elementele necesare unui model mai puternic. Ea prevede explicit SaaS, nu doar găzduirea infrastructurii; interconectarea prin API-uri; politici și standarde comune; proprietatea statului asupra anumitor produse software; precum și mecanisme de licențiere centralizată. De asemenea, stabilește, în anumite condiții, că software-ul dezvoltat și personalizat pentru entitățile găzduite sau care urmează să fie găzduite în CPG constituie proprietatea privată a statului și este administrat de ADR. Dacă statul român deține software dezvoltat din bani publici, o bună guvernanță IT ar trebui să pună întrebarea:

De ce ar trebui ca o altă instituție să achiziționeze din nou un software care îndeplinește, în esență, aceeași funcție?

De aici rezultă direct necesitatea unei guvernanțe a portofoliului de aplicații.

Ce ar face un CIO guvernamental

Sarcina sa principală ar fi să răspundă la întrebarea:

Ce capabilități digitale ar trebui să dețină statul român o singură dată și să le reutilizeze de mai multe ori?

Această funcție ar administra un portofoliu național de aplicații și capabilități și ar clasifica cerințele aproximativ după principiul: Reutilizează-Configurează-Extinde-Achiziționează-Dezvoltă.

O instituție care solicită finanțare pentru un sistem nou ar trebui mai întâi să demonstreze de ce o capabilitate guvernamentală existentă nu îi poate satisface cerințele. Și aici se intersectează guvernanța financiară cu guvernanța IT.

De exemplu, înainte de aprobarea a 5 milioane de euro pentru o nouă aplicație X, procesul de guvernanță ar trebui să verifice dacă un alt minister/autoritate/instituție nu deține deja un produs echivalent finanțat de stat; dacă procesele de business sînt identice din punct de vedere legal; dacă un produs existent poate deveni multi-tenant; dacă un API sau un serviciu comun poate rezolva cerința; și abia apoi dacă este justificată o nouă achiziție.

Securitatea cibernetică îmi întărește argumentul

CISO caută răspuns la întrebarea: Cum securizăm această aplicație?

CIO caută răspuns la întrebarea: De ce avem 47 de aplicații de securizat, dacă poate cinci produse comune ar putea îndeplini aceleași funcții?

Reducerea diversității inutile a aplicațiilor reduce suprafața de atac, dependențele software învechite, variațiile în managementul patch-urilor, numărul conturilor privilegiate, configurațiile neuniforme, dependențele de furnizori și complexitatea monitorizării de către SOC. Aplicațiile comune vor crea un risc de concentrare, motiv pentru care necesită izolarea tenant-urilor, arhitectură Zero Trust și mecanisme solide de reziliență. Dar aceasta este o problemă arhitecturală care poate fi gestionată explicit. CIO ar impune: identitate centralizată cu MFA și managementul accesului privilegiat; autorizare cu privilegii minime/zero-trust; criptare în tranzit și în repaus cu managementul cheilor separat corespunzător; înregistrare în jurnal de audit imuabilă; API-uri în loc de integrări DB- la-DB; management centralizat al vulnerabilităților și dependențelor; testare obligatorie securizată SDLC/SAST/DAST/compoziție software; testare independentă de penetrare; aplicare centralizată rapidă de patch-uri; copii de rezervă offline/imuabile; și mecanisme testate de recuperare în caz de dezastru.

Autoritatea centrală/instituția de produs garantează că, de exemplu, aplicația financiară în sine este actualizată și securizată din punct de vedere tehnic. Însă directorul Instituției X rămâne responsabil pentru stabilirea faptului că Maria Popescu poate aproba plăți de până la X lei și pentru retragerea acestei autorizații atunci când își schimbă locul de muncă.

Cîteva concluzii

Programul Cloudului Guvernamental din România demonstrează existența unei guvernanțe în domeniul infrastructurii cloud, securității cibernetice, migrării și interoperabilității.

Pe baza informațiilor disponibile public, este mult mai puțin evidentă existența unei funcții superioare de guvernanță IT la nivelul întregului stat. Cadrul normativ al Cloudului Guvernamental instituie o guvernanță solidă a infrastructurii, securității, interoperabilității și migrării în cloud. În schimb, nu rezultă explicit existența unui mecanism de guvernanță a portofoliului de aplicații la nivelul întregii administrații publice, care să decidă sistematic când o capabilitate digitală trebuie dezvoltată o singură dată și reutilizată de mai multe instituții, în locul dezvoltării sau achiziției unor aplicații paralele.

Decalajul se află între guvernanța cloudului și guvernanța patrimoniului IT al statului ca portofoliu de capabilități de business și produse digitale. Prin CPG România construiește infrastructura tehnologică comună. Următoarea provocare de guvernanță IT este să decidă ce ar trebui să ruleze pe această infrastructură, câte versiuni ale aceleiași capabilități ar trebui să finanțeze statul și cine are autoritatea de a lua această decizie.