Microsoft 365 Risk Assessment

Užívání online služeb společnosti Microsoft přináší společnostem nové možnosti zajištění produktivity a přístup k firemnímu prostředí, potřebným informacím i systémům kdykoliv a odkudkoliv. Tento přístup ale vyžaduje zvýšené nároky na zabezpečení takto dostupné služby, neboť je z principu otevřena do veřejné sítě internet. Služby Microsoft 365 obsahují hned několik bezpečnostních prvků, které brání společnost, její data a identity uživatelů proti potencionálním útokům. Tyto prvky je ovšem nutné správně nastavit tak, aby byly v souladu s firemní bezpečnostní politikou, regulatorními požadavky a neohrozily provoz ani uživatele.

Figure 1: KPCS produkt

Naše společnost se již několik let snaží pomáhat zákazníkům získat informaci o stavu jejich online prostředí pomocí nezávislého auditu, který nabízí celkový přehled o konfiguraci prostředí a souvisejících technologiích z pohledu bezpečnosti či doporučeného nastavení. Díky desítkám provedených kontrol, praktickým zkušenostem z implementací, odborným znalostem online služeb i bezpečnostních standardů jsme schopni identifikovat možné nedostatky v konfiguraci prostředí, které mohou mít nyní či budoucnu negativní vliv na bezpečnost, dostupnost, odolnost proti výpadku, nebo zhoršení uživatelské zkušenosti.

V dnešním článku bych se chtěl zaměřit na dvě základní kontroly a funkce, které naše analýzy obsahují a které dokážou poměrně zásadně zvýšit bezpečnost Microsoft 365 služby. Bohužel jsou obě oblasti v řadě společností opomíjeny, a to i přesto, že se na ně snaží klást důraz jejich samotný provozovatel.

Figure 2: Hrozby v číslech

Basic autentizace

Basic autentizace je označení pro „jednoduchou“ autentizaci v podobě jména a hesla v oblasti přístupu. I přesto, že mohou být tyto informace přenášeny v zašifrované relaci, tak se v dnešní době nejedná o bezpečný způsob ověřování, které by mělo jakékoliv prostředí nabízet. Microsoft v tomto ohledu oznámil zrušení Basic autentizace na tento rok – konkrétně 13. října 2020 (ačkoliv s ohledem na světovou pandemii bylo zrušení odloženo do Q1 20201) a nabízí pro autentizaci bezpečnější způsob v podobě moderní autentizace založené na ADAL a OAuth 2.0. Basic autentizaci mohou využívat například neaktualizované verze balíku Office, ActiveSync klienti, PowerShell scripty i moduly a dále pak IMAP, POP, EWS, SMTP, webové i jiné aplikace.

Je Basic autentizace ve vašem online prostředí využívána?

Pokud ano, tak je nejvyšší čas se touto problematikou zabývat. Jestli si při odpovědi nejste jistí, tak o to více, protože v konečném důsledku mohou nastat problémy. Základním předpokladem pro vyřazení Basic autentizace je povolení a podpora moderní autentizace v organizaci. Moderní autentizace je již dnes ve výchozím stavu zapnuta a měla by být klientům k dispozici. Dále je i základem druhé oblasti tohoto článku, a to vícefaktorovému ověřování, které lze pro Basic autentizaci zajistit pouze prostřednictvím aplikačního hesla (App password). Váš tenant nabízí poměrně kvalitní logy pro Sing-in aktivity klientů, které jsou doporučeny pro detekci závislostí na této autentizaci.

Figure 3: Zapnutí moderní autentizace

Doporučenou cestou je opakovaná kontrola logů, detekce souvisejících klientů, změna typu jejich ověřování a následné vypnutí Basic autentizace. Vypnutí lze realizovat globálně skrz Conditional Access nebo Security Defaults, či per služby:

• Exchange Online,
• SharePoint Online,
• Microsoft Teams.

Exchange Online je v této oblasti nejpokročilejší, protože je také nejzneužívanější, takže disponuje autentizačními politikami umožňující blokaci per uživatel a služba POP, IMAP, SMTP atd. Poštovní službou je doporučeno začít jako první, pokud nelze zajistit bezpečné globální vypnutí Basic autentizace na celé organizace. Autentizační politiky lze testovat, přiřazovat uživatelům a později vybranou politiku nastavit jako výchozí pro všechny Exchange Online uživatelské objekty.

SharePoint Online nedisponuje granularitou Exchange Online služby, ale i tak nabízí nastavení, kterým lze Basic autentizaci ovládat, ať už prostřednictvím příkazové řádky (Set-SPOTenant LegacyAuthProtocolsEnabled $false) nebo v grafickém rozhraní.

Figure 4: Blokace Basic autentizace v SPO

Microsoft Teams přepínačem ani nedisponuje, ale v případě, že se dopracujete do nastavení organizace v podobě Teams Only režimu, tak máte automaticky problematiku Basic autentizace vyřešenou v kontextu IM a VoIP online služeb.

Figure 5: Nastavení Teams Only režimu

Nejelegantnějším způsobem v oblasti blokace Basic autentizace bývá Conditional Access a tedy podmíněný přístup, které lze uplatnit na jednotlivé uživatele, služby i lokace, takže nabízí opravdu velkou variabilitu v oblasti řízeného a postupného vyřazování zmíněného protokolu z online organizace.

Figure 6: Podmíněný přístup a zakázání Basic autentizace

Vícefaktorové ověřování

Vícefaktorové ověřování neboli MFA (multi-factor autentication) by mělo být součásti každého uživatelského i administrátorského účtu. Toto tvrzení není zcela úplné, protože v prostředí by měl existovat „break glass“ admin účtu, který je určen pro nouzové případy a z principu věci by neměl být chráněn druhým faktorem, protože v případě výpadku této podpůrné služby by mohla být správa online prostředí ohrožena. Samozřejmě tento účet musí být chráněn velice komplexním heslem, ideálně uchovaným v trezoru a jeho samotné požití by mělo disponovat celou řadu procesů, například vygenerování upozornění a následná změna hesla. Pokud vás tato oblast zajímala doporučuji článek „Manage emergency access accounts in Azure AD“ popisující související principy. Ve vašem prostředí mohou existovat i další účty, které druhý faktor nedokáží využívat, ale obecně by se mělo jednat o jednotky servisních účtů, například účet „On-Premises Directory Synchronization Service“ pro službu Azure AD Connect synchronizující lokálního AD s Azure AD. Servisní účty jsou často využívány i pro bezobslužné automatizace, kde je skoro nemožné zajistit ověření druhým faktorem, ale zase mohou existovat podmínky přístupu vylepšující bezpečnost při používání účtů tohoto typu. Například lze zvážit povolení autentizace jen z vybraných lokalit nebo pokud to je programově možné, změnit typ přístupu a využívat Secure App model v podobě zaregistrované aplikace o ověření například prostřednictvím certifikátu viz dlouho očekávaná funkce pro Exchange Online (Modern Auth and Unattended Scripts in Exchange Online PowerShell V2).

Figure 7: Síla vícefaktorového ověřování

Oblast více faktorové autentizace je poměrně bohatá na typy druhého faktoru pro ověření. Někdo tím může chápat i fakt, že se uživatel hlásí například z důvěryhodné sítě, ale spíše by se mělo jednat o druhý typ ověření vyžadující uživatelskou interakci. V oblasti Microsoft 365 je hned několik možností druhého faktoru, některé jsou v dnešní době méně preferované, například SMS, Voice Call nebo App Password, jiné zase více, ale obecně lze zvažovat následující:

• Microsoft Authenticator app,
• FIDO2 security keys (preview),
• OATH software tokens,
• OATH hardware tokens (preview),
• SMS,
• Voice call,
• App passwords.

Dle typu licencí ve vašem tenatu se otevírají možnosti vzhledem k vlastnostem a funkcím MFA služby, které je potřeba vyhodnocovat hned z několika hledisek.

Office 365 MFA:

• Bezplatná funkce uplatňující se per uživatel.
• Registrace druhého faktoru – 14 dní.
• Nelze uplatnit automatizované vynucení, zapamatování ani vyhodnocení rizikovosti přihlášení.
• Podpora pro všechny výše uvedené typy druhého faktoru.

Security Baseline / Security Defaults:

• Bezplatná funkce v Azure AD uplatňující se per organizace.
• MFA je pouze součástí výchozích bezpečnostních zásad.
• Okamžitá registrace druhého faktoru.
• Podpora pro všechny výše uvedené typy druhého faktoru kromě SMS, Voice Call a App Password.
• Podpora biometrie a Windows Hello for Business.

Azure MFA / Conditional Acesss.

• Placená funkce – Microsoft 365 E3 a E5, v subskripcích Enterprise Mobility + Security 3 a 5, v rámci Azure AD Premium P1 a P2 a nově i v Microsoft 365 Business Premium.
• Funkci lze uplatit per uživatel, skupina nebo organizace.
• Registrace druhého faktoru v případě splnění podmínek nebo pomocí URL.
• Podpora všech dostupných typů druhého faktoru s tím, že vyhodnocení rizikovosti přihlášení je součásti licence Azure AD Premium P2 a příslušných subskripcí.
• Možnost reportů a bezpečného nasazení.
• Možnost podmínek a výjimek pro MFA, MDM, IP, GEO lokace.

Figure 8: Principy podmíněného přístupu

KPCS nabízí analýzu pro vybrané on-premises i Online služby, při které je kontrolováno stovky parametrů. V oblasti Microsoft 365 se analýza zabývá mimo jiné i oblastí Basic autentizace a vícefaktorovému ověřování, pro které jsem se snažil v tomto článku uvést základní technické záležitosti. Obě oblasti a stejně tak mnoho dalších považuji za základní stavební jednotky bezpečného a řízeného provozu online služeb, který by měl ctít každý z nás.

Zjistit více o Risk Assessment