Tento článek popisuje architekturu podmíněného přístupu, která dodržuje zásady nulová důvěra (Zero Trust). Architektura používá přístup založený na osobách k vytvoření strukturované architektury podmíněného přístupu.
Architektura nulová důvěra (Zero Trust) podmíněného přístupu
Nejdřív je potřeba zvolit architekturu. Doporučujeme zvážit architekturu cíleného nebo nulová důvěra (Zero Trust) podmíněného přístupu. Tento diagram znázorňuje odpovídající nastavení:
Architektura podmíněného přístupu nulová důvěra (Zero Trust) je ta, která nejlépe odpovídá principům nulová důvěra (Zero Trust). Pokud v zásadách podmíněného přístupu vyberete možnost Všechny cloudové aplikace , budou všechny koncové body chráněné poskytnutými ovládacími prvky udělení, jako je známý uživatel a známé nebo vyhovující zařízení. Zásady se ale nevztahují jenom na koncové body a aplikace, které podporují podmíněný přístup. Platí pro každý koncový bod, se kterým uživatel pracuje.
Příkladem je koncový bod toku přihlášení zařízení, který se používá v různých nových nástrojích PowerShellu a Microsoft Graphu. Tok přihlášení zařízení poskytuje způsob, jak povolit přihlášení ze zařízení, na kterém není možné zobrazit přihlašovací obrazovku, jako je zařízení IoT.
Na daném zařízení se spustí přihlašovací příkaz založený na zařízení a uživateli se zobrazí kód. Tento kód se používá na jiném zařízení. Uživatel přejde na https://aka.ms/devicelogin své uživatelské jméno a heslo a určí ho. Po přihlášení z jiného zařízení se přihlášení na zařízení IoT v kontextu uživatele úspěšně přihlásí.
Výzvou při tomto přihlášení je, že nepodporuje podmíněný přístup založený na zařízeních. To znamená, že nikdo nemůže používat nástroje a příkazy, pokud použijete základní zásady, které vyžadují známého uživatele a známé zařízení pro všechny cloudové aplikace. Existují i jiné aplikace, které mají stejný problém s podmíněným přístupem založeným na zařízení.
Druhá architektura, cílová architektura, je založená na principu, že cílíte jenom na jednotlivé aplikace, které chcete chránit v zásadách podmíněného přístupu. V tomto případě není přihlášení zařízení pro koncové body dříve pokryté všemi cloudovými aplikacemi, jako jsou volání grafu na ID Microsoft Entra, chráněno zásadami podmíněného přístupu, takže budou dál fungovat.
Při použití přihlášení k zařízení jako příkladu k rozlišení dvou architektur můžete provést ověření pomocí přihlášení zařízení. Přihlášení zařízení může být možné povolit pro jednu nebo několik jednotlivých aplikací, protože každá aplikace je cílitelná, a proto je možné ji vyloučit v zásadách podmíněného přístupu, které vyžadují přihlášení na základě zařízení.
Problémem s cílenou architekturou je, že možná zapomenete chránit všechny cloudové aplikace. I tak byste v zásadách podmíněného přístupu zvolili všechny vybrané aplikace. Přístup k aplikacím, které nelze vybrat bez ochrany, ponecháte. Mezi příklady patří přístup k portálu Office, portálu Azure EA (smlouva Enterprise) a portálu informací o zabezpečení, což jsou všechny velmi citlivé portály.
Dalším aspektem je, že počet aplikací Office 365 a Microsoft Entra se v průběhu času zvyšuje, protože Microsoft a partneři vydávají nové funkce a jako vaši správci IT integrují různé aplikace s Id Microsoft Entra. Přístup ke všem těmto aplikacím je chráněn pouze v případě, že máte mechanismus, který zjistí jakoukoli novou aplikaci, která podporuje podmíněný přístup a která na ni automaticky aplikuje zásadu. Vytvoření a údržba takového skriptu může být obtížné.
Maximální podporovaný počet aplikací pro libovolnou zásadu podmíněného přístupu je také přibližně 250. Před překročením datové části můžete přidat až 600 aplikací, ale toto číslo se nepodporuje.
Osoby podmíněného přístupu
Existuje mnoho způsobů, jak strukturovat zásady podmíněného přístupu. Jedním z přístupů je strukturování zásad na základě citlivosti přístupu k prostředku. V praxi může být tento přístup obtížné implementovat způsobem, který stále chrání přístup k prostředkům pro různé uživatele.
Můžete například definovat zásady podmíněného přístupu, které vyžadují známého uživatele a známé zařízení pro přístup k citlivému prostředku, ke kterému musí přistupovat hosté i zaměstnanci. Když se hosté pokusí o přístup ze spravovaného zařízení, žádost o přístup nebude fungovat. Zásady podmíněného přístupu byste museli upravit tak, aby splňovaly obě požadavky, což by obvykle vedlo k zásadám, které splňují méně bezpečný požadavek.
Dalším přístupem je pokus o definování zásad přístupu na základě toho, kde je uživatel v organizaci. Tento přístup může vést k mnoha zásadám podmíněného přístupu a může být nespravovatelný.
Lepším přístupem je strukturovat zásady související s běžnými potřebami přístupu a seskupit sadu potřeb přístupu v osobě pro skupinu uživatelů, kteří mají stejné potřeby. Personas jsou typy identit, které sdílejí společné podnikové atributy, odpovědnosti, prostředí, cíle a přístup.
Pochopení přístupu k podnikovým prostředkům a prostředkům různými osobami je nedílnou součástí vývoje komplexní strategie nulová důvěra (Zero Trust).
Tady jsou některé navrhované osoby podmíněného přístupu od Microsoftu:
Microsoft také doporučuje definovat samostatnou osobu pro identity, které nejsou součástí žádné jiné skupiny osob. Tomu se říká globální osoba. Globální je určen k vynucení zásad pro identity, které nejsou ve skupině osob a zásadách, které by se měly vynucovat pro všechny osoby.
Následující části popisují některé doporučené osoby.
Globální
Globální je persona/zástupný symbol pro zásady, které jsou obecně v přírodě. Slouží k definování zásad, které se vztahují na všechny osoby nebo které se nevztahují na jednu konkrétní osobu. Použijte ho pro zásady, na které se nevztahují jiné osoby. Tuto osobu potřebujete k ochraně všech relevantních scénářů.
Předpokládejme například, že chcete použít jednu zásadu k blokování starší verze ověřování pro všechny uživatele. Můžete ji nastavit jako globální zásadu místo použití skupiny starších zásad, které se můžou lišit pro různé osoby.
Další příklad: Chcete blokovat daný účet nebo uživatele z konkrétních aplikací a uživatel nebo účet není součástí žádné osoby. Pokud například vytvoříte cloudovou identitu v tenantovi Microsoft Entra, tato identita není součástí žádné jiné osoby, protože nemá přiřazené žádné role Microsoft Entra. Stále můžete chtít zablokovat přístup identity ke službám Office 365.
Možná budete chtít blokovat veškerý přístup k identitám, které nejsou pokryté žádnou skupinou osob. Nebo můžete chtít vynutit vícefaktorové ověřování.
Správa
V tomto kontextu je správce jakákoli identita bez hosta, cloud nebo synchronizace, která má jakékoli ID Microsoft Entra nebo jinou roli správce Microsoftu 365 (například v Programu Microsoft Defender for Cloud Apps, Exchange, Defender for Endpoint nebo Správce dodržování předpisů). Hosté, kteří mají tyto role, jsou pokryti jinou osobou, a proto jsou z této osoby vyloučeni hosté.
Některé společnosti mají samostatné účty pro citlivé role správce, na kterých je tato osoba založena. Správci tyto citlivé účty používají optimálně z pracovní stanice s privilegovaným přístupem (PAW). Často ale vidíme, že účty správců se používají na standardních pracovních stanicích, kde uživatel právě přepíná mezi účty na jednom zařízení.
Místo použití samostatných účtů můžete chtít rozlišovat na základě citlivosti rolí správců cloudu a přiřazovat méně citlivé role Azure interní osobě. Místo toho můžete použít zvýšení podle potřeby (JIT). V tomto případě je uživatel cílem dvou sad zásad podmíněného přístupu, jedné pro každou osobu. Pokud používáte pracovní stanice s privilegovaným přístupem, můžete také chtít zavést zásady, které používají filtry zařízení v podmíněném přístupu k omezení přístupu, aby správci měli povolené jenom pracovní stanice s privilegovaným přístupem.
Vývojáři
Osoba vývojářů obsahuje uživatele, kteří mají jedinečné potřeby. Jsou založené na účtech Active Directory, které se synchronizují s ID Microsoft Entra, ale potřebují zvláštní přístup ke službám, jako jsou Azure DevOps, kanály CI/CD, tok kódu zařízení a GitHub. Osoba vývojářů může zahrnovat uživatele, kteří jsou považováni za interní a ostatní považují za externí, ale osoba by měla být pouze v jedné z těchto osob.
Vnitřní fungování
Interní informace obsahují všechny uživatele, kteří mají účet Active Directory synchronizovaný s ID Microsoft Entra, kteří jsou zaměstnanci společnosti a kteří pracují ve standardní roli koncového uživatele. Doporučujeme přidat interní uživatele, kteří jsou vývojáři do osoby vývojářů.
Externí
Tato osoba obsahuje všechny externí konzultanty, kteří mají účet Active Directory synchronizovaný s ID Microsoft Entra. Doporučujeme přidat externí uživatele, kteří jsou vývojáři do osoby vývojářů.
Hosté
Hosté mají všechny uživatele, kteří mají účet hosta Microsoft Entra, který byl pozván do tenanta zákazníka.
Host Správa s
Host Správa s persona obsahuje všechny uživatele, kteří mají účet hosta Microsoft Entra, který má přiřazenou některou z dříve uvedených rolí správce.
Microsoft365ServiceAccounts
Tato osoba obsahuje uživatelské účty služeb založené na cloudu (Microsoft Entra ID), které se používají pro přístup ke službám Microsoftu 365, pokud žádné jiné řešení nevyhovuje potřebám, jako je použití identity spravované služby.
AzureServiceAccounts
Tato osoba obsahuje uživatelské účty služeb založené na cloudu (Microsoft Entra ID), které se používají pro přístup ke službám Azure (IaaS/PaaS), pokud žádné jiné řešení nevyhovuje potřebě, například použití identity spravované služby.
CorpServiceAccounts
Tato osoba obsahuje uživatelské účty služeb, které mají všechny tyto vlastnosti:
- Pochází z místní Active Directory.
- Používají se z místního prostředí nebo z virtuálního počítače založeného na IaaS v jiném (cloudovém) datacentru, jako je Azure.
- Synchronizují se s instancí Microsoft Entra, která přistupuje k jakékoli službě Azure nebo Microsoft 365.
Tento scénář by se měl vyhnout.
ÚlohyIdentity
Tato osoba obsahuje identity počítačů, jako jsou instanční objekty Microsoft Entra a spravované identity. Podmíněný přístup teď podporuje ochranu přístupu k prostředkům z těchto účtů s určitými omezeními, pokud jde o podmínky a udělení ovládacích prvků.
Karty šablon aplikace Access
K definování charakteristik jednotlivých osob doporučujeme použít přístupové karty šablon. Tady je příklad:
Karta šablony pro každou osobu poskytuje vstup pro vytvoření konkrétních zásad podmíněného přístupu pro každou osobu.
Pokyny k podmíněnému přístupu
Projděte si architekturu podmíněného přístupu, která zahrnuje strukturovaný přístup pro zásady seskupování na základě vytvořených osob.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- Claus Jespersen | ID hlavního konzultanta
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
- Učení cesta: Implementace a správa identit a přístupu
- Co je podmíněný přístup?
- Běžné zásady podmíněného přístupu