Ügyfelekkel való konzultáció során szinte mindig elhangzik a kérdés: melyek az ingyenes Sentinel-konnektorok? Tudjuk őket definiálni, de vannak olyan ingyenes konnektorok, amik tartalmaznak fizetős elemeket is.
Ingyenes adatforrások:
Azure AD Identity Protection
Azure Activity Logs
Office 365
Microsoft Defender for Cloud
Microsoft Defender for IoT
Microsoft 365 Defender
Microsoft Defender for Endpoint
Microsoft Defender for Identity
Microsoft Defender for Cloud Apps
Fontos tisztázni: a data connector bekötése mindig ingyenes. A logfileok esetén csak az Azure Acive Directory és O365 audit logok ingyenesek. A többi logforrásnál csak az alert és incidens generálás és néhány aktivitás ingyenes.
Nézzük egyenként a data connectorokat:
Azure AD Identity Protection:
Előfeltétel: Azure AD Premium 2 licensz
Ingyenes adattipus: Security Alert (IPC)
Azure Activity:
Ingyenes adattipus: minden tipus
Office 365
Ingyenes adattipus: Sharepoint, Exchange és Teams activity
Defender for Cloud:
Ingyenes adattipusok: Security Alert
Defender for IoT:
Ingyenes adattipus: Security Alert
Microsoft M365 Defender:
Ingyenes adattipus: Security Alert és Security Incident
Figyelem: a többi adatbetöltés már számolódik a Sentinel költségbe!
Defender for Endpoint:
Ingyenes adattipus: Security Alert (MDATP)
Defender for Identity:
Ingyenes adattipus: Security Alert (AATP)
Defender for Cloud Apps:
Ingyenes adattipus: Security Alert (Defender for Cloud App)
A Cloud Discovery logok bekapcsolása szintén számolódik a Sentinelben
Összefoglalva:
Mint látjuk, a Microsoft Sentinelt költséghatékony módon tudjuk használni arra hogy az O365 és Azure Activity logokat gyűjtsük és a különböző Microsoft termékekből érkező alerteket is fogadjuk.
Ügyfeles konzultáció során merült fel az alábbi scenárió:
“Exchange 2016 hybrid környezetünk van, sok postafiókot már migráltunk az O365-be, de sok még a földi Exchange-en van. Az Exchange Online elérésére van több Conditional Access lehetőségünk (MFA, Intune compliant device stb) is, lehetne ezt a földi fiókokra is alkalmazni?”
Jó hír, hogy lehetséges, a Hybrid Modern Authentication révén (minimum követelmény az Exchange 2013 és Outlook 2013)
Hogyan néz ki a Hybrid Modern Authentication (HMA) folyamat?
A felhasználó elindítja az Outlookot ami az autodiscover segítségével csatlakozik a földi Exchange–hez. Innen a kapcsolat továbbmegy az evoSTS URL-hez, amit az HMA kialakítása során beállítottunk.
Az Outlook az AzureAD-hoz fordul, végrehajtja a modern auth folyamatot, alkalmazódnak rá az esetlegesen beállított Conditional Access szabályok.
A sikeres auth után a felhaszáló megkapja az Access Tokent és Refresh Tokent.
Az Access Tokent átadva a földi Exchange szervernek, a mailbox elérhetővé válik.
Kinek ajánlott a HMA?
Olyan szervezeteknek, ahol hosszú távú hybrid kialakítását tervezik, és biztosítani kívánják, hogy a földi postafiókok elérése is ugyanolyan szabályozottan történjen, mint a felhős esetén.
Bár tehetjük kötelezővé informatikai szabályzat révén, hogy pl. minden céges adatot tartalmazó dokumentumot/emailt a felhasználók lássanak el a megfelelő sensitivity labellel, az emberi hibát nem lehet kizárni; ha elfelejti rátenni a labelt, adatszivárgási probléma lehet belőle. Illetve ha a meglévő fileokra (pl. Sharepoint Online-ban) is szeretnénk “védelmet”, szintén segítségül hívhatjuk az M365-öt.
Érdemesebb hát az automatizmust felhasználni, a client-side labeling és service-side labeling segítségével.
A licenszelési előfeltétele: Microsoft 365 E5/A5/G5, Microsoft 365 E5/A5/G5/F5 Compliance and F5 Security & Compliance, Microsoft 365 E5/A5/G5 Information Protection and Governance, Office 365 E5, Enterprise Mobility + Security E5/A5/G5, and AIP Plan 2
Ennél a módnál “on-the-fly” történhet meg a labelezés az épp szerkesztés alatt álló dokumentumban vagy emailben. Amennyiben a rendszer érzékeli, hogy szenzitív adatokat tartalmaz (ezt nekünk kell definiálni a beállításokban), felajánlja a felhasználónak az adott label alkalmazását vagy kötelezően ráteszi.
Az alábbi példában látható, ha a dokumentum tartalmaz TAJ-számot, ajánlja fel a felhasználónak a label használatát:
Ennél a módnál nemcsak az újonnan létrehozott dokumentumok labelezést lehet ellátni, hanem a meglévő, helyben tárolt adatokra is. Ugyanazokat a feltételeket lehet konfigurálni, mint a fenti client-side példában:
Kiválaszthatjuk, hogy melyik label alkalmazódjon:
A policyt első alkalommal kötelezően Simulation mode-ban kell futtatni:
Ha mindent rendben találtunk a szimuláció lefutása után, engedélyezhetjük a tényleges alkalmazódást a fileokra. A label automatikusan rákerül a megfelelő fileokra, anélkül hogy a felhasználónak egyenként kellene megnyitni/alkalmazni azt.
Jó tudni:
Néhány korlátozás, amit szem előtt kell tartani.
Ha egy file már tartalmazott egy kézzel hozzáadott labelt, az automatizmus nem cseréli le.
Az automatic labeling felülírja a default sensitivity labelt (ha volt definiálva)
A service-side labeling nem alkalmazza a labelt meglévő emailekre, csak küldéskor (data in transit) teszi rá
Maximum 25 ezer automatic labeling művelet lehet naponta.
Sokszor nemcsak az ügyfelek, de a tanácsadók is elveszettek lehetnek, hogy melyik M365 csomagban milyen szolgáltatás szerepel, milyen limitációkkal stb.
Az alábbi két táblázat hasznos lehet, hogy eligazodjuk a “rengetegben”
A Seamless SSO segíti a felhasználói élményt, hogy domain-joined gépeken automatikusan bejelentkeznek az Azure AD-ba.
Amikor az AD Connect segítségével konfiguráljuk az SSO-t, a földi domainben létrejön egy AZUREADSSOACC computer objektum. Ez felelős érte, hogy megvalósuljon az SSO az Azure AD-val. A működésének rövid leírása:
Felhasználó be szeretne jelentkezni egy felhős web app-ba.
Az App átírányítja az Azure AD-hoz.
Az adott App nem továbbít semmilyen domain vagy tenant információt, ezért meg kell adni a felhasználónak a felhasználó nevét.
A webbrowser 401-es hibát ad, mert nincs érvényes kerberos ticket.
A felhasználó böngészője kerberos jegyet igényel a “AZUREADSSOACC” objektumhoz. Igen és itt nyer értelmet ez az objektum, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget és ez az objektum képviseli az Azure AD-t.
Kapunk egy kerberos ticketet a “AZUREADSSOACC” objektumhoz, ami titkosítva lesz a “számítógép” kulcsával.
A felhasználó böngészője elküldi a titkosított kerberos ticketet.
Azure visszafejti a titkosított kerberos ticketet, azzal a kulcssal, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget.
Amennyiben érvényes a jegy, akkor a böngésző visszakap egy tokent, amivel hozzáférhet az erőforráshoz.
Ezáltal a felhasználó sikeresen bejelentkezett a wep app-ba, anélkül, hogy megadta volna a jelszavát.
Ez az objektumot érdemes egy külön OU-ba tenni és bekapcsolni rajta a “protect object from accidental deletion” opciót is.
A Kerberos-kulcs (decryption key) a lényeges, ezt érdemes legalább 30 napota cserélni. Ha nem tesszük, akkor kerül ki az Azure portálra a figyelmeztető ikon.
Hogyan cseréljük a Kerberos-kulcsot?
A művelethez szükségünk van Global Administrator és Domain Admin jogosultságra. Lépjünk be az AD Connect szerverre és admin powershellben navigáljunk el a “Microsoft Azure Active Directory Connect” mappába:
cd “C:\Program Files\Microsoft Azure Active Directory Connect\”
Importáljuk be az SSO modult:
Import-Module .\AzureADSSO.psd1
A következő paranccsal végrehajtjuk a hitelesítést az Azure AD felé:
New-AzureADSSOAuthenticationContext
Futtassuk le a kulcs-csere parancsot, és hitelesítsük magukat a földi AD felé:
Update-AzureADSSOForest
A hitelesítés után megtörténik a kulcs cseréje:
Rövid idő után frissül az Azure portálon is:
Összefoglalva: evvel az egyszerű művelettel érdemes legalább 30 naponta frissíteni a Kerberos-kulcsot. Az AZUREADSSOACC objektumra kevés figyelem jut, de érdemes jól “eltenni” egy külön OU-ba és bekapcsolni rajta a véletlen törlés elleni védelmet.
Az Azure AD egyik, még Preview fázisban lévő megoldása, a Continous Access Evaluation jó eszköz lehet, hogy még robosztusabb legyen a hozzáférési szabályzatunk.
Amikor egy felhasználó bejelentkezik egy online szolgáltatásba (pl. Exchange Online), akkor az Azure AD egy hozzáférési tokent állít ki számára, egy óra érvényességgel. A token érvényésségének lejártáig él a hozzáférés.
(az időtartam egyébként szabályozható, pl. conditional access session control segtíségével)
Nézzünk egy alappéldát:
Mi történik, ha letiltunk egy felhasználót?
Sajnos, a token érvényessége ettől még megmarad és továbbra is eléri az online szolgáltatást. Ez sok szervezet számára elfogadhatatlan, és szükség van granulárisabb megoldásra.
Itt jön képbe a Conditional Access Evaluation (CAE). Ennek lényege, hogy bizonyos események hatására az addigi token érvényessége azonnal megszűnik és szükséges lesz egy újra-authentikáció végrehajtása.
Milyen eseményeknél történik meg?
A felhasználói fiókot letiltjuk/töröljük
Jelszóreset vagy jelszócserét követően
MFA engedélyezésekor a felhasználó számára
Az admin visszavonja a meglévő hozzáférési tokeneket
Azure AD Identity Protection magas kockázatot érzékel
Valamelyik esemény bekövetkeztekor gyakorlatilag egy percen belül megszűnik a hozzáférés a Sharepoint Online, Exchange Online és Teams szolgáltatásokhoz (jelen preview állapotban ezt a két szolgáltatást támogatja). Saját tesztelés alapján 20-30 mp elteltével jöttek az authentikációs popup-ok, laptopon-telefonon-tableten egyaránt.
Milyen alkalmazások támogatják a CAE-t?
Alapesetben a kliensek megpróbálják felhasználni a már meglévő tokent a hozzáféréshez. CAE-vel a kliens az ún. claim challenge segítségével tudja, hogy nem a tárolt tokent kell használnia, hanem újat kell kérnie az Azure AD-tól (authentikáció bekérése)
Az alábbi alkalmazások CAE-kompatibilisek:
Outlook Windows
Outlook iOS
Outlook Android
Outlook Mac
Outlook Web App
Teams for Windows (Only for Teams resource)
Teams iOS (Only for Teams resource)
Teams Android (Only for Teams resource)
Teams Mac (Only for Teams resource)
Word/Excel/PowerPoint for Windows
Word/Excel/PowerPoint for iOS
Word/Excel/PowerPoint for Android
Word/Excel/PowerPoint for Mac
Hogyan működik a gyakorlatban?
Az alábbi példában úgy állítottuk be a Conditional Access policyt, hogy az online szolgáltatást csak meghatározott IP-tartományokól elérhető (pl. irodai hálózat)
A CAE-kompatibilis kliens megkéri a tokent az Azure AD-tól (vagy felhasználja a tárolt érvényes tokent)
A Conditional Access Policy megvizsgálja a hozzáférési kérést és engedélyezi (mivel az irodai hálózatban van)
A kliens megkapja a hozzáférési tokent
A felhasználó elmegy az irodai hálózatból, átvált mobilnetre
A kliens az engedélyezett IP-tartományon kívülről küldi a hozzáférési kérést
Az Azure AD megvizsgálja a kérést
Az Azure AD megtagadja a hozzáférést és 401+ claim challenge-et küld vissza a kliensnek
A kliens értelmezi a 401+ claim challenge-t, és nem próbálja a tárolt tokent használni, hanem újat kér
A Conditional Access megtagadja a hozzáférést, mert nem a policyben engedélyezett IP-tartományokból érkezett a kérés.
Ide kell felvinni azokat az IPv4 és IPv6 tartományokat, amikre szeretnénk ebben az esetben a CAE-t hasznáni.
Összefoglaló:
A CAE egy nagyszerű irányba mutató fejlesztés, és bízhatunk benne, hogy a preview után még több funckióval bővül. Addig is, érdemes kipróbálni és használatba venni.
A pandémia miatt nagyon sokan kényszerülnek otthonról dolgozni és meetingelni, ahol sokszor korántsem ideálisak a körülmények: pont akkor kezd el falat fúrni a szomszéd (ő is otthon van, ráér 🙂 ), a másik szobából áthallatszik a kisgyerekek zsinatolása, és még ezer háttérzaj lehet, ami zavarhatja a Teams-meetingeket.
Év végére megérkezett a frissítése a Teams szolgáltatásba, ami beépített zajszűrőt használ. A mesterséges intelligencia folyamatosan elemzi a hangokat és képes kiszűrni a nem beszédhez tartozó zajokat.
A Teams kliensben a Settings / Devices résznél találjuk a Noise Suppression beállításokat:
A következő opciók vannak:
Auto: a Teams figyeli a háttérzajokat és szükség esetén kiszűri őket, pl. kutyaugatás vagy papírzörgés
Low: a zajszűrés folyamatos, ideális ha pl. a háttérben zenét hallgatnak
High: minden zajt eltávolít, ami nem beszédhez köthető
Off: nincs zajszűrés
Az alapbeállítás az Auto, érdemes ezen maradni és hagyni, hogy a mesterséges intelligencia tegye a dolgát. A magasabb szintű szűrések (Low, High) viszont többletterhelés a gépnek, CPU szinten.
Amennyiben olyan “szerencsénk” van, hogy a szomszéd fúrni kezd, akkor a meeting idejére érdemes a High opciót választani.
Zoltan Istvanffy's IT Blog 