k0nsult.cloud / ai-truth / ipIII / playbook-ciaglosc
Playbook L — Ciągłość, backup, Punkt Zero i PQC
Odtworzenie działania po utracie dostępności: portal, baza dowodów, dashboardy, rejestr agentów, backup, scoring i historia decyzji. Poziom 4 (odporność i ciągłość). Priorytet P0 dla utraty dostępności systemów krytycznych — cel: powrót do zdefiniowanego, zaufanego stanu (Punkt Zero) w założonym RTO.
Backup, którego nie przetestowano odtworzeniem, to hipoteza — nie zabezpieczenie. Ciągłość udowadnia się testem, nie deklaracją.
Odporność to zdolność powrotu do zaufanego stanu po incydencie — ransomware, awarii, błędzie operatora, skażeniu danych. W kontekście AI Truth ciągłość obejmuje nie tylko systemy produkcyjne, ale i bazę dowodów: bez integralności hashy i podpisów odtworzony system traci zdolność odróżniania faktu od GAP.
Problem — co musi wrócić i w jakim stanie
Incydent L wyzwala się przy utracie dostępności lub integralności komponentu krytycznego. System musi wrócić do działania w zdefiniowanej kolejności i z zachowaniem zaufania do danych:
Portal / dostęp
Warstwa publiczna i operatorska — punkt wejścia dla zgłoszeń i reakcji.
Baza dowodów
Evidence Layer: artefakty, hashe, znaczniki czasu. Integralność krytyczna dla doktryny claim ≤ proof.
Dashboardy
Executive Overview i panele decyzyjne — widoczność sytuacji.
Rejestr agentów
DID, tiering, trust score — sterowanie rojem (patrz Playbook H).
Backup i scoring
Kopie zapasowe oraz modele oceny ryzyka/priorytetu.
Historia decyzji
Log decyzji (wymagany też przez Playbook K) — rozliczalność.
Rozwiązania — architektura odporności
| Mechanizm | Cel | Realizacja |
|---|
| RTO / RPO per moduł | Wyznaczone cele czasu i utraty danych | każdy moduł ma zdefiniowane maksymalne RTO (czas powrotu) i RPO (dopuszczalna utrata) wg krytyczności |
| Immutable backup | Kopia odporna na modyfikację/szyfrowanie | WORM/object-lock — ransomware nie nadpisze ani nie usunie kopii |
| Backup offline (air-gap) | Kopia poza zasięgiem sieci | egzemplarz odizolowany fizycznie/logicznie — ostatnia linia obrony |
| Test odtworzenia | Dowód, że backup działa | regularne, udokumentowane próby restore z pomiarem faktycznego RTO |
| Punkt Zero | Zdefiniowany zaufany stan bazowy | znany-dobry snapshot konfiguracji i danych, do którego wraca się po skażeniu |
| DR plan + runbook awaryjny | Wykonalna procedura na kryzys | kolejność przywracania, role, kontakty, kryteria decyzji — gotowe do wykonania pod presją |
| Crypto inventory | Wiedza, gdzie i jaka kryptografia | inwentaryzacja algorytmów, kluczy, certyfikatów, protokołów w systemach |
| Plan przejścia PQC | Odporność post-kwantowa | mapa migracji do kryptografii postkwantowej + podejście „harvest now, decrypt later" |
| Podpisy i hashe dowodów | Integralność Evidence Layer | weryfikowalne podpisy i sumy kontrolne — odtworzony dowód musi dać się zweryfikować |
RTO/RPO — przykładowa tabela priorytetów SYMULACJA
| Moduł | Krytyczność | RTO (cel) | RPO (cel) |
|---|
| Baza dowodów (Evidence) | P0 | ≤ 1 h | ≤ 5 min |
| Portal / Incident Intake | P0 | ≤ 2 h | ≤ 15 min |
| Rejestr agentów / trust score | P1 | ≤ 4 h | ≤ 15 min |
| Dashboardy / raportowanie | P1 | ≤ 8 h | ≤ 1 h |
| Archiwum historyczne | P2 | ≤ 72 h | ≤ 24 h |
Dane demonstracyjne (demo). Powyższe RTO/RPO są przykładowe — właściwe wartości ustala analiza wpływu na działalność (BIA) odbiorcy.
Playbook — 8 kroków reakcji
DEKLARACJA DR→IZOLACJA→OCENA BACKUP→PUNKT ZERO→ODTWORZENIE→WERYFIKACJA INTEGRALNOŚCI→PRZYWRÓCENIE USŁUG→WALIDACJA
Krok 1 — Deklaracja DR. Utrata dostępności/integralności komponentu krytycznego → ogłoszenie sytuacji DR, uruchomienie runbooka awaryjnego, powołanie zespołu i ról. Priorytet P0. Start zegara RTO.
Krok 2 — Izolacja i powstrzymanie. Odetnij skażony/zagrożony segment, by zatrzymać rozprzestrzenianie (np. szyfrowania). Zabezpiecz backup offline przed dostępem atakującego. Nie przywracaj do wciąż skażonego środowiska.
Krok 3 — Ocena backupu. Ustal, które kopie są zaufane (immutable/offline), sprzed skażenia. Zweryfikuj ich datę względem RPO. Wybierz źródło odtworzenia dające najmniejszą utratę przy pewności czystości.
Krok 4 — Ustal Punkt Zero. Wyznacz zaufany stan bazowy (znany-dobry snapshot), do którego wracasz. To referencja: konfiguracja, dane, wersje modeli/agentów sprzed incydentu.
Krok 5 — Odtworzenie wg kolejności. Restore zgodnie z priorytetami RTO/RPO: najpierw baza dowodów i portal (P0), potem rejestr agentów i dashboardy. Postępuj wg runbooka, dokumentuj każdy krok.
Krok 6 — Weryfikacja integralności. Sprawdź podpisy i hashe odtworzonych dowodów — Evidence Layer musi dać się zweryfikować. Potwierdź spójność rejestru agentów (DID) i logów decyzji. Rozbieżność = GAP, nie zamykaj.
Krok 7 — Przywrócenie usług. Kontrolowane przywrócenie ruchu, ponowna kwarantanna agentów (trust score od zera —
Playbook H), rotacja kluczy jeśli podejrzenie kompromitacji. Monitoruj stabilność.
Krok 8 — Walidacja i lessons learned. Potwierdź dowodem: usługi w RTO, dane w RPO, integralność dowodów zweryfikowana, brak śladów atakującego. Zmierz faktyczne RTO vs cel, zaktualizuj DR plan, crypto inventory i harmonogram PQC → odporność +1. Zamknięcie tylko z dowodem odtworzenia.
Warstwa post-kwantowa (PQC)
Dlaczego PQC w playbooku ciągłości: integralność Evidence Layer opiera się na podpisach i hashach. Model zagrożenia „harvest now, decrypt later" zakłada, że przeciwnik gromadzi dziś zaszyfrowane dane, by odszyfrować je, gdy dojrzeją komputery kwantowe. Ciągłość długoterminowa wymaga: (1) crypto inventory — wiedzy, gdzie jest jaka kryptografia; (2) krypto-zwinności — zdolności wymiany algorytmów bez przebudowy systemu; (3) planu migracji PQC dla podpisów dowodów i kluczy o długim horyzoncie zaufania.
Flagi i sprzężenia
| Warunek | Flaga | Konsekwencja |
|---|
| Utrata dostępności usługi kluczowej/ważnej | NIS2_RELEVANT | Obowiązki NIS2: wczesne ostrzeżenie 24h, zgłoszenie 72h, raport końcowy |
| Komponent infrastruktury krytycznej | CRITICAL_INFRA | Podwyższone wymogi ciągłości i raportowania (KSC) |
| Skażenie danych osobowych / utrata dostępu do nich | GDPR_BREACH | RODO art. 33/34 — utrata dostępności też bywa naruszeniem |
| Przyczyna: ransomware | — | Sprzężenie z Playbook B (odtworzenie z immutable backup) |
Metryki odporności SYMULACJA
Dane demonstracyjne (demo). Wartości ilustrują format panelu, nie są rzeczywistymi pomiarami środowiska odbiorcy.
58 min
Faktyczne RTO bazy dowodów w teście SYMULACJA
cel ≤ 1 h
100%
Testów restore z weryfikacją hashy SYMULACJA
integralność potwierdzona
3
Kopie: prod + immutable + offline SYMULACJA
reguła 3-2-1
62%
Pokrycie crypto inventory planem PQC SYMULACJA
trend rosnący
Powiązane strony
Ransomware
Odtworzenie z immutable backup po szyfrowaniu. → Playbook B
Agent hijack
Ponowna kwarantanna roju po odtworzeniu. → Playbook H
Uwaga metodyczna: RTO/RPO, reguła 3-2-1 i model „harvest now, decrypt later" to ramki metodyczne (norma/dobra praktyka INTERNAL), nie wdrożone pomiary środowiska odbiorcy. Ramki NIS2/KSC/RODO opierają się na treści regulacji. Metryki i tabela RTO/RPO oznaczone SYMULACJA są przykładowe.