Kopia zapasowa i odtwarzanie sklasyfikowanych obciążeń chmurowych: RTO, RPO i ciągłość kryptograficzna

Sklasyfikowane wojskowe obciążenia chmurowe nie są abstrakcyjnymi zasobami. Prowadzą potoki celowania, tkanki komunikacyjne i warstwy fuzji wywiadowczej, które decydują o tym, czy jednostka zachowuje świadomość sytuacyjną pod ostrzałem. Gdy te obciążenia zawodzą — a sprzęt ulega awarii, obiekty tracą zasilanie, a przeciwnicy sondują każdą dostępną powierzchnię — organizacja potrzebuje przetestowanego, wykonywalnego planu odtwarzania, który przywraca je w czasie, jaki misja jest w stanie wytoleować. Kopia zapasowa i odtwarzanie po awarii dla systemów sklasyfikowanych to nie jest pomniejszona wersja komercyjnego DR; to odrębna dziedzina inżynierska ukształtowana przez ograniczenia akredytacyjne, zależności od kluczy kryptograficznych i operacyjną rzeczywistość, że systemy najbardziej potrzebujące szybkiego odtwarzania są najtrudniejsze do przywrócenia pod presją.

Artykuł ten analizuje pełny stos odtwarzania dla sklasyfikowanych obciążeń chmurowych: jak wyprowadzać cele RTO i RPO z poziomów krytyczności misji, jak projektować architekturę kopii zapasowych spełniającą wymagania granic klasyfikacji, jak zarządzać kluczami szyfrowania, aby przeżyły awarię głównej lokalizacji, jak tworzyć kopie zapasowe baz danych i klastrów Kubernetes, jak testować odtwarzanie w środowiskach ograniczających fizyczny dostęp oraz jak przywrócić ciągłość kryptograficzną po odbudowaniu systemów. Ujęcie jest techniczne i operacyjne — decyzje te należą do inżynierów platform, oficerów ds. bezpieczeństwa systemów informacyjnych (ISSO) i architektów programów pracujących wspólnie.

Wymagania RTO i RPO dla wojskowych systemów C2 i ISR

Recovery Time Objective (RTO) i Recovery Point Objective (RPO) nie są umowami o poziomie usług IT zaimportowanymi z szablonu komercyjnego. Dla sklasyfikowanych systemów obronnych są wyprowadzane z tempa operacyjnego — rytmu, w jakim dowódcy potrzebują aktualnych danych do podejmowania decyzji — oraz z krytyczności misji, która określa, jak długo zdolność może być nieobecna, zanim misja pogorszy się do nieakceptowalnego poziomu.

Praktyczna struktura krytyczności przypisuje systemy do trzech poziomów:

• Poziom 1 — Krytyczny dla misji C2 i ISR w czasie rzeczywistym. Platformy dowodzenia i kierowania, fuzja sensorów w czasie rzeczywistym i aktywne systemy celowania. RTO: poniżej czterech godzin. RPO: poniżej 15 minut. System C2 niedostępny przez ponad cztery godziny podczas aktywnej operacji osłabia zdolność dowódcy do wydawania, śledzenia i rewizji rozkazów. RPO większy niż 15 minut oznacza potencjalną utratę niedawnych danych celowania lub sytuacyjnych, których nie można odtworzyć.
• Poziom 2 — Analiza ISR i systemy wsparcia misji. Stacje robocze do analizy wywiadowczej, rejestracja komunikacji i zarządzanie logistyką. RTO: 8–24 godziny. RPO: jedna do czterech godzin. Systemy te wspierają planowanie misji i ocenę, a nie wykonanie w czasie rzeczywistym; ich nieobecność obniża efektywność, lecz nie wstrzymuje natychmiast operacji.
• Poziom 3 — Systemy administracyjne i archiwalne. Systemy kadrowe, przechowywanie archiwalne i aplikacje administracyjne. RTO: 48–72 godziny. RPO: 24 godziny. Przedłużona niedostępność jest operacyjnie tolerowana; utrata danych do jednego dnia roboczego jest akceptowalna.

Kluczowa implikacja projektowa przypisania do poziomu polega na tym, że cele RTO na poziomie 1 — odtwarzanie w czasie poniżej czterech godzin — są osiągalne wyłącznie przy architekturach gorącego lub ciepłego standby. Zimna kopia zapasowa (taśma lub dysk bez działającego standby) wprowadza etapy odtwarzania, które łącznie nie mogą zakończyć się w ciągu czterech godzin: pobranie nośnika, prowizjonowanie infrastruktury, przywrócenie systemu operacyjnego, przywrócenie warstwy aplikacji, weryfikacja kontroli bezpieczeństwa i akceptacja ISSO. Program, który uważa, że posiada czterogodzinne RTO wyłącznie dzięki zimnej kopii zapasowej, nie zamodelował rzeczywistej procedury odtwarzania.

Budżet RTO musi być podzielony na fazy i zsumowany przed przyjęciem jako cel:

Faza odtwarzania	Gorący standby	Ciepły standby	Zimna kopia zapasowa
Decyzja o przełączeniu awaryjnym i autoryzacja	5–15 min	15–30 min	30–60 min
Pobranie nośnika / odtwarzanie kluczy	N/D (żywa replika)	15–30 min	60–180 min
Przywrócenie infrastruktury i systemu operacyjnego	0–15 min	30–60 min	60–120 min
Przywrócenie aplikacji i danych	0–5 min	20–60 min	60–240 min
Weryfikacja kontroli bezpieczeństwa + akceptacja ISSO	30–60 min	60–90 min	60–120 min

Krok weryfikacji kontroli bezpieczeństwa — potwierdzenie, że oznaczenia klasyfikacyjne, rejestrowanie audytu, kontrole dostępu i powiązania kryptograficzne działają poprawnie na przywróconym systemie — jest często pomijany w komercyjnych modelach RTO. Dla systemów sklasyfikowanych jest obowiązkowy przed powrotem do operacji. Dokładny cel RTO uwzględnia go.

Architektura kopii zapasowych dla sklasyfikowanych obciążeń

Architektura kopii zapasowych dla sklasyfikowanych obciążeń wychodzi od dwóch nienaruszalnych ograniczeń: izolacji granic klasyfikacji i ciągłości akredytacji. Każda strefa klasyfikacyjna wymaga fizycznie oddzielnej infrastruktury kopii zapasowych — oddzielnych węzłów pamięci masowej, oddzielnych nośników, oddzielnych instancji oprogramowania do tworzenia kopii zapasowych, jeśli oprogramowanie korzysta ze wspólnej płaszczyzny zarządzania. Skonsolidowana infrastruktura kopii zapasowych obejmująca wiele stref klasyfikacyjnych stanowi naruszenie zgodności niezależnie od tego, czy dane kopii zapasowej są szyfrowane, ponieważ wspólna płaszczyzna zarządzania tworzy potencjalny kanał ukryty i poszerzoną powierzchnię ataku.

Ciągłość akredytacji oznacza, że środowisko odtwarzania — infrastruktura, do której przywracane są sklasyfikowane dane podczas katastrofy — musi posiadać aktualne Zezwolenie na Eksploatację przed katastrofą, a nie dopiero po niej. Najczęstszą przyczyną niepowodzenia sklasyfikowanego DR w analizach poawaryjnych nie jest brak kopii zapasowej; jest to kopia zapasowa, która istnieje, ale nie może być legalnie przywrócona w wymaganym czasie, ponieważ ATO środowiska odtwarzania wygasło.

Niezmienialny magazyn kopii zapasowych jest obowiązkową kontrolą dla sklasyfikowanych obciążeń na poziomie 1 i 2. Niezmienialność — wymuszana na poziomie sprzętu lub oprogramowania układowego poprzez nośniki jednorazowego zapisu lub blokadę obiektów w trybie zgodności — zapewnia, że aktor ransomware lub złośliwy wtajemniczony, który naruszy infrastrukturę kopii zapasowych, nie może usunąć ani zmienić zestawów kopii zapasowych. Programowa implementacja WORM, którą może zastąpić konto z wystarczającymi uprawnieniami, nie spełnia tego wymagania. Dla sklasyfikowanej pamięci masowej on-premises sprzętowa taśma WORM (LTO z kasetami WORM) lub urządzenie dyskowe z niezmiennalnością na poziomie oprogramowania układowego jest właściwym wyborem. Dla suwerennych wdrożeń sklasyfikowanej chmury obiektowy magazyn danych z blokadą obiektów kompatybilną z S3 w trybie zgodności zapewnia równoważną ochronę.

Trójwarstwowa architektura spełnia pełen zakres scenariuszy odtwarzania:

• Warstwa 1 — Lokalna niezmienialana kopia zapasowa. Ciągłe lub godzinowe przyrostowe kopie zapasowe na lokalny magazyn WORM w akredytowanym obiekcie. Chroni przed błędami operacyjnymi: przypadkowym usunięciem, uszkodzeniem bazy danych, ransomware. Najszybsza ścieżka odtwarzania dla awarii niekatastroficznych.
• Warstwa 2 — Replikacja synchroniczna do ciepłego standby. Dla systemów poziomu 1 dzienniki transakcji baz danych i stan krytyczny są replikowane do węzła wtórnego w tym samym lub zlokalizowanym w pobliżu akredytowanym obiekcie. Ta warstwa obsługuje RTO poniżej czterech godzin. Replikacja jest w granicach akredytacji — węzeł wtórny jest częścią tego samego akredytowanego środowiska.
• Warstwa 3 — Okresowa kopia poza siedzibą do obiektu DR. Tygodniowe lub miesięczne zaszyfrowane kopie zapasowe przenoszone do fizycznie oddzielnego akredytowanego obiektu. Ta warstwa chroni przed katastrofalną utratą głównej lokalizacji. W przypadku taktycznej chmury brzegowej w operacjach odłączonych transfer ten jest fizyczny — zaszyfrowane nośniki transportowane przez upoważnionego kuriera — a czas tranzytu kuriera musi być uwzględniony w obliczeniu RTO dla scenariusza DR, który obejmuje.

Lokalizacje DR z izolacją powietrzną (air-gapped) wprowadzają specyficzne wyzwanie projektowe: kopia poza siedzibą zawsze pozostaje w tyle za główną lokalizacją o interwał między fizycznymi transferami. Program, który transferuje nośniki kopii zapasowych do swojej lokalizacji DR co tydzień, ma potencjalne okno utraty danych do siedmiu dni dla scenariusza, w którym główna lokalizacja zostaje zniszczona. Ta luka musi być udokumentowana, zaakceptowana przez organ misji i odzwierciedlona w planie awaryjnym systemu — a nie ukryta w architekturze.

Szyfrowanie danych kopii zapasowej: zarządzanie kluczami przez cały proces odtwarzania

Każdy zestaw kopii zapasowej dla sklasyfikowanego obciążenia musi być szyfrowany w spoczynku przy użyciu AES-256 (lub krajowego odpowiednika zatwierdzonego dla poziomu klasyfikacji systemu). Trudniejszym problemem nie jest samo szyfrowanie — lecz zapewnienie, że klucze deszyfrowania przeżyją awarię głównej lokalizacji i będą dostępne w lokalizacji DR w ramach budżetu czasu odtwarzania.

Zalecana hierarchia kluczy dla szyfrowania sklasyfikowanych kopii zapasowych ma trzy poziomy:

• Klucz szyfrowania kluczy (KEK). Klucz główny przechowywany w Sprzętowym Module Bezpieczeństwa (HSM) w akredytowanym obiekcie. KEK nigdy nie opuszcza HSM w postaci jawnej. Dostęp do KEK wymaga autoryzacji wielu stron — co najmniej dwóch upoważnionych osób z oddzielnymi poświadczeniami uwierzytelniania HSM (schemat kworum m-z-n, zazwyczaj 2-z-3 lub 3-z-5).
• Klucz szyfrowania danych (DEK). Unikalny klucz AES-256 generowany dla każdego zadania kopii zapasowej. DEK szyfruje dane kopii zapasowej. Po zakończeniu zadania kopii zapasowej DEK jest szyfrowany (owijany) przez KEK wewnątrz HSM, a zawinięty DEK jest przechowywany razem z metadanymi kopii zapasowej. Jawny DEK nigdy nie jest zapisywany na dysk.
• Depozyt kluczy w lokalizacji DR. KEK jest synchronizowany z pomocniczym HSM w lokalizacji DR, poprzez ciągłą replikację klastra HSM lub poprzez okresową procedurę tworzenia kopii zapasowej kluczy. Pomocniczy HSM przechowuje KEK w środowisku o równoważnym bezpieczeństwie i udostępnia go upoważnionym operatorom odtwarzania podczas ogłoszonej katastrofy, umożliwiając lokalne odwijanie DEK i deszyfrowanie kopii zapasowych.

Częstotliwość synchronizacji depozytu określa maksymalne opóźnienie KEK w lokalizacji DR. W przypadku rotujących KEK (roczna lub częstsza rotacja), aktualizacja depozytu musi nastąpić w ciągu jednego okresu rotacji. Procedura depozytu — w tym etapy uwierzytelniania i autoryzacji wymagane, aby pomocniczy HSM zaakceptował zaktualizowany klucz — musi być udokumentowana, a dokumentacja musi być przechowywana w lokalizacji DR (nie tylko w głównej lokalizacji).

W celu głębszego kontekstu dotyczącego doboru HSM i architektur post-kwantowego zarządzania kluczami HSM zapewniających długoterminową odporność na ataki kwantowe na przechowywane szyfrogramy, zapoznaj się z powiązanym opracowaniem. Hierarchia kluczy opisana powyżej jest kompatybilna z post-kwantowymi algorytmami KEK (CRYSTALS-Kyber lub ML-KEM na poziomach CNSA 2.0) bez zmiany relacji strukturalnej między warstwami.

Podręcznik DR, który nigdy nie był ćwiczony end-to-end — łącznie z uwierzytelnianiem HSM w lokalizacji DR i odwijaniem DEK — nie zweryfikował swojego najbardziej podatnego na awarie kroku. Odtwarzanie kluczy musi być ćwiczone jako nazwany krok w każdej pełnej próbie odtwarzania, a nie pozostawione jako zakładana zdolność.

Strategie tworzenia kopii zapasowych baz danych dla operacyjnych systemów C2

Operacyjne systemy C2 zazwyczaj utrwalają stan w relacyjnych bazach danych: PostgreSQL jest dominującym wyborem open-source dla akredytowanych wdrożeń chmury obronnej. Standardowa komercyjna kopia zapasowa „codzienny pełny zrzut plus nocne różnicowe" nie spełnia wymagań RPO systemów poziomu 1 — RPO wynoszące 15 minut wymaga ciągłego mechanizmu kopii zapasowej, który przechwytuje każdą zatwierdzoną transakcję.

Dziennik zapisu z wyprzedzeniem (WAL) PostgreSQL zapewnia ten mechanizm. Każda zatwierdzona zmiana bazy danych jest zapisywana do segmentu WAL przed jej zastosowaniem do plików danych. Poprzez ciągłe archiwizowanie segmentów WAL do akredytowanego magazynu kopii zapasowych natychmiast po ich zapisaniu, gromadzisz kompletny dziennik zmian, który można odtworzyć do przodu od dowolnej pełnej kopii zapasowej do dowolnego punktu w czasie — aż do ostatniego zarchiwizowanego segmentu przed awarią. Jest to odtwarzanie do punktu w czasie (PITR).

Konfiguracja w postgresql.conf dla ciągłego archiwizowania WAL z szyfrowaniem:

wal_level = replica
archive_mode = on
archive_command = '/opt/backup/encrypt-wal.sh %p %f'
archive_timeout = 60        # wymuszenie przełączenia segmentu co maksymalnie 60 sekund
restore_command = '/opt/backup/decrypt-wal.sh %f %p'
recovery_target_time = '2026-06-25 14:30:00 UTC'  # ustawione w recovery.conf

Skrypt encrypt-wal.sh powinien szyfrować segment WAL przy użyciu DEK opartego na HSM przed zapisem do lokalizacji archiwum. Wartość archive_timeout wynoszącą 60 sekund zapewnia, że nawet w okresach niskiego zapisu segmenty WAL są archiwizowane co najmniej raz na minutę, ograniczając RPO do około jednej minuty w normalnych warunkach.

Dla systemów C2 złożonych z wielu mikroserwisów współdzielących rozproszony stan — powszechny wzorzec, gdzie dane celowania przepływają między serwisem fuzji sensorów, serwisem wsparcia decyzji i bramą komunikacyjną — spójność kopii zapasowych wymaga, aby migawki wszystkich baz danych serwisów były pobierane w tym samym logicznym punkcie w czasie. Zestaw kopii zapasowych, w którym aktualizacja celowania istnieje w bazie danych systemu kontroli ognia, ale jeszcze nie w bazie danych fuzji ISR, daje logicznie niespójny stan odtwarzania. Spójne migawki między mikroserwisami są osiągane przez:

• Rozproszony koordynator migawek, który wysyła sygnał uśpienia do wszystkich serwisów, czeka na wyczerpanie transakcji w locie, wyzwala jednoczesne migawki na wszystkich bazach danych, a następnie zwalnia uśpienie.
• Haki przed kopią zapasową w orkiestratorze kontenerów, które wywołują API uśpienia każdego serwisu przed wyzwoleniem migawki woluminu.
• Numer sekwencyjny lub globalny identyfikator transakcji wstawiany do każdego zestawu migawek, umożliwiający procedurom odtwarzania weryfikację, że wszystkie komponenty zestawu odtwarzania współdzielą ten sam logiczny znacznik czasu przed zatwierdzeniem odtwarzania.

Kopia zapasowa obciążeń Kubernetes

Velero jest standardowym narzędziem open-source do tworzenia kopii zapasowych obciążeń Kubernetes zarówno w kontekście komercyjnym, jak i obronnym. W sklasyfikowanym klastrze z izolacją powietrzną (air-gapped) wdrożenie Velero wymaga specyficznych adaptacji: wszystkie obrazy kontenerów Velero, obrazy wtyczek (w szczególności wtyczka CSI i wszelkie wtyczki dostawcy obiektowego magazynu danych) oraz plik binarny Velero CLI muszą być wstępnie umieszczone w lokalnym rejestrze obrazów klastra przed katastrofą, ponieważ klaster nie może pobierać z zewnętrznych rejestrów podczas odtwarzania.

Velero tworzy kopie zapasowe obiektów API Kubernetes — Deployments, DaemonSets, Services, ConfigMaps, Secrets, PersistentVolumeClaims, NetworkPolicies, obiektów RBAC i zasobów niestandardowych — oraz wyzwala migawki woluminów CSI dla danych trwałych. Harmonogram kopii zapasowych Velero dla sklasyfikowanego klastra:

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: classified-cluster-hourly
  namespace: velero
spec:
  schedule: "0 * * * *"          # co godzinę
  template:
    storageLocation: classified-backup-location
    volumeSnapshotLocations:
      - classified-csi-snapshots
    includedNamespaces:
      - c2-platform
      - isr-fusion
      - comms-gateway
    hooks:
      resources:
        - name: db-quiesce
          includedNamespaces:
            - c2-platform
          labelSelector:
            matchLabels:
              app: postgres
          pre:
            - exec:
                command:
                  - /bin/sh
                  - -c
                  - psql -c "SELECT pg_start_backup('velero', true);"
                timeout: 60s
          post:
            - exec:
                command:
                  - /bin/sh
                  - -c
                  - psql -c "SELECT pg_stop_backup();"
                timeout: 60s
    ttl: 720h                    # retencja 30 dni

Czego Velero nie tworzy kopii zapasowej: stanu etcd (Velero odczytuje z serwera API, nie bezpośrednio z etcd), konfiguracji systemu operacyjnego na poziomie węzła, plików binarnych płaszczyzny sterowania i danych zapisanych w lokalnej pamięci węzła poza woluminami trwałymi. etcd musi być archiwizowany osobno. Dla trzywęzłowej płaszczyzny sterowania uruchom poniższe polecenia na każdym węźle płaszczyzny sterowania i zaszyfruj wynik:

ETCDCTL_API=3 etcdctl snapshot save \
  /tmp/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Zaszyfruj migawkę przed archiwizacją
gpg --symmetric --cipher-algo AES256 \
  --batch --passphrase-file /etc/backup/etcd-key.txt \
  /tmp/etcd-snapshot-*.db

# Zweryfikuj integralność migawki
etcdctl snapshot status /tmp/etcd-snapshot-*.db

Migawki etcd powinny być planowane godzinowo na wszystkich węzłach płaszczyzny sterowania, a zaszyfrowane migawki powinny być zapisywane do tego samego akredytowanego magazynu kopii zapasowych, co kopie zapasowe Velero. Kompletna strategia DR dla Kubernetes wymaga zarówno Velero (dla stanu warstwy obciążeń), jak i migawek etcd (dla stanu warstwy klastra). Odtworzenie tylko jednego daje nieodwracalny klaster — obiekty API w etcd i dane trwałe w woluminach muszą być ze sobą spójne.

Strategie migawek PersistentVolumeClaim zależą od używanej klasy pamięci masowej. Dla pamięci masowej obsługiwanej przez CSI w środowiskach sklasyfikowanych sterownik pamięci masowej musi implementować interfejs migawek CSI, a migawki muszą być przechowywane w akredytowanym magazynie. Dla NFS lub starszej pamięci masowej nieobsługującej migawek CSI, tryb tworzenia kopii zapasowych systemu plików Velero (oparty na Kopia) może tworzyć kopie zapasowe danych PVC poprzez bezpośrednie kopiowanie plików z zamontowanych woluminów — wolniejszy niż migawki CSI, ale możliwy do zastosowania dla dowolnego rodzaju pamięci masowej.

Testowanie odtwarzania w środowiskach sklasyfikowanych

Testowanie odtwarzania w środowiskach sklasyfikowanych jest bardziej ograniczone niż w środowiskach komercyjnych: nie można uruchomić dowolnego publicznego środowiska chmurowego jako celu odtwarzania, nie można testować z danymi produkcyjnymi poza granicą akredytacji i nie można przeprowadzać prób odtwarzania w godzinach operacyjnych bez wcześniejszej autoryzacji i przetestowanego planu wycofania.

Harmonogram ćwiczeń DR dla sklasyfikowanego programu powinien następować w trzystopniowym rytmie:

• Ćwiczenie przy stole — kwartalnie. Zespół odtwarzania werbalnie przechodzi przez podręcznik, identyfikując niejasne kroki, nieobsadzone role lub nieudokumentowane zależności. Żadne systemy nie są dotykane. Wynik: zaktualizowany podręcznik i lista luk do naprawienia.
• Ćwiczenie funkcjonalne — półrocznie. Podzbiór procedury odtwarzania jest wykonywany w żywym środowisku: na przykład odtworzenie jednej bazy danych z kopii zapasowej i weryfikacja integralności danych, lub odtworzenie kopii zapasowej Velero jednej przestrzeni nazw i potwierdzenie, że aplikacja działa. Częściowe pokrycie przy niższym koszcie i ryzyku niż pełna próba.
• Pełna próba odtwarzania — co najmniej rocznie, półrocznie dla poziomu 1. Kompletne odtwarzanie end-to-end z kopii zapasowej do kwarantannowego środowiska odtwarzania. Wszystkie fazy odtwarzania są wykonywane, łącznie z odtwarzaniem kluczy, weryfikacją kontroli bezpieczeństwa i akceptacją ISSO. Rzeczywiste RTO i RPO są mierzone i porównywane z celami.

Weryfikacja integralności danych po odtworzeniu wymaga więcej niż potwierdzenia, że baza danych uruchamia się. Dla relacyjnych baz danych weryfikacja integralności obejmuje:

# Kontrole integralności PostgreSQL po odtworzeniu
# 1. Zweryfikuj liczby wierszy względem oczekiwanych wartości z dziennika audytu przed kopią zapasową
psql -c "SELECT schemaname, tablename, n_live_tup
         FROM pg_stat_user_tables ORDER BY schemaname, tablename;"

# 2. Sprawdź naruszenia ograniczeń po odtworzeniu
psql -c "SELECT conname, conrelid::regclass
         FROM pg_constraint WHERE NOT convalidated;"

# 3. Zweryfikuj, że odtwarzanie WAL osiągnęło docelowy czas odtwarzania
psql -c "SELECT pg_last_xact_replay_timestamp();"

# 4. Uruchom kontrolę stanu zdrowia warstwy aplikacji
curl -sf https://c2-platform.internal/health/deep | jq '.checks'

Metodologia pomiaru RTO musi być precyzyjna: zegar startuje w momencie formalnego ogłoszenia katastrofy (nie gdy awaria jest po raz pierwszy wykryta — wykrycie incydentu i ogłoszenie może zająć 15–30 minut i musi być odjęte od pozostałego budżetu). Zegar zatrzymuje się, gdy ISSO formalnie akceptuje gotowość odtworzonego systemu do sklasyfikowanych operacji — nie gdy aplikacja zwraca pierwsze udane sprawdzenie stanu zdrowia. Różnica między tymi dwiema interpretacjami może wynosić 60–90 minut, co może decydować o tym, czy program spełnia swoje umowne lub regulacyjne zobowiązanie RTO.

Ciągłość kryptograficzna po odtwarzaniu

System, który został odtworzony z kopii zapasowej, nie jest kryptograficznie identyczny z systemem, który był archiwizowany. W zależności od tego, kiedy kopia zapasowa została wykonana względem ostatniej rotacji kluczy, wystawienia certyfikatu lub ustanowienia sesji, odtworzony system może działać z przestarzałym materiałem kryptograficznym, który jest wygasły, unieważniony lub niespójny z aktualnym stanem podłączonych systemów. Ciągłość kryptograficzna to zestaw procedur, które doprowadzają stan kryptograficzny odtworzonego systemu do zgodności z środowiskiem operacyjnym po odtworzeniu.

Ponowne kluczowanie po przełączeniu awaryjnym HSM. Gdy główny HSM zawodzi i pomocniczy HSM w lokalizacji DR przejmuje kontrolę, pierwszym krokiem jest weryfikacja, że inwentarz kluczy pomocniczego HSM jest aktualny. W przypadku HSM korzystających z ciągłej replikacji klastrowej, pomocniczy powinien być aktualny od ostatniego sygnału heartbeat replikacji — zazwyczaj w ciągu sekund. Dla HSM korzystających z okresowych kopii zapasowych kluczy, pomocniczy może być opóźniony o interwał kopii zapasowej. Wszelkie klucze utworzone lub poddane rotacji od ostatniej kopii zapasowej nie są obecne w pomocniczym i muszą być ponownie wyprowadzone lub ponownie wystawione, zanim systemy od nich zależne będą mogły działać. Audyt inwentarza kluczy — porównanie listy kluczy pomocniczego HSM z ostatnim dziennikiem audytu głównego — jest pierwszym działaniem kryptograficznym po przełączeniu awaryjnym HSM.

Stan certyfikatów po odtworzeniu. Certyfikaty klastra Kubernetes i certyfikaty TLS aplikacji mają daty wygaśnięcia, które upływają niezależnie od tego, czy system jest uruchomiony. Klaster odtworzony z kopii zapasowej sprzed 30 dni jest odtworzony w stanie, w którym 30 dni zostało skonsumowanych z pozostałej ważności każdego certyfikatu. Jeśli jakikolwiek certyfikat był w ciągu 30 dni od wygaśnięcia w momencie tworzenia kopii zapasowej, jest wygasły w odtworzonym klastrze. Procedura audytu certyfikatów:

# Audyt wygaśnięcia wszystkich certyfikatów płaszczyzny sterowania Kubernetes
kubeadm certs check-expiration

# Odnawianie wygasłych lub bliskich wygaśnięcia certyfikatów płaszczyzny sterowania
kubeadm certs renew all

# Dla certyfikatów aplikacji cert-manager: wymuszenie ponownego wystawienia
# przez usunięcie zasobów Certificate i pozwolenie cert-manager na ponowne wystawienie
kubectl get certificates -A -o json | \
  jq -r '.items[] | select(.status.notAfter < now | todate) |
         "\(.metadata.namespace)/\(.metadata.name)"' | \
  xargs -I{} kubectl delete certificate -n $(echo {} | cut -d/ -f1) \
                                           $(echo {} | cut -d/ -f2)

# Zweryfikuj, że cert-manager wystawia nowe certyfikaty
kubectl get certificaterequests -A --watch

Ponowne ustanowienie kluczy sesji. Klucze sesji — efemeryczne klucze symetryczne negocjowane podczas uzgadniania TLS i ustanawiania zaszyfrowanych kanałów — nigdy nie są przechowywane w HSM i nigdy nie są archiwizowane. Istnieją tylko w pamięci komunikujących się procesów. Po odtworzeniu systemu z kopii zapasowej wszystkie aktywne sesje ze migawki kopii zapasowej są nieobecne; odtworzony system nie ma stanu sesji. Podłączone systemy — inne węzły klastra, zdalne sensory, partnerzy C2 — będą próbować ponownie ustanowić sesje przy użyciu długoterminowych poświadczeń odtworzonego systemu (certyfikatów i kluczy opartych na HSM). Jeśli te poświadczenia są aktualne i ważne, ponowne ustanowienie sesji jest automatyczne i transparentne. Jeśli są przestarzałe lub wygasłe, ponowne ustanowienie sesji nie powiedzie się i każde połączenie musi być ręcznie zainicjowane ponownie po rozwiązaniu problemu z poświadczeniami.

Procedury ponownego kluczowania po odtworzeniu. Dla systemów, gdzie samo zdarzenie odtwarzania jest traktowane jako potencjalny wskaźnik naruszenia kluczy — szczególnie jeśli awaria była spowodowana incydentem bezpieczeństwa, a nie awarią sprzętu lub zasilania — ISSO może wymagać pełnego cyklu ponownego kluczowania przed powrotem systemu do sklasyfikowanych operacji. Ponowne kluczowanie obejmuje generowanie nowych KEK w odtworzonym HSM, ponowne szyfrowanie wszystkich DEK danych pod nowym KEK i dystrybucję nowych certyfikatów do wszystkich podłączonych systemów. Jest to długotrwały proces, który musi być zabudżetowany w harmonogramie odtwarzania, jeśli istnieje jakakolwiek możliwość, że będzie wymagany. Dokumenty planistyczne powinny wyraźnie uwzględniać decyzję dotyczącą ponownego kluczowania versus wznowienia na istniejących kluczach i definiować kryteria dla każdej ścieżki.

Skrzyżowanie inżynierii kopii zapasowych, zarządzania kluczami i operacji Kubernetes, którego wymaga sklasyfikowany DR chmury, nie jest obsługiwane przez żadne pojedyncze narzędzie ani framework. Jest budowane z kombinacji narzędzi do tworzenia kopii zapasowych na poziomie platformy (Velero, etcdctl, pg_basebackup), zarządzania kluczami zintegrowanego z HSM i procedur operacyjnych, które były ćwiczone w warunkach zbliżonych do rzeczywistych katastrof. Programy, które inwestują w rytm ćwiczeń — i w uczciwe Raporty po Działaniu, które po nich następują — konsekwentnie przewyższają te, które traktują DR jako ćwiczenie dokumentacyjne.