Stručně: Kdo chce po bezpečnostním incidentu změnit hostera, měl by nejprve zajistit důkazy a incident objasnit, pak přenést jen prověřená data na nově nasazený systém a teprve poté ukončit starou smlouvu. Nového poskytovatele vybírejte podle bezpečnostních kritérií: doložitelné postupy záplatování, oddělení zákazníků, přístup k logům, zálohy a jasné kontaktní osoby. Změna hostera dává smysl, když chybí důvěra nebo výkon, ale nenahrazuje vyčištění.
Když je důvěra pryč
Po PHP2Shell zažívá mnoho firem svého hostera poprvé pod tlakem. Někteří rychle dostali jasnou informaci o stavu záplat. Jiní čekali dny na odpověď, dostávali jen obecné formulky, nebo zjistili, že jejich web běžel na zastaralé verzi PHP. Když k tomu přijde ještě incident, je přání změnit poskytovatele pochopitelné.
Změna hostera ale není krokem při zvládání incidentu, nýbrž přestavbou po něm. Kdo ji zařadí do špatného pořadí, v nejhorším případě přenese útočníka s sebou a zároveň přijde o stopy, které ukazují, co se stalo.
Správné pořadí při změně
- Zajistěte stopy, dokud existují. Logy, soubory a databáze starého systému patří do zálohy dříve, než se cokoli smaže nebo vypoví. Zeptejte se starého hostera výslovně na přístupové a chybové logy od 20. října 2026 a na dobu jejich uchování. Jak postupovat, popisuje článek Zajistěte důkazy před novou instalací.
- Vymezte incident. Které systémy jsou dotčeny, jaké přístupy byly použity, jaká data byla dosažitelná? Závisí na tom oznamovací povinnosti i otázka, co smíte přenést.
- Prověřte oznamovací povinnosti. Mohou-li být dotčeny osobní údaje, začíná lhůta pro případné oznámení podle GDPR okamžikem, kdy se o incidentu dozvíte, nikoli stěhováním. Souvislosti najdete na stránce Oznamovací povinnost podle GDPR: 72 hodin.
- Nový systém postavte čistě. Podporovaná verze PHP, aktuální balíčky, zabezpečená konfigurace, než se přenese první soubor.
- Přenášejte jen prověřené. Kód z čistého zdroje, databáze a média po kontrole.
- Vyměňte všechny přístupové údaje. Databáze, účty správců, SSH, FTP, klíče API, i ty v konfiguračních souborech.
- Přepněte a sledujte. Změna DNS, poté po určitou dobu přísnější monitoring.
- Ukončete starou smlouvu. Až když jsou logy a zálohy zajištěny a nový provoz stabilně běží.
Starou smlouvu nevypovídejte, dokud nemáte logy a zálohy v ruce. Se skončením smlouvy mohou být u poskytovatele smazána data, která potřebujete pro pojišťovnu, úřady nebo vlastní objasnění.
Co byste neměli přenášet
Pohodlné by bylo prostě zkopírovat celý webový adresář nebo obraz serveru. Právě to je po incidentu riziková volba. Webshelly se maskují jako neškodné soubory, zadní vrátka se skrývají v konfiguračních souborech jako .htaccess nebo .user.ini a vložený kód může ležet v obsahu databáze.
Aplikační kód proto přenášejte z čistého zdroje, například z balíčku výrobce v odpovídající verzi nebo ze svého systému správy verzí. Média přebírejte bez spustitelných souborů, databázi po kontrole na nápadný obsah a nové účty správců. Co se našlo na starém systému, pomáhá při této kontrole.
Myslete také na vše, co leží u starého poskytovatele vedle webu. E-mailové schránky, záznamy DNS, certifikáty a přesměrování se při stěhování snadno zapomenou. Zkraťte dobu platnosti záznamů DNS několik dní před přepnutím, aby se změna rychle dostala k návštěvníkům. Stěhují-li se i e-maily, naplánujte přechod schránek zvlášť, protože i tam mohou být po incidentu dotčeny přístupové údaje.
Nového hostera vybrat podle bezpečnosti
Cena a úložný prostor jsou v každé nabídce. Rozhodující bezpečnostní otázky musíte většinou položit sami. Následující seznam pomáhá při srovnání:
| Kritérium | Otázka na poskytovatele | Proč na tom záleží |
|---|---|---|
| Postup záplatování | Jak a v jakém rámci se nasazují a restartují bezpečnostní aktualizace PHP? | PHP2Shell ukázalo, jak důležitý je doložitelný postup |
| Důkaz | Dostanu na vyžádání písemné potvrzení stavu záplat? | Podklad pro vaši vlastní dokumentaci |
| Verze PHP | Které větve se nabízejí a jak dlouho ještě? | Staré větve bez aktualizací jsou trvalé riziko |
| Oddělení | Běží každý web pod vlastním uživatelem a s vlastním procesem PHP? | Omezí škody, když je napaden soused |
| Logy | Mám přístup k přístupovým a chybovým logům a jak dlouho se uchovávají? | Bez logů žádné objasnění |
| Zálohy | Jak často, jak dlouho, odděleně od webového serveru, s testem obnovy? | Obnova po incidentu |
| Nouzový kontakt | Jak při incidentu zastihnu odborně způsobilou osobu? | Čas je v krizi nejvzácnější |
| Zpracování osobních údajů | Existuje smlouva podle GDPR a seznam dalších zpracovatelů? | Povinnost u osobních údajů |
Vzor pro otázku na stav záplat nabízí průvodce Zeptejte se hostera na stav záplat. Hodí se i k porovnání poskytovatelů před uzavřením smlouvy.
Je lepší odpovědí jiný provozní model?
Někdy leží problém méně u hostera než v provozním modelu. Kdo provozuje vlastní server bez pravidelné péče, bývá lépe zaopatřen dobře spravovanou nabídkou managed. Naopak firma s vlastním IT může získat větší kontrolu nad okamžikem nasazení záplat, když spravuje sama. Zvážení popisuje článek Managed hosting, nebo vlastní server?.
Bez ohledu na model platí: rozdělení úkolů mějte písemně. Kdo nasazuje aktualizace PHP, kdo restartuje, kdo kontroluje aplikaci, kdo koho kontaktuje v nouzi? U PHP2Shell vznikla mnohá zpoždění právě tady, protože každá strana myslela, že se o to stará ta druhá.
Jak konkrétně pomáhá PHP SOS?
- Zajistíme logy a data starého systému a objasníme, co se při incidentu stalo.
- Nový systém postavíme zabezpečený a přeneseme jen prověřený obsah z čistých zdrojů.
- Nabídky nových poskytovatelů posoudíme podle bezpečnostních kritérií a položíme správné otázky.
- Při probíhajícím incidentu pracujeme v rámci naší Incident Response, dokud není incident uzavřen a zdokumentován.
Časté dotazy
Mám po napadení okamžitě změnit hostera?
Ne hned. Nejprve je třeba zajistit stopy, vymezit incident a objasnit příčinu. Ukvapené stěhování může přenést škodlivý kód a zničit důkazy u původního poskytovatele.
Byl host vinen, když byl můj web napaden přes PHP2Shell?
Záleží na smlouvě a na časovém okamžiku. U sdíleného hostingu za aktualizace PHP zpravidla odpovídá hoster, u vlastních serverů provozovatel. Záplaty vyšly 21. října 2026; zda a kdy byly nasazeny, lze objasnit jen doklady. Pro otázky odpovědnosti se obraťte na právního poradce.
Která data smím přenést k novému hosterovi?
Jen prověřený obsah: databázi po kontrole na vložený kód, média bez spustitelných souborů a kód z čistého zdroje, například z balíčku výrobce nebo ze systému správy verzí. Kompletní obrazy serveru nebo webové adresáře z kompromitovaného systému byste neměli přenášet bez kontroly.
Musím po incidentu zapojit ochranu osobních údajů?
Mohou-li být dotčeny osobní údaje, může existovat oznamovací povinnost podle GDPR, zpravidla do 72 hodin. U nového hostera navíc potřebujete smlouvu o zpracování osobních údajů. Ujasněte si to s pověřencem pro ochranu osobních údajů; nejde o právní poradenství.