# Zmena poskytovateľa hostingu po bezpečnostnom incidente: na čo dbať?

> Zmena hostingu po bezpečnostnom incidente: správne poradie krokov, zabezpečenie dôkazov, presun len čistých dát a preverenie nového poskytovateľa.

Zdroj: https://phpsos.de/sk/blog/hoster-wechseln-nach-vorfall/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**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

1. **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](https://phpsos.de/sk/blog/beweise-sichern-vor-neuinstallation/).
2. **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ť.
3. **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](https://phpsos.de/sk/compliance/dsgvo-meldepflicht-72-stunden/).
4. **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.
5. **Prenášajte len preverené.** Kód z čistého zdroja, databázu a médiá po kontrole.
6. **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.
7. **Prepnite a sledujte.** Zmena DNS, potom nejaký čas užšie monitorovanie.
8. **Ukončite starú zmluvu.** Až keď sú logy a zálohy zabezpečené a nová prevádzka beží stabilne.

> **Dôležité:**
> 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](https://phpsos.de/sk/ratgeber/hoster-patch-status-erfragen/). 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?](https://phpsos.de/sk/blog/managed-oder-eigener-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](https://phpsos.de/sk/leistungen/incident-response/), 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.

## Zdroje

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [GDPR čl. 33: oznámenie dozornému orgánu](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [php.net: bezpečnostné hlásenia](https://www.php.net/)
