Trumpai: IT avarinis planas žiniatinklio serveriams iš anksto nustato, kas kritiniu atveju sprendžia, ką galima pasiekti, kurios sistemos gali būti paveiktos ir kokie žingsniai seka kokia tvarka. Kas nori sudaryti IT avarinį planą, nepaisant to nereikia storo vadovo, o tik kelių aktualių puslapių, pasiekiamų ir be veikiančios IT. PHP2Shell padėtis yra geras pretekstas tai padaryti dabar.
Kodėl avarinis planas taupo laiką ir žalą
Kritiniu atveju pirmosios valandos dažnai prarandamos ieškant: kas turi prieigą prie hostingo teikėjo? Kur yra atsarginės kopijos? Kas sprendžia, ar parduotuvė bus atjungta? Ką reikia informuoti? Avarinis planas atsako į šiuos klausimus iš anksto, ramiai.
PHP2Shell parodė, kaip trumpas gali būti laikas. 2026-10-20 php.net paskelbė apie pataisas, 10-21 16 val. Vokietijos laiku jos buvo išleistos, o BSI (Vokietijos Federalinė informacijos saugumo tarnyba) rekomendavo nedelsiant atnaujinti arba laikinai išjungti. Įmonės su planu žinojo, kam skambinti ir kuriuos serverius tikrinti. Kitoms pirmiausia reikėjo išsiaiškinti, kur apskritai veikia PHP.
IT avarinio plano sudarymas: sudedamosios dalys
Praktiškas planas žiniatinklio serveriams apima šias dalis:
1. Vaidmenys ir sprendimai. Kas vadovauja kritiniu atveju, kas pavaduoja, kas gali išjungti sistemas, kas kalba išorėje? Užfiksuokite vardus ir pavaduotojus.
2. Kontaktų sąrašas. Vidiniai kontaktiniai asmenys, hostingo teikėjas, agentūra, IT paslaugų teikėjas, duomenų apsaugos pareigūnas, teisinė konsultacija, kibernetinis draudikas su draudimo numeriu, kompetentinga duomenų apsaugos priežiūros institucija, jūsų federalinės žemės Zentrale Ansprechstelle Cybercrime (centrinis kibernetinių nusikaltimų kontaktinis punktas). Šis sąrašas turi būti atspausdintas.
3. Sistemų inventorius. Kiekviena svetainė, parduotuvė ir portalas su serveriu, hostingo teikėju, veikimo režimu, PHP versija, programa, atsakingu asmeniu ir tvarkomų duomenų rūšimi.
4. Sprendimų taisyklės. Kokiomis sąlygomis sistemą atjungiame nuo tinklo? Kas gali tai nuspręsti? Kas galioja naktį ir savaitgalį?
5. Eiga. Trumpos žingsnių sekos tipiniams atvejams: žinomas kritinis pažeidžiamumas, įsilaužimo įtarimas, svetainė iškraipyta, duomenys nutekėjo, šantažas.
6. Pranešimo keliai. Kas vertina pranešimo pareigą pagal BDAR 33 straipsnį, jei įmanoma, per 72 valandas nuo sužinojimo? Kas praneša BSI esant NIS2 pareigai? Kas informuoja draudiką?
7. Atkūrimas. Kur yra atsarginės kopijos, kas gali jas atkurti, kiek tai trunka, kada tai paskutinį kartą buvo išbandyta?
Pavyzdys: eiga „kritinis PHP pažeidžiamumas“
Štai kaip gali atrodyti eiga, kokios prireikė PHP2Shell atveju:
| Žingsnis | Kas | Rezultatas |
|---|---|---|
| Įvertinti pranešimą (php.net, BSI) | IT atsakingi asmenys | paveiktos sistemos pagal inventorių |
| Įdiegti atnaujinimą, iš naujo paleisti visus worker | Administratorius arba paslaugų teikėjas | įrodymas su paketų būsena ir procesų laiku |
| Kur atnaujinimas neįmanomas: pereinamosios priemonės arba atjungti nuo tinklo | Sprendžia vadovybė | dokumentuotas sprendimas |
| Išsaugoti žurnalus, tikrinti pėdsakus | Administratorius arba forensika | radinys arba be radinio |
| Esant radiniui: paleisti incidento eigą | Avarinė vadovybė | patikrinti pranešimo kelius |
Svarbu: pataisa uždaro pažeidžiamumą, bet nepašalina anksčiau įterptos kenkėjiškos programinės įrangos. Todėl pėdsakų paieška turi tvirtai priklausyti eigai.
Nustatykite, kiek laiko saugomi žiniatinklio serverio žurnalai ir kur jie yra ne serveryje. Dėl PHP2Shell specializuota spauda rekomendavo saugoti žurnalus nuo 2026-10-20. Kas žurnalus laiko tik kelias dienas, tokių rekomendacijų įgyvendinti negali.
Prevencija, dėl kurios planas apskritai veikia
Planas yra tiek geras, kiek jo pagrindas. Patikrinkite, ar yra ir ar išbandytos atsarginės kopijos pagal 3-2-1 taisyklę, žr. Atsarginės kopijos pagal 3-2-1 taisyklę. Raštu su hostingo teikėju ir agentūra išsiaiškinkite, kas ką perima kritinių pažeidžiamumų atveju. Prieigos duomenis avariniams atvejams laikykite saugiai, bet pasiekiamai, pavyzdžiui, apsaugotoje slaptažodžių saugykloje su avarine prieiga.
Be to, parenkite tekstų šablonus: vidinę informaciją, klientų pranešimą, pranešimą statiniame priežiūros puslapyje. Nurodymus rasite puslapyje Krizių komunikacija po atakos.
Pratybos ir aktualumo išlaikymas
Planas, kuris niekada nebuvo išbandytas, beveik visada turi spragų. Kartą per metus išbandykite scenarijų, pavyzdžiui, „kritinis PHP pažeidžiamumas penktadienio popietę“, ir užsirašykite, kur strigo. Pradžiai pakanka paprasto testo: ar antras asmuo be pirmojo pagalbos gali pasiekti hostingo teikėją, atkurti atsarginę kopiją ir perjungti svetainę į priežiūros režimą? Jei ne, plane kažko trūksta, dažniausiai prieigos, telefono numerio ar aprašymo. Būtent tokias spragas pratybos turi parodyti, kol dar nėra rimta. Planą atnaujinkite po kiekvienų pratybų ir po kiekvieno esminio pakeitimo. Metodiniu pagrindu tinka BSI (Vokietijos Federalinė informacijos saugumo tarnyba) IT-Grundschutz ir BSI-Standard 200-4 dėl verslo tęstinumo valdymo.
Teisinių klausimų, pavyzdžiui, dėl pranešimo pareigų, planas galutinai neišsprendžia. Jis pasirūpina, kad tinkami asmenys būtų laiku įtraukti. Šis puslapis yra bendra informacija, o ne teisinė konsultacija.
Kaip PHP SOS padeda konkrečiai?
- Kartu su jumis sudarome jūsų žiniatinklio serverių sistemų inventorių, įskaitant veikimo režimą ir PHP versiją.
- Parašome technines eigas tipiniams scenarijams ir suderiname jas su hostingo teikėju ir agentūra.
- Atliekame pratybas ir įžvalgas įtraukiame į planą.
- Kritiniu atveju technine puse rūpinamės per incidentų valdymą, pageidaujant užtikrintą saugumo priežiūros sutartimi.
Dažni klausimai
Kokios apimties turi būti IT avarinis planas?
Kuo trumpesnis, tiek išsamus, kiek būtina. Žiniatinklio serveriams dažnai pakanka kelių puslapių su kontaktais, sistemų sąrašu, sprendimų taisyklėmis ir eiga. Svarbiau už apimtį, kad jis būtų aktualus ir kritiniu atveju surandamas.
Kur laikyti avarinį planą?
Bent vienoje vietoje, kuri pasiekiama ir be veikiančios IT, pavyzdžiui, atspausdintas arba atskirame įrenginyje. Planas, esantis tik paveiktame serveryje ar užrakintame įmonės tinkle, kritiniu atveju nepadeda.
Kaip dažnai planą reikia tikrinti?
Bent kartą per metus ir po kiekvieno esminio pakeitimo, pavyzdžiui, pakeitus hostingo teikėją ar įdiegus naują programinę įrangą. Prasminga trumpa pratyba, kurios metu išbandomas scenarijus.
Ar BSI turi šablonų?
BSI avarinį valdymą nagrinėja IT-Grundschutz ir BSI-Standard 200-4 dėl verslo tęstinumo valdymo (Business Continuity Management). Jie tinka kaip pagrindas; žiniatinklio serveriams verta trumpos, praktiškos versijos.