Krótko: Plan awaryjny IT dla serwerów WWW ustala z góry, kto w sytuacji kryzysowej decyduje, z kim można się skontaktować, jakie systemy mogą być dotknięte i jakie kroki następują w jakiej kolejności. Kto chce stworzyć plan awaryjny IT, nie potrzebuje grubego podręcznika, lecz kilku aktualnych stron dostępnych także bez działającej informatyki. Sytuacja wokół PHP2Shell jest dobrym powodem, aby zrobić to teraz.
Dlaczego plan awaryjny oszczędza czas i szkody
W sytuacji kryzysowej pierwsze godziny często mijają na szukaniu: kto ma dostęp do hostera? Gdzie leżą kopie zapasowe? Kto decyduje, czy sklep przechodzi offline? Kogo trzeba poinformować? Plan awaryjny odpowiada na te pytania wcześniej, w spokoju.
PHP2Shell pokazał, jak krótki może być czas. W dniu 20.10.2026 php.net zapowiedziało poprawki, 21.10. o 16:00 czasu niemieckiego je opublikowano, a BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleciło natychmiastową aktualizację lub czasowe wyłączenie. Firmy z planem wiedziały, do kogo zadzwonić i które serwery sprawdzić. Inne musiały najpierw ustalić, gdzie w ogóle działa PHP.
Tworzenie planu awaryjnego IT: elementy
Praktyczny plan dla serwerów WWW obejmuje następujące części:
1. Role i decyzje. Kto kieruje w sytuacji awaryjnej, kto zastępuje, kto może wyłączać systemy, kto wypowiada się na zewnątrz? Proszę zapisać nazwiska i zastępstwa.
2. Lista kontaktów. Wewnętrzne osoby kontaktowe, hoster, agencja, usługodawca IT, inspektor ochrony danych, doradca prawny, cyberubezpieczenie z numerem polisy, właściwy organ nadzorczy ochrony danych, Zentrale Ansprechstelle Cybercrime (ZAC, centralny punkt kontaktowy ds. cyberprzestępczości) Państwa kraju związkowego. Ta lista musi być dostępna w formie wydruku.
3. Inwentarz systemów. Każda strona, każdy sklep i każdy portal z serwerem, hosterem, trybem pracy, wersją PHP, aplikacją, osobą odpowiedzialną i rodzajem przetwarzanych danych.
4. Reguły decyzyjne. Na jakich warunkach odłączamy system od sieci? Kto może o tym zdecydować? Co obowiązuje w nocy i w weekend?
5. Procedury. Krótkie sekwencje kroków dla typowych przypadków: znana krytyczna luka, podejrzenie włamania, strona zniekształcona, wyciek danych, wymuszenie.
6. Drogi zgłoszeń. Kto sprawdza obowiązek zgłoszenia według art. 33 RODO, o ile to możliwe w ciągu 72 godzin od powzięcia wiedzy? Kto zgłasza do BSI przy obowiązku NIS2? Kto informuje ubezpieczyciela?
7. Odtwarzanie. Gdzie leżą kopie zapasowe, kto może je odtworzyć, jak długo to trwa, kiedy ostatnio to testowano?
Przykład: procedura „krytyczna luka w PHP”
Tak może wyglądać procedura, jakiej potrzebowano przy PHP2Shell:
| Krok | Kto | Wynik |
|---|---|---|
| Ocena komunikatu (php.net, BSI) | Osoby odpowiedzialne za IT | dotknięte systemy według inwentarza |
| Instalacja aktualizacji, restart wszystkich procesów roboczych | Admin lub usługodawca | Dowód ze stanem pakietów i czasem procesów |
| Gdzie aktualizacja niemożliwa: środki przejściowe lub odłączenie od sieci | Decyduje kierownictwo | udokumentowana decyzja |
| Zabezpieczenie logów, sprawdzenie śladów | Admin lub informatyka śledcza | ustalenie lub brak ustaleń |
| Przy ustaleniu: uruchomić procedurę incydentu | Kierownictwo awaryjne | sprawdzić drogi zgłoszeń |
Ważne przy tym: poprawka zamyka lukę, ale nie usuwa wcześniej wprowadzonego szkodliwego oprogramowania. Dlatego poszukiwanie śladów należy na stałe do procedury.
Proszę ustalić, jak długo przechowywane są logi serwera WWW i gdzie leżą poza serwerem. W przypadku PHP2Shell prasa branżowa zalecała przechowywanie logów od 20.10.2026. Kto zachowuje logi tylko kilka dni, nie może wdrożyć takich zaleceń.
Prewencja, która dopiero czyni plan skutecznym
Plan jest tak dobry, jak warunki, na których się opiera. Proszę sprawdzić, czy istnieją i są przetestowane kopie zapasowe według reguły 3-2-1, zob. Kopie zapasowe według reguły 3-2-1. Proszę uzgodnić z hosterem i agencją na piśmie, kto przy krytycznych lukach przejmuje co. Dane dostępowe na sytuacje awaryjne proszę przechowywać bezpiecznie, ale w sposób osiągalny, na przykład w chronionym menedżerze haseł z dostępem awaryjnym.
Proszę przygotować także wzory tekstów: informację wewnętrzną, komunikat dla klientów, notę na statycznej stronie konserwacyjnej. Wskazówki podaje artykuł Komunikacja kryzysowa po ataku.
Ćwiczyć i utrzymywać aktualność
Plan, który nigdy nie był ćwiczony, prawie zawsze zawiera luki. Raz w roku proszę przeprowadzić jakiś scenariusz, na przykład „krytyczna luka w PHP w piątkowe popołudnie”, i zanotować, gdzie się zacina. Na początek wystarczy prosty test: czy druga osoba bez pomocy pierwszej potrafi skontaktować się z hosterem, odtworzyć kopię zapasową i przełączyć stronę w tryb konserwacji? Jeśli nie, w planie czegoś brakuje, zwykle dostępu, numeru telefonu lub opisu. Właśnie takie luki mają uwidocznić ćwiczenia, zanim zrobi się poważnie. Plan proszę aktualizować po każdym ćwiczeniu i każdej istotnej zmianie. Ramą metodyczną są IT-Grundschutz (podstawowa ochrona IT) wydany przez BSI oraz BSI-Standard 200-4 dotyczący zarządzania ciągłością działania.
Kwestii prawnych, na przykład obowiązków zgłoszeniowych, plan nie rozstrzyga ostatecznie. Zapewnia, że właściwe osoby zostaną zaangażowane na czas. Ta strona to ogólna informacja, a nie porada prawna.
Jak konkretnie pomaga PHP SOS?
- Sporządzamy z Państwem inwentarz systemów Państwa serwerów WWW, wraz z trybem pracy i wersją PHP.
- Piszemy procedury techniczne dla typowych scenariuszy i uzgadniamy je z hosterem i agencją.
- Przeprowadzamy ćwiczenie i wprowadzamy wnioski do planu.
- W sytuacji kryzysowej przejmujemy stronę techniczną przez reagowanie na incydenty, na życzenie zabezpieczone umową serwisową bezpieczeństwa.
Częste pytania
Jak obszerny musi być plan awaryjny IT?
Tak krótki, jak to możliwe, tak szczegółowy, jak to konieczne. Dla serwerów WWW często wystarcza kilka stron z kontaktami, listą systemów, regułami decyzyjnymi i procedurami. Ważniejsze od objętości jest, aby był aktualny i aby w sytuacji kryzysowej dało się go znaleźć.
Gdzie przechowywać plan awaryjny?
Co najmniej w jednym miejscu dostępnym także bez działającej informatyki, na przykład w formie wydruku lub na osobnym urządzeniu. Plan, który leży tylko na dotkniętym serwerze lub w zablokowanej sieci firmowej, w sytuacji kryzysowej nie pomoże.
Jak często plan powinien być sprawdzany?
Co najmniej raz w roku i po każdej istotnej zmianie, na przykład zmianie hostera lub nowym oprogramowaniu. Sensowne jest krótkie ćwiczenie, w którym przeprowadza się jakiś scenariusz.
Czy BSI oferuje wzory?
BSI omawia zarządzanie awaryjne w ramach IT-Grundschutz oraz w BSI-Standard 200-4 dotyczącym zarządzania ciągłością działania (Business Continuity Management). Nadają się jako rama; dla serwerów WWW warto przygotować zwięzłą, praktyczną wersję.