Röviden: Egy webszerverekre vonatkozó IT-vészhelyzeti terv előre rögzíti, ki dönt éles helyzetben, kit lehet elérni, mely rendszerek lehetnek érintettek, és mely lépések követik egymást milyen sorrendben. Aki IT-vészhelyzeti tervet akar készíteni, nem vastag kézikönyvre van szüksége, hanem néhány, naprakész oldalra, amely működő IT nélkül is elérhető. A PHP2Shell körüli helyzet jó alkalom arra, hogy ezt most megtegye.
Miért takarít meg a vészhelyzeti terv időt és kárt
Éles helyzetben az első órák gyakran keresgéléssel mennek el: kinek van hozzáférése a tárhelyszolgáltatóhoz? Hol vannak a mentések? Ki dönti el, hogy a webshop offline állapotba kerül-e? Kit kell tájékoztatni? A vészhelyzeti terv ezeket a kérdéseket előre, nyugodtan megválaszolja.
A PHP2Shell megmutatta, milyen rövid lehet az idő. 2026. október 20-án a php.net bejelentette a javításokat, október 21-én német idő szerint 16 órakor közzétették őket, és a BSI (a német Szövetségi Információbiztonsági Hivatal) azonnali frissítést vagy ideiglenes leállítást ajánlott. A tervvel rendelkező vállalkozások tudták, kit hívjanak, és mely szervereket kell ellenőrizniük. Mások előbb ki kellett deríteniük, hol fut egyáltalán PHP.
IT-vészhelyzeti terv készítése: az építőkockák
Egy gyakorlatban használható terv webszerverekhez ezeket a részeket tartalmazza:
1. Szerepek és döntések. Ki vezet vészhelyzetben, ki helyettesít, ki állíthat le rendszereket, ki beszél kifelé? Rögzítse a neveket és a helyettesítéseket.
2. Kapcsolattartó-lista. Belső kapcsolattartók, tárhelyszolgáltató, ügynökség, IT-szolgáltató, adatvédelmi tisztviselő, jogi tanácsadás, kiberbiztosítás a biztosítási számmal, illetékes adatvédelmi felügyeleti hatóság, a szövetségi tartománya Zentrale Ansprechstelle Cybercrime (ZAC, központi kiberbűnözési kapcsolattartó pont) szervezete. Ennek a listának kinyomtatva rendelkezésre kell állnia.
3. Rendszerleltár. Minden weboldal, webshop és portál a szerverrel, a tárhelyszolgáltatóval, az üzemmóddal, a PHP-verzióval, az alkalmazással, a felelőssel és a feldolgozott adatok fajtájával.
4. Döntési szabályok. Mely feltételek mellett vesszük le a hálózatról a rendszert? Ki döntheti ezt el? Mi érvényes éjjel és hétvégén?
5. Folyamatok. Rövid lépéssorok tipikus esetekre: kritikus rés ismertté vált, betörés gyanúja, a weboldalt elcsúfították, adatok szivárogtak ki, zsarolás.
6. Bejelentési utak. Ki vizsgálja a GDPR 33. cikke szerinti bejelentési kötelezettséget, lehetőleg a tudomásszerzéstől számított 72 órán belül? Ki jelent be NIS2-kötelezettség esetén a BSI-nek? Ki tájékoztatja a biztosítót?
7. Helyreállítás. Hol vannak a mentések, ki tudja visszatölteni őket, mennyi ideig tart, mikor tesztelték utoljára?
Példa: a „kritikus PHP-rés” folyamata
Így nézhet ki egy folyamat, amilyenre a PHP2Shellnél szükség volt:
| Lépés | Ki | Eredmény |
|---|---|---|
| A közlemény értékelése (php.net, BSI) | IT-felelősök | az érintett rendszerek a leltár szerint |
| Frissítés telepítése, az összes worker újraindítása | Admin vagy szolgáltató | Igazolás csomagállapottal és folyamatidővel |
| Ahol frissítés nem lehetséges: átmeneti intézkedések vagy leválasztás a hálózatról | A vezetés dönt | dokumentált döntés |
| Naplók mentése, nyomok ellenőrzése | Admin vagy forenzika | lelet vagy nincs lelet |
| Lelet esetén: az incidensfolyamat indítása | Vészhelyzeti vezetés | a bejelentési utak ellenőrzése |
Fontos ehhez: a javítás bezárja a rést, de nem távolítja el a korábban bejuttatott kártevőt. Ezért a nyomkeresés szilárdan a folyamat része.
Rögzítse, mennyi ideig őrzik a webszerver-naplókat, és hol vannak a szerveren kívül. A PHP2Shellnél a szakmai sajtó azt javasolta, hogy a naplókat 2026. október 20-tól őrizzék meg. Aki a naplókat csak néhány napig tartja meg, az ilyen ajánlásokat nem tudja megvalósítani.
Előrelátás, amely a tervet hatásossá teszi
Egy terv annyit ér, mint a mögötte álló feltételek. Ellenőrizze, hogy vannak-e a 3-2-1 szabály szerinti, tesztelt mentések, lásd Mentések a 3-2-1 szabály szerint. Tisztázza írásban a tárhelyszolgáltatóval és az ügynökséggel, ki mit vállal át kritikus réseknél. A hozzáférési adatokat vészhelyzetekre tartsa biztonságosan, de elérhetően, például egy védett jelszókezelő széfben vészhozzáféréssel.
Készítsen elő emellett szövegsablonokat: belső tájékoztatás, ügyfél-közlemény, tájékoztatás egy statikus karbantartási oldalon. Ehhez útmutatás a következő oldalon van: Kríziskommunikáció egy támadás után.
Gyakorlás és naprakészen tartás
Az a terv, amelyet soha nem gyakoroltak, szinte mindig hézagos. Évente egyszer játsszon végig egy forgatókönyvet, például „kritikus PHP-rés pénteken délután”, és jegyezze fel, hol akad el. Elején egy egyszerű teszt elég: el tudja-e érni egy második személy az első segítsége nélkül a tárhelyszolgáltatót, vissza tud-e tölteni egy mentést, és karbantartási módba tudja-e helyezni a weboldalt? Ha nem, hiányzik valami a tervből, többnyire egy hozzáférés, egy telefonszám vagy egy leírás. Éppen az ilyen hézagokat kell a gyakorlatoknak láthatóvá tenniük, mielőtt komolyra fordul a dolog. Frissítse a tervet minden gyakorlat és minden lényeges változás után. Módszertani keretként a BSI IT-Grundschutz és az üzletmenet-folytonossági menedzsmentről szóló 200-4 BSI-standard alkalmas.
A jogi kérdéseket, például a bejelentési kötelezettségeket, a terv nem tisztázza véglegesen. Azt biztosítja, hogy a megfelelő személyeket időben bevonják. Ez az oldal általános tájékoztatás és nem jogi tanácsadás.
Hogyan segít konkrétan a PHP SOS?
- Önnel együtt elkészítjük a webszervereinek rendszerleltárát az üzemmóddal és a PHP-verzióval együtt.
- Megírjuk a műszaki folyamatokat tipikus forgatókönyvekre, és egyeztetjük őket a tárhelyszolgáltatóval és az ügynökséggel.
- Gyakorlatot tartunk, és a tanulságokat beépítjük a tervbe.
- Éles helyzetben az Incident Response keretében átvesszük a műszaki oldalt, kérésre biztonsági karbantartási szerződéssel biztosítva.
Gyakori kérdések
Mennyire terjedelmes legyen egy IT-vészhelyzeti terv?
Olyan rövid, amennyire lehet, olyan részletes, amennyire kell. Webszerverekhez gyakran elég néhány oldal a kapcsolattartókkal, a rendszerlistával, a döntési szabályokkal és a folyamatokkal. A terjedelemnél fontosabb, hogy naprakész legyen, és éles helyzetben megtalálják.
Hol őrizzem a vészhelyzeti tervet?
Legalább egy olyan helyen, amely működő IT nélkül is elérhető, például kinyomtatva vagy egy különálló eszközön. Egy olyan terv, amely csak az érintett szerveren vagy a lezárt céges hálózaton van, éles helyzetben nem segít.
Milyen gyakran kell ellenőrizni a tervet?
Legalább évente egyszer és minden lényeges változás után, például a tárhelyszolgáltató váltásakor vagy új szoftver bevezetésekor. Értelmes egy rövid gyakorlat, amelyben egy forgatókönyvet végigjátszanak.
Vannak sablonok a BSI-től?
A BSI az IT-Grundschutz (német IT-alapvédelem) keretében és az üzletmenet-folytonossági menedzsmentről (Business Continuity Management) szóló 200-4 BSI-standardban foglalkozik a vészhelyzeti menedzsmenttel. Ezek keretként alkalmasak; webszerverekhez érdemes egy tömör, gyakorlatias változat.