# Tárhelyszolgáltató cseréje biztonsági incidens után: mire figyeljen?

> Tárhelyszolgáltató cseréje biztonsági incidens után: a helyes sorrend, bizonyítékok mentése, csak tiszta adatok költöztetése és az új szolgáltató célzott ellenőrzése.

Forrás: https://phpsos.de/hu/blog/hoster-wechseln-nach-vorfall/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Aki biztonsági incidens után tárhelyszolgáltatót szeretne váltani, először mentse a bizonyítékokat és tisztázza az incidenst, azután csak ellenőrzött adatokat vigyen át egy újonnan felépített rendszerre, és csak ezután szüntesse meg a régi szerződést. Az új szolgáltatót biztonsági szempontok szerint válassza ki: igazolható javítási folyamatok, az ügyfelek elválasztása, hozzáférés a naplókhoz, mentések és egyértelmű kapcsolattartók. A szolgáltatóváltás akkor értelmes, ha hiányzik a bizalom vagy a teljesítmény, de nem helyettesíti a tisztítást.

## Ha elveszett a bizalom

A PHP2Shell után sok vállalat először él át nyomás alatt a tárhelyszolgáltatójával. Egyesek gyorsan egyértelmű tájékoztatást kaptak a javítási állapotról. Mások napokig vártak válaszra, csak általános frázisokat kaptak, vagy kiderült, hogy a weboldaluk elavult PHP-verzión futott. Ha ehhez még egy incidens is társul, érthető a váltás szándéka.

A tárhelyszolgáltató cseréje azonban nem az incidens kezelésének lépése, hanem az utána következő újrafelállításé. Aki rossz sorrendben csinálja, a legrosszabb esetben a támadót is magával viszi, és egyidejűleg elveszíti azokat a nyomokat, amelyek megmutatják, mi történt.

## A váltás helyes sorrendje

1. **Mentse a nyomokat, amíg megvannak.** A régi rendszer naplóit, fájljait és adatbázisát mentse el, mielőtt bármit törölnének vagy felmondanának. Kérdezze meg kifejezetten a régi tárhelyszolgáltatót a 2026. október 20-tól készült hozzáférési és hibanaplókról és azok megőrzési idejéről. A [Bizonyítékok mentése az újratelepítés előtt](https://phpsos.de/hu/blog/beweise-sichern-vor-neuinstallation/) cikk leírja, hogyan járjon el.
2. **Határolja be az incidenst.** Mely rendszerek érintettek, mely hozzáféréseket használták, mely adatok voltak elérhetők? Ettől függnek a bejelentési kötelezettségek és az, hogy mit vihet át.
3. **Vizsgálja meg a bejelentési kötelezettségeket.** Ha személyes adatok érintettek lehetnek, a lehetséges GDPR-bejelentés határideje az incidensről való tudomásszerzéssel kezdődik, nem a költözéssel. A háttér a [GDPR-bejelentési kötelezettség: 72 óra](https://phpsos.de/hu/compliance/dsgvo-meldepflicht-72-stunden/) oldalon olvasható.
4. **Építse fel tisztán az új rendszert.** Támogatott PHP-verzió, friss csomagok, megerősített konfiguráció, még az első fájl átvitele előtt.
5. **Csak ellenőrzött tartalmat vigyen át.** Kód tiszta forrásból, adatbázis és médiafájlok ellenőrzés után.
6. **Cserélje ki az összes hozzáférési adatot.** Adatbázis, admin-fiókok, SSH, FTP, API-kulcsok, azokat is, amelyek konfigurációs fájlokban vannak.
7. **Kapcsoljon át és figyeljen.** DNS-átállítás, utána egy ideig szorosabb felügyelet.
8. **Szüntesse meg a régi szerződést.** Csak ha a naplók és a mentések biztonságban vannak, és az új üzemeltetés stabilan fut.

> **Fontos:**
> Ne mondja fel a régi szerződést, mielőtt a naplók és a mentések a kezében nem lennének. A szerződés megszűntével a szolgáltatónál olyan adatok is törlődhetnek, amelyekre a biztosítóhoz, hatóságokhoz vagy a saját kivizsgáláshoz szüksége van.

## Mit ne vigyen magával

Kényelmes lenne a teljes webkönyvtárat vagy a szerver egy képét egyszerűen átmásolni. Incidens után éppen ez a kockázatos. A webshellek ártalmatlan fájloknak álcázzák magukat, a hátsó kapuk konfigurációs fájlokban bújnak meg, például a `.htaccess` vagy a `.user.ini` fájlban, és a beszúrt kód adatbázis-tartalmakban is lehet.

Az alkalmazáskódot ezért tiszta forrásból vigye át, például a megfelelő verziójú gyártói csomagból vagy a verziókezelő rendszerből. A médiafájlokat végrehajtható fájlok nélkül vegye át, az adatbázist pedig feltűnő tartalmak és új rendszergazdai fiókok ellenőrzése után. Amit a régi rendszeren találtak, segít ebben az ellenőrzésben.

Gondoljon mindarra is, ami a weboldal mellett a régi szolgáltatónál van. Az e-mail-postafiókok, a DNS-bejegyzések, a tanúsítványok és az átirányítások könnyen kimaradnak a költözésből. Csökkentse a DNS-bejegyzések érvényességi idejét néhány nappal az átállás előtt, hogy a változás gyorsan eljusson a látogatókhoz. Ha az e-mailek is költöznek, a postafiókok váltását tervezze külön, mert ott is érintettek lehetnek a hozzáférési adatok egy incidens után.

## Az új szolgáltató kiválasztása biztonság szerint

Az ár és a tárhely minden ajánlatban szerepel. A döntő biztonsági kérdéseket többnyire Önnek kell feltennie. Az alábbi lista segít az összehasonlításban:

| Szempont | Kérdés a szolgáltatóhoz | Miért számít |
|---|---|---|
| Javítási folyamat | Hogyan és milyen keretek között telepítik és indítják újra a PHP-biztonsági frissítéseket? | A PHP2Shell megmutatta, mennyire fontos az igazolható folyamat |
| Igazolás | Kérésre kapok írásos megerősítést a javítási állapotról? | Alap a saját dokumentációjához |
| PHP-verziók | Mely ágakat kínálják, és meddig? | A frissítés nélküli régi ágak tartós kockázatot jelentenek |
| Elválasztás | Minden weboldal saját felhasználóval és saját PHP-folyamattal fut? | Korlátozza a kárt, ha egy szomszédot támadnak meg |
| Naplók | Hozzáférek a hozzáférési és hibanaplókhoz, és meddig őrzik meg őket? | Napló nélkül nincs kivizsgálás |
| Mentések | Milyen gyakran, meddig, a webszervertől elkülönítve, visszaállítási teszttel? | Visszaállítás incidens után |
| Vészhelyzeti kapcsolat | Hogyan érek el szakértő személyt egy incidens esetén? | Éles helyzetben az idő a legszűkösebb tényező |
| Adatfeldolgozás | Van GDPR szerinti szerződés és alvállalkozói lista? | Személyes adatoknál kötelező |

A javítási állapotra vonatkozó kérdéshez mintát kínál a [Kérdezze meg a tárhelyszolgáltatót a javítási állapotról](https://phpsos.de/hu/ratgeber/hoster-patch-status-erfragen/) útmutató. Alkalmas arra is, hogy a szerződéskötés előtt összehasonlítsa a szolgáltatókat.

## Jobb válasz lehet egy másik üzemeltetési modell?

Néha a probléma kevésbé a tárhelyszolgáltatónál van, mint az üzemeltetési modellben. Aki rendszeres karbantartás nélkül üzemeltet saját szervert, gyakran jobb helyen van egy jól támogatott menedzselt ajánlatnál. Fordítva, egy saját IT-vel rendelkező vállalat több kontrollt nyerhet a javítási időpontok fölött, ha maga üzemeltet. A mérlegelést a [Menedzselt tárhely vagy saját szerver?](https://phpsos.de/hu/blog/managed-oder-eigener-server/) cikk írja le.

A modelltől függetlenül érvényes: rögzítse írásban a feladatmegosztást. Ki telepíti a PHP-frissítéseket, ki indít újra, ki ellenőrzi az alkalmazást, ki kinek jelez vészhelyzetben? A PHP2Shell esetében sok késedelem éppen itt keletkezett, mert mindkét fél azt hitte, hogy a másik gondoskodik a dologról.

## Hogyan segít konkrétan a PHP SOS?

- Mentjük a régi rendszer naplóit és adatait, és tisztázzuk, mi történt az incidens során.
- Megerősítve építjük fel az új rendszert, és csak ellenőrzött tartalmat viszünk át tiszta forrásokból.
- Az új szolgáltatók ajánlatait biztonsági szempontok szerint vizsgáljuk, és feltesszük a megfelelő kérdéseket.
- Folyamatban lévő incidens esetén az [Incident Response](https://phpsos.de/hu/leistungen/incident-response/) szolgáltatásunk keretében dolgozunk, amíg az incidens le nem zárul és dokumentálva nem lesz.


## Gyakori kérdések

**Azonnal tárhelyszolgáltatót kell váltanom egy feltörés után?**  
Nem azonnal. Előbb nyomokat kell menteni, az incidenst be kell határolni, és az okot tisztázni. Egy elhamarkodott költözés a kártékony kódot is magával viheti, és a régi szolgáltatónál megsemmisítheti a bizonyítékokat.

**A tárhelyszolgáltató hibája volt, ha a weboldalamat a PHP2Shellen keresztül támadták meg?**  
Ez a szerződéstől és az időponttól függ. Megosztott tárhelyen a PHP-frissítésekért többnyire a tárhelyszolgáltató felel, saját szervernél az üzemeltető. A javítások 2026. október 21-én jelentek meg; hogy felkerültek-e, és mikor, azt csak bizonyítékokkal lehet tisztázni. Felelősségi kérdésekben kérjen jogi tanácsot.

**Milyen adatokat vihetek át az új tárhelyszolgáltatóhoz?**  
Csak ellenőrzött tartalmat: az adatbázist a beszúrt kód ellenőrzése után, a médiafájlokat végrehajtható fájlok nélkül, a kódot pedig tiszta forrásból, például a gyártói csomagból vagy a verziókezelő rendszerből. Teljes szerverképeket vagy webkönyvtárakat az megfertőzött rendszerről ne vigyen át ellenőrzés nélkül.

**Be kell vonnom az adatvédelmet egy incidens után?**  
Ha személyes adatok érintettek lehetnek, a GDPR szerinti bejelentési kötelezettség állhat fenn, általában 72 órán belül. Az új tárhelyszolgáltatóval ezenkívül adatfeldolgozási szerződésre is szüksége van. Egyeztessen az adatvédelmi felelősével; ez nem jogi tanácsadás.

## Források

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [GDPR 33. cikk: bejelentés a felügyeleti hatóságnak](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [php.net: biztonsági közlemények](https://www.php.net/)