Aplikacje obronne natywne dla chmury: mikroserwisy, siatka usług

Obronne platformy dowodzenia i kierowania historycznie miały charakter monolityczny — pojedynczą jednostkę wdrożeniową obejmującą zarządzanie śladami, przekaźnik łączności, koordynację wsparcia ogniowego i integrację rozpoznania za wspólną bazą danych. Monolit nie był przypadkiem: upraszczał akredytację, minimalizował sieciową powierzchnię ataku i odpowiadał modelowi kadrowemu małego zespołu utrzymującego jeden artefakt. Jednak kruchość, którą tworzy, jest coraz mniej do zaakceptowania. Aktualizacja pojedynczego komponentu wymaga okna serwisowego dla całej platformy. Gwałtowny wzrost liczby śladów ISR pogarsza działanie interfejsu wsparcia ogniowego. Zmiana schematu bazy danych na całe tygodnie blokuje niepowiązane wątki prac rozwojowych.

Architektura cloud-native przeciwdziała tym trybom awarii, dzieląc platformę na niezależnie wdrażane usługi, z których każda ma własną warstwę trwałości danych, jest zarządzana przez Kubernetes i zabezpieczona end-to-end przez service mesh. Nie jest to przede wszystkim opowieść o kosztach czy zwinności — to opowieść o odporności i suwerenności operacyjnej. Gdy usługa fuzji śladów ulega awarii w platformie C2 w architekturze cloud-native, awaria ma charakter izolowany. Interfejs koordynacji wsparcia ogniowego pozostaje dostępny, przekaźnik łączności nadal kieruje wiadomości, a operatorzy widzą zdegradowany — ale nie zanikły — wspólny obraz operacyjny (COP), podczas gdy uszkodzona usługa się samonaprawia. Porównywalnej izolacji nie da się uzyskać w monolicie bez celowej izolacji typu bulkhead wewnątrz procesu, co wprowadza w istocie taką samą złożoność.

Artykuł obejmuje pełny zakres wzorców cloud-native dla obronnych obciążeń C2 i ISR: dekompozycję domen na ograniczone konteksty, wdrożenie service mesh dla wzajemnego TLS i obserwowalności, wzorce operatorów Kubernetes dla komponentów stanowych, sterowaną zdarzeniami fuzję danych z sensorów z CQRS i event sourcing, praktykę SRE dla usług krytycznych dla misji oraz łagodną degradację w kontestowanych warunkach sieciowych.

Dlaczego cloud-native dla obronnych aplikacji C2/ISR

Argumentacja za cloud-native w obronności nie jest taka sama jak w oprogramowaniu komercyjnym. Zespoły komercyjne wdrażają mikrousługi ze względu na tempo rozwoju — mniejsze zespoły odpowiadają za mniejsze bazy kodu i dostarczają szybciej oraz niezależnie. Te korzyści istnieją także w obronności, ale mają charakter drugorzędny. Głównym argumentem jest odporność: tryby awarii monolitu są niezgodne z wymaganiami misji.

Kruchość monolitu w środowiskach kontestowanych. Monolityczna platforma C2 ma jedną domenę awarii. Nadmierne obciążenie pamięci w wątku przyjmowania śladów pogarsza działanie interfejsu wsparcia ogniowego. Zawieszona transakcja bazodanowa blokuje routing wiadomości. Komponent z wyciekiem pamięci wymaga restartu całej platformy — co jednocześnie wyłącza wszystkie funkcje. Takie tryby awarii są akceptowalne, gdy system działa w kontrolowanym środowisku garnizonowym z planowymi oknami serwisowymi. Nie są akceptowalne, gdy system jest głównym narzędziem świadomości sytuacyjnej dla jednostki w kontakcie bojowym lub gdy działania przeciwnika celowo godzą w stabilność systemu.

Niezależne tempo wdrażania aktualizacji zdolności. Programy obronne stoją przed paradoksem: muszą szybko aktualizować oprogramowanie (nowe sygnatury zagrożeń, zaktualizowana logika ROE, załatane podatności), a jednocześnie ograniczać zakłócenia operacyjne do minimum. W monolicie każda zmiana dotyka tego samego wdrażanego artefaktu, co wymaga pełnych testów regresji i okna serwisowego dla całej platformy. W architekturze cloud-native usługę fuzji zagrożeń można zaktualizować — zwalidować, wdrożyć i w razie potrzeby wycofać — bez ingerencji w interfejs wsparcia ogniowego ani przekaźnik łączności. Każda usługa ma niezależny cykl wydawniczy dopasowany do częstotliwości zmian i profilu ryzyka.

Skalowalność pozioma w sytuacjach nagłego wzrostu obciążenia. Operacje ISR generują wolumeny danych o dużej zmienności. Ćwiczenie na szczeblu teatru działań może wygenerować dziesięciokrotnie większe niż zwykle obciążenie śladami. Monolit skaluje się jako całość — aby obsłużyć szczytowe obciążenie, każdy komponent musi mieć zapewnione zasoby na poziomie szczytowym, co marnuje zasoby w czasie normalnych operacji. W platformie cloud-native usługa fuzji śladów skaluje się poziomo pod obciążeniem, podczas gdy interfejs wsparcia ogniowego i przekaźnik łączności utrzymują normalną liczbę replik. Kubernetes obsługuje skalowanie automatycznie w odpowiedzi na CPU, pamięć lub metryki niestandardowe wyprowadzone z głębokości kolejek w potoku przyjmowania danych z sensorów.

Cloud-native w obronności nie jest tożsame z chmurą publiczną. Wzorzec ten ma równie dobre zastosowanie w niejawnej infrastrukturze on-premises, prywatnych suwerennych środowiskach chmurowych oraz wysuniętych klastrach brzegowych z minimalną dystrybucją Kubernetes. Cechą definiującą jest to, że usługi są skonteneryzowane, zarządzane deklaratywnie i odizolowane od siebie — a nie miejsce, w którym znajduje się infrastruktura.

Dekompozycja na mikrousługi w aplikacjach C2

Najtrudniejszą częścią wdrażania cloud-native nie jest technologia — lecz decyzja, gdzie wyznaczyć granice usług. Błędne granice tworzą mikrousługi silnie sprzężone przez wspólne bazy danych lub synchroniczne łańcuchy wywołań tak długie, że awaria w dowolnym miejscu kaskadowo rozchodzi się wszędzie. Właściwe granice tworzą usługi, które można wdrażać, skalować i wymieniać niezależnie, bez koordynacji z sąsiednimi zespołami.

Projektowanie ograniczonych kontekstów dla domen C2. Projektowanie sterowane dziedziną dostarcza ram: należy zidentyfikować odrębne domeny w platformie C2 i wyznaczyć wokół nich granice w oparciu o własność danych, populacje odbiorców i semantykę aktualizacji. Platforma C2 zawiera zazwyczaj co najmniej pięć odrębnych domen, które dają się czysto odwzorować na ograniczone konteksty:

• Zarządzanie śladami — jest właścicielem autorytatywnego magazynu śladów, łączy raporty z sensorów, utrzymuje historię śladów i obsługuje wspólny obraz operacyjny. Częstotliwość aktualizacji jest wysoka (raporty z sensorów napływają bez przerwy); odbiorcami są praktycznie wszystkie pozostałe usługi.
• Przekaźnik łączności — zarządza routingiem wiadomości, topologią sieci radiowych i alokacją kanałów. Jest odseparowany od zarządzania śladami: łączność działa niezależnie od tego, czy fuzja śladów jest sprawna.
• Koordynacja wsparcia ogniowego — zarządza misjami ogniowymi, rozwiązywaniem kolizji i śledzeniem angażowania celów. Konsumuje dane o śladach, ale jest właścicielem własnego stanu; interfejs wsparcia ogniowego musi pozostać dostępny nawet wtedy, gdy fuzja śladów jest tymczasowo zdegradowana.
• Integracja rozpoznania — przyjmuje produkty rozpoznania, koreluje je ze śladami i publikuje oceny. Długotrwałe zadania analityczne o wymaganiach opóźnień innych niż w fuzji śladów w czasie rzeczywistym.
• Status logistyczny — śledzi poziomy zaopatrzenia jednostek, dostępność sprzętu i zapotrzebowania na utrzymanie. Inna częstotliwość aktualizacji i inna baza odbiorców niż w operacyjnych funkcjach C2.

Kontrakty interfejsów usług. Każdy ograniczony kontekst publikuje kontrakt interfejsu — specyfikację OpenAPI dla synchronicznych interfejsów REST lub gRPC, schemat Avro lub Protobuf dla asynchronicznych interfejsów zdarzeniowych. Kontrakty są podstawowym mechanizmem sprzężenia między usługami i muszą być wersjonowane oraz traktowane jako wrażliwe na zmiany łamiące zgodność. Usługa, która zmienia swój schemat zdarzeń bez zarejestrowania nowej wersji w rejestrze schematów, może po cichu uszkodzić konsumentów — tryb awarii niewidoczny do momentu, aż konsument przetworzy wadliwe zdarzenie i wyprodukuje niepoprawny wynik.

Najważniejsza zasada: usługi są właścicielami swoich danych. Usługa zarządzania śladami jest właścicielem magazynu śladów. Usługa wsparcia ogniowego jest właścicielem stanu misji ogniowych. Żadna usługa nie czyta bezpośrednio z bazy danych innej usługi. Cały międzyserwisowy dostęp do danych odbywa się przez opublikowany interfejs. To ograniczenie sprawia, że niezależne wdrażanie staje się realne — bez niego zmiana schematu bazy danych w zarządzaniu śladami łamie usługę wsparcia ogniowego niezależnie od ich nominalnej niezależności.

Szczegółowe omówienie tego, jak usługi te są utwardzane na poziomie infrastruktury, znajduje się w artykule Utrwardzanie Kubernetes dla obronności — opisuje on bezpieczeństwo podów, polityki sieciowe i konfigurację kontroli przyjęć, która uzupełnia dekompozycję usług.

Service mesh: mTLS i obserwowalność

Service mesh wstawia proxy sidecar (Envoy w przypadku Istio; lekki proxy napisany w Rust w Linkerd) do każdego poda, przejmując cały ruch przychodzący i wychodzący. Aplikacja komunikuje się z localhost; sidecar obsługuje szyfrowanie, uwierzytelnianie, ponowienia, wyłączniki obwodu i zbieranie telemetrii. Z perspektywy aplikacji sieć jest abstrahowana; z perspektywy operatora każde wywołanie w obrębie mesha jest widoczne i kontrolowane przez polityki.

Wzajemny TLS dla ruchu wschód–zachód w sieciach C2 o architekturze zero trust. Architektura zero trust wymaga, aby żadne wywołanie sieciowe nie było ufane wyłącznie z racji położenia w sieci — usługa wewnątrz granicy klastra musi uwierzytelniać się równie rygorystycznie jak usługa spoza niej. W service mesh skonfigurowanym do strict mTLS każde wywołanie wschód–zachód (usługa do usługi wewnątrz klastra) jest uwierzytelniane certyfikatami obciążenia roboczego wydawanymi przez urząd certyfikacji mesha. Usługa, która nie może przedstawić ważnego certyfikatu — czy to dlatego, że jest nieautoryzowanym obciążeniem roboczym, błędnie skonfigurowanym wdrożeniem, czy przejętym kontenerem — jest odrzucana na proxy sidecar, zanim żądanie dotrze do aplikacji.

W środowiskach niejawnych urząd certyfikacji mesha musi integrować się z wewnętrzną infrastrukturą PKI enklawy, a nie z urząd certyfikacji dostępnym z internetu. Istio obsługuje wymienialne backendy CA — Istio CA można zastąpić niestandardowym CA wydającym certyfikaty z łańcucha zaufania zakorzenionego w akredytowanej infrastrukturze PKI programu. Rotacja certyfikatów musi być zautomatyzowana: ręczne zarządzanie certyfikatami jest operacyjnie kruche i powodowało awarie w systemach niejawnych, gdy certyfikaty wygasały podczas ćwiczeń.

Istio a Linkerd w środowiskach niejawnych. Istio dostarcza bogatszy zestaw funkcji — AuthorizationPolicy na poziomie metody i ścieżki HTTP, klonowanie ruchu do analiz kanaryjskich, haki rozszerzeń Lua — ale kosztem wyższej złożoności i większego śladu płaszczyzny sterowania. Linkerd ma znacznie mniejszą powierzchnię ataku i prostszy model operacyjny, co czyni go atrakcyjnym dla programów, w których priorytetem jest minimalizacja bazy obliczeniowej podlegającej zaufaniu. Wybór zależy od wymagań funkcjonalnych konkretnego programu: jeśli potrzebna jest autoryzacja per ścieżka i klonowanie ruchu, złożoność Istio jest uzasadniona; jeśli podstawowymi wymaganiami są mTLS i podstawowa obserwowalność, prostota Linkerd jest preferowana.

Śledzenie rozproszone do analizy opóźnień. W platformie C2 z siedmioma lub więcej usługami w łańcuchu wywołań problemy z opóźnieniami są praktycznie niemożliwe do zdiagnozowania bez śledzenia rozproszonego. Żądanie, które trwa 800 ms end-to-end, mogło spędzić 600 ms na oczekiwaniu na zapytanie bazodanowe w usłudze zarządzania śladami i tylko 200 ms na transmisji oraz przetwarzaniu w pozostałych sześciu usługach. Bez śledzenia jedynym dostępnym sygnałem jest całkowite opóźnienie — wkłady poszczególnych usług są niewidoczne. Ze śledzeniem diagram wodospadowy jest widoczny w Jaegerze lub Tempo: każdy span usługi, jego czas trwania i relacja do całego żądania są od razu widoczne.

Service mesh generuje spany śledzenia automatycznie dla każdego wywołania, które proxuje, bez wymagania instrumentacji w kodzie aplikacji. Spany na poziomie aplikacji (zapytania bazodanowe, wywołania zewnętrznych API wewnątrz usługi) wymagają jawnej instrumentacji z użyciem OpenTelemetry SDK, ale międzyserwisowy szkielet zapewnia mesh bez dodatkowego wysiłku. W środowiskach niejawnych backend śledzenia (Jaeger, Tempo lub Zipkin) musi działać wewnątrz akredytowanej granicy — dane śledzenia zawierają nazwy usług, ścieżki punktów końcowych i informacje o czasie, które mogą być wrażliwe dla niejawnego systemu C2.

Wzorce operatorów Kubernetes dla stanowych obciążeń obronnych

Kubernetes dobrze obsługuje obciążenia bezstanowe od razu po instalacji — jeśli pod ulegnie awarii, kontroler ReplicaSet tworzy zamiennik. Obciążenia stanowe wymagają bardziej zaawansowanego zarządzania: kolejność uruchamiania i zatrzymywania replik ma znaczenie, dane muszą być migrowane między woluminami pamięci masowej podczas aktualizacji, a sekwencja aktualizacji musi zachowywać gwarancje spójności danych. Wzorzec operatora koduje tę wiedzę operacyjną jako kontroler działający w klastrze.

Definicje zasobów niestandardowych dla stanu C2. Operator jest zbudowany wokół Custom Resource Definition (CRD), która wyraża pożądany stan zarządzanego komponentu w terminach znaczących dla dziedziny aplikacji. Dla magazynu śladów C2 CRD może określać liczbę replik, klasę pamięci masowej, politykę retencji, współczynnik replikacji oraz minimalną liczbę replik zsynchronizowanych wymaganych, zanim operator zezwoli na aktualizację. Operatory udostępniają zespołom infrastrukturalnym interfejs deklaratywny: deklarują, czego chcą, a operator ustala, jak to osiągnąć. Sposób jest zakodowany raz w operatorze, a nie wyliczany od nowa dla każdego wdrożenia.

Pętla uzgadniania operatora do samonaprawiania. Pętla uzgadniania jest sercem operatora: odczytuje bieżący stan zarządzanego zasobu, porównuje go z pożądanym stanem w CRD i podejmuje minimalny zestaw działań wymaganych do doprowadzenia do zbieżności. Jeśli replika magazynu śladów znajduje się w stanie CrashLoopBackOff, operator wykrywa rozbieżność i inicjuje odzyskiwanie — potencjalnie uruchamiając wymianę repliki, przełączenie awaryjne na replikę dodatkową lub alert wymagający interwencji człowieka, w zależności od tego, którą ścieżkę odzyskiwania zaprojektowano w operatorze. Operator działa stale, więc odzyskiwanie rozpoczyna się w ciągu sekund od wykrycia awarii, zamiast wymagać zauważenia i reakcji człowieka.

Aktualizacja krocząca bez luki w misji. Aktualizacja stanowego komponentu C2 w działającym systemie bez luki w misji wymaga określonej sekwencji: przed rozpoczęciem sprawdzić, czy cel aktualizacji jest sprawny; opróżniać jedną replikę na raz; poczekać, aż zamiennik osiągnie znany stan sprawny, zanim opróżni się następną; i przerwać, jeśli kontrole zdrowia zawiodą w dowolnym momencie. Operator Kubernetes koduje tę sekwencję jako maszynę stanów w pętli uzgadniania. Operator wymusza minimalną liczbę sprawnych replik na każdym kroku — nie przejdzie do następnego kroku aktualizacji, jeśli system miałby spaść poniżej skonfigurowanego minimum. To kluczowa przewaga nad aktualizacjami ręcznymi: ograniczenie jest wymuszane przez kod działający z prędkością klastra, a nie przez człowieka realizującego listę kontrolną pod presją operacyjną.

Potok CI/CD dla obronnych środowisk air-gapped, który buduje i podpisuje obrazy operatorów, jest równie ważny jak sam operator — operator wdrożony z niepodpisanego, nieskanowanego obrazu jest ryzykiem łańcucha dostaw w środowisku niejawnym.

Architektura sterowana zdarzeniami dla fuzji danych z sensorów

Fuzja danych z sensorów — integrowanie raportów z wielu typów sensorów w spójny obraz środowiska operacyjnego — jest jednym z najbardziej wymagających obciążeń w platformie C2. Z natury jest sterowana zdarzeniami: raporty z sensorów napływają asynchronicznie, ze zmienną szybkością, z wielu źródeł jednocześnie. Synchroniczna architektura żądanie–odpowiedź jest strukturalnie niedopasowana do tego obciążenia. Właściwym dopasowaniem jest architektura sterowana zdarzeniami z trwałym dziennikiem jako kręgosłupem.

Strumienie zdarzeń oparte na Kafce dla danych z sensorów. Apache Kafka (lub Apache Pulsar ze względu na wielodzienność i pamięć masową warstwową) dostarcza trwały, partycjonowany dziennik, który stanowi podstawę potoku fuzji danych z sensorów. Każdy typ sensora publikuje do własnego tematu — raporty radarowe do jednego tematu, rozpoznanie elektroniczne do drugiego, wskazania obrazowe do trzeciego. Usługa fuzji śladów subskrybuje wszystkie istotne tematy i przetwarza raporty w miarę ich napływania. Mechanizm grup konsumentów Kafki pozwala skalować usługę fuzji poziomo: każda replika przejmuje partycję, więc przepustowość rośnie wraz z liczbą replik. Trwały dziennik Kafki oznacza, że jeśli usługa fuzji jest tymczasowo niedostępna — podczas aktualizacji lub awarii węzła — raporty gromadzą się w dzienniku i są przetwarzane po kolei po przywróceniu usługi, bez strat.

Wzorzec CQRS do zarządzania stanem śladów. Wzorzec Command Query Responsibility Segregation oddziela ścieżkę zapisu (polecenia modyfikujące stan) od ścieżki odczytu (zapytania zwracające stan). W usłudze zarządzania śladami ścieżka zapisu przetwarza napływające raporty z sensorów i polecenia operatorów, aktualizując autorytatywny magazyn śladów i dołączając zdarzenia do dziennika zdarzeń. Ścieżka odczytu obsługuje wspólny obraz operacyjny i interfejsy analityków z projekcji zoptymalizowanej pod odczyt — materializowanego widoku stanu śladów zoptymalizowanego pod wzorce dostępu odbiorców COP, które różnią się od wzorców zapisu fuzji danych z sensorów.

CQRS umożliwia niezależne skalowanie ścieżki odczytu wobec ścieżki zapisu. Podczas zdarzenia nagłego wzrostu, gdy wolumen raportów z sensorów jest wysoki, ścieżka zapisu skaluje się, aby obsłużyć przyjmowanie danych, podczas gdy ścieżka odczytu utrzymuje stabilne opóźnienie COP dla operatorów. Ścieżka odczytu może również udostępniać różne projekcje różnym odbiorcom bez dodawania złożoności do ścieżki zapisu — odbiorca COP otrzymuje widok od najnowszych, filtrowany; narzędzie analityczne otrzymuje widok z oknem czasowym i pełną historią.

Event sourcing do ścieżki audytu. Event sourcing rozszerza wzorzec sterowany zdarzeniami na trwałość: zamiast przechowywać bieżący stan rekordu śladu i nadpisywać go przy każdej aktualizacji, system przechowuje sekwencję zdarzeń, która doprowadziła do bieżącego stanu. Autorytatywny rekord śladu jest wyliczany przez odtworzenie dziennika zdarzeń. Podejście to daje kilka właściwości cennych w kontekście akredytacji obronnej: kompletna historia każdego przejścia stanu jest zachowana i niezmienna; stan systemu w dowolnym momencie przeszłości można odtworzyć, odtwarzając zdarzenia do tego punktu; a ścieżka audytu wymagana przez standardy akredytacji jest bezpośrednim wynikiem architektury, a nie osobno utrzymywanym dziennikiem.

SRE dla usług obronnych krytycznych dla misji

Praktyki Site Reliability Engineering — SLO, budżety błędów, ustrukturyzowane zarządzanie incydentami — mają zastosowanie do obronnych platform C2, ale ich wdrożenie musi być dostosowane do niejawnego środowiska operacyjnego, ograniczeń tempa operacyjnego i modelu konsekwencji zaangażowanych aplikacji.

Definicja SLO i SLI dla usług C2. Komercyjne SLO są zazwyczaj formułowane jako metryki doświadczenia użytkownika. SLO dla C2 muszą być formułowane jako metryki efektu operacyjnego, definiowane we współpracy z operatorami i planistami misji, którzy rozumieją, jakie zachowania systemu faktycznie wpływają na wyniki misji. Reprezentatywne SLO dla platformy C2:

• Opóźnienie aktualizacji śladów: 95. percentyl wieku śladów na COP nie może przekraczać 15 sekund. Mierzone jako różnica między znacznikiem czasu raportu z sensora a chwilą, gdy aktualizacja śladu jest widoczna na COP.
• Współczynnik dostarczania wiadomości: Wiadomości z poleceniami muszą być dostarczane ze stratami poniżej 1% w dowolnym oknie 30-minutowym. Mierzone jako stosunek potwierdzonych dostarczeń do wysłanych wiadomości na granicy usługi przekaźnikowej.
• Dostępność interfejsu wsparcia ogniowego: Interfejs koordynacji wsparcia ogniowego musi być dostępny przez 99,9% okien ważonych czasem w zadeklarowanych okresach operacyjnych. Mierzone syntetycznymi sondami, a nie pasywnym współczynnikiem sukcesu żądań.
• Opóźnienie przyjmowania danych z sensorów: Raporty z sensorów muszą być przyjęte i zatwierdzone w dzienniku zdarzeń w ciągu 5 sekund od odbioru dla 99. percentyla. Mierzone od znacznika czasu odbioru sieciowego w bramie przyjmowania do znacznika czasu zatwierdzenia offsetu Kafki.

Pomiar SLI powinien wszędzie tam, gdzie to możliwe, wykorzystywać telemetrię service mesh — metryki warstwy mesh są niezależne od kodu aplikacji i nie mogą zostać zafałszowane przez błędy na poziomie aplikacji, które zaniżają liczbę błędów. Tam, gdzie metryki mesha są niewystarczające (na przykład pomiar nieaktualności wymaga znaczników czasu na poziomie aplikacji, niedostępnych na warstwie proxy), należy zainstrumentować aplikację z użyciem OpenTelemetry i wyeksportować dane do kompatybilnego z Prometheus backendu wewnątrz enklawy.

Polityka budżetu błędów. Budżet błędów jest dopełnieniem SLO: jeśli SLO aktualności śladów wynosi 99,5% zgodności w ciągu 30 dni, budżet błędów wynosi 0,5% — około 2 godzin i 10 minut okien niezgodnych miesięcznie. Gdy budżet jest w dobrej kondycji, zespoły inżynieryjne mogą wdrażać zmiany i akceptować wyważone ryzyko. Gdy budżet zbliża się do wyczerpania, polityka przesuwa się w stronę stabilności: żadnych wdrożeń nieawaryjnych, zasoby inżynieryjne przekierowane na poprawę niezawodności oraz obowiązkowy przegląd po wyczerpaniu budżetu. Programy obronne muszą nałożyć okna operacyjne na politykę budżetu błędów: niektóre okresy są deklarowane jako operacyjne, a zużycie budżetu w tych okresach niesie podwyższony koszt niezależnie od skumulowanego salda.

Runbooki dyżurne. Runbooki dla niejawnych systemów C2 muszą spełniać wyższe wymagania niż runbooki komercyjne. Muszą być wykonalne przez personel dyżurny, który może nie być oryginalnymi architektami usługi, o każdej porze, pod presją operacyjną, z użyciem wyłącznie narzędzi dostępnych wewnątrz akredytowanej granicy. Każdy runbook powinien zawierać: mapowanie objaw–diagnoza (które alerty odpowiadają którym trybom awarii), dokładne polecenia do wykonania (z oczekiwanym wynikiem dla przypadku zdrowego i wynikiem błędu dla typowych przypadków awarii), kontakty eskalacyjne z zaznaczonymi poziomami dopuszczenia oraz oczekiwane czasy przywrócenia sprawności dla każdej procedury.

Łagodna degradacja w warunkach kontestowanych

Środowiska kontestowane narzucają warunki awarii, które nie występują w garnizonie: celowe zagłuszanie łańcuchów łączności, odmowa GPS wpływająca na synchronizację czasu, fizyczne uszkodzenia infrastruktury sieciowej oraz obciążenie wywołane przez przeciwnika za pomocą sfałszowanych raportów z sensorów. Platforma C2 w architekturze cloud-native musi się łagodnie degradować we wszystkich tych warunkach — utrzymując funkcje o najwyższym priorytecie tak długo, jak to możliwe, ze zdefiniowanym i przetestowanym zachowaniem na każdym poziomie degradacji.

Wyłączniki obwodu dla zdegradowanej łączności. Wyłączniki obwodu zapobiegają rozprzestrzenianiu się awarii wolnej lub niesprawnej zależności przez łańcuch wywołań. W meshu Istio wyłączniki obwodu konfiguruje się przez zasób OutlierDetection w DestinationRule: określa się próg kolejnych błędów, który otwiera obwód, interwał wykluczania oraz bazowy czas wykluczenia. Gdy współczynnik błędów usługi przekroczy próg, mesh przestaje kierować do niej wywołania i natychmiast zwraca błędy, zamiast kolejkować wywołania, które i tak by się przeterminowały. Chroni to budżet opóźnień wywołującego — usługa wsparcia ogniowego nie czeka 30 sekund na przeterminowanie zapytania o ślad, lecz otrzymuje natychmiastowy błąd i przechodzi do stanu z pamięci podręcznej.

Wzorce awaryjne odczytu z pamięci podręcznej. Gdy usługa nadrzędna jest niedostępna, usługi obsługujące obciążenia o przewadze odczytu mogą przejść na lokalną lub rozproszoną pamięć podręczną zawierającą ostatni znany poprawny stan. Awaryjny odczyt z pamięci podręcznej jest dopuszczalny tylko wtedy, gdy nieaktualność danych jest ograniczona i ujawniana operatorom — COP, który po cichu serwuje ślad sprzed 10 minut bez wskazania jego wieku, jest gorszy niż COP, który jawnie oznacza ślady jako nieaktualne. Należy zaimplementować mechanizm awaryjny z jawnym nagłówkiem odpowiedzi lub polem ładunku wskazującym wiek i źródło danych (bieżące versus z pamięci podręcznej), aby interfejsy operatorskie mogły pokazywać stan degradacji, a nie go maskować.

Stopniowa degradacja usług z obsługą pracy offline. Pełna izolacja — brak łączności z jakąkolwiek usługą nadrzędną — wymaga wstępnie rozmieszczonych danych i logiki aplikacji działającej offline. Należy zaprojektować macierz degradacji dla platformy, określającą, które funkcje działają w każdym stanie łączności: w pełni połączonym (wszystkie usługi osiągalne), częściowo połączonym (niektóre usługi osiągalne, inne nie) oraz w pełni odizolowanym (brak łączności zewnętrznej). Każda funkcja w macierzy musi mieć przetestowaną implementację swojego zdegradowanego zachowania — nie adnotację w dokumencie projektowym, lecz przetestowaną ścieżkę kodu, która została sprawdzona we wstrzykiwaniu błędów przed wdrożeniem operacyjnym.

Przypadek częściowo połączony jest najtrudniejszy do zaprojektowania, ponieważ zbiór dostępnych usług jest nieprzewidywalny — magazyn śladów może być osiągalny, ale usługa integracji rozpoznania nie, albo odwrotnie. Usługi muszą być zaprojektowane tak, aby działać z dowolnym podzbiorem dostępnych zależności, płynnie degradując się w miarę awarii poszczególnych zależności, zamiast wymagać łączności typu wszystko albo nic. Wymaga to jawnej klasyfikacji zależności na poziomie usługi: obowiązkowe (usługa nie może bez nich funkcjonować), preferowane (usługa działa z nimi lepiej, ale może się łagodnie zdegradować bez nich) oraz opcjonalne (usługa całkowicie ignoruje ich niedostępność).

Fundamenty bezpieczeństwa kontenerów, na których opiera się cała ta architektura — podpisywanie obrazów, skanowanie podatności i wymuszanie polityk w czasie działania — opisano w artykule Bezpieczeństwo obrazów kontenerów w obronności. Architektura cloud-native jest bezpieczna tylko tak, jak bezpieczne są obrazy, które w niej działają; dekompozycja na mikrousługi mnoży kontenerową powierzchnię ataku, jeśli obrazy nie są utwardzane i stale skanowane.

Architektura cloud-native dla platform C2 i ISR w zastosowaniach obronnych to znacząca inwestycja inżynierska: analiza ograniczonych kontekstów, wdrożenie i eksploatacja siatki usług (service mesh), rozwój operatorów, projektowanie potoków sterowanych zdarzeniami, definiowanie SLO z interesariuszami operacyjnymi oraz testowanie łagodnej degradacji wymagają świadomego wysiłku inżynierskiego, którego platforma monolityczna nie wymaga. Zwrotem z tej inwestycji jest platforma, w której awaria jest lokalna, aktualizacje są niezależne, skala jest elastyczna, a degradacja jest zaprojektowana, a nie przypadkowa — cechy, które stają się bezwzględnym wymogiem dla oprogramowania obronnego działającego w warunkach przeciwdziałania.