# Patchmenedzsment folyamatként, nem tűzoltásként

> Patchmenedzsment folyamatként: patchosztályok, karbantartási ablak, teszt, visszaút, újraindítás és igazolás a kritikus frissítésekhez.

Forrás: https://phpsos.de/hu/blog/patch-management-prozess/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A patchmenedzsment-folyamat rögzíti, hogyan zajlanak a frissítések a beérkezéstől az igazolásig: melyik osztályba esik egy patch, melyik ablakban telepítik, hogyan tesztelik és görgetik vissza, ki indít újra, és hogyan igazolják a sikert. A rutinfrissítések tervezhetően, ütemben futnak, a vészhelyzeti patchek egy előre megállapodott gyorsútvonalat követnek. Így a tűzoltásból megismételhető folyamat lesz.

## Ha minden patch vészhelyzet

2026. 10. 21. estéjén sok vállalkozásnál ugyanaz a minta játszódott le. A patchek megvoltak, a BSI (a német Szövetségi Információbiztonsági Hivatal) sürgetett, és megkezdődtek a kérdések: Frissíthetünk most csak úgy? Ki tesztel? Ki indítja újra a szolgáltatásokat? Ki szól a vezetésnek, hogy a webshop rövid időre kiesik? És hogyan bizonyítjuk utólag, hogy sikerült?

A folyamat nélküli vállalkozásoknál mindezt a pillanatban kell tisztázni. A folyamattal rendelkezőknél a válasz már megvan. A különbség nem a technikában van, hanem az előre megkötött megállapodásokban.

## A patchmenedzsment-folyamat építőelemei

Egy teherbíró folyamat először azt különbözteti meg, mennyire sürgős egy patch. Három osztály többnyire elegendő:

| Osztály | Tipikus ok | Ablak | Teszt | Jóváhagyás |
|---|---|---|---|---|
| Rutin | hibajavítások, alacsony kockázatú biztonsági frissítések | rögzített havi időpont | staging, szokásos tesztek | IT, terv szerint |
| Sürgős | magas besorolás, nyilvánosan elérhető rendszer | rövid időn belülre előrehozva | lerövidített, a legfontosabb folyamatok | IT-vezetés |
| Vészhelyzet | kritikus rés, jelentett támadások, pl. PHP2Shell | azonnal | füsttesztelés a telepítés után | előre megadott vészhelyzeti jóváhagyás |

Hogy ki melyik osztályt adja, annak éppúgy rögzítettnek kell lennie, mint a kritériumainak. Maga az értékelés az előző lépéshez tartozik, lásd [Sebezhetőségkezelés a közép- és kisvállalkozásoknál](https://phpsos.de/hu/blog/schwachstellenmanagement-mittelstand/).

Fontos az előre megadott vészhelyzeti jóváhagyás. A vezetés egyszer, nyugodtan eldönti, hogy vészhelyzeti patcheknél azonnal lehet cselekedni, akkor is, ha ez rövid megszakítást jelent. Éles helyzetben így senkinek sem kell éjszaka hozzájárulást kérnie.

Ugyanilyen fontosak a szerepek. Minden rendszernél rögzíteni kell, ki telepíti a frissítéseket, ki tesztel szakmailag, működik-e utána a webshop vagy a portál, és ki kap értesítést. A kiszervezett rendszereknél a tárhelyszolgáltató és az ügynökség kifejezetten hozzátartozik, névvel és elérhetőséggel. A rögzített karbantartási ablakot belül ismertté kell tenni, hogy az értékesítés és az ügyfélszolgálat tudja, mikor lehetségesek rövid megszakítások.

Mérje meg emellett, mennyi ideig tart valójában a folyamata: egy patch kiadásától az igazolt lezárásig, osztályonként külön. Ezek a saját értékek megmutatják, hol akad el, és láthatóvá teszik a javulást. Egy olyan folyamatot, amelynek az időtartamát senki sem ismeri, aligha lehet irányítani.

## Egy patch menete nyolc lépésben

Minden patch, bármelyik osztályba tartozik is, ugyanazokon az állomásokon megy át. Csak a tempó és a tesztelés mélysége különbözik.

1. **Beérkezés:** a közleményt vagy az elérhető frissítést rögzítik, dátummal és forrással.
2. **Besorolás:** az osztály meghatározása, az érintett rendszerek megállapítása a leltár alapján.
3. **Előkészítés:** mentés vagy pillanatkép, a visszaút leírása, az érintettek tájékoztatása.
4. **Teszt:** először stagingben vagy egy kevésbé kritikus rendszeren.
5. **Telepítés:** a megállapodott ablakban, rendszerenként.
6. **Újraindítás:** az összes érintett szolgáltatás és folyamat, nem csak a csomagok.
7. **Igazolás:** a csomagállapot, a changelog-bejegyzés és a folyamatindítás rögzítése.
8. **Ellenőrzés:** a működés vizsgálata, biztonsági réseknél emellett egy korábbi behatolás nyomaira is ügyelni kell.

A 6. lépést meglepően gyakran elfelejtik. A PHP a folyamatok indításakor tölti be a kódját. Amíg régi PHP-FPM-workerek vagy mod_php-s Apache-folyamatok futnak, a régi, sebezhető állapottal dolgoznak tovább. Hogy ez miért van így, és hogyan kell helyesen újraindítani, azt a [A frissítés után: a PHP-FPM és az összes worker újraindítása](https://phpsos.de/hu/php2shell/php-fpm-neustart/) tartalmazza.

## Igazolások, amelyek később számítanak

Igazolás nélküli patch kétség esetén nincs telepítve, legalábbis az ügyfelek, a biztosítók vagy az auditorok felé. Rögzítse rendszerenként, hogy melyik csomagállapot van telepítve, szerepelnek-e a CVE-számok a changelogban, és mikor indultak el a futó folyamatok. Debian- és Ubuntu-rendszereken olvasó parancsok segítenek, mint ezek (a csomagnevet igazítsa a saját rendszeréhez):

```bash
# Tartalmazza a telepített csomag a javításokat?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Mikor indultak el a futó PHP-FPM-folyamatok?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
```

Ha a folyamatok indulási időpontja a csomag telepítése előtt van, az újraindítás hiányzik. Részletesen ezt írja le a [CVE-számok igazolása a csomag changelogjában](https://phpsos.de/hu/blog/cve-im-changelog-nachweisen/).

> **Fontos:**
> A patch a jövőre nézve zár le egy rést. Nem távolítja el a korábban bejuttatott kártékony szoftvert, és nem bizonyítja, hogy korábban nem történt semmi. Vészhelyzeti patcheknél ezért a nyomkeresés is a folyamat szerves része.

## Automatizálás ott, ahol biztonságos

Az operációsrendszer-csomagok automatikus biztonsági frissítései sok rutinmunkát levesznek a vállalkozás válláról. Csak akkor tehermentesítenek, ha vannak mentések, valaki elolvassa az eredményeket, és az érintett szolgáltatásokat is újraindítják. Hogyan állítható be ez Linuxon, és milyen korlátai vannak, azt az [Automatikus biztonsági frissítések Linux-szervereken](https://phpsos.de/hu/blog/automatische-sicherheitsupdates/) írja le.

A konténereknek saját útra van szükségük. Ott nem a futó rendszerben frissítenek, hanem újraépítik és kitelepítik a javított PHP-verziójú image-et. Egy olyan patchfolyamat, amely csak szervereket ismer, könnyen figyelmen kívül hagyja ezeket a rendszereket. Vegye fel ezért a build-pipeline-okat és az image-registryket is a patchutak listájára, felelős személlyel és ugyanazzal az igazolással, mint a klasszikus szervereknél: melyik PHP-verzió fut a kitelepített konténerben, és mióta?

Az alkalmazásoknak, CMS-eknek és bővítményeknek többnyire saját, tesztelt útra van szükségük, mert a frissítések ott gyakrabban változtatnak funkciókat. A rögzített havi időpont erre a megfelelő hely. Végül az a fontos, hogy minden út ugyanabban a dokumentációban fusson össze: egy helyen látszik, melyik rendszer milyen állapotban van.

## Hogyan segít konkrétan a PHP SOS?

- Önnel együtt leírjuk a patchosztályokat, ablakokat és jóváhagyásokat, az Ön rendszereihez és szervezetéhez igazítva.
- Ahol ésszerű, ott újraindítás-ellenőrzéssel és értesítéssel állítunk be automatikus biztonsági frissítéseket.
- A vészhelyzeti patcheket az újraindítással, az igazolással és a nyomkereséssel együtt átvesszük a [PHP-patch-szolgáltatásunkon](https://phpsos.de/hu/leistungen/php-patch-service/) keresztül.
- Rendszerenként úgy vezetjük az igazolásokat, hogy azokat az ügyfeleknek, biztosítóknak vagy auditoroknak be lehessen mutatni.

**Összegzés:** A patchmenedzsment szenzációmentesnek tűnik, amíg működik. Éppen ez a cél: amikor a következő kritikus közlemény megjön, egy begyakorolt folyamat fut, és senkinek sem kell rögtönöznie.


## Gyakori kérdések

**Mi a különbség a patchmenedzsment és a sebezhetőségkezelés között?**  
A sebezhetőségkezelés felméri és értékeli a réseket, és eldönti, mit kell tenni. A patchmenedzsment a döntést valósítja meg: frissítéseket tesztel, telepít, szolgáltatásokat indít újra, és igazolja a sikert. A kettő összekapcsolódik.

**A biztonsági frissítéseket automatikusan kell telepíteni?**  
Az operációsrendszer-csomagoknál ez gyakran ésszerű, feltéve, hogy vannak mentések, és a futás után ellenőrzik az eredményt. Fontos, hogy az érintett szolgáltatások is újrainduljanak. A PHP-nál ellenkező esetben a régi folyamatok a sebezhető kóddal a memóriában maradnak.

**Hogyan igazolom, hogy egy javítás valóban hat?**  
A telepített csomagállapottal és a csomag changelogjában szereplő CVE-számokkal, a telepítés időpontjával és a futó folyamatok indulási időpontjával, amelynek a telepítés után kell lennie.

**Mit tegyek, ha egy frissítés elront valamit?**  
Erre való a visszaút: egy mentés vagy pillanatkép a frissítés előtt, és egy leírt folyamat a visszagörgetéshez. Biztonsági frissítéseknél a visszagörgetésnek kivételnek kell lennie, és átmeneti intézkedéssel kell párosítani.

## Források

- [php.net: biztonsági közlemények](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)