Plán kontinuity podnikání a obnovy po havárii¶
Rámec kontinuity služeb, odolnosti a obnovy MazeVault
ID dokumentu: MV-LEG-008
Verze: 1.0.0
Klasifikace: Důvěrné
Vlastník: Chief Information Security Officer (CISO)
Poslední aktualizace: 2026-05-01
Cyklus revize: Roční
Schválil: CEO / Představenstvo
Regulatorní základ: zákon č. 264/2025 Sb., směrnice NIS2 čl. 21 odst. 2 písm. c), nařízení DORA čl. 11–12, ISO/IEC 27001:2022 A.17
1. Účel a rozsah¶
1.1 Účel¶
Tento Plán kontinuity podnikání a obnovy po havárii („Plán") stanoví rámec, postupy a odpovědnosti pro zajištění kontinuity služeb MazeVault během narušujících událostí a obnovu provozu po havárii. Plán zajišťuje, že kritické podnikové funkce mohou pokračovat na přijatelné úrovni během narušení i po něm a že plný provoz služeb je obnoven v rámci definovaných cílů obnovy.
1.2 Rozsah¶
Tento Plán se vztahuje na:
- Všechny produkční systémy, služby a infrastrukturu MazeVault
- Všechny konfigurace nasazení: cloudově hostovaný backend, instalace brány (Kubernetes a on-premise) a nasazení agentů
- Všechna datová aktiva: zákaznické tajné údaje (secrets), šifrovací klíče, certifikáty, konfigurace a provozní data
- Veškerý personál zapojený do poskytování služeb a reakce na incidenty
- Všechna prostředí, kde jsou zpracovávána nebo uchovávána zákaznická data
1.3 Cíle¶
- Udržovat kritické funkce služeb během narušujících událostí
- Minimalizovat ztrátu dat v rámci definovaných cílů bodu obnovy (RPO)
- Obnovit služby v rámci definovaných cílů doby obnovy (RTO)
- Chránit integritu a důvěrnost zákaznických dat během operací obnovy
- Zajistit soulad s regulatorními požadavky na kontinuitu a odolnost
- Poskytnout jasné postupy pro běžné scénáře havárií
1.4 Definice¶
| Pojem | Definice |
|---|---|
| RTO (Recovery Time Objective) | Maximální přijatelná doba výpadku služby od okamžiku narušení do obnovení služby |
| RPO (Recovery Point Objective) | Maximální přijatelná ztráta dat měřená v čase; bod v čase, ke kterému musí být data obnovitelná |
| BCP (Business Continuity Plan) | Postupy pro udržení kritických podnikových funkcí během narušení |
| DR (Disaster Recovery) | Technické postupy pro obnovení IT systémů a dat po havárii |
| MTPD (Maximum Tolerable Period of Disruption) | Absolutní maximální doba, po které narušení způsobí nenapravitelné obchodní škody |
| BIA (Business Impact Analysis) | Posouzení dopadu narušení na podnikové funkce |
| Fencing Token | Monotónně rostoucí token používaný k prevenci split-brain operací v distribuovaných systémech |
2. Cíle RTO/RPO¶
2.1 Cíle obnovy podle scénáře¶
| Scénář havárie | RPO | RTO | MTPD | Priorita |
|---|---|---|---|---|
| Poškození databáze (logická chyba, neúspěšná migrace, selhání integrity dat) | <24 hodin (denní záloha) | <4 hodiny | 8 hodin | Kritická |
| Úplné selhání uzlu (pád jednoho serveru/podu, selhání hardwaru) | <24 hodin (denní záloha) | <2 hodiny (Kubernetes) / <4 hodiny (on-premise) | 6 hodin | Kritická |
| Selhání datového centra (úplný výpadek DC, síťová partice, selhání cloudového regionu) | <1 hodina (se synchronní replikací) | <8 hodin | 12 hodin | Kritická |
| Ztráta šifrovacího klíče (vault.key smazán nebo poškozen bez zálohy) | 0 (s řádnými zálohami klíčů) / TRVALÁ ZTRÁTA (bez zálohy) | <2 hodiny (se zálohou) / Neobnovitelné (bez zálohy) | N/A | Kritická |
| Ransomware / úplná ztráta dat (škodlivé šifrování, hromadné smazání, selhání úložiště) | <24 hodin (poslední čistá záloha) | <8 hodin | 12 hodin | Kritická |
| Selhání brány (nedostupnost jedné brány) | 0 (agenti ukládají do lokální mezipaměti) | <30 minut (failover) / <2 hodiny (manuálně) | 4 hodiny | Vysoká |
| Kompromitace certifikační autority | 0 (opětovné vydání) | <4 hodiny | 8 hodin | Kritická |
2.2 Klasifikace úrovní služeb¶
| Úroveň | Služby | RTO | RPO |
|---|---|---|---|
| Úroveň 1 — Kritická | Získávání/ukládání tajných údajů, vydávání certifikátů, autentizace, auditní protokolování | <2 hodiny | <1 hodina |
| Úroveň 2 — Důležitá | Správa brány, komunikace agentů, monitoring, upozorňování | <4 hodiny | <24 hodin |
| Úroveň 3 — Standardní | Reportování, dashboardy, nekritická upozornění, analytika | <8 hodin | <24 hodin |
| Úroveň 4 — Odložitelná | Dokumentace, vývojová prostředí, neprodukční testování | <24 hodin | <7 dní |
3. Architektura pro odolnost¶
3.1 Přehled systémové architektury¶
┌─────────────────────────────────────────────────────────────────┐
│ PRIMÁRNÍ BACKEND │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ API │ │ Auth │ │ Secret │ │ Certificate │ │
│ │ Service │ │ Service │ │ Service │ │ Service │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └──────┬───────┘ │
│ │ │ │ │ │
│ ┌────┴──────────────┴──────────────┴───────────────┴────┐ │
│ │ PostgreSQL (Centrální DB) │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────┴─────────┐ ┌───────────────┐ ┌────────────────┐ │
│ │ Redis Cache │ │ Secrets Vault │ │ Prometheus │ │
│ │ (Efemérní) │ │ (Šifrovaný) │ │ (Monitoring) │ │
│ └──────────────┘ └───────────────┘ └────────────────┘ │
└─────────────────────────────┬───────────────────────────────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
┌───────────┴──────┐ ┌──────┴───────┐ ┌─────┴────────────┐
│ Prostředí: │ │ Prostředí: │ │ Prostředí: │
│ NPR │ │ PRO │ │ PRO-2 │
│ │ │ │ │ │
│ ┌─────────────┐ │ │ ┌──────────┐ │ │ ┌─────────────┐ │
│ │ GW Primární │ │ │ │GW Primár.│ │ │ │ GW Primární │ │
│ │ (Aktivní) │ │ │ │(Aktivní) │ │ │ │ (Aktivní) │ │
│ └──────┬──────┘ │ │ └────┬─────┘ │ │ └──────┬──────┘ │
│ │ │ │ │ │ │ │ │
│ ┌──────┴──────┐ │ │ ┌────┴─────┐ │ │ ┌──────┴──────┐ │
│ │ GW DR │ │ │ │GW DR │ │ │ │ GW DR │ │
│ │ (Pohotov.) │ │ │ │(Pohotov.)│ │ │ │ (Pohotov.) │ │
│ └─────────────┘ │ │ └──────────┘ │ │ └─────────────┘ │
│ │ │ │ │ │ │ │ │
│ ┌────┴────┐ │ │ ┌───┴───┐ │ │ ┌────┴────┐ │
│ │ Agenti │ │ │ │Agenti │ │ │ │ Agenti │ │
│ │(On-Prem)│ │ │ │(On-P.)│ │ │ │(On-Prem)│ │
│ └─────────┘ │ │ └───────┘ │ │ └─────────┘ │
└──────────────────┘ └──────────────┘ └──────────────────┘
3.2 Synchronizace více DC založená na CRDT¶
Pro nasazení ve více datových centrech využívá MazeVault bezkonfliktní replikované datové typy (CRDT) pro synchronizaci:
- Účel: Umožnit eventuální konzistenci mezi geograficky distribuovanými bránami bez nutnosti synchronní replikace pro všechny operace
- Řešení konfliktů: CRDT garantují konvergenci bez ohledu na pořadí zpráv nebo síťové partice
- Datové typy: Aplikováno na stav konfigurace, metadata tajných údajů a šíření stavu certifikátů
- Model konzistence: Silná konzistence pro hodnoty tajných údajů (zdroj pravdy na backendu); eventuální konzistence pro provozní metadata na úrovni brány
3.3 GatewayEnvironmentLock a Fencing Tokens¶
Mechanismus GatewayEnvironmentLock zabraňuje scénářům split-brain v prostředích s více bránami:
- Jedna aktivní brána: V každém prostředí může být v daném okamžiku aktivní pouze JEDNA brána
- Fencing Tokens: Každé získání zámku generuje monotónně rostoucí fencing token (časové razítko UnixNano)
- Validace tokenů: Všechny zápisové operace validují fencing token; zastaralé tokeny jsou odmítnuty
- Prevence split-brain: Pokud se dříve aktivní brána zotaví po failoveru, její zastaralý fencing token zabrání provádění konfliktních zápisů
- AutoFailover: Ve výchozím nastavení vypnuto; vyžaduje manuální aktivaci k prevenci zbytečných failoverů při přechodných problémech
4. Strategie zálohování¶
4.1 Harmonogram zálohování a retence¶
| Aktivum | Metoda zálohování | Frekvence | Retence | Umístění úložiště | Šifrování |
|---|---|---|---|---|---|
| Databáze PostgreSQL | pg_dump (logický) / Azure Backup (pokud cloudově hostováno) |
Denně + před významnými změnami (migrace, velké aktualizace) | 30 dní klouzavě | Samostatný účet úložiště / mimo lokalitu | AES-256 v klidovém stavu |
| Šifrovací klíče (vault.key) | Manuální kopie do zabezpečeného úložiště | Při vytvoření + při každé rotaci | Trvalá (všechny historické verze) | Fyzicky oddělené zabezpečené místo (trezor, HSM, samostatné DC) | Chráněno fyzickou bezpečností + řízením přístupu |
| Trezor tajných údajů (secrets.vault) | Kopie souboru trezoru + přidruženého souboru klíče | Při každé změně + při rotaci klíčů | Trvalá | Fyzicky odděleno od vault.key | Inherentně šifrováno (šifrování trezoru) |
| Konfigurační soubory | Kopie souborového systému / správa verzí | Před každou změnou | 30 dní klouzavě | Záložní úložiště mimo lokalitu | AES-256 v klidovém stavu |
| TLS certifikáty | Kopie souborového systému | Před každou rotací | Do expirace + 90 dní | Záložní úložiště mimo lokalitu | AES-256 v klidovém stavu |
| Redis | NEZÁLOHUJE SE | N/A | N/A | N/A | N/A |
| Data Prometheus | Snapshot (volitelné) | Týdně | 90 dní | Záložní úložiště mimo lokalitu | AES-256 v klidovém stavu |
| Auditní záznamy | Export logů / replikace | Průběžně (v reálném čase) | Minimálně 3 roky | Samostatné neměnné úložiště | AES-256 v klidovém stavu |
4.2 Redis — Zdůvodnění efemérní mezipaměti¶
Redis je záměrně vyloučen z postupů zálohování, protože:
- Používá se výhradně jako přechodná vrstva mezipaměti (relace, omezování rychlosti, dočasné tokeny)
- Všechna autoritativní data se nacházejí v PostgreSQL
- Mezipaměť je automaticky obnovena z databáze při restartu služby
- V Redis nejsou uloženy žádné zákaznické tajné údaje ani trvalý stav
- Postup obnovy: restart Redis; aplikace automaticky znovu naplní mezipaměť
4.3 Ověřování záloh¶
- Měsíčně: Automatizovaná kontrola integrity záloh (ověření kontrolních součtů, testovací obnovení do izolovaného prostředí)
- Čtvrtletně: Úplný test obnovení do izolovaného prostředí s funkčním ověřením (viz oddíl 7)
- Při rotaci: Při rotaci šifrovacích klíčů nebo souborů trezoru ověřit, že nová záloha je kompletní a přístupná
- Dokumentace: Všechny výsledky ověřování zaznamenány se stavem úspěch/neúspěch a podpisem recenzenta
4.4 Požadavky na zálohy mimo lokalitu¶
- Zálohy MUSÍ být uloženy v geograficky oddělené lokalitě od produkčních systémů
- Minimální vzdálenost: jiná zóna dostupnosti (cloud) nebo jiná fyzická budova (on-premise)
- Přístup k úložišti záloh MUSÍ vyžadovat oddělené přihlašovací údaje od produkčních systémů
- Přístup k úložišti záloh MUSÍ být protokolován a monitorován
- Šifrovací klíče záloh MUSÍ být uloženy odděleně od šifrovaných záloh
5. Postupy obnovy po havárii¶
5.1 DR failover brány¶
Scénář: Primární brána pro prostředí se stane nedostupnou a nelze ji obnovit v rámci RTO.
Předpoklady:
- DR pohotovostní brána je zřízena a aktuální (konfigurace synchronizována)
- GatewayEnvironmentLock funguje správně
- Síťové připojení mezi DR bránou a backendem potvrzeno
Postup:
| Krok | Akce | Ověření | Odpovědná osoba |
|---|---|---|---|
| 1 | Ověřit, že primární brána je potvrzeně nedostupná (3 po sobě jdoucí selhání heartbeatu potvrzená GatewayHealthMonitorem) | Přijata upozornění monitoru stavu; pokus o manuální ověření | Vedoucí provozu |
| 2 | Oznámit veliteli incidentu; získat oprávnění pro failover | Potvrzení IC zdokumentováno | Vedoucí provozu |
| 3 | Spustit DR AKS cluster (pokud není warm standby): kubectl scale deployment mazevault-gateway --replicas=1 -n mazevault-dr |
Pody ve stavu Running: kubectl get pods -n mazevault-dr |
Inženýr infrastruktury |
| 4 | Ověřit, že DR pody brány jsou zdravé a připojené k backendu | Logy podů ukazují úspěšné připojení k backendu; endpoint stavu vrací 200 | Inženýr infrastruktury |
| 5 | Aktivovat DR bránu přes administrativní API: POST /api/v1/admin/failover/{env}/activate-dr |
API vrací 200; vydán nový fencing token | Vedoucí provozu |
| 6 | Ověřit, že DR brána je nyní aktivní a zpracovává požadavky | Potvrzena konektivita agentů; testovací získání tajného údaje úspěšné | Vedoucí provozu |
| 7 | Monitorovat 30 minut pro stabilitu | Žádné chyby v logech; metriky nominální | Inženýr infrastruktury |
| 8 | Oznámit dotčeným zákazníkům dokončení failoveru | Oznámení zákazníkům odesláno | Vedoucí komunikace |
Odhadovaná doba trvání: 15–30 minut (warm standby) / 30–60 minut (cold start)
5.2 Failback brány¶
Scénář: Primární brána byla obnovena a provoz by měl být vrácen z DR na primární bránu.
Předpoklady:
- Primární brána plně obnovena a ověřena jako zdravá
- Žádné aktivní incidenty na DR bráně
- Naplánováno okno údržby (pokud možno)
Postup:
| Krok | Akce | Ověření | Odpovědná osoba |
|---|---|---|---|
| 1 | Ověřit, že primární brána je plně obnovena a zdravá | Endpoint stavu vrací 200; všechny subsystémy provozní | Inženýr infrastruktury |
| 2 | Synchronizovat veškerý stav nashromážděný na DR bráně na primární | Stav synchronizace potvrzen; žádné datové nesrovnalosti | Inženýr infrastruktury |
| 3 | Provést failback přes administrativní API: POST /api/v1/admin/failover/{env}/failback |
API vrací 200; nový fencing token vydán primární bráně | Vedoucí provozu |
| 4 | Ověřit, že primární brána je aktivní a zpracovává požadavky | Potvrzena konektivita agentů; testovací operace úspěšné | Vedoucí provozu |
| 5 | Monitorovat primární bránu 30 minut pro stabilitu | Žádné chyby; metriky nominální | Inženýr infrastruktury |
| 6 | Zastavit DR AKS cluster: kubectl scale deployment mazevault-gateway --replicas=0 -n mazevault-dr |
DR pody ukončeny | Inženýr infrastruktury |
| 7 | Zdokumentovat dokončení failbacku | Záznam incidentu aktualizován; zpráva o provedené akci podána | Vedoucí provozu |
5.3 Obnovení databáze¶
Scénář: Poškození databáze PostgreSQL, neúspěšná migrace nebo selhání integrity dat vyžadující obnovení ze zálohy.
Postup:
| Krok | Akce | Příkaz/Ověření | Odpovědná osoba |
|---|---|---|---|
| 1 | Zastavit aplikační služby pro zabránění dalším zápisům | systemctl stop mazevault nebo škálovat deployment na 0 |
Inženýr infrastruktury |
| 2 | Posoudit rozsah poškození; určit bod obnovení | Přezkoumat logy; identifikovat poslední známou dobrou zálohu | Technický vedoucí |
| 3 | Vytvořit zálohu aktuálního (poškozeného) stavu pro forenzní analýzu | pg_dump -Fc mazevault_db > /backup/forensic-YYYYMMDD.dump |
Inženýr infrastruktury |
| 4 | Odstranit a znovu vytvořit databázi (nebo obnovit do nové instance) | dropdb mazevault_db && createdb mazevault_db |
Inženýr infrastruktury |
| 5 | Obnovit z vybrané zálohy | pg_restore -d mazevault_db /backup/mazevault-YYYYMMDD.dump |
Inženýr infrastruktury |
| 6 | Ověřit integritu databáze | Spustit kontroly stavu aplikace; ověřit počty řádků; zkontrolovat omezení | Inženýr infrastruktury |
| 7 | Spustit aplikační služby | systemctl start mazevault nebo škálovat deployment na požadovaný počet replik |
Inženýr infrastruktury |
| 8 | Ověřit plný stav aplikace | Endpoint stavu vrací 200; všechny subsystémy připojeny; testovací operace | Vedoucí provozu |
| 9 | Posoudit ztrátu dat (mezera mezi zálohou a selháním) | Zdokumentovat veškerá data vytvořená po záloze, která jsou ztracena; v případě potřeby informovat dotčené zákazníky | Technický vedoucí |
Odhadovaná doba trvání: 1–4 hodiny v závislosti na velikosti databáze a metodě zálohování.
5.4 Úplné obnovení systému¶
Scénář: Úplná ztráta systému vyžadující obnovu od nuly (katastrofální selhání hardwaru, ransomware nebo zřízení nového prostředí).
Postup:
| Krok | Akce | Podrobnosti | Odpovědná osoba |
|---|---|---|---|
| 1 | Příprava hostitele | Zřídit server/VM splňující minimální požadavky; nainstalovat OS; konfigurovat síť | Inženýr infrastruktury |
| 2 | Obnovení konfigurace | Zkopírovat konfigurační soubory ze zálohy na příslušná umístění | Inženýr infrastruktury |
| 3 | Obnovení TLS certifikátů | Obnovit CA certifikáty, serverové certifikáty a soukromé klíče ze zálohy | Inženýr infrastruktury |
| 4 | Načtení kontejnerových obrazů (pokud je to relevantní) | Stáhnout nebo načíst kontejnerové obrazy MazeVault do lokálního registru | Inženýr infrastruktury |
| 5 | Spuštění infrastrukturních služeb | Spustit PostgreSQL, Redis; ověřit konektivitu | Inženýr infrastruktury |
| 6 | Obnovení databáze | Provést postup obnovení databáze (oddíl 5.3, kroky 5–6) | Inženýr infrastruktury |
| 7 | Obnovení trezoru tajných údajů | Zkopírovat secrets.vault a vault.key z zabezpečených záložních umístění na určené cesty |
Inženýr infrastruktury |
| 8 | Spuštění aplikačních služeb | Spustit backendové služby MazeVault | Inženýr infrastruktury |
| 9 | Ověření stavu systému | Provést úplný kontrolní seznam ověření obnovy (oddíl 9) | Vedoucí provozu |
| 10 | Obnovení konektivity brány | Ověřit, že se brány mohou připojit; v případě potřeby znovu registrovat | Vedoucí provozu |
| 11 | Ověření konektivity agentů | Potvrdit, že se agenti znovu připojují k bránám; otestovat získání tajných údajů | Vedoucí provozu |
| 12 | Obnovení monitoringu | Ověřit, že Prometheus, upozorňování a protokolování jsou funkční | Inženýr infrastruktury |
| 13 | Dokumentace a komunikace | Aktualizovat záznam incidentu; informovat zainteresované strany o obnovení | Vedoucí komunikace |
Odhadovaná doba trvání: 4–8 hodin v závislosti na době zřizování infrastruktury.
5.5 Obnovení šifrovacího klíče¶
Scénář: Ztráta nebo poškození vault.key (klíče, který dešifruje trezor tajných údajů).
5.5.1 Se zálohou k dispozici¶
| Krok | Akce | Odpovědná osoba |
|---|---|---|
| 1 | Získat zálohu vault.key ze zabezpečeného úložiště mimo lokalitu |
CISO / Inženýr infrastruktury |
| 2 | Ověřit integritu klíče (porovnání kontrolních součtů) | Inženýr infrastruktury |
| 3 | Umístit klíč na určené zabezpečené místo na cílovém systému | Inženýr infrastruktury |
| 4 | Ověřit dešifrování trezoru: vault-tool list |
Inženýr infrastruktury |
| 5 | Ověřit, že všechny tajné údaje jsou přístupné a dešifrovatelné | Vedoucí provozu |
| 6 | Obnovit normální provoz | Vedoucí provozu |
Odhadovaná doba trvání: <2 hodiny
5.5.2 Bez zálohy — TRVALÁ ZTRÁTA DAT¶
KRITICKÉ VAROVÁNÍ: Pokud je
vault.keyztracen a neexistuje žádná záloha, všechny tajné údaje zašifrované tímto klíčem jsou trvale a neodvolatelně ztraceny. Neexistuje žádný mechanismus obnovení. Tento scénář vyžaduje úplné opětovné vytvoření tajných údajů.
| Krok | Akce | Odpovědná osoba |
|---|---|---|
| 1 | Potvrdit, že záloha neexistuje nikde (ověřit všechna záložní umístění) | CISO |
| 2 | Přijmout trvalou ztrátu existujících šifrovaných tajných údajů | Rozhodnutí CISO + CEO |
| 3 | Vygenerovat nový šifrovací klíč: vault-tool init |
Inženýr infrastruktury |
| 4 | Okamžitě vytvořit více záloh nového klíče v oddělených zabezpečených umístěních | CISO |
| 5 | Ručně znovu vytvořit všechny tajné údaje (koordinovat s každým zákazníkem ohledně jejich přihlašovacích údajů) | Vedoucí provozu + Zákaznické vztahy |
| 6 | Zdokumentovat incident a aktualizovat postupy pro prevenci opakování | CISO |
| 7 | Provést revizi po incidentu | Celý tým IRT |
Odhadovaná doba trvání: Dny až týdny (v závislosti na počtu tajných údajů k opětovnému vytvoření)
6. Prevence split-brain¶
6.1 Popis problému¶
V distribuované architektuře brány může síťová partice nebo selhání komunikace vést k tomu, že více brán věří, že jsou aktivní instancí pro dané prostředí. Tento stav „split-brain" může způsobit:
- Konfliktní zápisy do sdílených zdrojů
- Nekonzistenci dat mezi bránami
- Konflikty při vydávání certifikátů
- Divergenci auditních záznamů
6.2 Mechanismus GatewayEnvironmentLock¶
GatewayEnvironmentLock poskytuje distribuované vzájemné vyloučení:
┌─────────────────────────────────────────────────────┐
│ GatewayEnvironmentLock │
├─────────────────────────────────────────────────────┤
│ Environment: PRO │
│ Active Gateway: gateway-pro-primary │
│ Fencing Token: 1714567890123456789 (UnixNano) │
│ Acquired: 2026-05-01T10:00:00Z │
│ Last Heartbeat: 2026-05-01T10:01:30Z │
│ AutoFailover: DISABLED │
└─────────────────────────────────────────────────────┘
6.3 Provozní parametry¶
| Parametr | Hodnota | Popis |
|---|---|---|
| HeartbeatTimeout | 2 minuty | Maximální doba mezi heartbeaty, po které je brána považována za nezdravou |
| HealthCheckInterval | 30 sekund | Frekvence kontrolních sond stavu |
| FailureThreshold | 3 po sobě jdoucí selhání | Počet po sobě jdoucích zmeškaných heartbeatů před vyhlášením selhání |
| AutoFailover | VYPNUTO (ve výchozím nastavení zakázáno) | Automatický failover na DR bránu se neprovádí bez explicitní akce operátora |
| FencingTokenType | UnixNano (monotónně rostoucí) | Zajišťuje řazení získání zámků |
6.4 Fungování Fencing Tokenu¶
- Když brána získá zámek prostředí, obdrží fencing token (aktuální časové razítko UnixNano)
- Všechny zápisové operace do sdíleného stavu zahrnují fencing token
- Backend odmítne jakoukoli operaci s fencing tokenem menším nebo rovným poslednímu přijatému tokenu
- To garantuje, že i pokud se zastaralá brána pokusí o operace po failoveru, její zastaralý token je odmítnut
- Vyšší token nové aktivní brány zajišťuje, že její operace mají přednost
6.5 AutoFailover vypnut — Zdůvodnění¶
AutoFailover je ve výchozím nastavení vypnut, protože:
- Přechodné síťové problémy (krátké partice, zpoždění DNS) by mohly vyvolat zbytečné failovery
- Failover přináší riziko nekonzistence dat, pokud není správně sekvencován
- Ověření operátorem zajišťuje, že primární brána skutečně selhala (není pouze dočasně nedostupná)
- Manuální failover umožňuje koordinovanou přípravu DR prostředí
- Snižuje riziko „oscilace" mezi primární a DR bránou při nestabilních podmínkách
AutoFailover MŮŽE být povolen pro konkrétní prostředí po explicitním přijetí rizika ze strany CISO, s příslušnými opatřeními (prodloužený práh selhání, potvrzovací zpoždění).
7. Program testování¶
7.1 Harmonogram testů¶
| Typ testu | Frekvence | Rozsah | Doba trvání | Účastníci |
|---|---|---|---|---|
| Test obnovení ze zálohy | Čtvrtletně | Úplné obnovení databáze a trezoru do izolovaného prostředí | 4–8 hodin | Infrastruktura + Provoz |
| Cvičení failoveru brány | Pololetně | Provedení úplného postupu failoveru a failbacku v testovacím prostředí | 2–4 hodiny | Provoz + Infrastruktura |
| Úplná DR simulace | Ročně | Simulace úplného selhání datového centra; obnova všech služeb | 1 celý den | Všechny role BCP |
| Ověření integrity záloh | Měsíčně | Automatizované ověření kontrolních součtů všech záloh | Automatizované | Infrastruktura (přezkum výsledků) |
| Test komunikace | Čtvrtletně | Ověření všech notifikačních kanálů a eskalačních kontaktů | 1 hodina | Vedoucí komunikace + IRT |
| Teoretické cvičení | Pololetně | Diskuse nad scénáři pro rozhodování v rámci BCP/DR | 2–3 hodiny | Všechny role BCP + management |
7.2 Postup čtvrtletního DR testu¶
| Krok | Akce | Kritéria úspěchu |
|---|---|---|
| 1 | Zřídit izolované testovací prostředí | Prostředí přístupné; žádné připojení k produkci |
| 2 | Obnovit databázi z nejnovější produkční zálohy | Obnovení dokončeno bez chyb; integrita dat ověřena |
| 3 | Obnovit trezor tajných údajů a vault.key | vault-tool list vrací očekávaný počet tajných údajů |
| 4 | Ověřit, že všechny tajné údaje jsou přístupné a dešifrovatelné | Vzorek tajných údajů získán a validován |
| 5 | Ověřit operace s certifikáty | Testovací vydání a validace certifikátu |
| 6 | Ověřit endpointy stavu aplikace | Všechny kontroly stavu projdou |
| 7 | Zdokumentovat výsledky | Testovací zpráva dokončena se stavem úspěch/neúspěch pro každé kritérium |
| 8 | Zlikvidovat testovací prostředí | Všechna testovací data bezpečně vymazána |
7.3 Požadavky na dokumentaci testů¶
Každý test MUSÍ vytvořit zprávu obsahující:
- Datum testu, účastníky a použité prostředí
- Dodržený postup (odkaz na tento dokument nebo vysvětlení odchylky)
- Stav úspěch/neúspěch pro každé testovací kritérium
- Skutečně dosažené RTO vs. cílové RTO
- Zjištěné problémy a jejich řešení
- Doporučení pro zlepšení postupů
- Podpis vedoucího provozu
7.4 Náprava selhání testů¶
- Jakékoli selhání testu MUSÍ být řešeno jako vysoce prioritní nález
- Analýza kořenové příčiny vyžadována do 5 pracovních dnů
- Plán nápravných opatření s vlastníkem a termínem
- Opakovaný test naplánován do 30 dnů od dokončení nápravného opatření
- Opakovaná selhání eskalována na CISO pro posouzení rizik
8. Šifrovaná záloha trezoru¶
8.1 Kritické soubory¶
| Soubor | Účel | Kritičnost |
|---|---|---|
secrets.vault |
Obsahuje všechny šifrované přihlašovací údaje, API klíče, hesla k databázi a zákaznické tajné údaje | KRITICKÝ — Ztráta bez zálohy znamená nutnost opětovného vytvoření všech tajných údajů |
vault.key |
Dešifrovací heslo/klíč pro trezor tajných údajů | KRITICKÝ — Ztráta bez zálohy znamená TRVALOU, NEODVOLATELNOU ztrátu veškerého obsahu trezoru |
8.2 Požadavky na úložiště¶
POVINNÉ:
secrets.vaultavault.keyMUSÍ být uloženy na fyzicky oddělených místech.
| Požadavek | secrets.vault | vault.key |
|---|---|---|
| Umístění úložiště | Záloha mimo lokalitu (oddělená od produkce) | Fyzicky oddělena od secrets.vault (jiné zařízení, trezor nebo HSM) |
| Řízení přístupu | Omezeno na autorizovaný provozní personál | Omezeno pouze na CISO + určeného správce záloh |
| Fyzická bezpečnost | Šifrované úložiště; zařízení s protokolovaným přístupem | Bezpečnostní trezor, HSM nebo ekvivalentní fyzická ochrana |
| Kopie | Minimálně 2 kopie v oddělených umístěních | Minimálně 2 kopie v oddělených umístěních (NIKDY umístěny společně se souborem trezoru) |
| Digitální ochrana | Šifrováno v klidovém stavu (šifrování záložního úložiště) | Šifrováno v klidovém stavu; dodatečně chráněno samostatným heslem při digitálním uložení |
8.3 Postup čtvrtletního ověření¶
| Krok | Akce | Očekávaný výsledek |
|---|---|---|
| 1 | Získat zálohu vault.key ze zabezpečeného úložiště | Soubor klíče přístupný; bezpečnostní pečeť neporušena |
| 2 | Získat zálohu secrets.vault z odděleného úložiště | Soubor trezoru přístupný; datum modifikace odpovídá poslední záloze |
| 3 | Nasadit oba do izolovaného ověřovacího prostředí | Soubory na místě |
| 4 | Provést: vault-tool list |
Vrátí úplný seznam uložených tajných údajů (odpovídá produkčnímu počtu) |
| 5 | Získat vzorové tajné údaje a ověřit dešifrování | Tajné údaje se správně dešifrují; hodnoty odpovídají produkci |
| 6 | Zdokumentovat výsledek ověření | Podepsaný záznam ověření uložen |
| 7 | Bezpečně vrátit záložní soubory do úložiště | Soubory znovu zapečetěny v zabezpečeném úložišti |
8.4 Postupy rotace¶
Při rotaci šifrovacích klíčů nebo souborů trezoru:
- Vytvořit zálohu nového trezoru a klíče okamžitě po rotaci
- Ověřit novou zálohu (vault-tool list v izolovaném prostředí)
- Zachovat předchozí verzi vault.key (potřebná k dešifrování jakékoli zálohy vytvořené se starým klíčem)
- Aktualizovat dokumentaci inventáře záloh
- Informovat správce záloh o aktualizaci
9. Ověření obnovy¶
9.1 Ověření kontrolami stavu¶
Po jakékoli operaci obnovy MUSÍ všechny následující kontroly projít, než bude obnova prohlášena za dokončenou:
| Kontrola | Metoda | Očekávaný výsledek |
|---|---|---|
| Stav aplikace | GET /api/v1/health |
HTTP 200; všechny stavy subsystémů „healthy" |
| Stav licence | Endpoint stavu nebo administrativní API | Stav licence: active |
| Konektivita databáze | Kontrola subsystému endpointu stavu | Fond připojení PostgreSQL aktivní; dotazy se provádějí |
| Konektivita Redis | Kontrola subsystému endpointu stavu | Připojení Redis navázáno; operace mezipaměti funkční |
| Auditní protokolování | Provést testovací akci; ověřit vytvoření auditní události | Auditní událost zapsána se správným pokračováním řetězu hashů |
| Metriky Prometheus | Zkontrolovat cíle Prometheus | Všechny cíle sběru UP; metriky proudí |
| Strukturované protokolování | Přezkoumat výstup aplikačních logů | JSON formátované záznamy logů se zobrazují s očekávanými poli |
| Operace s tajnými údaji | Získat testovací tajný údaj | Tajný údaj úspěšně získán; správně dešifrován |
| Operace s certifikáty | Vydat testovací certifikát (neprodukční) | Certifikát vydán s platným řetězcem |
| Konektivita brány | Ověřit přijetí heartbeatu brány | Brána hlásí zdravý stav; heartbeat v rámci časového limitu |
| Konektivita agentů | Ověřit registraci agenta | Alespoň jeden agent úspěšně komunikuje |
9.2 Prodloužená doba monitorování¶
Po úspěšném ověření obnovy:
- Prvních 2 hodiny: Zvýšený monitoring se sníženými prahy upozornění
- Prvních 24 hodin: Pohotovostní inženýr aktivně monitoruje chování systému
- Prvních 72 hodin: Denní přezkum všech metrik pro anomálie
- Po 72 hodinách: Návrat ke standardnímu monitoringu, pokud nebyly zjištěny žádné problémy
9.3 Eskalace při selhání obnovy¶
Pokud ověření obnovy selže:
- Identifikovat selhávající kontrolu a posoudit dopad
- Pokusit se o nápravnou akci (restart služby, opětovné použití konfigurace)
- Pokud nebude vyřešeno do 30 minut, eskalovat na velitele incidentu
- Zvážit alternativní přístup k obnově (jiná záloha, jiný postup)
- Zdokumentovat selhání a řešení pro zlepšení postupu
10. Role a odpovědnosti během BCP¶
10.1 Organizace BCP¶
| Role | Primární držitel | Odpovědnosti |
|---|---|---|
| Velitel incidentu | CISO | Celková autorita BCP; rozhodování; eskalace; regulatorní komunikace |
| Vedoucí provozu | Vedoucí provozu | Koordinace činností obnovy; řízení technických týmů; správa časového harmonogramu |
| Inženýr infrastruktury | Sr. DevOps inženýr | Provádění technických postupů obnovy; správa systémů; monitoring |
| Vedoucí komunikace | Vedoucí zákaznického úspěchu | Oznámení zákazníkům; interní komunikace; správa stavové stránky |
| Technický vedoucí | CTO | Technické rozhodování; vedení architektury; koordinace s dodavateli |
| Právní poradce | Právní poradce | Regulatorní povinnosti; smluvní požadavky; posouzení odpovědnosti |
10.2 Matice rozhodovací pravomoci¶
| Rozhodnutí | Pravomoc | Eskalace |
|---|---|---|
| Aktivovat BCP | Velitel incidentu (CISO) | CEO, pokud je CISO nedostupný |
| Autorizovat failover | Velitel incidentu | Vedoucí provozu (pokud IC předem autorizoval) |
| Obsah komunikace se zákazníky | Vedoucí komunikace + Právní poradce | Velitel incidentu ke schválení |
| Přijmout ztrátu dat (RPO překročeno) | CEO | Představenstvo, pokud ztráta překročí definovanou hranici |
| Zapojit externí dodavatele/konzultanty | Velitel incidentu | CEO, pokud náklady překročí předem schválený rozpočet |
| Prohlásit obnovu za dokončenou | Velitel incidentu (po ověření) | N/A |
| Deaktivovat BCP | Velitel incidentu | CEO, pokud doba trvání incidentu >48 hodin |
10.3 Nástupnictví a dostupnost¶
- Každý primární držitel role MUSÍ mít určeného zástupce
- Kontaktní informace udržovány na bezpečném, přístupném místě (ne výhradně závislé na postižených systémech)
- Pokud jsou primární osoba i zástupce nedostupní, odpovědnost přebírá další v organizační hierarchii
- Minimálně 2 kvalifikovaní pracovníci musí být dosažitelní kdykoli pro obnovu služeb Úrovně 1
11. Kritéria aktivace BCP¶
11.1 Automatické spouštěcí události¶
BCP MUSÍ být aktivován okamžitě, když je potvrzena jakákoli z následujících podmínek:
| Spouštěcí událost | Podmínka | Úroveň aktivace |
|---|---|---|
| Závažný incident (P1) | Kritický bezpečnostní incident s dopadem na službu přesahujícím 30 minut | Plné BCP |
| Selhání datového centra | Úplná ztráta primárního hostingového prostředí | Plné BCP |
| Potvrzení ransomware | Potvrzené nasazení ransomware ovlivňující produkční systémy | Plné BCP |
| Kompromitace klíčů | Potvrzená kompromitace nebo ztráta šifrovacích klíčů (vault.key) | Plné BCP |
| Prodloužený výpadek | Jakýkoli neplánovaný výpadek přesahující 50 % příslušného RTO | Částečné BCP (eskalovat, pokud se neřeší) |
| Selhání více systémů | Současné selhání 2+ služeb Úrovně 1 | Plné BCP |
11.2 Aktivace na základě uvážení¶
Velitel incidentu MŮŽE aktivovat BCP dle vlastního uvážení při:
- Důvěryhodné zpravodajské informaci o hrozícím útoku
- Významné degradaci směřující k selhání
- Výpadku dodavatele/poskytovatele s nejistým časovým rámcem řešení
- Přírodní katastrofě nebo fyzické bezpečnostní hrozbě pro hostingová zařízení
- Pandemii nebo personální krizové situaci ovlivňující provozní schopnost
11.3 Proces aktivace¶
- Spouštěcí podmínka identifikována a potvrzena
- Velitel incidentu (nebo zástupce) formálně vyhlašuje aktivaci BCP
- Všichni držitelé rolí BCP informováni prostřednictvím nouzových komunikačních kanálů
- Zřízen krizový štáb BCP (fyzický nebo virtuální)
- Provedeno počáteční posouzení situace (do 30 minut)
- Strategie obnovy vybrána na základě scénáře a dostupných zdrojů
- Činnosti obnovy zahájena podle příslušného postupu (oddíl 5)
12. Komunikace během výpadku¶
12.1 Interní komunikace¶
| Kanál | Účel | Frekvence |
|---|---|---|
| Krizový štáb (vyhrazený video/chat kanál) | Koordinace v reálném čase mezi týmem BCP | Průběžně během aktivního incidentu |
| Stavové aktualizace (interní) | Povědomí širšího týmu | Každých 30 minut během aktivní obnovy |
| Briefing vedení | Povědomí CEO/Představenstva o situaci | Každé 2 hodiny nebo při významných změnách |
| Celofiremní aktualizace | Povědomí celé společnosti (pokud závažné) | Dle potřeby; minimálně denně během prodlouženého výpadku |
12.2 Komunikace se zákazníky¶
| Fáze | Komunikace | Kanál | Načasování |
|---|---|---|---|
| Počáteční | Potvrzení narušení služby; probíhá šetření | Stavová stránka + email | Do 30 minut od detekce |
| Aktualizace | Pokrok, odhadované řešení, alternativní řešení | Stavová stránka | Každých 60 minut (minimálně) |
| Vyřešení | Služba obnovena; shrnutí dopadu | Stavová stránka + email | Do 1 hodiny od obnovy |
| Post-mortem | Kořenová příčina, nápravná opatření, preventivní opatření | Email + publikace na portálu | Do 5 pracovních dnů |
12.3 Protokol stavové stránky¶
- Stavová stránka MUSÍ být hostována na infrastruktuře nezávislé na produkčních systémech MazeVault
- Aktualizace stavové stránky NESMÍ obsahovat citlivé bezpečnostní detaily
- Kategorie stavů: Provozní → Degradovaný výkon → Částečný výpadek → Hlavní výpadek
- Granularita stavu na úrovni služby: Backend API, Služby brány, Certifikační služby, Monitoring
12.4 Šablony komunikace¶
Šablony pro komunikaci se zákazníky během výpadku MUSÍ být předem schváleny právním poradcem a připraveny k okamžitému použití. Šablony MUSÍ pokrývat:
- Počáteční potvrzení výpadku
- Pravidelné stavové aktualizace (s odhadovaným časem řešení i bez něj)
- Oznámení o obnovení služby
- Shrnutí po incidentu
13. Mapování na regulatorní požadavky¶
| Regulatorní požadavek | Oddíl v tomto dokumentu |
|---|---|
| Směrnice NIS2 čl. 21 odst. 2 písm. c) — Kontinuita podnikání a krizové řízení | Oddíly 1–12 (komplexní rámec BCP/DR) |
| Nařízení DORA čl. 11 — Politika kontinuity podnikání v oblasti ICT | Oddíly 1–4 (politika, cíle, architektura, zálohování) |
| Nařízení DORA čl. 12 — Plány reakce a obnovy ICT | Oddíly 5–6 (postupy DR, prevence split-brain) |
| Nařízení DORA čl. 12 odst. 2 — Politiky zálohování a metody obnovení | Oddíl 4 (strategie zálohování), oddíl 5 (postupy obnovení) |
| Nařízení DORA čl. 12 odst. 3 — Redundance pro kritické funkce | Oddíl 3 (architektura pro odolnost), oddíl 6 (split-brain) |
| Nařízení DORA čl. 12 odst. 5 — Testování plánů kontinuity podnikání v ICT | Oddíl 7 (program testování) |
| ISO/IEC 27001:2022 A.5.29 — Bezpečnost informací během narušení | Oddíly 3, 5, 6 (bezpečnost zachována během obnovy) |
| ISO/IEC 27001:2022 A.5.30 — Připravenost ICT na kontinuitu podnikání | Oddíly 2–4 (RTO/RPO, architektura, zálohování) |
| ISO/IEC 27001:2022 A.8.13 — Zálohování informací | Oddíl 4 (strategie zálohování) |
| ISO/IEC 27001:2022 A.8.14 — Redundance zařízení pro zpracování informací | Oddíl 3 (architektura více DC, DR pohotovostní režim) |
| SOC 2 A1.1 — Cíle obnovy definovány | Oddíl 2 (cíle RTO/RPO) |
| SOC 2 A1.2 — Postupy obnovy existují a jsou testovány | Oddíly 5, 7 (postupy a testování) |
| SOC 2 A1.3 — Postupy obnovy podporují cíle | Oddíl 9 (ověření obnovy vůči cílům) |
| Zákon č. 264/2025 Sb. — Požadavky na kontinuitu pro základní služby | Oddíly 1–12 (komplexní rámec) |
14. Související dokumenty¶
| ID dokumentu | Název |
|---|---|
| MV-LEG-001 | Politika bezpečnosti informací |
| MV-LEG-002 | Politika kryptografie |
| MV-LEG-003 | Politika řízení rizik |
| MV-LEG-004 | Politika protokolování a monitoringu |
| MV-LEG-005 | Politika řízení přístupu |
| MV-LEG-006 | Politika správy zranitelností a záplat |
| MV-LEG-007 | Plán reakce na incidenty |
Příloha A: Rychlý přehled nouzových kontaktů¶
| Role | Primární kontakt | Záložní kontakt | Dostupnost |
|---|---|---|---|
| Velitel incidentu (CISO) | [Jméno CISO / Telefon / Email] | [Zástupce / Telefon / Email] | 24/7 |
| Vedoucí provozu | [Jméno / Telefon / Email] | [Zástupce / Telefon / Email] | 24/7 |
| Inženýr infrastruktury | [Jméno / Telefon / Email] | [Zástupce / Telefon / Email] | 24/7 (rotace pohotovostí) |
| Vedoucí komunikace | [Jméno / Telefon / Email] | [Zástupce / Telefon / Email] | Pracovní doba + pohotovost |
| CEO | [Jméno / Telefon / Email] | [COO / Telefon / Email] | 24/7 pro P1 |
| Právní poradce | [Jméno / Telefon / Email] | [Externí firma / Telefon] | Pracovní doba + nouzová smlouva |
Poznámka: Skutečné kontaktní údaje udržovány v zabezpečeném, samostatně přístupném kontaktním seznamu (ne v tomto dokumentu).
Příloha B: Rychlý rozhodovací diagram¶
Zjištěno narušení služby
│
▼
Je ovlivněna produkce?
│
Ano ─┤── Ne → Monitorovat; standardní proces incidentu
│
▼
Lze službu obnovit do 30 minut?
│
Ano ─┤── Ne → Aktivovat BCP
│ │
▼ ▼
Standardní Identifikovat scénář (oddíl 5)
reakce na │
incident ├─ Selhání brány → Oddíl 5.1
├─ Problém s databází → Oddíl 5.3
├─ Úplná ztráta systému → Oddíl 5.4
├─ Ztráta klíče → Oddíl 5.5
└─ Selhání DC → Oddíl 5.1 + 5.4
Správa dokumentu¶
| Verze | Datum | Autor | Popis změny |
|---|---|---|---|
| 1.0.0 | 2026-05-01 | CISO | Počáteční vydání |
KONEC DOKUMENTU