Stručně: IT nouzový plán pro webové servery předem stanoví, kdo v krizi rozhoduje, koho lze zastihnout, které systémy mohou být dotčeny a jaké kroky následují v jakém pořadí. Kdo chce vytvořit IT nouzový plán, nepotřebuje tlustou příručku, ale několik aktuálních stran, které jsou dostupné i bez fungujícího IT. Situace kolem PHP2Shell je dobrým důvodem to udělat nyní.
Proč nouzový plán šetří čas a škody
V krizi se první hodiny často ztratí hledáním: Kdo má přístup k poskytovateli hostingu? Kde jsou zálohy? Kdo rozhodne, zda e-shop půjde offline? Koho je třeba informovat? Nouzový plán na tyto otázky odpovídá předem, v klidu.
PHP2Shell ukázal, jak krátký může být čas. Dne 20. 10. 2026 php.net oznámilo záplaty, 21. 10. v 16:00 německého času byly zveřejněny a BSI (německý Spolkový úřad pro informační bezpečnost) doporučil okamžitou aktualizaci nebo dočasné vypnutí. Firmy s plánem věděly, komu zavolat a které servery zkontrolovat. Jiné musely nejdřív zjistit, kde vůbec PHP běží.
Vytvoření IT nouzového plánu: stavební kameny
Praktický plán pro webové servery zahrnuje tyto části:
1. Role a rozhodování. Kdo v krizi řídí, kdo zastupuje, kdo smí systémy vypnout, kdo mluví navenek? Zaznamenejte jména a zástupce.
2. Seznam kontaktů. Interní kontaktní osoby, poskytovatel hostingu, agentura, IT poskytovatel, pověřenec pro ochranu osobních údajů, právní poradenství, kyberpojištění s číslem pojistné smlouvy, příslušný dozorový úřad pro ochranu osobních údajů, Zentrale Ansprechstelle Cybercrime (ústřední kontaktní místo pro kybernetickou kriminalitu) vaší spolkové země. Tento seznam musí být k dispozici vytištěný.
3. Inventář systémů. Každý web, e-shop a portál se serverem, poskytovatelem hostingu, provozním režimem, verzí PHP, aplikací, odpovědnou osobou a druhem zpracovávaných dat.
4. Pravidla rozhodování. Za jakých podmínek systém odpojíme od sítě? Kdo o tom smí rozhodnout? Co platí v noci a o víkendu?
5. Postupy. Krátké sledy kroků pro typické případy: známá kritická zranitelnost, podezření na průnik, znehodnocený web, únik dat, vydírání.
6. Cesty oznamování. Kdo posuzuje oznamovací povinnost podle čl. 33 GDPR, pokud možno do 72 hodin od zjištění? Kdo hlásí BSI při povinnosti podle NIS2? Kdo informuje pojišťovnu?
7. Obnova. Kde leží zálohy, kdo je může obnovit, jak dlouho to trvá, kdy to bylo naposledy testováno?
Příklad: postup „kritická zranitelnost PHP“
Takto může vypadat postup, jaký byl u PHP2Shell potřeba:
| Krok | Kdo | Výsledek |
|---|---|---|
| Posoudit oznámení (php.net, BSI) | odpovědní za IT | dotčené systémy podle inventáře |
| Nasadit aktualizaci, restartovat všechny workery | admin nebo poskytovatel | doklad se stavem balíčků a časem procesu |
| Kde aktualizace nejde: přechodná opatření nebo odpojit od sítě | rozhoduje vedení | zdokumentované rozhodnutí |
| Zajistit logy, zkontrolovat stopy | admin nebo forenzní analýza | nález nebo žádný nález |
| Při nálezu: spustit postup pro incident | vedení krizového řízení | zkontrolovat cesty oznamování |
Důležité přitom je: záplata zranitelnost uzavírá, ale neodstraní dříve zavlečený škodlivý software. Proto patří hledání stop pevně do postupu.
Stanovte, jak dlouho se logy webového serveru uchovávají a kde leží mimo server. U PHP2Shell odborný tisk doporučoval uchovávat logy od 20. 10. 2026. Kdo logy drží jen několik dní, taková doporučení nemůže splnit.
Příprava, která plán teprve zefektivní
Plán je jen tak dobrý jako předpoklady za ním. Ověřte, zda existují a jsou otestovány zálohy podle pravidla 3-2-1, viz Zálohy podle pravidla 3-2-1. S poskytovatelem hostingu a agenturou písemně vyjasněte, kdo při kritických zranitelnostech co přebírá. Přístupové údaje pro nouzové případy uchovávejte bezpečně, ale dosažitelně, například v chráněném trezoru hesel s nouzovým přístupem.
Připravte také textové šablony: interní informaci, oznámení zákazníkům, upozornění na statické stránce o údržbě. Pokyny najdete na stránce Krizová komunikace po útoku.
Cvičit a udržovat aktuální
Plán, který se nikdy necvičil, téměř vždy obsahuje mezery. Jednou ročně projděte jeden scénář, například „kritická zranitelnost PHP v pátek odpoledne“, a zaznamenejte, kde to drhne. Pro začátek stačí jednoduchý test: Dokáže druhá osoba bez pomoci první zastihnout poskytovatele hostingu, obnovit zálohu a přepnout web do režimu údržby? Pokud ne, v plánu něco chybí, většinou přístup, telefonní číslo nebo popis. Právě takové mezery mají cvičení zviditelnit dříve, než půjde do tuhého. Plán po každém cvičení a každé podstatné změně aktualizujte. Jako metodický rámec se hodí IT-Grundschutz (německý standard základní ochrany IT) od BSI a BSI-Standard 200-4 k řízení kontinuity činností.
Právní otázky, například k oznamovacím povinnostem, plán nevyjasňuje konečně. Zajišťuje, aby byly správné osoby zapojeny včas. Tato stránka je obecná informace, nikoli právní poradenství.
Jak konkrétně pomáhá PHP SOS?
- S vámi vytvoříme inventář systémů vašich webových serverů, včetně provozního režimu a verze PHP.
- Napíšeme technické postupy pro typické scénáře a odsouhlasíme je s poskytovatelem hostingu a agenturou.
- Provedeme cvičení a poznatky zapracujeme do plánu.
- V krizi převezmeme technickou stránku prostřednictvím reakce na incidenty, na přání zajištěnou smlouvou o bezpečnostní údržbě.
Časté dotazy
Jak rozsáhlý musí IT nouzový plán být?
Co nejkratší, tak podrobný, jak je nutné. Pro webové servery často stačí několik stran s kontakty, seznamem systémů, pravidly rozhodování a postupy. Důležitější než rozsah je, aby byl aktuální a v krizi se našel.
Kde nouzový plán uchovávat?
Alespoň na jednom místě dostupném i bez fungujícího IT, například vytištěný nebo na odděleném zařízení. Plán, který leží jen na dotčeném serveru nebo v uzamčené firemní síti, v krizi nepomůže.
Jak často by se měl plán kontrolovat?
Alespoň jednou ročně a po každé podstatné změně, například při změně poskytovatele hostingu nebo novém softwaru. Smysl má krátké cvičení, při kterém se projde jeden scénář.
Existují vzory od BSI?
BSI se tématu nouzového řízení věnuje v rámci IT-Grundschutz a v BSI-Standardu 200-4 k řízení kontinuity činností (Business Continuity Management). Hodí se jako rámec; pro webové servery se vyplatí stručná, praktická verze.