Pe scurt: Cine vrea să schimbe furnizorul de hosting după un incident de securitate ar trebui mai întâi să păstreze probele și să clarifice incidentul, apoi să transfere doar date verificate pe un sistem nou configurat și abia după aceea să încheie vechiul contract. Noul furnizor îl alegeți după criterii de securitate: fluxuri de patch dovedibile, separarea clienților, acces la loguri, backupuri și persoane de contact clare. O schimbare de furnizor este justificată când lipsesc încrederea sau performanța, dar nu înlocuiește curățarea.
Când încrederea s-a pierdut
După PHP2Shell, multe companii și-au văzut furnizorul de hosting pentru prima dată sub presiune. Unele au primit rapid o informație clară despre nivelul de patch. Altele au așteptat zile după un răspuns, au primit doar formule generale sau au constatat că site-ul lor rula pe o versiune PHP depășită. Dacă se adaugă și un incident, dorința de schimbare este de înțeles.
O schimbare de furnizor nu este însă un pas al gestionării incidentului, ci al reorganizării de după. Cine o face în ordinea greșită duce, în cel mai rău caz, atacatorul cu el și pierde totodată urmele care arată ce s-a întâmplat.
Ordinea corectă la schimbare
- Păstrați urmele cât timp există. Logurile, fișierele și baza de date ale vechiului sistem trebuie puse într-o copie de siguranță înainte de a șterge sau a rezilia ceva. Cereți vechiului furnizor în mod explicit logurile de acces și de erori începând din 20 octombrie 2026 și perioada lor de păstrare. Cum procedați descrie articolul Păstrați probele înainte de reinstalare.
- Delimitați incidentul. Ce sisteme sunt afectate, ce accesuri au fost folosite, ce date erau accesibile? De aceasta depind obligațiile de notificare și întrebarea ce aveți voie să luați cu dumneavoastră.
- Verificați obligațiile de notificare. Dacă pot fi afectate date cu caracter personal, termenul pentru o eventuală notificare RGPD începe odată cu luarea la cunoștință a incidentului, nu odată cu mutarea. Context găsiți la Obligația de notificare RGPD: 72 de ore.
- Construiți curat noul sistem. Versiune PHP acceptată, pachete actuale, configurație securizată, înainte de a transfera primul fișier.
- Transferați doar ce a fost verificat. Cod dintr-o sursă curată, baza de date și fișierele media după control.
- Schimbați toate datele de acces. Baza de date, conturile de administrator, SSH, FTP, cheile API, inclusiv cele din fișierele de configurare.
- Comutați și observați. Schimbarea DNS, apoi, o vreme, o monitorizare mai atentă.
- Încheiați vechiul contract. Abia când logurile și copiile de siguranță sunt păstrate, iar noua exploatare rulează stabil.
Nu reziliați vechiul contract înainte de a avea în mână logurile și copiile de siguranță. Odată cu sfârșitul contractului, furnizorul poate șterge date de care aveți nevoie pentru asigurători, autorități sau propria investigare.
Ce nu ar trebui să luați cu dumneavoastră
Ar fi comod să copiați pur și simplu întregul director web sau o imagine a serverului. Exact acest lucru este riscant după un incident. Webshell-urile se deghizează în fișiere inofensive, ușile din spate se ascund în fișiere de configurare precum .htaccess sau .user.ini, iar codul introdus poate sta în conținutul bazei de date.
Transferați de aceea codul aplicației dintr-o sursă curată, de exemplu pachetul producătorului în versiunea potrivită sau sistemul dumneavoastră de control al versiunilor. Fișierele media le preluați fără fișiere executabile, baza de date după un control pentru conținut suspect și conturi noi de administrator. Ceea ce s-a găsit pe vechiul sistem ajută la acest control.
Gândiți-vă și la tot ce se află lângă site la vechiul furnizor. Căsuțele de e-mail, înregistrările DNS, certificatele și redirecționările se uită ușor la mutare. Reduceți durata de valabilitate a înregistrărilor DNS cu câteva zile înainte de comutare, pentru ca schimbarea să ajungă repede la vizitatori. Dacă și e-mailurile se mută, planificați separat schimbarea căsuțelor, deoarece și acolo pot fi afectate datele de acces după un incident.
Alegerea noului furnizor după securitate
Prețul și spațiul de stocare apar în orice ofertă. Întrebările de securitate decisive trebuie de obicei să le puneți dumneavoastră. Lista următoare ajută la comparație:
| Criteriu | Întrebare către furnizor | De ce contează |
|---|---|---|
| Flux de patch | Cum și în ce cadru sunt aplicate și repornite actualizările de securitate PHP? | PHP2Shell a arătat cât de important este un flux dovedibil |
| Dovadă | Primesc la cerere o confirmare scrisă a nivelului de patch? | Bază pentru propria documentație |
| Versiuni PHP | Ce ramuri sunt oferite și cât timp încă? | Ramurile vechi fără actualizări sunt un risc permanent |
| Separare | Fiecare site rulează cu utilizator propriu și proces PHP propriu? | Limitează daunele dacă un vecin este atacat |
| Loguri | Am acces la logurile de acces și de erori, cât timp sunt păstrate? | Fără loguri nu există clarificare |
| Backupuri | Cât de des, cât timp, separat de serverul web, cu test de restaurare? | Restaurarea după un incident |
| Contact de urgență | Cum ajung la o persoană competentă în caz de incident? | Timpul este factorul cel mai limitat într-un caz grav |
| Prelucrare în numele operatorului | Există un contract conform RGPD și o listă a subcontractanților? | Obligatoriu pentru datele cu caracter personal |
Un model pentru întrebarea despre nivelul de patch oferă ghidul Întrebați furnizorul de hosting despre starea patchului. El este potrivit și pentru compararea furnizorilor înainte de încheierea contractului.
Este un alt model de operare răspunsul mai bun?
Uneori problema ține mai puțin de furnizorul de hosting și mai mult de modelul de operare. Cine operează un server propriu fără întreținere regulată este adesea mai bine servit de o ofertă managed bine îngrijită. Invers, o companie cu IT propriu poate câștiga mai mult control asupra momentelor de patch dacă administrează singură. Evaluarea o descrie articolul Hosting managed sau server propriu?.
Indiferent de model, valabil este: consemnați în scris împărțirea sarcinilor. Cine aplică actualizările PHP, cine repornește, cine verifică aplicația, cine se anunță la cine în caz de urgență? La PHP2Shell multe întârzieri au apărut exact aici, pentru că fiecare parte credea că cealaltă se ocupă.
Cum ajută PHP SOS concret?
- Păstrăm logurile și datele vechiului sistem și clarificăm ce s-a întâmplat în incident.
- Construim noul sistem securizat și transferăm doar conținut verificat din surse curate.
- Verificăm ofertele noilor furnizori pe baza criteriilor de securitate și punem întrebările potrivite.
- La un incident în desfășurare lucrăm în cadrul răspunsului la incidente, până când incidentul este încheiat și documentat.
Întrebări frecvente
Ar trebui să schimb imediat furnizorul de hosting după un atac?
Nu imediat. Mai întâi trebuie păstrate urmele, delimitat incidentul și clarificată cauza. O mutare grăbită poate duce cu ea codul malițios și poate distruge probe la vechiul furnizor.
A fost vina furnizorului de hosting dacă site-ul meu a fost atacat prin PHP2Shell?
Depinde de contract și de momentul atacului. La shared hosting, de actualizările PHP răspunde de obicei furnizorul, la serverele proprii operatorul. Patchurile au apărut pe 21 octombrie 2026; dacă și când au fost aplicate se poate clarifica doar cu dovezi. Pentru întrebările de răspundere apelați la consultanță juridică.
Ce date am voie să iau la noul furnizor?
Doar conținut verificat: baza de date după controlul pentru cod introdus, fișiere media fără fișiere executabile și cod dintr-o sursă curată, precum pachetul producătorului sau sistemul dumneavoastră de control al versiunilor. Imaginile complete de server sau directoarele web de pe sistemul compromis nu ar trebui transferate neverificate.
Trebuie să implic protecția datelor după un incident?
Dacă pot fi afectate date cu caracter personal, poate exista o obligație de notificare conform RGPD, de regulă în 72 de ore. La noul furnizor aveți nevoie, în plus, de un contract de prelucrare în numele operatorului. Clarificați aceasta cu responsabilul dumneavoastră cu protecția datelor; aceasta nu este consultanță juridică.