Az egyszerű hitelesítés alkonya, MFA mindörökké?

Multi-factor authentication…IT-biztonsági berkekben az manapság egyik legnépszerűbb termék, sok esetben a “Szent Grál”, ami megoldja a szervezetek security problémáját.

Sajnos mint minden a világban, ez sem egyszerűen fehér vagy fekete, itt is fontos az átgondolt hozzáállás. Hiába a beruházás MFA-megoldásokba, minden felhasználónál bekapcsolva,stb, ha van olyan technikai megoldás, amire a többtényezős hitelesítés nem értelmezhető.

Tehát legyünk körültekintőek, hiába az MFA, ha az adott szolgáltatások elérhető legacy authentikációval is!

Block legacy authentication….ez olvassuk minden security guide-ban, mint egyik fontos tétel a biztonságos környezet kialakításában.

Mit jelent mindez?

Legacy authentication, mikor egyszerű felhasználónév/jelszó párossal hitelesítünk egy erőforráson, pl. levelezőszerveren. Ilyen többek között a POP, SMTP, IMAP, és MAPI protokollok. Mivel ezek nem támogatják a többfaktoros hitelesítést, a használatuk veszélyt jelent. Ha a felhasználói jelszót ellopják/feltörik, akkor bárhonnan bármikor elérik a céges erőforrásokat.

Hogy a sima jelszó-mint védelem- mennyire kevés, jól személteti az alábbi kép:

Megjelöltem egy tételt feketével. Bizony, hétkarakteres jelszó, ami tartalmaz kisbetű-nagybetű-szám-speciális szimbólumot, 17 óra alatt feltörhető….

Az Azure AD statisztikái szerint a jelszótámadások 99%-a a legacy authenticationhoz köthető. Ahol ezt már letiltották, ott 67%-kal csökkent a sikeres törések száma.

zek után nézzük, hogyan érdemes kivezetni a legacy authenticationt Azure AD környezetben? Segít az AzureAD Conditional Access.

előfeltétel: legalább Azure AD P1 licensz megléte.

  1. Mik a legacy protokollok? Mire valók pontosan?
  • Hitelesített SMTP – A POP és az IMAP-ügyfél által használt e-mail üzenetek küldésére.
  • Automatikus észlelés – Az Outlook és az EAS-ügyfelek segítségével kereshet postaládákat az Exchange Online-ban, és csatlakozhat azokhoz.
  • Exchange Online PowerShell – Az Exchange Online-hoz távoli PowerShell használatával való csatlakozáshoz használható. Ha letiltja az Exchange Online PowerShell alapszintű hitelesítését, a csatlakozáshoz az Exchange Online PowerShell-modult kell használnia. 
  • Exchange Web Services (EWS) – Az Outlook, a Mac Outlook és a külső alkalmazások által használt programozási felület.
  • IMAP4 – Az IMAP levelezőügyfelei használják.
  • MAPI HTTP-n keresztül (MAPI/HTTP) – Az Outlook 2010 és újabb verziói használják.
  • Kapcsolat nélküli címjegyzék (OAB) – Az Outlook által letöltött és használt címlista-gyűjtemények másolata.
  • Outlook Anywhere (HTTP-n keresztüli RPC) – Az Outlook 2016-ban használt
  • Outlook-szolgáltatás – A Windows 10 Posta és Naptár alkalmazása használja.
  • POP3 – A POP e-mail ügyfelek használják.
  • Jelentéskészítő webszolgáltatások – jelentésadatok beolvasására szolgál az Exchange Online-ban.
  • Egyéb ügyfelek – Az örökölt hitelesítést használóként azonosított egyéb protokollok.

2. Hogyan tekintsem át, milyen legacy protokollok vannak használatban?

Az AzureAD Sign-in logs kiváló eszközt nyújt számunkra a kereséshez. Navigáljunk el az AzureAD/Monitoring/Sign-ins részre. Válasszuk ki a kívánt időtartamot és a filterben adjuk hozzá a Client app mezőt, majd pipáljuk be az összes Legacy Authentication Clients-t.

Utána a Columns-nál adjuk hozzá, hogy jelentítse meg a Client Appokat is.

Így lesz egy kész táblázatunk, amiben látjuk a használatban lévő legacy protokollokat:

A tábálzatot letölthetjük CSV vagy JSON formában is, további feldolgozás céljából.

Miután beazonosítottuk a protokollokat, döntést hozhatunk a sorsuk felől. Szükséges a céges levelezéshez a POP? Kell-e támogatni az unsupported ActiveSync klienseket (ezek általában nem szabványos levelezőalkalmazások stb) ? Érdemes manapság a Modern Authenticationt használó alkalmazásokra áttérni (pl. Outlook 2013-tól felfelé és egyéb újabb alkalmazások) Vigyázat, a Skype for Business Exchange Web Services-t használ a Exchange-naptár eléréséhez, tehát tiltás esetén a Skype és naptár integrációtól elbúcsúzhatunk….

3. Blokkoljuk a legacy authenticationt! – monitor módban

Természetesen nem javasolt azonnali tiltást bevezetni, minden felhasználóra vonatkozóan. Szerencsére az Azure AD Conditional Access segítségével tudunk felmérést készíteni, hány felhasználót érintene a tiltás. A policyt beállítva, szűri az usereket, de nem blokkol, csak logolást végez. A szükséges beállítás a következő:

Ezt a policy érdemes futni hagyni 4-6 hétig, hogy elegendő adatot gyűjtsön.

Jön a kiértékelés rész, hány usert érintene a blokkolás? A Conditional Access Insights részen látható a Failure szám.

Érdemes felhasználói csoportokra bontva, fokozatosan bevezetni a tiltást. Azok az userek, akik már biztosan nem használnak ilyen régi protokollokat, bevonhatóak az enforce block beállításba.

4. Blokkoljuk a legacy authenticationt! – enforced módban

Miután meggyőződtünk róla, hogy a felhasználók készen állnak a kivezetésbe, a legegyszerűbb mód, ha a fenti policyt átállítjuk Report-only módból On-ra. Természetesen létrehozhatunk másik policyt, ami csak adott csoportra állítunk be és ott tiltjuk aktívan a legacy authenticationt.

A sig-in logok között látható lesz, ha mégis érkezne ilyen protokollon kapcsolódás:

Összefoglalva: nagyon népszerű manapság a többfaktoros hitelesítés, napról-napra több helyen is vezetik be, ami örvendetes tendencia. Viszont ne feledkezzünk meg róla, hogy csak akkor ér valamit, ha van mihez kötni a második faktort. Erre pedig a legacy protokollok nem képesek.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s