Krótko: Umowa serwisowa strony z naciskiem na bezpieczeństwo sprawia, że aktualizacje, kopie zapasowe i nadzór nie zależą od przypadku. Opiekujemy się Państwa stronami i serwerami PHP na stałe, utrzymujemy aktualny stan, testujemy odtwarzanie i reagujemy według uzgodnionego trybu, gdy ujawniona zostanie nowa luka. Regularnie otrzymują Państwo zrozumiały raport.
Dlaczego bezpieczeństwo należy do umowy serwisowej strony
Wiele umów serwisowych obejmuje aktualizacje CMS i na tym się kończy. PHP2Shell pokazało, że to nie wystarcza: luki CVE-2026-109618 i CVE-2026-109619 tkwią w samym PHP, a nie w CMS. Aktualizacja WordPressa lub Shopware ich nie zamyka. Kto dba tylko o CMS, nie ma na oku prawdziwego zagrożenia.
Dochodzi czynnik czasu. Między wcześniejszym zapowiedzeniem przez php.net 20.10.2026 a publikacją poprawek 21.10. minął jeden dzień, a według doniesień medialnych już 17.10. zaobserwowano pierwszą próbę ataku. W takich sytuacjach pomaga tylko tryb działania ustalony wcześniej oraz ktoś, kto ma dostęp i wie, które systemy są dotknięte. Kto dopiero w sytuacji awaryjnej szuka danych dostępowych, dzwoni do usługodawców i wyjaśnia odpowiedzialności, traci dokładnie ten czas, który wykorzystują atakujący.
Jeszcze jeden punkt bywa niedoceniany: kopie zapasowe, które nigdy nie zostały odtworzone, to obietnica bez dowodu. Dopiero test odtwarzania pokazuje, czy kopia jest kompletna i jak długo faktycznie trwa powrót do pracy.
Dla kogo opłaca się umowa serwisowa bezpieczeństwa
Umowa serwisowa z naciskiem na bezpieczeństwo pasuje przede wszystkim do firm, których strona lub sklep jest krytyczny dla działalności, ale które nie mają własnej administracji serwerów i PHP. Typowe są sklepy internetowe, praktyki lekarskie, kancelarie i średnie przedsiębiorstwa z portalami klientów, ale także instytucje publiczne z kilkoma witrynami.
Równie sensowna jest, gdy odpowiedzialność jest dziś rozłożona na wiele osób: agencja zbudowała stronę, dostawca hostingu udostępnia serwer, a dostępy znał były pracownik. W takich konstelacjach przy sytuacjach takich jak PHP2Shell szybko okazuje się, że nikt nie jest jednoznacznie odpowiedzialny. Umowa tworzy stałe miejsce, które wie, co się dzieje, i może działać.
Dla pojedynczej, małej strony bez formularzy lub danych klientów może wystarczyć węższy zakres. Wyjaśniamy to podczas inwentaryzacji.
Co zawiera umowa serwisowa bezpieczeństwa
- Aktualizacje: system operacyjny, serwer WWW, PHP, CMS, rozszerzenia i zależności, w stałym rytmie oraz dodatkowo przy krytycznych lukach
- Restart i dowód: po aktualizacjach PHP restart wszystkich workerów z kontrolą, że nie działają stare procesy
- Kopie zapasowe: według reguły 3-2-1, z regularnym testem odtwarzania. Podstawy opisuje strona Kopie zapasowe według reguły 3-2-1.
- Nadzór: integralność plików, logowania, procesy i logi, jak opisano w Monitoring bezpieczeństwa dla serwerów WWW
- Cykl życia: wczesne planowanie, zanim wersja PHP osiągnie koniec wsparcia, na przykład PHP 8.2 w dniu 31.12.2026
- Tryb awaryjny: uzgodnione kroki na wypadek awarii, dostępy i osoby kontaktowe, które w incydencie są znane od razu
- Raport: regularne podsumowanie z zainstalowanymi aktualizacjami, zdarzeniami i zaleceniami
Kto za co odpowiada?
Wiele luk w bezpieczeństwie powstaje nie technicznie, lecz organizacyjnie: każdy myśli, że zajmuje się tym ktoś inny. Dlatego odpowiedzialności zapisujemy na piśmie. Typowy przykład:
| Zadanie | Dostawca hostingu | Agencja | PHP SOS | Państwo |
|---|---|---|---|---|
| Sprzęt, sieć, centrum danych | tak | |||
| System operacyjny i aktualizacje PHP | zależnie od umowy | tak | ||
| CMS i rozszerzenia | tak | wg uzgodnienia | ||
| Treści i konta użytkowników | tak | |||
| Nadzór i tryb awaryjny | tak | zatwierdzenia |
Rzeczywisty podział zależy od Państwa umów. Szczególnie przy serwerach zarządzanych warto dokładnie sprawdzić, co dostawca faktycznie przejmuje, zob. Serwer zarządzany: wyjaśnienie odpowiedzialności. Agencje z wieloma stronami klientów znajdą odpowiedni model w Partner bezpieczeństwa dla agencji.
Jak konkretnie pomaga PHP SOS?
- Inwentaryzacja: Rejestrujemy wszystkie strony, serwery, wersje, dostępy, kopie zapasowe i istniejące umowy.
- Zabezpieczenie wstępne: Otwarte aktualizacje i znane słabe punkty są zamykane najpierw, zanim rozpocznie się bieżąca opieka.
- Ustalenie: Zakres, rytm, odpowiedzialności i tryb awaryjny zapisujemy na piśmie, także kwestię, kiedy pytamy Państwa przed zmianami.
- Bieżąca opieka: Aktualizacje, kopie zapasowe, nadzór i raporty według planu, a przy krytycznych lukach dodatkowo według uzgodnionego trybu awaryjnego.
- Coroczny przegląd: Wspólnie sprawdzamy, czy umowa nadal pasuje do Państwa środowiska systemowego.
Czego potrzebujemy i czego nie obiecujemy
Potrzebujemy stałych dostępów administracyjnych, osoby kontaktowej uprawnionej do decyzji, kontaktu z dostawcą hostingu i agencją oraz informacji o planowanych zmianach w Państwa aplikacjach. Dostępy zarządzamy oddzielnie dla każdego klienta i dokumentujemy, kto ma dostęp. Jeśli planują Państwo zmiany w swoich systemach, na przykład nowy sklep, dodatkową stronę lub zmianę dostawcy hostingu, proszę powiedzieć nam o tym wcześnie, aby aktualizacje, kopie zapasowe i nadzór mogły rosnąć razem z nimi.
Nie obiecujemy, że Państwa systemy nigdy nie zostaną zaatakowane. Umowa serwisowa obniża ryzyko i sprawia, że w razie awarii działa się szybko i w uporządkowany sposób. Cen i czasów reakcji nie podajemy ryczałtowo, lecz ustalamy je po inwentaryzacji w ofercie. Jak dodatkowo przygotować się organizacyjnie na sytuację awaryjną, opisuje strona Opracowanie planu awaryjnego IT dla serwerów WWW.
Częste pytania
Co należy do umowy serwisowej strony z naciskiem na bezpieczeństwo?
Co najmniej aktualizacje serwera, PHP, CMS i rozszerzeń, regularne kopie zapasowe z testem odtwarzania, nadzór bezpieczeństwa i jasna regulacja na wypadek awarii. Ważne jest także zapisanie na piśmie, kto za co odpowiada.
Czy umowa serwisowa zastępuje moją agencję lub dostawcę hostingu?
Niekoniecznie. Często współpracujemy z agencją i dostawcą hostingu i przejmujemy część dotyczącą bezpieczeństwa. Decydujące jest, aby odpowiedzialności były rozdzielone bez luk i aby nic nie zostawało pomiędzy zaangażowanymi.
Co się dzieje, gdy ujawniona zostanie krytyczna luka taka jak PHP2Shell?
Wtedy sprawdzamy, które z Państwa systemów są dotknięte, instalujemy aktualizacje według uzgodnionego trybu lub wdrażamy środki przejściowe i informujemy Państwa o stanie. Jak szybko to nastąpi, ustalamy wspólnie w umowie.
Czy istnieje cena ryczałtowa?
Zakres zależy od liczby i rodzaju Państwa systemów. Po inwentaryzacji sporządzamy ofertę, która dokładnie opisuje, co jest w niej zawarte.