Stručne: IT núdzový plán pre webservery vopred určí, kto v kritickom prípade rozhoduje, koho možno zastihnúť, ktoré systémy môžu byť dotknuté a aké kroky nasledujú v akom poradí. Kto chce vypracovať IT núdzový plán, nepotrebuje hrubú príručku, ale niekoľko aktuálnych strán, ktoré sú dostupné aj bez fungujúcej IT. Situácia okolo PHP2Shell je dobrým dôvodom urobiť to teraz.
Prečo núdzový plán šetrí čas a škodu
V kritickom prípade sa prvé hodiny často stratia hľadaním: Kto má prístup k poskytovateľovi hostingu? Kde ležia zálohy? Kto rozhoduje, či obchod pôjde offline? Koho treba informovať? Núdzový plán odpovedá na tieto otázky vopred, v pokoji.
PHP2Shell ukázalo, aký krátky môže byť čas. Dňa 20. 10. 2026 php.net oznámil záplaty, 21. 10. o 16:00 nemeckého času boli zverejnené a BSI odporučilo okamžitú aktualizáciu alebo dočasné vypnutie. Firmy s plánom vedeli, komu zavolať a ktoré servery skontrolovať. Iné museli najprv zistiť, kde PHP vôbec beží.
Vypracovanie IT núdzového plánu: stavebné kamene
Praktický plán pre webservery zahŕňa tieto časti:
1. Úlohy a rozhodnutia. Kto v núdzi vedie, kto zastupuje, kto smie systémy vypnúť, kto hovorí navonok? Zaznamenajte mená a zástupcov.
2. Zoznam kontaktov. Interné kontaktné osoby, poskytovateľ hostingu, agentúra, IT dodávateľ, zodpovedná osoba za ochranu údajov, právne poradenstvo, kybernetické poistenie s číslom poistky, príslušný dozorný orgán pre ochranu údajov, Zentrale Ansprechstelle Cybercrime (ZAC, centrálne kontaktné miesto pre kybernetickú kriminalitu) vašej spolkovej krajiny. Tento zoznam musí byť k dispozícii vytlačený.
3. Inventár systémov. Každý web, každý obchod a každý portál so serverom, poskytovateľom hostingu, režimom prevádzky, verziou PHP, aplikáciou, zodpovednou osobou a druhom spracúvaných údajov.
4. Pravidlá rozhodovania. Za akých podmienok systém odpojíme od siete? Kto o tom smie rozhodnúť? Čo platí v noci a cez víkend?
5. Postupy. Krátke sledy krokov pre typické prípady: známa kritická zraniteľnosť, podozrenie na vlámanie, zničený web, odliv údajov, vydieranie.
6. Cesty hlásenia. Kto posudzuje oznamovaciu povinnosť podľa čl. 33 GDPR, podľa možnosti do 72 hodín od okamihu, keď sa o tom dozviete? Kto hlási BSI pri povinnosti podľa NIS2? Kto informuje poisťovateľa?
7. Obnova. Kde ležia zálohy, kto ich vie obnoviť, ako dlho to trvá, kedy sa to naposledy testovalo?
Príklad: postup „kritická zraniteľnosť PHP“
Takto môže vyzerať postup, aký bol potrebný pri PHP2Shell:
| Krok | Kto | Výsledok |
|---|---|---|
| Posúdiť hlásenie (php.net, BSI) | Zodpovední za IT | dotknuté systémy podľa inventára |
| Nasadiť aktualizáciu, reštartovať všetkých workerov | Administrátor alebo dodávateľ | Dôkaz so stavom balíkov a časom procesu |
| Kde aktualizácia nie je možná: prechodné opatrenia alebo odpojenie od siete | Rozhoduje vedenie | zdokumentované rozhodnutie |
| Zabezpečiť logy, skontrolovať stopy | Administrátor alebo forenzná analýza | nález alebo žiadny nález |
| Pri náleze: spustiť postup pre incident | Vedenie núdzového riešenia | skontrolovať cesty hlásenia |
Dôležité pritom: Záplata uzavrie zraniteľnosť, ale neodstráni predtým zavlečený škodlivý softvér. Preto patrí hľadanie stôp pevne do postupu.
Určte, ako dlho sa uchovávajú logy webservera a kde ležia mimo servera. Pri PHP2Shell odborná tlač radila uchovať logy od 20. 10. 2026. Kto logy drží len niekoľko dní, také odporúčania nemôže uplatniť.
Prevencia, vďaka ktorej je plán účinný
Plán je len taký dobrý, aké sú predpoklady za ním. Skontrolujte, či existujú a sú otestované zálohy podľa pravidla 3-2-1, pozri Zálohy podľa pravidla 3-2-1. S poskytovateľom hostingu a agentúrou písomne vyjasnite, kto pri kritických zraniteľnostiach preberá čo. Prístupové údaje pre núdzové prípady uchovajte bezpečne, ale dostupne, napríklad v chránenom trezore hesiel s núdzovým prístupom.
Pripravte aj textové šablóny: interná informácia, oznámenie zákazníkom, upozornenie na statickej stránke údržby. Upozornenia k tomu nájdete na stránke Krízová komunikácia po útoku.
Cvičte a udržiavajte aktuálnosť
Plán, ktorý sa nikdy necvičil, takmer vždy obsahuje medzery. Raz za rok prejdite jeden scenár, napríklad „kritická zraniteľnosť PHP v piatok popoludní“, a poznačte si, kde to viazne. Na začiatok stačí jednoduchý test: Dokáže druhá osoba bez pomoci prvej zastihnúť poskytovateľa hostingu, obnoviť zálohu a prepnúť web do režimu údržby? Ak nie, v pláne niečo chýba, väčšinou prístup, telefónne číslo alebo opis. Práve také medzery majú cvičenia odhaliť skôr, než to bude vážne. Plán aktualizujte po každom cvičení a po každej podstatnej zmene. Ako metodický rámec sa hodia IT-Grundschutz od BSI a štandard BSI 200-4 o Business Continuity Management.
Právne otázky, napríklad o oznamovacích povinnostiach, plán konečne neuzavrie. Zabezpečí, aby boli správne osoby zapojené včas. Táto stránka je všeobecná informácia a nie právne poradenstvo.
Ako konkrétne pomáha PHP SOS?
- S vami vypracujeme inventár systémov vašich webserverov, vrátane režimu prevádzky a verzie PHP.
- Napíšeme technické postupy pre typické scenáre a dohodneme ich s poskytovateľom hostingu a agentúrou.
- Uskutočníme cvičenie a poznatky zapracujeme do plánu.
- V kritickom prípade preberáme technickú stránku cez reakciu na incident (Incident Response), na požiadanie zabezpečenú zmluvou o bezpečnostnej údržbe.
Časté otázky
Aký rozsiahly musí IT núdzový plán byť?
Čo najkratší, no podľa potreby podrobný. Pre webservery často stačí niekoľko strán s kontaktmi, zoznamom systémov, pravidlami rozhodovania a postupmi. Dôležitejšie než rozsah je to, aby bol aktuálny a v kritickom prípade sa našiel.
Kde núdzový plán uchovať?
Aspoň na jednom mieste, ktoré je dostupné aj bez fungujúcej IT, napríklad vytlačený alebo na oddelenom zariadení. Plán, ktorý leží iba na dotknutom serveri alebo v zablokovanej firemnej sieti, v kritickom prípade nepomôže.
Ako často by sa mal plán kontrolovať?
Aspoň raz za rok a po každej podstatnej zmene, napríklad pri zmene poskytovateľa hostingu alebo novom softvéri. Zmysel má krátke cvičenie, pri ktorom sa prejde jeden scenár.
Existujú vzory od BSI?
BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) rieši riadenie núdzových situácií v rámci IT-Grundschutz a v štandarde BSI 200-4 o Business Continuity Management. Hodia sa ako rámec; pre webservery sa oplatí stručná, praktická verzia.