# Správa záplat ako proces namiesto hasenia požiarov

> Správa záplat ako proces: triedy záplat, servisné okná, test, cesta späť, reštart a doklad, aby kritické aktualizácie ako pri PHP2Shell sedeli.

Zdroj: https://phpsos.de/sk/blog/patch-management-prozess/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručne:** Proces správy záplat určuje, ako aktualizácie prebiehajú od prijatia po doklad: do ktorej triedy záplata patrí, v ktorom okne sa nainštaluje, ako sa testuje a vracia späť, kto reštartuje a ako sa dokladuje úspech. Rutinné aktualizácie bežia plánovane v pravidelnom rytme, núdzové záplaty idú vopred dohodnutou rýchlou cestou. Tak sa z hasičských výjazdov stane opakovateľný postup.

## Keď je každá záplata núdzová

Večer 21. 10. 2026 sa v mnohých firmách opakoval ten istý scenár. Záplaty boli k dispozícii, BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) naliehalo a začali sa otázky: Môžeme teraz jednoducho aktualizovať? Kto testuje? Kto reštartuje služby? Kto oznámi konateľom, že obchod na chvíľu nepôjde? A ako potom dokážeme, že to vyšlo?

Vo firmách bez procesu sa musí všetko vyjasniť v danej chvíli. Vo firmách s procesom odpoveď už existuje. Rozdiel nie je v technike, ale v dohodách, ktoré sa uzavreli vopred.

## Stavebné prvky procesu správy záplat

Použiteľný proces najprv rozlišuje, ako naliehavá záplata je. Zvyčajne stačia tri triedy:

| Trieda | Typický dôvod | Okno | Test | Schválenie |
|---|---|---|---|---|
| Rutina | opravy chýb, bezpečnostné aktualizácie s nízkym rizikom | pevný mesačný termín | staging, štandardné testy | IT, podľa plánu |
| Naliehavá | vysoké zaradenie, systém verejne dostupný | skrátený termín | skrátený, najdôležitejšie postupy | vedúci IT |
| Núdzová | kritická zraniteľnosť, hlásené útoky, napr. PHP2Shell | okamžite | rýchly test po nasadení | vopred udelené núdzové schválenie |

Kto prideľuje akú triedu, by malo byť určené rovnako ako kritériá. Samotné hodnotenie patrí do predchádzajúceho kroku, pozri [Riadenie zraniteľností pre stredné firmy](https://phpsos.de/sk/blog/schwachstellenmanagement-mittelstand/).

Dôležité je vopred udelené núdzové schválenie. Konatelia sa raz v pokoji rozhodnú, že pri núdzových záplatách sa smie konať okamžite, aj keď to znamená krátke prerušenie. V krízovej situácii potom nikto nemusí v noci zháňať súhlas.

Rovnako dôležité sú roly. Pre každý systém by malo byť jasné, kto aktualizácie inštaluje, kto odborne testuje, či obchod alebo portál potom funguje, a kto je informovaný. Pri outsourcovaných systémoch k tomu výslovne patria poskytovateľ hostingu a agentúra, s menami a dostupnosťou. Pevné servisné okno by malo byť interne známe, aby predaj a zákaznícky servis vedeli, kedy sú možné krátke prerušenia.

Okrem toho merajte, ako dlho váš proces skutočne trvá: od zverejnenia záplaty po doložené ukončenie, osobitne podľa triedy. Tieto vlastné hodnoty ukážu, kde sa to zasekáva, a zviditeľnia zlepšenia. Proces, ktorého trvanie nikto nepozná, sa dá riadiť len ťažko.

## Postup jednej záplaty v ôsmich krokoch

Každá záplata, bez ohľadu na triedu, prechádza rovnakými stanicami. Líši sa len tempo a hĺbka testov.

1. **Prijatie:** Hlásenie alebo dostupná aktualizácia sa zaznamená s dátumom a zdrojom.
2. **Zaradenie:** Určiť triedu, podľa inventára zistiť dotknuté systémy.
3. **Príprava:** Záloha alebo snapshot, opísať cestu späť, informovať zúčastnených.
4. **Test:** najprv v stagingu alebo na menej kritickom systéme.
5. **Nasadenie:** v dohodnutom okne, systém po systéme.
6. **Reštart:** všetky dotknuté služby a procesy, nielen balíky.
7. **Doklad:** zaznamenať stav balíka, záznam v changelogu a spustenie procesov.
8. **Kontrola:** overiť funkčnosť, pri bezpečnostných zraniteľnostiach navyše dávať pozor na stopy skoršieho vniknutia.

Na krok 6 sa prekvapivo často zabúda. PHP načíta svoj kód pri spustení procesov. Kým bežia staré workery PHP-FPM alebo procesy Apache s mod_php, pracujú ďalej so starým, zraniteľným stavom. Prečo to tak je a ako správne reštartovať, nájdete v článku [Po aktualizácii: reštartovať PHP-FPM a všetkých workerov](https://phpsos.de/sk/php2shell/php-fpm-neustart/).

## Doklady, ktoré neskôr rozhodnú

Záplata bez dokladu nie je v prípade pochybností nainštalovaná, aspoň voči zákazníkom, poisťovateľom alebo audítorom. Pre každý systém zaznamenajte, aký stav balíka je nainštalovaný, či sú čísla CVE v changelogu a kedy sa spustili bežiace procesy. Na systémoch Debian a Ubuntu pomáhajú príkazy na čítanie, ako sú tieto (názov balíka upravte podľa svojho systému):

```bash
# Obsahuje nainštalovaný balík opravy?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Kedy sa spustili bežiace procesy PHP-FPM?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
```

Ak je čas spustenia procesov pred inštaláciou balíka, chýba reštart. Podrobne to opisuje článok [Doloženie čísel CVE v changelogu balíka](https://phpsos.de/sk/blog/cve-im-changelog-nachweisen/).

> **Dôležité:**
> Záplata uzavrie zraniteľnosť do budúcnosti. Neodstráni škodlivý softvér, ktorý sa do systému dostal predtým, a nedokazuje, že sa predtým nič nestalo. Pri núdzových záplatách preto k postupu pevne patrí hľadanie stôp.

## Automatizovať tam, kde je to bezpečné

Automatické bezpečnostné aktualizácie balíkov operačného systému ušetria veľa rutinnej práce. Odľahčia však iba vtedy, ak existujú zálohy, niekto číta výsledky a reštartujú sa aj dotknuté služby. Ako sa to nastavuje v Linuxe a aké má hranice, opisuje článok [Automatické bezpečnostné aktualizácie na linuxových serveroch](https://phpsos.de/sk/blog/automatische-sicherheitsupdates/).

Kontajnery potrebujú vlastnú cestu. Tam sa neaktualizuje v bežiacom systéme, ale znova sa zostaví a nasadí obraz (image) s opravenou verziou PHP. Proces záplatovania, ktorý pozná iba servery, tieto systémy ľahko prehliadne. Zahrňte preto do zoznamu ciest záplatovania aj build pipeline a registre obrazov, so zodpovednou osobou a rovnakým dokladom ako pri klasických serveroch: Aká verzia PHP beží v nasadenom kontajneri a odkedy?

Aplikácie, CMS a pluginy zvyčajne potrebujú vlastnú, otestovanú cestu, pretože aktualizácie tam častejšie menia funkcie. Pevný mesačný termín je na to správne miesto. Nakoniec je dôležité, aby všetky cesty viedli do tej istej dokumentácie: jedno miesto, kde je vidieť, ktorý systém je v akom stave.

## Ako konkrétne pomáha PHP SOS?

- Spolu s vami zapíšeme triedy záplat, okná a schválenia, prispôsobené vašim systémom a vašej organizácii.
- Tam, kde to dáva zmysel, nastavíme automatické bezpečnostné aktualizácie s kontrolou reštartu a upozorňovaním.
- Núdzové záplaty vrátane reštartu, dokladu a hľadania stôp preberáme prostredníctvom našej [služby záplatovania PHP](https://phpsos.de/sk/leistungen/php-patch-service/).
- Doklady vedieme pre každý systém tak, aby ste ich mohli predložiť zákazníkom, poisťovateľom alebo audítorom.

**Záver:** Správa záplat pôsobí nenápadne, kým funguje. Presne to je cieľ: keď príde ďalšie kritické hlásenie, beží nacvičený postup a nikto nemusí improvizovať.


## Časté otázky

**Aký je rozdiel medzi správou záplat a riadením zraniteľností?**  
Riadenie zraniteľností zachytáva a hodnotí zraniteľnosti a rozhoduje, čo sa má urobiť. Správa záplat rozhodnutie realizuje: aktualizácie testuje, inštaluje, reštartuje služby a dokladuje úspech. Obe do seba zapadajú.

**Majú sa bezpečnostné aktualizácie inštalovať automaticky?**  
Pri balíkoch operačného systému to často dáva zmysel, ak existujú zálohy a po behu sa kontroluje výsledok. Dôležité je, aby sa reštartovali aj dotknuté služby. Pri PHP inak zostanú v pamäti staré procesy so zraniteľným kódom.

**Ako doložím, že záplata skutočne pôsobí?**  
Nainštalovaným stavom balíka a číslami CVE v changelogu balíka, časom inštalácie a časom spustenia bežiacich procesov, ktorý musí byť po inštalácii.

**Čo robiť, ak aktualizácia niečo pokazí?**  
Na to slúži cesta späť: záloha alebo snapshot pred aktualizáciou a opísaný postup návratu. Pri bezpečnostných aktualizáciách by mal byť návrat výnimkou a mal by byť spojený s prechodným opatrením.

## Zdroje

- [php.net: bezpečnostné hlásenia](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)