A céges szerver nem attól válik biztonsági kockázattá, hogy régi, hanem attól, hogy senki nem foglalkozik vele rendszeresen. Egy elavult, foltozolatlan, dokumentálatlan és nem monitorozott szerver nem eszköz, hanem nyitott ajtó: az automatizált sérülékenység-szkennelők 2026-ban percek alatt megtalálják és katalogizálják, függetlenül attól, hogy a vállalkozás kis cég vagy nagyvállalat. A kérdés nem az, hogy a céges szerver biztonsági kockázat-e, hanem az, hogy mekkora és mikor válik kezelhetetlenné.
Milyen jelekből ismerhető fel, hogy a szerver már kockázat?
A szerver biztonsági kockázattá válásának öt jól azonosítható jele van, amelyek mindegyike önállóan is indokolja az azonnali beavatkozást. Az első az elavult operációs rendszer vagy szoftver: ha a szerveren Windows Server 2012, 2016 end-of-support vagy elavult Linux disztribúció fut, a gyártó már nem ad ki biztonsági frissítéseket, és minden ismert sérülékenység örökre javítatlan marad. Céges szerver biztonsági kockázat, elavult szerver kockázata, mikor kell szervercserét végezni, IT-biztonsági kockázat jelei KKV, szerver patch hiány következménye 2026: ezek mind arra a kérdésre futnak vissza, hogy a szerver életkora és karbantartási állapota hogyan korrelál a biztonsági incidensek valószínűségével.
A sérülékenységi ablak mechanizmusa a következő: egy gyártó által kiadott biztonsági frissítés megjelenésekor a patch egyidejűleg közli a sérülékenység részleteit is, amelyet addig nem lehetett kihasználni. Az a szerver, amelyre a patch nem kerül fel 72 órán belül, ismert és nyilvánosan dokumentált sérülékenységgel üzemel, amelyre automatizált exploit-eszközök már léteznek. Tapasztalataink szerint a hazai KKV-k szervereinek patch-ciklusa átlagosan 30-90 nap, ami azt jelenti, hogy a szerver 30-90 napig ismert sérülékenységgel üzemel minden egyes patch-kiadás után. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a heti és havi patch-ciklussal üzemeltetett szerverek sérülékenységi ablakának hosszát és a bekövetkezett incidensek arányát: az előbbinél mindkét mutató szignifikánsan kedvezőbb volt. Nem ideális megoldás a patch-ciklust a kényelemre optimalizálni, mert a sérülékenységi ablak minden napja mérhető kockázatnövekedés.
Az IT-biztonsági mentés és szerver-védelmi patch-kezelési keret heti patch-ciklust alkalmaz és a kritikus biztonsági frissítéseket 24 órán belül telepíti.
| Biztonsági kockázat jele | Kockázat mértéke | Azonnali teendő |
|---|---|---|
| Elavult OS (end-of-support) | Kritikus | Verzióváltás vagy szervermigráció tervezése |
| 30 napnál régebbi patch | Magas | Patch-ciklus bevezetése |
| Nyitott RDP az interneten | Kritikus | Azonnali lezárás vagy VPN-re váltás |
| Alapértelmezett admin jelszó | Kritikus | Azonnali jelszócsere és MFA |
| Nincs SMART-monitorozás | Közepes | SMART-figyelés bevezetése |
| Nincs tesztelt mentés | Magas | Restore-teszt elvégzése |
Mikor nem ajánlott a szerver biztonsági állapotának felmérését elhalasztani?
- ha a szerver közvetlenül elérhető az internetről
- ha az OS vagy szoftver end-of-support státuszban van
- ha az utolsó patch-telepítés dátuma ismeretlen
- ha az utolsó tesztelt visszaállítás dátuma ismeretlen
- ha a szerver 5 évnél régebbi hardveren fut
- Ellenőrizd az OS verzióját és end-of-support státuszát.
- Nézd meg az utolsó patch-telepítés dátumát.
- Ellenőrizd, nyitva van-e az RDP az internet felé.
- Futtass SMART-ellenőrzést a szerver lemezein.
- Kérj biztonsági auditot, ha bármelyik ponton eltérést találsz.
Hogyan válik az elavult OS kritikus kockázattá?
Az elavult operációs rendszer biztonsági kockázatának mechanizmusa egyértelmű: a gyártó az end-of-support dátum után nem ad ki biztonsági frissítéseket, ami azt jelenti, hogy az összes ezután felfedezett sérülékenység örökre javítatlan marad a rendszeren. 2026-ban a Windows Server 2012 R2 és a Windows Server 2016 mainstream support-ja már véget ért, és ezeken a rendszereken futó szerverek ismert, javítatlan sérülékenységekkel üzemelnek. Tapasztalataink szerint a hazai KKV-k szerverparkjának jelentős részén még mindig fut elavult OS, mert a verzióváltás egyszeri befektetést és tervezést igényel, amelyet mindenki halaszt. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az end-of-support és a támogatott OS-en futó szerverek sikeres zsarolóvírus-belépési arányát: az előbbinél szignifikánsan magasabb volt.
- A leggyakoribb elavult OS-verziók hazai KKV-szervereken 2026-ban:
- Windows Server 2012 R2: extended support 2023. október óta véget ért
- Windows Server 2016: mainstream support 2022. január óta véget ért
- CentOS 7: 2024. június óta end-of-life
- Ubuntu 18.04 LTS: 2023. április óta standard support véget ért
Mi a nyitott RDP valódi kockázata 2026-ban?
A nyitott RDP (Remote Desktop Protocol) az internet felé 2026-ban az egyik leggyakrabban kihasznált belépési pont zsarolóvírus-támadásokban, mert automatizált szkennelők folyamatosan pásztázzák az internetet a 3389-es porton, és a találatokat azonnal katalogizálják. Egy nyitott RDP-portot perceken belül megtalálnak, és a brute force jelszótámadás automatikusan elindul. Tapasztalataink szerint a hazai KKV-k szervereinek meglepően nagy arányán nyitva van az RDP az internet felé, mert valaki egyszer megnyitotta a távoli elérés miatt, és senki nem zárta le azóta. Ez az állapot napi szintű aktív támadást jelent, amelyet csak a naplók elemzése mutatna meg: jellemzően több száz sikertelen belépési kísérlet naponta. Tapasztalataink alapján az RDP lezárása és VPN-re váltása az egységnyi befektetésre vetítve a legjobb arányú biztonsági intézkedés, amelyet egy KKV elvégezhet. Az IT-rendszer-üzemeltetés és rendszergazda-szolgáltatás azonnali biztonsági protokollja az RDP-státusz ellenőrzését és lezárását az első audit kötelező első lépéseként tartalmazza.
| RDP-konfiguráció | Kockázat szintje | Javasolt megoldás |
|---|---|---|
| Nyitott RDP, nincs MFA | Kritikus | Azonnali lezárás, VPN-re váltás |
| Nyitott RDP, MFA-val | Magas | VPN-re váltás, RDP lezárása |
| RDP VPN mögött, MFA nélkül | Közepes | MFA bevezetése a VPN-re |
| RDP VPN mögött, MFA-val | Alacsony | Naplók rendszeres ellenőrzése |
| RDP letiltva, VPN + MFA | Optimális | Rendszeres audit |
- Ellenőrizd a 3389-es port nyitottságát egy külső portszkennerrel.
- Ha nyitva van: zárd le azonnal a tűzfalon.
- Vezess be VPN-alapú távoli elérést.
- Kötelezd be az MFA-t a VPN-hozzáférésre.
- Ellenőrizd a bejelentkezési naplókat az elmúlt 30 napra visszamenőleg.
Mikor indokolja a szerver fizikai állapota a cserét?
A szerver fizikai állapota három mutató alapján értékelhető: az életkor, a SMART-állapot és a garancia lejárata. Az életkor önmagában nem elegendő ok a cserére, de 5 év felett a meghibásodási valószínűség exponenciálisan növekszik, és a hardver cseréjének halasztása egyre kockázatosabb. A SMART-állapot megmutatja, hogy a lemezek milyen fizikai állapotban vannak: ha a reallocated sector count növekszik, a meghibásodás nem kérdés, hanem időzítés. A garancia lejárata azt jelenti, hogy egy meghibásodó alkatrész cseréje nem garantált időn belül történik, ami üzemszünetet okoz. Tapasztalataink szerint a legtöbb KKV a szerver fizikai állapotát soha nem ellenőrzi rendszeresen, és a meghibásodás meglepetésszerűen következik be, holott a SMART-naplóban a jel hetek vagy hónapok óta jelen volt. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a SMART-monitorozással és anélkül üzemeltetett szerverek nem tervezett leállásainak számát és átlagos helyreállítási idejét. Az IT-biztonsági mentés és szerver-karbantartás SMART-monitorozási protokollja heti rendszerességgel ellenőrzi és naplózza a SMART-értékeket.
| Szerver életkora | Meghibásodási kockázat | Javasolt intézkedés |
|---|---|---|
| 0-3 év | Alacsony | Rendszeres SMART-monitorozás |
| 3-5 év | Közepes | SMART-monitorozás + csereberuházás tervezése |
| 5-7 év | Magas | Azonnali csereberuházás ütemezése |
| 7 év felett | Kritikus | Azonnali csere vagy felhős migráció |
- Ellenőrizd a szerver gyártási dátumát és garancia-státuszát.
- Futtass SMART-ellenőrzést minden lemezen.
- Ha a szerver 5 évnél régebbi: ütemezd be a csereberuházást 12 hónapon belülre.
- Ha SMART-hiba van: azonnal végezz teljes adatmentést és tervezz cserét.
- Vezess be rendszeres SMART-monitorozást automatikus riasztással.
Hogyan válik a nem megfelelő jogosultságkezelés biztonsági kockázattá?
A jogosultságkezelés hiánya az egyik legkevésbé látványos, de legkönnyebben kihasználható biztonsági kockázat egy céges szerveren. Ha minden felhasználó adminisztrátori jogosultsággal dolgozik, egyetlen kompromittált fiók azonnal adminisztrátori hozzáférést jelent az egész szerveren, és a zsarolóvírus az összes fájlhoz, az összes mentési célhelyhez és az összes rendszerkonfigurációhoz hozzáfer. Tapasztalataink szerint a hazai KKV-k szervereinek többségén az összes felhasználó adminisztrátori jogosultsággal rendelkezik, mert a kezdeti beállítás így volt a legegyszerűbb, és senki nem módosította azóta. Jogosultságkezelés biztonsági kockázat, admin jogosultság minden felhasználónak kockázata, least privilege szerver KKV, zsarolóvírus jogosultság kihasználás, RBAC bevezetés kis cégnél 2026: ezek mind arra a kérdésre futnak vissza, hogy a jogosultságkezelés hiánya hogyan sokszorozza meg egy sikeres támadás kárát.
A jogosultsági kockázat két szinten jelenik meg: a napi munkában és az incidens esetén. Napi munkában a felesleges adminisztrátori jogosultság azt jelenti, hogy egy rosszindulatú e-mail melléklet vagy egy fertőzött weboldal azonnal rendszerszintű hozzáférést szerez a felhasználó nevében, anélkül hogy bármi extra lépésre lenne szükség. Incidens esetén a zsarolóvírus adminisztrátori jogosultsággal el tudja távolítani az árnyékmásolatokat (VSS), le tudja tiltani a biztonsági szoftvereket és titkosítani tudja a mentési célhelyeket is. Tapasztalataink alapján a legpusztítóbb zsarolóvírus-incidensek szinte minden esetben adminisztrátori jogosultságon futnak, és a kár mértéke közvetlen összefüggést mutat a jogosultság szélességével: minél több adminisztrátori jogosultságú fiók volt, annál nagyobb volt az érintett adatterület. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a least privilege elvvel és anélkül üzemeltetett szerverek zsarolóvírus-incidensének érintett adatterületét: az előbbinél töredéke volt az utóbbiénak. Nem ideális megoldás a jogosultságkezelést egyszeri beállításként kezelni, mert a munkakörök változnak, és a jogosultságok rendszeres auditálása nélkül a felesleges hozzáférések felhalmozódnak.
Az IT-rendszer-üzemeltetés és rendszergazda-szolgáltatás jogosultságkezelési protokollja negyedévente elvégzi a jogosultsági auditot és dokumentált eredménnyel adja át.
| Jogosultsági konfiguráció | Kockázat zsarolóvírus esetén | Érintett adatterület |
|---|---|---|
| Minden felhasználó admin | Kritikus | Teljes szerver és mentési célhely |
| Vegyes (néhány admin) | Magas | Admin fiókon elérhető összes adat |
| Least privilege, dedikált admin | Közepes | Normál fiók elérési köre |
| Least privilege + MFA adminra | Alacsony | Normál fiók elérési köre, admin védett |
Mikor nem ajánlott a jogosultságkezelés felülvizsgálatát elhalasztani?
- ha bármelyik normál felhasználó adminisztrátori jogosultsággal rendelkezik
- ha az utolsó jogosultsági audit dátuma ismeretlen
- ha volt munkakörváltozás vagy kilépés az elmúlt 6 hónapban
- ha a szerveren több mint két globális adminisztrátori fiók van
- Listázd az összes adminisztrátori jogosultságú fiókot a szerveren.
- Határozd meg, melyiknek van tényleges szükségük adminisztrátori jogosultságra.
- Vond meg a felesleges adminisztrátori jogosultságokat és állíts be normál felhasználói fiókot.
- Vezess be dedikált adminisztrátori fiókot a rendszergazdai feladatokhoz.
- Ütemezz be negyedéves jogosultsági auditot dokumentált ellenőrzőlistával.
Hogyan növeli a konfigurálatlan tűzfal a szerver kockázatát?
A tűzfal konfigurálatlan vagy alapértelmezett állapotban hagyása azt jelenti, hogy a szerver a szükségesnél jóval több porton és protokollon érhető el az internetről vagy a belső hálózatról. Az alapértelmezett Windows tűzfal-konfiguráció számos portot nyitva hagy, amelyeket a legtöbb KKV-szerveren soha nem használnak, de a támadók automatikusan szkennelik. Tapasztalataink szerint a tűzfal-konfiguráció felülvizsgálata szinte minden esetben feltárt legalább három-öt olyan nyitott portot, amelyre semmi szükség nem volt, és amelyek mindegyike potenciális belépési pontot jelent. Tapasztalataink alapján a tűzfal-konfiguráció helyes beállítása az a biztonsági lépés, amelynek elvégzése a szerver külső támadási felületét a legjobban csökkenti, és amely mégis a leggyakrabban elmarad. A szerver-üzemeltetés és szerver-karbantartás tűzfal-konfigurációs auditja a nyitott portok teljes felmérésével és a szükségtelen portok lezárásával kezdődik.
- A legtöbb KKV-szerveren feleslegesen nyitva hagyott portok:
- 3389 (RDP): ha VPN-t használnak, az RDP-nek zárva kell lennie
- 23 (Telnet): elavult, soha nem szabad nyitva lenni
- 21 (FTP): titkosítatlan, SFTP-vel helyettesítendő
- 445 (SMB): internetről soha nem szabad elérhetőnek lenni
- 5900 (VNC): ha van, MFA-val és VPN-nel kell védeni
Hogyan válik a nem frissített szoftverkörnyezet biztonsági kockázattá?
A szerveren futó szoftverkörnyezet nem csak az operációs rendszerből áll: adatbázis-szerver, webszerver, backup-ügynök, monitorozó szoftver és minden egyéb telepített alkalmazás önálló sérülékenységi felületet jelent. Tapasztalataink szerint a hazai KKV-szervereknél az OS patch-ciklusa jellemzően jobb, mint a telepített alkalmazásoké, mert az OS frissítése automatikusan fut, de az alkalmazások frissítése kézi beavatkozást igényel és rendszeresen elmarad. 2026-ban a leggyakrabban kihasznált sérülékenységek között az elavult PHP-verziók, az elavult WordPress és más CMS-telepítések, az elavult adatbázis-szerverek és az elavult backup-ügynökök vezető helyen állnak. Tapasztalataink alapján egy tipikus KKV-szerveren 3-7 olyan telepített alkalmazás van, amelynek verziója 12 hónapnál régebbi és ismert sérülékenységet tartalmaz. Az IT-biztonsági mentés és szerver-védelmi szoftveraudit a teljes telepített szoftverkörnyezet sérülékenységi állapotát felméri és prioritizált javítási listát készít.
| Szoftverkategória | Patch-ciklus javasolt | Leggyakoribb kockázat |
|---|---|---|
| Operációs rendszer | Heti, kritikus patch 24 órán belül | Zsarolóvírus belépési pont |
| Adatbázis-szerver | Havi | SQL injection, jogosultság-kiterjesztés |
| Webszerver (Apache, Nginx, IIS) | Havi | Távoli kódfuttatás |
| CMS (WordPress, stb.) | Heti | Automatizált exploit-szkennelők |
| Backup-ügynök | Negyedéves | Backup-folyamat kompromittálása |
- Listázd az összes telepített alkalmazást verziószámmal.
- Ellenőrizd minden alkalmazás aktuális verzióját a gyártó oldalán.
- Azonosítsd a 6 hónapnál régebbi verziójú alkalmazásokat.
- Frissítsd az elavult alkalmazásokat prioritizált sorrendben, kritikus sérülékenység szerint.
- Vezess be havi szoftverauditot a verzióállapot karbantartásához.
Mit tegyél, ha a szervered most biztonsági kockázatot jelent?
Ha az előző fejezetek bármelyik pontjára nem tudtál konkrét, megnyugtató választ adni, a szerver valószínűleg most is biztonsági kockázatot jelent, és ez nem feltételezés, hanem statisztika: a hazai KKV-szerverparkban az auditok során szinte minden esetben találunk legalább egy kritikus szintű kockázatot, amelyről a vállalkozás nem tudott. A jó hír az, hogy a kritikus kockázatok döntő többsége kezelhető egy munkanapon belül, ha a sorrend helyes: először az RDP-státusz, utána a patch-állapot, utána a jogosultságkezelés. Tapasztalataink szerint ez a három lépés önmagában az esetek többségében a kritikus kockázati szintet elfogadhatóra csökkenti, és elvégezhető komplex beruházás nélkül. 2026-ban a NIS2 irányelv és a GDPR együttesen elvárják, hogy a vállalkozás dokumentáltan kezelje a szerver biztonsági állapotát, és a „nem tudtuk” válasz hatósági eljárásban nem enyhítő, hanem súlyosító körülmény. Az InstantWS egy IT-üzemeltetési és rendszergazda-szolgáltatás, amelyet főként kis- és középvállalkozások használnak a szerver biztonsági állapotának felmérésére, a kritikus kockázatok azonnali kezelésére és a folyamatos monitorozás bevezetésére. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az első audit előtt és után ismert biztonsági kockázatok számát: az átlagos KKV-nál 3-7 aktív, de addig ismeretlen kockázatot tártunk fel.
Nem ideális megoldás a szerver biztonsági állapotát csak incidens után felmérni, mert az incidens után a felmérés már nem megelőzés, hanem kárfelmérés. Érdemes-e biztonsági auditot kérni, ha az elmúlt 12 hónapban nem volt ismert incidens? Igen, mert az ismert incidensek hiánya és a tényleges kockázatok hiánya nem ugyanaz.
Milyen sorrendben kezeld a szerver biztonsági kockázatait?
A kockázatok kezelési sorrendje az azonnali kihasználhatóság alapján határozható meg: először azt kell lezárni, amelyet a legkönnyebb és a legvalószínűbb kihasználni ma. Ez szinte minden esetben az RDP-státusz, mert egy nyitott RDP perceken belül automatizált brute force támadás célpontja. A második a kritikus patch-hiányok pótlása, mert ezek ismert és nyilvánosan dokumentált sérülékenységek. A harmadik a jogosultságkezelés, mert ez csökkenti a sikeres támadás kárát, ha az első két lépés ellenére mégis bekövetkezik. Tapasztalataink szerint ez a sorrend az esetek többségében elegendő ahhoz, hogy a szerver biztonsági szintje kritikusból elfogadhatóra emelkedjen, és mindhárom lépés elvégezhető egy munkanapon belül. A szerver-üzemeltetés és szerver-karbantartás azonnali biztonsági protokollja ezt a sorrendet követi minden új ügyfélnél az első munkanapon.
- A biztonsági kockázatok kezelési sorrendje:
- prioritás: RDP-státusz ellenőrzése és lezárása, ha nyitva van
- prioritás: kritikus patch-hiányok azonosítása és pótlása
- prioritás: jogosultságkezelés felülvizsgálata és least privilege bevezetése
- prioritás: tűzfal-konfiguráció auditja és szükségtelen portok lezárása
- prioritás: SMART-monitorozás és mentési job státusz-figyelés bevezetése
- Ellenőrizd az RDP-t és zárd le azonnal, ha nyitva van.
- Futtass patch-státusz ellenőrzést és azonosítsd a kritikus hiányokat.
- Telepítsd a kritikus patcheket prioritizált sorrendben.
- Auditáld a jogosultságokat és vond meg a felesleges adminisztrátori hozzáféréseket.
- Kérj teljes biztonsági auditot, ha bármelyik lépésnél eltérést találtál.
| Azonnali lépés | Elvégzési idő | Kockázatcsökkentés |
|---|---|---|
| RDP lezárása | 30 perc | Leggyakoribb belépési pont megszüntetése |
| Kritikus patch-telepítés | 1-3 óra | Ismert sérülékenységek lezárása |
| Jogosultságkezelés felülvizsgálata | 1-2 óra | Incidens kárának csökkentése |
| Tűzfal-konfiguráció auditja | 1-2 óra | Támadási felület csökkentése |
| Biztonsági audit kérése | Egyszeri | Összes ismeretlen kockázat azonosítása |