A Microsoft 365 a legtöbb cégnél a levelezést és a dokumentumokat is őrzi, az Entra ID pedig sok más felhős alkalmazás belépési pontja. Aki egy felhasználói fiókot átvesz, ezért jóval többhöz fér hozzá egy postafióknál.
Sok bérlőben a beállítások az indulás óta érintetlenek. Az alapértelmezések a gyors együttműködést szolgálják, a szigorítás az üzemeltetőre marad. Az alábbiakban öt területet veszünk sorra a tipikus hibákkal, a végén pedig leírjuk, milyen sorrendben érdemes hozzányúlni.
Hitelesítés
A bérlő elleni támadás jellemzően egy fiók átvételével kezdődik, ellopott vagy kitalált jelszóval. A többfaktoros hitelesítés ezt megnehezíti, de hogy mennyire, az a módszeren és a kivételeken múlik. A módszerek erősségéről az MFA típusairól szóló cikkünkben írtunk, itt a bérlőre jellemző hibák következnek.
Az adminisztrátori fiókok
A globális adminisztrátor a bérlőben mindenhez hozzáfér. Gyakori hiba, hogy túl sok fiók kapja meg ezt a szerepkört, köztük olyan is, amellyel a tulajdonosa naponta levelez és böngészik. Az adminisztrátori munkához külön, csak erre használt fiók kell, a lehető legszűkebb szerepkörrel: a jelszavak visszaállításához elég a helpdesk-adminisztrátori, a postafiókok kezeléséhez az Exchange-adminisztrátori szerepkör. Ezeken a fiókokon adathalászat-álló hitelesítés legyen, például FIDO2-kulcs vagy passkey.
A vészhelyzeti fiók
Ha egy hibás feltételes hozzáférési szabály vagy az MFA-szolgáltatás zavara kizárja az összes adminisztrátort, csak egy előre elkészített vészhelyzeti fiókkal lehet visszajutni. Ezt a fiókot szándékosan kivesszük a szabályok alól, ezért erős, offline őrzött hitelesítő adattal kell védeni, és minden bejelentkezéséről riasztást kell kapni. Sok bérlőben ilyen fiók nincs, vagy van, de évek óta senki nem próbálta ki.
Az örökölt hitelesítés
A régi levelezési protokollok és kliensek egy része nem tud többfaktoros hitelesítést, így náluk a jelszó önmagában elég a belépéshez. A Microsoft az Exchange Online-ban az alapszintű hitelesítést nagyrészt kivezette, a bérlőben mégis érdemes ellenőrizni, hogy feltételes hozzáférési szabály is tiltja-e, és látszik-e még ilyen bejelentkezés a naplóban. Ha egy nyomtató vagy egy régi alkalmazás jelszóval küld levelet, arra külön, szűkre szabott megoldás kell.
Az alkalmazás-hozzájárulás
Az MFA nem segít, ha a felhasználó maga ad hozzáférést. A hozzájárulás-alapú adathalászatnál a támadó egy ártalmatlannak látszó alkalmazást kér jóváhagyásra, és az így engedélyt kap a postafiók vagy a fájlok olvasására. Ez a jogosultság a jelszócsere után is megmarad. Érdemes korlátozni, milyen engedélyt adhatnak a felhasználók saját hatáskörben, a többit adminisztrátori jóváhagyáshoz kötni, és időnként átnézni, mely alkalmazások kaptak már hozzáférést a bérlőben.
Feltételes hozzáférés
A feltételes hozzáférés az Entra ID szabálymotorja. Minden bejelentkezésnél megnézi, ki lép be, honnan, milyen eszközről és melyik alkalmazásba, és ennek alapján enged, többfaktoros hitelesítést kér vagy tilt. Így írható elő például, hogy ismeretlen eszközről a dokumentumok csak böngészőben, letöltés nélkül nyíljanak meg.
Ha a bérlőben egyetlen feltételes hozzáférési szabály sincs, legalább a biztonsági alapértelmezések legyenek bekapcsolva. A kettő egyszerre nem működik, ezért aki szabályokra vált, azokkal kell lefednie mindazt, amit az alapértelmezések eddig adtak.
Tipikus hibák
- A kivétellista nő. Egy szolgáltatásfiók, egy vezető, aki nem akar telefont használni: egyenként minden kivétel indokoltnak tűnik, együtt viszont olyan csoportot adnak, amelyre semmilyen szabály nem vonatkozik.
- A szabály jelentés módban marad. Az új szabályt helyes először csak naplózó üzemmódban kipróbálni, de sok bérlőben évekig ott is marad, és semmit nem tilt.
- Nem minden alkalmazásra vonatkozik. Ha a szabály egyes alkalmazásokat sorol fel, egy újonnan bevezetett alkalmazás kívül esik rajta. Az MFA-t előíró alapszabály minden felhőalkalmazásra szóljon.
- A vendégfiókok kimaradnak. A külső partnerek bejelentkezésére is kell szabály.
- Az irodai hálózat megbízható helyként kivételt kap. Ekkor az irodai gépen ülő támadónak vagy egy kompromittált VPN-kapcsolatnak sem kell második faktor.
Élesítés előtt a What If eszközzel és a bejelentkezési naplóval ellenőrizhető, kire melyik szabály vonatkozna, és ki maradna ki belőlük.
Külső megosztás
A SharePoint és a OneDrive megosztási szintje bérlőszinten dől el, a webhelyek ennél csak szigorúbbak lehetnek. A legkockázatosabb a bárki számára elérhető hivatkozás: aki megkapja, bejelentkezés nélkül megnyitja a dokumentumot, és tovább is küldheti. Ha üzletileg szükség van rá, legyen lejárati ideje, és csak olvasási jogot adjon. Az alapértelmezett hivatkozástípus a megnevezett személyeknek vagy a szervezeten belülieknek szóló legyen, így a tágabb megosztást a felhasználónak tudatosan kell választania.
A Teams vendéghozzáférése és a más szervezetek felhasználóival folytatott csevegés két külön beállítás. Mindkettőnél érdemes eldönteni, hogy bármely külső tartomány jöhet, vagy csak a partnereké.
A vendégfiókok maguktól nem tűnnek el. Egy projekt végén a partner fiókja a hozzáféréseivel együtt a bérlőben marad, ezért a vendéglistát rendszeresen át kell nézni.
A belső megosztás is számít. A Copilot csak azt látja, amit a felhasználó is láthat, ezért egy túl tágan megosztott mappa tartalma a válaszaiban is felbukkanhat. Erről a biztonságos Copilot-bevezetésnél írunk részletesebben.
Levelezés
Kifelé az a kérdés, tud-e más a cég nevében levelet küldeni. Ezt az SPF, a DKIM és a DMARC rendezi, amiről külön cikkünk szól. A bérlőn belül a következő beállításokon múlik a legtöbb.
Automatikus továbbítás külső címre
Az átvett postafiókban a támadó gyakran első lépésként beállít egy szabályt, amely a beérkező leveleket csendben egy külső címre másolja. A külső címre irányuló automatikus továbbítást bérlőszinten érdemes tiltani, és csak indokolt esetben, név szerint engedélyezni.
Postafiók-szabályok
Ugyanilyen árulkodó egy új szabály, amely bizonyos feladók vagy kulcsszavak leveleit törli, vagy egy ritkán nézett mappába mozgatja. Így a felhasználó nem veszi észre a támadó leveleit, és a partnerek gyanakvó visszakérdezését sem. Az ilyen szabályokra a naplózásnál beállított riasztás figyel.
Adathalászat elleni szabályok
A levélszűrés házirendjeiben beállítható a megszemélyesítés elleni védelem a vezetők és a fontos partnerek nevére, valamint a külső feladó jelölése, amely a szervezeten kívülről érkező levélnél figyelmeztetést tesz az üzenet fölé.
Naplózás
Egy fiókátvétel vizsgálatánál az első kérdés, mikor és honnan léptek be, és mit csináltak a fiókkal. Erre az egységes auditnapló és az Entra ID bejelentkezési naplója felel, ha be van kapcsolva és még megvan.
Az auditnapló az újabb bérlőkben alapértelmezetten be van kapcsolva, a régebbieknél érdemes ellenőrizni. A nagyobb gond a megőrzés: a naplók csak korlátozott ideig maradnak meg a bérlőben, a behatolást pedig gyakran hetekkel később veszik észre. Ezért érdemes őket egy külön tárolóba vagy SIEM-be másolni, ahol a bérlőben jogot szerzett támadó sem tudja törölni őket.
Riasztás kell legalább az új adminisztrátori szerepkör kiosztására, az MFA-módszer módosítására, a külső továbbításra vagy gyanús postafiók-szabályra, és a szokatlan helyről érkező bejelentkezésre. Hogy egy incidenshez milyen forrásból mit érdemes gyűjteni, azt a naplózásról szóló cikkünkben írtuk le.
Mit érdemes először rendbe tenni
Ha egyszerre nem fér bele minden, ez a sorrend adja a legtöbb védelmet a legkevesebb munkával:
- Adminisztrátori fiókok: kevés globális adminisztrátor, külön adminisztrátori fiókok adathalászat-álló MFA-val, és egy kipróbált vészhelyzeti fiók.
- Többfaktoros hitelesítés minden felhasználónak, szűk és dokumentált kivételekkel, az örökölt hitelesítés tiltásával.
- A külső címre irányuló automatikus továbbítás tiltása és az alkalmazás-hozzájárulás korlátozása.
- Az auditnapló ellenőrzése, a naplók kimásolása és az első riasztások beállítása.
- A külső megosztás alapértelmezéseinek szigorítása és a vendégfiókok átnézése.
- A feltételes hozzáférés finomítása eszköz- és kockázatalapú feltételekkel.
Az első két lépés a felhasználóknak alig jelent változást, ha a szabályokat előtte naplózó üzemmódban kipróbálták.
Ha szeretné tudni, hol tart a saját bérlője, a Microsoft 365 biztonsági keményítés a bérlő biztonsági állapotának felmérésével indul. Ezután beállítjuk a többfaktoros hitelesítést és a feltételes hozzáférési szabályokat, szigorítjuk a külső megosztási és levelezési beállításokat, a végrehajtott változtatásokat pedig dokumentáljuk.
