Cloud suveran pentru ministerele apărării: rezidența datelor, planuri de control și arhitectură națională

Fiecare minister al apărării care a mutat sarcini de lucru în cloud ajunge în cele din urmă în fața aceleiași tensiuni: hiperscalerii comerciali furnizează capacități — baze de date administrate, platforme AI/ML, rețele globale — pe care niciun furnizor național nu le poate egala, dar aceiași hiperscaleri sunt corporații străine supuse procesului juridic al guvernului lor de origine, controalelor de export și cererilor de acces ale comunității de informații. Termenul „cloud suveran” descrie încercarea de a rezolva această tensiune fără a accepta vreunul dintre extreme: nici dependența completă de hiperscaleri, nici un mainframe național înghețat tehnologic. Arhitectura care rezultă nu este niciodată simplă, iar compromisurile rareori sunt evidente până când nu au fost deja făcute în producție.

Acest articol examinează arhitectura tehnică a cloud-ului suveran pentru ministerele apărării — nu ca listă de verificare pentru achiziții, ci ca problemă de inginerie. Acoperim ce înseamnă de fapt suveranitatea în fiecare dintre cele trei dimensiuni ale ei, cum se proiectează un plan de control național care supraviețuiește perturbărilor furnizorului, ce componente ale hiperscalerilor introduc riscuri de suveranitate inacceptabile, cum arată stiva suverană open-source în producție și cum se echilibrează constrângerile de suveranitate cu cerințele operaționale de capacitate ale apărării moderne. Pentru contextul mai larg al cerințelor de securitate a sarcinilor de lucru, consultați ghidul nostru despre securitatea sarcinilor de lucru militare în cloud.

1. Ce înseamnă suveranitatea cloud pentru un minister al apărării

Expresia „cloud suveran” este folosită de furnizori ca să însemne aproape orice — un centru de date din țară, un angajament contractual de rezidență a datelor, o entitate juridică locală — și aproape nimic din ce înseamnă în marketingul furnizorilor nu este suficient pentru o revizuire arhitecturală serioasă a unui minister al apărării. Suveranitatea cloud reală pentru apărare cuprinde trei cerințe distincte, care trebuie evaluate independent, pentru că satisfacerea uneia nu implică satisfacerea celorlalte.

Rezidența datelor este garanția că datele clasificate sau sensibile sunt stocate, prelucrate și transmise exclusiv pe teritoriul național sau într-o graniță jurisdicțională aprobată — și că ministerul, nu furnizorul de cloud, controlează cheile de criptare care le protejează. Rezidența datelor este cerința de suveranitate cel mai des discutată și cea mai ușor de falsificat: un angajament contractual că datele vor rămâne în țară nu este aplicabil juridic împotriva unei citații de informații a unui guvern străin și nu oferă nicio protecție tehnică împotriva unei sarcini de replicare configurate greșit, care copiază datele într-o zonă de disponibilitate din afara țării.

Suveranitatea operațională este capacitatea de a continua operarea platformei cloud fără cooperarea continuă a oricărui furnizor străin — inclusiv capacitatea de a supraviețui insolvenței furnizorului, sancțiunilor comerciale, schimbărilor de control al exporturilor sau unei situații în care un guvern străin obligă furnizorul să refuze sau să degradeze serviciul. Suveranitatea operațională cere ca ministerul să poată opera fiecare componentă a platformei doar din documentație și cod sursă, fără nicio dependență continuă de suport proprietar al furnizorului, care ar putea fi retras.

Suveranitatea lanțului de aprovizionare este controlul asupra componentelor software și hardware folosite pentru construirea și operarea cloud-ului. O platformă construită pe software open-source auditabil, rulând pe servere ale unui producător non-aliat, nu satisface nicio dimensiune: stratul software poate fi auditabil, dar firmware-ul hardware poate să nu fie. O analiză completă a suveranității lanțului de aprovizionare acoperă firmware-ul procesoarelor, sistemele de operare ale echipamentelor de rețea, firmware-ul controllerelor de stocare și dependențele de biblioteci software ale fiecărei componente din stiva suverană.

Majoritatea arhitecturilor actuale de cloud suveran ale ministerelor apărării satisfac parțial rezidența datelor, parțial suveranitatea operațională și minim suveranitatea lanțului de aprovizionare. Scopul explicitării celor trei dimensiuni este să permită o evaluare onestă a riscurilor, nu o asigurare falsă din partea unei certificări „cloud suveran” care adresează doar cea mai vizibilă dimensiune.

2. Impunerea rezidenței datelor

Controalele tehnice de rezidență a datelor operează pe trei straturi: rezidența cheilor de criptare, aplicarea politicilor de locație a datelor și auditul și verificarea. Toate trei sunt necesare; oricare dintre ele, singură, este insuficientă.

Rezidența cheilor de criptare este cel mai important control tehnic, pentru că determină dacă datele pot fi decriptate în afara graniței aprobate chiar dacă sunt exfiltrate fizic. Cerința este ca modulul de securitate hardware (HSM) sau serviciul de gestiune a cheilor (KMS) care deține cheile de criptare a datelor să fie amplasat fizic pe teritoriul național și sub controlul operațional al ministerului sau al unei organizații acreditate național — nu un KMS administrat al unui furnizor străin de cloud, unde materialul de chei final este păstrat în hardware controlat de furnizor. În practică, aceasta înseamnă:

• HSM on-premises (Thales Luna, Utimaco SecurityServer sau echivalent) pentru nivelurile de clasificare cele mai înalte, cu HSM-ul securizat fizic și auditat conform politicii de securitate fizică a ministerului
• KMS al unui furnizor național de cloud, susținut de hardware HSM din țară, pentru nivelurile de clasificare inferioare în care serviciile administrate de chei sunt acceptabile
• Criptare cu plic: cheile de criptare a datelor (DEK) sunt generate per obiect sau per volum și criptate cu chei de criptare a cheilor (KEK) păstrate în HSM — HSM-ul nu deține niciodată date brute, doar material de chei
• Jurnalizarea accesului la chei, separată de și independentă de jurnalul de audit al sistemului de stocare, astfel încât încercările neautorizate de acces la chei să fie vizibile chiar dacă stratul de stocare este compromis

Aplicarea politicilor de locație a datelor cere ca serviciile de stocare — stocare de obiecte, volume de bloc, instanțe de baze de date — să fie restricționate la zone de disponibilitate din țară la nivelul configurației platformei, nu doar prin declarație de politică. Într-o dislocare OpenStack, aceasta înseamnă configurarea în Cinder și Swift a regulilor de afinitate de zonă de disponibilitate care împiedică plasarea replicilor în afara zonei definite. Într-o dislocare pe hiperscaler, aceasta înseamnă folosirea politicilor de control al serviciilor (AWS) sau a definițiilor Azure Policy care refuză crearea oricărei resurse de stocare în regiuni din afara țării, aplicate la nivelul contului de management sau al grupului de management, astfel încât echipele individuale de sarcini de lucru să nu le poată suprascrie.

Auditul și verificarea sunt procesul operațional continuu care confirmă că măsurile de control ale rezidenței datelor funcționează conform proiectului. Stratul de audit trebuie să fie independent de stratul de stocare — entitatea care stochează datele nu poate fi singura entitate care verifică unde sunt stocate datele. Componente necesare:

• Verificare automată zilnică că toate punctele terminale de stocare folosite de sarcinile de lucru se rezolvă la adrese IP din țară, cu alertare la orice punct terminal nou
• Monitorizarea fluxurilor de rețea care semnalează orice trafic de ieșire către intervale IP din afara țării provenit din serviciile de stocare
• Audit tehnic trimestrial efectuat de terți asupra controalelor de rezidență a datelor, cu constatările raportate autorității de securitate a ministerului
• Configuration-as-code pentru toate politicile de locație a datelor, versionate într-un depozit imuabil, astfel încât schimbările de politică să genereze un diff detectabil înainte de a intra în vigoare

Controalele contractuale — acorduri de prelucrare a datelor, clauze de localizare a datelor — sunt un complement necesar al controalelor tehnice, dar nu ar trebui să fie niciodată mecanismul principal. Contractele constrâng ce va face un furnizor cooperant; nu constrâng ce face un furnizor sub constrângere juridică din partea guvernului său de origine și nu oferă nicio protecție împotriva configurării tehnice greșite.

3. Proiectarea planului de control național

Planul de control al unei platforme cloud — ansamblul de servicii care administrează orchestrarea, identitatea și secretele — este acolo unde trăiește riscul de suveranitate cu cel mai mare impact. Într-un mediu Kubernetes, componentele planului de control sunt serverul API, clusterul etcd, scheduler-ul, controller manager-ul și admission webhook-urile care impun politica la momentul creării sarcinilor de lucru. Dacă oricare dintre aceste componente rulează pe infrastructură administrată de personalul operațional al unui hiperscaler străin, acel personal are capacitatea tehnică (chiar dacă interzisă contractual) de a modifica configurațiile sarcinilor de lucru, de a extrage secrete din etcd sau de a perturba programarea la indicația guvernului său de origine.

O proiectare de plan de control național plasează toate aceste componente pe infrastructură aflată fizic și organizațional sub controlul ministerului. Arhitectura practică:

Serverul API Kubernetes și etcd. Dislocați o distribuție Kubernetes autogestionată — kubeadm pentru flexibilitate maximă, k0s pentru operațiuni simplificate sau Talos Linux pentru o abordare cu SO imuabil — pe baremetal sau mașini virtuale rulând pe hipervizoare controlate de minister. Clusterul etcd cere trei sau cinci noduri pentru cvorum, rulând pe hardware dedicat care nu este partajat cu nodurile de sarcini de lucru. Datele etcd trebuie criptate în repaus folosind pluginul de provider KMS conectat la HSM-ul național. Faceți copii de siguranță ale instantaneelor etcd în stocare de obiecte criptată din țară, cu testare automată a restaurării.

# Example kube-apiserver flag for national KMS encryption provider
--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

# encryption-config.yaml (excerpt)
resources:
  - resources: [secrets, configmaps]
    providers:
      - kms:
          name: national-hsm-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          cachesize: 1000
          timeout: 3s
      - identity: {}

Furnizorul de identitate. Keycloak este furnizorul standard open-source de identitate OIDC/SAML pentru dislocările cloud suverane. Dislocați Keycloak pe infrastructură națională dedicată, integrat cu directorul existent al ministerului (Active Directory sau LDAP prin conectorii de federație ai Keycloak). Configurați serverul API Kubernetes să folosească Keycloak ca autentificator OIDC:

# kube-apiserver OIDC flags
--oidc-issuer-url=https://keycloak.national.mil/realms/defense
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/keycloak-ca.crt

Disponibilitatea Keycloak este acum pe calea critică pentru autentificarea clusterului. Dislocați-o în mod de înaltă disponibilitate (minimum trei instanțe Keycloak în spatele unui balanser de sarcină intern, cu cache distribuit pentru starea sesiunilor) și documentați procedura de urgență break-glass pentru accesul la serverul API atunci când Keycloak este indisponibil — de regulă un kubeconfig local cu un certificat de client pentru acces de urgență la cluster-admin, păstrat într-un loc securizat fizic.

Gestiunea secretelor. HashiCorp Vault (sau ramura sa open-source OpenBao), dislocat pe infrastructură națională, furnizează stratul de gestiune a secretelor. Vault se deschide automat (auto-unseal) folosind HSM-ul național, eliminând procesul manual de unseal care altfel ar fi un punct unic de defectare pentru recuperarea planului de control. Jurnalul de audit al Vault — fiecare citire și fiecare scriere de secret — este transmis în timp real către SIEM-ul național, în afara razei de impact a unei dislocări Vault compromise.

4. Evaluarea dependenței de hiperscaleri

Majoritatea mediilor cloud ale ministerelor apărării folosesc cel puțin un hiperscaler pentru un anumit nivel al infrastructurii lor — fie pentru o topologie suveran conectată, pentru o zonă de recuperare în caz de dezastru, fie pentru sarcini de lucru moștenite, încă nemigrate. Înțelegerea căror componente de hiperscaler introduc risc de suveranitate este esențială pentru decizia administrat sau autogestionat, luată pentru fiecare componentă.

Risc ridicat de suveranitate — trebuie înlocuite sau operate independent:

• Plane de control Kubernetes administrate (EKS, AKS, GKE) — serverul API și etcd sunt operate de personalul hiperscalerului cu acces privilegiat; înlocuiți-le cu Kubernetes autogestionat pe primitive IaaS
• Furnizori de identitate administrați (AWS IAM, Azure Active Directory ca IdP primar) — asertări de identitate autoritative făcute de servicii operate de străini; înlocuiți-le cu Keycloak sau echivalent pe infrastructură națională
• Depozite de secrete administrate (AWS Secrets Manager, Azure Key Vault cu HSM-uri controlate de hiperscaler) — material de chei păstrat în HSM-uri străine; înlocuiți-le cu Vault autogestionat pe HSM național
• Rețele CDN și edge globale — trafic direcționat prin puncte de prezență din afara țării; dezactivați-le sau restricționați-le doar la noduri edge din țară

Risc mediu de suveranitate — acceptabile cu controale suplimentare:

• Stocarea de obiecte a hiperscalerului într-o zonă de disponibilitate din țară — acceptabilă dacă este criptată cu chei controlate de minister, provenite dintr-un HSM național, cu replicarea blocată la zonele din țară
• Baze de date administrate ale hiperscalerului în zone din țară — acceptabile pentru date neclasificate dacă gestiunea cheilor de criptare este națională, cu replicarea inter-regiuni dezactivată
• Rețelele virtuale ale hiperscalerului — VPC-uri, subrețele, grupuri de securitate sunt primitive IaaS cu risc scăzut; riscul de suveranitate stă în planul de control care le administrează, nu în primitivele înseși

Risc mai mic de suveranitate:

• Calcul IaaS (mașini virtuale) fără cadre de agenți administrați — hiperscalerul furnizează hardware-ul; ministerul operează stiva software și controlează toată criptarea
• Stocarea de bloc cu chei gestionate de client, provenite dintr-un KMS național — hiperscalerul deține blocuri criptate care nu pot fi decriptate fără cheia deținută de minister

Rezultatul evaluării este o hartă a riscurilor la nivel de componentă, nu o decizie binară „folosește hiperscaler” sau „nu folosi hiperscaler”. Majoritatea arhitecturilor cloud suverane vor păstra unele componente de hiperscaler la stratul IaaS, în timp ce înlocuiesc componentele planului de control și de identitate cu alternative naționale. Pentru o privire mai largă asupra modelelor de dislocare și a implicațiilor lor de clasificare, consultați articolul nostru despre modelele de dislocare cloud clasificate.

5. Tipare de arhitectură: suveran conectat vs suveran complet izolat

Există două tipare arhitecturale primare pentru dislocările cloud suverane, cu profiluri de cost, de capacitate și de complexitate operațională substanțial diferite.

Topologia suveran conectat folosește zona de disponibilitate din centrul de date din țară al unui hiperscaler ca strat IaaS, ministerul operându-și propriul plan de control (Kubernetes, Keycloak, Vault) deasupra primitivelor de calcul și de stocare ale hiperscalerului. Hiperscalerul furnizează ciclurile de reînnoire a hardware-ului, operațiunile centrului de date și securitatea fizică; ministerul furnizează operațiunile software, gestiunea cheilor de criptare și toate componentele planului de control.

Această topologie oferă ministerului acces la economiile de scară ale hyperscaler-ului, la fiabilitatea hardware și la serviciile gestionate de stocare și baze de date (cu controale adecvate), menținând în același timp suveranitatea operațională la stratul software. Golul de suveranitate rămâne stratul fizic al hardware-ului: tehnicienii din datacenter-ul hyperscaler-ului au acces fizic la servere, iar lanțul de aprovizionare al hyperscaler-ului determină ce hardware este disponibil. Pentru majoritatea ministerelor apărării aflate în afara mediilor de amenințare cu risc maxim, acesta este un risc rezidual acceptabil — cu condiția ca arhitectura de criptare și a planului de control să asigure că accesul fizic la hardware nu oferă date în clar și nici acces la planul de control.

Topologia suveran-conectată permite de asemenea capacitate de tip burst: când infrastructura națională de cloud a ministerului atinge limita de capacitate, sarcinile de lucru pot trece în zona hyperscaler-ului din țară, fără a traversa granițe jurisdicționale. Aceasta o face alegerea practică pentru ministerele care trebuie să îndeplinească atât cerințele de suveranitate, cât și cerințele moderne de capabilități, fără cheltuielile de capital necesare dimensionării infrastructurii naționale pentru sarcina de vârf.

Cloud complet național elimină integral dependența de hyperscaler. Toată infrastructura fizică — servere, echipamente de rețea, matrice de stocare și datacenter-ul care le găzduiește — este achiziționată, deținută și operată de minister sau de o organizație acreditată la nivel național. OpenStack furnizează stratul IaaS peste acest hardware; Ceph furnizează stocarea distribuită; Kubernetes furnizează orchestrarea.

Compromisurile sunt semnificative. Cheltuielile de capital sunt mult mai mari decât la o topologie suveran-conectată. Ciclurile de achiziție pentru servere și echipamente de rețea sunt lungi — de obicei 12-24 de luni de la cerință la capabilitate operațională. Reînnoirea hardware necesită cicluri noi de achiziție. Cerințele de personal operațional sunt mult mai mari: operarea OpenStack, Ceph, Kubernetes și Keycloak în producție cere o echipă cu expertiză profundă în toate cele patru componente, foarte greu de recrutat la nivelurile de salarizare din guvern. Iar golul de capabilități față de hyperscaler-i se lărgește în timp, pe măsură ce aceștia investesc masiv în platforme gestionate de AI/ML, analiză de date și serverless.

Cloud complet național este alegerea corectă pentru sarcinile de lucru cu cel mai înalt grad de clasificare, pentru sarcinile cu cerințe stricte de tip air-gap (fără nicio conexiune fizică sau de rețea la infrastructura comercială) și pentru capabilitățile în care suveranitatea lanțului de aprovizionare la stratul hardware este o cerință fermă. Nu este alegerea potrivită pentru portofoliul general de sarcini de lucru al unui minister modern al apărării — complexitatea operațională și golul de capabilități sunt un prea mare de plătit pentru cerințe de suveranitate pe care o topologie suveran-conectată bine proiectată le poate satisface.

6. Stiva suverană open-source

Stiva canonică de cloud suveran open-source pentru apărare este construită pe patru componente care împreună furnizează platforma completă de IaaS, stocare, orchestrare și identitate, fără dependențe proprietare și cu cod sursă complet auditabil.

OpenStack este stratul IaaS: Nova pentru calcul, Neutron pentru rețele virtuale, Cinder pentru stocare pe blocuri, Swift pentru stocare de obiecte, Glance pentru gestionarea imaginilor, Keystone pentru identitatea și catalogul serviciilor. OpenStack are o istorie de producție de 15 ani în medii din telecomunicații, guvernamentale și de calcul științific. Complexitatea operațională este reală — implementările OpenStack cer o echipă de platformă dedicată și o gestionare atentă a schimbărilor — dar ecosistemul de operatori, integratori și documentație este matur. Instrumentele de implementare Kolla-Ansible fac instalarea inițială gestionabilă; provocarea operațională continuă este gestionarea upgrade-urilor, care trebuie planificată cu grijă într-un mediu de apărare în care procesele de control al schimbărilor sunt lente.

Ceph este backend-ul de stocare distribuită. Furnizează stocare pe blocuri (RBD) pentru volumele Cinder, stocare de obiecte (RGW) pentru API-uri compatibile Swift și un sistem de fișiere partajat (CephFS) pentru sarcinile de lucru care necesită semantică POSIX. Arhitectura Ceph distribuie datele pe toate nodurile din cluster cu factori de replicare configurabili, oferind reziliență la defectele individuale de noduri sau discuri fără matrice de stocare proprietare. Complexitatea operațională se concentrează pe reglarea performanței — Ceph cere o selecție atentă a hardware-ului (SSD-uri NVMe pentru jurnalele OSD, rețele cu lățime de bandă mare între noduri) și monitorizarea continuă a performanței, pentru a evita cascadele „OSD lent” care pot degrada performanța clusterului sub sarcină intensă de scriere.

Keycloak este furnizorul de identitate. Suportă OIDC, SAML 2.0, OAuth 2.0 și federația LDAP/AD, fiind punctul de integrare pentru toată autentificarea din stiva suverană: autentificarea serverului API Kubernetes, federația de identitate OpenStack Keystone, autentificarea Vault JWT și autentificarea utilizatorilor. Interfața de administrare și API-ul REST din Keycloak furnizează instrumentele operaționale pentru gestionarea utilizatorilor, a grupurilor și înregistrarea clienților (aplicațiilor). Modelul de implementare cu disponibilitate ridicată — instanțe Keycloak multiple care partajează o memorie cache distribuită Infinispan și o bază de date PostgreSQL comună — este bine documentat și dovedit în producție.

Kubernetes este stratul de orchestrare a containerelor. Implementat cu kubeadm sau Talos Linux pe instanțe de calcul OpenStack Nova, Kubernetes furnizează stratul de planificare a sarcinilor de lucru, descoperire a serviciilor și gestionare a configurației pe care echipele de aplicații îl consumă. Cerința arhitecturală cheie pentru stiva suverană este ca distribuția Kubernetes să fie compatibilă cu upstream-ul — nu o variantă gestionată de hyperscaler — astfel încât planul de control să rămână sub controlul ministerului. Pentru rețeaua containerelor, Cilium este CNI-ul preferat pentru mediile de apărare datorită aplicării politicilor bazate pe eBPF și observabilității profunde fără un proxy sidecar. Pentru integrarea stocării, driverul Ceph CSI asigură legătura dintre PersistentVolumes Kubernetes și Ceph RBD.

Complexitatea operațională a acestei stive nu trebuie subestimată. Operarea OpenStack, Ceph, Kubernetes și Keycloak în producție cere expertiză de specialitate în toate cele patru componente, greu de recrutat și păstrat în organizații guvernamentale. Realist, un minister care implementează această stivă are nevoie fie de o echipă internă mare de platformă (20+ ingineri pentru o implementare de scară medie), fie de un integrator suveran contractat, cu expertiză profundă în toate cele patru componente. Alternativa — reducerea complexității operaționale prin adoptarea unui serviciu gestionat de hyperscaler pentru unele componente — trebuie evaluată în raport cu cerințele de suveranitate pe care le compromite. Pentru controalele de securitate care trebuie să ruleze peste această stivă, consultați articolul nostru despre CSPM pentru cloudul de apărare.

7. Echilibrarea suveranității cu capabilitățile cloud moderne

Cea mai dificilă problemă arhitecturală pentru cloudul suveran al unui minister al apărării nu sunt chiar controalele de suveranitate — ci menținerea acestor controale în timp ce se furnizează capabilitățile cloud moderne pe care organizațiile de apărare le cer tot mai mult: antrenarea și inferența modelelor AI/ML, analiza de date în timp real, arhitecturi serverless conduse de evenimente și platforme globale de colaborare. Hyperscaler-ii au investit miliarde în versiuni gestionate ale acestor capabilități, pe care stiva suverană open-source nu le poate egala pe un orizont de un deceniu.

Portabilitatea IaC prin abstractizarea providerelor Terraform este mecanismul cel mai practic pentru gestionarea acestei tensiuni. Strategia constă în definirea întregii infrastructuri în module Terraform agnostice față de provider — abstracții interne care acceptă intrări consecvente și produc ieșiri consecvente, indiferent dacă providerul subjacent este OpenStack, AWS sau Azure. Interfața modulului pentru un „cluster de calcul” este aceeași indiferent dacă se implementează pe OpenStack Nova sau AWS EC2; se schimbă doar legătura cu providerul. Această abstractizare păstrează opțiunea de a migra sarcini de lucru între stiva națională suverană și o zonă suveran-conectată a hyperscaler-ului, fără rearhitecturizarea infrastructurii de aplicație.

# Example provider-agnostic compute module interface
module "compute_cluster" {
  source        = "internal/modules/compute-cluster"
  name          = "sensor-processing"
  instance_type = "c5.4xlarge"  # resolved per provider
  count         = 3
  subnet_id     = module.network.private_subnet_id
  security_groups = [module.security.workload_sg_id]
  user_data     = file("cloud-init/sensor-processor.yaml")
}

# Bind to provider via workspace variable
# terraform.tfvars.national:  provider = "openstack"
# terraform.tfvars.govcloud:  provider = "aws-govcloud"

Alternative la serviciile gestionate pentru cele mai importante goluri de capabilități din punct de vedere strategic:

• Antrenare AI/ML: clustere GPU on-premises care rulează Kubeflow sau MLflow, achiziționate de la furnizori cu o postură acceptabilă a lanțului de aprovizionare; capacitate burst suveran-conectată către instanțe GPU ale hyperscaler-ului din țară, pentru sarcinile de antrenare care depășesc capacitatea on-premises
• Analiza datelor: Apache Spark pe Kubernetes (prin operatorul Spark) înlocuiește serviciile gestionate de analiză; ClickHouse sau Apache Druid pentru sarcini de interogare analitică în timp real
• Baze de date gestionate: operatorii pentru PostgreSQL (CloudNativePG), Redis (Redis Operator) și Kafka (Strimzi) oferă o experiență operațională asemănătoare serviciilor gestionate pe Kubernetes autogestionat
• Observabilitate: Prometheus, Loki și Grafana furnizează stiva de metrici, jurnalizare și vizualizare, fără dependențe proprietare de observabilitate gestionată

Foaia de parcurs a capabilităților pentru cloudul suveran trebuie tratată ca un program viu, nu ca o implementare unică. Golul dintre capabilitățile stivei suverane și serviciile gestionate ale hyperscaler-ilor este real, dar nu static — ecosistemul open-source produce continuu alternative suverane la serviciile gestionate proprietare. O revizuire structurată a capabilităților la fiecare șase luni — comparând capabilitățile actuale ale stivei suverane cu cerințele operaționale actuale și cu alternativele actuale ale hyperscaler-ilor — permite ministerului să prioritizeze ce goluri să închidă prin adoptarea open-source, ce goluri prin acces suveran-conectat la serviciile hyperscaler-ului din țară și pe care să le accepte ca limitări reziduale de capabilități în schimbul garanțiilor de suveranitate.

Cloudul suveran pentru ministerele apărării este, în ultimă instanță, o decizie de gestionare a riscurilor, nu o decizie tehnologică. Arhitectura descrisă aici — plan de control național, controale tehnice de rezidență a datelor, stivă suverană open-source, abstractizare a providerelor Terraform pentru portabilitate — este un set de instrumente pentru gestionarea unui set specific de riscuri. Arhitectura potrivită pentru fiecare minister depinde de care riscuri sunt cele mai importante în mediul său de amenințări, ce capacitate operațională poate fi menținută realist cu personalul și bugetul disponibile și unde, pe curba de compromis dintre suveranitate și capabilitate, se situează cerințele sale de sarcini de lucru clasificate. Calibrarea corectă cere o evaluare sinceră a amenințărilor și judecată de inginerie — nu asigurări de la furnizori.