Stručne: Kto chce po bezpečnostnom incidente zmeniť poskytovateľa hostingu, mal by najprv zabezpečiť dôkazy a objasniť incident, potom preniesť len preverené dáta na novo nasadený systém a až potom ukončiť starú zmluvu. Nového poskytovateľa vyberajte podľa bezpečnostných kritérií: doložiteľné postupy záplatovania, oddelenie zákazníkov, prístup k logom, zálohy a jasné kontaktné osoby. Zmena poskytovateľa hostingu je zmysluplná, ak chýba dôvera alebo výkon, nenahrádza však čistenie.
Keď dôvera zmizne
Po PHP2Shell zažilo mnoho firiem svojho poskytovateľa hostingu prvýkrát pod tlakom. Niektoré dostali rýchlo jasnú informáciu o stave záplat. Iné čakali na odpoveď dni, dostali len všeobecné frázy alebo zistili, že ich web beží na zastaranej verzii PHP. Ak k tomu pribudne ešte incident, je túžba po zmene pochopiteľná.
Zmena poskytovateľa hostingu však nie je krokom zvládania incidentu, ale nového nastavenia po ňom. Kto ju zaradí v nesprávnom poradí, prenesie v najhoršom prípade so sebou útočníka a súčasne príde o stopy, ktoré ukazujú, čo sa stalo.
Správne poradie pri zmene
- Zabezpečte stopy, kým sú k dispozícii. Logy, súbory a databáza starého systému patria do zálohy ešte predtým, než sa niečo zmaže alebo vypovie. Opýtajte sa starého poskytovateľa výslovne na prístupové logy a chybové logy od 20. októbra 2026 a na dobu ich uchovávania. Ako postupovať, opisuje článok Zabezpečte dôkazy skôr, než systém nasadíte nanovo.
- Ohraničte incident. Ktoré systémy sú zasiahnuté, ktoré prístupy sa použili, ktoré dáta boli dosiahnuteľné? Od toho závisia oznamovacie povinnosti a otázka, čo smiete preniesť.
- Skontrolujte oznamovacie povinnosti. Ak môže ísť o osobné údaje, lehota na prípadné oznámenie podľa GDPR začína plynúť okamihom, keď sa o incidente dozviete, nie presunom. Súvislosti sú v článku Oznamovacia povinnosť podľa GDPR: 72 hodín.
- Nový systém postavte čisto. Podporovaná verzia PHP, aktuálne balíky, zabezpečená konfigurácia, ešte predtým, než sa prenesie prvý súbor.
- Prenášajte len preverené. Kód z čistého zdroja, databázu a médiá po kontrole.
- Zmeňte všetky prístupové údaje. Databáza, administrátorské účty, SSH, FTP, kľúče API, aj tie v konfiguračných súboroch.
- Prepnite a sledujte. Zmena DNS, potom nejaký čas užšie monitorovanie.
- Ukončite starú zmluvu. Až keď sú logy a zálohy zabezpečené a nová prevádzka beží stabilne.
Starú zmluvu nevypovedajte skôr, než budete mať logy a zálohy v rukách. S koncom zmluvy môže poskytovateľ zmazať dáta, ktoré potrebujete pre poisťovateľa, úrady alebo vlastné objasnenie.
Čo by ste nemali preberať
Pohodlné by bolo jednoducho skopírovať celý webový adresár alebo obraz servera. Presne to je po incidente riskantné. Webshelly sa maskujú ako neškodné súbory, zadné vrátka sa ukrývajú v konfiguračných súboroch, ako .htaccess alebo .user.ini, a votrelecký kód môže ležať v obsahu databázy.
Kód aplikácie preto prenášajte z čistého zdroja, napríklad z balíka od výrobcu v zodpovedajúcej verzii alebo z vášho systému správy verzií. Médiá preberte bez spustiteľných súborov, databázu po kontrole na nápadný obsah a nové administrátorské účty. Pri tejto kontrole pomôže to, čo sa našlo na starom systéme.
Myslite aj na všetko, čo leží u starého poskytovateľa popri webe. E-mailové schránky, záznamy DNS, certifikáty a presmerovania sa pri presune ľahko zabudnú. Skráťte platnosť záznamov DNS niekoľko dní pred prepnutím, aby sa zmena rýchlo dostala k návštevníkom. Ak sa sťahujú aj e-maily, naplánujte zmenu schránok osobitne, pretože aj tam môžu byť po incidente zasiahnuté prístupové údaje.
Nového poskytovateľa hostingu vyberajte podľa bezpečnosti
Cena a diskový priestor sú v každej ponuke. Rozhodujúce bezpečnostné otázky musíte spravidla položiť sami. Nasledujúci zoznam pomáha pri porovnaní:
| Kritérium | Otázka pre poskytovateľa | Prečo na tom záleží |
|---|---|---|
| Postup záplatovania | Ako a v akom rámci sa nasadzujú a reštartujú bezpečnostné aktualizácie PHP? | PHP2Shell ukázal, aké dôležité je doložiteľné postupovanie |
| Doklad | Dostanem na požiadanie písomné potvrdenie o stave záplat? | Základ pre vašu vlastnú dokumentáciu |
| Verzie PHP | Ktoré vetvy sa ponúkajú a ako dlho ešte? | Staré vetvy bez aktualizácií sú trvalé riziko |
| Oddelenie | Beží každý web s vlastným používateľom a vlastným procesom PHP? | Obmedzuje škody, keď je napadnutý sused |
| Logy | Mám prístup k prístupovým logom a chybovým logom, ako dlho sa uchovávajú? | Bez logov niet objasnenia |
| Zálohy | Ako často, ako dlho, oddelene od webového servera, s testom obnovy? | Obnova po incidente |
| Núdzový kontakt | Ako sa pri incidente dostanem k odborne zdatnej osobe? | Čas je v krízovej situácii najvzácnejším faktorom |
| Spracovanie v mene prevádzkovateľa | Existuje zmluva podľa GDPR a zoznam subdodávateľov? | Povinnosť pri osobných údajoch |
Vzor otázky na stav záplat ponúka sprievodca Ako sa opýtať poskytovateľa hostingu na stav záplat. Hodí sa aj na porovnanie poskytovateľov ešte pred uzavretím zmluvy.
Je lepšou odpoveďou iný model prevádzky?
Niekedy problém nie je ani tak v poskytovateľovi hostingu, ako v modeli prevádzky. Kto prevádzkuje vlastný server bez pravidelnej údržby, je často lepšie zaopatrený s dobre spravovanou ponukou managed. Naopak firma s vlastným IT môže získať väčšiu kontrolu nad časmi záplatovania, ak si server spravuje sama. Porovnanie opisuje článok Managed hosting alebo vlastný server?.
Bez ohľadu na model platí: rozdelenie úloh si zafixujte písomne. Kto nasadzuje aktualizácie PHP, kto reštartuje, kto kontroluje aplikáciu, kto sa v núdzi komu ozve? Pri PHP2Shell vznikli mnohé oneskorenia presne v tomto bode, pretože každá strana myslela, že sa o to stará tá druhá.
Ako konkrétne pomáha PHP SOS?
- Zabezpečíme logy a dáta starého systému a objasníme, čo sa pri incidente stalo.
- Nový systém postavíme zabezpečený a prenesieme len preverený obsah z čistých zdrojov.
- Ponuky nových poskytovateľov preveríme podľa bezpečnostných kritérií a položíme správne otázky.
- Pri prebiehajúcom incidente pracujeme v rámci našej služby reakcie na incidenty, kým nie je incident uzavretý a zdokumentovaný.
Časté otázky
Mal by som po hacku okamžite zmeniť poskytovateľa hostingu?
Nie okamžite. Najprv treba zabezpečiť stopy, ohraničiť incident a objasniť príčinu. Unáhlený presun môže preniesť škodlivý kód a zničiť dôkazy u pôvodného poskytovateľa.
Bol poskytovateľ hostingu vinný, ak bol môj web napadnutý cez PHP2Shell?
Záleží od zmluvy a od času. Pri zdieľanom hostingu zodpovedá za aktualizácie PHP spravidla poskytovateľ, pri vlastných serveroch prevádzkovateľ. Záplaty vyšli 21. októbra 2026; či a kedy boli nasadené, sa dá objasniť len na základe dokladov. Pri otázkach zodpovednosti sa poraďte s advokátom.
Aké dáta môžem preniesť k novému poskytovateľovi hostingu?
Len preverený obsah: databázu po kontrole na votrelecký kód, médiá bez spustiteľných súborov a kód z čistého zdroja, ako je balík od výrobcu alebo váš systém správy verzií. Kompletné obrazy servera alebo webové adresáre z kompromitovaného systému by ste nemali prenášať bez kontroly.
Musím po incidente zapojiť ochranu údajov?
Ak môže ísť o osobné údaje, môže existovať oznamovacia povinnosť podľa GDPR, spravidla do 72 hodín. U nového poskytovateľa hostingu navyše potrebujete zmluvu o spracovaní osobných údajov. Vyjasnite to so svojím zodpovedným pracovníkom pre ochranu údajov; nejde o právne poradenstvo.