# Správa záplat jako proces, ne hašení požárů

> Správa záplat jako proces: třídy záplat, servisní okna, test, cesta zpět, restart a doklad, aby kritické aktualizace jako u PHP2Shell opravdu fungovaly.

Zdroj: https://phpsos.de/cs/blog/patch-management-prozess/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručně:** Proces správy záplat určuje, jak aktualizace probíhají od přijetí až po doložení: do jaké třídy záplata spadá, v jakém okně se instaluje, jak se testuje a vrací zpět, kdo restartuje a jak se dokládá úspěch. Rutinní aktualizace běží plánovaně v taktu, nouzové záplaty následují předem dohodnutou rychlou cestou. Z hasičských zásahů se tak stává opakovatelný postup.

## Když je každá záplata nouzový stav

Večer 21. 10. 2026 probíhal v mnoha firmách stejný scénář. Záplaty byly venku, BSI (německý Spolkový úřad pro informační bezpečnost) naléhalo a začaly otázky: Smíme teď prostě aktualizovat? Kdo testuje? Kdo restartuje služby? Kdo řekne vedení, že e-shop bude krátce nedostupný? A jak potom dokážeme, že to vyšlo?

Ve firmách bez procesu se to všechno musí vyjasňovat v tu chvíli. Ve firmách s procesem je odpověď už dána. Rozdíl není v technice, ale v dohodách, které padly předem.

## Stavební kameny procesu správy záplat

Funkční proces nejdřív rozlišuje, jak je záplata naléhavá. Většinou stačí tři třídy:

| Třída | Typický důvod | Okno | Test | Schválení |
|---|---|---|---|---|
| Rutina | opravy chyb, bezpečnostní aktualizace s nízkým rizikem | pevný měsíční termín | staging, standardní testy | IT, podle plánu |
| Naléhavé | vysoké hodnocení, systém veřejně dostupný | předsunuto na krátkou dobu | zkrácený, nejdůležitější postupy | vedoucí IT |
| Nouzové | kritická zranitelnost, hlášené útoky, např. PHP2Shell | okamžitě | smoke test po instalaci | předem udělené nouzové schválení |

Kdo přiděluje jakou třídu, by mělo být stanoveno stejně jako kritéria. Samotné hodnocení patří do předchozího kroku, viz [Řízení zranitelností pro střední firmy](https://phpsos.de/cs/blog/schwachstellenmanagement-mittelstand/).

Důležité je předem udělené nouzové schválení. Vedení jednou v klidu rozhodne, že u nouzových záplat se smí jednat okamžitě, i když to znamená krátké přerušení. V krizi pak nemusí nikdo v noci shánět souhlas.

Stejně důležité jsou role. U každého systému by mělo být jasné, kdo instaluje aktualizace, kdo po odborné stránce testuje, zda po nich e-shop nebo portál funguje, a kdo je informován. U outsourcovaných systémů patří výslovně k věci poskytovatel hostingu a agentura, se jménem a dostupností. Pevné servisní okno by mělo být známé uvnitř firmy, aby obchod a zákaznický servis věděly, kdy jsou možná krátká přerušení.

Měřte také, jak dlouho váš proces skutečně trvá: od zveřejnění záplaty po doložené dokončení, odděleně podle třídy. Tyto vlastní hodnoty ukážou, kde to drhne, a zviditelní zlepšení. Proces, jehož délku nikdo nezná, lze stěží řídit.

## Průběh záplaty v osmi krocích

Každá záplata, bez ohledu na třídu, prochází stejnými stanicemi. Liší se jen tempo a hloubka testování.

1. **Přijetí:** Hlášení nebo dostupná aktualizace se zaeviduje s datem a zdrojem.
2. **Zařazení:** Určit třídu, podle inventáře zjistit dotčené systémy.
3. **Příprava:** Záloha nebo snapshot, popsat cestu zpět, informovat zúčastněné.
4. **Test:** nejdřív na stagingu nebo na méně kritickém systému.
5. **Instalace:** v dohodnutém okně, systém po systému.
6. **Restart:** všechny dotčené služby a procesy, nejen balíčky.
7. **Doklad:** zaznamenat stav balíčku, záznam v changelogu a spuštění procesu.
8. **Kontrola:** ověřit funkci, u bezpečnostních zranitelností navíc dbát na stopy dřívějšího průniku.

Krok 6 se překvapivě často zapomíná. PHP načítá svůj kód při spuštění procesů. Dokud běží staří workeři PHP-FPM nebo procesy Apache s mod_php, pracují dál se starým, zranitelným stavem. Proč tomu tak je a jak správně restartovat, najdete v [Po aktualizaci: restartovat PHP-FPM a všechny workery](https://phpsos.de/cs/php2shell/php-fpm-neustart/).

## Doklady, na kterých později záleží

Záplata bez dokladu není v případě pochybností nainstalována, alespoň vůči zákazníkům, pojišťovnám nebo auditorům. U každého systému zaznamenejte, jaký stav balíčku je nainstalován, zda jsou čísla CVE uvedena v changelogu a kdy byly spuštěny běžící procesy. Na systémech Debian a Ubuntu v tom pomáhají čtecí příkazy jako tyto (název balíčku upravte podle svého systému):

```bash
# Obsahuje nainstalovaný balíček opravy?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Kdy byly spuštěny běžící procesy PHP-FPM?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
```

Pokud je čas spuštění procesů dřívější než instalace balíčku, chybí restart. Podrobně to popisuje [Doložení čísel CVE v changelogu balíčku](https://phpsos.de/cs/blog/cve-im-changelog-nachweisen/).

> **Důležité:**
> Záplata uzavře zranitelnost do budoucna. Neodstraní škodlivý software, který byl vložen dříve, a nedokazuje, že se předtím nic nestalo. U nouzových záplat proto patří k postupu pevně i hledání stop.

## Automatizovat tam, kde je to bezpečné

Automatické bezpečnostní aktualizace balíčků operačního systému ušetří mnoho rutinní práce. Uleví ale jen tehdy, pokud existují zálohy, někdo čte výsledky a restartují se i dotčené služby. Jak to na Linuxu nastavit a jaké má hranice, popisuje [Automatické bezpečnostní aktualizace na linuxových serverech](https://phpsos.de/cs/blog/automatische-sicherheitsupdates/).

Kontejnery potřebují vlastní cestu. Neaktualizuje se v běžícím systému, ale znovu se sestaví image s opravenou verzí PHP a nasadí se. Proces záplatování, který zná jen servery, tyto systémy snadno přehlédne. Zařaďte proto do seznamu cest záplatování i build pipeline a registry image, s odpovědnou osobou a stejným dokladem jako u klasických serverů: Jaká verze PHP běží v nasazeném kontejneru a od kdy?

Aplikace, CMS a pluginy potřebují většinou vlastní, otestovanou cestu, protože aktualizace tam častěji mění funkce. Pevný měsíční termín je pro to správným místem. Nakonec je důležité, aby všechny cesty ústily do téže dokumentace: jednoho místa, kde je vidět, v jakém stavu je který systém.

## Jak konkrétně pomáhá PHP SOS?

- Společně s vámi sepíšeme třídy záplat, okna a schválení, přizpůsobené vašim systémům a vaší organizaci.
- Tam, kde to dává smysl, nastavíme automatické bezpečnostní aktualizace s kontrolou restartu a upozorněním.
- Nouzové záplaty včetně restartu, dokladu a hledání stop přebíráme prostřednictvím naší [služby záplatování PHP](https://phpsos.de/cs/leistungen/php-patch-service/).
- Doklady vedeme u každého systému tak, abyste je mohli předložit zákazníkům, pojišťovnám nebo auditorům.

**Závěr:** Správa záplat působí nenápadně, dokud funguje. Přesně to je cíl: Když přijde další kritické hlášení, běží nacvičený postup a nikdo nemusí improvizovat.


## Časté dotazy

**Jaký je rozdíl mezi správou záplat a řízením zranitelností?**  
Řízení zranitelností zjišťuje a hodnotí zranitelnosti a rozhoduje, co je třeba udělat. Správa záplat rozhodnutí provádí: aktualizace testuje, instaluje, restartuje služby a dokládá úspěch. Obojí do sebe zapadá.

**Mají se bezpečnostní aktualizace instalovat automaticky?**  
U balíčků operačního systému to často dává smysl, pokud existují zálohy a po běhu se provádí kontrola. Důležité je, aby se restartovaly i dotčené služby. U PHP jinak zůstávají v paměti staré procesy se zranitelným kódem.

**Jak doložím, že záplata skutečně funguje?**  
Nainstalovaným stavem balíčku a čísly CVE v changelogu balíčku, časem instalace a časem spuštění běžících procesů, který musí být po instalaci.

**Co dělat, když aktualizace něco pokazí?**  
K tomu slouží cesta zpět: záloha nebo snapshot před aktualizací a popsaný postup návratu. U bezpečnostních aktualizací by měl být návrat výjimkou a spojit se s přechodným opatřením.

## Zdroje

- [php.net: bezpečnostní hlášení](https://www.php.net/)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)