Lühidalt: Veebiserverite IT-hädaolukorra plaan määrab ette, kes tõsisel hetkel otsustab, keda kätte saab, millised süsteemid võivad olla mõjutatud ja millised sammud millises järjekorras järgnevad. Kes tahab IT-hädaolukorra plaani koostada, ei vaja paksu käsiraamatut, vaid mõnda ajakohast lehekülge, mis on kättesaadavad ka ilma töötava IT-ta. PHP2Shelli olukord on hea põhjus seda nüüd teha.
Miks hädaolukorra plaan säästab aega ja kahju
Tõsisel hetkel kulub esimene paar tundi sageli otsimisele: kellel on juurdepääs majutajale? Kus asuvad varukoopiad? Kes otsustab, kas pood läheb võrgust maha? Keda tuleb teavitada? Hädaolukorra plaan vastab neile küsimustele ette, rahulikult.
PHP2Shell on näidanud, kui lühike võib aeg olla. 20.10.2026 teatas php.net paikadest, 21.10. kell 16 Saksamaa aja järgi need avaldati ja BSI soovitas kohest uuendust või ajutist väljalülitamist. Plaaniga ettevõtted teadsid, kellele helistada ja milliseid servereid kontrollida. Teised pidid kõigepealt välja selgitama, kus PHP üldse töötab.
IT-hädaolukorra plaani koostamine: ehituskivid
Praktiline plaan veebiserverite jaoks sisaldab neid osi:
1. Rollid ja otsused. Kes juhib hädaolukorras, kes asendab, kes tohib süsteeme välja lülitada, kes räägib väljapoole? Pange kirja nimed ja asendajad.
2. Kontaktide loend. Sisemised kontaktisikud, majutaja, agentuur, IT-teenusepakkuja, andmekaitsespetsialist, õigusnõustaja, küberkindlustus koos kindlustusnumbriga, pädev andmekaitse järelevalveasutus, teie liidumaa küberkuritegevuse kesksed kontaktpunktid (ZAC). See loend peab olema väljaprinditult olemas.
3. Süsteemide inventar. Iga veebisait, pood ja portaal koos serveri, majutaja, töörežiimi, PHP versiooni, rakenduse, vastutaja ja töödeldavate andmete liigiga.
4. Otsustusreeglid. Millistel tingimustel võtame süsteemi võrgust maha? Kes tohib seda otsustada? Mis kehtib öösel ja nädalavahetusel?
5. Käigud. Lühikesed sammujärjestused tüüpiliste juhtumite jaoks: kriitiline turvaauk teada, sissemurdmise kahtlus, veebisait moonutatud, andmed välja voolanud, väljapressimine.
6. Teavitamisteed. Kes kontrollib teavitamiskohustust IKÜM art 33 järgi, võimaluse korral 72 tunni jooksul pärast teadasaamist? Kes teavitab NIS2 kohustuse korral BSI-d? Kes teavitab kindlustajat?
7. Taastamine. Kus asuvad varukoopiad, kes oskab neid tagasi mängida, kui kaua see võtab, millal seda viimati testiti?
Näide: käik „kriitiline PHP turvaauk“
Nii võib välja näha käik, mida PHP2Shelli puhul vaja oli:
| Samm | Kes | Tulemus |
|---|---|---|
| Hinnata teadet (php.net, BSI) | IT-vastutajad | mõjutatud süsteemid inventari järgi |
| Paigaldada uuendus, käivitada kõik tööprotsessid uuesti | Administraator või teenusepakkuja | Tõend paketi seisu ja protsessi ajaga |
| Kus uuendus pole võimalik: ajutised meetmed või võrgust maha | Juhtkond otsustab | dokumenteeritud otsus |
| Kindlustada logid, kontrollida jälgi | Administraator või forensika | leid või leid puudub |
| Leiu korral: käivitada intsidendi käik | Hädaolukorra juht | kontrollida teavitamisteid |
Oluline on: paik sulgeb turvaaugu, kuid ei eemalda varem sisse toodud pahavara. Seetõttu kuulub jälgede otsimine kindlalt käigu juurde.
Pange paika, kui kaua veebiserveri logisid säilitatakse ja kus need väljaspool serverit asuvad. PHP2Shelli puhul soovitas erialaajakirjandus logisid säilitada alates 20.10.2026. Kes hoiab logisid vaid mõne päeva, ei saa selliseid soovitusi ellu viia.
Ennetus, mis plaani tegelikult mõjusaks teeb
Plaan on nii hea kui selle taga olevad eeldused. Kontrollige, kas varukoopiad 3-2-1 reegli järgi on olemas ja testitud, vt Varukoopiad 3-2-1 reegli järgi. Selgitage majutaja ja agentuuriga kirjalikult, kes mida kriitiliste turvaaukude korral üle võtab. Hoidke hädaolukorra ligipääsuandmeid turvaliselt, kuid kättesaadavalt, näiteks kaitstud paroolihoidlas koos hädaolukorra juurdepääsuga.
Valmistage lisaks ette tekstimallid: sisemine teave, klienditeade, märkus staatilisel hooldusleheküljel. Näpunäited leiate lehelt Kriisikommunikatsioon pärast rünnakut.
Harjutage ja hoidke ajakohasena
Plaan, mida pole kunagi harjutatud, sisaldab peaaegu alati lünki. Mängige kord aastas läbi mõni stsenaarium, näiteks „kriitiline PHP turvaauk reede pärastlõunal“, ja märkige üles, kus on takistusi. Alustuseks piisab lihtsast testist: kas teine inimene saab esimese abita majutajaga ühendust, varukoopia tagasi mängida ja veebisaidi hooldusrežiimi viia? Kui mitte, puudub plaanist midagi, enamasti juurdepääs, telefoninumber või kirjeldus. Just selliseid lünki peavad õppused nähtavaks tegema, enne kui läheb tõsiseks. Ajakohastage plaani pärast iga õppust ja iga olulist muudatust. Metoodilise raamistikuna sobivad BSI IT-baaskaitse (IT-Grundschutz) ja BSI standard 200-4 tegevuse jätkuvuse juhtimise kohta.
Õiguslikke küsimusi, näiteks teavitamiskohustuste kohta, plaan ammendavalt ei selgita. Ta hoolitseb selle eest, et õiged inimesed kaasatakse õigel ajal. See leht on üldine teave ja ei ole õigusnõustamine.
Kuidas PHP SOS konkreetselt aitab?
- Koostame koos teiega teie veebiserverite süsteemide inventari, sealhulgas töörežiimi ja PHP versiooni.
- Kirjutame tehnilised käigud tüüpiliste stsenaariumide jaoks ja kooskõlastame need majutaja ja agentuuriga.
- Viime läbi õppuse ja töötame saadud teadmised plaani sisse.
- Tõsisel hetkel võtame tehnilise poole üle intsidendile reageerimise kaudu, soovi korral kindlustatuna turvahoolduslepinguga.
Korduma kippuvad küsimused
Kui mahukas peab IT-hädaolukorra plaan olema?
Nii lühike kui võimalik, nii üksikasjalik kui vaja. Veebiserverite jaoks piisab sageli mõnest leheküljest kontaktide, süsteemide loendi, otsustusreeglite ja käikudega. Olulisem kui maht on, et plaan oleks ajakohane ja tõsisel hetkel leitav.
Kus ma hädaolukorra plaani hoian?
Vähemalt ühes kohas, mis on kättesaadav ka ilma töötava IT-ta, näiteks väljaprinditult või eraldi seadmes. Plaan, mis asub ainult mõjutatud serveris või lukustatud ettevõtte võrgus, ei aita tõsisel hetkel.
Kui tihti peaks plaani kontrollima?
Vähemalt kord aastas ja pärast iga olulist muudatust, näiteks majutaja vahetust või uut tarkvara. Mõistlik on lühike õppus, kus stsenaarium läbi mängitakse.
Kas BSI-l on malle?
BSI käsitleb hädaolukorra juhtimist IT-baaskaitse (IT-Grundschutz) raames ja BSI standardis 200-4 tegevuse jätkuvuse juhtimise kohta. Need sobivad raamistikuks; veebiserverite jaoks tasub koostada napp, praktiline versioon.