Strategia multi-cloud dla obrony: unikanie uzależnienia od dostawcy w systemach wojskowych

Zależność od jednego dostawcy chmury stanowi ryzyko strategiczne dla systemów obronnych analitycznie podobne do zależności od jednego dostawcy w jakiejkolwiek innej dziedzinie kluczowych możliwości. Gdy cała infrastruktura chmurowa programu obronnego działa u jednego dostawcy, dostawca ten może wywierać presję poprzez ceny, zaprzestanie świadczenia usług lub zmiany kontraktowe przy odnowieniu. Zmiany geopolityczne mogą skomplikować lub wyeliminować dostęp do infrastruktury chmurowej należącej do podmiotów zagranicznych. Poważna awaria chmury może zdegradować lub wyeliminować operacyjne zdolności obronne zależne od tej infrastruktury.

Strategia multi-cloud rozwiązuje to ryzyko strategiczne poprzez dystrybucję obciążeń między wieloma dostawcami, utrzymanie przenośności na poziomie architektury i unikanie głębokiego uzależnienia od własnościowych usług chmurowych, które sprawiłyby, że migracja byłaby wygórowanie droga. Ten artykuł analizuje, jak działają wzorce wdrożenia multi-cloud, jak narzędzia Infrastructure-as-Code niezależne od chmury wspierają przenośność oraz jak zarządzana jest złożoność zgodności przy utrzymaniu kontroli klasyfikacji u wielu dostawców.

Strategiczne ryzyko zależności od jednego dostawcy chmury

Ryzyko geopolityczne jest najbardziej charakterystycznym dla obronności ryzykiem w zależności od dostawcy chmury. Relacje między organizacjami obronnymi a dostawcami chmury są pośredniczone przez struktury polityczne i prawne, które mogą się zmieniać. Ustawodawstwo UE dotyczące suwerenności danych (RODO, wyłączenia bezpieczeństwa narodowego, EUCS) tworzy trwałą niepewność prawną co do długoterminowej legalności przechowywania danych obronnych w infrastrukturze dostawców z siedzibą w USA.

Ryzyko operacyjne z powodu awarii jest bardziej bezpośrednią obawą. Główni dostawcy chmury doświadczają znaczących awarii: awarie AWS us-east-1 w 2021 i 2023 roku zakłóciły pracę dużych części komercyjnego internetu na godziny. Dla systemów obronnych z wymaganiami dotyczącymi dostępności zależność od jednego dostawcy chmury bez możliwości awaryjnych jest operacyjnie nie do przyjęcia.

Presja cenowa jest ryzykiem komercyjnym o implikacjach strategicznych. Dostawcy chmury mogą podnosić ceny przy odnowieniu kontraktów; koszty przejścia w głęboko zintegrowanych architekturach utrudniają reagowanie. Doświadczenia DoD z przetargami na kontrakty chmurowe JEDI i JWCC odzwierciedlały świadomość tego ryzyka — wielodostawcowa struktura JWCC była wyraźnie zamierzona, aby zapobiec uzależnieniu od jednego dostawcy.

Wzorce wdrożenia multi-cloud

Aktywno-aktywny podział obciążeń dystrybuuje różne typy obciążeń między różnych dostawców chmury w oparciu o przewagi komparatywne każdego z nich: program obronny może uruchamiać sklasyfikowane aplikacje u dostawcy z najsilniejszymi akredytacjami chmury sklasyfikowanej, analitykę i obciążenia ML u dostawcy z najlepszą infrastrukturą ML, a narzędzia współpracy u trzeciego suwerennego dostawcy UE ze względu na rezydencję danych.

Odtwarzanie po awarii pierwotno-wtórne uruchamia obciążenia produkcyjne u pierwotnego dostawcy z ciepłym środowiskiem rezerwowym u dostawcy wtórnego. Środowisko wtórne jest utrzymywane w wystarczającej gotowości, aby przejąć obciążenia w określonym RTO (Recovery Time Objective) w przypadku awarii pierwotnego. Ten wzorzec jest prostszy operacyjnie, ale wymaga regularnych testów przełączania awaryjnego w celu weryfikacji, że środowisko wtórne może rzeczywiście przejąć obciążenia w realistycznych warunkach.

IaC niezależny od chmury: Terraform i Crossplane

Terraform (od HashiCorp, obecnie produkt z licencją BSL z fork'iem open-source w OpenTofu) jest standardowym narzędziem Infrastructure-as-Code dla aprowizacji zasobów niezależnej od chmury. Dostawcy Terraform istnieją dla wszystkich głównych platform chmurowych (AWS, Azure, GCP, OVHcloud i dziesiątek innych), a składnia konfiguracji Terraform jest niezależna od chmury.

W przypadku architektur multi-cloud system przestrzeni roboczych i modułów Terraform pozwala na instancjowanie tej samej infrastruktury aplikacji u różnych dostawców: moduł Terraform dla „trójwarstwowej aplikacji webowej" może mieć implementacje specyficzne dla dostawcy (jedną dla AWS, jedną dla Azure, jedną dla OVHcloud), które udostępniają ten sam interfejs.

Crossplane to projekt CNCF-graduated, który zapewnia opartą na Kubernetes płaszczyznę sterowania dla aprowizacji zasobów chmurowych. System Crossplane Composition umożliwia abstrakcję zasobów chmurowych: Composition definiuje typ zasobu złożonego (np. „DefenceDatabase"), który mapuje się na zasoby specyficzne dla dostawcy, pozwalając zespołom aplikacji żądać DefenceDatabase bez znajomości, czy jest ono obsługiwane przez AWS RDS, Azure Database for PostgreSQL, czy lokalną instancję PostgreSQL.

Crossplane jest szczególnie cenny dla programów obronnych przyjmujących model inżynierii platformy: centryczny zespół platformy zarządza kompozycjami Crossplane i konfiguracjami dostawców, a zespoły aplikacji konsumują zasoby chmurowe poprzez samoobsługę.

Przenośność danych: otwarte formaty i pamięć masowa kompatybilna z S3

Uzależnienie od dostawcy chmury na poziomie danych — gdzie dane są przechowywane we własnościowych formatach lub usługach bez standardowego mechanizmu eksportu — jest najtrudniejszą formą uzależnienia do ucieczki. Unikanie tego wymaga jawnego projektowania przenośności danych:

Pamięć masowa obiektów kompatybilna z S3 jest praktycznym standardem dla agnostycznego wobec chmury przechowywania danych. API Amazon S3 stało się de facto standardem dla pamięci masowej obiektów, z interfejsami API kompatybilnymi z S3 zapewnianymi przez Azure Blob Storage, GCP Cloud Storage, OVHcloud Object Storage i lokalne rozwiązania takie jak MinIO.

Standardowy SQL na zarządzanych bazach danych kompatybilnych z PostgreSQL unika uzależnienia od własnościowych usług baz danych. Aplikacje korzystające ze standardowego SQL i protokołu PostgreSQL mogą migrować między dostawcami jedynie przy zmianach konfiguracji.

Złożoność zgodności: kontrole klasyfikacji u wielu dostawców

Najbardziej znaczącym wyzwaniem operacyjnym w wielochmurowych architekturach obronnych jest utrzymanie kontroli klasyfikacji spójnie u wielu dostawców, każdy z różnymi możliwościami usług, różnymi certyfikatami zgodności i różnymi narzędziami do wdrażania kontroli bezpieczeństwa.

Kontrole klasyfikacji — kontrola dostępu oparta na poziomie dostępu, rejestrowanie audytu całego dostępu do sklasyfikowanych danych, zarządzanie kluczami szyfrowania, egzekwowanie rezydencji danych — muszą być równoważnie zaimplementowane u każdego dostawcy używanego dla sklasyfikowanych obciążeń.

Praktyczne podejście polega na zbudowaniu warstwy zgodności niezależnej od dostawcy: zestawu modułów Terraform/Crossplane i polityk kontrolerów admisji Kubernetes, które implementują wymagane kontrole zgodności niezależnie od tego, który dostawca chmury aprowizuje bazowe zasoby.