Wybór platformy chmurowej dla obciążeń obronnych to przede wszystkim decyzja o zgodności i suwerenności danych, a nie technologiczna. Podstawowa infrastruktura obliczeniowa Azure Government i AWS GovCloud jest zasadniczo podobna do ich komercyjnych odpowiedników. Różnica leży w postawie regulacyjnej zgodności, fizycznej i logicznej izolacji od komercyjnych najemców, modelu wsparcia oraz maksymalnym obsługiwanym poziomie klasyfikacji.

Błędna decyzja ma konsekwencje trudne do odwrócenia. Migracja aplikacji obronnej z jednej platformy chmurowej na drugą po wdrożeniu produkcyjnym to znaczące przedsięwzięcie na poziomie programu. Decyzja o wyborze platformy, podjęta wcześnie, ogranicza architekturę przez cały czas trwania programu.

Frameworki zgodności: FedRAMP, poziomy IL i wymagania NATO

Główny amerykański framework zgodności dla obciążeń chmurowych to FedRAMP (Federal Risk and Authorization Management Program), który definiuje trzy poziomy wpływu: niski, umiarkowany i wysoki. FedRAMP High jest poziomem bazowym dla wrażliwych, ale jawnych danych rządowych. Zarówno Azure Government, jak i AWS GovCloud posiadają autoryzacje FedRAMP High dla większości usług.

Powyżej FedRAMP, Przewodnik po wymaganiach bezpieczeństwa przetwarzania w chmurze DoD (CC SRG) definiuje poziomy wpływu od 4 do 6. IL4 obejmuje kontrolowane informacje jawne (CUI) z oznaczeniem bezpieczeństwa narodowego. IL5 obejmuje Systemy Bezpieczeństwa Narodowego (NSS) i informacje niejawne DoD do poziomu SECRET. IL6 obejmuje dane SECRET. Tylko określone, fizycznie izolowane regiony chmurowe kwalifikują się dla obciążeń IL5 i IL6 — nie standardowe regiony GovCloud.

Dla krajów członkowskich NATO spoza USA odpowiednimi frameworkami są wymagania bezpieczeństwa chmury NATO NCIA (Agencja Łączności i Informatyki) oraz ich krajowe odpowiedniki. NATO NCIA zatwierdziła określone oferty usług chmurowych dla danych NATO RESTRICTED i NATO CONFIDENTIAL po własnych procesach audytowych. Te zatwierdzenia nie są automatycznie przyznawane przez FedRAMP — wymagana jest oddzielna ocena.

Azure Government vs AWS GovCloud: kluczowe różnice

Fizyczna izolacja. Obie platformy działają na fizycznie oddzielnej infrastrukturze od swoich komercyjnych chmur, obsługiwanej wyłącznie przez sprawdzonych obywateli USA (dla programów amerykańskich) lub równoważne krajowe wymagania weryfikacyjne. Obie zapewniają logiczne oddzielenie poprzez dedykowane opcje infrastrukturalne (dedykowane hosty, obliczenia bare metal).

Parytety dostępności usług. Komercyjne usługi chmurowe często pojawiają się w GovCloud z opóźnieniem 12–24 miesięcy. AWS GovCloud historycznie ma szerszy parytet katalogu usług z komercyjnym AWS. Azure Government ma silny parytet w podstawowych usługach IaaS i PaaS i znacznie poprawiło pokrycie usług AI/ML, choć niektóre komercyjne usługi Azure pozostają niedostępne w chmurze rządowej.

Usługi specyficzne dla DoD. Microsoft posiada kontrakt DoD JEDI/JWCC i dokonał znacznych inwestycji w regiony Azure Government zdolne do obsługi IL5. AWS obsługuje środowisko C2S (Commercial Cloud Services) dla społeczności wywiadowczej i posiada regiony GovCloud East i West zdolne do IL5. Dla programów wymagających IL5 obie są wykonalne — konkretna dostępność usług na poziomie IL5 różni się w zależności od regionu i musi być zweryfikowana w aktualnej dokumentacji dostawcy.

Model wsparcia. Obaj dostawcy oferują dedykowane rządowe poziomy wsparcia z przebadanym personelem. Dla programów ze ścisłymi wymaganiami bezpieczeństwa operacyjnego weryfikacja, że dostęp do wsparcia jest ograniczony do odpowiednio sprawdzonego personelu — i podlega audytowi — jest wymogiem kontraktowym, a nie założeniem.

Chmura hybrydowa dla obciążeń niejawnych

Większość programów obronnych powyżej poziomu SECRET nie może umieszczać obciążeń w komercyjnej chmurze — nawet w akredytowanym regionie GovCloud. Obciążenia niejawne na poziomie SECRET i wyżej muszą działać w akredytowanych obiektach rządowych lub wykonawczych z fizycznymi kontrolami bezpieczeństwa i wymogami dostępu personelu na poziomie SCIF. Chmura dla takich obciążeń to albo wdrożenie chmury prywatnej (sprzęt rządowy z IaaS podobnym do chmury), albo niejawne środowisko chmurowe, takie jak C2S lub Azure Government Top Secret.

Praktyczna architektura dla większości programów jest hybrydowa: jawne komponenty i CUI działają w GovCloud, niejawne w prywatnym lub niejawnym środowisku chmurowym, a rozwiązania między domenami (CDS) pośredniczą w transferze danych między tymi środowiskami. Prawidłowe zaprojektowanie CDS — w tym logiki walidacji danych, konwersji formatów i reklasyfikacji — jest zazwyczaj jednym z najbardziej złożonych i krytycznych czasowo elementów architektury.

Wymagania dotyczące rezydencji danych

Wiele programów obronnych ma umowne lub prawne wymagania określające, gdzie dane mogą być przechowywane i przetwarzane. Niejawne dane krajów członkowskich UE mogą mieć ograniczenia uniemożliwiające przechowywanie w infrastrukturze operowanej przez USA (nawet w europejskich centrach danych należących do USA). Dane niejawne NATO mają specyficzne wymagania dotyczące obsługi, które ograniczają miejsca ich przetwarzania.

Zarówno Azure, jak i AWS mają rządowe regiony chmurowe w Europie (Holandia, Niemcy) ze specyficzną postawą wobec wymagań suwerenności danych UE. Ocena tych opcji wymaga prawnego przeglądu konkretnych instrukcji klasyfikacji programu i przepisów krajowych, a nie tylko materiałów marketingowych dostawcy chmury.

Kluczowy wniosek: Architektura zerowego zaufania jest wymogiem, a nie wyborem, dla obronnych wdrożeń chmurowych. Założenia bezpieczeństwa oparte na obwodzie (ruch wewnętrzny jest zaufany) są architektonicznie niezgodne z chmurą wielodostępną i środowiskami hybrydowymi. Planuj uwierzytelnianie per-żądanie, mikrosegmentację i ciągłą weryfikację autoryzacji od pierwszego dnia.

Poziom bazowy zerowego zaufania dla chmury obronnej

Referencyjna architektura zerowego zaufania DoD definiuje siedem filarów: użytkownik, urządzenie, sieć, aplikacja/obciążenie, dane, automatyzacja/orkiestracja oraz widoczność/analityka. Dla wdrożenia GovCloud implementacja bazowego poziomu zerowego zaufania oznacza: dostęp oparty na tożsamości (Microsoft Entra ID / AWS IAM z MFA i dostępem warunkowym), egzekwowanie postawy urządzenia (brak dostępu z urządzeń niezarządzanych lub niezgodnych), mikrosegmentację sieci (zapora na poziomie aplikacji, brak domyślnego zaufania między usługami w tej samej VNet/VPC) oraz kontrole dostępu oparte na klasyfikacji danych (szyfrowanie w spoczynku z kluczami zarządzanymi przez klienta, etykiety klasyfikacji egzekwowane na poziomie aplikacji).

Izolacja wielodostępna na poziomie infrastruktury — zapewnienie, że obciążenie jednego najemcy nie może uzyskać dostępu do danych lub infrastruktury innego — jest gwarantowana przez dostawcę chmury. To, co nie jest gwarantowane, to izolacja na poziomie aplikacji. Wielodostępna aplikacja obronna przechowująca wszystkie dane najemców we współdzielonej bazie danych z zabezpieczeniami na poziomie wierszy nie jest zgodna z zerowym zaufaniem, niezależnie od platformy chmurowej, na której działa. Izolacja najemców musi być zaimplementowana i zweryfikowana na poziomie aplikacji.