Migrare în cloudul guvernamental pentru aplicațiile instituțiilor publice

Probleme pe care le rezolvăm

Nu pornim de la tehnologie. Pornim de la situația concretă în care se află instituția — și de cele mai multe ori este una dintre acestea.

Ce înseamnă, de fapt, migrarea în Cloudul Privat Guvernamental

NERDS.SH nu reprezintă ADR, STS, SRI sau DNSC și nu are acces privilegiat la infrastructurile administrate de acestea. Lucrăm la nivelul aplicației și al infrastructurii pe care o controlați, pentru ca cerințele tehnice de intrare să fie îndeplinite. Decizia de acceptare aparține administratorului infrastructurii.

Servicii disponibile

Fiecare serviciu are obiect definit, livrabile, termen și condiții de prestare, ca să poată fi evaluat, bugetat și contractat fără o fază lungă de clarificări.

Livrabilele se adaptează după evaluarea inițială. Nu recomandăm Kubernetes pentru orice aplicație — propunem o arhitectură proporțională cu necesitatea reală.

De la incident la operare stabilă

Majoritatea furnizorilor acoperă un singur pas: hosting, dezvoltare web, mentenanță, scanare de vulnerabilități sau consultanță. Noi acoperim întregul traseu, iar fiecare etapă se încheie cu ceva pe care instituția îl poate folosi.

1. 01

   Incident sau vulnerabilitate

   Preluăm controlat infrastructura și facem un backup inițial, ca datele să fie conservate înainte de orice modificare.

2. 02

   Stabilizare

   Izolăm componentele afectate, aplicăm remedierile imediate și repunem serviciul în funcțiune.

3. 03

   Audit

   Inventariem codul, dependențele, baza de date și integrările, apoi clasificăm ce se migrează, ce se modernizează, ce se rescrie și ce se retrage.

4. 04

   Modernizare

   Rescriem sau înlocuim componentele care nu mai pot fi operate în siguranță, păstrând conținutul și arhiva publică.

5. 05

   Infrastructură

   Construim infrastructura cu Terraform: medii separate, secrete gestionate, backup și observabilitate.

6. 06

   Migrare

   Migrăm datele și traficul controlat, cu testare și cu plan de rollback stabilit din timp.

7. 07

   Operare

   Monitorizăm, actualizăm, testăm procedura de restaurare și răspundem la incidente în condițiile agreate.

8. 08

   Predare

   Documentație, proceduri de operare și transfer de cunoștințe, ca instituția să nu rămână dependentă de un singur furnizor.

Vocabularul, explicat pe scurt

Termenii următori apar în orice caiet de sarcini și în orice ofertă de furnizor. Nu trebuie să le stăpâniți — dar merită să puteți distinge dacă un furnizor vă propune ceva proporțional cu necesitatea reală.

Cloud Privat Guvernamental (CPG)

Servere, spațiu de stocare și rețea puse la dispoziția instituțiilor publice în centre de date ale statului. Vi se alocă capacitate; nu cumpărați echipamente.

IaaS, PaaS și SaaS

La IaaS primiți mașini virtuale și rețea, iar aplicația și întreținerea ei rămân la dumneavoastră. La PaaS primiți și platforma pe care rulează aplicația. La SaaS primiți aplicația gata făcută. CPG oferă toate trei — iar diferența stabilește cine răspunde când ceva nu merge.

OpenStack

Software-ul care transformă un set de servere fizice într-un cloud privat. „Migrare în OpenStack" înseamnă mutarea aplicației pe o astfel de platformă — nu pe un serviciu comercial din altă țară.

Containere

Aplicația împachetată împreună cu tot ce îi trebuie ca să ruleze. Pornește identic pe laptopul dezvoltatorului și în centrul de date, iar asta face migrarea previzibilă în loc de pariu.

Kubernetes

Sistemul care pornește, repornește și distribuie containerele pe mai multe servere. Util când serviciul trebuie să reziste la căderea unui server. Nu este necesar pentru un site de prezentare — iar un furnizor care îl propune pentru așa ceva merită întrebat de ce.

Terraform / Infrastructure as Code

Infrastructura scrisă în fișiere text, ca o rețetă. Mediul poate fi recreat identic oricând și fiecare modificare rămâne înregistrată — spre deosebire de configurările făcute manual, pe care nimeni nu le mai poate reproduce după ce pleacă omul care le-a făcut.

CI/CD

Lansarea automată a versiunilor noi. Elimină o categorie întreagă de erori umane și face rapidă revenirea la versiunea anterioară.

Backup și disaster recovery

Backup-ul este copia datelor. Disaster recovery este procedura testată prin care serviciul revine — în cât timp și cu ce pierdere de date acceptată. Un backup care nu a fost restaurat niciodată nu este o strategie.

High availability (disponibilitate ridicată)

Aplicația continuă să funcționeze când un server cade, pentru că rulează în mai multe exemplare. Costă mai mult. Se justifică pentru servicii folosite zilnic de cetățeni, nu pentru orice pagină.

Observabilitate / monitorizare

Posibilitatea de a vedea în orice moment dacă serviciul funcționează și de ce nu funcționează. Fără ea, aflați de la cetățeni că site-ul este căzut.

Rollback

Revenirea la versiunea anterioară, funcțională, când o lansare merge prost. Se pregătește dinainte, nu se improvizează în timpul incidentului.

Legacy

O aplicație încă folosită, dar construită pe tehnologie care nu mai primește actualizări. Nu e o chestiune de vechime, ci de dacă mai poate fi securizată și mutată.

Întrebări frecvente

Ce este Cloudul Privat Guvernamental, pe scurt?

Servere, spațiu de stocare și rețea puse la dispoziția autorităților și instituțiilor publice în centre de date ale statului, în locul unui server ținut în sediul propriu sau la un furnizor comercial de hosting. ADR este beneficiar și autoritate contractantă, STS este beneficiar și partener, iar SRI este partener de securitate prin Centrul Național Cyberint. Finanțarea vine din Planul Național de Redresare și Reziliență, Componenta 7. Se oferă servicii de tip IaaS, PaaS și SaaS: vi se alocă capacitate, nu cumpărați echipamente.

Putem muta pur și simplu serverul actual acolo?

Aproape niciodată. Nu se mută serverul, se mută aplicația. Infrastructura are cerințe de intrare: componente care mai primesc actualizări de securitate, o aplicație care poate fi pornită automat, cod sursă complet, autentificare definită, copii de siguranță testate. O aplicație care nu le îndeplinește este refuzată indiferent de capacitatea disponibilă — de aceea auditul de pregătire vine înaintea oricărei migrări.

Cine decide dacă aplicația noastră este acceptată?

Administratorul infrastructurii-țintă. Nu reprezentăm ADR, STS, SRI sau DNSC și nu avem acces privilegiat la ce administrează acestea. Ce putem face este să aducem aplicația în starea în care cerințele tehnice sunt îndeplinite și să predăm documentația care o dovedește.

Instituția noastră nu este în programul național. Ce facem?

Țintele publicate ale programului privesc instituții ale administrației publice centrale, migrate prin furnizori contractați centralizat. Majoritatea autorităților locale nu se află în acele loturi, deci pregătirea aplicației și alegerea furnizorului le rămân în sarcină — exact activitatea descrisă în această pagină, care poate fi contractată direct în condițiile Legii nr. 98/2016.

Puteți interveni dacă am primit deja o notificare sau un raport de vulnerabilitate?

Da. Începem prin preluarea controlată a infrastructurii și un backup inițial, ca datele să fie conservate înainte de orice modificare. Apoi evaluăm vulnerabilitățile critice, izolăm componentele afectate și stabilim planul de remediere. Ne angajăm la mobilizare și evaluare rapidă — nu la un termen fix de rezolvare stabilit înainte de analiză.

În cât timp primim o ofertă?

Răspundem solicitării în aceeași zi lucrătoare, cu încadrarea preliminară, serviciul recomandat și pașii necesari ofertării. Oferta tehnică și financiară urmează după ce înțelegem accesul disponibil și starea reală a aplicației.

Ce facem dacă furnizorul inițial nu mai răspunde sau codul sursă este incomplet?

Este una dintre cele mai frecvente situații. Pornim de la ce există efectiv: aplicația în funcțiune, baza de date, configurările de pe server. Reconstruim inventarul tehnic, documentăm dependențele și stabilim ce se poate recupera, ce trebuie reconstruit și ce poate fi retras.

Aplicația poate fi mutată direct în infrastructura guvernamentală?

Rareori direct. O aplicație cu componente depășite, cu dependențe care nu mai pot fi actualizate sau fără deployment automat poate fi respinsă la intrarea în noua infrastructură. Auditul de pregătire a migrării stabilește exact ce trebuie modernizat înainte de mutare.

Este nevoie de Kubernetes?

Nu pentru orice aplicație. Pentru site-uri și portaluri simple recomandăm o arhitectură proporțională cu cerința. Kubernetes este justificat atunci când disponibilitatea, scalarea și complexitatea operațională o cer efectiv.

Avem backup. Este suficient?

Un backup neverificat nu este o strategie de recuperare. Testăm restaurarea efectivă, măsurăm cât durează și documentăm procedura, ca instituția să cunoască timpul real de revenire înainte de incident, nu în timpul lui.

Serviciile pot fi contractate prin achiziție directă?

Serviciile sunt definite cu obiect, livrabile, termen și condiții de prestare, astfel încât să poată fi achiziționate direct în condițiile Legii nr. 98/2016. Decizia asupra procedurii aparține autorității contractante, în funcție de valoarea estimată a întregii necesități.

Puteți publica serviciul în catalogul electronic SEAP?

Da. Transmitem la cerere fișa tehnică, codul CPV corespunzător și reperul din catalogul electronic SEAP, împreună cu oferta tehnică și financiară.

Se pot păstra conținutul și istoricul site-ului actual?

Da. Preluarea și structurarea conținutului, împreună cu migrarea arhivei publice, fac parte din pachetul de modernizare. Păstrarea arhivei publice este de obicei o cerință, nu o opțiune.

Ce se întâmplă după migrare?

Putem prelua operarea prin abonament lunar sau contract anual: monitorizare, actualizări, backup, testarea restaurării, managementul certificatelor, revizuiri de securitate, raportare și managementul incidentelor.