# Promjena hostera nakon sigurnosnog incidenta: na što paziti?

> Promjena hostera nakon sigurnosnog incidenta: pravi redoslijed, osiguranje dokaza, selidba samo čistih podataka i ciljana provjera novog pružatelja.

Izvor: https://phpsos.de/hr/blog/hoster-wechseln-nach-vorfall/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Tko nakon sigurnosnog incidenta želi promijeniti hostera, trebao bi najprije osigurati dokaze i razjasniti incident, zatim na novo postavljen sustav prenijeti samo provjerene podatke i tek onda otkazati stari ugovor. Novog pružatelja birajte prema sigurnosnim kriterijima: dokazivi postupci zakrpanja, razdvajanje klijenata, pristup zapisnicima, sigurnosne kopije i jasne kontakt osobe. Promjena hostera ima smisla kad nedostaje povjerenja ili kvalitete usluge, ali ne zamjenjuje čišćenje.

## Kad povjerenja više nema

Nakon PHP2Shella mnoge tvrtke prvi put doživljavaju svog hostera pod pritiskom. Neke su brzo dobile jasnu informaciju o stanju zakrpe. Druge su danima čekale odgovor, dobile samo opće fraze ili utvrdile da je njihova web-stranica radila na zastarjeloj PHP verziji. Ako se tome pridoda još i incident, želja za promjenom je razumljiva.

Promjena hostera ipak nije korak rješavanja incidenta, nego novog početka nakon njega. Tko je stavi u pogrešan redoslijed, u najgorem slučaju sa sobom povlači napadača i istodobno gubi tragove koji pokazuju što se dogodilo.

## Pravi redoslijed pri promjeni

1. **Osigurati tragove dok postoje.** Zapisnici, datoteke i baza podataka starog sustava pripadaju u sigurnosnu kopiju prije nego što se nešto obriše ili otkaže. Starog hostera izričito pitajte za pristupne zapisnike i zapisnike pogrešaka od 20. listopada 2026. te za trajanje njihove pohrane. Kako postupiti, opisuje članak [Osigurati dokaze prije ponovne instalacije](https://phpsos.de/hr/blog/beweise-sichern-vor-neuinstallation/).
2. **Ograničiti incident.** Koji su sustavi pogođeni, koji su pristupi korišteni, koji su podaci bili dostupni? O tome ovise obveze prijave i pitanje što smijete preseliti.
3. **Provjeriti obveze prijave.** Ako su mogli biti pogođeni osobni podaci, rok za moguću GDPR prijavu počinje saznanjem za incident, a ne selidbom. Pozadinu donosi članak [Obveza prijave prema GDPR-u: 72 sata](https://phpsos.de/hr/compliance/dsgvo-meldepflicht-72-stunden/).
4. **Novi sustav postaviti čisto.** Podržana PHP verzija, aktualni paketi, ojačana konfiguracija, prije nego što se prenese prva datoteka.
5. **Prenijeti samo provjereno.** Kod iz čistog izvora, baza podataka i mediji nakon kontrole.
6. **Promijeniti sve pristupne podatke.** Baza podataka, administratorski računi, SSH, FTP, API ključevi, i oni u konfiguracijskim datotekama.
7. **Prebaciti i promatrati.** Promjena DNS-a, zatim neko vrijeme pojačan nadzor.
8. **Raskinuti stari ugovor.** Tek kad su zapisnici i sigurnosne kopije osigurani, a novi pogon stabilno radi.

> **Važno:**
> Ne otkazujte stari ugovor dok zapisnike i sigurnosne kopije nemate u rukama. S krajem ugovora kod pružatelja se mogu obrisati podaci koji su Vam potrebni za osiguravatelja, tijela ili vlastito razjašnjavanje.

## Što ne biste smjeli preseliti

Bilo bi zgodno jednostavno kopirati cijeli web-direktorij ili sliku poslužitelja. Upravo je to nakon incidenta rizično. Web shellovi maskiraju se u bezazlene datoteke, stražnja vrata skrivaju se u konfiguracijskim datotekama poput `.htaccess` ili `.user.ini`, a ubačeni kod može ležati u sadržaju baze podataka.

Kod aplikacije stoga prenesite iz čistog izvora, primjerice iz paketa proizvođača u odgovarajućoj verziji ili iz svog sustava za upravljanje verzijama. Medije preuzmite bez izvršnih datoteka, a bazu podataka nakon provjere na upadljive sadržaje i nove administratorske račune. Ono što je pronađeno na starom sustavu pomaže u toj provjeri.

Pomislite i na sve što uz web-stranicu leži kod starog pružatelja. E-mail sandučići, DNS zapisi, certifikati i preusmjeravanja pri selidbi se lako zaborave. Nekoliko dana prije prebacivanja skratite vrijeme valjanosti DNS zapisa kako bi promjena brzo stigla do posjetitelja. Ako se sele i e-mailovi, promjenu sandučića planirajte zasebno, jer i tamo nakon incidenta mogu biti pogođeni pristupni podaci.

## Novog hostera birati prema sigurnosti

Cijena i prostor za pohranu stoje u svakoj ponudi. Ključna sigurnosna pitanja uglavnom morate postaviti sami. Sljedeći popis pomaže pri usporedbi:

| Kriterij | Pitanje pružatelju | Zašto je važno |
|---|---|---|
| Postupak zakrpanja | Kako i u kojem okviru se instaliraju PHP sigurnosna ažuriranja i radi ponovno pokretanje? | PHP2Shell je pokazao koliko je važan dokaziv postupak |
| Dokaz | Dobivam li na zahtjev pisanu potvrdu o stanju zakrpe? | Osnova za Vašu vlastitu dokumentaciju |
| PHP verzije | Koje se grane nude i dokle? | Stare grane bez ažuriranja trajan su rizik |
| Razdvajanje | Radi li svaka web-stranica s vlastitim korisnikom i vlastitim PHP procesom? | Ograničava štetu ako je napadnut susjed |
| Zapisnici | Imam li pristup pristupnim zapisnicima i zapisnicima pogrešaka, koliko se dugo čuvaju? | Bez zapisnika nema razjašnjavanja |
| Sigurnosne kopije | Koliko često, koliko dugo, odvojeno od web-poslužitelja, s testom oporavka? | Oporavak nakon incidenta |
| Kontakt za hitne slučajeve | Kako u slučaju incidenta mogu doći do stručne osobe? | Vrijeme je u kriznoj situaciji najrjeđi čimbenik |
| Obrada podataka | Postoji li ugovor prema GDPR-u i popis podobrađivača? | Obveza kod osobnih podataka |

Predložak za pitanje o stanju zakrpe nudi vodič [Pitati hostera za stanje zakrpe](https://phpsos.de/hr/ratgeber/hoster-patch-status-erfragen/). Prikladan je i za usporedbu pružatelja prije sklapanja ugovora.

## Je li drugi model poslovanja bolji odgovor?

Ponekad problem nije toliko u hosteru koliko u modelu poslovanja. Tko vodi vlastiti poslužitelj bez redovite njege, često je bolje zbrinut uz dobro održavanu upravljanu ponudu. Obrnuto, tvrtka s vlastitim IT-om može dobiti više kontrole nad trenucima zakrpanja ako sama upravlja. Odvagivanje opisuje članak [Upravljani hosting ili vlastiti poslužitelj?](https://phpsos.de/hr/blog/managed-oder-eigener-server/).

Neovisno o modelu vrijedi: podjelu zadataka zabilježite pisano. Tko instalira PHP ažuriranja, tko ponovno pokreće, tko provjerava aplikaciju, tko se u slučaju nužde kome javlja? Kod PHP2Shella mnoga su kašnjenja nastala upravo na tom mjestu, jer je svaka strana mislila da će se druga pobrinuti.

## Kako PHP SOS konkretno pomaže?

- Osiguravamo zapisnike i podatke starog sustava i razjašnjavamo što se dogodilo tijekom incidenta.
- Novi sustav postavljamo ojačano i prenosimo samo provjerene sadržaje iz čistih izvora.
- Ponude novih pružatelja provjeravamo prema sigurnosnim kriterijima i postavljamo prava pitanja.
- Kod aktivnog incidenta radimo u okviru svog [odgovora na incidente](https://phpsos.de/hr/leistungen/incident-response/) sve dok incident nije zaključen i dokumentiran.


## Česta pitanja

**Trebam li nakon hakerskog napada odmah promijeniti hostera?**  
Ne odmah. Prvo treba osigurati tragove, ograničiti incident i razjasniti uzrok. Prenagljena selidba možda sa sobom nosi zlonamjerni kod i može uništiti dokaze kod starog pružatelja.

**Je li hoster kriv ako je moja web-stranica napadnuta putem PHP2Shella?**  
To ovisi o ugovoru i trenutku. Kod zajedničkog hostinga za PHP ažuriranja je u pravilu odgovoran hoster, a kod vlastitih poslužitelja operater. Zakrpe su objavljene 21. listopada 2026.; jesu li i kada instalirane, može se razjasniti samo dokazima. Za pitanja odgovornosti zatražite pravni savjet.

**Koje podatke smijem preseliti k novom hosteru?**  
Samo provjerene sadržaje: bazu podataka nakon provjere na ubačeni kod, medije bez izvršnih datoteka i kod iz čistog izvora, poput paketa proizvođača ili Vašeg sustava za upravljanje verzijama. Cijele slike poslužitelja ili web-direktorije s kompromitiranog sustava ne biste smjeli prenositi neprovjereno.

**Moram li nakon incidenta uključiti zaštitu podataka?**  
Ako su mogli biti pogođeni osobni podaci, može postojati obveza prijave prema GDPR-u, u pravilu u roku od 72 sata. Kod novog hostera uz to trebate ugovor o obradi podataka. Razjasnite to sa službenikom za zaštitu podataka; ovo nije pravni savjet.

## Izvori

- [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: prijava nadzornom tijelu](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [php.net: sigurnosne objave](https://www.php.net/)