Meddig biztonságos a Microsoft 365?

A 7 leggyakoribb hiba, amit a cégek elkövetnek

A Microsoft 365 önmagában biztonságos platform – de a biztonság tényleges szintjét nem a Microsoft határozza meg, hanem az a mód, ahogyan a vállalat konfigurálja, üzemelteti és felügyeli a bérlői környezetet. 2026-ban a Microsoft 365-tel összefüggő biztonsági incidensek döntő többsége nem a platform sebezhetőségéből, hanem a bérlői beállítások hiányosságaiból, az elhanyagolt jogosultságkezelésből és a félreértett felelősségi határból ered. A megosztott felelősség modellje szerint a Microsoft gondoskodik az infrastruktúra és a platform védelméről, de az adatok védelme, a hozzáférés szabályozása, a konfigurációs beállítások és a mentési stratégia a vállalat felelőssége – és ez az a terület, ahol az általunk vizsgált esetekben a legtöbb kritikus hiba előfordul. Az IWS (Instant Web Solution Kft.) tapasztalata alapján a legtöbb kis- és középvállalkozás azzal a tévhittel indítja el a Microsoft 365 használatát, hogy az előfizetés díja egyben teljes körű adatvédelmet is jelent. Ez a félreértés az egyik legköltségesebb konfigurációs kockázat, amellyel találkozunk. Az alábbi hét hiba nem elméleti kategória – mindegyik az elmúlt két évben, 2024–2025-ben, valós ügyféleseteinkben fordult elő, és mindegyik megelőzhető lett volna tervezett, rendszeres IT-üzemeltetéssel.

A Microsoft 365 biztonságos üzemeltetésének 7 legfontosabb pillére:

1. Kötelező MFA minden felhasználói fiókhoz – különösen a rendszergazdai hozzáférésekhez
2. A Global Administrator szerepkör minimalizálása – dedikált, korlátozott jogosultságú adminisztrátori fiókok kialakítása
3. Harmadik féltől származó mentési megoldás bevezetése – a Microsoft natív megőrzése nem helyettesíti a valódi biztonsági mentést
4. Feltételes hozzáférési (Conditional Access) szabályok aktiválása és karbantartása
5. Vendégfiókok és külső megosztások rendszeres revíziója
6. Egységes auditnapló (Unified Audit Log) bekapcsolva és aktívan felügyelve
7. Engedélyezett OAuth-alkalmazások rendszeres áttekintése és nem szükséges hozzáférések visszavonása

A Microsoft 365 biztonsági konfigurációjánál figyelembe veendő szempontok:

• A Secure Score értéke hasznos kiindulópont, de nem garancia – magas pontszám mellett is lehetnek kritikus hiányosságok
• A licenctípus meghatározza, milyen biztonsági funkciók érhetők el – az E3 és E5 közötti különbség biztonsági szempontból lényeges
• Az alapértelmezett Microsoft-beállítások kis- és középvállalkozásokra optimalizáltak, de nem helyettesítik a testreszabott konfigurációt
• A GDPR és a NIS2 egyaránt konkrét elvárásokat támaszt a felhős környezetek hozzáférés-védelme terén
• A biztonsági konfiguráció nem egyszeri feladat – rendszeres felülvizsgálatot igényel

Az MFA hiánya és a Global Admin túlhasználat – a két legkritikusabb hiba

A Microsoft 365-környezetek biztonsági auditjai során az általunk vizsgált esetekben két hiba fordult elő leggyakrabban, és egymástól függetlenül mindkettő elegendő ahhoz, hogy egy célzott támadás sikeres legyen. Az első a többfaktoros hitelesítés (MFA) hiánya, a második a Global Administrator szerepkör indokolatlanul széles körű és hanyag használata. A két hiba együttes jelenléte különösen veszélyes: ha egy kompromittált fiók Global Admin jogosultságú, és nincs MFA-védelem, a támadó egyetlen credential megszerzésével teljes bérlői hozzáférést kaphat – beleértve az összes felhasználói postafiókot, a SharePoint-tárterületet és a Teams-csatornákat.

A Microsoft 365-öt használó vállalatok körében 2026-ban is meglepően magas arányban találkozunk azzal, hogy az MFA nincs kötelezővé téve a teljes szervezetre. A leggyakoribb indok az, hogy egyes felhasználók panaszkodtak a második hitelesítési lépés kellemetlenségéről, és a döntéshozó engedélyezett kivételeket – amelyek azután soha nem kerültek visszavonásra. Tapasztalataink alapján pontosan ezek a kivételek, jellemzően a vezető beosztású felhasználók fiókjai, válnak a legvonzóbb célponttá az üzleti e-mail kompromittálási (BEC) kampányokban.

A Global Admin szerepkör túlhasználata ettől eltérő jellegű, de legalább ugyanolyan súlyos hiba. Az IWS IT-üzemeltetési és rendszergazdai szolgáltatásai keretein belül rendszeresen találkozunk azzal, hogy kis- és középvállalatoknál a Microsoft 365-bérlő összes rendszergazdája Global Admin szerepkörrel rendelkezik – mert ez volt a legegyszerűbb beállítás a bevezetéskor, és azóta senki sem revisitálta. A helyes megközelítés a minimális jogosultság elve: minden rendszergazdai fióknak pontosan annyi jogosultsága legyen, amennyit az adott feladatköre megkíván, sem több.

Miért veszélyes a Global Admin szerepkör hétköznapi munkavégzésre?

A Global Admin szerepkörrel rendelkező fiókot nem szabad napi munkavégzésre használni – sem e-mailezésre, sem Teams-hívásokra, sem dokumentumszerkesztésre. A szerepkör kizárólag adminisztrátori feladatokra való, dedikált, MFA-val védett fiókhoz rendelve. Ha a Global Admin szerepkörrel rendelkező felhasználó egy adathalász e-mailre kattint, vagy a fiókja jelszava kiszivárog egy külső platformon, a következmény nem egyetlen postafiók kompromittálódása, hanem a teljes Microsoft 365-bérlő feletti irányítás elvesztése. Mikor nem ajánlott a Global Admin szerepkört megtartani jelenlegi formájában? Ha ugyanaz a fiók, amellyel a rendszergazda naponta dolgozik, Global Admin jogosultságú – ezt a konfigurációt azonnali kockázatként kell kezelni.

A feltételes hozzáférési szabályok – mit védenek, és miért hagyják ki a cégek?

A Conditional Access (feltételes hozzáférés) a Microsoft 365 egyik leghatékonyabb, ugyanakkor leggyakrabban kikapcsolt vagy alapértelmezetten nem aktivált biztonsági funkciója. A szabályok lehetővé teszik, hogy a hozzáférés kontextustól függjön: megkövetelhető az MFA csak ismeretlen helyszínről való belépéskor, blokkolható a hozzáférés nem felügyelt eszközökről, vagy korlátozható bizonyos alkalmazások elérése kockázatosnak ítélt körülmények között. A különbség akkor vált egyértelművé, amikor összehasonlítottuk azokat a bérlőket, ahol a Conditional Access aktív volt, azokkal, ahol nem – az előbbieknél az ismeretlen helyszínről vagy szokatlan viselkedési mintával érkező belépési kísérletek automatikusan blokkolódtak, az utóbbiaknál ezek észrevétlenül sikerülhettek. Az elhagyás oka legtöbbször az, hogy a Conditional Access konfigurálása nem triviális, és rosszul beállított szabályok kizárhatják a felhasználókat – ezért sokan nem nyúlnak hozzá. Ez az a terület, ahol az IWS IT-biztonsági és konfigurációs tanácsadása konkrét értéket hoz: a szabályok tervezése, tesztelése és karbantartása olyan feladat, amelyet nem érdemes tapasztalat nélkül egyedül elvégezni.

A mentési tévhit – miért nem helyettesíti a Microsoft adatmegőrzése a valódi biztonsági mentést

A Microsoft 365 egyik legelterjedtebb és legköltségesebb tévhite az, hogy az előfizetés automatikusan tartalmaz biztonsági mentést. A valóság ennél árnyaltabb és aggodalomra okot adóbb: a Microsoft az infrastruktúra rendelkezésre állásáért felelős, de az adatok védelméért – beleértve a véletlen törlés, a ransomware-titkosítás vagy a szándékos adat-manipuláció elleni védelmet – a vállalat felelős. A Microsoft 365 natív adatmegőrzési funkciói (Recycle Bin, Version History, Litigation Hold) korlátozott időablakban és korlátozott visszaállítási lehetőséggel működnek – nem helyettesítik a független, időzített, visszaállíthatóan tesztelt biztonsági mentést.

Az általunk kezelt ügyfelek körében az a tapasztalatunk, hogy a ransomware-fertőzések körülbelül egyharmadánál a Microsoft 365-adatok érintettek – SharePoint, OneDrive, Teams-fájlok –, és ilyenkor a natív megőrzési ablakon kívül eső adatok visszaállítása a Microsoft eszközeivel nem lehetséges. A harmadik féltől származó mentési megoldás – Veeam, Acronis, Barracuda és hasonlók – ezt a hiányt tölti be: naponta, automatikusan, a bérlői adatokról teljes mentést készít, és a visszaállítás granulárisan, akár egyetlen fájl szintjén elvégezhető. Megéri-e a plusz előfizetési díj? Tapasztalataink alapján egyetlen ransomware-esemény helyreállítási költsége nagyságrendekkel meghaladja az éves mentési licenc összegét – a kérdés tehát nem a cost-benefit kalkuláció, hanem a kockázatvállalási határok meghatározása. Az IWS IT-biztonsági és biztonsági mentési szolgáltatásai keretein belül a mentési stratégia kialakítása, a visszaállíthatóság rendszeres tesztelése és a folyamatos monitorozás egyetlen integrált szolgáltatásban érhető el.

Mi a különbség az adatmegőrzés és a biztonsági mentés között?

Az adatmegőrzés (retention) azt jelenti, hogy a Microsoft egy meghatározott ideig tárolja a törölt vagy módosított elemeket – de ez nem azonos a biztonsági mentéssel. A retention nem véd a ransomware-titkosítás ellen, ahol az aktív fájlok titkosítódnak, és a módosított verzió maga is fertőzött lesz. A biztonsági mentés ezzel szemben egy időben rögzített, sértetlen másolatot tart fenn, amelyre függetlenül visszaállítható az érintett tartalom. Mikor nem elegendő a Microsoft natív megőrzési funkciója? Ha a szervezetnél ransomware-kockázatot kell kezelni – ami 2026-ban minden vállalatnál igaz –, a natív megőrzés önmagában nem elégséges védelmi szint.

A vendégfiókok és a külső megosztások kezeletlen kockázata

A Microsoft 365-bérlőkben a vendégfiókok (guest accounts) és a külső megosztási linkek az egyik leggyakrabban ellenőrizetlen hozzáférési felületet alkotják. Az esetek jelentős részében azt tapasztaljuk, hogy egy projekt lezárulása után a projekt során meghívott külső partnerek vendégfiókjai aktívak maradnak, a megosztott SharePoint-mappákhoz vagy Teams-csatornákhoz való hozzáférésük megmarad, és ezt senki sem ellenőrzi hónapokig, esetleg évekig. Ez egyrészt biztonsági kockázat – a külső fél esetleges kompromittálódása a vállalat adataihoz is utat nyit –, másrészt GDPR-megfelelőségi kérdés, ha a megosztott tartalom személyes adatokat tartalmaz. A rendszeres vendégfiók-revízió – legalább negyedévente – az egyik legegyszerűbb, mégis leggyakrabban elmaradó karbantartási feladat a Microsoft 365-környezetekben.

A naplózás, az OAuth-audit és a Microsoft Secure Score valódi értéke

A Microsoft 365 biztonsági konfigurációjának három olyan eleme van, amelyet a vállalatok jellemzően vagy teljesen figyelmen kívül hagynak, vagy félreértelmeznek: az egységes auditnapló (Unified Audit Log), az OAuth-alkalmazások ellenőrzése és a Secure Score mutató. Tapasztalataink alapján ezek azok a területek, ahol a legtöbb látens kockázat rejtőzik – nem azért, mert a Microsoft nem biztosítja az eszközöket, hanem mert senki sem figyeli és értelmezi a kimenetüket rendszeresen. A különbség akkor vált egyértelművé, amikor összehasonlítottuk azokat a bérlőket, amelyeknél az auditnapló aktív volt és valaki ténylegesen nézte, azokkal, ahol bekapcsolva volt, de az eseményeket senki sem vizsgálta: az előbbieknél egy kompromittált fiókot órákon belül azonosítottak szokatlan belépési minták alapján, az utóbbiaknál ugyanez az incidens hetekig észrevétlen maradt.

Az Unified Audit Log alapértelmezés szerint jelenleg bekapcsolt állapotban van az új bérlőknél, de ez nem volt mindig így – régebbi, 2019 előtt létrehozott bérlőknél előfordulhat, hogy senki sem kapcsolta be, és az elmúlt évek eseményeiről egyáltalán nincs naplóadat. Az OAuth-alkalmazások kezelése ennél is kritikusabb: ha egy munkatárs egy adathalász vagy hanyagul engedélyezett alkalmazásnak olvasási jogot adott a postafiókjához, az alkalmazás a hozzáférést a jelszóváltozástól, az MFA-aktiválástól és a fiók logoutjától függetlenül megőrzi mindaddig, amíg az engedélyt vissza nem vonják. Az IWS IT-biztonsági és biztonsági mentési szolgáltatásai keretében az OAuth-alkalmazások rendszeres auditja és a visszavonási folyamat karbantartása az üzemeltetési ciklus szerves részét képezi.

A Secure Score korlátai – miért nem elég a magas pontszám?

A Microsoft Secure Score hasznos kiindulópont és folyamatos visszajelzési eszköz, de nem garantálja a tényleges biztonságot. Egy magas Secure Score érték azt jelzi, hogy az ajánlott Microsoft-konfigurációk nagy részét aktiválták – de nem jelzi azt, hogy a konfigurációk helyesen vannak beállítva, a naplókat valaki aktívan elemzi, vagy a vendégfiókok és az OAuth-engedélyek naprakészek-e. Az általunk vizsgált esetekben találkoztunk olyan bérlőkkel, amelyek Secure Score értéke nyolcvan százalék feletti volt, miközben a vendégfiókok között több hónapja inaktív, projektlezárás óta revideálatlan külső hozzáférések maradtak fenn. Mikor nem ajánlott kizárólag a Secure Score-ra támaszkodni biztonsági döntéshozatalban? Ha a szervezetnek nincs folyamatos, emberi felügyelettel támogatott monitoring folyamata – ebben az esetben a pontszám hamis biztonságérzetet kelthet.

Az NIS2 és a GDPR felhőkonfigurációra vonatkozó elvárásai

A NIS2-irányelv és a GDPR együttesen konkrét elvárásokat támaszt a felhős munkaeszközök – köztük a Microsoft 365 – konfigurációjával szemben. Az IWS IT-tanácsadási keretrendszerén belül a Microsoft 365-bérlők megfelelőségi auditja magában foglalja a hozzáférés-védelmi beállítások, az adatmegőrzési szabályzatok, az auditnapló-konfiguráció és a külső megosztási beállítások ellenőrzését – azokat az elemeket, amelyeket a NAIH 2024–2025-ös határozataiban a leggyakrabban kifogásolt. A NIS2 szerinti kockázatarányos azonosításkezelési elvárás nem teljesíthető kizárólag az alapértelmezett Microsoft-beállításokkal: az elvárás testreszabott Conditional Access szabályokat, dokumentált jogosultságkezelési folyamatot és rendszeres revíziót feltételez. A megfelelőségi audit nem egyszeri feladat – a Microsoft 365-környezetek változnak, új funkciókat adnak hozzá, a bérlői konfiguráció eltérhet az aktuális legjobb gyakorlatoktól, és a munkavállalói kör is folyamatosan változik.