Suwerenna chmura to jeden z najbardziej przeładowanych terminów w obronnym procurementach IT. Dostawcy stosują go do wszystkiego — od regionu hyperscalera, którego budynki stoją w granicach państwowych, po w pełni air-gapped chmurę prywatną obsługiwaną wyłącznie przez przeszłych weryfikacje obywateli kraju. Etykieta ukrywa decyzje architektoniczne, które w praktyce decydują o tym, czy obcy rząd może wymusić ujawnienie twoich danych, czy zagraniczna służba wywiadowcza może zwerbować personel operatora chmury i czy twój plan ciągłości działania przetrwa geopolityczny rozłam. Dla obciążeń obronnych te pytania są nośne.

Ten artykuł omawia praktyczny krajobraz suwerennych chmur na rok 2026: amerykańskie rządowe regiony hyperscalerów, nową generację europejskich ofert suwerennych (Bleu, Delos, T-Systems, OVH), chmury NATO i narodowe chmury obronne oraz on-prem'ową bazę, z którą wszystkie one ostatecznie konkurują. Jest pisany dla architektów podejmujących decyzje o lokalizacji obciążeń, a nie dla zespołów procurementowych piszących RFP.

1. Co właściwie oznacza „suwerenna chmura”

Suwerenność w chmurze to nie jedna właściwość — to trzy ortogonalne wymiary, a każda uczciwa ocena musi punktować je niezależnie.

Rezydencja danych to najłatwiejszy i najbardziej przeceniany. Pyta: gdzie fizycznie żyją bajty? Region we Frankfurcie, Paryżu czy Warszawie zaspokaja rezydencję dla nabywców UE. Ale sama rezydencja to najsłabsza gwarancja suwerenności w ofercie, ponieważ nie mówi nic o tym, kto może sięgnąć po te bajty przez control plane.

Suwerenność operatora pyta: kto może administrować infrastrukturą? Komercyjne regiony hyperscalerów z USA są administrowane przez globalnie rozproszone zespoły inżynieryjne — ticket L2 dotykający twojego tenanta może być obsłużony z Indii, Irlandii lub Seattle. Oferty suwerenne klasy rządowej ograniczają to do zdefiniowanego zestawu zweryfikowanych obywateli, ze ścieżkami audytu wystarczającymi do dowiedzenia zgodności. SecNumCloud (Francja) i C5 (Niemcy) wymagają, by operatorzy byli obywatelami UE pracującymi pod jurysdykcją UE.

Suwerenność jurysdykcyjna to wymiar łamiący najwięcej założeń procurementowych. Amerykański CLOUD Act z 2018 pozwala władzom USA wymusić od dowolnej firmy zarejestrowanej w USA wydanie danych pod jej kontrolą, niezależnie od fizycznej lokalizacji tych danych. Tak więc hyperscaler z centralą w USA prowadzący infrastrukturę we Frankfurcie wciąż jest prawnie osiągalny z amerykańskiego sądu. Odpowiedź UE — RODO, Schrems II, Data Act — wyostrzyła pytanie, ale go nie rozwiązała. Jedyna strukturalna odpowiedź to umieszczenie zarówno danych, jak i podmiotu korporacyjnego je kontrolującego pod jurysdykcją UE.

Użyteczna diagnostyka: zapytaj, czy zagraniczny nakaz sądowy doręczony dostawcy chmury mógłby w zasadzie wymusić ujawnienie danych twojego obciążenia bez udziału twojego rządu. Jeśli uczciwa odpowiedź brzmi „tak”, nie masz suwerennej chmury — masz chmurę regionalną.

2. Oferty suwerenne hyperscalerów z USA

Amerykańscy hyperscalerzy spędzili piętnaście lat budując izolację klasy rządowej. Rezultatem jest najdojrzalszy poziom suwerennej chmury na planecie — dla nabywców związanych z USA.

AWS GovCloud (US-East i US-West) jest fizycznie izolowany, administrowany wyłącznie przez osoby z USA i akredytowany na FedRAMP High oraz DoD IL4/IL5. AWS Secret Region i AWS Top Secret Region istnieją dla warstw niejawnych, ale są osiągalne tylko przez akredytowanych nabywców rządowych USA i kontraktorów. AWS ogłosił European Sovereign Cloud (Brandenburgia) z dostawą w 2026, operowany w pełni przez obywateli UE — pierwszy hyperscaler z USA, który zobowiązał się do takiej struktury dla nabywców UE.

Azure Government odzwierciedla model AWS z Azure Government (FedRAMP High, IL5), Azure Government Secret (IL6) i Azure Government Top Secret. Microsoft ma najbardziej rozległy akredytowany ślad w warstwie niejawnej, a Azure Government dziedziczy większość usług komercyjnego Azure z opóźnieniem sześciu do dwunastu miesięcy. Microsoft prowadzi też Microsoft Cloud for Sovereignty jako konfigurowalną warstwę na komercyjnym Azure dla nabywców chcących kontroli suwerennych bez pełnego narzutu akredytacji Azure Government — patrz nasze porównanie architektury GovCloud dla szczegółów lokowania Azure vs AWS.

Google Assured Workloads to najlżejsza z trzech: nakładka control plane na komercyjny Google Cloud wymuszająca rezydencję, personel i ograniczenia zarządzania kluczami. Celuje w FedRAMP High i IL5 dla konkretnych konfiguracji, ale nie prowadzi osobnego regionu. Dla obciążeń, gdzie skonfigurowany region komercyjny jest akceptowalny, może to skrócić czas do ATO; dla IL6 i wyżej nie konkuruje.

Twarde ograniczenie dla nabywców spoza USA: GovCloud, Azure Government i warstwy IL5/IL6 są bramkowane przez dostęp tylko dla osób z USA oraz amerykańską kontrolę eksportu. Francuska jednostka sił powietrznych nie może kupić pojemności GovCloud. To strukturalna przyczyna istnienia warstwy suwerennej chmury UE.

3. Oferty suwerenne UE

Bleu to francuska suwerenna chmura — joint venture między Capgemini a Orange. Prowadzi licencjonowaną technologię Microsoft Azure w francuskich centrach danych, obsługiwaną tylko przez obywateli Francji, z kontrolą korporacyjną w całości pod francuskim prawem — wyraźnie poza zasięgiem CLOUD Act. Kwalifikacja SecNumCloud to wiodąca akredytacja. Bleu to najczystszy przykład modelu „licencjonowany hyperscaler pod suwerennym operatorem” i jest preferowaną lokalizacją dla obciążeń francuskiej obronności, ministerstw i OIV (operatorów istotnych).

Delos to niemiecka suwerenna chmura zbudowana przez SAP i Arvato Systems, znowu na licencjonowanej technologii Microsoftu, celująca w akredytację C5 i przeznaczona dla obciążeń Bund (federalnych) i Länder (krajów związkowych). Delos i Bleu to bliźniaki: ten sam wzorzec techniczny, różne jurysdykcje narodowe.

T-Systems Sovereign Cloud to starsza oferta Deutsche Telekom — suwerenna chmura zbudowana bez warstwy licencyjnej hyperscalera, na OpenStack i własnej orkiestracji Telekom. Celuje w tę samą bazę nabywców co Delos, ale z niższym pułapem funkcji i dłuższym operacyjnym track recordem. Dla obciążeń niewymagających pełnej powierzchni API hyperscalera T-Systems jest często tańszy i szybszy do uruchomienia.

OVHcloud zajmuje wyraźną niszę: w pełni europejska alternatywa hyperscalowa z bare-metal pods, dedykowaną chmurą i warstwą chmury publicznej, wszystkie pod jurysdykcją francuską. OVH nie udaje, że dorównuje parytetowi funkcji AWS, ale dla obciążeń compute-heavy i storage-heavy jest konkurencyjny cenowo i dostarcza prawdziwą suwerenność jurysdykcyjną bez zależności licencyjnej od USA. Dla głębszej analizy lokowania UE vs US patrz nasze porównanie suwerennej chmury UE vs US.

4. Chmury NATO i narodowe chmury obronne

Nad komercyjną warstwą suwerenną siedzi warstwa, której nie ma w broszurach dostawców: chmury NATO i narodowych MoD. To miejsca docelowe dla obciążeń niejawnych, gdzie nawet SecNumCloud czy FedRAMP High są niewystarczające.

NCIA Software Factory i szerszy program chmurowy NATO dostarczają platformę poziomu sojuszu dla wielonarodowych obciążeń niejawnych (NATO Secret i niżej). Narodowe MoD prowadzą równoległe chmury suwerenne — MODCloud w Wielkiej Brytanii, chmura BWI Bundeswehry w Niemczech, holenderski CC-NDC, polska chmura MON — każda akredytowana do narodowej warstwy niejawnej i zintegrowana z protokołami wymiany sojuszniczej.

Poniżej siedzi właściwa warstwa air-gapped, dla obciążeń odpowiadających TS/SCI. Pokrywaliśmy wzorzec architektoniczny w wdrożeniu air-gapped dla obronności. Istotny punkt jest tu taki, że decyzje o lokowaniu obciążeń muszą jawnie obejmować tę warstwę — przenoszenie obciążenia z NATO Secret w dół do komercyjnej chmury suwerennej jest rzadkie, ale w górę powszechne, a architektura musi przetrwać tę zmianę bez przeprojektowywania.

5. Hybryda i baza on-prem

Suwerenna chmura nie zawsze jest właściwą odpowiedzią. Baza prywatnej chmury on-prem — VMware vSphere, OpenStack lub Kubernetes na bare metal w akredytowanym narodowym centrum danych — wciąż wygrywa w trzech scenariuszach.

Po pierwsze, dla obciążeń niejawnych lub air-gapped, które nie mogą tolerować żadnej zewnętrznej zależności sieciowej. Suwerenni hyperscalerzy oferują tryby rozłączone (Azure Stack Hub, AWS Outposts, Google Distributed Cloud Air-Gapped), ale ceny, model wsparcia i ograniczenia dostępu operatora często cofają kalkulację do chmury prywatnej.

Po drugie, dla obciążeń o ustalonym stanie, gdzie amortyzacja capex bije narzut hyperscalera. Obciążenie działające 24/7 z przewidywalnym obciążeniem przez pięć lat to najgorsze możliwe ekonomiczne dopasowanie dla dowolnej chmury — suwerennej czy nie. Narzut hyperscalera nad zamortyzowanym bare metalem jest zazwyczaj 3-5x rocznie.

Po trzecie, dla organizacji, które już prowadzą certyfikowane centra danych. Marginalny koszt jeszcze jednej szafy jest niski. Marginalny koszt zbudowania zdolności operacyjnej suwerennej chmury hyperscalera jest wysoki. Dla zasiedziałych organizacji IT MoD rozszerzenie on-prem jest zwykle tańszą ścieżką przejścia.

Kluczowy wniosek: Pytanie o lokowanie rzadko brzmi „suwerenna chmura czy nie”. Brzmi „która warstwa suwerenności per obciążenie i jakie transfery międzywarstwowe są wymagane?” Nowoczesna obronna majątek prowadzi wszystkie cztery — chmurę komercyjną dla marketingu, chmurę suwerenną dla CUI, narodową chmurę MoD dla restricted-i-wyżej, air-gapped chmurę prywatną dla secret-i-wyżej — a architektura żyje w konektorach między nimi. Patrz kompletny przewodnik po cyberbezpieczeństwie obronnym dla otaczającego framework'a kontroli.

6. Decyzje o lokowaniu obciążeń

Lokowanie obciążeń sprowadza się do małego zestawu warstw klasyfikacji i małego zestawu kompromisów koszt-vs-kontrola. Praktyczna macierz:

Niejawne, publicznie dostępne (strony, portale rekrutacyjne, publiczne API) należy do komercyjnych regionów hyperscalerów w twojej jurysdykcji. Kontrole suwerenności dodają koszt i tarcie operacyjne bez proporcjonalnej wartości.

Niesklasyfikowane, wewnętrzne CUI (HR, finanse, wewnętrzna kolaboracja) należy do chmury suwerennej — klasy Bleu/Delos/Azure Gov — dla ochrony jurysdykcyjnej danych personalnych i operacyjnych, mimo że nie obowiązuje formalne oznaczenie niejawne. Ekspozycja na CLOUD Act jest czynnikiem decydującym.

Restricted i NATO Restricted należy do narodowej chmury MoD lub równoważnej warstwy sojuszniczej. Komercyjna chmura suwerenna jest tu zwykle niewystarczająca z powodów akredytacyjnych, a nie technicznych.

Secret i wyżej należy do air-gapped narodowej lub sojuszniczej infrastruktury. Żadna komercyjna akredytacja chmury nie sięga tej warstwy w 2026.

Koszt, który zespoły procurementowe niedoszacowują, to transfer między domenami: za każdym razem, gdy dane przekraczają warstwy, wymagane jest cross-domain solution (jednokierunkowa dioda, inspekcyjna brama treści lub akredytowane urządzenie cross-domain). Są one wolne, drogie i stanowią operacyjne wąskie gardło architektur wielowarstwowych. Projektowanie z myślą o minimalizacji wymaganych transferów ma większą wartość niż optymalizacja wewnątrz pojedynczej warstwy.

7. Wzorce architektoniczne

Trzy wzorce powtarzają się w dobrze zaprojektowanych majątkach obronnych.

Control-plane w chmurze suwerennej, data-plane w chmurze misji. Tożsamość, polityka, monitoring i CI/CD żyją w chmurze warstwy suwerennej, gdzie dostęp operatora i audyt są ścisłe. Obciążenia misji — przetwarzanie czujników, usługi C2, analityka geoprzestrzenna — działają tam, gdzie wymaga tego latencja i klasyfikacja, często na infrastrukturze brzegowej lub chmurze misji. Control plane zarządza data plane przez wąskie, audytowane interfejsy. To ta sama separacja, którą zero-trust w sieciach wojskowych formalizuje w warstwie sieciowej.

Federowana tożsamość między warstwami. Tożsamość musi obejmować cały majątek — analityk nie powinien potrzebować trzech osobnych poświadczeń dla chmury suwerennej, chmury MoD i enklawy air-gapped. Federowana tożsamość z autoryzacją opartą na claims, zakotwiczona w suwerennym dostawcy tożsamości i projektowana (przez zatwierdzone mechanizmy cross-domain) na warstwy o wyższej klasyfikacji, to standardowy wzorzec. Trudny problem to cykl życia poświadczeń przez air-gap.

Regionalna topologia wdrożenia. Regiony chmury suwerennej są rzadsze niż regiony komercyjne. Wielregionowe wdrożenie active-active, które jest trywialne w komercyjnym AWS, staje się starannym ćwiczeniem projektowym w GovCloud (dwa regiony) lub Bleu (początkowo jeden). Matematyka domeny awarii się zmienia: regionalna odporność często oznacza odporność hybrydową, z chmurą suwerenną jako primary failującym na on-prem secondary w tej samej jurysdykcji. Patrz strategia multi-cloud dla obronności dla szczegółów wzorca odporności.

8. Vendor lock-in i planowanie wyjścia

Lock-in suwerennej chmury jest trudniejszy niż lock-in komercyjnej chmury, ponieważ zestaw substytutów jest mniejszy. Istnieje pięć opłacalnych opcji suwerennych UE. Istnieją dwie realne opcje klasy GovCloud z USA. Dźwignia, jaką pojedynczy dostawca ma na uwięzionym kliencie obronnym, jest odpowiednio większa.

Łagodzenie ma trzy warstwy.

Abstrakcje infrastruktury. Terraform z modułami niezależnymi od dostawcy lub Crossplane na Kubernetes pozwala artefaktowi wdrożeniowemu przetrwać zmianę dostawcy. Trudniejsza dyscyplina to unikanie usług proprietarnych dostawcy tam, gdzie istnieje przenośna alternatywa — używanie zarządzanego Kubernetes (EKS, AKS, OVH Managed Kubernetes) zamiast PaaS specyficznego dla dostawcy, używanie object storage zgodnego z S3 zamiast natywnych API blob, używanie PostgreSQL lub open-source'owych silników danych zamiast proprietarnych baz dostawcy. Koszt przenośności jest realny, ale ograniczony; koszt późnoetapowej migracji jest nieograniczony.

Ćwiczenie wyjścia. Ćwiczenie „opuszczenie GovCloud” — faktyczne zrobienie tabletop lub pilotażowej migracji niekrytycznego obciążenia z wybranej chmury suwerennej do innego suwerennego dostawcy lub on-prem — ujawnia koszt lock-in konkretnie. Organizacje obronne powinny prowadzić to ćwiczenie co najmniej co dwa lata na każde duże obciążenie. Wynikiem jest udokumentowany runbook migracji z czasem i kosztorysem, który zasila rejestr ryzyk procurementowych i plan BCP/DR.

Klauzule kontraktowe. Procurement powinien wymagać czytelnego maszynowo eksportu danych w zdefiniowanym oknie, praw IP do automatyzacji wdrożeniowej, braku premii za egress w celu wyjścia od dostawcy i warunków pomocy przejściowej. To tam oprogramowanie obronne wolne od ITAR i język wyjścia od dostawcy zbiegają się: cel w obu przypadkach to zachowanie suwerennej opcjonalności niezależnie od dalszej współpracy jakiegokolwiek pojedynczego zagranicznego dostawcy.

Suwerenna chmura, dobrze wykonana, to nie pojedyncza decyzja procurementowa, lecz postawa portfelowa: jawne lokowanie per obciążenie, świadome projektowanie transferu międzywarstwowego, abstrakcje infrastruktury zachowujące wyjście oraz powracające ćwiczenie weryfikujące, że wyjście faktycznie działa. Dostawcy będą dalej dodawać etykiety suwerenności. To architektura decyduje, czy te etykiety coś znaczą.