Přecházíme do Azure Active Directory

Mám pocit, jako by čas neustále zrychloval. Můj TO-DO list je delší a delší. Já pracuji, jak mi situace dovolí. Přesto to však není dost, abych úkoly a nápady (jako například i přechod do Azure Active Directory) realizoval rychleji, než přibývají.

Článek jsem začal psát před svou dovolenou a chtěl jsem ho vydat se svým odletem. Nakonec ho dokončuji na pokoji, ve čtyři hodiny ráno, protože šestihodinový „jet lag“ mi nedá spát… Člověk míní, život mění. To je přísloví, které mám v hlavě poslední dobou nejčastěji… Snad se vám bude líbit.

Přechod do Azure Active Directory

Aktuálně máme posledního zákazníka, který má svůj vlastní on-premise MS Exchange. A i ten má svého vlastního M365 tenanta. Všichni ostatní jsou zmigrovaní do M365, kde používají Azure AD, Exchange, Sharepoint, OneDrive a Teams. V tomhle směru se IT prostředí velice změnilo.

Pamatuji si, jak jsem ještě v roce 2018 na ESET partnerském setkání nevěřil vizi jednoho z ESET partnerů ohledně M365 (tehdy ještě Office 365). Tehdy jsem si nedokázal představit, že by firmy chtěly platit stokorun měsíčně za uživatele jen za e-mailové služby. Teď, o necelých pět let později, je to standard. Dokonce, oproti mým očekáváním, některé firmy platí i násobně více (vyšší stovky korun) za další služby, každý měsíc, za každého uživatele.

V PATRON-IT také používáme M365. Jen jsme ho zatím měli od on-premise infrastruktury oddělený (nepoužíváme AD FS ani Azure AD Connect). Před mnoha roky jsem se tak rozhodl z bezpečnostních důvodů. O AAD (Azure Active Directory) jsme neměli tolik znalostí a chtěl jsem udržet menší „attack surface“.

Teď však děláme větší investici do obměny HW (stanice i servery – viz další kapitola) a s tím přichází i možnost udělat „velký třesk„. Cítím, že AAD již začíná být dospělá (je tam dostatek funkcionalit a chyby jsou opraveny) a tak zkusíme přejít z on-prem AD přímo na „AAD only“ (přeskočíme hybrid režim AD+AAD).

Co si od změny slibujeme

Věřím, že do budoucna bude přibývat více firem, které již on-prem AD mít nebudou. Půjde hlavně o nově vzniklé firmy, co mohou začít na zelené louce. Dvě takové už teď spravujeme.

Když si tím procesem projdeme sami, budeme pak na tuto situaci lépe připraveni (znalosti, zkušenosti, osvědčené postupy). Zároveň věřím, že budeme schopni s novými možnostmi, které M365 přináší, dosáhnout vyššího zabezpečení.

Co mám v plánu využít

Jako MS partneři máme přístup k M365 E5 licencím – můžeme tedy experimentovat snad se vším, co Microsoft nabízí. Základem tedy bude Azure AD, Conditional Access, Intune a Defender pro všechno.

Azure Active Directory

Postupně bych chtěl napojit ověřování dalších služeb a SW na Azure AD. Díky tomu budu moci řídit požadavky na přihlášení skrze Conditional Access: Vyžadovat pro přihlášení firemní zařízení, sílu ověření, či vyhovující („compliant“) zařízení. Zároveň budou veškerá přihlášení logována do jednoho místa a vyhodnocována (Identity protection).

FIDO2

Pro přihlašování bych chtěl používat FIDO2 klíče s biometrickým ověřováním. Jedná se v podstatě o jednu z nejsilnějších metod ověření, která je pohodlná a imunní (zatím) vůči phishingu. Oproti mobilnímu authenticatoru se nedá HW klíč vzdáleně hacknout.

Věřím, že do budoucna by to mohla být metoda, kterou bychom mohli nasazovat u zákazníků:

• HW klíče nejsou drahé (+- 1300 Kč),
• jedná se o jednorázový výdaj,
• vyřeší se tím problém s instalací authenticatoru na soukromé mobily (což někdy uživatelé nechtějí, nemají smartphone, nebo už není podporovaný),
• jsou jednoduché na používání,
• jsou imunní vůči phishingu.

Defender for *

V jednom ze svých předchozích článků (Proč chci nasadit EDR ke všem zákazníkům) popisuji hledání EDR ideálního pro naše použití. Už několikrát jsem myslel, že mám nalezeno – nakonec se ale našlo něco, co nám na produktu nevyhovovalo.

Nyní to zkusíme s MS Defenderem. Nějaké zkušenosti s ním již v rámci řešení incidentů máme. Zákazníka, který jej má jako primární antivirus, také. Monitorovací skripty pro náš monitorovací systém jsou hotové a tak věřím, že to vyjde (další výhody, co vidím v Defenderu, jsem popisoval ve výše zmíněném článku).

Otazníky, které mi zůstávají v hlavě

Některé technické detaily (a rozhodnutí) jsou jasné. U některých však stále váhám.

PIM, anebo více účtů

O365 účet budeme používat pro přihlášení do PC, VPN i RDP. Dále budeme O365 účty používat k privilegovanějším operacím, jako je přístup ke správě zákaznickým tenantů (skrze delegovanou správu GDAP) a ke správě hesel (Devolutions server s RDM).

Přemýšlím proto, zdali to udělat tak, že každý bude mít svůj účet a bude využívat PIM. Druhou variantou je každému založit dva účty. Jeden účet pro běžnou práci a ten druhý pro privilegovanou práci.

Zatím se kloním k té druhé možnosti. Bojím se, že když se kolegové budou přihlašovat na domácím PC do VPN (ověří se skrze FIDO2), tak se na těch počítačích budou objevovat Referesh/Access tokeny daného uživatele s MFA claimem – což mi nepřijde úplně vhodné… Nicméně stále zde mám spoustu otazníků a musím toho ještě dost nastudovat. Případně zkonzultovat s někým, kdo má v tomhle směru hlubší znalosti.

Windows Hello for Business

Tuhle technologii beru jako bezva zlepšovák, jak se bezpečně a jednoduše (PIN, biometrika) přihlašovat do PC. Nevýhodou je, že si uživatel musí při prvním přihlášení na každém PC to WHfB konfigurovat.

FIDO2 nabízí stejně pohodlné přihlášení a to přitom na všech AAD Joined PC bez potřeby jakéhokoliv nastavování. V podstatě jen zapojím USB klíč a dotknu se ho (tím dojde k ověření otisku prstu a přihlášení – ani nemusím zadávat uživatelský účet).

Nevím tedy, jestli WHfB nezablokovat a nepoužívat jen FIDO2. Zde opět potřebuji nastudovat trochu více o „vnitřním“ fungování těch věcí a bezpečnostním dopadu (zdali to zvýší/sníží zabezpečení).

Například čekám (jen přemýšlím nahlas), že při přihlašování skrze FIDO2 bez WHfB v PC nevznikne PRT token – to by mohlo znamenat o trochu menší „attack surface“.

FIDO2 výrobce klíčů

V současné době pro FIDO2 používáme „Kensingnton VeriMark™ Guard“ klíč. Funguje spolehlivě (otisky prstů aj.), je malý a odolný. Možná jen ta cena není nejnižší.

Na hraní v labu jsem si koupil ještě YubiKey Bio. Také je spolehlivý (ačkoliv se mi občas stane, že nerozpozná můj otisk prstu [„false negative“] – otázkou pak ale zůstává, jestli naopak ten Kensington netrpí na „false positive“ detekce), měl by být i voděodolný. Jen ten rozměr není tak praktický. Cílem pro mě je, aby se ten FIDO2 klíč mohl přidělat na kroužek ke klíčům od kanceláře a všichni si jej tak nosili sebou.

Nicméně, hlavně si musím promyslet, jakou váhu dám zemi původu klíče (případně úrovni jeho certifikace). Přeci jen, ten klíč budeme používat i pro nejdůležitější práci (přístup ke všem heslům a zákaznickým tenantům).

Když část západního světa řeší čínské výrobky v 5G sítích, neměli bychom i my v rámci opatrnosti zvolit výrobek z „alianční“ země? K téhle otázce mě přivedl článek od Erica Woodruffa „Choosing A FIDO2 Security Key„.

Local admins / lateral movement

Od přechodu do Azure Active Directory jsem si sliboval zbavení se NTLM a Kerberos ověřování mezi doménovými PC (AAD Joined) a ztížení lateral movementu.

Nakonec to zase tak jednoduché nebude. Zůstává jak Kerberos tak i jednoduchý lateral movement v případě kompromitace PC s přihlášeným privilegovaným uživatelem.

Mám na mysli následující. Pokud útočníci kompromitují nějakou stanici/server, kde bude přihlášený uživatel, který je administrátorem i na dalších stanicích/serverech, útočníci jej mohou okamžitě ovládnout. Spustí například psexec pod daným uživatelem. Stačí jim k tomu jen možnost pouštět vlastní kód pod existující uživatelskou session (v takovém případě se „Conditional Access“ ani MFA neuplatňuje). Něco málo, jak to funguje v běžné AD, jsem psal v článku „Naše postřehy z auditů bezpečnosti ve firmách“ v odstavci „Správa stanic a serverů doménovým administrátorem“.

Musím tedy vymyslet, jak udělat/nastavit admin účet pro správu stanic, aniž bychom přihlášením toho admin účtu na stanici ohrozili zbytek sítě.

Závěr

Přechod do Azure Active Directory je daná věc. Zbývá mi „jen“ vymyslet detaily. Během dovolené budu studovat, po návratu realizovat, pak pár měsíců ladit. Nakonec by z toho mohla být i pěkná přednáška ohledně nasazení/zabezpečení v AAD prostředí (z jiného úhlu pohledu, než co jsem zatím viděl).

Pokud se zadaří, zkusil bych se s ní přihlásit na každoroční konference Cyb3r Days 2023, kterou pořádají přátelé (Dan s Honzou) ze Cyber Rangers.

Níže také sdílím odkazy na zajímavé blogy/články, na které jsem narazil. Třeba přijdou zajímavé i vám:

• https://www.samuraj-cz.com/serie/azure-microsoft-365-office-365-cloud/ – jeden z nejznámějších česky psaných blogů o problematice správy sítí. Pan Bouška popisuje své zkušenosti z reálných nasazení a dodává postřehy/zkušenosti, které se v dokumentaci produktů nenajdou.
• https://aadinternals.com/ – blog věnující se bezpečnosti AAD. Nové metody útoku, obrany a popis toho, jak věci fungují na nižší úrovni.
• https://syfuhs.net/how-azure-ad-windows-sign-in-works
• https://syfuhs.net/how-azure-ad-kerberos-works
• https://call4cloud.nl/2021/08/the-battle-between-aadj-and-aadr/
• https://call4cloud.nl/2021/08/the-death-of-compliance/

A jako vždy, pokud vás napadají další postřehy, otázky, či jsem něco napsal nepřesně, budu rád, když necháte komentář.

Nechť jsou vaše sítě bezpečné.

Martin