Identita a dál – pohled jednoho architekta

V tomto článku alex Shteynberg, hlavní technický architekt v Microsoftu, popisuje hlavní strategie návrhu pro podnikové organizace, které přijímají Microsoft 365 a další cloudové služby Microsoftu.

O autorovi

Jsem hlavní technický architekt v newyorské společnosti Microsoft Technology Center. Pracuji většinou s velkými zákazníky a složitými požadavky. Moje názory a názory jsou založené na těchto interakcích a nemusí se vztahovat na každou situaci. Ale podle mých zkušeností můžeme pomoci zákazníkům s nejsložitějšími výzvami, můžeme pomoci všem zákazníkům.

Obvykle pracuji s více než 100 zákazníky každý rok. I když má každá organizace jedinečné vlastnosti, je zajímavé sledovat trendy a společné rysy. Jedním z trendů je například zájem mnoha zákazníků napříč odvětvími. Koneckonců, bankovní pobočka může být také kavárna a komunitní centrum.

Ve své roli se soustředím na to, abych zákazníkům pomohla dosáhnout nejlepšího technického řešení, které by řešilo jejich jedinečnou sadu obchodních cílů. Oficiálně se zaměřuji na identity, zabezpečení, ochranu osobních údajů a dodržování předpisů. Líbí se mi, že se dotýká všeho, co děláme. Dává mi příležitost zapojit se do většiny projektů. Díky této aktivitě jsem zaneprázdněná a užívám si tuto roli.

Bydlím v New Yorku (nejlepší!) a opravdu si užívám rozmanitost jeho kultury, jídla a lidí (ne dopravní). Rád cestuji, když můžu, a doufám, že uvidím většinu světa v mém životě. Právě zkoumám výlet do Afriky, abych se dozvěděl o divočině.

Hlavní principy

• Jednoduché je často lepší: S technologií můžete dělat (téměř) cokoliv, ale neznamená to, že byste měli. Zejména v oblasti zabezpečení, mnoho zákazníků overengineer řešení. Líbí se mi toto video z konference Google Stripe, aby podtrhl tento bod.
• Lidé, proces, technologie: Navrhujte pro lidi, abyste zlepšili proces, ne technologie jako první. Neexistují žádná "dokonalá" řešení. Potřebujeme vyvážit různé rizikové faktory a rozhodnutí, která se můžou pro každou firmu lišit. Příliš mnoho zákazníků navrhuje přístup, kterému se jejich uživatelé později vyhýbají.
• Zaměřte se na "proč" nejprve a "jak" později: Buďte otravným 7-letým starým dítětem s milionem otázek. Nemůžeme přijít na správnou odpověď, pokud neznáme správné otázky, na které se máme zeptat. Spousta zákazníků předpokládá, jak musí věci fungovat místo definování obchodního problému. Vždy existuje několik cest, které je možné použít.
• Dlouhý konec minulých osvědčených postupů: Uvědomte si, že osvědčené postupy se mění rychlostí světla. Pokud jste se podívali na Microsoft Entra před více než třemi měsíci, pravděpodobně jste zastaralý. Všechno, co tady najdete, se může po publikování změnit. "Nejlepší" možnost dnes nemusí být stejných šest měsíců od této chvíle.

Základní koncepty

Tuto část nepřekočte. Často zjistím, že se musím vrátit k těmto článkům, a to i pro zákazníky, kteří používají cloudové služby už léta. Jazyk bohužel není přesný nástroj. Často používáme stejné slovo k tomu, aby znamenalo různé koncepty, nebo různá slova, která znamenají stejný koncept. Následující diagram často používám k vytvoření základní terminologie a "hierarchický model".

Když se naučíte plavat, je lepší začít v bazénu a ne uprostřed oceánu. Nesnažím se být technicky přesný s tímto diagramem. Jedná se o model, který popisuje některé základní koncepty.

V diagramu:

• Tenant = instance Microsoft Entra ID. Je na "vrcholu" hierarchie nebo na úrovni 1 v diagramu. Tuto úroveň můžeme považovat za "hranici", kde se děje všechno ostatní (Microsoft Entra B2B bokem). Všechny podnikové cloudové služby Microsoftu jsou součástí jednoho z těchto tenantů. Služby pro spotřebitele jsou oddělené. "Tenant" se v dokumentaci zobrazí jako tenant Microsoftu 365, tenant Azure, tenant WVD atd. Tyto varianty často způsobují pro zákazníky zmatek.
• Služby/předplatná, úroveň 2 v diagramu, patří do jednoho a jenom jednoho tenanta. Většina služeb SaaS je 1:1 a bez migrace se nedají přesunout. Azure je jiný. Fakturace nebo předplatné můžete přesunout do jiného tenanta. Existuje mnoho zákazníků, kteří potřebují přesunout předplatná Azure. Tento scénář má různé důsledky. Objekty, které existují mimo předplatné, se nepřesouvají. Například řízení přístupu na základě role (Azure RBAC), Microsoft Entra objekty (skupiny, aplikace, zásady atd.) a některé služby (Azure Key Vault, Datové cihly atd.). Nemigrujte služby bez dobrých obchodních potřeb. Některé skripty, které můžou být užitečné pro migraci, se sdílí na GitHubu.
• Daná služba má obvykle určitou hranici "sublevel" neboli úroveň 3 (L3). Tato hranice je užitečná pro oddělení zabezpečení, zásad, zásad správného řízení atd. Bohužel neexistuje žádné jednotné jméno, o kterých bych věděl. Příklady názvů pro L3 jsou: Předplatné Azure = prostředek; Dynamics 365 CE = instance; Power BI = pracovní prostor; Power Apps = prostředí; a tak dále.
• Úroveň 4 je místo, kde se nacházejí skutečná data. Tato rovina dat je složitý článek. Některé služby používají Microsoft Entra ID pro řízení přístupu na základě role, jiné ne. Probereme to, až se dostaneme k článkům o delegování.

Mezi další koncepty, u kterých je podle řady zákazníků (a zaměstnanců Microsoftu) zmatené nebo ohledně kterých mají dotazy, patří následující problémy:

• Každý může vytvořit mnoho tenantů zdarma. Nepotřebujete v ní zřizovat službu. Mám desítky. Název každého tenanta je v celosvětové cloudové službě Microsoftu jedinečný (jinými slovy, žádní dva tenanti nemůžou mít stejný název). Všechny jsou ve formátu TenantName.onmicrosoft.com. Existují také procesy, které vytvářejí tenanty automaticky (nespravované tenanty). K tomuto výsledku může dojít například v případě, že se uživatel zaregistruje k podnikové službě s e-mailovou doménou, která neexistuje v žádném jiném tenantovi.
• Ve spravovaném tenantovi je možné zaregistrovat mnoho domén DNS . Tento výsledek nezmění původní název tenanta. V současné době neexistuje snadný způsob, jak přejmenovat tenanta (kromě migrace). I když název tenanta není v dnešní době technicky kritický, někteří lidé se mohou cítit omezeni touto realitou.
• Název tenanta pro vaši organizaci byste si měli rezervovat i v případě, že zatím neplánujete nasazovat žádné služby. V opačném případě vám ho někdo může vzít a neexistuje jednoduchý proces, jak ho vzít zpět (stejný problém jako názvy DNS). Slyším to od zákazníků příliš často. Název vašeho tenanta by měl být také diskuzní článek.
• Pokud vlastníte obor názvů DNS, měli byste do svých tenantů přidat všechny tyto obory názvů. V opačném případě by bylo možné vytvořit nespravovaného tenanta s tímto názvem, což pak způsobí přerušení a jeho správu.
• Obor názvů DNS (například contoso.com) může patřit jenom jednomu tenantovi. Tento požadavek má vliv na různé scénáře (například sdílení e-mailové domény během fúze nebo akvizice atd.). Existuje způsob, jak zaregistrovat předplatné DNS (například div.contoso.com) v jiném tenantovi, ale tomu byste se měli vyhnout. Registrací názvu domény nejvyšší úrovně se předpokládá, že všechny subdomény patří do stejného tenanta. Ve scénářích s více tenanty (jak je vysvětleno dále) obvykle doporučujeme použít jiný název domény nejvyšší úrovně (například contoso.ch nebo ch-contoso.com).
• Kdo by měl "vlastnit" tenanta? Často vidím zákazníky, kteří nevědí, kdo aktuálně vlastní jejich tenanta. Tento nedostatek znalostí je významným červeným příznakem. Zavolejte na podporu Microsoftu co nejdříve. Stejně problematické je, když je vlastník služby (často správce Exchange) určen ke správě tenanta. Tenant obsahuje všechny služby, které byste v budoucnu mohli chtít. Vlastníkem tenanta by měla být skupina, která může rozhodovat o povolení všech cloudových služeb v organizaci. Dalším problémem je, když je skupina vlastníků tenanta požádána o správu všech služeb. Tato metoda neprovádí škálování pro velké organizace.
• Neexistuje koncept dílčího nebo super tenanta. Z nějakého důvodu se tento mýt stále opakuje. Tento koncept platí také pro tenanty Azure Active Directory B2C . Mockrát uslyším, že se jedná o prostředí B2C v tenantovi XYZ nebo "Návody přesunout tenanta Azure do tenanta Microsoftu 365?".
• Tento dokument se zaměřuje hlavně na komerční cloud po celém světě, protože ho používá většina zákazníků. Někdy je užitečné vědět o suverénních cloudech. Suverénní cloudy mají k diskuzi další důsledky, které jsou mimo rozsah této diskuze.

Články o základní identitě

Existuje mnoho dokumentace k platformě Microsoft Identity Platform – Microsoft Entra ID. Pro lidi, kteří teprve začínají, je to často ohromující. I když se o tom dozvíte, může být udržování neustálé inovace a změn náročné. V interakcích se zákazníky se často ocitám jako "překladatel" mezi obchodními cíli a přístupy "dobré, lepší, nejlepší", abych tyto obavy řešil (a lidské "poznámky" pro tyto články). Málokdy existuje dokonalá odpověď a "správným" rozhodnutím je vyvážení různých rizikových faktorů. V dalším kroku jsou některé běžné otázky a oblasti nejasností, které mám tendenci probírat se zákazníky.

Zajišťování

Microsoft Entra ID neřeší nedostatek zásad správného řízení ve světě identit! Zásady správného řízení identit by měly být kritickým prvkem nezávisle na jakýchkoli cloudových rozhodnutích. Požadavky na zásady správného řízení se v průběhu času mění, a proto se jedná o program, a ne o nástroj.

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) nebo něco jiného (třetí strana nebo vlastní)? Ušetřete si problémy teď i v budoucnu a používejte Microsoft Entra Connect. V tomto nástroji jsou všechny druhy inteligentních řešení, které řeší zvláštní konfigurace zákazníků a probíhající inovace.

Některé hraniční případy, které můžou vést ke složitější architektuře:

• Mám několik doménových struktur AD bez síťového připojení mezi nimi. Existuje nová možnost s názvem Zřizování cloudu.
• Nemám službu Active Directory ani ji nechci instalovat. Microsoft Entra Connect je možné nakonfigurovat tak, aby se synchronizoval s protokolem LDAP (může se vyžadovat partner).
• Potřebuji zřídit stejné objekty pro více tenantů. Tento scénář není technicky podporovaný, ale závisí na definici "stejné".

Mám přizpůsobit výchozí pravidla synchronizace (objekty filtru, změnit atributy, alternativní přihlašovací ID atd.)? Vyhněte se tomu! Platforma identit je stejně cenná jako služby, které ji používají. I když můžete provádět všechny druhy konfigurací, abyste na tuto otázku odpověděli, musíte se podívat na vliv na aplikace. Pokud filtrujete objekty s povolenou poštou, globální adresář pro online služby není úplný. Pokud aplikace spoléhá na konkrétní atributy, filtrování těchto atributů má nepředvídatelné účinky atd. Není to rozhodnutí týmu identity.

XYZ SaaS podporuje zřizování za běhu (JIT). Proč vyžadujete synchronizaci? Podívejte se na předchozí odstavec. Mnoho aplikací potřebuje informace o profilu pro funkce. Globální adresář nemůžete mít, pokud nejsou dostupné všechny objekty s povolenou poštou. Totéž platí pro zřizování uživatelů v aplikacích integrovaných s Microsoft Entra ID.

Ověřování

Synchronizace hodnot hash hesel (PHS) vs. předávací ověřování (PTA) vs. federace.

Obvykle probíhá vášnivá debata o federaci. Jednodušší je obvykle lepší a proto používejte PHS, pokud nemáte dobrý důvod, proč ne. Je také možné nakonfigurovat různé metody ověřování pro různé domény DNS ve stejném tenantovi.

Někteří zákazníci umožňují federaci + PHS hlavně pro:

• Možnost návratu (pro zotavení po havárii), pokud není dostupná služba FS (Federation Service).
• Další možnosti (například Microsoft Entra Doménové služby) a služby zabezpečení (například uniklé přihlašovací údaje)
• Podpora služeb v Azure, které nerozumí federovaným ověřováním (například Azure Files).

Zákazníky často procházím tokem ověřování klientů, abych objasnil některé mylné představy. Výsledek vypadá jako na následujícím obrázku, který není tak dobrý jako interaktivní proces, jak se tam dostat.

Tento typ výkresu tabule znázorňuje, kde se v toku žádosti o ověření použijí zásady zabezpečení. V tomto příkladu se zásady vynucované prostřednictvím služby AD FS (Active Directory Federation Service) použijí na první žádost o službu, ale ne na následné žádosti o službu. Toto chování je alespoň jedním z důvodů, proč co nejvíce přesunout bezpečnostní prvky do cloudu.

Snažíme se honit sen o jednotném přihlašování (SSO) tak dlouho, jak si pamatuji. Někteří zákazníci se domnívají, že můžou dosáhnout jednotného přihlašování výběrem správného zprostředkovatele federace (STS). Microsoft Entra ID může významně pomoct s povolením funkcí jednotného přihlašování, ale žádná služba STS není kouzelná. Existuje příliš mnoho "starších" metod ověřování, které se stále používají pro kritické aplikace. Řadu z těchto scénářů může vyřešit rozšíření Microsoft Entra ID o partnerská řešení. Jednotné přihlašování je strategie a cesta. Nedostanete se tam, aniž byste přešli na standardy pro aplikace. S tímto článkem souvisí cesta k ověřování bez hesla , které také nemá kouzelnou odpověď.

Vícefaktorové ověřování (MFA) je dnes nezbytné (další informace najdete tady ). Přidejte do něj analýzu chování uživatelů a máte řešení, které zabrání většině běžných kybernetických útoků. Dokonce i spotřebitelské služby se přesouvají tak, aby vyžadovaly vícefaktorové ověřování. Přesto se stále setkávám s mnoha zákazníky, kteří nechtějí přejít na moderní přístupy k ověřování . Největší argument, který slyším, je, že to ovlivňuje uživatele a starší aplikace. Někdy může zákazníkům pomoct dobrý krok – Exchange Online ohlášené změny. K dispozici je teď spousta Microsoft Entra sestav, které zákazníkům s tímto přechodem pomůžou.

Autorizace

Podle Wikipedie je "autorizovat" definovat zásady přístupu. Mnoho lidí to považuje za schopnost definovat řízení přístupu k objektu (soubor, služba atd.). V současném světě kybernetických hrozeb se tento koncept rychle vyvíjí na dynamickou zásadu, která dokáže reagovat na různé vektory hrozeb a rychle na ně upravit řízení přístupu. Pokud například přistupuji ke svému bankovnímu účtu z neobvyklého místa, zobrazí se mi další potvrzovací kroky. Abychom se této realitě mohli přiblížit, musíme vzít v úvahu nejen samotnou zásadu, ale také ekosystém metodologií detekce hrozeb a korelace signálů.

Modul zásad Microsoft Entra ID se implementuje pomocí zásad podmíněného přístupu. Tento systém závisí na informacích z jiných systémů detekce hrozeb, aby se dynamicky rozhodovalo. Jednoduché zobrazení by vypadalo podobně jako na následujícím obrázku:

Kombinace všech těchto signálů dohromady umožňuje dynamické zásady, jako jsou tyto:

• Pokud je na vašem zařízení zjištěna hrozba, omezí se váš přístup k datům pouze na web bez možnosti stahování.
• Pokud stahujete neobvykle velký objem dat, všechno, co stahujete, je šifrované a omezené.
• Pokud ke službě přistupujete z nespravovaného zařízení, budou vám zablokovaná vysoce citlivá data, ale přístup k nestriktním datům bez možnosti jejich kopírování do jiného umístění.

Pokud s touto rozšířenou definicí autorizace souhlasíte, budete muset implementovat další řešení. To, která řešení implementujete, závisí na tom, jak dynamická má být zásada a jaké hrozby chcete upřednostňovat. Mezi příklady takových systémů patří:

• Microsoft Entra ID Protection
• Microsoft Defender for Identity
• Microsoft Defender for Endpoint
• Microsoft Defender pro Office 365
• Microsoft Defender for Cloud Apps (Defender for Cloud Apps)
• Microsoft Defender XDR
• Microsoft Intune
• Microsoft Purview – ochrana informací
• Microsoft Sentinel

Kromě Microsoft Entra ID mají různé služby a aplikace vlastní specifické modely autorizace. Některé z těchto modelů jsou popsány dále v části delegování.

Auditu

Microsoft Entra ID nabízí možnosti podrobného auditu a vytváření sestav. Tyto sestavy ale obvykle nejsou jediným zdrojem informací potřebným k rozhodování o zabezpečení. Další informace k tomuto tématu najdete v části delegování.

Neexistuje žádná výměna

Nepropadejte panice! Exchange není zastaralý (nebo SharePoint atd.). Stále se jedná o základní službu. Chci tím říct, že poskytovatelé technologií už nějakou dobu přecházejí do uživatelského prostředí tak, aby zahrnovaly komponenty více služeb. Jednoduchým příkladem v Microsoftu 365 jsou moderní přílohy, ve kterých se přílohy k e-mailu ukládají na SharePoint Online nebo OneDrive.

Když se podíváte na klienta Outlook, uvidíte mnoho služeb, které jsou "připojené" jako součást tohoto prostředí, nejen Exchange. Mezi příklady patří Microsoft Entra ID, Microsoft Search, Aplikace, Profil, dodržování předpisů a skupiny Microsoft 365.

Přečtěte si o Microsoft Fluid Framework verze Preview chystaných funkcí. V náhledu teď můžu číst konverzace Teams a odpovídat na tyto konverzace přímo v Outlooku. Klient Teams je ve skutečnosti jedním z nejvýznamnějších příkladů této strategie.

Celkově je čím dál obtížnější vykreslit jasnou čáru mezi Microsoftem 365 a dalšími službami v cloudech Microsoftu. Vidím to jako velkou výhodu pro zákazníky, protože mohou těžit z celkových inovací ve všem, co děláme, i když používají jednu komponentu. Docela cool a má dalekosáhlé důsledky pro mnoho zákazníků.

Dnes vidím, že mnoho zákaznických IT skupin je strukturovaných kolem "produktů". Pro místní svět je to logické, protože potřebujete odborníka na každý konkrétní produkt. Jsem ale rád, že už nemusím ladit databázi Active Directory nebo Exchange, protože se tyto služby přesunuly do cloudu. Automatizace (kterou cloud v podstatě je) odebere určité opakující se ruční úlohy (podívejte se, co se stalo s továrnami). Tyto úlohy jsou však nahrazeny složitějšími požadavky pro pochopení interakce, účinku, obchodních potřeb a tak dále. Pokud jste ochotni se učit, cloudová transformace nabízí skvělé příležitosti. Než se pustím do technologií, často mluvím se zákazníky o řízení změn v IT dovednostech a týmových strukturách.

Všem fanouškům a vývojářům SharePointu se prosím přestaňte ptát " Jak můžu dělat XYZ v SharePointu Online?" Pokud používáte Power Automate (neboli Flow) pro pracovní postup, je to mnohem výkonnější platforma. K vytvoření lepšího uživatelského prostředí pro seznam položek s 500 K použijte Azure Bot Framework . Začněte místo CSOM používat Microsoft Graph . Microsoft Teams zahrnuje SharePoint, ale také další svět. Existuje mnoho dalších příkladů, které můžu uvést. Je tam obrovský a nádherný vesmír. Otevřete dveře a začněte prozkoumávat.

Dalším běžným účinkem je oblast dodržování předpisů. Zdá se, že tento přístup napříč službami zcela zaměňuje mnoho zásad dodržování předpisů. Pořád vidím organizace, které uvádějí, že potřebuji zapisovat veškerou e-mailovou komunikaci do systému eDiscovery. Co toto prohlášení skutečně znamená, když e-mail už není jenom e-mail, ale okno pro jiné služby? Microsoft 365 má komplexní přístup k dodržování předpisů, ale změna lidí a procesů je často mnohem obtížnější než technologie.

Existuje mnoho dalších lidí a dopadů na procesy. Podle mého názoru je tento faktor kritickou a nedostatečně diskutovanou oblastí. Možná více v jiném článku.

Možnosti struktury tenanta

Jeden tenant vs. více tenantů

Obecně platí, že většina zákazníků by měla mít jenom jednoho produkčního tenanta. Existuje mnoho důvodů, proč je více tenantů náročné (dejte ho hledat Bingem) nebo si přečtěte tento dokument white paper. Mnoho podnikových zákazníků, se kterými spolupracuji, má zároveň dalšího (malého) tenanta pro výuku, testování a experimentování v IT. Azure Lighthouse usnadňuje přístup k Azure mezi tenanty. Microsoft 365 a mnoho dalších služeb SaaS mají omezení pro scénáře napříč tenanty. V Microsoft Entra scénářích B2B je toho hodně, co je potřeba zvážit.

Mnoho zákazníků má po fúzi a akvizici (M&A) několik produkčních tenantů a chce je konsolidovat. Dnes to není jednoduché a vyžadovalo by to konzultační služby microsoftu (MCS) nebo partnera a software třetích stran. V budoucnu probíhá technická práce na řešení různých scénářů se zákazníky s více tenanty.

Někteří zákazníci se rozhodnou používat více než jednoho tenanta. To by mělo být pečlivé rozhodnutí a téměř vždy řídit obchodní důvody! Mezi příklady patří následující důvody:

• Podniková struktura typu holding, ve které není nutná snadná spolupráce mezi různými entitami a vyžaduje se silná administrativní a další izolace.
• Po akvizici se podniká obchodní rozhodnutí, aby se dvě entity oddělily.
• Simulace prostředí zákazníka, která nemění produkční prostředí zákazníka
• Vývoj softwaru pro zákazníky.

V těchto scénářích s více tenanty zákazníci často chtějí zachovat určitou konfiguraci napříč tenanty stejně nebo hlásit změny a odchylky konfigurace. To často znamená přechod od ručních změn k konfiguraci jako kódu. Podpora aplikace Microsoft Premiere nabízí workshop pro tyto typy požadavků na základě této veřejné IP adresy: https://Microsoft365dsc.com.

Multi-Geo

Do multi-Geo nebo ne do Multi-Geo. To je otázka. S Microsoft 365 Multi-Geo můžete zřizovat a ukládat neaktivní uložená data v geografických umístěních, která se rozhodnete pro splnění požadavků na rezidenci dat . Existuje mnoho mylných představ o této funkci. Mějte na paměti následující body:

• Neposkytuje výhody z hlediska výkonu. Pokud návrh sítě není správný, může se výkon zhoršit. Získejte zařízení "blízko" k síti Microsoftu, ne nutně k vašim datům.
• Nejedná se o řešení dodržování předpisů GDPR. GDPR se nezaměřuje na suverenitu dat ani umístění úložiště. Existují i další architektury dodržování předpisů pro suverenitu dat nebo umístění úložiště.
• Neřeší delegování správy (viz níže) ani informační bariéry.
• Není to totéž jako pro více tenantů a vyžaduje více pracovních postupů zřizování uživatelů .
• Nepřesune vašeho tenanta (Microsoft Entra ID) do jiné geografické oblasti.

Delegování správy

Ve většině velkých organizací je oddělení povinností a řízení přístupu na základě role (RBAC) nezbytnou realitou. Předem se omluvím. Tato aktivita není tak jednoduchá, jak si někteří zákazníci přejí. Požadavky zákazníka, právní požadavky, požadavky na dodržování předpisů a další požadavky se po celém světě liší a někdy jsou v konfliktu. Jednoduchost a flexibilita jsou často na opačných stranách. Nechápejte mě špatně, můžeme v tomto cíli udělat lepší práci. V průběhu času došlo (a bude) k významným vylepšením. Navštivte místní technologické centrum Microsoftu a vypracujte model, který vyhovuje vašim obchodním požadavkům, aniž byste si museli přečíst 379 230 dokumentů. Tady se soustředím na to, o čem byste měli přemýšlet, a ne na to, proč je to takhle. Připravujeme pět různých oblastí, které je potřeba naplánovat, a některé časté otázky, na které narážím.

Microsoft Entra ID a centra pro správu Microsoftu 365

Existuje dlouhý a rostoucí seznam předdefinovaných rolí. Každá role se skládá ze seznamu oprávnění role seskupených dohromady, aby bylo možné provádět konkrétní akce. Tato oprávnění se zobrazí na kartě Popis uvnitř každé role. Případně můžete zobrazit lidsky čitelnější verzi těchto oprávnění v centru Správa Microsoftu 365 Center. Definice předdefinovaných rolí se nedají upravit. Obecně platí, že tyto role seskupuji do tří kategorií:

• Globální správce: Tato "všemocná" role by měla být vysoce chráněná stejně jako v jiných systémech. Mezi typická doporučení patří: žádné trvalé přiřazení a použití Microsoft Entra Privileged Identity Management (PIM), silné ověřování atd. Zajímavé je, že tato role ve výchozím nastavení neposkytuje přístup ke všemu. Obvykle vidím nejasnosti ohledně přístupu podle předpisů a přístupu k Azure, které jsou popsány později. Tato role ale může vždy přiřadit přístup k dalším službám v tenantovi.
• Konkrétní správci služeb: Některé služby (Exchange, SharePoint, Power BI atd.) využívají role správy vysoké úrovně z Microsoft Entra ID. Toto chování není konzistentní ve všech službách a existuje více rolí specifických pro službu, které probereme později.
• Funkční: Existuje dlouhý (a stále rostoucí) seznam rolí zaměřených na konkrétní operace (pozvaný host atd.). Pravidelně se více těchto rolí přidává na základě potřeb zákazníka.

Není možné delegovat všechno (i když se mezera snižuje), což znamená, že někdy bude potřeba použít roli globálního správce. Místo členství uživatelů v této roli by se měla brát v úvahu konfigurace jako kódu a automatizace.

Poznámka: Centrum pro správu Microsoftu 365 má uživatelsky přívětivější rozhraní, ale v porovnání s prostředím pro správu Microsoft Entra má podmnožinu funkcí. Oba portály používají stejné Microsoft Entra role, takže ke změnám dochází na stejném místě. Tip: Pokud chcete uživatelské rozhraní správce zaměřené na správu identit bez nepotřebných informací v Azure, použijte https://aad.portal.azure.com.

Co je v názvu? Nevyjádřit z názvu role předpoklady. Jazyk není přesný nástroj. Cílem by mělo být definování operací, které je potřeba delegovat, než se podíváte na potřebné role. Když někoho přidáte do role Čtenář zabezpečení, neuvidí nastavení zabezpečení ve všem.

Možnost vytvářet vlastní role je běžnou otázkou. Tato funkce je v současné době v Microsoft Entra omezená (jak je vysvětleno dále), ale časem se bude rozšiřovat. Myslím, že tyto vlastní role jsou použitelné pro funkce v Microsoft Entra ID a nemusí překlenovat "dolů" hierarchii modelu (jak jsme probírali dříve). Vždy, když se zabývám "vlastním", mám tendenci se vracet k mému principu "jednoduchý je lepší".

Další běžnou otázkou je schopnost vymezit rozsah rolí na podmnožinu adresáře. Jedním z příkladů je něco jako "Správce helpdesku pouze pro uživatele v EU". Jednotky pro správu jsou určené k řešení tohoto scénáře. Jak jsme popsali dříve, myslím, že tyto obory jsou použitelné pro funkce v Microsoft Entra ID a nemusí být rozloženy "dolů". Určité role nedává smysl v rozsahu (globální správci, správci služeb atd.).

Všechny tyto role dnes vyžadují přímé členství (nebo dynamické přiřazení, pokud používáte Microsoft Entra PIM). To znamená, že zákazníci musí tyto role spravovat přímo v Microsoft Entra ID a tyto role nemohou být založené na členství ve skupině zabezpečení. Nejsem fanouškem vytváření skriptů pro správu těchto rolí, protože by se musely spouštět se zvýšenými právy. Obecně doporučuji integraci rozhraní API s procesními systémy, jako je ServiceNow, nebo používání partnerských nástrojů zásad správného řízení, jako je Saviynt. Na řešení tohoto problému v průběhu času probíhá technická práce.

Několikrát jsem zmínil Microsoft Entra PIM. K dispozici je odpovídající řešení Microsoft Identity Manager (MIM) Privileged Access Management (PAM) pro místní ovládací prvky. Můžete se také podívat na pracovní stanice s privilegovaným přístupem (s privilegovaným přístupem) a Microsoft Entra ID Governance. Existují také různé nástroje třetích stran, které umožňují zvýšit úroveň rolí za běhu, za běhu a dynamické zvýšení oprávnění. Tato funkce je obvykle součástí rozsáhlejší diskuze o zabezpečení prostředí.

Scénáře někdy volají po přidání externího uživatele do role (viz předchozí část s více tenanty). Tento výsledek funguje správně. Microsoft Entra B2B je další velký a zábavný článek, který zákazníky provede, třeba v jiném článku.

portály pro dodržování předpisů Microsoft Defender XDR a Microsoft 365 Purview

role Email & Spolupráce na portálu Microsoft Defender a skupiny rolí pro řešení Microsoft Purview na portálu dodržování předpisů Microsoft 365 Purview jsou kolekce skupin rolí, které jsou oddělené a odlišné od Microsoft Entra rolí. To může být matoucí, protože některé z těchto skupin rolí mají stejný název jako role Microsoft Entra (například Čtenář zabezpečení), ale můžou mít jiné členství. Dávám přednost Microsoft Entra rolím. Každá skupina rolí se skládá z jedné nebo několika "rolí" (co mám na mysli při opakovaném použití stejného slova?) a mají členy z Microsoft Entra ID, což jsou objekty s povoleným e-mailem. Můžete také vytvořit skupinu rolí se stejným názvem jako role, která může nebo nemusí tuto roli obsahovat (vyhněte se tomuto zmatení).

V nějakém smyslu jsou tato oprávnění vývojem modelu skupin rolí Exchange. Exchange Online ale má vlastní rozhraní pro správu skupin rolí. Některé skupiny rolí v Exchange Online jsou uzamčené a spravované z portálů pro dodržování předpisů Microsoft Entra ID nebo portálů pro dodržování předpisů Microsoft Defender XDR a Microsoft 365 Purview, ale jiné můžou mít stejné nebo podobné názvy a jsou spravované v Exchange Online (což k nejasnostem přidává). Pokud nepotřebujete obory pro správu Exchange, doporučujeme nepoužívat Exchange Online uživatelské rozhraní.

Nemůžete vytvářet vlastní role. Role jsou definovány službami vytvořenými Microsoftem a s uvedením nových služeb se stále zvětšují. Toto chování je v konceptu podobné rolím definovaným aplikacemi v Microsoft Entra ID. Když jsou povolené nové služby, je často potřeba vytvořit nové skupiny rolí, aby bylo možné k těmto službám udělit nebo k těmto službám delegovat přístup (například ke správě insiderských rizik).

Tyto skupiny rolí také vyžadují přímé členství a nemůžou obsahovat Microsoft Entra skupin. Tyto skupiny rolí bohužel v současné Microsoft Entra PIM nepodporují. Stejně jako Microsoft Entra rolím i já obvykle doporučuji správu těchto skupin rolí prostřednictvím rozhraní API nebo partnerského produktu zásad správného řízení, jako je Saviynt, nebo jiných.

role portálu Microsoft Defender a portálu dodržování předpisů Microsoft 365 Purview zahrnují Microsoft 365 a tyto skupiny rolí nemůžete vymezit na podmnožinu prostředí (jako to můžete u jednotek pro správu v Microsoft Entra ID). Mnoho zákazníků se ptá, jak mohou subdelegate. Například vytvořit zásadu ochrany před únikem informací jenom pro uživatele v EU. Pokud dnes máte práva ke konkrétní funkci na portálech dodržování předpisů pro Microsoft Defender XDR a Microsoft 365 Purview, máte v tenantovi práva ke všemu, co tato funkce pokrývá. Mnoho zásad ale může cílit na podmnožinu prostředí (například "zpřístupnit tyto popisky jenom těmto uživatelům"). Správné zásady správného řízení a komunikace jsou klíčovou součástí, aby nedocházelo ke konfliktům. Někteří zákazníci se rozhodnou implementovat přístup "konfigurace jako kód", který řeší poddelegaci na portálech dodržování předpisů Microsoft Defender XDR a Microsoft 365 Purview. Některé konkrétní služby podporují subdelegaci (viz další část).

Konkrétní služba

Jak jsme uvedli dříve, mnoho zákazníků se snaží dosáhnout podrobnějšího modelu delegování. Běžný příklad: "Spravovat službu XYZ pouze pro uživatele a umístění divize X" (nebo jinou dimenzi). Tato možnost závisí na jednotlivých službách a není konzistentní napříč službami a funkcemi. Každá služba navíc může mít samostatný a jedinečný model RBAC. Místo diskuze o všech těchto modelech (což by trvalo navždy), přidávám relevantní odkazy pro každou službu. Tento seznam není úplný, ale může vám pomoct začít.

• Exchange Online – (/exchange/permissions-exo/permissions-exo)
• SharePoint Online – (/sharepoint/manage-site-collection-administrators)
• Microsoft Teams – (/microsoftteams/itadmin-readiness)
• eDiscovery – (.. /compliance/index.yml)
  • Filtrování oprávnění – (.. /compliance/index.yml)
  • Hranice dodržování předpisů – (.. /compliance/set-up-compliance-boundaries.md)
  • eDiscovery (Premium) – (.. /compliance/overview-ediscovery-20.md)
• Viva Engage – (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
• Multi-geo – (.. /enterprise/add-a-sharepoint-geo-admin.md)
• Dynamics 365 – (/dynamics365/)

Poznámka

Tento odkaz je na kořen dokumentace. V modelu správy/delegování existuje několik typů služeb s různými variantami.

• Power Platform – (/power-platform/admin/admin-documentation)

  • Power Apps – (/power-platform/admin/wp-security)

    Poznámka

    V modelech správy/delegování existuje několik typů s různými variantami.

  • Power Automate – (/power-automate/environment-overview-admin)

  • Power BI – (/power-bi/service-admin-governance)

    Poznámka: Zabezpečení a delegování datové platformy (což je komponenta Power BI) je složitá oblast.

• Intune – (/mem/intune/fundamentals/řízení přístupu na základě role)

• Microsoft Defender for Endpoint – (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

• Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

• Microsoft Defender for Cloud Apps – (/cloud-app-security/manage-admins)

• Stream – (/stream/assign-administrator-user-role)

• Informační bariéry - (.. /compliance/information-barriers.md)

Protokoly aktivit

Microsoft 365 má jednotný protokol auditu. Jedná se o velmi podrobný protokol, ale do názvu moc nečtěte. Nemusí obsahovat vše, co chcete nebo potřebujete pro potřeby zabezpečení a dodržování předpisů. Někteří zákazníci mají také velký zájem o audit (Premium).

Mezi příklady protokolů Microsoftu 365, ke kterým se přistupuje prostřednictvím jiných rozhraní API, patří následující funkce:

• Microsoft Entra ID (aktivity nesouvisely s Microsoftem 365)
• Sledování zpráv Exchange
• Threat/UEBA Systems diskutované výše (například Microsoft Entra ID Protection, Microsoft Defender for Cloud Apps, Microsoft Defender for Endpoint atd.)
• Microsoft Purview – ochrana informací
• Microsoft Defender for Endpoint
• Microsoft Graph

Je důležité nejprve identifikovat všechny zdroje protokolů potřebné pro program zabezpečení a dodržování předpisů. Všimněte si také, že různé protokoly mají různé limity uchovávání informací online.

Z pohledu delegování správce nemá většina protokolů aktivit Microsoftu 365 integrovaný model RBAC. Pokud máte oprávnění k zobrazení protokolu, uvidíte v něm všechno. Běžným příkladem požadavku zákazníka je: "Chci mít možnost dotazovat aktivity jenom pro uživatele v EU" (nebo nějaký jiný rozměr). K dosažení tohoto požadavku potřebujeme přenést protokoly do jiné služby. V cloudu Microsoftu doporučujeme převést ho do služby Microsoft Sentinel nebo Log Analytics.

Diagram vysoké úrovně:

Diagram znázorňuje integrované možnosti odesílání protokolů do služby Event Hubs nebo Azure Storage nebo Azure Log Analytics. Tento systém ještě není součástí všech systémů. Existují ale i jiné přístupy k odeslání těchto protokolů do stejného úložiště. Podívejte se například na téma Ochrana teams pomocí služby Microsoft Sentinel.

Zkombinování všech protokolů do jednoho umístění úložiště přináší další výhody, jako jsou křížové korelace, vlastní doby uchovávání, rozšiřování o data potřebná k podpoře modelu RBAC atd. Jakmile jsou data v tomto systému úložiště, můžete vytvořit řídicí panel Power BI (nebo jiný typ vizualizace) s odpovídajícím modelem RBAC.

Protokoly nemusí být směrované jenom na jedno místo. Může být také užitečné integrovat protokoly Microsoftu 365 s Microsoft Defender for Cloud Apps nebo vlastním modelem RBAC v Power BI. Různá úložiště mají různé výhody a cílové skupiny.

Stojí za zmínku, že ve službě s názvem Microsoft Defender XDR je k dispozici bohatý integrovaný analytický systém pro zabezpečení, hrozby, ohrožení zabezpečení atd.

Mnoho velkých zákazníků chce tato data protokolu přenést do systému třetí strany (například SIEM). Pro tento výsledek existují různé přístupy, ale obecně jsou dobrými výchozími body Azure Event Hubs a Graph.

Azure

Často se mě ptají, jestli existuje způsob, jak oddělit role s vysokými oprávněními mezi Microsoft Entra ID, Azure a SaaS (např. globální správce pro Microsoft 365, ale ne Azure). Ani ne. Architektura s více tenanty je potřebná, pokud je vyžadováno úplné oddělení správy, ale zvyšuje se tím značná složitost (jak bylo popsáno výše). Všechny tyto služby jsou součástí stejné hranice zabezpečení/identity (jak je znázorněno v modelu hierarchie).

Je důležité porozumět vztahům mezi různými službami ve stejném tenantovi. Pracuji s mnoha zákazníky, kteří vytvářejí obchodní řešení, která zahrnují Azure, Microsoft 365 a Power Platform (a často také místní cloudové služby a cloudové služby třetích stran). Jeden z běžných příkladů:

1. Chci spolupracovat na sadě dokumentů, obrázků atd. (Microsoft 365)
2. Odešlete každou z nich prostřednictvím schvalovacího procesu (Power Platform)
3. Po schválení všech komponent sestavte tyto položky do sjednocených dodávek (Azure) Microsoftu Graph API je tady vaším nejlepším přítelem. Není to nemožné, ale výrazně složitější navrhnout řešení zahrnující více tenantů.

Azure Role-Based Access Control (RBAC) umožňuje jemně odstupňovanou správu přístupu pro Azure. Pomocí RBAC můžete spravovat přístup k prostředkům tím, že uživatelům udělíte nejmenší oprávnění potřebná k provádění jejich úloh. Podrobnosti jsou mimo rozsah tohoto dokumentu, ale další informace o řízení přístupu na základě role najdete v tématu Co je řízení přístupu na základě role (RBAC) v Azure? Řízení přístupu na základě role (RBAC) je důležité, ale jen část aspektů zásad správného řízení pro Azure. Cloud Adoption Framework je skvělým výchozím bodem pro další informace. Líbí se mi, jak můj přítel Andres Ravinet provede zákazníky krok za krokem různými komponentami, aby se rozhodli o přístupu. Základní pohled na různé prvky (není tak dobrý jako proces, jak se dostat k modelu skutečného zákazníka) je podobný následujícímu:

Jak vidíte na obrázku výše, v rámci návrhu byste měli vzít v úvahu mnoho dalších služeb (např. Zásady Azure, Azure Blueprints, Skupiny pro správu atd.).

Závěr

Tento článek začal jako krátký souhrn, skončil déle, než jsem čekal. Doufám, že jste teď připraveni se ponořit do hloubky vytváření modelu delegování pro vaši organizaci. Tato konverzace je velmi běžná se zákazníky. Neexistuje žádný model, který by fungoval pro každého. Čekáme na několik plánovaných vylepšení od technického týmu Microsoftu, než zdokumentujeme běžné vzory, které vidíme u zákazníků. Mezitím můžete ve spolupráci s týmem účtu Microsoft zajistit návštěvu nejbližšího technologického centra Microsoftu. Uvidíme se!