EOL szerver és NIS2: mikor válik az elavult hardver konkrét auditakadállyá?

Ez a cikk a NIS2 megfelelés hardver szempontból sorozat második része. Az első részben lefektettük az alapokat: miért érinti a NIS2 a hardvert, és melyek a négy fő kockázati terület. Ebben a részben az EOL és EOS státuszú szerverek auditakadályait, és az EOL szerver NIS2 megfelelés kihívásait vizsgáljuk meg részletesen.

Az EOL szerver kérdése a NIS2-megfelelési felkészülés egyik legtöbbet félreértett területe. A sorozat nyitócikkében végigvettük, hogy az IT infrastruktúra hardver rétege milyen NIS2-vonatkozású kockázatokat hordoz. Ezek az elavult eszközök, a nem patchelt firmware, a nyilvánosan elérhető menedzsment interfészek, a hiányzó redundancia. Ez a cikk az első és legkönnyebben mérhető területbe megy mélyre: az EOL és EOS státuszú szerverekbe. Sok IT-vezető úgy gondolja, hogy a régi szerver addig nem jelent problémát, amíg fut – az audit szempontjából viszont egy gyártói biztonsági frissítéseket már nem kapó eszköz egészen más megítélés alá esik. A 2026. június 30-i kötelező kiberbiztonsági audit határideje közeledik. A 4000–7500 érintett magyarországi szervezet egy jelentős részénél az EOL infrastruktúra a legkönnyebben azonosítható. Legtöbbjüknél ez a legritkábban kezelt kockázati pont.

Mit jelent EOL és EOS a NIS2-es audit kontextusában?

Az EOL (End of Life) és az EOS (End of Support) szakkifejezések nem ugyanazt jelölik, és a különbség az audit szempontjából is számít, pláne a EOL szerver NIS2 megfelelés esetén.

Az EOL az eszköz forgalmazásának végét jelenti: a gyártó nem értékesít tovább új egységeket abból a modellből. Az EOS ennél súlyosabb: ettől a dátumtól kezdve a gyártó nem ad ki hibajavítást, biztonsági patchet, firmware-frissítést az adott hardverplatformhoz. A NIS2 kontextusában az EOS az, ami közvetlen kockázatot jelent – az EOL önmagában még nem.

A 2024. évi LXIX. törvény, amely a NIS2 irányelvet ülteti át a hazai jogrendbe, kockázatalapú megközelítést alkalmaz. Nem nevesít konkrét szervergenerációkat, hanem elvárja, hogy az érintett szervezetek azonosítsák és kezeljék azokat az eszközöket, amelyeknél a sérülékenységek javítása nem lehetséges. Egy EOS státuszú szerver definíció szerint idetartozik.

A 40%-os vakfolt – az EOL eszközök a támadók legkedveltebb célpontjai

Az elmélet mögött kemény számok állnak. A Cisco Talos 2025-ös éves biztonsági jelentése szerint az év legtöbbet célzott sérülékenységeinek közel 40%-a olyan eszközöket érintett, amelyek már EOS státuszban vannak, és amelyekhez gyártói patch nem érhető el. Ezek az eszközök nem azért kerülnek a célkeresztbe, mert különösen érdekesek. A támadó tudja, hogy a sérülékenység soha nem lesz befoltozva.

Az IBM X-Force 2026-os fenyegetéselemzése megerősíti ezt a képet: a nyilvánosan elérhető alkalmazások és interfészek elleni támadások 44%-kal nőttek egy év alatt. Többek között azért, mert az AI-eszközök lehetővé teszik, hogy a támadók villámgyorsan azonosítsák a javítatlan, sebezhető rendszereket. Egy EOS szerver ilyen környezetben nem csupán üzemeltetési kockázat – aktív biztonsági lyuk.

Dell PowerEdge generációs térkép – mikor jár le a gyártói support?

A Dell a ProSupport keretében generációnként határozza meg az EOS dátumokat. Az alábbi tájékoztató áttekintés a saját szerverleltár rendezéséhez nyújt kiindulópontot; a pontos, modellszintű dátumokat mindig a Dell hivatalos termékéletciklus-oldalán érdemes ellenőrizni.

11. generáció (R610, R710, R810, R910): a gyártói biztonsági támogatás már évekkel ezelőtt megszűnt. Ezek az eszközök ma auditakadályként funkcionálnak, és cseréjük nem halasztható tovább.

12. generáció (R620, R720, R820): szintén EOS státuszban van. A biztonsági frissítések 2023-ban értek véget, a meglévő CVE-k tehát javítatlanok maradnak.

13. generáció (R430, R530, R630, R730): a mainstream support 2025 végén zárul le több modellnél. Ezek a szerverek 2026-ban már EOS küszöbén állnak vagy azt átlépték.

14. generáció (R440, R540, R640, R740): jellemzően 2028-ig kap biztonsági frissítéseket, ez a leggyakoribb „biztonságos zóna” a felkészülő szervezetek gépparkjában.

15. generáció (R650, R750) és 16. generáció (R660, R760): a következő évekre szólóan biztonságos életciklus-pozícióban vannak.

Az iDRAC firmware-re külön figyelj! Az iDRAC9 tovább kap frissítéseket a 14. és 15. generációs platformokon, de az iDRAC8 (13. gen) és az iDRAC7 (12. gen) biztonsági fejlesztései már nem folytatódnak. Ez önmagában is auditproblémát jelenthet, hiszen a CISA BOD 23-02 direktíva kifejezetten nevesíti az iLO és iDRAC típusú out-of-band menedzsment interfészeket mint kritikus védelmi területeket.

HPE ProLiant generációs térkép

A HPE a Pointnext Services keretében hasonló struktúrát követ, de eltérő generációs jelölésrendszerrel. A pontos adatokat a HPE hivatalos termékéletciklus-kereső eszközzel tudod lekérdezni termékszám alapján.

Gen8 (BL460c, DL360p, DL380p): a gyártói biztonsági támogatás 2023-ban ért véget – az ezeken a platformokon futó iLO4 firmware szintén nem kap további biztonsági frissítéseket.

Gen9 (DL360, DL380, DL560): a mainstream support 2024–2025 fordulóján zárul le a legtöbb modellnél, egyes konfigurációknál már lezárult.

Gen10 és Gen10 Plus: jellemzően 2027–2028 körülig kapnak biztonsági frissítéseket, ez a jelenlegi felkészülési időszakban még biztonságos zóna.

Gen11: az aktuális biztonságos generáció, amelyre a szerverdokk.hu refurbished kínálata is épít.

Hogyan befolyásolja konkrétan az EOS státusz az auditot?

Az SZTFH-val szerződött auditorok a kockázatmenedzsment-keretrendszer részeként vizsgálják az eszközleltárt. Ha az eszközleltárban szerepel egy EOS szerver, az auditor három kérdést tesz fel: van-e kompenzáló kontroll? Dokumentált-e a kockázat? Van-e csereütemterv?

Ha ezekre nincs kielégítő válasz, az nem automatikus megfelelési bukás, de súlyos megállapítást generál. A PwC NIS2 auditfelkészítési tapasztalatai szerint az érintett szervezeteknek kockázatmenedzsment-keretrendszert kell működtetniük. Az ilyen kockázatokat azonosítják, értékelik és kezelik – tehát a kezelés hiánya önmagában megfelelési hiányosság.

Három konkrét auditpont, ahol az EOL szerver problémává válik:

Sérülékenységkezelés: az auditor ellenőrzi, hogy a szervezet képes-e a szerverei ismert CVE-it javítani. Egy EOS eszköznél a válasz strukturálisan nem – ez dokumentált kockázatot kell, hogy eredményezzen.

Hozzáférési kontroll: ha az EOS szerveren érzékeny adatokat kezelő alkalmazás fut. A mögöttes platform biztonsági állapota nem garantálható – ez hozzáférési kontroll hiányosságként is megjelenik az auditban.

Üzletmenet-folytonosság: a BCP/DR terv csak akkor fogadható el az auditornak, ha az abban szereplő infrastruktúra életciklusa tervezhető. Egy EOS szerverre épített helyreállítási terv önmagában kockázatot hordoz.

Mit tegyél, ha EOL szerverre épül az infrastruktúra?

Ha az eszközleltárod EOS szervereket tartalmaz, az audit előtt három lépés elvégzése szükséges.

Első lépés: dokumentáld a kockázatot. Az auditnak nem az a feltétele, hogy minden eszközöd friss legyen – hanem az, hogy a kockázatot ismerd, értékeld és kezeld. Egy írásban rögzített kockázatértékelés, amely tartalmazza az EOS dátumot, az érintett rendszert és a kompenzáló kontrollokat, már teljesíti az alapvárást.

Második lépés: kompenzáló kontrollok. Ha az EOS szerver nem cserélhető le az audit előtt, a kockázat csökkenthető hálózati szegmentációval (az eszköz izolálása saját VLAN-ra), a menedzsment interfész lezárásával (iDRAC/iLO internet-elérhetőségének megszüntetése), és fokozott monitorozással. A Cisco Talos elemzése külön kiemeli: az EOS eszközök esetében az EDR-ből való kiesés önálló vakfoltot jelent – ezt monitorozással részben kompenzálni lehet.

Harmadik lépés: csereütemterv. Az auditor elfogadja, ha van dokumentált, reális ütemterve a problémás eszköz kivonásának. Nem kell azonnalinak lennie – de léteznie kell, és tartalmaznia kell a céldátumot.

Refurbished szerver és EOS: mi a különbség, és miért számít?

A refurbished szerver és az EOS szerver nem szinonim. Egy felújított Dell PowerEdge R740 vagy HPE DL380 Gen10 például mai napig a gyártói support hatálya alá esik. A fizikai állapota nem befolyásolja a firmware és a biztonsági frissítések elérhetőségét, feltéve, hogy az eszköz még nem érte el az EOS dátumát.

A felújított szerverek NIS2 szempontból releváns előnye éppen ebben rejlik. Lehetővé teszik, hogy egy infrastruktúra-csere az EOL szerver kivonásakor ne az újgép árával számoljon, hanem a szükséges életciklus-maradék alapján optimalizálja a beruházást. Ha egy szervezetnek 14. generációs kapacitásra van szüksége és az EOS dátum 2028, egy refurbished R740 pontosan ezt biztosítja – töredék áron.

A szerverdokk.hu-tól érkező refurbished szerverek gyári visszaállítással és frissített firmware-rel kerülnek kiszállításra, amely az iDRAC/iLO alapkonfiguráció biztonságossá tételének első lépése.

Összefoglalás és következő lépések

Az EOL/EOS szerver nem attól lesz auditprobléma, hogy régi – hanem attól, hogy a szervezet nem tudja kezelni a belőle fakadó kockázatot. Az audit előtt elvégzendő minimális lépések: eszközleltár EOS dátumokkal, dokumentált kockázatértékelés az EOS eszközökhöz, kompenzáló kontrollok és csereütemterv a kritikus rendszerekhez.

A sorozat következő részeiben a NIS2 hardvermegfelelés többi kritikus területét járjuk végig. A 3. cikkben az iDRAC és iLO menedzsment interfészek biztonságát vesszük górcső alá lépésről lépésre: mi kerüljön dedikált VLAN-ra, hogyan zárd le az alapértelmezett hozzáféréseket, és mit vár el tőled konkrétan az auditor ezen a területen. A 4. cikkben a firmware patch menedzsment kerül sorra – friss CVE-példákkal, amelyek megmutatják, mit jelent a valóságban egy elmaradt frissítési ciklus. Az 5. cikkben a fizikai redundanciát tárgyaljuk: dual PSU, RAID-konfiguráció, UPS – és azt, hogy mindez hogyan kapcsolódik a BCP/DR terv auditkövetelményeihez.

Mi jön a sorozat következő részében?

Az EOL/EOS kérdés megoldása után a következő leggyakoribb auditprobléma a szerver remote menedzsment interfészének – az iDRAC-nak és az iLO-nak – a konfigurációja. Ezek az out-of-band menedzsment interfészek teljes körű, hálózaton keresztüli hozzáférést biztosítanak a szerverhez, és ha rosszul vannak konfigurálva, egyetlen ellopott jelszó elegendő a teljes szerver feletti kontroll megszerzéséhez. A sorozat következő részében lépésről lépésre végigvezetünk az iDRAC és iLO NIS2-kompatibilis lezárásán.

→ 03. rész: iDRAC és iLO biztonság NIS2 alatt – hogyan zárjuk le a menedzsment interfészt?

Ha bizonytalanok vagytok abban, hogy a meglévő szerverinfrastruktúrátok hol áll az EOS-térkép szempontjából, és szeretnétek EOL szerver NIS2 megfelelésre felkészülni, a szerverdokk.hu csapata segít az eszközleltár összeállításában és a generációs életciklus-értékelésben –vegyétek fel velünk a kapcsolatot!