# Sebezhetőségkezelés a közép- és kisvállalkozásoknál

> Sebezhetőségkezelés kkv-knál: a közlemények forrásai, kockázat szerinti értékelés, döntés, megvalósítás és igazolás a PHP2Shell példáján keresztül.

Forrás: https://phpsos.de/hu/blog/schwachstellenmanagement-mittelstand/  
Á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 sebezhetőségkezelés a közép- és kisvállalkozásoknál egy karcsú, ismétlődő ciklus: a rendszerek ismerete, a közlemények célzott követése, kockázat szerinti értékelés, döntés, megvalósítás és igazolás. Nem a drága eszközök a döntők, hanem az egyértelmű felelősségek és egy olyan sorrend, amely figyelembe veszi az elérhetőséget, az adatokat és a támadási helyzetet. A PHP2Shell jó gyakorlópélda, mert benne minden lépés előfordul.

## Száz közlemény, kevés munkatárs

Hétről hétre újabb biztonsági réseket hoznak nyilvánosságra operációs rendszerekben, programozási nyelvekben, alkalmazásokban és bővítményekben. Egy nagyvállalatnak erre van egy csapata. Egy középvállalkozásnak gyakran van egy IT-vezetője, egy-két rendszergazdája és több külső szolgáltatója. Senki sem tud minden közleményt elolvasni, és nem is kell.

Szűrőre van szükség: mely közlemények érintik a rendszereinket, ezek közül melyik sürgős, és ki foglalkozik vele? Ha ez a szűrő hiányzik, két dolog egyike történik. Vagy mindent figyelmen kívül hagynak, amíg meg nem történik valami, vagy minden közlemény felbolydulást okoz, és az igazán kritikus elvész a zajban.

## A sebezhetőségkezelés ciklusa

A kkv-k számára használható folyamat hat lépésben írható le:

1. **Felmérni, mi fut.** Leltár nélkül nincs összevetés. Mely weboldalakat, szervereket, PHP-verziókat és alkalmazásokat üzemeltet, és hol? Hogyan sikerül ez, azt a [Tudni, mi fut: az összes weboldal és szerver leltára](https://phpsos.de/hu/blog/inventar-websites-server/) mutatja meg.
2. **Közleményeket követni.** Néhány megbízható forrásra feliratkozni: a BSI (a német Szövetségi Információbiztonsági Hivatal) figyelmeztetései, a használt szoftverek gyártóinak közleményei, a Linux-disztribúció biztonsági oldalai, a PHP-nél a php.net nyitóoldala.
3. **Értékelni.** Érint-e minket a közlemény? Ha igen, mennyire sürgős? Erről lejjebb bővebben.
4. **Dönteni.** Kijavítani, átmenetileg védeni, a rendszert elszigetelni vagy a kockázatot tudatosan vállalni. Ki dönthet miről?
5. **Megvalósítani.** Frissítést telepíteni, átmeneti intézkedést beállítani, szolgáltatót megbízni.
6. **Igazolni és nyomon követni.** Valóban lezárult a rés? Mikor váltják le az átmeneti megoldást?

A ciklus ezután elölről kezdődik. Új rendszerek jönnek, a régiek kiesnek, és új közlemények jelennek meg.

A 2. lépéshez egy egyszerű szabály segít: inkább kevés forrást olvasson rendszeresen, mint sokat alkalmanként. Egy tipikus középvállalati webes környezetben többnyire elegendő a BSI-nál működő CERT-Bund (a német szövetségi kormányzat CERT-je) figyelmeztetése, a használt Linux-disztribúció biztonsági közleményei, a CMS- és webshopgyártók oldalai és a php.net nyitóoldala. Határozza meg, ki olvassa ezeket a forrásokat, és erre hozzon létre egy közös postafiókot vagy csatornát, amely nem egyetlen személyhez kötött.

Kiegészítésként érdemes kívülről is rápillantani. A nyilvánosan elérhető rendszerek rendszeres sebezhetőségi vizsgálata megmutatja, hogy látható-e elavult szoftver vagy szükségtelenül nyitott szolgáltatás. Nem helyettesíti a leltárt és a frissítéseket, de feltárja azokat a rendszereket, amelyek egyetlen listán sem szerepelnek.

## Értékelés: mi kerül elsőként sorra

A CVSS-érték, a súlyosság szabványosított besorolása, jó kiindulópont. A saját házon belüli sorrendhez azonban nem elég. Három további kérdés dönt:

| Kérdés | Növeli a sürgősséget | Csökkenti a sürgősséget |
|---|---|---|
| Elérhető a rendszer az internetről? | nyilvános weboldal, webshop, portál | csak belső, VPN mögött |
| Szükséges bejelentkezés a rés kihasználásához? | nem, hitelesítés nélkül | igen, csak rendszergazdáknak |
| Milyen adatokat dolgoz fel a rendszer? | ügyféladatok, fizetések, hozzáférések | nyilvános tartalmak fiókok nélkül |
| Vannak jelentések támadásokról? | támadási kísérleteket jelentettek | nincs ismert kísérlet |
| Van átmeneti intézkedés? | nincs | van, igazolt hatással |

A PHP2Shell megmutatja, hogyan hat együtt mindez. Mindkét rés CVSS v4.0 értéke 9,2, bejelentkezés nélküli kódfuttatást tesznek lehetővé, és nyilvánosan elérhető webszervereket érintenek. A Cloudflare és a Patchstack a médiajelentések szerint támadási kísérletekről számolt be, a BSI pedig a helyzetet 3. riasztási szintűnek minősítette. A php.net átmeneti intézkedései kifejezetten nem nyújtanak teljes védelmet. Minden kérdés ugyanabba az irányba mutat: azonnal cselekedni. Hogy a BSI konkrétan mit javasolt, az [A BSI ajánlásai a PHP2Shellről](https://phpsos.de/hu/compliance/bsi-empfehlungen/) oldalon áll.

## Dönteni és dokumentálni

Nem minden rés zárható le azonnal. Egy régi rendszer PHP 8.1-en fut, amelyhez már nincsenek hivatalos frissítések (lásd a [PHP 8.1 és régebbi: mi érvényes most](https://phpsos.de/hu/php2shell/php-8-1-und-aelter/) oldalt), egy szakalkalmazás pedig még nem bírja a frissítést. Ilyenkor döntésre van szükség, és az nem tartozhat egyedül a technikához.

Egy jó döntési feljegyzés tartalmazza az érintett rendszert, a rést, az értékelést, a választott lehetőséget, az átmeneti intézkedéseket, a felelős személyt és egy időpontot az újbóli felülvizsgálatra. Ha egy kockázatot tudatosan vállalnak, a vezetés dönt, nem a rendszergazda egyedül. A sebezhető függőségek kezeléséről szóló OWASP Cheat Sheet is azt ajánlja, hogy a kockázatvállalás kifejezetten vezetői szinten legyen rögzítve.

> **Tipp:**
> Vezessen egyetlen listát a nyitott sebezhetőségekről állapottal, felelőssel és határidővel. Egy táblázat is elég. Az a fontos, hogy rendszeresen átnézzék, például a vezetéssel tartott havi körben.

## Mi köze ehhez a NIS2-nek és a szolgáltatóknak

A NIS2 hatálya alá tartozó vállalkozásoknál a sebezhetőségek kezelése a kockázatkezelési kötelezettségek része. A részleteket a [NIS2 és a webszerverek biztonsága](https://phpsos.de/hu/compliance/nis2/) írja le. De törvényi kötelezettség nélkül is előny egy dokumentált folyamat, például az ügyfelekkel, a biztosítókkal és a saját vezetéssel szemben.

Sok lépés kiszervezhető, például a közlemények követése vagy a frissítések telepítése. A kockázatokról szóló döntésnek és az átfogó áttekintésnek azonban házon belül kell maradnia. Aki a ciklust teljesen átadja egy szolgáltatónak, vészhelyzetben már nem tudja, egyáltalán mely rendszerei vannak. Hogyan szervezhető meg a megvalósítás rutinként, azt a [Patchmenedzsment folyamatként, nem tűzoltásként](https://phpsos.de/hu/blog/patch-management-prozess/) írja le.

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

- Önnel együtt elkészítjük a weboldalak és szerverek leltárát, minden összevetés alapjaként.
- Követjük az Ön rendszereire vonatkozó közleményeket, és világos szavakkal értékelést adunk ajánlással.
- Döntési feljegyzéseket készítünk elő olyan esetekre, amikor a frissítés nem lehetséges azonnal.
- A [biztonsági monitoringon](https://phpsos.de/hu/leistungen/security-monitoring/) keresztül folyamatosan ellenőrizzük, hogy a rendszerek feltűnővé válnak-e, amíg egy rés még nyitott.

**Összegzés:** A sebezhetőségkezelésnek a közép- és kisvállalkozásoknál nem kell nagynak lennie, de kötelezőnek igen. Aki ismeri a rendszereit, néhány jó forrást olvas és rögzíti a döntéseket, a következő kritikus közleménynél gyorsan és helyesen reagál.


## Gyakori kérdések

**Mi a sebezhetőségkezelés?**  
Egy ismétlődő folyamat, amelynek során a vállalkozás megtudja, értékeli, kijavítja vagy tudatosan vállalja a rendszereiben lévő biztonsági réseket, és az eredményt rögzíti. Nem egy eszközről szól, hanem felelősségekről és döntésekről.

**Elég a CVSS-érték a sorrend meghatározásához?**  
Jó kiindulópont, de nem elég. Emellett az dönt, hogy az érintett rendszer elérhető-e az internetről, milyen adatokat dolgoz fel, és megfigyeltek-e már támadásokat. Egy belső tesztrendszeren lévő magas értékű rés várhatna, a webshopon lévő nem.

**Kell ehhez egy kisvállalkozásnak saját eszköz?**  
Kezdetben nem. Elég a rendszerek gondozott listája, a feliratkozott biztonsági közlemények és egy táblázat a nyitott pontokkal. A sebezhetőségi szkennerek akkor érik meg, ha nő a rendszerek száma, vagy rendszeresen igazolni kell az ellenőrzéseket.

**Szabad egy rést tudatosan nem kijavítani?**  
Igen, ha a kockázatot értékelték, a döntést az illetékes vezetés hozta meg, és írásban rögzítették, lehetőleg átmeneti intézkedésekkel és egy időponttal az újbóli felülvizsgálatra.

## Források

- [BSI](https://www.bsi.bund.de/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [OWASP: Vulnerable Dependency Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)