Integrarea unui sistem informațional cu MConnect presupune atât obținerea dreptului legal de acces la date, cât și configurarea tehnică necesară pentru comunicarea securizată dintre sisteme.

Unul dintre elementele tehnice esențiale este certificatul de sistem. Acesta permite identificarea și autentificarea aplicației care comunică cu MConnect și nu trebuie confundat cu semnătura electronică a administratorului sau cu certificatul SSL public al site-ului.

Ce este MConnect?

MConnect este Platforma guvernamentală de interoperabilitate a Republicii Moldova. Prin intermediul acesteia, sistemele informaționale autorizate pot furniza sau consuma date din registre și alte surse administrative.

Platforma este administrată de Agenția de Guvernare Electronică, iar operatorul tehnico-tehnologic este Serviciul Tehnologia Informației și Securitate Cibernetică – STISC.

Catalogul serviciilor și procedura de conectare sunt disponibile pe portalul MConnect.

Certificatul tehnic nu oferă automat acces la date

Obținerea certificatului reprezintă doar o parte a integrării. Certificatul identifică sistemul în cadrul comunicării tehnice, însă accesul efectiv la date este acordat separat, în baza:

• cererii de conectare;
• scopului declarat al utilizării datelor;
• temeiului legal;
• aprobării serviciilor și seturilor de date solicitate;
• anexei tehnice de integrare;
• drepturilor configurate în MConnect.

Prin urmare, procesul trebuie început prin coordonarea integrării cu Agenția de Guvernare Electronică.

1. Identificarea serviciilor MConnect necesare

Organizația trebuie să stabilească ce date dorește să consume sau să furnizeze prin MConnect.

Pentru fiecare flux de date este necesar să fie clarificate:

• sistemul informațional care va utiliza datele;
• serviciile sau seturile de date necesare;
• scopul utilizării;
• temeiul juridic;
• categoriile de utilizatori;
• frecvența estimată a solicitărilor;
• mediile necesare: test și producție;
• persoanele responsabile de integrare.

Serviciile disponibile pot fi consultate în Catalogul semantic publicat pe portalul MConnect.

2. Depunerea cererii de conectare

Organizația înaintează cererea de conectare și de acordare a accesului la serviciile necesare.

În funcție de tipul participantului și de datele solicitate, pot fi necesare:

• cererea oficială de conectare;
• justificarea scopului și a temeiului legal;
• informații despre sistemul informațional;
• datele persoanelor responsabile;
• descrierea fluxului de schimb de date;
• documente privind protecția datelor;
• contractul de utilizare a MConnect, în cazul participanților privați;
• anexa tehnică pentru fiecare flux de integrare.

Pentru organizațiile private, utilizarea MConnect poate fi supusă contractării și tarifelor aplicabile.

3. Coordonarea parametrilor certificatului

Înainte de generarea CSR-ului, echipa tehnică trebuie să solicite confirmarea cerințelor pentru certificat de la AGE sau STISC.

Trebuie confirmate cel puțin:

• algoritmul și lungimea cheii;
• formatul câmpului Subject;
• valoarea obligatorie pentru Common Name – CN;
• includerea denumirii organizației și a sistemului;
• necesitatea extensiei Subject Alternative Name;
• existența certificatelor distincte pentru test și producție;
• perioada de valabilitate;
• formatul în care va fi emis certificatul.

Valoarea CN nu trebuie stabilită arbitrar. Aceasta trebuie completată conform convenției comunicate pentru proiectul concret de integrare.

4. Generarea cheii private și a CSR-ului

CSR-ul — Certificate Signing Request — se generează în infrastructura în care certificatul va fi utilizat.

Un exemplu de comandă OpenSSL este:

openssl req -new -newkey rsa:2048 -nodes \  -keyout mconnect-prod.key \  -out mconnect-prod.csr \  -sha256

Datele pot fi completate orientativ astfel:

C  = MD O  = Denumirea juridică a organizației OU = Denumirea sistemului informațional CN = Valoarea confirmată de AGE/STISC

Parametrii exacți trebuie utilizați numai după confirmarea cerințelor tehnice aplicabile integrării.

În urma comenzii sunt create două fișiere:

• mconnect-prod.key — cheia privată;
• mconnect-prod.csr — cererea de emitere a certificatului.

5. Protejarea cheii private

Cheia privată este elementul sensibil al certificatului și trebuie protejată corespunzător.

Aceasta:

• nu se transmite prin e-mail;
• nu se atașează la cererea adresată STISC;
• nu se include în repository-ul proiectului;
• nu se păstrează în foldere publice;
• nu se transmite furnizorilor sau altor persoane;
• trebuie accesată numai de serviciul și administratorii autorizați.

Către autoritatea de certificare se transmite doar CSR-ul. Este recomandată utilizarea unor chei și certificate separate pentru mediile de test și producție.

6. Verificarea CSR-ului

Înainte de transmitere, conținutul CSR-ului poate fi verificat cu următoarea comandă:

openssl req -in mconnect-prod.csr -noout -text -verify

Pentru afișarea rapidă a datelor despre titular:

openssl req -in mconnect-prod.csr -noout -subject

Echipa trebuie să verifice în special denumirea organizației, sistemul informațional și valoarea CN.

7. Solicitarea certificatului de la STISC

Solicitarea se transmite, de regulă, în numele organizației care deține sau utilizează sistemul informațional.

Dosarul poate include, în funcție de cerințele comunicate:

• scrisoarea oficială de solicitare;
• CSR-ul generat;
• denumirea sistemului informațional;
• indicarea mediului de test sau producție;
• datele persoanei responsabile;
• referința la integrarea coordonată cu AGE;
• formularul sau documentele suplimentare solicitate de STISC.

STISC emite certificatele cheilor publice în baza cererilor depuse. Datele de contact și informațiile actualizate despre serviciile de certificare sunt disponibile pe site-ul STISC.

8. Instalarea certificatului

După emitere, certificatul este instalat împreună cu cheia privată generată anterior.

În funcție de tehnologia aplicației, pot fi necesare:

• certificatul sistemului;
• cheia privată;
• certificatul intermediar;
• certificatul autorității rădăcină;
• conversia într-un container PKCS#12/PFX;
• configurarea trust store-ului;
• configurarea autentificării mutuale TLS;
• configurarea semnării solicitărilor.

Dacă aplicația necesită un fișier PFX, acesta poate fi creat astfel:

openssl pkcs12 -export \  -out mconnect-prod.pfx \  -inkey mconnect-prod.key \  -in mconnect-prod.crt \  -certfile issuing-ca.crt

Fișierul PFX conține cheia privată și trebuie protejat la același nivel ca fișierul .key.

9. Înregistrarea certificatului în MConnect

Certificatul public trebuie asociat sistemului informațional și drepturilor aprobate în MConnect.

După înregistrare se efectuează:

• verificarea conexiunii;
• testarea autentificării;
• apelarea serviciilor autorizate;
• verificarea răspunsurilor;
• testarea jurnalizării și trasabilității;
• validarea scenariilor de eroare;
• acceptarea tehnică înainte de activarea în producție.

Un certificat valid nu compensează lipsa drepturilor de acces. Dacă sistemul se autentifică, dar nu este autorizat pentru serviciul solicitat, MConnect va refuza operațiunea.

10. Reînnoirea certificatului

Certificatele au o perioadă limitată de valabilitate. Organizația trebuie să monitorizeze data expirării și să înceapă reînnoirea din timp.

Cadrul MConnect prevede informarea autorității competente despre certificatele noi cu cel puțin 10 zile lucrătoare înainte de expirarea celor utilizate curent.

Este recomandată:

• monitorizarea automată a expirării;
• inițierea reînnoirii cu 30–45 de zile înainte;
• testarea certificatului nou înainte de înlocuire;
• planificarea schimbării fără întreruperea serviciului;
• revocarea certificatului compromis sau care nu mai este utilizat.

Greșeli frecvente

Cele mai întâlnite probleme în procesul de certificare și integrare sunt:

• generarea CSR-ului înainte de confirmarea valorii CN;
• confundarea certificatului de sistem cu certificatul SSL al domeniului;
• utilizarea aceluiași certificat pentru test și producție;
• transmiterea accidentală a cheii private;
• generarea cheii pe calculatorul unui dezvoltator, nu în infrastructura beneficiarului;
• solicitarea certificatului pe numele companiei IT, deși sistemul aparține clientului;
• presupunerea că certificatul acordă automat acces la toate serviciile;
• lipsa monitorizării datei de expirare;
• păstrarea parolelor PFX în codul sursă sau în fișiere de configurare neprotejate.

Cine trebuie să solicite certificatul?

În mod normal, certificatul trebuie emis pentru organizația și sistemul informațional care participă la schimbul de date.

Compania IT poate:

• analiza serviciile necesare;
• pregăti documentația tehnică;
• genera CSR-ul în infrastructura clientului;
• configura certificatul;
• implementa integrarea;
• testa serviciile MConnect;
• pregăti procedura de reînnoire.

Cererea oficială și justificarea dreptului de acces la date rămân însă responsabilitatea organizației beneficiare.

Cum poate ajuta Indrivo

Indrivo poate asigura întregul proces tehnic de integrare cu MConnect:

• analiza fluxurilor de date;
• identificarea serviciilor necesare;
• pregătirea anexelor tehnice;
• generarea și validarea CSR-ului;
• integrarea certificatelor;
• dezvoltarea serviciilor de consum sau furnizare a datelor;
• testarea în mediul de integrare;
• pregătirea lansării în producție;
• monitorizarea și reînnoirea certificatelor.

O integrare reușită cu MConnect nu înseamnă doar instalarea unui certificat. Ea presupune alinierea cerințelor juridice, operaționale, de securitate și dezvoltare software într-un flux unic și controlat.

Notă: Cerințele tehnice și administrative pot fi actualizate. Înainte de generarea CSR-ului și depunerea dosarului, trebuie confirmate instrucțiunile aplicabile direct cu Agenția de Guvernare Electronică și STISC.