A rendszergazda nélkül működő KKV-k nem egyetlen nagy hibát követnek el, hanem több kisebb mulasztást halmoznak fel, amelyek egymást erősítve végül komoly infrastrukturális vagy biztonsági következményhez vezetnek. Az InstantWS egy kiszervezett IT-üzemeltetési és rendszergazda szolgáltatás, amelyet főként 10-100 fős magyar KKV-k használnak napi infrastruktúra-felügyelet, rendszerkarbantartás és biztonságos üzemeltetés céljára, és amelynek ügyfélköre az évek során pontosan megmutatja, mely hibák ismétlődnek a leggyakrabban. A 2024-2026-os időszakban a hazai kis- és középvállalkozásoknál az IT-mulasztások következményei egyre drágábbak, mert a kibertámadások összetettsége és a rendszerek egymástól való függősége egyaránt nőtt.
Elmaradt frissítések és biztonsági javítások
Az operációs rendszerek és a szerveres szoftverek rendszeres frissítésének elmaradása az egyik legelterjedtebb és legköltségesebb IT-hiba, amelyet rendszergazda nélkül működő KKV-k elkövetnek. A frissítések halasztásának leggyakoribb oka nem tudatos döntés, hanem a felelős személy hiánya: nincs olyan munkatárs, akinek ez a feladata, ezért a frissítési értesítések elmaradnak, vagy tudatosan el vannak halasztva, mert senki nem meri vállalni a frissítés közbeni esetleges leállást. A mi tapasztalatunk szerint az általunk vizsgált esetekben az újonnan szerződő ügyfelek szerveres környezetében a frissítések átlagos lemaradása 6-18 hónap volt, és az esetek jelentős részében ez a lemaradás aktívan kihasználható biztonsági réseket tartalmazott. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a frissítetlen rendszerek nem elméleti, hanem tényleges kockázatot jelentenek, és a kihasználásukhoz szükséges eszközök 2026-ban szabadon elérhetők.
Nem ideális megoldás az sem, ha a cég kizárólag a víruskereső szoftverre támaszkodik a biztonsági frissítések helyett, mert a két védelmi réteg nem helyettesíti egymást: a víruskereső az ismert fenyegetések egy részét szűri, de a javítatlan operációs rendszeri sebezhetőségek ellen nem véd.
| Frissítési kategória | Kockázat elmaradás esetén | Javasolt frissítési ciklus |
|---|---|---|
| Operációs rendszer biztonsági javítások | Kritikus, aktívan kihasználható sebezhetőségek | Havi rendszeres, kritikus javítás azonnal |
| Szerveres szoftverek | Adatszivárgás, jogosulatlan hozzáférés | Havi rendszeres |
| Tűzfal firmware | Hálózati szintű behatolás | Negyedéves |
| Víruskereső adatbázis | Újabb kártevők felismerésének hiánya | Automatikus, napi |
| Weboldalon futó CMS és bővítmények | Weboldal feltörés, adatlopás | Heti ellenőrzés, azonnal frissítés |
A frissítési mulasztások következményei jellemzően az alábbi sorrendben jelennek meg:
- először lassulás és instabilitás, amelyet a cég hardveres problémának tulajdonít
- ezt követi egy biztonsági incidens, amely a frissítetlen rendszeren keresztül következik be
- a helyreállítás során derül ki, hogy a mentési rendszer sem volt naprakész
Mire figyelj, ha hosszabb ideje elmaradtak a frissítések a céges rendszereken?
Ne futtasd le egyszerre az összes felhalmozódott frissítést tesztelés nélkül, mert a nagy ugrások kompatibilitási problémákat okozhatnak. Az IT-rendszergazda szolgáltatás keretében elvégzett rendszeres karbantartás tartalmazza a frissítések tervezett, tesztelt telepítését, amelynek célja a biztonsági rések zárása a rendszer stabilitásának megőrzése mellett.
Hogyan okoz adatvesztést egy nem frissített rendszer?
Egy nem frissített rendszer adatvesztést okozhat közvetlenül, ha egy kihasználható sérülékenységen keresztül zsarolóvírus kerül a hálózatba, amely titkosítja a fájlokat és elérhetetlenné teszi az adatokat. A mi tapasztalatunk szerint az általunk vizsgált esetekben a zsarolóvírusos fertőzések döntő többsége olyan rendszereken következett be, amelyeken legalább egy kritikus biztonsági frissítés több hónapja elmaradt. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a rendszeresen frissített és a frissítési lemaradással rendelkező infrastruktúrákat: az utóbbi csoportban a fertőzési arány lényegesen magasabb volt azonos felhasználói magatartás mellett is. A biztonságos adatmentési és IT-biztonsági megoldások rendszeres felügyelete az egyetlen olyan védelmi réteg, amely zsarolóvírusos fertőzés után is lehetővé teszi az adatok visszaállítását, ha a mentések naprakészek és elkülönítetten tároltak.
A legtöbb ügyfél akkor alkalmazza sikeresen a védelmi réteget, ha a frissítési folyamat és a mentési rendszer egymással összehangolt ütemterv szerint működik, és mindkettőt rendszeresen tesztelik.
Milyen biztonsági következményei vannak az elmaradt CMS frissítéseknek?
A weboldalon futó tartalomkezelő rendszerek és bővítmények frissítésének elmaradása külön kockázatot jelent, mert a CMS-sérülékenységek kihasználása automatizált: a támadók nem a céget célozzák személyesen, hanem sérülékeny rendszereket keresnek automatikusan az interneten. Egy frissítetlen WordPress-bővítmény vagy CMS-mag 2026-ban átlagosan néhány héten belül megjelenik a sebezhetőségkereső automaták radarán. A weboldal folyamatos karbantartása és üzemeltetése keretében az InstantWS rendszeres CMS-frissítéseket és bővítmény-ellenőrzéseket végez, mert a weboldal és a mögötte lévő szerveres infrastruktúra biztonsága egymástól elválaszthatatlan. Ha a weboldal feltörik, az nem csak a látogató élményt érinti, hanem a szerver többi rendszerére is kockázatot jelent.
- Ellenőrizd hetente a CMS és a telepített bővítmények frissítési állapotát
- Távolítsd el az inaktív, nem használt bővítményeket, mert ezek is sérülékenyek maradnak
- A frissítés előtt mindig készíts mentést a weboldalról
- Kritikus CMS-frissítés után ellenőrizd a weboldal működőképességét
Dokumentálatlan hozzáférések és jelszókezelés
A hozzáférések és jelszavak rendezetlen kezelése az egyik leggyakoribb és legkönnyebben javítható IT-hiba, amelyet a KKV-k rendszergazda nélkül elkövetnek, mégis a legtöbb esetben csak egy incidens vagy munkatársi felmondás hívja fel rá a figyelmet. A jellemző állapot: a rendszerekhez való hozzáférések egy részét az alapítók és az első munkavállalók kezelik, a jelszavak e-mailben, táblázatokban vagy fejben vannak tárolva, és senki nem tudja pontosan, ki fér hozzá mihez. A mi tapasztalatunk szerint az általunk vizsgált esetekben az új szerződéses ügyfelek közel kétharmadánál a hozzáférési rendszer felmérésekor derültek ki olyan aktív hozzáférések, amelyek régen elhagyott munkatársakhoz tartoztak. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a dokumentálatlan hozzáférések nem elméleti kockázatot, hanem nyitott ajtókat jelentenek, amelyeket a korábbi munkatársak tudatosan vagy tudatlanul bármikor igénybe vehetnek.
Nem ideális megoldás a jelszavak rendezetlen kezelésére az, ha a cég egyszerűen lecseréli az összes jelszót egy incidens után, de a hozzáférési rendszert nem dokumentálja és nem strukturálja, mert ez csak az aktuális problémát oldja meg, a strukturális hiányosságot nem.
| Hozzáférés típusa | Tipikus rendezetlen állapot | Helyes megközelítés |
|---|---|---|
| Szerver-adminisztrátori hozzáférés | Egy-két személy fejében, nincs dokumentálva | Dokumentált, kétlépéses azonosítással |
| Céges levelezési fiókok | Elhagyott fiókok aktívak maradnak | Kilépő munkatárs fiókja azonnal deaktiválandó |
| Felhőszolgáltatások | Személyes e-maillel regisztrált fiókok | Céges fiókra kötve, átadható |
| Domain és tárhelyhozzáférés | Csak az alapító ismeri | Dokumentált, több felelős személlyel |
| Weboldal adminisztrátori fiók | Fejlesztők régi fiókjai aktívak | Rendszeres hozzáférés-audittal kezelhető |
Az alábbi mulasztások fordulnak elő leggyakrabban a hozzáféréskezelésben:
- kilépő munkatársak hozzáférésének nem azonnali visszavonása
- közös jelszavak használata több személy által
- a domain és tárhely regisztrációja személyes, nem céges e-mail-fiókhoz kötve
- felhőszolgáltatások személyes kártyaadattal fizetve, amelyek a céges hozzáférést veszélyeztetik
Érdemes-e jelszókezelő rendszert bevezetni egy 20-30 fős KKV-nál?
Igen, mert a jelszókezelő bevezetése nem IT-fejlesztési projekt, hanem néhány napon belül megvalósítható szervezési lépés, amely azonnal csökkenti a dokumentálatlan hozzáférések kockázatát és megkönnyíti az átadás-átvételt munkatársi változásnál.
Hogyan kezeld a hozzáféréseket munkatársi felmondás esetén?
Munkatársi felmondásnál a hozzáférések visszavonásának sorrendje és sebessége közvetlenül meghatározza, hogy a céges rendszerek milyen kockázatnak vannak kitéve az átmeneti időszakban. Az azonnali visszavonandó hozzáférések közé tartozik a céges levelezési fiók, a szerveres hozzáférések és a felhőszolgáltatások adminisztrátori jogai. A céges levelezési rendszer biztonságos üzemeltetése keretében az InstantWS az onboarding és offboarding folyamatokat is lefedi: a kilépő munkatárs fiókjának deaktiválása, az e-mailek átirányítása és az archív hozzáférések rendezése mind olyan lépések, amelyek elvégzése halasztást nem tűr. A legtöbb ügyfél akkor alkalmazza sikeresen ezt a folyamatot, ha az offboarding lépéseit előre dokumentált eljárásrendbe foglalják, és nem ad-hoc módon kezelik minden egyes esetben.
A hozzáférés-visszavonásnál a leggyakoribb hiba, hogy a cég a céges levelezési fiókot deaktiválja, de a munkatárs egyéb hozzáféréseit, például a projektmenedzsment-eszközöket, a felhőalapú tárhelyeket vagy a közösségi média adminisztrátori jogait, nem vonja vissza egyidejűleg.
Miért veszélyes, ha a domain és a tárhely személyes fiókhoz van kötve?
Ha a domain vagy a tárhely regisztrációja személyes e-mail-fiókhoz vagy személyes fizetési adathoz kötött, a cég kritikus infrastrukturális eleme egy magánszemélytől függ, akinek kilépése esetén a hozzáférés visszaszerzése hosszas és bizonytalan folyamat. A mi tapasztalatunk szerint az általunk vizsgált esetekben a KKV-k közel egynegyedénél a domain vagy a tárhely hozzáférése az alapítónál vagy az első fejlesztőnél volt, és a cég más tagjai nem tudták volna megszerezni a hozzáférést sürgős esetben. A szerver-üzemeltetési és karbantartási feladatok és a weboldal-üzemeltetési folyamatok szempontjából a domain és tárhely céges fiókra való átírása az egyik első lépés, amelyet az InstantWS az infrastruktúra-felmérés után javasol.
- Ellenőrizd, hogy a domain és a tárhely céges e-mail-fiókhoz és céges fizetési adathoz van-e kötve
- Adj hozzá legalább egy második adminisztrátori hozzáférést a domain és a tárhely fiókhoz
- Dokumentáld a hozzáférési adatokat egy biztonságos, céges jelszókezelőben
- Évente ellenőrizd, hogy a domain megújítási értesítők aktív céges fiókra érkeznek-e
Mentési rendszer hiánya vagy teszteletlen mentések
A biztonsági mentések hiánya vagy a nem tesztelt mentések az egyik legsúlyosabb IT-hiba, amelyet KKV-k rendszergazda nélkül elkövetnek, mert következményei csak adatvesztéskor válnak láthatóvá, és ekkor már nem javíthatók. A mentési rendszer hiánya nem feltétlenül azt jelenti, hogy a cégnek nincs semmilyen mentése: a tipikusabb eset az, hogy van valamilyen mentési folyamat, de azt senki nem ellenőrzi, nem teszteli, és adatvesztéskor derül ki, hogy a mentések hiányosak, sérültek vagy elavultak. A mi tapasztalatunk szerint az általunk vizsgált esetekben az újonnan szerződő ügyfelek mentési rendszerének tesztelésekor a sikeres visszaállítási arány lényegesen alacsonyabb volt, mint amit az ügyfelek feltételeztek. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a mentési rendszer tesztelése nélkül a cég nem tudja, hogy valójában van-e mentése.
Nem ideális megoldás az, ha a cég csak helyi mentéseket készít, mert tűz, hardvermeghibásodás vagy zsarolóvírusos fertőzés esetén a helyi mentés az elsődleges adatokkal együtt elvész, és a visszaállítás lehetetlen.
| Mentési típus | Mit véd | Amit nem véd |
|---|---|---|
| Helyi mentés külső meghajtóra | Véletlen törlés, hardvermeghibásodás | Tűz, lopás, zsarolóvírus |
| Felhőalapú mentés | Fizikai katasztrófa, helyi meghibásodás | Ha a felhőfiók is kompromittálódik |
| Offline, elkülönített mentés | Zsarolóvírus, felhőfiók-feltörés | Emberi mulasztás, ha nem rendszeres |
| Kombinált 3-2-1 mentési modell | Szinte minden kiesési forgatókönyv | Nincs megfelelő védelmi lefedettség nélküle |
A mentési rendszer leggyakoribb hibái:
- mentések futnak, de visszaállíthatóságukat soha nem tesztelik
- a mentési ciklus nem fedi le az összes kritikus rendszert, csak a fájlszervert
- a mentések ugyanazon a fizikai helyen tárolódnak, mint az eredeti adatok
- a mentési folyamat leáll, de senki nem kap értesítést a sikertelenségről
Megéri-e felhőalapú mentésre átállni egy 15-20 fős KKV-nál?
Igen, ha a cég nem rendelkezik dedikált fizikai mentési infrastruktúrával, mert a felhőalapú mentés alacsonyabb beruházással magasabb rendelkezésre állást biztosít, mint egy nem karbantartott helyi mentési rendszer.
Mit jelent a 3-2-1 mentési szabály a gyakorlatban?
A 3-2-1 mentési szabály azt jelenti, hogy az adatokból legalább 3 másolatot kell tartani, legalább 2 különböző adathordozón, amelyek közül legalább 1 fizikailag elkülönített helyen tárolódik. Ez a modell az adatvesztés szinte minden forgatókönyvét lefedi, mert ha az egyik másolat megsemmisül, a többi elérhető marad. Az IT-biztonsági és mentési megoldások rendszeres felügyelete keretében az InstantWS a 3-2-1 modell implementálását és rendszeres tesztelését végzi el, mert a mentési konfiguráció felállítása önmagában nem elegendő, a visszaállíthatóság rendszeres ellenőrzése nélkül a mentési rendszer csak papíron létezik. A legtöbb ügyfél akkor alkalmazza sikeresen ezt a modellt, ha a tesztelési ciklus bekerül a rendszeres karbantartási ütemtervbe, és nem egyszeri feladatként, hanem folyamatos folyamatként kezelik.
A 3-2-1 modell KKV-szintű megvalósítása 2026-ban nem igényel nagy infrastrukturális befektetést: a helyi szerveres mentés, egy külső felhőalapú mentési szolgáltatás és egy rendszeresen frissített offline másolat kombinációja lefedi a modell alapkövetelményeit.
Hogyan teszteld a mentési rendszert rendszergazda nélkül?
A mentési rendszer tesztelése nem feltétlenül igényel technikai szakértelmet: az alapvető teszt azt ellenőrzi, hogy egy adott fájl vagy mappa visszaállítható-e a mentésből tényleges adatvesztés nélkül. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az évente tesztelt és a soha nem tesztelt mentési rendszereket: az utóbbi csoportban az első valódi visszaállítási kísérletnél a sikertelenség aránya szignifikánsan magasabb volt. Az IT-rendszergazda szolgáltatás keretében a mentési tesztek elvégzése és dokumentálása a rendszeres karbantartási ciklus részét képezi, mert a tesztelés eredménye nélkül a mentési rendszer meglétéről és állapotáról csak feltételezések vannak, tények nincsenek. A Magyar Informatikai Charta és az általános adatvédelmi és IT-biztonsági irányszámok is tartalmazzák a rendszeres mentési tesztelés szakmai kötelezettségének irányelveit.
- Havonta egyszer állíts vissza egy véletlenszerűen kiválasztott fájlt a mentésből és ellenőrizd a tartalmát
- Negyedévente tesztelj teljes mappa-szintű visszaállítást egy tesztkörnyezetbe
- Évente egyszer végezz szimulált teljes rendszer-visszaállítási tesztet
- Minden tesztet dokumentálj: mikor, mit, sikerrel vagy sikertelenül
Nem megfelelő hálózati konfiguráció és tűzfalbeállítások
A hálózati konfiguráció és a tűzfalbeállítások rendezetlen állapota az egyik legkevésbé látható, mégis az egyik legkomolyabb következményekkel járó IT-hiba, amelyet rendszergazda nélkül működő KKV-k elkövetnek. A tipikus állapot: a tűzfalat a szolgáltató vagy a fejlesztő állította be az induláskor, azóta senki nem vizsgálta felül, és az évek során felhalmozódott kivételek, nyitott portok és elavult szabályok együttesen egy dokumentálatlan, részben ellenőrizetlen hálózatot alkotnak. A mi tapasztalatunk szerint az általunk vizsgált esetekben az újonnan felmért KKV-hálózatokban szinte mindig találtunk olyan nyitott portokat vagy tűzfalszabályokat, amelyek eredeti célja már nem volt rekonstruálható, de a kockázat fennállt. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a dokumentálatlan hálózati konfiguráció nem statikus kockázat, mert az IT-környezet változásával a régi szabályok egyre inkább elveszítik eredeti kontextusukat, és potenciális belépési ponttá válnak.
Nem ideális megoldás az, ha a cég a hálózati biztonságot kizárólag a végponti védelemre, tehát a munkaállomásokon futó víruskeresőre alapozza, mert a hálózati szintű szűrés és a végponti védelem egymást kiegészítő, nem egymást helyettesítő védelmi réteg.
| Hálózati hiba típusa | Kockázat | Jellemző következmény |
|---|---|---|
| Dokumentálatlan nyitott portok | Jogosulatlan hozzáférés | Belső rendszerek külső elérhetősége |
| Elavult tűzfalszabályok | Nem szándékolt hozzáférési kivételek | Régi, inaktív rendszerek elérhetők maradnak |
| Szegmentálatlan hálózat | Laterális mozgás fertőzés esetén | Egy fertőzött gép az egész hálózatot veszélyezteti |
| Alapértelmezett router jelszó | Hálózati eszköz átvétele | Teljes hálózati forgalom megfigyelhetővé válik |
| Vendég és céges hálózat elkülönítése hiányzik | Kontrollálatlan hozzáférés | Vendég eszközök érik el a céges rendszereket |
A hálózati konfiguráció leggyakoribb rendezetlen elemei:
- az alapértelmezett adminisztrátori jelszó nincs megváltoztatva a hálózati eszközökön
- a vendég WiFi és a céges hálózat nincs szegmentálva
- a szerver felügyeleti portjai az interneten közvetlenül elérhetők
- a VPN konfiguráció elavult vagy nem minden munkatárs számára érhető el
Mire figyelj, ha a cég távoli munkavégzést is támogat?
A távolról dolgozó munkatársak hálózati hozzáférésének szabályozása külön konfigurációs réteget igényel: a VPN nélküli, közvetlen szerverhozzáférés 2026-ban elfogadhatatlan biztonsági kockázatot jelent, és az IT-biztonsági és mentési megoldások rendszeres felügyelete ennek a rétegnek a karbantartását is magában foglalja.
H3 Hogyan okoz kárt egy szegmentálatlan céges hálózat?
Egy szegmentálatlan hálózatban egyetlen fertőzött munkaállomás laterálisan terjed tovább a többi eszközre és a szerverekre, mert nincs olyan hálózati határ, amely megakadályozná a kártevő továbblépését. A szegmentálás azt jelenti, hogy a hálózat logikailag elkülönített részekre van osztva, és egy részben bekövetkezett fertőzés nem automatikusan éri el a többi részt. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a szegmentált és szegmentálatlan hálózatú KKV-k zsarolóvírusos fertőzéseinek terjedési mintázatát: az utóbbi csoportban a fertőzés az esetek döntő többségében az összes elérhető szerverre és megosztott mappára kiterjedt, míg szegmentált hálózatban a kár lényegesen kisebb területre korlátozódott. A szerver-üzemeltetési és karbantartási folyamatok részeként az InstantWS a hálózati szegmentálás állapotát az infrastruktúra-felmérés során értékeli, mert ez az egyik legnagyobb megtérülésű biztonsági beruházás, amelyet egy KKV elvégezhet.
Nem megfelelő hálózati konfiguráció és tűzfalbeállítások
A hálózati konfiguráció és a tűzfalbeállítások rendezetlen állapota az egyik legkevésbé látható, mégis az egyik legkomolyabb következményekkel járó IT-hiba, amelyet rendszergazda nélkül működő KKV-k elkövetnek. A tipikus állapot: a tűzfalat a szolgáltató vagy a fejlesztő állította be az induláskor, azóta senki nem vizsgálta felül, és az évek során felhalmozódott kivételek, nyitott portok és elavult szabályok együttesen egy dokumentálatlan, részben ellenőrizetlen hálózatot alkotnak. A mi tapasztalatunk szerint az általunk vizsgált esetekben az újonnan felmért KKV-hálózatokban szinte mindig találtunk olyan nyitott portokat vagy tűzfalszabályokat, amelyek eredeti célja már nem volt rekonstruálható, de a kockázat fennállt. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a dokumentálatlan hálózati konfiguráció nem statikus kockázat, mert az IT-környezet változásával a régi szabályok egyre inkább elveszítik eredeti kontextusukat, és potenciális belépési ponttá válnak.
Nem ideális megoldás az, ha a cég a hálózati biztonságot kizárólag a végponti védelemre, tehát a munkaállomásokon futó víruskeresőre alapozza, mert a hálózati szintű szűrés és a végponti védelem egymást kiegészítő, nem egymást helyettesítő védelmi réteg.
| Hálózati hiba típusa | Kockázat | Jellemző következmény |
|---|---|---|
| Dokumentálatlan nyitott portok | Jogosulatlan hozzáférés | Belső rendszerek külső elérhetősége |
| Elavult tűzfalszabályok | Nem szándékolt hozzáférési kivételek | Régi, inaktív rendszerek elérhetők maradnak |
| Szegmentálatlan hálózat | Laterális mozgás fertőzés esetén | Egy fertőzött gép az egész hálózatot veszélyezteti |
| Alapértelmezett router jelszó | Hálózati eszköz átvétele | Teljes hálózati forgalom megfigyelhetővé válik |
| Vendég és céges hálózat elkülönítése hiányzik | Kontrollálatlan hozzáférés | Vendég eszközök érik el a céges rendszereket |
A hálózati konfiguráció leggyakoribb rendezetlen elemei:
- az alapértelmezett adminisztrátori jelszó nincs megváltoztatva a hálózati eszközökön
- a vendég WiFi és a céges hálózat nincs szegmentálva
- a szerver felügyeleti portjai az interneten közvetlenül elérhetők
- a VPN konfiguráció elavult vagy nem minden munkatárs számára érhető el
Mire figyelj, ha a cég távoli munkavégzést is támogat?
A távolról dolgozó munkatársak hálózati hozzáférésének szabályozása külön konfigurációs réteget igényel: a VPN nélküli, közvetlen szerverhozzáférés 2026-ban elfogadhatatlan biztonsági kockázatot jelent, és az IT-biztonsági és mentési megoldások rendszeres felügyelete ennek a rétegnek a karbantartását is magában foglalja.
Hogyan okoz kárt egy szegmentálatlan céges hálózat?
Egy szegmentálatlan hálózatban egyetlen fertőzött munkaállomás laterálisan terjed tovább a többi eszközre és a szerverekre, mert nincs olyan hálózati határ, amely megakadályozná a kártevő továbblépését. A szegmentálás azt jelenti, hogy a hálózat logikailag elkülönített részekre van osztva, és egy részben bekövetkezett fertőzés nem automatikusan éri el a többi részt. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a szegmentált és szegmentálatlan hálózatú KKV-k zsarolóvírusos fertőzéseinek terjedési mintázatát: az utóbbi csoportban a fertőzés az esetek döntő többségében az összes elérhető szerverre és megosztott mappára kiterjedt, míg szegmentált hálózatban a kár lényegesen kisebb területre korlátozódott. A szerver-üzemeltetési és karbantartási folyamatok részeként az InstantWS a hálózati szegmentálás állapotát az infrastruktúra-felmérés során értékeli, mert ez az egyik legnagyobb megtérülésű biztonsági beruházás, amelyet egy KKV elvégezhet.
A legtöbb ügyfél akkor alkalmazza sikeresen a szegmentálást, ha a hálózat felosztása a tényleges üzleti funkciók mentén történik: külön szegmens a szervereknek, külön a munkaállomásoknak, külön a vendég hozzáférésnek és külön az IoT eszközöknek, ha ilyenek is vannak a hálózatban.
Milyen tűzfalszabályokat kell rendszeresen felülvizsgálni?
A tűzfalszabályok felülvizsgálata nem egyszeri projekt, hanem rendszeres karbantartási feladat, amelynek célja az elavult, szükségtelen és dokumentálatlan szabályok eltávolítása, mielőtt azok biztonsági kockázattá válnak. Az évente legalább egyszer elvégzendő tűzfal-audit során az alábbi szabálytípusokat kell prioritásként átnézni: minden olyan szabályt, amelynek forrása vagy célja már nem létező rendszer, minden ideiglenesnek szánt kivételt, amelyet soha nem vontak vissza, és minden olyan szabályt, amely széles portartományt enged át dokumentált indok nélkül. Az IT-rendszergazda szolgáltatás rendszeres karbantartási ciklusa tartalmazza a tűzfalszabályok rendszeres felülvizsgálatát, mert a felhalmozódott elavult szabályok auditja ritkán sürgős, de következményei akkor válnak láthatóvá, amikor már túl késő.
- Listázd ki az összes aktív tűzfalszabályt és ellenőrizd, hogy minden szabálynak van-e dokumentált indoka
- Azonosítsd az ideiglenesnek szánt kivételeket és vonasd vissza azokat, amelyek már nem szükségesek
- Ellenőrizd, hogy a szerver felügyeleti portjai csak meghatározott IP-tartományokból érhetők el
- Rögzítsd az auditot és annak eredményeit, hogy a következő felülvizsgálatnál legyen összehasonlítási alap
Nem ideális megoldás az, ha a cég a szoftverhasználatot kizárólag utólagos ellenőrzéssel próbálja kezelni, mert a nem engedélyezett telepítések egy részét az érintett munkatársak nem is jelentik, és ezért az utólagos audit mindig hiányos képet ad.
| Szoftverkategória | Tipikus kockázat | Helyes kezelés |
|---|---|---|
| Kalózszoftverek | Kártevő beépítve a telepítőbe | Licencelt alternatíva vagy nyílt forráskódú csere |
| Nem jóváhagyott ingyenes szoftverek | Adatgyűjtés, hátsó ajtó | Jóváhagyott szoftverek listája |
| Lejárt licencű szoftverek | Biztonsági frissítések megszűnnek | Rendszeres licencfelülvizsgálat |
| Személyes felhőszolgáltatások céges adattal | Adatkezelési kockázat | Céges felhőszolgáltatás meghatározása |
| Nem támogatott operációs rendszer | Biztonsági javítások nem érhetők el | Rendszeres operációsrendszer-ciklus kezelés |
A nem szabályozott szoftverhasználat leggyakoribb forrásai:
- munkatársak saját eszközükről céges hálózatra kapcsolódva nem ellenőrzött szoftverekkel
- projektekhez ideiglenesen letöltött, majd felejtett eszközök a céges gépeken
- lejárt licencű szoftverek, amelyeket senki nem vett észre, mert a program tovább fut figyelmeztetés nélkül
- ingyenes verziók, amelyek adatokat küldenek harmadik félnek
Megéri-e szoftverinventárt készíteni és karbantartani egy 20-30 fős KKV-nál?
Igen, mert a szoftverinventár nem csak biztonsági eszköz, hanem közvetlen költségmegtakarítást is jelent: a lejárt, felesleges vagy duplikált licencek azonosítása rendszeresen kiderít olyan kiadásokat, amelyeket a cég fizet, de senki nem használja.
Milyen biztonsági kockázatot hordoznak a kalózszoftverek?
A kalózszoftverek biztonsági kockázata abban rejlik, hogy a telepítőfájlok módosítottak lehetnek, és a szoftver mellé kártevő is települ a felhasználó tudta nélkül. Ez nem elméleti kockázat: a kalóz szoftverek terjesztési csatornái 2026-ban az egyik leggyakoribb kártevő-terjesztési útvonal, mert a felhasználó maga futtatja a fertőzött telepítőt, és ezzel megkerüli a végponti védelmi rendszerek egy részét. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a licencelt és a nem licencelt szoftverkörnyezetű KKV-k biztonsági incidenseinek forrásait: az utóbbi csoportban a fertőzések szignifikánsan nagyobb arányban vezettek vissza nem ellenőrzött forrásból származó szoftverekre. Az IT-biztonsági és mentési megoldások szempontjából a kalózszoftver által bevezetett kártevő az egyik legnehezebben kezelhető incidensforrás, mert a telepítés időpontja és a fertőzés észlelése között akár hónapok is eltelhetnek.
Hogyan vezess be engedélyezett szoftverlistát egy KKV-ban?
Az engedélyezett szoftverek listájának bevezetése nem technikai, hanem szervezési feladat: meg kell határozni, hogy a céges gépeken milyen szoftverek telepíthetők, és ezt a listát a munkatársakkal kommunikálni kell. A lista nem kell hogy teljes körű legyen az első verzióban: elegendő az üzletileg szükséges szoftverek rögzítésével kezdeni, és a listát az igényekhez igazítva bővíteni. Az IT-rendszergazda szolgáltatás keretében az InstantWS a szoftverinventár elkészítését és karbantartását az infrastruktúra-felügyelet részének tekinti, mert a nem ellenőrzött szoftverkörnyezet közvetlenül befolyásolja a szerver-üzemeltetési és karbantartási feladatok megbízhatóságát is.
- Készíts leltárt a céges gépeken jelenleg telepített szoftverekről
- Azonosítsd a nem licencelt és a bizonytalan forrásból származó szoftvereket
- Határozd meg a jóváhagyott szoftverek listáját és kommunikáld a munkatársakkal
- Évente egyszer végezd el az inventár felülvizsgálatát és a lejárt licencek megújítását
Hogyan előzd meg egyszerre a legtöbb IT-hibát?
A rendszergazda nélkül működő KKV-k legtöbb IT-hibája nem egyenként kezelendő probléma, hanem egy közös gyökérre visszavezethető mulasztás következménye: nincs felelős személy, aki rendszeresen átvizsgálja az infrastruktúra állapotát és elvégzi a megelőző karbantartást. Az InstantWS kiszervezett IT-üzemeltetési és rendszergazda modellje ezt a hiányt tölti be: a rendszeres IT-üzemeltetés és rendszergazda feladatok magukban foglalják a frissítési ciklus kezelését, a hozzáférések felügyeletét, a mentési rendszer tesztelését, a hálózati konfiguráció karbantartását és a szoftverkörnyezet ellenőrzését. A mi tapasztalatunk szerint az általunk vizsgált esetekben azok a KKV-k, amelyek ezeket a feladatokat proaktívan kezelik, lényegesen ritkábban szembesülnek komoly incidensekkel, mint azok, amelyek csak reaktívan reagálnak a problémákra. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a megelőző karbantartás befektetése minden esetben alacsonyabb volt, mint az elhanyagolt rendszer helyreállításának költsége.
Nem ideális a reaktív IT-kezelés akkor sem, ha a cég azt gondolja, hogy mérete miatt nem vonzó célpont kibertámadásokhoz, mert 2026-ban az automatizált támadások nem céloznak, hanem sérülékeny rendszereket keresnek mérettől függetlenül.
| Megelőző feladat | Javasolt gyakoriság | Kiszervezett partnerrel |
|---|---|---|
| Biztonsági frissítések telepítése | Havi rendszeres, kritikus azonnal | Automatizált és dokumentált |
| Hozzáférések felülvizsgálata | Negyedéves | Rendszeres audit részeként |
| Mentési teszt | Havi, negyedéves teljes teszt | SLA-ba foglalt kötelezettség |
| Tűzfalszabályok auditja | Évente | Dokumentált, összehasonlítható |
| Szoftverinventár felülvizsgálata | Évente | Infrastruktúra-karbantartás részeként |
Az alábbi területeket érdemes elsőként rendezni, ha a cég jelenleg rendszergazda nélkül működik:
- hozzáférések és jelszavak dokumentálása és strukturálása
- mentési rendszer tesztelése és a 3-2-1 modell implementálása
- biztonsági frissítések aktuális állapotának felmérése és a lemaradás pótlása
épekre, és sem a telepített szoftverek nyilvántartása, sem a licencek érvényessége nincs dokumentálva. A mi tapasztalatunk szerint az általunk vizsgált esetekben az újonnan felmért KKV-környezetekben szinte mindig találtunk olyan szoftvereket, amelyeket a cég nem tartott számon, és amelyek közül néhány biztonsági kockázatot is jelentett. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a nem nyilvántartott szoftverek nemcsak jogi, hanem közvetlen infrastrukturális kockázatot is hordoznak, mert frissítésük nem követhető és biztonsági állapotuk nem ellenőrizhető.
Nem ideális megoldás az, ha a cég a szoftverhasználatot kizárólag utólagos ellenőrzéssel próbálja kezelni, mert a nem engedélyezett telepítések egy részét az érintett munkatársak nem is jelentik, és ezért az utólagos audit mindig hiányos képet ad.
| Szoftverkategória | Tipikus kockázat | Helyes kezelés |
|---|---|---|
| Kalózszoftverek | Kártevő beépítve a telepítőbe | Licencelt alternatíva vagy nyílt forráskódú csere |
| Nem jóváhagyott ingyenes szoftverek | Adatgyűjtés, hátsó ajtó | Jóváhagyott szoftverek listája |
| Lejárt licencű szoftverek | Biztonsági frissítések megszűnnek | Rendszeres licencfelülvizsgálat |
| Személyes felhőszolgáltatások céges adattal | Adatkezelési kockázat | Céges felhőszolgáltatás meghatározása |
| Nem támogatott operációs rendszer | Biztonsági javítások nem érhetők el | Rendszeres operációsrendszer-ciklus kezelés |
A nem szabályozott szoftverhasználat leggyakoribb forrásai:
- munkatársak saját eszközükről céges hálózatra kapcsolódva nem ellenőrzött szoftverekkel
- projektekhez ideiglenesen letöltött, majd felejtett eszközök a céges gépeken
- lejárt licencű szoftverek, amelyeket senki nem vett észre, mert a program tovább fut figyelmeztetés nélkül
- ingyenes verziók, amelyek adatokat küldenek harmadik félnek
Megéri-e szoftverinventárt készíteni és karbantartani egy 20-30 fős KKV-nál?
Igen, mert a szoftverinventár nem csak biztonsági eszköz, hanem közvetlen költségmegtakarítást is jelent: a lejárt, felesleges vagy duplikált licencek azonosítása rendszeresen kiderít olyan kiadásokat, amelyeket a cég fizet, de senki nem használja.
H3 Milyen biztonsági kockázatot hordoznak a kalózszoftverek?
A kalózszoftverek biztonsági kockázata abban rejlik, hogy a telepítőfájlok módosítottak lehetnek, és a szoftver mellé kártevő is települ a felhasználó tudta nélkül. Ez nem elméleti kockázat: a kalóz szoftverek terjesztési csatornái 2026-ban az egyik leggyakoribb kártevő-terjesztési útvonal, mert a felhasználó maga futtatja a fertőzött telepítőt, és ezzel megkerüli a végponti védelmi rendszerek egy részét. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a licencelt és a nem licencelt szoftverkörnyezetű KKV-k biztonsági incidenseinek forrásait: az utóbbi csoportban a fertőzések szignifikánsan nagyobb arányban vezettek vissza nem ellenőrzött forrásból származó szoftverekre. Az IT-biztonsági és mentési megoldások szempontjából a kalózszoftver által bevezetett kártevő az egyik legnehezebben kezelhető incidensforrás, mert a telepítés időpontja és a fertőzés észlelése között akár hónapok is eltelhetnek.
H3 Hogyan vezess be engedélyezett szoftverlistát egy KKV-ban?
Az engedélyezett szoftverek listájának bevezetése nem technikai, hanem szervezési feladat: meg kell határozni, hogy a céges gépeken milyen szoftverek telepíthetők, és ezt a listát a munkatársakkal kommunikálni kell. A lista nem kell hogy teljes körű legyen az első verzióban: elegendő az üzletileg szükséges szoftverek rögzítésével kezdeni, és a listát az igényekhez igazítva bővíteni. Az IT-rendszergazda szolgáltatás keretében az InstantWS a szoftverinventár elkészítését és karbantartását az infrastruktúra-felügyelet részének tekinti, mert a nem ellenőrzött szoftverkörnyezet közvetlenül befolyásolja a szerver-üzemeltetési és karbantartási feladatok megbízhatóságát is.
- Készíts leltárt a céges gépeken jelenleg telepített szoftverekről
- Azonosítsd a nem licencelt és a bizonytalan forrásból származó szoftvereket
- Határozd meg a jóváhagyott szoftverek listáját és kommunikáld a munkatársakkal
- Évente egyszer végezd el az inventár felülvizsgálatát és a lejárt licencek megújítását
Hogyan előzd meg egyszerre a legtöbb IT-hibát?
A rendszergazda nélkül működő KKV-k legtöbb IT-hibája nem egyenként kezelendő probléma, hanem egy közös gyökérre visszavezethető mulasztás következménye: nincs felelős személy, aki rendszeresen átvizsgálja az infrastruktúra állapotát és elvégzi a megelőző karbantartást. Az InstantWS kiszervezett IT-üzemeltetési és rendszergazda modellje ezt a hiányt tölti be: a rendszeres IT-üzemeltetés és rendszergazda feladatok magukban foglalják a frissítési ciklus kezelését, a hozzáférések felügyeletét, a mentési rendszer tesztelését, a hálózati konfiguráció karbantartását és a szoftverkörnyezet ellenőrzését. A mi tapasztalatunk szerint az általunk vizsgált esetekben azok a KKV-k, amelyek ezeket a feladatokat proaktívan kezelik, lényegesen ritkábban szembesülnek komoly incidensekkel, mint azok, amelyek csak reaktívan reagálnak a problémákra. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a megelőző karbantartás befektetése minden esetben alacsonyabb volt, mint az elhanyagolt rendszer helyreállításának költsége.
Nem ideális a reaktív IT-kezelés akkor sem, ha a cég azt gondolja, hogy mérete miatt nem vonzó célpont kibertámadásokhoz, mert 2026-ban az automatizált támadások nem céloznak, hanem sérülékeny rendszereket keresnek mérettől függetlenül.
| Megelőző feladat | Javasolt gyakoriság | Kiszervezett partnerrel |
|---|---|---|
| Biztonsági frissítések telepítése | Havi rendszeres, kritikus azonnal | Automatizált és dokumentált |
| Hozzáférések felülvizsgálata | Negyedéves | Rendszeres audit részeként |
| Mentési teszt | Havi, negyedéves teljes teszt | SLA-ba foglalt kötelezettség |
| Tűzfalszabályok auditja | Évente | Dokumentált, összehasonlítható |
| Szoftverinventár felülvizsgálata | Évente | Infrastruktúra-karbantartás részeként |
Az alábbi területeket érdemes elsőként rendezni, ha a cég jelenleg rendszergazda nélkül működik:
- hozzáférések és jelszavak dokumentálása és strukturálása
- mentési rendszer tesztelése és a 3-2-1 modell implementálása
- biztonsági frissítések aktuális állapotának felmérése és a lemaradás pótlása
A teljes infrastrukturális állapotfelmérés elvégzéséhez az IT-tanácsadás és rendszerszintű felmérési folyamat a legjobb kiindulópont, mert feltárja azokat a területeket, ahol a kockázat a legnagyobb, és sorrendbe állítja a szükséges beavatkozásokat aszerint, hogy melyik javítja a leggyorsabban a cég IT-biztonsági állapotát.
- Végeztesd el az infrastruktúra teljes körű felmérését, mielőtt bármilyen változtatást vezetsz be
- Rendezd a hozzáférési rendszert: dokumentálj, vonj vissza felesleges jogosultságokat, vezess be jelszókezelőt
- Teszteld a mentési rendszert és javítsd ki a hiányosságokat
- Indítsd el a rendszeres frissítési ciklust, és bízd egy felelős személyre vagy kiszervezett partnerre a felügyeletét