Īsi: IT ārkārtas plāns tīmekļa serveriem iepriekš nosaka, kas nopietnā gadījumā lemj, ko var sasniegt, kuras sistēmas var būt skartas un kādi soļi seko kādā secībā. Kas vēlas izveidot IT ārkārtas plānu, tam nevajag biezu rokasgrāmatu, bet dažas aktuālas lappuses, kas pieejamas arī bez funkcionējošas IT. Situācija ap PHP2Shell ir labs iemesls to izdarīt tagad.
Kāpēc ārkārtas plāns ietaupa laiku un zaudējumus
Nopietnā gadījumā pirmās stundas bieži zūd meklējot: kam ir piekļuve hostinga sniedzējam? Kur atrodas rezerves kopijas? Kurš lemj, vai veikals tiek atvienots? Kas jāinformē? Ārkārtas plāns uz šiem jautājumiem atbild iepriekš, mierīgi.
PHP2Shell parādīja, cik īss var būt laiks. 2026. gada 20. oktobrī php.net paziņoja par ielāpiem, 21. oktobrī plkst. 16:00 Vācijas laiks tie tika publicēti, un BSI ieteica nekavējoties atjaunināt vai uz laiku atslēgt. Uzņēmumi ar plānu zināja, kam zvanīt un kurus serverus pārbaudīt. Citiem vispirms bija jānoskaidro, kur vispār darbojas PHP.
IT ārkārtas plāna izveide: sastāvdaļas
Praksē noderīgs plāns tīmekļa serveriem ietver šīs daļas:
1. Lomas un lēmumi. Kas vada ārkārtas gadījumā, kas aizvieto, kam atļauts sistēmas izslēgt, kas runā uz āru? Fiksējiet vārdus un aizvietojumus.
2. Kontaktu saraksts. Iekšējās kontaktpersonas, hostinga sniedzējs, aģentūra, IT pakalpojumu sniedzējs, datu aizsardzības speciālists, juridiskā konsultācija, kiberapdrošināšana ar apdrošināšanas numuru, kompetentā datu aizsardzības uzraudzības iestāde, jūsu federālās zemes Kibernoziegumu centrālais kontaktpunkts. Šim sarakstam jābūt izdrukātam.
3. Sistēmu inventārs. Katra vietne, veikals un portāls ar serveri, hostinga sniedzēju, darbības režīmu, PHP versiju, lietojumprogrammu, atbildīgo un apstrādāto datu veidu.
4. Lēmumu noteikumi. Kādos apstākļos mēs sistēmu atvienojam no tīkla? Kam to atļauts lemt? Kas ir spēkā naktī un nedēļas nogalē?
5. Norises. Īstas soļu secības tipiskiem gadījumiem: zināma kritiska ievainojamība, aizdomas par ielaušanos, izkropļota vietne, datu aizplūšana, šantāža.
6. Ziņošanas ceļi. Kas pārbauda ziņošanas pienākumu saskaņā ar VDAR 33. pantu, iespējami 72 stundu laikā no brīža, kad kļuvis zināms? Kas ziņo BSI NIS2 pienākuma gadījumā? Kas informē apdrošinātāju?
7. Atjaunošana. Kur atrodas rezerves kopijas, kas tās var atjaunot, cik tas ilgst, kad tas pēdējoreiz pārbaudīts?
Piemērs: norise „kritiska PHP ievainojamība“
Tā var izskatīties norise, kāda bija vajadzīga PHP2Shell gadījumā:
| Solis | Kas | Rezultāts |
|---|---|---|
| Novērtēt paziņojumu (php.net, BSI) | IT atbildīgie | skartās sistēmas pēc inventāra |
| Ieinstalēt atjauninājumu, pārstartēt visus worker | Administrators vai pakalpojumu sniedzējs | Pierādījums ar pakotņu stāvokli un procesa laiku |
| Kur atjauninājums nav iespējams: pagaidu pasākumi vai atvienot no tīkla | Lemj vadība | dokumentēts lēmums |
| Saglabāt žurnālus, pārbaudīt pēdas | Administrators vai forensika | atradums vai nav atradumu |
| Atradumu gadījumā: sākt incidenta norisi | Ārkārtas vadība | pārbaudīt ziņošanas ceļus |
Svarīgi pie tā: ielāps aizver ievainojamību, taču nenoņem iepriekš ievadītu ļaunprātīgu programmatūru. Tāpēc pēdu meklēšanai jābūt norises sastāvdaļai.
Nosakiet, cik ilgi tīmekļa servera žurnāli tiek glabāti un kur tie atrodas ārpus servera. PHP2Shell gadījumā speciālistu prese ieteica žurnālus glabāt no 2026. gada 20. oktobra. Kas žurnālus patur tikai dažas dienas, tas šādus ieteikumus īstenot nevar.
Sagatavotība, kas plānu padara efektīvu
Plāns ir tik labs, cik tā priekšnoteikumi. Pārbaudiet, vai ir rezerves kopijas pēc 3-2-1 noteikuma un vai tās ir pārbaudītas, skatiet Rezerves kopijas pēc 3-2-1 noteikuma. Rakstiski noskaidrojiet ar hostinga sniedzēju un aģentūru, kurš kritisku ievainojamību gadījumā ko uzņemas. Piekļuves datus ārkārtas gadījumiem glabājiet droši, bet sasniedzami, piemēram, aizsargātā paroļu glabātuvē ar ārkārtas piekļuvi.
Sagatavojiet arī teksta veidnes: iekšējā informācija, klientu paziņojums, norāde statiskā uzturēšanas lapā. Norādes par to atrodamas lapā Krīzes komunikācija pēc uzbrukuma.
Trenēt un uzturēt aktuālu
Plānā, kas nekad nav trenēts, gandrīz vienmēr ir nepilnības. Reizi gadā izspēlējiet scenāriju, piemēram, „kritiska PHP ievainojamība piektdienas pēcpusdienā“, un pierakstiet, kur ķeras. Sākumam pietiek ar vienkāršu testu: vai otrs cilvēks bez pirmā palīdzības var sasniegt hostinga sniedzēju, atjaunot rezerves kopiju un pārslēgt vietni uzturēšanas režīmā? Ja nē, plānā kaut kā trūkst, parasti piekļuves, tālruņa numura vai apraksta. Tieši šādas nepilnības treniņiem jāatklāj, pirms kļūst nopietni. Atjauniniet plānu pēc katra treniņa un katras būtiskas izmaiņas. Kā metodisks ietvars der BSI IT-Grundschutz un standarts BSI-Standard 200-4 par darbības nepārtrauktības pārvaldību.
Tiesiskus jautājumus, piemēram, par ziņošanas pienākumiem, plāns galīgi neizlemj. Tas nodrošina, ka īstās personas tiek iesaistītas laikus. Šī lapa ir vispārīga informācija, nevis juridiska konsultācija.
Kā PHP SOS palīdz konkrēti?
- Mēs kopā ar jums izveidojam jūsu tīmekļa serveru sistēmu inventāru, ieskaitot darbības režīmu un PHP versiju.
- Mēs uzrakstām tehniskās norises tipiskiem scenārijiem un saskaņojam tās ar hostinga sniedzēju un aģentūru.
- Mēs veicam treniņu un atziņas iestrādājam plānā.
- Nopietnā gadījumā mēs uzņemamies tehnisko pusi ar Incident Response, pēc vēlēšanās nodrošinātu ar drošības uzturēšanas līgumu.
Biežāk uzdotie jautājumi
Cik apjomīgam jābūt IT ārkārtas plānam?
Pēc iespējas īsam, tik izsmeļošam, cik nepieciešams. Tīmekļa serveriem bieži pietiek ar dažām lappusēm ar kontaktiem, sistēmu sarakstu, lēmumu noteikumiem un norisēm. Svarīgāk par apjomu ir tas, lai plāns ir aktuāls un nopietnā gadījumā atrodams.
Kur glabāt ārkārtas plānu?
Vismaz vienā vietā, kas pieejama arī bez funkcionējošas IT, piemēram, izdrukāts vai atsevišķā ierīcē. Plāns, kas atrodas tikai skartajā serverī vai bloķētā uzņēmuma tīklā, nopietnā gadījumā nepalīdz.
Cik bieži plāns jāpārbauda?
Vismaz reizi gadā un pēc katras būtiskas izmaiņas, piemēram, hostinga sniedzēja maiņas vai jaunas programmatūras. Lietderīgs ir īss treniņš, kurā tiek izspēlēts scenārijs.
Vai BSI ir veidnes?
BSI ārkārtas pārvaldību aplūko IT-Grundschutz ietvaros un standartā BSI-Standard 200-4 par darbības nepārtrauktības pārvaldību (Business Continuity Management). Tie der kā ietvars; tīmekļa serveriem vērts izveidot kodolīgu, praksei tuvu versiju.