# Ćwiczenie awaryjne przy stole: przećwiczenie incydentu serwera WWW

> Ćwiczenie tabletop dla IT: jak przeprowadzić przy stole incydent serwera WWW, ze scenariuszem, rolami, wstrzykami i oceną, która coś zmienia.

Źródło: https://phpsos.de/pl/blog/notfalluebung-am-tisch/  
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:** Ćwiczenie tabletop w IT omawia incydent bezpieczeństwa przy stole: moderacja krok po kroku podaje nowe informacje o sytuacji, uczestnicy decydują jak w razie prawdziwej awarii, a na końcu powstaje lista konkretnych usprawnień. Dla serwerów WWW nadaje się scenariusz wzorowany na PHP2Shell, ponieważ dotyka jednocześnie techniki, decyzji w warunkach niepewności, ochrony danych i komunikacji.

## Dlaczego plan zaczyna działać dopiero przez ćwiczenie

Wiele firm ma dziś plan awaryjny. To, czy działa, pokazuje się jednak dopiero wtedy, gdy ktoś używa go pod presją czasu. Czy jest w nim właściwy numer telefonu? Czy zarząd wie, że musi zdecydować o wyłączeniu? Czy usługodawca zna dostępy? Takie pytania ćwiczenie przy stole wyjaśnia w kilka godzin.

Tydzień października 2026 pokazał, jak szybko sytuacja może eskalować: zapowiedź php.net 20.10., poprawki 21.10. o godz. 16:00 czasu niemieckiego, poziom ostrzegawczy pomarańczowy BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej), według doniesień medialnych wyłączenia publicznych stron. Kto wcześniej raz przećwiczył taki przebieg, musiał mniej improwizować. Przebieg w szczegółach opisuje [Chronologia PHP2Shell](https://phpsos.de/pl/ratgeber/php2shell-chronologie/). Jak samodzielnie zbudować plan, wyjaśnia artykuł [Jak sporządzić plan awaryjny IT dla serwerów WWW](https://phpsos.de/pl/compliance/notfallplan-erstellen/); tutaj chodzi o ćwiczenie.

## Ćwiczenie tabletop w IT: role i przygotowanie

Dobre ćwiczenie wymaga niewiele materiałów, ale jasnych ról. **Moderacja** prowadzi przez scenariusz, wprowadza informacje i pilnuje czasu. Nie dyskutuje, lecz zadaje pytania. **Protokolant** zapisuje decyzje, otwarte pytania i każde miejsce, w którym ktoś mówi „tego teraz bym nie wiedział”. Opcjonalnie kolejna osoba obserwuje, jak przebiega komunikacja.

**Uczestnicy** to ludzie, którzy w razie prawdziwej awarii faktycznie działają: zarząd, wewnętrzne IT lub zewnętrzny usługodawca, inspektorzy ochrony danych, komunikacja, w razie potrzeby zakupy lub dział prawny. Ważne, aby byli też zastępcy, ponieważ incydenty nie liczą się z planami urlopowymi.

Do przygotowania należą: aktualny plan awaryjny na papierze, lista kontaktów, przegląd stron i serwerów oraz pomieszczenie bez przerw. Proszę wcześniej ustalić, że chodzi o uczenie się, a nie o oceny. Kto boi się skompromitować, nie powie, czego nie wie.

## Gotowy scenariusz: krytyczna luka w PHP w piątek po południu

Poniższy scenariusz jest fikcyjny, ale wzorowany na prawdziwej sytuacji. Proszę dostosować systemy i nazwy do swojego środowiska. Każdy wstrzyk otrzymuje dziesięć do dwudziestu minut dyskusji.

| Krok | Wstrzyk moderacji | Pytanie przewodnie do grupy |
|---|---|---|
| 1 | Prasa branżowa donosi o krytycznej luce w PHP, poprawki są zapowiedziane, ale jeszcze ich nie ma. | Kto dowie się o tym pierwszy i kogo trzeba poinformować? |
| 2 | Poprawki ukazują się po południu. BSI zaleca natychmiastową aktualizację, w przeciwnym razie tymczasowe wyłączenie. | Które z naszych systemów są dotknięte i skąd to wiemy? |
| 3 | Firma hostingowa się nie odzywa. Własny serwer działa na wersji PHP bez oficjalnej aktualizacji. | Łatać, wyłączyć czy czekać i kto o tym decyduje? |
| 4 | Sklep ma w weekend prowadzić promocję. Sprzedaż naciska, by niczego nie wyłączać. | Jak ważymy przychody i ryzyko i jak dokumentujemy decyzję? |
| 5 | Administrator znajduje w poniedziałek nieznany plik PHP w folderze uploadu. | Co robimy najpierw, czego świadomie nie robimy? Kto zabezpiecza dowody? |
| 6 | Nie jest jasne, czy dane klientów wyciekły. | Kto ocenia możliwy obowiązek zgłoszenia i kiedy biegnie termin? |
| 7 | Dziennikarka pyta, dlaczego strona jest offline. | Kto wypowiada się na zewnątrz i co mówimy, dopóki wiemy niewiele? |

Krok 6 dotyka RODO. W ćwiczeniu wystarczy wyjaśnić przebieg: kto włącza inspektorów ochrony danych i kiedy. Ocena prawna pozostaje przy specjalistach; podstawowe zasady dotyczące terminu zawiera art. 33 RODO.

## Typowe wnioski i jak je zapisać

Pewne luki pojawiają się niemal przy każdym pierwszym ćwiczeniu. Brakuje pełnej listy, jakie strony działają na jakich serwerach z jaką wersją PHP. Dane kontaktowe firmy hostingowej są nieaktualne albo zapisane tylko w skrzynce pocztowej, która w razie awarii jest nieosiągalna. Nikt nie wie na pewno, czy zarząd może sam zarządzić wyłączenie, czy ktoś musi się zgodzić.

Proszę zapisać każdy wniosek w trzech częściach: co stwierdziliśmy, co zmieniamy i kto to zrobi do kiedy. Wniosek bez osoby odpowiedzialnej, jak pokazuje doświadczenie, zostaje na półce. Punkty proszę uporządkować według skutku: brakujący numer awaryjny jest szybko uzupełniony i pomaga od razu, nowe rozwiązanie monitoringu wymaga planowania.

Do uporządkowanej oceny po ćwiczeniu nadaje się to samo postępowanie, co po prawdziwym incydencie. Jest opisane we wpisie [Lessons learned: jak stać się lepszym po incydencie](https://phpsos.de/pl/blog/lessons-learned-nach-vorfall/). Listę kontaktów, która w ćwiczeniu zwykle ujawnia słabości, omawia wpis [Kontakty awaryjne: kogo i kiedy trzeba poinformować?](https://phpsos.de/pl/blog/notfallkontakte-liste/).

> **Wskazówka:**
> Proszę powtórzyć ćwiczenie po sześciu do dwunastu miesiącach z innym scenariuszem, na przykład zhakowanej strony z przekierowaniem na obce witryny. W ten sposób sprawdzą Państwo, czy działania z pierwszej rundy zostały naprawdę wdrożone.

## Jak konkretnie pomaga PHP SOS?

1. Dostosowujemy scenariusz do Państwa rzeczywistych stron, serwerów i usługodawców i przygotowujemy wstrzyki.
2. Moderujemy ćwiczenie zdalnie lub przez wideokonferencję i powstrzymujemy się od ocen, dopóki grupa nie podejmie decyzji.
3. Dostarczamy potem protokół z wnioskami, działaniami, osobami odpowiedzialnymi i terminami.
4. Na życzenie ćwiczymy następnie część techniczną, czyli inwentaryzację, poprawkę i poszukiwanie śladów, tak jak wykonuje ją nasze [reagowanie na incydenty](https://phpsos.de/pl/leistungen/incident-response/) w razie awarii.

## Podsumowanie

Ćwiczenie awaryjne przy stole to najtańszy sposób na znalezienie słabości planu awaryjnego, zanim zrobi to prawdziwy incydent. Na początek wystarczą jedno popołudnie, realistyczny scenariusz i uczciwa ocena. Decydujące jest to, aby z każdego wniosku powstało zadanie z nazwiskiem i datą.


## Częste pytania

**Czym jest ćwiczenie tabletop?**  
To ćwiczenie, w którym uczestnicy wspólnie omawiają incydent przy stole, nie pracując na prawdziwych systemach. Moderacja krok po kroku wprowadza nowe informacje, a grupa decyduje i uzasadnia swoje decyzje. W ten sposób uwidaczniają się luki w planie, odpowiedzialnościach i listach kontaktów.

**Kto powinien uczestniczyć w ćwiczeniu awaryjnym?**  
Wszyscy, którzy w razie awarii decydują lub działają: zarząd, IT lub usługodawca, ochrona danych, komunikacja oraz, jeśli jest, osoba odpowiedzialna za sprawy ubezpieczeniowe. Więcej niż osiem do dziesięciu osób sprawia, że runda staje się ociężała.

**Jak długo trwa ćwiczenie tabletop?**  
Na pierwsze przejście wystarczają dwie do trzech godzin wraz z oceną. Ważniejsze niż długość jest to, aby wyniki zostały zapisane, a działania przydzielone z terminem.

**Czy scenariusz musi być realistyczny?**  
Powinien pasować do Państwa środowiska, ale nie musi zgadzać się w każdym szczególe. Scenariusz wzorowany na prawdziwej sytuacji, takiej jak PHP2Shell, jest wiarygodny i kieruje dyskusję na decyzje zamiast na szczegóły techniczne.

## Źródła

- [BSI: informacje o zarządzaniu awaryjnym](https://www.bsi.bund.de/)
- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [RODO art. 33 (tekst w języku niemieckim)](https://dsgvo-gesetz.de/art-33-dsgvo/)