Krótko: Kto po incydencie bezpieczeństwa chce zmienić dostawcę hostingu, powinien najpierw zabezpieczyć dowody i wyjaśnić incydent, następnie przenieść tylko sprawdzone dane na nowo zainstalowany system, a dopiero potem rozwiązać starą umowę. Nowego dostawcę wybiera się według kryteriów bezpieczeństwa: udokumentowane procesy poprawek, rozdzielenie klientów, dostęp do logów, kopie zapasowe i jasne osoby kontaktowe. Zmiana dostawcy hostingu ma sens, gdy brakuje zaufania lub jakości usługi, ale nie zastępuje oczyszczenia systemu.
Gdy zaufanie zniknęło
Po PHP2Shell wiele firm po raz pierwszy widzi swojego dostawcę hostingu pod presją. Niektórzy szybko dostali jasną informację o stanie poprawek. Inni czekali dniami na odpowiedź, otrzymywali tylko ogólne formułki albo stwierdzali, że ich strona działała na przestarzałej wersji PHP. Jeśli do tego dojdzie incydent, chęć zmiany jest zrozumiała.
Zmiana dostawcy hostingu nie jest jednak krokiem w opanowywaniu incydentu, lecz nowym ustawieniem po nim. Kto zrobi to w złej kolejności, w najgorszym razie zabierze ze sobą atakującego i jednocześnie straci ślady pokazujące, co się stało.
Właściwa kolejność przy zmianie
- Zabezpieczyć ślady, dopóki są. Logi, pliki i baza danych starego systemu powinny trafić do kopii, zanim cokolwiek zostanie usunięte lub wypowiedziane. Proszę wyraźnie zapytać dotychczasowego dostawcę hostingu o logi dostępu i błędów od 20 października 2026 oraz o okres ich przechowywania. Jak postępować, opisuje artykuł Zabezpieczanie dowodów przed ponowną instalacją.
- Ograniczyć zasięg incydentu. Które systemy są dotknięte, jakie dostępy zostały użyte, jakie dane były osiągalne? Od tego zależą obowiązki zgłoszeniowe i pytanie, co wolno przenieść.
- Sprawdzić obowiązki zgłoszeniowe. Jeśli mogą być dotknięte dane osobowe, termin ewentualnego zgłoszenia na podstawie RODO biegnie od stwierdzenia incydentu, a nie od przeprowadzki. Tło znajdą Państwo w Obowiązek zgłoszenia RODO: 72 godziny.
- Zbudować nowy system w czysty sposób. Wspierana wersja PHP, aktualne pakiety, utwardzona konfiguracja, zanim zostanie przeniesiony pierwszy plik.
- Przenosić tylko sprawdzone. Kod z czystego źródła, baza danych i media po kontroli.
- Zmienić wszystkie dane dostępowe. Baza danych, konta administratorów, SSH, FTP, klucze API, także te zapisane w plikach konfiguracyjnych.
- Przełączyć i obserwować. Zmiana DNS, potem przez pewien czas ściślejszy monitoring.
- Zakończyć starą umowę. Dopiero gdy logi i kopie są zabezpieczone, a nowa praca przebiega stabilnie.
Proszę nie wypowiadać starej umowy, zanim logi i kopie zapasowe nie znajdą się w Państwa rękach. Z końcem umowy dostawca może usunąć dane, których potrzebują Państwo dla ubezpieczyciela, organów lub własnego wyjaśnienia sprawy.
Czego nie należy zabierać ze sobą
Wygodnie byłoby po prostu skopiować cały katalog WWW lub obraz serwera. Właśnie to jest po incydencie ryzykowne. Webshelle maskują się jako nieszkodliwe pliki, tylne furtki tkwią w plikach konfiguracyjnych takich jak .htaccess czy .user.ini, a wprowadzony kod może leżeć w treściach bazy danych.
Kod aplikacji należy więc przenieść z czystego źródła, na przykład z pakietu producenta w odpowiedniej wersji lub z systemu kontroli wersji. Media przejmują Państwo bez plików wykonywalnych, bazę danych po kontroli pod kątem podejrzanych treści i nowych kont administratorów. W tej kontroli pomaga to, co znaleziono na starym systemie.
Proszę też pomyśleć o wszystkim, co poza stroną internetową leży u dotychczasowego dostawcy. Skrzynki e-mail, wpisy DNS, certyfikaty i przekierowania łatwo przy przeprowadzce pominąć. Na kilka dni przed przełączeniem proszę skrócić czas ważności wpisów DNS, aby zmiana szybko dotarła do odwiedzających. Jeśli przenoszone są też e-maile, przeniesienie skrzynek należy zaplanować osobno, ponieważ także tam po incydencie mogą być dotknięte dane dostępowe.
Wybór nowego dostawcy hostingu pod kątem bezpieczeństwa
Cena i miejsce na dysku stoją w każdej ofercie. Decydujące pytania o bezpieczeństwo trzeba zwykle zadać samodzielnie. Poniższa lista pomaga w porównaniu:
| Kryterium | Pytanie do dostawcy | Dlaczego to ważne |
|---|---|---|
| Proces poprawek | Jak i w jakich ramach instalowane są aktualizacje bezpieczeństwa PHP i wykonywany jest restart? | PHP2Shell pokazało, jak ważny jest udokumentowany proces |
| Dowód | Czy na prośbę otrzymam pisemne potwierdzenie stanu poprawek? | Podstawa Państwa własnej dokumentacji |
| Wersje PHP | Jakie gałęzie są oferowane i jak długo jeszcze? | Stare gałęzie bez aktualizacji to stałe ryzyko |
| Rozdzielenie | Czy każda strona działa z własnym użytkownikiem i własnym procesem PHP? | Ogranicza szkody, gdy atakowany jest sąsiad |
| Logi | Czy mam dostęp do logów dostępu i błędów i jak długo są przechowywane? | Bez logów nie ma wyjaśnienia |
| Kopie zapasowe | Jak często, jak długo, oddzielnie od serwera WWW, z testem odtwarzania? | Odtworzenie po incydencie |
| Kontakt awaryjny | Jak w razie incydentu skontaktuję się z osobą znającą temat? | W sytuacji awaryjnej czas jest najrzadszym zasobem |
| Powierzenie przetwarzania | Czy istnieje umowa zgodna z RODO i lista podwykonawców? | Obowiązek przy danych osobowych |
Wzór pytania o stan poprawek oferuje poradnik Zapytanie dostawcy hostingu o status poprawek. Nadaje się też do porównywania dostawców przed zawarciem umowy.
Czy inny model prowadzenia jest lepszą odpowiedzią?
Czasem problem leży mniej w dostawcy hostingu, a bardziej w modelu prowadzenia. Kto prowadzi własny serwer bez regularnej pielęgnacji, bywa lepiej obsłużony w dobrze zarządzanej ofercie managed. I odwrotnie, firma z własnym działem IT może zyskać większą kontrolę nad momentem instalacji poprawek, jeśli sama zarządza serwerem. Rozważenie opisuje artykuł Managed hosting czy własny serwer?.
Niezależnie od modelu obowiązuje zasada: podział zadań proszę ustalić na piśmie. Kto instaluje aktualizacje PHP, kto restartuje, kto sprawdza aplikację, kto w razie awarii kontaktuje się z kim? Przy PHP2Shell wiele opóźnień powstało właśnie w tym miejscu, ponieważ każda strona myślała, że zajmie się tym druga.
Jak konkretnie pomaga PHP SOS?
- Zabezpieczamy logi i dane starego systemu oraz wyjaśniamy, co wydarzyło się podczas incydentu.
- Budujemy nowy system w wersji utwardzonej i przenosimy tylko sprawdzone treści z czystych źródeł.
- Oceniamy oferty nowych dostawców według kryteriów bezpieczeństwa i zadajemy właściwe pytania.
- Przy trwającym incydencie pracujemy w ramach naszej usługi Incident Response, aż incydent zostanie zamknięty i udokumentowany.
Częste pytania
Czy po włamaniu powinienem od razu zmienić dostawcę hostingu?
Nie od razu. Najpierw trzeba zabezpieczyć ślady, ograniczyć zasięg incydentu i ustalić przyczynę. Pochopna przeprowadzka może przenieść złośliwy kod i zniszczyć dowody u dotychczasowego dostawcy.
Czy dostawca hostingu ponosi winę, jeśli moja strona została zaatakowana przez PHP2Shell?
To zależy od umowy i momentu. W hostingu współdzielonym za aktualizacje PHP odpowiada zwykle dostawca hostingu, w przypadku własnych serwerów operator. Poprawki ukazały się 21 października 2026; czy i kiedy zostały zainstalowane, można ustalić tylko na podstawie dowodów. W kwestiach odpowiedzialności proszę skorzystać z porady prawnika.
Jakie dane mogę przenieść do nowego dostawcy hostingu?
Tylko sprawdzone treści: bazę danych po kontroli pod kątem wprowadzonego kodu, media bez plików wykonywalnych oraz kod z czystego źródła, takiego jak pakiet producenta lub Państwa system kontroli wersji. Pełnych obrazów serwera ani katalogów WWW ze skompromitowanego systemu nie należy przenosić bez sprawdzenia.
Czy po incydencie muszę uwzględnić ochronę danych?
Jeżeli mogą być dotknięte dane osobowe, może istnieć obowiązek zgłoszenia na podstawie RODO, zwykle w ciągu 72 godzin. U nowego dostawcy hostingu potrzebna jest ponadto umowa powierzenia przetwarzania danych. Proszę to wyjaśnić z inspektorem ochrony danych; nie jest to porada prawna.