Pe scurt: Un plan de urgență IT pentru serverele web stabilește în prealabil cine decide în caz grav, pe cine puteți contacta, ce sisteme pot fi afectate și ce pași urmează în ce ordine. Cine vrea să întocmească un plan de urgență IT nu are nevoie de un manual gros, ci de câteva pagini actuale, accesibile și fără IT funcțional. Situația din jurul PHP2Shell este un bun prilej să faceți acest lucru acum.
De ce un plan de urgență economisește timp și daune
În caz grav, primele ore se pierd adesea căutând: cine are acces la hoster? Unde sunt copiile de siguranță? Cine decide dacă magazinul trece offline? Cine trebuie informat? Un plan de urgență răspunde la aceste întrebări în prealabil, în liniște.
PHP2Shell a arătat cât de scurt poate fi timpul. Pe 20.10.2026, php.net a anunțat patchurile, pe 21.10. la ora 16:00 ora Germaniei au fost publicate, iar BSI a recomandat actualizarea imediată sau oprirea temporară. Companiile cu plan știau pe cine să sune și ce servere să verifice. Altele au trebuit să afle mai întâi unde rulează de fapt PHP.
Întocmirea unui plan de urgență IT: componentele
Un plan practic pentru serverele web cuprinde aceste părți:
1. Roluri și decizii. Cine conduce în caz de urgență, cine îl înlocuiește, cine are voie să oprească sisteme, cine vorbește în exterior? Consemnați numele și înlocuitorii.
2. Lista de contacte. Interlocutori interni, hoster, agenție, prestator IT, responsabil cu protecția datelor, consultanță juridică, asigurare cyber cu numărul poliței, autoritatea de supraveghere competentă pentru protecția datelor, Zentrale Ansprechstelle Cybercrime (punctul central de contact pentru criminalitate cibernetică al poliției) din landul dumneavoastră. Această listă trebuie să existe tipărită.
3. Inventarul sistemelor. Fiecare site, fiecare magazin și fiecare portal, cu server, hoster, mod de operare, versiune PHP, aplicație, responsabil și tipul datelor prelucrate.
4. Reguli de decizie. În ce condiții scoatem un sistem din rețea? Cine are voie să decidă? Ce se aplică noaptea și în weekend?
5. Procese. Secvențe scurte de pași pentru cazuri tipice: vulnerabilitate critică cunoscută, suspiciune de intruziune, site desfigurat, date scurse, șantaj.
6. Căi de notificare. Cine verifică o obligație de notificare conform art. 33 RGPD, dacă este posibil în 72 de ore de la luarea la cunoștință? Cine notifică la BSI în caz de obligație NIS2? Cine informează asigurătorul?
7. Restabilirea. Unde se află copiile de siguranță, cine le poate restaura, cât durează și când au fost testate ultima dată?
Exemplu: procesul „vulnerabilitate PHP critică”
Iată cum poate arăta un proces, așa cum a fost necesar la PHP2Shell:
| Pas | Cine | Rezultat |
|---|---|---|
| Evaluarea anunțului (php.net, BSI) | Responsabilii IT | sisteme afectate conform inventarului |
| Instalarea actualizării, repornirea tuturor workerilor | Administrator sau prestator | Dovadă cu starea pachetelor și ora proceselor |
| Unde nu este posibilă actualizarea: măsuri provizorii sau scoatere din rețea | Decide conducerea | Decizie documentată |
| Salvarea jurnalelor, verificarea urmelor | Administrator sau criminalistică | Constatare sau nicio constatare |
| În caz de constatare: pornirea procesului de incident | Conducerea situației de urgență | Verificarea căilor de notificare |
Important aici: un patch închide vulnerabilitatea, dar nu elimină programele malițioase introduse anterior. De aceea căutarea de urme aparține ferm procesului.
Stabiliți cât timp se păstrează jurnalele serverului web și unde se află ele în afara serverului. La PHP2Shell, presa de specialitate a recomandat păstrarea jurnalelor începând cu 20.10.2026. Cine păstrează jurnalele doar câteva zile nu poate aplica astfel de recomandări.
Prevenția care face planul eficient
Un plan este la fel de bun ca premisele din spatele lui. Verificați dacă există copii de siguranță după regula 3-2-1 și dacă sunt testate, vezi Copii de siguranță după regula 3-2-1. Clarificați în scris cu hosterul și cu agenția cine preia ce în caz de vulnerabilități critice. Păstrați datele de acces pentru urgențe în siguranță, dar accesibile, de exemplu într-un seif de parole protejat, cu acces de urgență.
Pregătiți în plus șabloane de text: informare internă, mesaj către clienți, indicație pe o pagină statică de mentenanță. Indicații găsiți la Comunicarea de criză după un atac.
Exersați și mențineți planul actual
Un plan care nu a fost niciodată exersat conține aproape întotdeauna lacune. Parcurgeți o dată pe an un scenariu, de exemplu „vulnerabilitate PHP critică vineri după-amiază”, și notați unde apar blocaje. Un test simplu este suficient pentru început: poate o a doua persoană, fără ajutorul primeia, să contacteze hosterul, să restaureze o copie de siguranță și să treacă site-ul în modul de mentenanță? Dacă nu, ceva lipsește din plan, de obicei un acces, un număr de telefon sau o descriere. Exact astfel de lacune trebuie să le facă vizibile exercițiile, înainte ca situația să devină gravă. Actualizați planul după fiecare exercițiu și după fiecare modificare importantă. Drept cadru metodic se potrivesc IT-Grundschutz de la BSI și standardul BSI 200-4 privind managementul continuității afacerii.
Întrebările juridice, de exemplu cele privind obligațiile de notificare, nu sunt clarificate definitiv de plan. El asigură că persoanele potrivite sunt implicate la timp. Această pagină este informare generală și nu constituie consultanță juridică.
Cum ajută PHP SOS concret?
- Întocmim împreună cu dumneavoastră inventarul sistemelor serverelor dumneavoastră web, inclusiv modul de operare și versiunea PHP.
- Redactăm procesele tehnice pentru scenarii tipice și le coordonăm cu hosterul și cu agenția.
- Efectuăm un exercițiu și integrăm constatările în plan.
- În caz grav preluăm partea tehnică prin răspunsul la incidente, la cerere asigurat printr-un contract de mentenanță de securitate.
Întrebări frecvente
Cât de amplu trebuie să fie un plan de urgență IT?
Cât mai scurt posibil, cât de detaliat este necesar. Pentru serverele web sunt adesea suficiente câteva pagini cu contacte, lista sistemelor, reguli de decizie și procese. Mai important decât volumul este ca planul să fie actual și să poată fi găsit în caz grav.
Unde păstrez planul de urgență?
Cel puțin într-un loc accesibil și fără IT funcțional, de exemplu tipărit sau pe un dispozitiv separat. Un plan care se află doar pe serverul afectat sau în rețeaua blocată a firmei nu ajută în caz grav.
Cât de des ar trebui verificat planul?
Cel puțin o dată pe an și după fiecare modificare importantă, de exemplu schimbarea hosterului sau software nou. Este utilă un scurt exercițiu în care se parcurge un scenariu.
Există modele de la BSI?
BSI (Oficiul Federal German pentru Securitatea Informațiilor) tratează managementul situațiilor de urgență în cadrul IT-Grundschutz și în standardul BSI 200-4 privind managementul continuității afacerii (Business Continuity Management). Acestea se potrivesc drept cadru; pentru serverele web merită o variantă concisă, apropiată de practică.