Chmura suwerenna dla ministerstw obrony: rezydencja danych, płaszczyzny kontroli i architektura narodowa

Autor: Zespół inżynierów Corvus Intelligence · O zespole →

25 czerwca 2026 Zaktualizowano: 25 czerwca 2026 12 min czytania

Każde ministerstwo obrony, które przeniosło obciążenia do chmury, prędzej czy później mierzy się z tym samym napięciem: komercyjni hiperskalerzy zapewniają zdolności – zarządzane bazy danych, platformy AI/ML, globalną sieć – których żaden dostawca narodowy nie jest w stanie zaoferować, a jednocześnie ci sami hiperskalerzy to zagraniczne korporacje podlegające postępowaniom prawnym, kontrolom eksportowym i żądaniom dostępu służb wywiadowczych rządu macierzystego. Termin „chmura suwerenna” opisuje próbę rozwiązania tego napięcia bez przyjmowania którejkolwiek ze skrajności: ani pełnej zależności od hiperskalera, ani narodowego mainframe'a zamrożonego technologicznie. Powstała architektura nigdy nie jest prosta, a kompromisy rzadko są oczywiste, dopóki nie zostaną już podjęte w produkcji.

Ten artykuł bada techniczną architekturę chmury suwerennej dla ministerstw obrony – nie jako listę kontrolną zakupów, lecz jako problem inżynierski. Omawiamy, co suwerenność faktycznie znaczy w każdym z trzech wymiarów, jak zaprojektować krajową płaszczyznę kontroli, która przetrwa zakłócenia po stronie dostawcy, które komponenty hiperskalera wprowadzają nieakceptowalne ryzyko suwerenności, jak wygląda suwerenny stos open source w produkcji oraz jak równoważyć ograniczenia suwerenności z operacyjnymi wymaganiami zdolności nowoczesnej obronności. Szersze wymagania bezpieczeństwa obciążeń opisuje nasz przewodnik bezpieczeństwo wojskowych obciążeń w chmurze.

1. Czym jest suwerenność chmury dla ministerstwa obrony

Fraza „chmura suwerenna” jest używana przez dostawców niemal do wszystkiego – krajowego centrum danych, umownego zobowiązania do rezydencji danych, lokalnej spółki prawnej – i prawie nic z tego, co oznacza w marketingu dostawców, nie wystarcza dla poważnego przeglądu architektury ministerstwa obrony. Prawdziwa suwerenność chmury dla obronności obejmuje trzy odrębne wymagania, które trzeba oceniać niezależnie, ponieważ spełnienie jednego nie pociąga spełnienia pozostałych.

Rezydencja danych to gwarancja, że dane niejawne lub wrażliwe są przechowywane, przetwarzane i przesyłane wyłącznie na terytorium kraju lub w granicach zatwierdzonej jurysdykcji – oraz że klucze szyfrujące, które je chronią, kontroluje ministerstwo, a nie dostawca chmury. Rezydencja danych jest najczęściej omawianym wymaganiem suwerenności i najłatwiejszym do sfingowania: umowne zobowiązanie, że dane pozostaną w kraju, jest prawnie niewykonalne wobec wezwania wywiadowczego obcego rządu i nie daje żadnej ochrony technicznej przed błędnie skonfigurowanym zadaniem replikacji, które kopiuje dane do strefy dostępności poza krajem.

Suwerenność operacyjna to zdolność dalszego prowadzenia platformy chmurowej bez dalszej współpracy jakiegokolwiek zagranicznego dostawcy – w tym zdolność przetrwania bankructwa dostawcy, sankcji komercyjnych, zmian kontroli eksportu albo zmuszenia dostawcy przez obcy rząd do odmowy lub degradacji usługi. Suwerenność operacyjna wymaga, aby ministerstwo było w stanie prowadzić każdy komponent platformy wyłącznie na podstawie dokumentacji i kodu źródłowego, bez bieżącej zależności od własnościowego wsparcia dostawcy, które może zostać wycofane.

Suwerenność łańcucha dostaw to kontrola nad komponentami sprzętowymi i programowymi wykorzystywanymi do budowy i prowadzenia chmury. Platforma zbudowana na audytowalnym oprogramowaniu open source działającym na serwerach producenta spoza sojuszu nie spełnia żadnego z tych wymiarów: warstwa programowa może być audytowalna, ale firmware sprzętowy już nie. Kompletna analiza suwerenności łańcucha dostaw obejmuje firmware procesorów, systemy operacyjne urządzeń sieciowych, firmware kontrolerów pamięci masowej oraz zależności biblioteczne każdego komponentu stosu suwerennego.

Większość dzisiejszych architektur chmury suwerennej ministerstw obrony spełnia rezydencję danych częściowo, suwerenność operacyjną częściowo, a suwerenność łańcucha dostaw minimalnie. Celem jawnego wyróżnienia trzech wymiarów jest umożliwienie uczciwej oceny ryzyka zamiast fałszywego zapewnienia z certyfikacji „chmury suwerennej”, która adresuje tylko najbardziej widoczny wymiar.

2. Egzekwowanie rezydencji danych

Techniczne kontrole rezydencji danych działają w trzech warstwach: rezydencja kluczy szyfrujących, egzekwowanie polityki lokalizacji danych oraz audyt i weryfikacja. Wymagane są wszystkie trzy; każda pojedynczo jest niewystarczająca.

Rezydencja kluczy szyfrujących jest najważniejszą kontrolą techniczną, ponieważ przesądza, czy dane da się odszyfrować poza zatwierdzoną granicą nawet po ich fizycznej eksfiltracji. Wymogiem jest, aby moduł bezpieczeństwa sprzętowego (HSM) lub usługa zarządzania kluczami (KMS) przechowująca klucze szyfrowania danych znajdowała się fizycznie na terytorium kraju i pod kontrolą operacyjną ministerstwa lub organizacji akredytowanej krajowo – a nie w zarządzanym KMS zagranicznego dostawcy chmury, gdzie ostateczny materiał kluczowy spoczywa w sprzęcie kontrolowanym przez dostawcę. W praktyce oznacza to:

Lokalny HSM (Thales Luna, Utimaco SecurityServer lub równoważny) dla najwyższych poziomów klauzul, z HSM fizycznie zabezpieczonym i audytowanym zgodnie z ministerstwową polityką bezpieczeństwa fizycznego
KMS narodowego dostawcy chmury oparty na krajowym sprzęcie HSM dla niższych poziomów klauzul, tam gdzie zarządzane usługi kluczowe są akceptowalne
Szyfrowanie kopertowe: klucze szyfrowania danych (DEK) są generowane per obiekt lub per wolumen i szyfrowane kluczami szyfrującymi klucze (KEK) trzymanymi w HSM – HSM nigdy nie przechowuje surowych danych, wyłącznie materiał kluczowy
Rejestrowanie dostępu do kluczy, oddzielne i niezależne od dziennika audytu systemu przechowywania, tak aby nieuprawnione próby dostępu do kluczy były widoczne nawet po skompromitowaniu warstwy przechowywania

Egzekwowanie polityki lokalizacji danych wymaga, aby usługi przechowywania – magazyn obiektowy, wolumeny blokowe, instancje baz danych – były ograniczone do krajowych stref dostępności na poziomie konfiguracji platformy, a nie jedynie deklaracji polityki. We wdrożeniu OpenStack oznacza to skonfigurowanie reguł koligacji stref dostępności w Cinder i Swift, które uniemożliwiają umieszczanie replik poza zdefiniowaną strefą. We wdrożeniu hiperskalera oznacza to użycie polityk kontroli usług (AWS) lub definicji Azure Policy odmawiających utworzenia jakiegokolwiek zasobu przechowywania w regionach poza krajem, zastosowanych na poziomie konta zarządzającego lub grupy zarządzającej, tak aby pojedyncze zespoły obciążeń nie mogły ich nadpisać.

Audyt i weryfikacja to ciągły proces operacyjny potwierdzający, że kontrole rezydencji danych działają zgodnie z projektem. Warstwa audytu musi być niezależna od warstwy przechowywania – podmiot przechowujący dane nie może być jedynym podmiotem weryfikującym, gdzie dane są przechowywane. Wymagane komponenty:

Codzienna zautomatyzowana weryfikacja, że wszystkie punkty końcowe przechowywania używane przez obciążenia rozwiązują się do krajowych adresów IP, z alertowaniem o każdym nowym punkcie końcowym
Monitoring przepływów sieciowych oznaczający każdy ruch wychodzący z usług przechowywania do zakresów IP poza krajem
Kwartalny techniczny audyt strony trzeciej kontroli rezydencji danych, z wynikami raportowanymi do organu bezpieczeństwa ministerstwa
Konfiguracja jako kod dla wszystkich polityk lokalizacji danych, wersjonowana w niemodyfikowalnym repozytorium, tak aby zmiany polityki generowały wykrywalny diff przed wejściem w życie

Kontrole umowne – umowy powierzenia przetwarzania danych, klauzule lokalizacji danych – są niezbędnym uzupełnieniem kontroli technicznych, ale nigdy nie powinny być mechanizmem głównym. Umowy wiążą to, czego dokona współpracujący dostawca; nie wiążą tego, co dostawca czyni pod przymusem prawnym własnego rządu, i nie chronią przed błędną konfiguracją techniczną.

3. Projektowanie krajowej płaszczyzny kontroli

Płaszczyzna kontroli platformy chmurowej – zbiór usług zarządzających orkiestracją, tożsamością i sekretami – to miejsce, gdzie mieszka ryzyko suwerenności o największym wpływie. W środowisku Kubernetes komponentami płaszczyzny kontroli są serwer API, klaster etcd, scheduler, controller manager oraz webhooky admission egzekwujące politykę w chwili tworzenia obciążenia. Jeśli którykolwiek z tych komponentów działa na infrastrukturze zarządzanej przez personel operacyjny zagranicznego hiperskalera, personel ten ma techniczną możliwość (nawet jeśli umownie zakazaną) modyfikowania konfiguracji obciążeń, wydobywania sekretów z etcd albo zakłócania planowania na polecenie własnego rządu.

Projekt krajowej płaszczyzny kontroli umieszcza wszystkie te komponenty na infrastrukturze fizycznie i organizacyjnie podległej ministerstwu. Praktyczna architektura:

Serwer API Kubernetes i etcd. Wdróż samodzielnie zarządzaną dystrybucję Kubernetes – kubeadm dla maksymalnej elastyczności, k0s dla uproszczonych operacji lub Talos Linux dla podejścia z niezmiennym systemem operacyjnym – na serwerach bare metal lub maszynach wirtualnych działających na hipernadzorcach kontrolowanych przez ministerstwo. Klaster etcd wymaga do kworum trzech lub pięciu węzłów, działających na dedykowanym sprzęcie nieudostępnianym węzłom obciążeń. Dane etcd muszą być szyfrowane w spoczynku przy użyciu wtyczki dostawcy KMS podłączonej do narodowego HSM. Kopie zapasowe migawek etcd twórz do szyfrowanego krajowego magazynu obiektowego ze zautomatyzowanym testowaniem odtwarzania.

# 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: {}

Dostawca tożsamości. Keycloak to standardowy open source'owy dostawca tożsamości OIDC/SAML dla wdrożeń chmury suwerennej. Wdróż Keycloak na dedykowanej infrastrukturze narodowej, zintegrowany z istniejącym katalogiem ministerstwa (Active Directory lub LDAP przez konektory federacyjne Keycloak). Skonfiguruj serwer API Kubernetes tak, aby używał Keycloak jako swojego uwierzytelniania 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

Dostępność Keycloak jest teraz ścieżką krytyczną uwierzytelniania klastra. Wdróż w trybie wysokiej dostępności (minimum trzy instancje Keycloak za wewnętrznym load balancerem, z rozproszoną pamięcią podręczną stanu sesji) i udokumentuj awaryjną procedurę break-glass dostępu do serwera API, gdy Keycloak jest niedostępny – typowo lokalny kubeconfig z certyfikatem klienta do awaryjnego dostępu cluster-admin, przechowywany w fizycznie zabezpieczonym miejscu.

Zarządzanie sekretami. HashiCorp Vault (lub jego open source'owy fork OpenBao) wdrożony na infrastrukturze narodowej zapewnia warstwę zarządzania sekretami. Vault odblokowuje się automatycznie (auto-unseal) przy użyciu narodowego HSM, eliminując ręczny proces odblokowania, który w przeciwnym razie byłby pojedynczym punktem awarii dla odtwarzania płaszczyzny kontroli. Dziennik audytu Vault – każdy odczyt i zapis sekretu – jest przesyłany w czasie rzeczywistym do narodowego SIEM, poza promieniem rażenia skompromitowanego wdrożenia Vault.

4. Ocena zależności od hiperskalerów

Większość środowisk chmurowych ministerstw obrony używa co najmniej jednego hiperskalera dla pewnego szczebla swojej infrastruktury – czy to dla topologii sovereign-connected, strefy disaster recovery, albo starszych obciążeń jeszcze niezmigrowanych. Zrozumienie, które komponenty hiperskalera wprowadzają ryzyko suwerenności, jest kluczowe dla decyzji „usługa zarządzana czy prowadzenie własne” dla każdego komponentu.

Wysokie ryzyko suwerenności – należy zastąpić lub prowadzić niezależnie:

Zarządzane płaszczyzny kontroli Kubernetes (EKS, AKS, GKE) – serwer API i etcd są prowadzone przez personel hiperskalera z dostępem uprzywilejowanym; zastąp samodzielnie zarządzanym Kubernetesem na prymitywach IaaS
Zarządzani dostawcy tożsamości (AWS IAM, Azure Active Directory jako główny IdP) – wiążące potwierdzenia tożsamości wystawiane przez usługi prowadzone za granicą; zastąp Keycloak lub równoważnym na infrastrukturze narodowej
Zarządzane magazyny sekretów (AWS Secrets Manager, Azure Key Vault z HSM kontrolowanymi przez hiperskalera) – materiał kluczowy trzymany w zagranicznych HSM; zastąp samodzielnie zarządzanym Vault na narodowym HSM
Globalne sieci CDN i brzegowe – ruch kierowany przez punkty obecności poza krajem; wyłącz albo ogranicz wyłącznie do krajowych węzłów brzegowych

Średnie ryzyko suwerenności – akceptowalne z dodatkowymi kontrolami:

Magazyn obiektowy hiperskalera w krajowej strefie dostępności – akceptowalny, jeśli jest szyfrowany kluczami kontrolowanymi przez ministerstwo z narodowego HSM, z replikacją zablokowaną na strefy krajowe
Zarządzane bazy danych hiperskalera w strefach krajowych – akceptowalne dla danych jawnych, jeśli zarządzanie kluczami szyfrowania jest narodowe, z wyłączoną replikacją międzyregionową
Sieć wirtualna hiperskalera – VPC, podsieci i grupy bezpieczeństwa to niskoryzykowne prymitywy IaaS; ryzyko suwerenności tkwi w płaszczyźnie kontroli, która nimi zarządza, a nie w samych prymitywach

Niższe ryzyko suwerenności:

Obliczenia IaaS (maszyny wirtualne) bez zarządzanych platform agentowych – hiperskaler dostarcza sprzęt; ministerstwo prowadzi stos programowy i kontroluje całe szyfrowanie
Pamięć masowa blokowa z kluczami zarządzanymi przez klienta z narodowego KMS – hiperskaler przechowuje zaszyfrowane bloki, których nie da się odszyfrować bez klucza posiadanego przez ministerstwo

Wynikiem oceny jest mapa ryzyka na poziomie komponentów, a nie binarna decyzja „używaj hiperskalera” albo „nie używaj hiperskalera”. Większość architektur chmury suwerennej zachowa część komponentów hiperskalera w warstwie IaaS, zastępując komponenty płaszczyzny kontroli i tożsamości alternatywami narodowymi. Szerszy obraz modeli wdrożenia i ich implikacji klauzulowych przedstawia nasz artykuł modele wdrożeń chmury dla danych niejawnych.

5. Wzorce architektoniczne: sovereign-connected czy air-gapped

Dla wdrożeń chmury suwerennej istnieją dwa główne wzorce architektoniczne, o istotnie różnych profilach kosztów, zdolności i złożoności operacyjnej.

Topologia sovereign-connected wykorzystuje strefę dostępności krajowego centrum danych hiperskalera jako warstwę IaaS, przy czym ministerstwo prowadzi na jej wierzchu własną płaszczyznę kontroli (Kubernetes, Keycloak, Vault) na prymitywach obliczeniowych i przechowywania hiperskalera. Hiperskaler zapewnia cykle odświeżania sprzętu, operacje centrum danych i bezpieczeństwo fizyczne; ministerstwo zapewnia operacje programowe, zarządzanie kluczami szyfrującymi i wszystkie komponenty płaszczyzny kontroli.

Ta topologia daje ministerstwu dostęp do korzyści skali hiperskalera, niezawodności sprzętu oraz zarządzanych usług przechowywania i bazodanowych (z odpowiednimi kontrolami), zachowując jednocześnie suwerenność operacyjną w warstwie programowej. Luką suwerenności jest fizyczna warstwa sprzętowa: technicy centrum danych hiperskalera mają fizyczny dostęp do serwerów, a łańcuch dostaw hiperskalera przesądza, jaki sprzęt jest dostępny. Dla większości ministerstw obrony poza środowiskami zagrożeń najwyższego ryzyka jest to akceptowalne ryzyko rezydualne – pod warunkiem że architektura szyfrowania i płaszczyzny kontroli oznacza, iż fizyczny dostęp do sprzętu nie daje ani danych w postaci jawnej, ani dostępu do płaszczyzny kontroli.

Topologia sovereign-connected umożliwia także zdolność burst: gdy krajowa infrastruktura chmurowa ministerstwa osiąga pełne wykorzystanie, obciążenia mogą przelewać się do krajowej strefy hiperskalera bez przekraczania granic jurysdykcyjnych. Czyni to ją praktycznym wyborem dla ministerstw, które muszą spełnić zarówno wymagania suwerenności, jak i nowoczesne wymagania zdolności, bez wydatków kapitałowych na wymiarowanie infrastruktury narodowej pod obciążenie szczytowe.

Chmura w pełni narodowa eliminuje zależność od hiperskalera całkowicie. Cała infrastruktura fizyczna – serwery, sprzęt sieciowy, macierze pamięci masowej i centrum danych, które je mieści – jest kupowana, posiadana i prowadzona przez ministerstwo lub organizację akredytowaną krajowo. OpenStack zapewnia na tym sprzęcie warstwę IaaS; Ceph zapewnia przechowywanie rozproszone; Kubernetes zapewnia orkiestrację.

Kompromisy są znaczące. Wydatki kapitałowe są istotnie wyższe niż w topologii sovereign-connected. Cykle zakupowe serwerów i sprzętu sieciowego są długie – typowo 12–24 miesiące od wymagania do zdolności operacyjnej. Odświeżanie sprzętu wymaga nowych cykli zakupowych. Wymagania kadrowe operacyjne są znacznie większe: produkcyjne prowadzenie OpenStack, Ceph, Kubernetes i Keycloak wymaga zespołu o głębokich kompetencjach we wszystkich czterech komponentach, bardzo trudnego do obsadzenia przy rządowych poziomach wynagrodzeń. A luka zdolności względem hiperskalerów poszerza się z czasem, gdy hiperskalerzy intensywnie inwestują w zarządzane usługi AI/ML, analitykę danych i platformy serverless.

Chmura w pełni narodowa jest właściwym wyborem dla obciążeń o najwyższych klauzulach, obciążeń z twardymi wymaganiami separacji fizycznej (brak fizycznego lub sieciowego połączenia z infrastrukturą komercyjną) oraz zdolności, dla których suwerenność łańcucha dostaw w warstwie sprzętowej jest bezwzględnym wymogiem. Nie jest właściwym wyborem dla ogólnego portfela obciążeń nowoczesnego ministerstwa obrony – złożoność operacyjna i luka zdolności to zbyt wysoka cena za wymagania suwerenności, które może spełnić dobrze zaprojektowana topologia sovereign-connected.

6. Suwerenny stos open source

Kanoniczny stos open source chmury suwerennej dla obronności jest zbudowany na czterech komponentach, które razem zapewniają pełną platformę IaaS, przechowywania, orkiestracji i tożsamości bez zależności własnościowych i z w pełni audytowalnym kodem źródłowym.

OpenStack stanowi warstwę IaaS: Nova dla obliczeń, Neutron dla sieci wirtualnej, Cinder dla pamięci blokowej, Swift dla magazynu obiektowego, Glance dla zarządzania obrazami, Keystone dla tożsamości i katalogu usług. OpenStack ma 15-letnią historię produkcyjną w środowiskach telekomunikacyjnych, rządowych i obliczeń naukowych. Złożoność operacyjna jest realna – wdrożenia OpenStack wymagają dedykowanego zespołu platformowego i starannego zarządzania zmianą – lecz ekosystem operatorów, integratorów i dokumentacji jest dojrzały. Narzędzia wdrożeniowe Kolla-Ansible czynią wstępne wdrożenie zarządzalnym; bieżącym wyzwaniem operacyjnym jest zarządzanie uaktualnieniami, które w środowisku obronnym, gdzie procesy kontroli zmian są powolne, musi być planowane ostrożnie.

Ceph to rozproszony backend przechowywania. Zapewnia pamięć blokową (RBD) dla wolumenów Cinder, magazyn obiektowy (RGW) dla API zgodnych ze Swift oraz współdzielony system plików (CephFS) dla obciążeń wymagających semantyki POSIX. Architektura Ceph rozprasza dane po wszystkich węzłach klastra z konfigurowalnymi współczynnikami replikacji, zapewniając odporność na awarie pojedynczych węzłów lub dysków bez własnościowych macierzy pamięci masowej. Złożoność operacyjna koncentruje się na dostrajaniu wydajności – Ceph wymaga starannego doboru sprzętu (dyski NVMe SSD dla journali OSD, sieci o wysokiej przepustowości między węzłami) i ciągłego monitorowania wydajności, aby uniknąć kaskad „wolnych OSD”, które mogą degradować wydajność klastra przy ciężkim obciążeniu zapisem.

Keycloak to dostawca tożsamości. Obsługuje OIDC, SAML 2.0, OAuth 2.0 oraz federację LDAP/AD, co czyni go punktem integracji całego uwierzytelniania w stosie suwerennym: uwierzytelnianie serwera API Kubernetes, federacja tożsamości OpenStack Keystone, uwierzytelnianie JWT w Vault i uwierzytelnianie użytkowników. Interfejs administracyjny i REST API Keycloak zapewniają narzędzia operacyjne do zarządzania użytkownikami, grupami i rejestracją klientów (aplikacji). Model wdrożenia wysokiej dostępności – wiele instancji Keycloak współdzielących rozproszoną pamięć podręczną Infinispan i współdzieloną bazę PostgreSQL – jest dobrze udokumentowany i sprawdzony produkcyjnie.

Kubernetes to warstwa orkiestracji kontenerów. Wdrożony z kubeadm lub Talos Linux na instancjach obliczeniowych OpenStack Nova, Kubernetes zapewnia warstwę planowania obciążeń, odkrywania usług i zarządzania konfiguracją, którą konsumują zespoły aplikacyjne. Kluczowym wymogiem architektonicznym stosu suwerennego jest, aby dystrybucja Kubernetes była zgodna z upstream – a nie zarządzanym wariantem hiperskalera – tak aby płaszczyzna kontroli pozostała pod kontrolą ministerstwa. Dla sieci kontenerów preferowanym CNI w środowiskach obronnych jest Cilium ze względu na egzekwowanie polityki oparte na eBPF i głęboką obserwowalność bez proxy sidecar. Dla integracji przechowywania sterownik Ceph CSI zapewnia powiązanie między PersistentVolumes Kubernetes a Ceph RBD.

Złożoności operacyjnej tego stosu nie należy niedoszacowywać. Produkcyjne prowadzenie OpenStack, Ceph, Kubernetes i Keycloak wymaga kompetencji specjalistycznych we wszystkich czterech komponentach, trudnych do rekrutacji i utrzymania w organizacjach rządowych. Realnie ministerstwo wdrażające ten stos potrzebuje albo dużego wewnętrznego zespołu platformowego (20+ inżynierów dla wdrożenia średniej skali), albo kontraktowego suwerennego integratora z głębokimi kompetencjami we wszystkich czterech komponentach. Alternatywa – redukcja złożoności operacyjnej przez przyjęcie zarządzanej usługi hiperskalera dla części komponentów – musi być oceniona względem wymagań suwerenności, które narusza. O kontrolach bezpieczeństwa, które muszą działać na tym stosie, piszemy w artykule CSPM dla chmury obronnej.

7. Równoważenie suwerenności z nowoczesnymi zdolnościami chmury

Najtrudniejszym problemem architektonicznym chmury suwerennej ministerstwa obrony nie są same kontrole suwerenności – lecz utrzymanie tych kontroli przy zapewnianiu nowoczesnych zdolności chmurowych, których organizacje obronne coraz bardziej wymagają: treningu i inferencji modeli AI/ML, analityki danych w czasie rzeczywistym, serwerlessowych architektur zdarzeniowych i globalnych platform współpracy. Hiperskalerzy zainwestowali miliardy w zarządzane wersje tych zdolności, których suwerenny stos open source nie jest w stanie dorównać w horyzoncie dekady.

Przenośność IaC przez abstrakcję dostawców Terraform jest najbardziej praktycznym mechanizmem zarządzania tym napięciem. Strategia polega na definiowaniu całej infrastruktury w modułach Terraform niezależnych od dostawcy – wewnętrznych abstrakcjach przyjmujących spójne wejścia i dających spójne wyjścia niezależnie od tego, czy dostawcą bazowym jest OpenStack, AWS czy Azure. Interfejs modułu „klastra obliczeniowego” jest ten sam, czy wdraża się na OpenStack Nova, czy AWS EC2; zmienia się wyłącznie powiązanie dostawcy. Ta abstrakcja zachowuje opcję migracji obciążeń między suwerennym stosem narodowym a strefą hiperskalera sovereign-connected bez przebudowy architektury infrastruktury aplikacyjnej.

# 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"

Alternatywy dla usług zarządzanych w najbardziej strategicznych lukach zdolności:

Trening AI/ML: lokalne klastry GPU z Kubeflow lub MLflow, kupowane od dostawców o akceptowalnej postawie łańcucha dostaw; burst sovereign-connected do krajowych instancji GPU hiperskalera dla zadań treningowych przekraczających lokalne zdolności
Analityka danych: Apache Spark na Kubernetes (przez operator Spark) zastępuje zarządzane usługi analityczne; ClickHouse lub Apache Druid dla obciążeń zapytań analitycznych w czasie rzeczywistym
Zarządzane bazy danych: operatory dla PostgreSQL (CloudNativePG), Redis (Redis Operator) i Kafka (Strimzi) zapewniają doświadczenie operacyjne zbliżone do usługi zarządzanej na samodzielnie zarządzanym Kubernetesie
Obserwowalność: Prometheus, Loki i Grafana zapewniają stos metryk, logowania i wizualizacji bez własnościowych zależności od zarządzanej obserwowalności

Mapa drogowa zdolności chmury suwerennej musi być traktowana jako żywy program, a nie jednorazowe wdrożenie. Luka między zdolnościami stosu suwerennego a usługami zarządzanymi hiperskalera jest realna, ale nie statyczna – ekosystem open source nieustannie wytwarza nowe suwerenne alternatywy dla własnościowych usług zarządzanych. Ustrukturyzowany przegląd zdolności co sześć miesięcy – porównujący bieżące zdolności stosu suwerennego z bieżącymi wymaganiami operacyjnymi i bieżącymi alternatywami hiperskalera – pozwala ministerstwu ustalać priorytety: które luki zamykać przez przyjęcie open source, które przez dostęp sovereign-connected do krajowych usług hiperskalera, a które zaakceptować jako rezydualne ograniczenia zdolności w zamian za gwarancje suwerenności.

Kluczowa obserwacja: Chmura suwerenna dla ministerstw obrony nie jest produktem, który można kupić – to postawa architektoniczna, którą trzeba zaprojektować, zbudować, prowadzić i nieustannie utrzymywać. Ministerstwa, którym się to udaje, traktują suwerenność jak wymaganie inżynierskie pierwszej kategorii obok wydajności, niezawodności i kosztu, dokonują jawnych kompromisów między wymiarami suwerenności a zdolnościami oraz budują zdolność operacyjną do prowadzenia stosu suwerennego w jakości produkcyjnej. Te, które traktują ją jako pole wyboru zgodności – nabywając certyfikację dostawcy „chmura suwerenna” bez oceny, czy kontrole techniczne faktycznie dostarczają rezydencję danych, suwerenność operacyjną i suwerenność łańcucha dostaw – odkryją tę lukę, gdy zakłócenie geopolityczne lub zmiana polityki dostawcy ją odsłoni.

Chmura suwerenna dla ministerstw obrony jest ostatecznie decyzją zarządzania ryzykiem, a nie decyzją technologiczną. Opisana tu architektura – krajowa płaszczyzna kontroli, techniczne kontrole rezydencji danych, suwerenny stos open source, abstrakcja dostawców Terraform dla przenośności – to zestaw narzędzi do zarządzania określonym zbiorem ryzyk. Właściwa architektura dla danego ministerstwa zależy od tego, które ryzyka są najbardziej istotne w jego środowisku zagrożeń, jaką zdolność operacyjną realnie da się utrzymać przy dostępnych kadrach i budżecie oraz gdzie na krzywej kompromisu suwerenność–zdolności lądują wymagania jego obciążeń niejawnych. Trafne skalowanie wymaga uczciwej oceny zagrożeń i inżynierskiego osądu – a nie zapewnienia dostawcy.

Omów swój projekt

Projektujemy i budujemy architektury chmury suwerennej dla ministerstw obrony – od wdrożenia krajowej płaszczyzny kontroli i egzekwowania rezydencji danych po operacje stosu open source i przenośność IaC.

Usługi bezpiecznej chmury → Umów briefing

Analizę przygotowali inżynierowie Corvus Intelligence, którzy budują krytyczne dla misji oprogramowanie dla organizacji obronnych i rządowych. Poznaj nasz zespół →

Często zadawane pytania

Czym jest suwerenność chmury dla ministerstwa obrony?

Suwerenność chmury dla ministerstwa obrony obejmuje trzy odrębne, ale powiązane wymagania. Rezydencja danych to prawna i techniczna gwarancja, że dane niejawne lub wrażliwe są przechowywane, przetwarzane i przesyłane wyłącznie na terytorium kraju lub w zatwierdzonych jurysdykcjach – oraz że klucze szyfrujące kontroluje ministerstwo, a nie dostawca. Suwerenność operacyjna to zdolność dalszego prowadzenia platformy chmurowej niezależnie od dalszej współpracy, licencjonowania lub dostępności usług jakiegokolwiek zagranicznego dostawcy, w tym zdolność przetrwania sankcji, bankructwa dostawcy lub zakłóceń geopolitycznych. Suwerenność łańcucha dostaw to kontrola nad komponentami sprzętowymi i programowymi wykorzystywanymi do budowy i prowadzenia chmury – zapewniająca, że żaden obcy rząd nie może zmusić dostawcy do wbudowania backdoorów ani odmowy świadczenia usług. Prawdziwie suwerenna chmura dla obronności musi adresować wszystkie trzy wymiary jednocześnie; wybory architektoniczne, które spełniają rezydencję danych, ale poświęcają suwerenność operacyjną lub łańcucha dostaw, dają słabszą ochronę, niż wynika z dokumentu architektury.

Czym jest egzekwowanie rezydencji danych w kontekście chmury obronnej?

Egzekwowanie rezydencji danych w chmurze obronnej oznacza wdrożenie kontroli technicznych, które czynią fizycznie i kryptograficznie niemożliwym – a nie jedynie umownie zakazanym – wyniesienie danych poza określoną granicę geograficzną lub jurysdykcyjną. Kluczowe warstwy to: rezydencja kluczy szyfrujących (HSM lub KMS przechowujący klucze szyfrowania danych musi fizycznie znajdować się w kraju i pod kontrolą narodową, tak aby danych zaszyfrowanych tymi kluczami nie dało się odszyfrować poza granicą nawet po fizycznej eksfiltracji); polityki lokalizacji danych egzekwowane w warstwie przechowywania (magazyn obiektowy, wolumeny blokowe i repliki baz danych muszą być ograniczone do krajowych stref dostępności); kontrole ruchu wychodzącego sieci (reguły zapory i polityki DNS blokujące ścieżki danych do punktów końcowych poza krajem); oraz audyt i weryfikacja (ciągły monitoring, czy kontrole danych w spoczynku i danych w ruchu nie zostały obejść, z dziennikami odpornymi na manipulację przeglądanymi przez własny zespół operacji bezpieczeństwa ministerstwa, a nie dostawcy).

Czym jest krajowa płaszczyzna kontroli i dlaczego ma znaczenie?

Płaszczyzna kontroli platformy chmurowej to zbiór usług zarządzających orkiestracją obciążeń, tożsamością i sekretami – w środowisku Kubernetes są to serwer API, etcd, scheduler i controller manager; w szerszym kontekście chmury obejmuje ona dostawcę tożsamości, system zarządzania sekretami oraz API zarządzania. Jeśli płaszczyzna kontroli działa na infrastrukturze zarządzanej przez zagranicznego hiperskalera, personel operacyjny hiperskalera ma – w założeniu – możliwość modyfikowania konfiguracji obciążeń, wydobywania sekretów lub zakłócania działań na polecenie własnego rządu. Krajowa płaszczyzna kontroli uruchamia te komponenty na infrastrukturze fizycznie i organizacyjnie podległej ministerstwu, eliminując tę zależność. Nawet przy korzystaniu z krajowego centrum danych hiperskalera krajowa płaszczyzna kontroli oznacza, że serwer API Kubernetes, klaster etcd i dostawca tożsamości działają na sprzęcie posiadanym lub kontrolowanym przez ministerstwo, a hiperskaler dostarcza wyłącznie podstawowe zasoby obliczeniowe, sieciowe i przechowywania danych.

Które komponenty hiperskalera wprowadzają największe ryzyko suwerenności?

Komponenty hiperskalera o najwyższym ryzyku dla ministerstwa obrony to: zarządzane płaszczyzny kontroli Kubernetes (EKS, AKS, GKE), w których serwer API i etcd działają na infrastrukturze hiperskalera, a jego personel operacyjny ma dostęp uprzywilejowany; zarządzani dostawcy tożsamości, w których wiążące potwierdzenie tożsamości wystawiają usługi kontrolowane przez hiperskalera; globalne warstwy CDN i pamięci podręcznej brzegowej kierujące ruch przez punkty obecności poza krajem; funkcje replikacji międzyregionowej, które mogą kopiować dane do stref dostępności poza zatwierdzoną jurysdykcją; oraz zarządzane magazyny sekretów, których materiał kluczowy ostatecznie spoczywa w HSM kontrolowanych przez hiperskalera. Komponenty IaaS hiperskalera – surowe obliczenia, storage blokowy i sieć wirtualna bez zarządzanej płaszczyzny kontroli – wprowadzają istotnie niższe ryzyko suwerenności, ponieważ ministerstwo prowadzi na nich stos programowy i niezależnie kontroluje wszystkie klucze szyfrowania.

Czym różni się chmura w modelu sovereign-connected od chmury w pełni narodowej?

Topologia sovereign-connected wykorzystuje krajowe centrum danych hiperskalera z płaszczyzną kontroli kontrolowaną przez ministerstwo działającą na jej wierzchu. Hiperskaler dostarcza IaaS – obliczenia, przechowywanie, sieć – ale wszystkie warstwy orkiestracji, tożsamości i zarządzania sekretami prowadzi ministerstwo lub zaufany krajowy integrator. Daje to dostęp do korzyści skali i usług zarządzanych hiperskalera kosztem trwałej zależności od obsługi sprzętu i łańcucha dostaw hiperskalera. Chmura w pełni narodowa eliminuje zależność od hiperskalera całkowicie – całą infrastrukturę fizyczną kupuje, posiada i prowadzi ministerstwo lub narodowy dostawca suwerenny. Ceną są istotnie wyższe wydatki kapitałowe, dłuższe cykle zakupowe, większa złożoność operacyjna i luka zdolności względem usług zarządzanych hiperskalera – ale maksymalna suwerenność operacyjna i łańcucha dostaw.

Jakie komponenty open source tworzą rdzeń stosu chmury suwerennej?

Kanoniczny stos open source chmury suwerennej tworzą: OpenStack jako IaaS (obliczenia przez Nova, magazyn obiektowy przez Swift, storage blokowy przez Cinder, sieć przez Neutron, zarządzanie obrazami przez Glance, tożsamość przez Keystone); Ceph jako rozproszona warstwa przechowywania pod wolumeny Cinder i magazyn obiektowy Swift OpenStacka; Kubernetes jako warstwa orkiestracji kontenerów wdrożona w dystrybucji upstream (nie w zarządzanym wariancie hiperskalera), tak aby serwer API i etcd pozostały pod kontrolą ministerstwa; oraz Keycloak jako dostawca tożsamości zarówno dla użytkowników (przez OpenID Connect i SAML), jak i obciążeń (przez poświadczenia klienta OAuth 2.0). Razem te cztery komponenty dostarczają pełny stos platformy chmurowej bez zależności własnościowych. Złożoność operacyjna jest zasadniczo wyższa niż przy usługach zarządzanych hiperskalera, a ministerstwo musi utrzymywać kompetencje do prowadzenia i łatania każdego komponentu – ale gwarancje suwerenności są bezwzględne, ponieważ kod źródłowy każdego komponentu jest audytowalny i żaden zagraniczny dostawca nie ma uprzywilejowanego dostępu operacyjnego.

Jak Terraform wspiera przenośność między środowiskami chmury suwerennej?

Abstrakcja dostawców Terraform umożliwia opisanie infrastruktury w modułach niezależnych od dostawcy, z implementacjami właściwymi dla dostawcy podmienianymi na poziomie modułu głównego. Wzorzec przenośności chmury suwerennej definiuje wewnętrzne interfejsy modułów – moduł klastra obliczeniowego, moduł zarządzanej bazy danych, moduł zasobnika magazynu obiektowego – które przyjmują te same wejścia i dają te same wyjścia niezależnie od tego, czy dostawcą bazowym jest wdrożenie OpenStack, narodowy dostawca chmury czy krajowa strefa hiperskalera. Gdy ministerstwo musi migrować z jednej platformy bazowej na inną z powodu ryzyka dostawcy, zmiany regulacyjnych lub ewolucji zdolności, zmienia się wyłącznie powiązanie z dostawcą – definicje modułów obciążeń, potoki wdrożeniowe i testy infrastruktury pozostają niezmienione. Praktyczną granicą tej przenośności są usługi zarządzane: modułu oplatającego zarządzaną usługę bazodanową specyficzną dla hiperskalera nie da się trywialnie przenieść na OpenStack bez zastąpienia usługi bazowej równoważnym wdrożeniem prowadzonym samodzielnie.

Jakie są kluczowe ryzyka chmury suwerennej dla ministerstwa obrony?

Ryzyka główne to: luka zdolności (dostawcy narodowi i stosy open source często ustępują hiperskalerom o kilka lat w zarządzanych usługach AI/ML, platformach serverless i wydajności sieci globalnej – to ogranicza nowoczesną mapę drogową zdolności); złożoność operacyjna (wewnętrzne prowadzenie OpenStack, Ceph, Kubernetes i Keycloak wymaga głębokich kompetencji, trudnych do rekrutacji i utrzymania w administracji); ryzyko łańcucha dostaw w sprzęcie (serwery, sprzęt sieciowy i pamięć masową kupowane od dostawców niebędących podmiotami narodowymi niosą własne ryzyka suwerenności łańcucha dostaw – nawet w pełni narodowa chmura może zostać skompromitowana w warstwie sprzętowej); oraz fałszywa suwerenność (chmura, która spełnia rezydencję danych na papierze, ale ma personel operacyjny hiperskalera z dostępem uprzywilejowanym albo używa zagranicznych HSM do zarządzania kluczami, daje słabsze gwarancje, niż sugeruje jej dokumentacja architektury). Zarządzanie ryzykiem wymaga traktowania suwerenności jako spektrum wielu niezależnie weryfikowalnych wymiarów, a nie binarnej certyfikacji.

Jak powinny być rozdzielone obciążenia niejawne i jawne w chmurze suwerennej?

Obciążenia niejawne i jawne muszą być rozdzielone w warstwie fizycznej – osobne klastry Kubernetes na osobnych pulach węzłów, bez współdzielonego etcd, bez współdzielonej płaszczyzny kontroli i bez współdzielonej infrastruktury sieciowej między poziomami klauzul. Rozdzielenie logiczne w ramach jednego klastra (izolacja przestrzeni nazw, NetworkPolicy) jest niewystarczające dla obciążeń na różnych poziomach klauzul, ponieważ podatność płaszczyzny kontroli lub ucieczka z kontenera może przekroczyć granice przestrzeni nazw. W praktyce oznacza to osobne tenanty OpenStack z fizycznie osobnymi klastrami pamięci masowej Ceph dla każdego poziomu klauzul, osobne realmy Keycloak lub całkowicie odrębnych dostawców tożsamości oraz osobne potoki CI/CD z osobnymi kluczami podpisującymi, tak aby kompromitacja jawnego potoku budowania nie mogła wprowadzić złośliwych obrazów do poziomu niejawnego. Transfer danych między poziomami musi przechodzić przez formalnie ocenione rozwiązanie międzydomenowe, a nie przez łączność sieciową.

Jak powinna wyglądać mapa drogowa zdolności ministerstwa obrony dla chmury suwerennej?

Realistyczna mapa drogowa zdolności chmury suwerennej dla ministerstwa obrony ma trzy fazy. Faza 1 (lata 1–2) buduje fundament: wdrożenie krajowej warstwy IaaS (OpenStack lub równoważnej), migrację obciążeń z chmury komercyjnej na infrastrukturę krajową, wdrożenie kontroli rezydencji danych i narodowego zarządzania kluczami oraz rozmieszczenie krajowej płaszczyzny kontroli Kubernetes. Faza 2 (lata 2–4) buduje warstwę platformy: wdrożenie Keycloak dla tożsamości federacyjnej, wdrożenie IaC opartego na Terraform z abstrakcją dostawców, budowę wewnętrznego rejestru kontenerów z kontrolami łańcucha dostaw (podpisywanie obrazów, skanowanie podatności) oraz ustanowienie topologii sovereign-connected z krajową strefą hiperskalera na szczytowe zapotrzebowanie i odporność. Faza 3 (lata 4+) celuje w zrównanie zdolności: budowę lub zakup suwerennych zarządzanych usług bazodanowych i analitycznych, wdrożenie lokalnej infrastruktury treningowej AI/ML, wdrożenie architektury zero trust we wszystkich poziomach oraz ustanowienie ram automatyzacji ciągłej zgodności obejmujących wszystkie komponenty stosu suwerennego.