Přednáška: Microsoft Entra ID – Obrana
Konečně. Díl, kvůli kterému jsem se do celého studia Entra ID pustil. Jako obránci potřebujeme správně zabezpečit / ochránit Entra ID prostředí našich zákazníků. Avšak bez studia útoků – motivace, taktik, technik a procedur (TTP 😊) by byla obrana založena jen na pocitech.
Tímto dílem uzavírám naši krátkou sérii (počtem dílů, nikoliv množstvím času – cca 6 hodin školení) o Entra ID:
- Entra ID: Attack Surface
- Entra ID: Lateral movement and persistence
- Entra ID: Obrana (tento článek)
Pokud jste neviděli předchozí díly, určitě doporučuji začít jimi – celé školení na sebe navazuje.
Microsoft Entra ID – Obrana
Stejně jako u obrany on-premise prostředí, stavíme obranu Entra ID na více pilířích:
- Hardening: výchozí nastavení Entra ID není žádný zázrak. Pár přepínači dokážeme zabezpečení výrazně zvednout.
- Conditional Access: jedná se krok v rámci hardeningu (úpravu konfigurace pro vyšší zabezpečení). Avšak protože je CA rozsáhlá technologie, kterou jsme na on-prem Active Directory neměli, věnoval jsem jí samostatnou kapitolu.
- Monitorování: i přes sebelepší zabezpečení (hardening) může k nějakému incidentu dojít (však jste viděli předchozí epizody). Je proto nutné prostředí sledovat, zdali nedošlo k překonání našeho zabezpečení.
Jednoduše řečeno. Cílem hardeningu je útočníkům útok co nejvíce „zesložitit“ a zpomalit, abychom v rámci monitoringu měli čas je detekovat dříve, než dosáhnou svého cíle (napáchají škodu). - Zálohování: pokud by došlo na nejhorší a o data jsme přišli, případně byla narušena jejich důvěryhodnost (např. jejich částečná změna/falsifikace).
Jako vždy, mám pro vás zmíněná témata včetně názorných demonstrací. Doufám, že se vám školení bude líbit a přinese vám nové informace, znalosti či pohled na věc.
Jak zmiňuji na konci školení, touto epizodou zabezpečení Entra ID nekončí, spíše začíná. Microsoft 365 / Office 365 je rozsáhlé a rychle se vyvíjející prostředí. A nevypadá to, že v následujících letech by měl vývoj ustat.
Nástroje které jsme si vybrali
Když jsem školení natáčel, ještě jsem váhal mezi několika nástroji. Nakonec jsme si pro archivování logů, reportování a alertování vybrali AdminDroid.
Tento rok jsme investovali do nových výkonných serverů a tak se nám líbí možnost si provozovat AdminDroid sami. Získáváme tím (za dobrou cenu):
- rychlý nástroj (mnohem rychlejší než procházet logy přímo v M365),
- možnost archivovat logy po dobu několika let (aniž bychom museli řešit předplatné na Log Analytics pro každého zákazníka – značná administrativní zátěž),
- poměrně vysoké zabezpečení (vzhledem k uloženým tokenům, přístupům a datům se jedná o kritický server [viz má přednáška na Hacker Festu], proto je server nedostupný z internetu),
- multitenantní nástroj (data všech zákazníků vidíme současně – nemusíme tak logy kontrolovat pro každého zákazníka zvlášť),
- možnost spolupráce (k jednotlivým tenatům/datům můžeme nasdílet přístup i internímu IT).
AdminDroid pak doplňujeme o vlastní skripty, které kontrolují konfiguraci jednotlivých tenantů a auditují věci se složitější logikou.
Závěr
Toto interní školení bylo pro nás záležitostí srpna / září (na blogu jej zveřejňuji až se zpožděním). Nyní jsem již zase odpočatý a pracuji na interních školeních pro Intune a MS Defender. Snad vše půjde hladce 🤞.
Nechť jsou vaše sítě bezpečné.
Martin
Diskuze k článku
Petr Bartos
20. 11. 2023 v 16:48
Je fajn vědět, že cesty jsou. To, že nesmíme polevit v běhu, nezní tak příjemně, ale na tyhle zprávy jsme v blue teamech asi už zvyklí:)
Dotazy:
1) zmínil jste jako příklad v privilegovaných/hardenovaných firemních stanicích „vypájet“ USB porty nebo je softwarově zablokovat… máte to takhle? Chápal bych ten důvod, jak by se dalo pak fungovat s FIDO2 klíči? Link na místo ve videu: youtu.be/8Q7ZACJNbsU?t=3380
2) ad problém: v SignIn logs se sice dozvím, že přihlášení do každé další aplikace bylo úspěšné (protože MFA jsem už zadal a funguje SSO), ale nedozvím se, které bylo to prvotní přihlášení, na jehož základě jsem token dostal… Zkoušel jsem to taky různě ale marně hledat. Kdyby u vás nějaký úspěch, tak klidně nasdílejte
3) Temporary access password by se (při zavedení MFA do firmy všem) mohlo hodit jako možnost pro support-adminy, aby mohli pomáhat či nastavovat něco uživatelům. Bez nutnosti znát jejich heslo, či být celou dobu remote na jejich zařízení. Neobejde se to bez auditování téhle funkce. Jak se na tenhle usecase díváte?
A díky za tohle video. Vaše videa pro mě nikdy netrvají 2hodiny, ale minimálně hodiny 4 – zahrnují současné zpracování poznámek, dohledávání uvedených URL, tvorbu to-do listů apod. To se mi s jinými zdroji nestává, taková informační hustota. Takže poklona!
Odpovědět
Martin Haller
21. 11. 2023 v 10:17
Petře, děkuji za pochvalu.
Ad 1) Volil bych metodu SW blokování USB zařízení. Tyto produkty pak umí blokovat (pokud se nepletu) zařízení podle typu – tzn. můžete zablokovat pouze storage a necháte funkční FIDO. Jsou to však jen příklady – nakonec každý si zvolí opatření dle svých potřeb a hrozeb.
Ad 2) Stále k tomu nic nemám a jak debuguji další sign-in logy tak otázek spíše přibývá. Když budu mít více objevů, udělám na to zvlášť epizodu :).
Ad 3) Jj, takhle bych to taky viděl – nebo jako metodu pro jednoduší reset uživatelského hesla, či provisioning uživatelů bez hesla (koncept co jsem zatím nezkoušel, jen o něm četl https://jeffreyappel.nl/go-fully-passwordless-with-the-new-azure-ad-temporary-access-pass-feature/ ).
Odpovědět
Petr Bartos
20. 11. 2023 v 22:06
jinak Admindroid běží fakt svižně a je to zdá se hezky napsaná appka. Hned bych ji použil, ale hlodají mě obavy.
Chce práva Global admina (chce to ke každému tenantu?) a pak minimálně nějaký ještě servisní účet v EntraID. Jak zkoušíte mitigovat riziko supply-chain útoku ke všem uloženým cloudovým credentials skrze některý z budoucích updatů AdminDroida?
Odpovědět
Martin Haller
21. 11. 2023 v 10:21
Jj, práva GA to chce pro každého onboardovaného tenanta. Věnoval jsem se tomu cca 1/3 přednášky na Hacker Festu a zároveň řeším nějaké security věci se supportem AdminDroidu.
Řekněme, že příští rok by tomu měla stačit jen custom Ent. App. v každém tenantu. Práva nejspíše půjdou omezit jen na Read Only (to už jde neoficiálně teď, ale nechci zabíhat do detailů – narazil jsem na to omylem).
Chápu, že to riziko ohledně autopatchů tady je (resp. teď je tu ještě jedno výrazně větší, ale o to se podělím až to bude opravené) avšak když vezmu přínosy a hrozby, tak je to pro nás akceptovatelné.
Odpovědět