# Bezpieczeństwo IT w modelu white label: partner bezpieczeństwa dla agencji

> Wiele stron klientów, różne firmy hostingowe, jeden dzień poprawek: pracujemy dla agencji w tle, łatamy, oczyszczamy i dokumentujemy pod Państwa kontrolą.

Źródło: https://phpsos.de/pl/branchen/agenturen-white-label/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Bezpieczeństwo IT w modelu white label oznacza dla Państwa agencji: zachowują Państwo relację z klientem, a my wykonujemy w tle pracę nad bezpieczeństwem. Przy PHP2Shell oznacza to inwentarz wszystkich stron klientów, ustalenie priorytetów według ryzyka, poprawkę i restart dla każdego serwera oraz dowód dla każdego klienta, który mogą Państwo przekazać dalej.

## Dlaczego agencje są przy PHP2Shell pod szczególną presją

Agencja z wieloma klientami rzadko obsługuje jednolity krajobraz. Część stron leży na własnych serwerach z Plesk, część u firm hostingowych klientów, niektóre stare projekty na wersjach PHP, które dawno nie otrzymują oficjalnych aktualizacji. Dochodzą różne systemy: WordPress, TYPO3, Shopware, [Craft CMS](https://phpsos.de/pl/plattformen/craft-cms/), własne rozwiązania w Laravelu.

Przy luce w samym PHP uderza to we wszystkie projekty jednocześnie. Klienci oczekują odpowiedzi, czy ich strona jest bezpieczna, a zespół projektowy jest obciążony bieżącymi zleceniami. Wiele umów serwisowych reguluje CMS, ale nie serwer pod spodem.

Dochodzą systemy, które nie pojawiają się już na żadnej liście projektów: środowiska stagingowe na subdomenach, strony kampanii z zakończonych projektów, instalacje testowe programistów na własnych vServerach. Działają często na starszych wersjach PHP, nie są nadzorowane i mimo to noszą nazwę Państwa agencji lub klienta. Dla automatycznych skanów są tak samo widoczne jak strona główna.

## Jakie pytania zadają teraz Państwa klienci

- Czy moja strona jest dotknięta i czy została już załatana?
- Czy przed poprawką coś zostało już wprowadzone?
- Czy aktualizacja CMS stanowi ochronę? Nie, aktualizacja CMS nie zamyka luki w PHP.
- Czy muszę odłączyć stronę od sieci? BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca to dla serwerów, których nie da się od razu zaktualizować.

Na każde z tych pytań Państwa agencja potrzebuje odpowiedzi możliwej do udowodnienia dla każdego klienta, a nie zbiorczego e-maila z ogólnymi stwierdzeniami.

## Jak przebiega bezpieczeństwo IT white label dla agencji

Pracujemy jako część Państwa zespołu, ale bez własnego kontaktu z klientem. Podział jest jasny:

| Zadanie | Państwa agencja | PHP SOS |
|---|---|---|
| Komunikacja z klientami i rozliczenia | tak | nie |
| Inwentarz wszystkich stron klientów ze stanem PHP | dostarcza dostępy | tworzy i prowadzi |
| Poprawka, restart, kontrola dla każdego serwera | zwalnia okno serwisowe | wykonuje lub koordynuje z firmami hostingowymi |
| Kontrola pod kątem kompromitacji | otrzymuje wynik | szuka webshelli i nieprawidłowości |
| Dowód dla każdego klienta | przekazuje dalej | sporządza neutralnie lub w Państwa formacie |

W przypadku stron na obcych firmach hostingowych uzyskujemy potwierdzenie stanu pakietu. Sam wyświetlany numer wersji nie wystarcza, ponieważ backporty mogą go pozostawić bez zmian.

> **Ważne:**
> Proszę najpierw nadać priorytet serwerom z Apache i mod_php, gdzie zespół PHP ocenia ryzyko jako najwyższe, potem sklepom i stronom z logowaniem, następnie projektom na PHP 8.1 i starszym. Statyczne stare projekty, których nikt już nie potrzebuje, lepiej wyłączyć, niż łatać.

## Wiele stron klientów na jednym serwerze: sprawdzić izolację

Na serwerach agencji wiele stron klientów dzieli często jedną maszynę. Jeśli jedna z nich zostanie skompromitowana, o tym, czy atakujący dotrze także do pozostałych, decyduje rozdzielenie. Ważni są osobni użytkownicy systemowi i pule PHP-FPM dla każdej strony, prawidłowe uprawnienia do plików i ograniczenia takie jak [open_basedir](https://phpsos.de/pl/ratgeber/open-basedir/). Na [serwerach Plesk](https://phpsos.de/pl/server/plesk/) te ustawienia można sprawdzić dla każdej subskrypcji.

Po poprawce obowiązuje: zrestartować wszystkie pule i procesy worker. Dopiero wtedy w pamięci nie działają już stare procesy PHP. Logi od 20.10.2026 powinny być przechowywane dla każdej strony klienta.

## Informowanie klientów: co jest udokumentowane, a co nie

Największą pokusą w tej sytuacji jest uspokajający e-mail zbiorczy. Bezpieczniejsze jest oświadczenie dla każdego klienta, które zawiera tylko to, co jest udokumentowane: jaki serwer, jaki stan pakietu PHP, kiedy zrestartowano, czy przeprowadzono kontrolę pod kątem kompromitacji i z jakim wynikiem. Zawiera ono także to, co jest jeszcze otwarte.

Sformułowań w rodzaju „Państwa strona jest bezpieczna” lepiej unikać. Poprawka zamyka lukę, ale nie dowodzi, że wcześniej nic się nie stało. Kto uczciwie to rozdziela, nie będzie później musiał się tłumaczyć, gdyby jednak pojawił się wynik.

## Przeredagować umowy serwisowe po PHP2Shell

Wiele umów agencyjnych reguluje aktualizacje CMS i rozszerzeń, ale milczy o serwerze. Proszę wykorzystać tę sytuację, aby dla każdego klienta ustalić, kto aktualizuje PHP, kto odpowiada za restarty, kto decyduje w razie incydentu i jakie usługi są zlecane osobno. Należy do tego także umowa powierzenia przetwarzania danych ze wszystkimi zaangażowanymi usługodawcami. Kształt umowny ustalają Państwo z doradztwem prawnym.

## Jak PHP SOS pomaga w praktyce?

- Przejmujemy inwentaryzację wszystkich stron klientów z wersją PHP, trybem pracy, firmą hostingową i odpowiedzialnością.
- Przez nasz [serwis poprawek PHP](https://phpsos.de/pl/leistungen/php-patch-service/) łatamy Państwa własne serwery, restartujemy wszystkie procesy worker i dokumentujemy to dla każdego klienta.
- Sprawdzamy strony o wysokim priorytecie pod kątem kompromitacji i w razie wyniku oczyszczamy, aż incydent zostanie zamknięty i udokumentowany.
- Dostarczamy elementy tekstowe do informowania klientów, które mogą Państwo dostosować i samodzielnie wysłać.
- Następnie na życzenie przejmujemy w ramach [umowy serwisowej bezpieczeństwa](https://phpsos.de/pl/leistungen/security-wartungsvertrag/) stałą opiekę nad bezpieczeństwem w tle.


## Częste pytania

**Czy występujecie Państwo wobec naszych klientów?**  
Tylko jeśli Państwo sobie tego życzą. W modelu white label pracujemy wyłącznie w tle, a cała komunikacja przebiega przez Państwa agencję. Naszą dokumentację dostarczamy w formie neutralnej lub w Państwa formacie.

**Czy potrzebujemy do tego umowy powierzenia przetwarzania danych?**  
Jeśli uzyskujemy dostęp do systemów z danymi osobowymi Państwa klientów, zwykle potrzebna jest umowa powierzenia przetwarzania, często jako podpowierzenie. Jak to wpisuje się w Państwa istniejące umowy, ustalają Państwo z doradztwem prawnym. Niezbędne informacje o naszych czynnościach udostępniamy.

**Co ze stronami klientów, których serwerów w ogóle nie zarządzamy?**  
Jeśli strony klientów znajdują się u obcych firm hostingowych, uzyskujemy w Państwa imieniu lub według Państwa wzorów potwierdzenia stanu poprawek i restartu. Tam, gdzie istnieje tylko dostęp FTP lub CMS, sprawdzamy, co da się stamtąd zrobić, i otwarcie zaznaczamy, co może udokumentować wyłącznie firma hostingowa.

**Czy możemy to także po PHP2Shell wyłączyć na stałe do zewnętrznej obsługi?**  
Tak. Wiele zadań powtarza się przy każdej luce: prowadzenie inwentarza, instalowanie poprawek, dokumentowanie restartów, zgłaszanie nieprawidłowości. Tę pracę można zorganizować jako stałą opiekę w tle.

## Źródła

- [php.net: komunikaty bezpieczeństwa](https://www.php.net/)
- [php.net: wspierane wersje](https://www.php.net/supported-versions.php)
- [BSI: ostrzeżenia i zalecenia](https://www.bsi.bund.de/)