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.

Miért van szükség az E5-re?

Az M365 E5 a legnagyobb nagyvállalati csomag, ami a Microsoftnál elérhető. A cikkben csak az IT-biztonsággal kapcsolatos részeire térek ki, az egyéb komponenseire (PowerBI, Audio Conferencing stb) nem.

Miért érdemes tehát az E5-be invesztálni? A legfőbb szempont, hogy nem kell csak IT-kiadásként gondolni a licenszekre, hanem komoly szerepük van az üzletfolytonosság fenntartásában. Ha egy vírustámadás miatt leáll a cég működése, az veszteség. A flottaüzemeltetők sem költségként tekintenek minden kötelező szervizelésre, hanem befeketetésként, hogy az üzlet működjön, fennakadás nélkül és bevételt termeljen.

A modern IT-világban már nem nehéz megoldani a folytonossághoz szükséges redundanciát, akár felhős, akár földi eszközökkel. Mindig be lehet tenni még egy szervert, még egy switchet, még egy internetkapcsolatot behúzni egy X-edik szolgáltatótól.

A következő feladat ennek a működésnek a “faltól-falig” védelme. A védekezés minden cég feladata, mérettől függetlenül. A végpontok, az identitások (felhasználói accountok) és céges adatok védelme kritikus feladat.

Régi és veszélyes gondolkodás, hogy “á, ki kíváncsi a mi adatainkra…”. Előfordult már, hogy a “kis” marketing partner céget törték fel, így szerezve belépési adatokat és hozzáféréseket a “nagy” céghez.

Az alábbi ábrán a klasszikus támadási lánc, az attack kill chain látható:

Balról jobbra haladva, röviden: phishing levelekkel és emberi tévedést- hiszékenységet kihasználva a támadók bejutnak a rendszerbe. Onnan továbbhaladva megpróbálnak egyre magasabb jogosultságokat megszerezni (lateral movement, admin jogosultságok megszerzése). Végül átveszik az irányítást a domain felett és a megszerzett adatokat kijuttatják (extrafilate data)

Itt jön be a képbe az E5 szerepe:

A fenti támadási lánc minden eleméhez van védelmi megoldása. A támadások már az elején azonosíthatók és megakadályozhatók.

Ahogy a képen látjuk, a támadás első fázisára az O365 ATP nyújt megoldást. A phishing maileket fejlett gépi intelligenciával megtámogatva megszűri, a csatolmányokat felhős sandboxban lefuttatja és elemzi viselkedésüket, a mailekben érkező linkeket megszűri, reputációs adatbázis alapján. Szintén erős az anti-spoofing, azaz levélhamisítás elleni védelme.

A következő részben az account feltörési kísérleteket és esetlegesen ellopott identitásokat az Azure AD Identity Protection és Azure ATP szolgáltatásokkal lehet felfedezni és megállítani.

Az Identity Protection figyel a bejelentkezési anomáliákra (idegen országokból, fertőzött hálózatból történéő belépésékre) és szükség esetén kikényszeríti a multi-faktoros hitelesítést, így meggyőződve róla, hogy a valódi felhasználó lépett be.

Az Azure ATP pedig a földi rendszerek kommunikációját figyeli (domain controllerek) és figyelmeztet, ha támadás készülődik (pl. jelszótöréses támadás egy felhasználói fiók ellen vagy Kerberos-ticket manipuláció). Ahogy az Identity Protection esetében, itt is a gépi elemzés segíti a támadások felmérését.

A céges adatok kiszivárogatásának megakadályozására és DLP-funkcióra pedig az utolsó fázisban szereplő Cloud App Security képes.

A Cloud App Security képes felmérni a végpontok (laptopok) forgalmát, adatszivárgási, jogosultatlan megosztási kísérletekre felhívni a figyelmet és megállítani azokat.

Milyen szolgáltatásokat kapunk még az E5-tel?

  • Self-service password reset, önkiszolgáló jelszóvisszaállítás: a felhasználók az IT-helpdesk segítsége nélkül tudják resetelni elfelejtett jelszavukat, kétfaktoros hitelesítés mellett
  • Conditional Access, feltételes hozzáférés: segítségével definiálható, hogy melyik felhős (és adott esetben földi) céges erőforráshoz milyen feltételek esetén lehet hozzáférni. Például, céges levelezés csak domain-tag gépről legyen elérhető.
  • Azure Information Protection, dokumentumvédelmi megoldás: a céges adatok kategorizálására és szükség esetén védelmére is. A védett dokumentumokhoz csak a meghatározott jogosultsággal bíró kör fér hozzá, függetlenül a file helyétől (emailen elküldve, USB-re kimásolva stb.)
  • Azure AD Privileged Identity Management, felhős jogosultságkezelési megoldás: admin szerepkörök időre történő megadása, auditálással, kötelező előzetes jóváhagyásokkal. Segítségével előírható, hogy ki, mennyi időre, milyen jogosultságot kapjon, majd az idő letelte után automatikusan visszavonódik.
  • Azure MFA, többfaktoros hitelesítés: segítéségvel az erőforrásokhoz való hozzáférést megerősíthetjük, a jelszavas bejelentkezésen túl. A fent említett Identity Protectionnal kombinálva, különböző scenáriókra is automatikus reagálás előírható. Például másik kontinensről történő bejelentkezési kísérlet esetén kötelező MFA-hitelesítés végrehajtása.
  • Microsoft Defender ATP: végpontvédelmi megoldás, ami a fejlett támadási formákat és fenyegetéseket észleli és elhárítja. Figyeli a végpontok viselkedését és gépi intelligencia segítségével proaktívan választ ad a felmerülő incidensekre

A teljes E5 funkcionalitás listája elérhető az alábbi linken: https://docs.microsoft.com/office365/servicedescriptions/downloads/microsoft-365-compliance-licensing-comparison.pdf

A fenti termékek működése és nagyfokú integráltsága miatt (pl. Azure ATP integrálódik a Cloud App Securityvel, így egy helyen tekinthetők meg az érintett fenyegetések) számít igazán ütőképesnek az M365 E5. Amennyiben olyan megoldást keresünk, amivel a céges adatokat, a végpontokat és felhasználói fiókokat biztonságban szeretnénk tudni, az E5 egy jó alternatíva lehet.

Miért fontos használni a Junk Email foldert?

Az Outlookban megtalálható Junk Email folder mindig is nagy viták tárgya volt. A felhasználók nem szeretik, mert ők csak az Inboxot nézik, az üzemeltetőknek is nyűg, ha sorra érkeznek a ticketek “nem érkeznek meg a leveleim”, holott csak a Junkba került.

Erre a problémára sok helyen azt a megoldást adják, hogy a spam-levelek tárgyába betesznek egy előtagot (prepend subject) pl [SPAM] és így küldik be a felhasználók inboxába. A felhasználók pedig tudomásul veszik, hogy néha bejön valami spam, de fontos levél biztosan nem kerül máshova.

Mindenki elégedett a helyzettel mindaddig, amíg nem jönnek az újabb panaszok: a Junk Email folderbe került a levél. Hát ez megy hogy lehet? Hiszen a spamszűrő (esetünkben Exchange Online Protection) oldalán beállítottuk, hogy a levél tárgyába tegyen valamit és utána Inbox. De mégis…

A válasz az Exchange postafiókokhoz tartozó rejtett antispam-rule (“By default, the junk email rule – a hidden Inbox rule named Junk E-mail Rule – is enabled in every mailbox)

Röviden, ehhez a szabályhoz a Spam Confidence Level (SCL) érték 4-esre van állítva. Ha az EOP ennél magasabb értéket állított be SCL-nek (pl 5-ös) akkor hiába a prepend subject, ettől még a Junk Email folderbe fog kerülni a levél.

Ezt a szabályt ki lehet kapcsolni felhasználónként:

Set-MailboxJunkEmailConfiguration “felhasználónév” -Enabled $false

Vagy az összes postafiókra:

$All = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited; $All | foreach {Set-MailboxJunkEmailConfiguration $_.Name -Enabled $false}

Ezt azért jegyezzük meg, mert később lesz jelentősége: “When the junk email rule is disabled on the mailbox, Exchange can’t deliver messages to the Junk Email folder based on the SCL Junk Email folder threshold”, azaz az Exchange nem fog tudni Junkba mozgatni leveleket. Ezt is akartuk,nem? Feladat teljesítve 🙂

Nos, kikapcsoltuk a fenti hidden szabályt, most már tényleg nem kerülhet semmilyen levél a Junk Email folderbe (ez így nem igaz, hiszen a Blocked Senderektől érkező mailek akkor is itt landolnak majd)

Ezután jön a következő fejvakarás: a spoofed és impersonated-gyanús levelek simán az Inboxban landolnak (a címzett zoltan.istvanffy@qualysoft.com, a feladó pedig zoltan.istvanffy@istvanffy.eu, ráadásul a Display Name is megegyezik, ez elég erősen véleményes lehet, mint megtévesztő)

Belenézve az O365 ATP policykbe, amikkel kontrolláljuk a spoof-impersonated próbálkozásokat, a következő a beállítás:

Hát igen, sajnos az előbb lőttük ki az Exchange képességét, hogy leveleket tudjon mozgatni a Junk Email folderbe, így nem tudott mit tenni, betette az Inboxba.

Visszakapcsolva a Junk Email Rule-t, a következő spoofolt levél már szépen a Junkba kerül:

Sajnos a spoof/impersonate policynél nincs olyan opció, hogy prepend subject, így ezt nem tudjuk beállítani.

És akkor még ott van a ZAP…

A Zero-hour auto purge előnye, hogy a már kézbesített levelek közül is visszamenőleg ki tudja szedni a káros leveleket (ehhez a mailboxnak az Exchange Online-ban kell lennie). Tegyük fel, kapunk egy mailt, benne egy ártalmatlan linkkel. Pár óra múlva a link mögé elhelyeznek egy adathalász oldalt. Erről a Microsoft is hamar tudomást szerez (a Security Intelligence Graph-ba érkező szignálok alapján), és automatikusan elindít egy workflow-t, amivel ezeket a leveleket átteszi a Junk Folderbe. Nagyon szuper szolgáltatás. Igenám, de:

“ZAP moves the message to the Junk Email folder, as long as the junk email rule is enabled on the mailbox ” azaz a működéséhez kell a junk email rule….

pluszban szintén nem működik, ha prepend subject megoldást válaszottunk “Prepend subject line with text: ZAP takes no action on the messagePrepend subject line with text: ZAP takes no action on the message

Összegezve az eddigieket, bár megoldottuk a felhasználóink számára, hogy ne kerüljön semmi a Junk Email folderbe, viszont kilőttünk két fontos védelmi vonalat: spoof-impersonation protection és a ZAP.

Mi lehet a legjobb megoldás: a fentiekből világosan látszik, hogy technikai szempontból a Microsoft erősen támaszkodik a Junk Email folderre. Amennyiben szeretnénk maximalizálni a védelmünket, érdemes átgondoni a koncepciót és használni a beépített lehetőségeket. A felhasználók felé pedig egy alapos (és folyamatos!) kommunikációval meg kell értetni, hogy bár nehézkesebb lehet a Junk Email foldert is figyelni, de összeségében közös érdek a védekezés. Az IT pedig természetesen a finomhangolással biztosítsa, hogy a lehető legkevesebb legitim levél kerüljön a Junk mappába.

Ahogy a bevezetőben is említettem, ez a spam-nem spam-junk kérdés örök vita, de azt látni kell felhasználói-üzemeltetői oldalról, hogy csak közös párbeszéddel-kompromisszummal lehet kezelni a kérdést.

AzureAD Password Protection

A jelszavak problémája az üzemeltetők és felhasználók örök fejfájása. Nem részletezem, mindenki ismeri a problémát, túl bonyolult, túl gyakran kell változtatni, a felhasználó felírja egy post-it-re a monitorára ragasztva, a panaszlista végtelen.

Talán rövidesen eljut a világ a jelszómentes berendezkedésig, ahol ezeket a gondokat elfelejthetjük, addig is egy kis hasznos segítség:

Világszerte nagy problémát jelentenek a gyakran használt gyenge jelszavak (pl. password, admin, qwert123, letmein, secret….) és a könnyen kitalálható verziók (pl. p@ssw0rd stb). A felhasználók is előszeretettel próbálják a cégnevet belevenni a jelszóba, hogy számukra könnyen megjegyezhető legyen (pl. Adatum cégnél @datuM123 és hasonló formák). Az esetleges támadónak így nem nagyon kell erőlködnie, pár jól célzott próbálkozással akár hozzáférést is szerezhet a felhasználói fiókhoz.

A gyenge és könnyen kitalálható jelszavak problémájára ad megoldást az AAD PP.

Beépített és folyamatosan frissülő “weak passwords list” és az adminok által egyedileg definiált tiltott jelszavak listájával megakadályozza, hogy könnyen kitalálható jelszavakat állítsanak be a felhasználók. Ez működhet az tisztán az AzureAD-ra, de akár a földi rendszerek is védhetőek vele.

A beállítása egyszerű, az Azure portálon az Azure Active Directory / Authentication methods / Password protection részhez kell navigálni, és kitölteni a Custom banned passwords mezőt:

A listába 1000 tételt lehet felvenni, minimum 4, maximum 16 karakter a követelmény.

A tiltott jelszó kiértékelése többlépcsős folyamat, mélyebben a mechanizmust a https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad cikk írja. Nagyon dióhéjban, tud különbséget tenni az “a és @” illetve “o és 0” értékek között, a végén egy pontszámítással megállapítva, hogy megfelelő-e a jelszó vagy sem (hány tiltott formát tartalmaz a jelszó, van-e további karakter megadva stb)

Nagy erőssége a megoldásnak, hogy földi rendszerrel is integrálható. Ebben az esetben a földi domain controllerek minden jelszóváltoztatás előtt “bekérdeznek” az AAD PP-be, hogy megfelel-e a policynek a jelszó. Ehhez minden domain controllerre (Windows Server 2012 vagy újabb) telepíteni kell egy AzureAD Password Protection DC Agent klienst, illetve egy vagy több member serverre a AzureAD Password Protection Proxy összetevőt.

A DC agentek a Proxy kliensek segítségével kommunikálnak az AzureAD-val és validálják a jelszóváltoztatást. Az alábbi ábra mutatja a működést:

A rendszer kipróbálható Audit és Enforced módban, természetesen érdemes az elején a teszt-üzemmódot választani. A domain controllereken található Eventlogok segítségével láthatóak a jelszóváltozatások, amik éles üzemmód esetén tiltásra kerülnének:

Éles üzem esetén pedig ha a felhasználó nem megfelelő jelszót állítana be, az alábbi üzenetet kapja:

A licenszelést tekintve, ha egyedi tiltólistát szeretnénk használni, és/vagy hibrid környezetben használni, Azure AD Premium P1 vagy P2 licensz szükséges.

Részletes step-by-step leírások a működésről és beüzemelésről itt találhatóak:

Segít a felhasználó – könnyebb védekezés a spamek ellen

A levélszemét egy érdekes terület, amit mind a felhasználók, mind az adminok jól ismernek (sajnos…). Számszerűleg az adminok vannak a legkevesebben, a felhasználók a legtöbben, hát miért ne kérnénk hogy segítsenek a spam elleni küzdelemben? 🙂

Az M365 egy jó eszközt biztosít ehhez, az új user submission policy segítségével. A beállítást a Threat Management alatt találjuk:

Lényege, hogy az Outlookba beépül a Report Message nevű addon, amivel a felhasználó könnyen jelentheti a levélszemetet:

Ezt az add-ont lehet csoportokra vagy minden felhasználóra érvényes módon telepíteni.

A policy újdonsága, hogy beállítható egy reporting mailbox, ahova a bejelentett emailek másolata is kerül, ami további elemzésekben segíthet:

A bejelentésekhez lehet egyedi üzenetet is fűzni a felhasználól számára (itt fel lehet hívni a figyelmet, hogy a Microsoft is átvizsgálhatja a mailt, ezért fontos a személyes vagy érzékeny adatok védelme)

Érdemes ezt a az eszközt igénybe venni, a felhasználókat is bevonni a levélszemét probléma megoldásába, hiszen ez közös érdek és több szem többet lát 🙂

Bejelentkezés lustáknak…

..ráadásul biztonságosan 🙂

Aki hozzám hasonlóan nem szeret sokat gépelni bejelentkezéskor, annak jó szolgálatot tehet egy FIDO2 security key.

Ez egy USB (vagy Type-C) csatlakozójú kis token, amivel az Azure/Office szolgáltatásokba felhasználónév és jelszó megadása nélkül lehet bejelentkezni.

Természetesen támogat minden más platformot is, amelyik implementálta ezt a lehetőséget, pl. Google, Facebook, AWS (Linkedin, az nem…) Másik nagy előnye, hogy nem igényel semmilyen driver telepítést, így bármelyik gépen azonnal használható.

Nézzük, hogyan történik egy bejelentkezés az Office Portalra, Chrome böngészőből. (először persze regisztrálnom kell a security keyt az AzureAD-ban)

A kezdőképernyőn nem kell beírni felhasználónevet, csak kattintani a Sign-in Optionsra

Az opciók közül a Sign in with security key-t választva.

Meg kell adni a security key-hez tartozó PIN-kódot (a hitelesítés első faktora)

Végül pedig meg kell nyomni a security key-en lévő fizikai gombot.

Ez a fizikai gomb biztosítja a második faktort a hitelesítéshez (kell felhasználói interakció, nem lehet programkódból kitrükközni)

A fenti módon tehát úgy léptem be a portálra, hogy semmilyen felhasználónevet és jelszót nem kellett gépelnem, megtakarítottam némi fáradtságot, esetleg elrontott jelszó miatti bosszankodást is. A kétfaktoros hitelesítés miatt pedig a belépési folyamat is biztonságosabb volt.

A FIDO2 kulcsok használhatóak Windows 10 bejelentkezéshez is (csak AzureAD joined gépeken, a klasszikus on-prem domainhez csatlakoztatott eszközöknek tavaszig várniuk kell erre a funkcióra)

Összefoglalva, a világ a jelszómentes, kétfaktoros hitelesítések felé halad, egy FIDO2 security key pedig egy nagyszerű alternatíva ehhez.

Új szemlélet az IT-biztonságban – Zero Trust Modell

avagy a perimeter-alapú hálózati védekezés miért kevés?

Az utóbbi években bekövetkezett robbanásszerű IT-fejlődés komoly kihívás elé állítja az üzemeltetőket és cégvezetőket egyaránt. Elterjedtek a mobileszközök (laptopok, tabletek, okostelefonok), az olcsó internet gyakorlatilag közszolgáltatássá lépett elő, és ezek a folyamatok változást generáltak a felhasználók oldalán is.

Egyre nőtt az igény, hogy mobileszközét a céges hálózaton kívül is használhassa, dolgozhasson otthonról, esetleg akár a saját eszközeit is bevethesse (BYOD). Alapvető elvárás lett, hogy a levelezését kezelhesse az okostelefonján, utazás közben is tudjon céges dokumentumokat megnyitni és így tovább. Az IT-mobilitás megteremtése kvázi kötelező feladat lett.

Ennek a nyomásnak a szervezetek igyekeznek is megfelelni, a felhős megoldások bevezetésével egyre könnyebbé válik a szolgáltatások elérése (pl, Exchange Online, Microsoft Teams), már akár az otthoni tableten is gond nélkül lehet követni a céges levelezést. Az eszközök védelmét is igyekeznek úgy-ahogy megoldani, általában antivirus megoldás bevezetésével (laptopok esetén, okostelefonoknál szinte semmi…)

Ettől függetlenül azonban a szervezeteknél még mindig kardinális kérdés maradt a klasszikus céges hálózat védelme. Ez érthető, hiszen a nagyon új, “felhőben született” cégeket leszámítva, mindenki rendelkezik földi infrasruktúrával, ott található az identitás-középpont (Active Directory), és a céges erőforrások nagy része is. A védelemre jellemzően nagy figyelmet fordítanak, robosztus tűzfalrendszer-megoldások, IDS/IPS, DDOS védelem,bonyolult VPN-es megoldások, ezekre hajlamosak milliókat is költeni. Sok esetben csak annyi a gondolatmenet, hogy “mi védettek vagyunk, minket nem lehet feltörni”

A gond ott kezdődik, hogy ezek a védelmi megoldások csak “kintről”, az internet felől élnek. Mi történik, ha egy mobilkliens bekerül a céges hálózatba? Semmi, hiszen a határon belül van, nem vonatkozik rá védelmi policy. Sok terméknél a belső hálózat esetén leold minden védelem, az eszköz “szabaddá válik”.

(Természetesen, vannak megoldások a belső hálózat védelmére, kliensek szűrésére. Régen a Microsoft Network Access Protection tudta ellátni ezt a feladatot, illetve a Cisco-nak is van ilyen terméke)

A céges adatok, adatvagyon védelme viszont ugyanúgy lényeges, nem számít, honnan érik el a kliensek, külső vagy belső hálózatból. Itt jön a képbe a Zero Trust megközelítés:

“Állandó ellenőrzés, bizalom nélkül!”

A Zero Trust három alapelve:

  • az identitás (felhasználó hitelesítése) ellenőrzése
  • az eszköz védelme (egészségi állapota legyen megfelelő)
  • hozzáférés ellenőrzése (csak annyi jogosultsága legyen a felhasználónak, és csak azokhoz, ami éppen szükséges)

Hogyan biztosíthatók ezek?

Identitás védelmének erősítése és megkövetelése: többfaktoros hitelesítés megkövetelésével, biometrikus azonosítási megoldásokkal, jelszavak felszámolásával

Eszköz állapota: az eszközök MDM-megoldásba bevonásával, megfelelő egészség-állapot megkövetelésével (device health)

Least privileged user rights: senkinek ne legyen több jogosultsága, mint szükséges

A fenti három tétel megvalósításával (vonatkozzon ez külső-belső hálózatra) nagy lépés lehet tenni a biztonság növelésére.

A Microsoft Zero Trust architektúráját a lenti ábra szemlélteti:

A megoldás lényege: a felhasználó az Azure AD-ban hitelesíti magát (MFA-val), az eszközének felügyeletét az Intune látja el. Az Itune előír egy bizonyos egészség-állapotot az eszköz számára (pl. kötelező lennie vírusirtó megoldásnak, vagy PIN kód és eszköztitkosítás megléte). Az Azure AD Conditional Access megköveteli, felhasználó esetén kockázati szint nem lehet magas (azaz nem komprimittálódott az accountja, nem voltak gyanús bejelentkezési kísérletei több országból stb.). Szintén megkövetelhető, hogy milyen alkalmazásokkal lehet elérni a céges erőforrásokat. A Conditional Access segítségével ez a végtelenségig variálható, a szervezet igényei szerint.

Az utolsó jobboldali kockán látjuk az Azure Application Proxy megnevezést. Ennek segítségével földi (on-premise) erőforrásokat tudunk biztonságosan publikálni, adott esetben a földi Sharepoint elérését is a fenti feltételrendszehez köthetjük. Még akkor is, ha a kliens és az SP szerver egy hálózatban vannak!

Összefoglalva: az Azure AD-Intune-Azure Application Proxy segítségével megvalósulhat a Zero Trust Modell, amellyel valós időben szűrhető-engedhető-tiltható, hogy milyen erőforrást milyen felhasználó, milyen feltételekkel érhet el.

A Zero Tust Modell felé elmozdulás nagyon ajánlott minden szervezet számára, megfelelő feltételek biztosításval kielégíti a biztonsági és felhasználói élmények iránti igényeket.