Az RDP (Remote Desktop Protocol, távoli asztal protokoll) az egyik leggyakrabban kihasznált belépési pont a céges hálózatokba 2026-ban. Ez az állítás különösen igaz a KKV-szegmensre, ahol az RDP-hozzáférést legtöbbször gyorsan, konfigurálás nélkül nyitják meg, majd évekig felügyelet nélkül hagyják. A protokoll önmagában nem hibás: a Microsoft által fejlesztett távoli elérési megoldás legitim üzemeltetési igényt elégít ki, de az alapértelmezett 3389-es porton, erős hitelesítés nélkül, internetre nyitva olyan támadási felületet teremt, amelyet automatizált eszközökkel percek alatt azonosítanak és kihasználnak. A KKV-k különösen kiszolgáltatottak, mert az RDP-t sokszor átmeneti megoldásként nyitják meg, amely aztán állandósul, miközben a hozzáférés körüli kontrollok nem fejlődnek a fenyegetési környezettel együtt.

Miért célozzák az automatizált támadások elsősorban az RDP-t

Az RDP 2026-ban a zsarolóvírus-incidensek egyik leggyakoribb kiindulópontja a KKV-szegmensben. Az automatizált keresőrobotok folyamatosan pásztázzák az internetet nyitott 3389-es portok után, és a megtalált célpontokat azonnal felveszik a brute force-kampányok listájára. A brute force támadás lényege egyszerű: a támadó szoftver másodpercenként több száz jelszókombinációt próbál ki, amíg érvényes belépési adatot nem talál. Tapasztalataink alapján egy internetre nyitott RDP-port átlagosan néhány órán belül megjelenik az automatizált szkennelési listákon, és az első belépési kísérletek rendszerint napokon belül megindulnak. Ezt az összefüggést különböző méretű KKV-k szervernaplóinak elemzése során figyeltük meg következetesen.

Az RDP célba vételének oka nem véletlen: a protokoll egyetlen sikeres belépéssel közvetlen, grafikus hozzáférést biztosít a szerverhez vagy munkaállomáshoz, ami zsarolóvírus telepítéséhez, adatkiszivárogtatáshoz és a teljes hálózat feltérképezéséhez elegendő. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a nyitott és a VPN mögé helyezett RDP-hozzáférések naplóit: az előbbiben napi több ezer belépési kísérlet volt rendszeres, az utóbbiban ilyen forgalom nem jelent meg.

Megéri-e az RDP-t teljesen letiltani, ha a cég távoli munkavégzést igényel? Nem feltétlenül, de a nyitott, hitelesítés nélküli RDP helyett minden esetben biztonságosabb alternatíva létezik, amelyek nem korlátozzák a munkavégzést.

Nem ideális megoldás az RDP megtartása az alapértelmezett beállításokkal akkor, ha a szerveren ügyféladatok, számviteli rendszer vagy bármilyen kritikus adat található. Ilyen esetben az RDP kizárólag VPN-kapcsolaton belülről legyen elérhető, kétfaktoros hitelesítéssel megerősítve.

Hozzáférési módBiztonsági szintBelépési kísérlet kockázataKKV-s megfelelőség
Nyitott RDP (3389)Kritikusan alacsonyFolyamatos, automatizáltNem ajánlott
RDP nem szabványos portonAlacsonyCsökkentett, de fennállóNem elegendő
RDP VPN mögöttKözepes-magasMinimálisÁtmeneti megoldás
RDP VPN + 2FAMagasElhanyagolhatóAjánlott
ZTNA-alapú hozzáférésNagyon magasGyakorlatilag nullaLegjobb gyakorlat
  • Automatizált szkennelés: a nyitott RDP-portokat perceken belül azonosítják a neten

  • Credential stuffing: kiszivárgott jelszólistákból próbálkoznak legitim belépési adatokkal

  • Brute force: szótáralapú vagy teljes kombinációs jelszókipróbálás

  • Pass-the-hash: ellopott hitelesítési tokennel belépési adat nélküli hozzáférés

  1. Nyitott RDP-portok azonosítása a cég összes eszközén

  2. Azononnali tűzfalszabály: 3389-es port zárása külső hozzáférés elől

  3. VPN-kapu beállítása az RDP elé

  4. Kétfaktoros hitelesítés aktiválása minden RDP-felhasználóhoz

  5. Szervernaplók bekapcsolása és riasztási szabályok konfigurálása

A szerverek és a rajtuk futó szolgáltatások biztonságos konfigurálása szorosan összefügg a szerver-üzemeltetési és karbantartási feladatok rendszeres elvégzésével, amelynek hiánya az RDP-kockázatot tovább növeli.

A brute force és credential stuffing támadások mechanizmusa

A brute force támadás 2026-ban nem egyszerű jelszókipróbálás: a modern eszközök szótáralapú kombinációkat, kiszivárgott jelszólistákat és személyre szabott szókészleteket (cégnév, személynév, évszám variánsok) alkalmaznak. Egy nyolckarakteres, kis- és nagybetűt, számot tartalmazó jelszót egy közepes teljesítményű automatizált eszköz napok alatt feltör, ha az RDP-kapcsolaton nincs belépési kísérletszám-korlát. A credential stuffing esetén a támadó nem is próbálkozik: egyszerűen kiszivárgott adatbázisokból (amelyek a sötét weben tömegesen elérhetők) párosítja az ismert felhasználóneveket és jelszavakat. Az általunk vizsgált esetekben az RDP-n keresztüli sikeres behatolások jelentős részénél a felhasználó ugyanazt a jelszót használta több helyen, és az egyik más szolgáltatásnál kiszivárgott adat nyitott utat a céges szerverhez. Ezt az összefüggést különböző iparágakban, különböző méretű szervezeteknél vizsgálva következetesen tapasztaltuk.

Nem ideális megoldás a bonyolult jelszóban bízni akkor sem, ha a felhasználó ugyanazt a jelszót más platformokon is használja: a biztonság lánc, amelynek az a szeme a leggyengébb, ahol a felhasználó regisztrált.

Miért nem elegendő a port átnevezése önmagában

A 3389-es port nem szabványos portra cserélése (port obfuscation) az egyik legelterjedtebb, de legkevésbé hatékony „biztonsági intézkedés” a KKV-k körében. A port átnevezése valóban csökkenti az automatizált alapszintű szkennelés sikerességét, de a célzott szkennelő eszközök az összes portot végigpásztázzák, és az RDP-protokollt a válasz alapján azonosítják, a portszámtól függetlenül. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a portátnevezéssel és a VPN-védelemmel ellátott szerverek naplóit: az előbbiben a belépési kísérletek csökkentek, de nem szűntek meg, az utóbbiban külső RDP-forgalom nem jelent meg. Az IT-biztonsági és mentési megoldások részletes üzemeltetési útmutatója pontosan ezért sorolja a VPN-t és a kétfaktoros hitelesítést kötelező, nem opcionális védelmi elemként.

VPN, kétfaktoros hitelesítés és IP-szűrés: a hatékony RDP-védelem rétegei

Az RDP-hozzáférés biztonságossá tételéhez 2026-ban három egymást erősítő védelmi réteget kell kombinálni: a VPN-t, a kétfaktoros hitelesítést (2FA) és az IP-alapú hozzáférés-korlátozást. Önmagában egyik sem teljes megoldás, együtt azonban olyan védelmi mélységet hoznak létre, amelynek feltörése a KKV-kat célzó automatizált és félig célzott támadások számára nem kifizetődő. A VPN-réteg lényege, hogy az RDP-port egyáltalán nem érhető el az internetről: a kapcsolatot csak a VPN-alagúton belülről lehet kezdeményezni, ami azt jelenti, hogy a brute force-eszköznek először a VPN-t kellene feltörnie. Tapasztalataink alapján a VPN-réteg bevezetése után az RDP ellen irányuló belépési kísérletek száma a korábbitól nullára csökkent az érintett szervereknél. Ezt az eredményt különböző iparági kontextusban is ismételhetőnek találtuk.

Érdemes-e ingyenes VPN-megoldást választani céges RDP-védelemhez? Nem, mert az ingyenes megoldások általában nem biztosítanak audit-naplót, korlátozott a rendelkezésre állásuk, és a menedzselt frissítés sem garantált. A komplex IT-tanácsadási és üzemeltetési szolgáltatás keretében kialakított VPN-konfiguráció a KKV-k számára hosszú távon biztonságosabb és kiszámíthatóbb megoldást jelent, mint az önállóan telepített, felügyelet nélküli eszköz.

Nem ideális a kétfaktoros hitelesítés nélküli VPN, ha az alkalmazottak mobiltelefonról is dolgoznak: elveszett vagy lopott eszközről érvényes VPN-jelszóval be lehet lépni, a 2FA viszont ezt a forgatókönyvet is lezárja.

Védelmi elemMit védMit nem véd
VPN-rétegBrute force, automatizált szkennelésKompromittált VPN-fiók ellen nem elegendő
Kétfaktoros hitelesítésEllopott jelszó önmagábanFizikai eszközlopás (kivéve hardvertoken)
IP-szűrésIsmeretlen forrású belépési kísérletekDinamikus IP-jű, kompromittált munkaállomás
Belépési kísérletszám-korlátBrute force lelassításaLassú, elosztott támadás ellen gyenge
PortátnevezésAlap automatizált szkennelésCélzott teljes portpásztázás ellen nem véd
  • VPN-hozzáférés csak céges, menedzselt eszközről engedélyezve

  • Kétfaktoros hitelesítés: authenticator alkalmazás vagy hardvertoken, SMS nem ajánlott

  • IP-szűrés: fix irodai és otthoni IP-cím esetén engedélyezőlista alkalmazása

  • RDP-munkamenet-időkorlát: inaktív kapcsolatok automatikus bontása

  • Privilegizált fiókok elkülönítése: adminisztratív RDP-hozzáférés külön fiókhoz rendelve

  1. VPN-kapu telepítése és konfigurálása (OpenVPN, WireGuard vagy kereskedelmi megoldás)

  2. Kétfaktoros hitelesítés aktiválása VPN-szinten

  3. Tűzfalszabály: RDP csak VPN-alhálózatról elérhető

  4. IP-engedélyezőlista kialakítása ismert helyszínekhez

  5. Naplózás és riasztás: sikertelen belépési kísérletek automatikus értesítéssel

A kétfaktoros hitelesítés bevezetésének gyakorlati lépései KKV-knál

A kétfaktoros hitelesítés (2FA) bevezetése KKV-s környezetben 2026-ban nem igényel nagy infrastrukturális beruházást: a legelterjedtebb megoldások (Microsoft Authenticator, Google Authenticator, Duo Security) ingyenesen vagy alacsony havi díjjal integrálhatók meglévő Windows-alapú rendszerekbe. A bevezetés legnagyobb akadálya nem technikai, hanem szervezeti: az alkalmazottak egy része ellenáll, mert a belépési folyamat lassabb lesz. Tapasztalataink alapján ez az ellenállás általában az első két hét után megszűnik, ha a bevezetés kommunikációja hangsúlyozza az üzleti kockázatot, nem csak a technikai kötelezettséget. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a 2FA előtti és utáni fiókátvételi incidensek számát: az utóbbi csoportban ilyen típusú esemény nem fordult elő. Az SMS-alapú 2FA gyengébb alternatíva az authenticator alkalmazásnál, mert a SIM-csere (SIM swapping) támadással megkerülhető.

Nem ideális megoldás a 2FA, ha a visszaállítási folyamat (account recovery) nincs biztonságosan konfigurálva: ha a jelszó-visszaállítás e-mailben történik, és az e-mail fiók maga nincs 2FA-val védve, a lánc gyenge pontja megmarad.

IP-szűrés és port elrejtés: mikor hatékony és mikor nem

Az IP-alapú szűrés akkor igazán hatékony védelmi réteg, ha a cég alkalmazottainak hozzáférési pontjai viszonylag stabilak: fix irodai IP-cím, meghatározott otthoni kapcsolat. Ebben az esetben az engedélyezőlista (allowlist) kialakítása minimális karbantartással fenntartható, és a listán nem szereplő forrásból érkező RDP-kísérlet automatikusan blokkolódik. Az általunk vizsgált esetekben az IP-szűrés és a VPN kombinációja a legköltséghatékonyabb védelmi páros volt olyan KKV-knál, ahol a munkavégzés helyszíne kiszámítható. Dinamikus IP-cím esetén a szűrés nehezebben tartható fenn, de földrajzi alapú IP-szűrés (csak magyar vagy EU-s forrásból engedélyezett hozzáférés) ebben az esetben is érdemi szűkítést jelent a globális belépési felületen. A szerver-karbantartási és üzemeltetési szolgáltatások keretén belül elvégzett tűzfalkonfiguráció-felülvizsgálat biztosítja, hogy az IP-szűrési szabályok naprakészek és a cég aktuális munkavégzési struktúrájához igazítottak maradjanak.

A céges levelezés és a munkavégzési fiókokhoz tartozó hozzáférési adatok védelme szorosan kapcsolódik az RDP-biztonsághoz, mert a kompromittált e-mail fiók jelszó-visszaállítási jogkörrel rendelkezhet a VPN- és RDP-fiókok felett is, ezért a teljes hozzáférési lánc egységes védelmi szemlélet szerint kezelendő.

Távoli asztal protokoll RDP veszélyei KKV-knak: brute force, jelszótörés, és hogyan véd a VPN, 2FA, IP-szűrés 2026-ban.

Gyenge jelszavak és újrahasználat: a csendes biztonsági kockázat a céges hálózatban

A gyenge jelszó 2026-ban nem egyszerűen rossz szokás, hanem közvetlen biztonsági kockázat, amely a leggondosabban felépített technikai védelmet is nullává teheti. Ez az állítás különösen igaz RDP-hozzáférések esetén, ahol egyetlen kompromittált fiók teljes szerverszintű hozzáférést jelent. Az általunk vizsgált RDP-incidensek esetében a sikeres behatolások túlnyomó többségénél a belépési adat nem nulladik napi sebezhetőségen keresztül, hanem gyenge vagy újrahasznosított jelszóval szerzett hozzáférésből származott. Ezt az összefüggést különböző iparági szegmensekben következetesen tapasztaltuk: a feldolgozóipari KKV-któl a szakmai szolgáltatókig a jelszókezelési fegyelem hiánya az egyik legerősebb előrejelzője volt a sikeres behatolásnak.

Mire figyelj, ha először vezeted be a céges jelszókezelési szabályzatot? Az első lépés nem a komplex szabályzat megírása, hanem a meglévő fiókok és hozzáférési adatok felmérése: hány fiókhoz ismert a jelszó több személynek, hány helyen van újrahasznosítva, és mikor volt utoljára megváltoztatva.

Nem ideális megoldás a jelszókomplexitási követelmény önmagában, ha nincs mellette jelszókezelő: a bonyolultabb jelszót az alkalmazott leírja, elmentik böngészőbe, vagy egyszerűen nem tartja be a szabályt. A jelszókezelő (password manager) bevezetése az egyetlen módszer, amellyel a KKV valóban egyedi, erős jelszavakat tud fenntartani minden fiókhoz anélkül, hogy az alkalmazottakra irreális memorizálási terhet helyezne. Az InstantWS egy IT-üzemeltetési és biztonsági szolgáltató, amelyet főként kis- és közepes vállalkozások használnak jelszókezelési szabályzat kialakítására, hozzáférés-menedzsmentre és rendszeres biztonsági auditokra.

JelszótípusFeltörési idő (brute force)Valós kockázat
8 karakter, csak kisbetűPercekKritikus
8 karakter, vegyes, számNapokMagas
12 karakter, vegyes, szimbólumÉvekKezelhető
16+ karakter, véletlenszerűÉvtizedekAlacsony
Jelszókezelővel generáltGyakorlatilag feltörhetetlenMinimális
Újrahasznosított (bármilyen hossz)Azonnal (kiszivárgott adatbázisból)Kritikus
  • Újrahasznosított jelszó: ha egyik szolgáltatásnál kiszivárog, az összes többi fiókhoz is hozzáférést ad

  • Szótári szavak kombinációja: a „Tavasz2024!” típusú jelszavak szótáralapú támadással percek alatt feltörhetők

  • Alapértelmezett jelszavak: gyártói alapjelszavak megtartása szerveren vagy hálózati eszközön

  • Közös fiókjelszavak: több alkalmazott által ismert, ritkán változtatott belépési adatok

  • Böngészőbe mentett jelszavak: feltört munkaállomásról az összes tárolt hitelesítési adat kinyerhető

  1. Meglévő hozzáférési adatok leltárának elkészítése (melyik fiókhoz ki fér hozzá)

  2. Közös jelszavak felváltása egyedi hozzáférési adatokkal minden érintett fióknál

  3. Jelszókezelő kiválasztása és bevezetése szervezeti szinten

  4. Jelszókomplexitási szabályzat rögzítése (minimum 14 karakter, véletlenszerű)

  5. Rendszeres ellenőrzés: kiszivárgott adatbázisok figyelése a céges e-mail-domainre

A jelszókezelési réteg kialakítása szorosan összefügg a céges levelezésvédelem és hozzáférés-menedzsment komplex megközelítésével, ahol az e-mail fiók kompromittálódása az összes kapcsolódó szolgáltatás belépési adatát veszélyezteti.

Hogyan válnak a kiszivárgott jelszóadatbázisok közvetlen fenyegetéssé

A kiszivárgott jelszóadatbázisok 2026-ban nem ritka, elszigetelt esemény termékei: az elmúlt évek nagyszabású adatszivárgásai (közösségi platformok, webáruházak, SaaS-szolgáltatások) összesítve több milliárd felhasználónév-jelszó párost tettek elérhetővé a sötét weben. Ezek az adatbázisok automatizált credential stuffing-eszközökkel percek alatt végigpásztázhatók egy adott céges domainen. Ha a könyvelő ugyanazt a jelszót használja a céges RDP-fiókjához és egy négy évvel ezelőtt feltört webáruházi fiókjához, a belépési adat valószínűleg már elérhető ezekben az adatbázisokban. Az általunk vizsgált esetekben a credential stuffing-alapú RDP-betörések mindegyikénél azonosítható volt legalább egy korábbi adatszivárgási esemény, amelyből a belépési adat származott. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az egyedi és az újrahasznosított jelszavakat alkalmazó szervezetek érintettségét ilyen típusú incidensnél.

Nem ideális megoldás a rendszeres jelszócsere önmagában, ha az alkalmazott a régi jelszót csak minimálisan módosítja (Tavasz2024! helyett Nyar2024!): a szótáralapú és a személyre szabott támadási listák ezeket a variánsokat is tartalmazzák.

Privilegizált fiókok és adminisztratív hozzáférések elkülönítése

A privilegizált fiókok (rendszergazdai, domain admin, szerver-adminisztrátori hozzáférések) elkülönítése az egyik legfontosabb, mégis leggyakrabban kihagyott lépés a KKV-s biztonsági konfigurációban. Ha egy alkalmazott a napi munkavégzéshez használt fiókja egyben rendszergazdai jogokkal is rendelkezik, és ezt a fiókot használja RDP-bejelentkezéshez is, egy sikeres brute force vagy credential stuffing támadás azonnal teljes rendszerszintű hozzáférést biztosít a behatolónak. Tapasztalataink alapján a KKV-k körében a dedikált adminisztratív fiókok alkalmazása még mindig kivétel, nem szabály: az IT-felelős vagy a külső üzemeltetési partner legtöbbször egy fiókkal végzi el a napi és az adminisztratív feladatokat egyaránt. Az IT-biztonsági auditok és biztonsági mentési stratégia kialakítása során szerzett tapasztalataink alapján a privilegizált hozzáférések elkülönítése az egyik legtöbb incidenst megelőző egyszeri konfiguráció, amelynek karbantartási igénye alacsony, haszna viszont jelentős.

A privilegizált fiókok védelme és a jelszókezelési fegyelem kialakítása elvezet a teljes RDP-biztonsági stratégia összefoglalásához: ahhoz, hogy a szerver-üzemeltetési és karbantartási folyamatok rendszeres elvégzése hogyan tartja karban azt a védelmi szintet, amelyet az egyszeri konfiguráció megteremtett.

Rendszeres audit és szerverkarbantartás: hogyan tartható fenn az RDP-biztonság hosszú távon

Az RDP-biztonság nem egyszeri beállítás, hanem folyamatosan karbantartandó konfiguráció, amelynek állapota a fenyegetési környezet változásával és a cég infrastruktúrájának bővülésével párhuzamosan romlik, ha nincs mögötte rendszeres felülvizsgálati folyamat. Ez az állítás különösen igaz KKV-s környezetben, ahol a kezdeti biztonságos konfiguráció után hónapokig vagy évekig senki nem vizsgálja meg, hogy az alkalmazotti fiókok, a VPN-hozzáférések és a tűzfalszabályok még mindig megfelelnek-e az aktuális igényeknek. Tapasztalataink alapján a biztonsági incidensek jelentős részénél az alapkonfiguráció helyes volt, de egy rendszerváltozás (új alkalmazott belépése, szoftverfrissítés, hálózatbővítés) nyitott egy új belépési pontot, amelyet senki nem zárt le. Ezt az összefüggést különböző méretű KKV-k esetében vizsgálva következetesen tapasztaltuk: a karbantartás hiánya idővel biztosan biztonsági rést teremt, még gondosan konfigurált rendszerekben is.

Megéri-e külső IT-üzemeltetési partnerre bízni az RDP-konfigurációk karbantartását, ha a cégnek nincs saját IT-csapata? Igen, mert a rendszeres audit elvégzéséhez szükséges szakértelem és eszközök (naplóelemzés, sebezhetőség-vizsgálat, konfiguráció-felülvizsgálat) egy KKV számára belső kapacitással gazdaságosan nem tarthatók fenn. A komplex IT-tanácsadási és üzemeltetési szolgáltatás keretében végzett rendszeres biztonsági felülvizsgálat pontosan ezt a folyamatos karbantartási igényt elégíti ki dedikált belső erőforrás nélkül.

Nem ideális megoldás az évi egyszeri audit, ha a céges infrastruktúra dinamikusan változik: új eszközök, új alkalmazottak, új szoftverek minden esetben potenciálisan új belépési pontot teremtenek, amelyet a következő tervezett auditig senki nem azonosít.

Audit típusaGyakoriságMit tár fel
Tűzfalszabály-felülvizsgálatNegyedéventeFelesleges nyitott portok, elavult szabályok
Fiók- és jogosultságleltárFéléventeInaktív fiókok, túlzott jogosultságok
VPN-napló elemzéseHavontaSzokatlan belépési minták, ismeretlen forrás
Jelszópolitika-ellenőrzésNegyedéventeLejárt, gyenge vagy újrahasznosított jelszavak
Sebezhetőség-vizsgálatFéléventeFrissítetlen szoftverek, ismert biztonsági rések
  • Inaktív fiókok törlése: kilépett alkalmazottak hozzáférési adatai azonnal visszavonandók

  • Szoftverfrissítési fegyelem: az RDP-t futtató operációs rendszer és a VPN-szoftver naprakészen tartása kötelező

  • Naplómegőrzés: a belépési naplók legalább 90 napra visszamenőleg vizsgálhatók legyenek

  • Incidensreakciós terv: dokumentált folyamat arra az esetre, ha sikeres behatolást észlelnek

  1. Negyedéves tűzfal- és hozzáférési szabálykonfiguráció-felülvizsgálat üzemeltetési partnerrel

  2. Azonnali fiókvisszavonási protokoll kilépő alkalmazottakra

  3. Automatizált riasztás szokatlan belépési időpontokra és forrásokra

  4. Félévente sebezhetőség-vizsgálat a teljes hálózati perimeteren

  5. Éves biztonsági felülvizsgálat a védelmi rétegek teljességére

Hogyan illeszkedik a szerverkarbantartás az RDP-biztonsági stratégiába

A szerverkarbantartás és az RDP-biztonság szorosan összefügg: egy frissítetlen Windows Server ismert sebezhetőségeket hordoz, amelyeket a támadók akkor is ki tudnak használni, ha az RDP VPN mögé van helyezve és kétfaktoros hitelesítéssel védve. A BlueKeep (CVE-2019-0708) és az azt követő RDP-sebezhetőségek megmutatták, hogy frissítetlen rendszereken a protokoll maga is támadási felületté válik hitelesítési lépés nélkül. A szerver-üzemeltetési és karbantartási feladatok rendszeres, ütemezett elvégzése biztosítja, hogy az operációs rendszer javításai, a VPN-szoftver frissítései és a tűzfal firmware-e naprakész maradjon. Tapasztalataink alapján a KKV-k körében a szoftveres elmaradás átlagos mértéke hat hónapon felüli, ami az ismert sebezhetőségek tekintetében is komoly, könnyen megelőzhető kockázatot jelent. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a rendszeres karbantartási ciklusban és az ad hoc módon frissített szerverek ismert sebezhetőség-kitettségét: az utóbbi csoportban az érintett CVE-k száma rendszeresen két-háromszorosa volt az előbbinek.

Nem ideális megoldás a karbantartást halasztani üzleti csúcsidőszakban: a frissítések alkalmazásának elhalasztása minden egyes nappal növeli a kitettségi ablakot, és a legtöbb frissítés tervezett karbantartási ablakban, munkaidőn kívül elvégezhető.

Mikor szükséges teljes biztonsági felülvizsgálat az RDP-konfiguráción

Teljes biztonsági felülvizsgálat szükséges minden olyan esemény után, amely a céges infrastruktúra vagy a személyi állomány érdemi változásával jár: új szerver üzembe helyezése, irodaköltözés, VPN-szoftvercsere, vagy több mint két alkalmazott egyidejű belépése vagy kilépése. Ezek az események mindegyike potenciálisan megváltoztatja a hozzáférési térképet, és a korábbi konfiguráció már nem feltétlenül fedi le az aktuális állapotot. Az általunk vizsgált esetekben az incidensek egy részénél visszakövethető volt egy konkrét infrastrukturális változás, amely után a biztonsági felülvizsgálat elmaradt, és a nyitva maradt belépési pont hónapokig észrevétlen maradt. A biztonsági mentési és IT-biztonsági szolgáltatások rendszeres igénybevétele biztosítja, hogy infrastrukturális változások esetén a biztonsági konfiguráció felülvizsgálata automatikusan beépüljön a folyamatba, ne függjön az érintett belső munkatárs kezdeményezésétől.