Ukratko: IT plan za hitne slučajeve za web-poslužitelje unaprijed određuje tko u kriznom slučaju odlučuje, koga se može dobiti, koji sustavi mogu biti pogođeni i koji koraci slijede kojim redoslijedom. Tko želi izraditi IT plan za hitne slučajeve, ne treba debeli priručnik, nego nekoliko aktualnih stranica koje su dostupne i bez ispravnog IT-a. Situacija oko PHP2Shella dobar je povod da se to učini sada.
Zašto plan za hitne slučajeve štedi vrijeme i štetu
U kriznom slučaju prvi sati često odlaze na traženje: tko ima pristup pružatelju hostinga? Gdje su sigurnosne kopije? Tko odlučuje hoće li shop biti isključen? Koga treba obavijestiti? Plan za hitne slučajeve odgovara na ta pitanja unaprijed, u miru.
PHP2Shell je pokazao koliko vremena može biti malo. Dana 20. 10. 2026. php.net je najavio zakrpe, 21. 10. u 16:00 po njemačkom vremenu objavljene su, a BSI je preporučio trenutačno ažuriranje ili privremeno isključivanje. Tvrtke s planom znale su koga nazvati i koje poslužitelje provjeriti. Druge su najprije morale otkriti gdje uopće radi PHP.
Izrada IT plana za hitne slučajeve: gradivni elementi
Praktičan plan za web-poslužitelje obuhvaća ove dijelove:
1. Uloge i odluke. Tko u hitnom slučaju vodi, tko zamjenjuje, tko smije isključiti sustave, tko govori prema van? Zabilježite imena i zamjene.
2. Popis kontakata. Interni kontakti, pružatelj hostinga, agencija, IT pružatelj usluga, službenik za zaštitu podataka, pravno savjetovanje, kibernetičko osiguranje s brojem police, nadležno nadzorno tijelo za zaštitu podataka, središnja kontaktna točka za kibernetički kriminal (Zentrale Ansprechstelle Cybercrime) Vaše savezne zemlje. Taj popis mora postojati ispisan.
3. Popis sustava. Svaka web-stranica, svaki shop i svaki portal s poslužiteljem, pružateljem hostinga, načinom rada, PHP verzijom, aplikacijom, odgovornom osobom i vrstom obrađivanih podataka.
4. Pravila odlučivanja. Pod kojim uvjetima sustav odvajamo s mreže? Tko to smije odlučiti? Što vrijedi noću i vikendom?
5. Postupci. Kratki nizovi koraka za tipične slučajeve: poznata kritična ranjivost, sumnja na provalu, unakažena web-stranica, odljev podataka, iznuda.
6. Putovi prijave. Tko provjerava obvezu prijave prema čl. 33. GDPR-a, ako je moguće u roku od 72 sata od saznanja? Tko prijavljuje BSI-ju kod obveze prema NIS2? Tko informira osiguravatelja?
7. Ponovna uspostava. Gdje su sigurnosne kopije, tko ih može vratiti, koliko to traje, kada je to zadnji put testirano?
Primjer: postupak „kritična PHP ranjivost“
Ovako može izgledati postupak kakav je bio potreban kod PHP2Shella:
| Korak | Tko | Rezultat |
|---|---|---|
| Procijeniti obavijest (php.net, BSI) | IT odgovorni | pogođeni sustavi prema popisu |
| Instalirati ažuriranje, ponovno pokrenuti sve workere | administrator ili pružatelj usluga | dokaz stanjem paketa i vremenom procesa |
| Gdje ažuriranje nije moguće: privremene mjere ili s mreže | uprava odlučuje | dokumentirana odluka |
| Osigurati zapisnike, provjeriti tragove | administrator ili forenzika | nalaz ili bez nalaza |
| Kod nalaza: pokrenuti postupak za incident | voditelj kriznog tima | provjeriti putove prijave |
Važno pritom: zakrpa zatvara ranjivost, ali ne uklanja zlonamjerni softver ubačen prije. Zato potraga za tragovima čvrsto spada u postupak.
Odredite koliko se dugo čuvaju zapisnici web-poslužitelja i gdje se nalaze izvan poslužitelja. Kod PHP2Shella stručni tisak preporučivao je čuvanje zapisnika od 20. 10. 2026. Tko zapisnike drži samo nekoliko dana, ne može provesti takve preporuke.
Prevencija koja plan tek čini djelotvornim
Plan je dobar koliko i preduvjeti iza njega. Provjerite postoje li sigurnosne kopije prema pravilu 3-2-1 i jesu li testirane, vidi Sigurnosne kopije prema pravilu 3-2-1. S pružateljem hostinga i agencijom pisanim putem razjasnite tko što preuzima kod kritičnih ranjivosti. Pristupne podatke za hitne slučajeve držite sigurno, ali dostupno, primjerice u zaštićenom trezoru lozinki s hitnim pristupom.
Pripremite i tekstualne predloške: interna informacija, obavijest klijentima, napomena na statičnoj stranici o održavanju. Napomene su u članku Krizna komunikacija nakon napada.
Vježbati i držati aktualnim
Plan koji nikad nije vježban gotovo uvijek sadrži praznine. Jednom godišnje odigrajte jedan scenarij, primjerice „kritična PHP ranjivost u petak poslijepodne“, i zabilježite gdje zapinje. Za početak je dovoljan jednostavan test: može li druga osoba bez pomoći prve doći do pružatelja hostinga, vratiti sigurnosnu kopiju i web-stranicu prebaciti u način održavanja? Ako ne, u planu nešto nedostaje, najčešće pristup, telefonski broj ili opis. Upravo takve praznine vježbe trebaju učiniti vidljivima prije nego što postane ozbiljno. Plan ažurirajte nakon svake vježbe i svake bitne promjene. Kao metodološki okvir prikladni su IT-Grundschutz BSI-ja i BSI-Standard 200-4 o upravljanju kontinuitetom poslovanja.
Pravna pitanja, primjerice o obvezama prijave, plan ne razjašnjava konačno. Brine se da se pravi ljudi uključe na vrijeme. Ova stranica je opća informacija, a ne pravni savjet.
Kako PHP SOS konkretno pomaže?
- S Vama izrađujemo popis sustava Vaših web-poslužitelja, uključujući način rada i PHP verziju.
- Pišemo tehničke postupke za tipične scenarije i usklađujemo ih s pružateljem hostinga i agencijom.
- Provodimo vježbu i saznanja ugrađujemo u plan.
- U kriznom slučaju preuzimamo tehničku stranu putem odgovora na incidente, na zahtjev osiguranu ugovorom o sigurnosnom održavanju.
Česta pitanja
Koliko opsežan mora biti IT plan za hitne slučajeve?
Što kraći, a koliko je potrebno opsežan. Za web-poslužitelje često je dovoljno nekoliko stranica s kontaktima, popisom sustava, pravilima odlučivanja i postupcima. Važnije od opsega je da je aktualan i da se u kriznom slučaju može pronaći.
Gdje čuvam plan za hitne slučajeve?
Na barem jednom mjestu dostupnom i bez ispravnog IT-a, primjerice ispisan ili na odvojenom uređaju. Plan koji leži samo na pogođenom poslužitelju ili u zaključanoj mreži tvrtke ne pomaže u kriznom slučaju.
Koliko često plan treba provjeravati?
Najmanje jednom godišnje i nakon svake bitne promjene, primjerice promjene pružatelja hostinga ili novog softvera. Smislena je kratka vježba u kojoj se odigra jedan scenarij.
Postoje li predlošci BSI-ja?
BSI (njemački Savezni ured za informacijsku sigurnost) obrađuje upravljanje u hitnim slučajevima u okviru IT-Grundschutza i u BSI-Standardu 200-4 o upravljanju kontinuitetom poslovanja. Oni su prikladni kao okvir; za web-poslužitelje isplati se sažeta, praktična inačica.