Konfigurace nulové důvěryhodnosti pro víceklientské organizace
Tento článek ukazuje víceklientské organizace, jak použít konfigurace v Microsoft Entra ID a splnit běžné požadavky na ochranu nulové důvěryhodnosti. Při vytváření správné architektury víceklientské identity a implementaci nulové důvěryhodnosti ve vašem prostředí postupujte podle těchto doporučení.
Obrázek 1: Ukázková architektura víceklientské obrany s konfigurací nulové důvěryhodnosti
Určení architektury identit
Tenanti Microsoft Entra jsou základem vaší architektury identit. Tenant je hranice identity v MICROSOFT Entra ID. Organizace s jedním tenantem Microsoft Entra má jednu architekturu tenanta. Organizace používající více tenantů Microsoft Entra mají víceklientských architektur.
Výhody jednoho tenanta Jedna tenanta je jednodušší spravovat a snižovat náklady prostřednictvím provozní efektivity. Umožňuje snadněji nakonfigurovat prostředí nulové důvěryhodnosti. Jeden tenant se vyhne fragmentování uživatelského prostředí s více přihlašovacími údaji. Pomáhá také zabránit vyloděným řešením, která potřebujete později integrovat. Měli byste se snažit mít data, Microsoft 365 a cloudové služby Azure v jednom tenantovi. Pokud už máte více tenantů Microsoft Entra, měli byste zvážit konsolidaci prostředí, abyste mohli použít jednoho tenanta. Tenanty můžete konsolidovat převodem předplatných Azure ze sekundárních tenantů do primárního tenanta. Další informace najdete v tématu Přenos předplatného Azure do jiného adresáře Microsoft Entra.
Případy použití s více tenanty Existuje důvod, proč organizace obrany používá víceklientovou architekturu. Velké a složité organizace obrany můžou potřebovat více tenantů Microsoft Entra pro zabezpečení, dodržování předpisů a spolupráci (viz tabulka 1).
Tabulka 1. Důvody, proč mít nebo vytvořit více tenantů
| Důvod | Příklad |
|---|---|
| Ochrana osobních údajů nebo zabezpečení vyžaduje hlubší oddělení dat. | Úřad generálního inspektora musí mít nezávislost. |
| Delegování a segmentace správy | Jedna organizace nemá možnost spravovat jinou organizaci. |
| Suverenita dat a/nebo vlastnictví | Jedna organizace nemá právní autoritu ke správě dat jiné organizace. |
| Síť a ORGANIZACE IT | Není možné ani příznivě sbalit několik velkých podnikových it architektur do jedné podnikové architektury. |
| Monitorování SOC a reakce na incidenty | SoC potřebuje samostatného tenanta ke správě rolí a zodpovědností. |
Pokud potřebujete více tenantů Microsoft Entra, měli byste použít Microsoft Entra Externí ID (B2B) a Azure Lighthouse. Tyto funkce pomáhají podporovat víceklientských prostředí ochrany. Další informace najdete v tématu Modely tenantů pro víceklientské řešení.
Identifikace typů tenantů
Organizace pro víceklientské obrany můžou kategorizovat instance Microsoft Entra, které používají jako primární nebo sekundární. Každá organizace by měla identifikovat a určit jednoho tenanta jako primárního tenanta. Všichni ostatní tenanti jsou sekundární. Obrázek 1 znázorňuje organizaci obrany s primárním tenantem a n sekundárními tenanty (zobrazí se dva sekundární tenanti).
Identifikujte primárního tenanta. Většina organizací obrany vytváří primárního tenanta při registraci k Microsoftu 365. Primární tenant obsahuje (1) všechny identity uživatelů a licence Microsoftu 365, (2) zařízení a (3) aplikace (viz obrázek 1). Organizace obrany často používají Microsoft Entra Connect k synchronizaci identit z místní služby Active Directory do primárního tenanta Microsoft Entra.
Některé organizace obrany využívají Microsoft 365 ve sdíleném tenantovi vlastněným a provozovaným externí agenturou. Tato agentura funguje jako poskytovatel sdílených služeb pro Microsoft 365. Vaše organizace nemusí spravovat ani řídit sdílený tenant, ale obsahuje licencované identity Microsoft Entra, které vaši uživatelé pravděpodobně používají pro Office 365 a další aplikace. V tomto scénáři je tenantem poskytovatele sdílených služeb váš primární tenant.
Identifikujte všechny sekundární tenanty (pokud je víceklientské). Všichni ostatní tenanti, které organizace spravuje, jsou sekundárními tenanty. Sekundární tenanty můžete mít, pokud jste migrovali aplikace do cloudu předtím, než vytvoříte cílovou zónu Azure na podnikové úrovni. Sekundární tenanty obvykle používáte ke správě úloh Azure (4) s externími uživateli (hosty B2B) nebo (5) účtů pouze v cloudu (viz obrázek 1).
Použijte rozhodovací strom. Nejjednodušší způsob, jak najít primárního tenanta, je zvážit licence identit, které máte v ID Microsoft Entra.
Tenant s licencemi Microsoftu 365 je váš primární tenant (viz obrázek 2). Primární tenant nemusí být prvním tenantem vytvořeným vaší organizací, ale měl by to být hlavní tenant se všemi uživateli a licencemi Microsoftu 365.
Pokud vaše organizace nepoužívá Microsoft 365, je vaším primárním tenantem jakýkoli tenant Microsoft Entra s licencemi Enterprise Mobility and Security (EMS ). V tomto tenantovi jste přidali a ověřili název domény vaší organizace. Tenant často používá hybridní identitu nebo se integruje se systémem lidských zdrojů (viz obrázek 2).
Obrázek č. 2. Rozhodovací strom pro určení primárního tenanta a sekundárního tenanta Microsoft Entra.
Pokud chcete vytvořit ID Microsoft Entra jako platformu nulové důvěryhodnosti, potřebujete tenanta naplněného identitami uživatelů a licencovanými pro zásady přístupu na základě uživatele a zařízení. Licencování Microsoftu 365 nabízí tyto funkce nulové důvěryhodnosti s Office 365. Pokud Microsoft 365 nepoužíváte, zvažte Možnost Enterprise Mobility + Security E5 vytvořit cloudového zprostředkovatele identity pro nulový vztah důvěryhodnosti. Další informace najdete v tématu Volba autority identity.
Konfigurace nulové důvěryhodnosti
Při správě identit v Microsoft Entra ID byste měli zvážit následující doporučení pro každý typ tenanta. Existují obecná doporučení pro všechny typy tenantů, které byste měli přijmout jako první. Po implementaci těchto obecných doporučení vyhledejte doporučení pro konkrétní typ tenanta (primární nebo sekundární) a pak tato doporučení použijte.
Další informace o zabezpečení tenantů Microsoft Entra s nulovou důvěryhodností najdete v tématu nulová důvěra (Zero Trust) Plán rychlé modernizace a plán rychlé modernizace zabezpečení.
Všichni tenanti
Ve všech tenantech Microsoft Entra byste měli implementovat následující doporučení.
Vytvořte účty a postupy pro nouzový přístup. Vytvořte dva nebo více účtů pro nouzový přístup, abyste se vyhnuli uzamčení tenanta Microsoft Entra. K těmto účtům musíte přiřadit roli globálního správce. Účty by měly být výhradně cloudové. Účty jen pro cloud používají doménu *.onmicrosoft.com . Další informace najdete v tématu Správa účtů správce tísňového přístupu.
Důležité
Microsoft doporučuje používat role s nejmenšími oprávněními. To pomáhá zlepšit zabezpečení pro vaši organizaci. Globální správce je vysoce privilegovaná role, která by měla být omezená na scénáře tísňového volání, pokud nemůžete použít existující roli.
Chraňte ID Microsoft Entra před místními útoky. Dodržujte osvědčené postupy popsané v části Zabezpečení privilegovaného přístupu. Přiřaďte pouze oprávnění Microsoft Entra k uživatelským účtům jen v cloudu s přihlašovacími údaji odolnými proti útokům phishing, jako je hardwarové heslo nebo ověřování založené na certifikátech. Nepoužívejte federované identity pro účely správy. Další informace najdete v tématu Ochrana Microsoftu 365 před místními útoky.
Použijte Privileged Identity Management. Ke správě přiřazení rolí pro id Microsoft Entra a role Azure použijte Microsoft Entra Privileged Identity Management (PIM ). PiM byste také měli použít ke správě oprávněného členství ve skupinách skupiny pro privilegované skupiny. Vytvořte pravidelné kontroly přístupu oprávněných správců a externích uživatelů (hosté B2B).
Povolte cloudové ověřování pro všechny uživatele. Cloudové metody ověřování jsou bezpečnější než federované ověřování. Nabízejí lepší možnosti jednotného přihlašování v kombinaci se zařízeními připojenými k Microsoft Entra. Federované ověřování zveřejňuje ID Microsoft Entra pro místní Active Directory ohrožení zabezpečení.
Ověřování na základě certifikátů microsoftu Entra (CBA) zneplatňuje federování domén Microsoft Entra. Ověřování Microsoft Entra podporuje následující metody ověřování bez hesla:
- Klíče (klíče zabezpečení FIDO2)
- Ověřování na základě certifikátů
- Microsoft Authenticator
- Windows Hello pro firmy
Vytvořte základní zásady podmíněného přístupu. Směrný plán podmíněného přístupu se liší podle organizace a požadavků. Vytvořte základní sadu zásad podmíněného přístupu pro všechny tenanty Microsoft Entra. V rámci sady zásad použijte identitu, zařízení, aplikaci a rizikové podmínky. Vylučte účty pro nouzový přístup ze zásad podmíněného přístupu.
Microsoft Entra ID Protection pomáhá organizacím zjišťovat, zkoumat a opravovat rizika založená na identitách. Pokud chcete chránit riziková přihlášení a uživatele, vytvořte zásady podmíněného přístupu s rizikovými podmínkami. Pro rizikové uživatele a rizikové přihlašování používejte samostatné zásady. Zvyšte použité kontroly s úrovní rizika pro každý typ rizika. Pokud chcete vyvážit produktivitu uživatelů se zabezpečením, vyhněte se používání řízení blokování v zásadách založených na rizicích.
Poznámka:
Uživatelé můžou sama napravit rizika přihlašování pomocí vícefaktorového ověřování. Pokud chcete uživatelům umožnit samoobslužné řešení rizik přihlašování, nakonfigurujte vícefaktorové ověřování nebo sílu ověřování udělte řízení v zásadách podmíněného přístupu na základě rizik přihlašování.
Uživatelé můžou sami napravit rizika uživatelů tím, že změní svá hesla. Pokud chcete uživatelům umožnit samoobslužné nápravy rizik uživatelů, nakonfigurujte zásady podmíněného přístupu na základě rizika na základě rizika pomocí vyžadovat řízení udělení změn hesla .
Upozornění
Uživatelé bez hesla, kteří se přihlašují jenom pomocí metod bez hesla, jako je ověřování založené na certifikátu Entra, klíč nebo Windows Hello pro firmy, můžou blokovat řízení udělení změn hesla, pokud nemůžou resetovat heslo v Microsoft Entra ID.
Navrhněte zásady podmíněného přístupu pro vaši organizaci pomocí kontrolního seznamu ukázkových zásad podmíněného přístupu (viz tabulka 2). Před nasazením do produkčního prostředí můžete pomocí režimu jen pro sestavy otestovat zásady podmíněného přístupu.
Tabulka 2: Příklad kontrolního seznamu zásad podmíněného přístupu
| Název zásady | Uživatelé | Aplikace | Podmínky | Udělení ovládacího prvku |
|---|---|---|---|---|
| Vícefaktorové ověřování pro všechny uživatele | Všichni uživatelé | Všechny aplikace | Nic | - Vícefaktorové ověřování odolné proti útokům phishing |
| Vyžadování spravovaného zařízení | Všichni uživatelé | Všechny aplikace | Nic | - Vyžadovat hybridní nebo vyhovující zařízení Microsoft Entra |
| Ochrana přihlášení se středními riziky | Všichni uživatelé | Všechny aplikace | Střední riziko přihlášení | - Vícefaktorové ověřování odolné proti útokům phishing - Vyžadovat vyhovující zařízení - Frekvence přihlášení: 1 hodina (upravit podle tolerance rizik vaší organizace) |
| Ochrana přihlášení s vysokým rizikem | Všichni uživatelé | Všechny aplikace | Vysoké riziko přihlášení | - Vícefaktorové ověřování odolné proti útokům phishing - Vyžadovat vyhovující zařízení - Frekvence přihlašování: Pokaždé |
| Ochrana vysoce rizikových uživatelů | Všichni uživatelé | Všechny aplikace | Vysoké uživatelské riziko | - Vícefaktorové ověřování odolné proti útokům phishing - Vyžadovat vyhovující zařízení - Frekvence přihlašování: Pokaždé |
| Zabezpečení správy Microsoft Entra | Role Microsoft Entra | Všechny aplikace | Nic | - Vícefaktorové ověřování odolné proti útokům phishing – Vyžadovat vyhovující pracovní stanici s privilegovaným přístupem (PAW) pomocí filtrů zařízení |
| Zabezpečená správa cloudu | Všichni uživatelé | Správa Azure Google Cloud Platform Amazon Web Services |
Nic | - Vícefaktorové ověřování odolné proti útokům phishing – Vyžadovat vyhovující pracovní stanici s privilegovaným přístupem (PAW) pomocí filtrů zařízení |
Ukázková zásada nastavená v tabulce 2 je určená pro organizace bez hesla, kde všichni uživatelé používají pouze vícefaktorové ověřování odolné proti útokům phishing ze spravovaných zařízení. Privilegovaní uživatelé používají pracovní stanice s privilegovaným přístupem spravované službou Intune (PAW). Místo toho, aby se u uživatelů s vysokým rizikem vyžadovala změna hesla, zásada rizikového uživatele vynucuje sílu ověřování a kontroly četnosti přihlašování. Tyto ovládací prvky nabízejí určitou ochranu, ale nenapravují úroveň rizika uživatele ve službě Microsoft Entra ID Protection. Váš provozní tým zabezpečení by měl vyšetřovat a opravovat vysoce rizikové uživatele.
Další informace o nasazení podmíněného přístupu najdete v tématu Plánování nasazení podmíněného přístupu.
Pro přístup ke všem aplikacím použijte primární identity tenanta. Uživatelé by měli mít přístup k aplikacím pomocí své identity v primárním tenantovi. Potřebujete zaregistrovat aplikace v primárním tenantovi. Vytvořte zásadu pro registraci aplikací v primárním tenantovi bez ohledu na umístění hostování infrastruktury aplikací.
Pro starší verze aplikací, které nepodporují moderní ověřovací protokoly, použijte službu proxy aplikací Microsoft Entra v primárním tenantovi. Proxy aplikace Microsoft Entra přináší funkce nulové důvěryhodnosti Microsoft Entra do stávajících starších aplikací beze změn kódu.
Když poskytovatel sdílených služeb nebo externí agentura řídí primárního tenanta, měl by delegovat oprávnění registrace aplikace. Pokud poskytovatel služeb toto delegování nenabízí, musíte místo toho zaregistrovat aplikace v sekundárním tenantovi, který řídí vaše organizace. Uživatelé by ale měli k těmto aplikacím přistupovat i bez vytvoření nové identity v sekundárním tenantovi. Pro účely tohoto nastavení přiřaďte uživatelům přístup pomocí externích identit (hostů B2B) pro uživatele v primárním tenantovi. Další informace naleznete v tématu Zabezpečení aplikací s nulovým vztahem důvěryhodnosti.
Ke správě dalších cloudových prostředí použijte ID Microsoft Entra. Microsoft Entra ID není jen platforma identit pro Azure a Microsoft 365. Použijte Microsoft Entra ID k získání přístupu k jiným cloudovým prostředím. Mezi tato prostředí patří oblíbené produkty SaaS (software jako služba) a cloudové platformy, jako jsou Amazon Web Services (AWS) a Google Cloud Platform (GCP). Další informace naleznete v galerii aplikací Microsoft Entra.
Použijte zabezpečenou architekturu cloud computingu (SCCA). Každá obranná organizace by měla nasadit architekturu cílové zóny vyhovující SCCA. Cílová zóna by měla být v předplatných Azure připojených k primárnímu tenantovi.
Segmentace správy prostředků Azure v jednom tenantovi Role Azure byste měli použít pro izolaci prostředků a správy pro předplatná v rámci cílové zóny Azure na podnikové úrovni. Zvažte převod předplatných ze sekundárních tenantů do primárního tenanta.
Použijte Správa oprávnění Microsoft Entra. Správa oprávnění Microsoft Entra je řešení CiEM (Cloud Infrastructure Entitlement Management) od Microsoftu. K přehledu o oprávněních přiřazených všem identitám byste měli použít Správa oprávnění Microsoft Entra. Měli byste ho také použít ke sledování oprávnění v prostředí s více cloudy vaší organizace.
Použijte zásady správného řízení MICROSOFT Entra ID. Pomocí zásad správného řízení Microsoft Entra ID můžete automatizovat životní cyklus přiřazení přístupu pro uživatele a hosty. Proveďte kontroly přístupu a odeberte přístup ke cloudovému prostředí uživatelům, kteří ho už nepotřebují.
Zabezpečení identit úloh Pomocí funkcí ID úloh Microsoft Entra můžete spravovat a používat zásady adaptivní nulové důvěryhodnosti pro identity aplikací (instanční objekty) v Microsoft Entra ID.
Povolte Defender for Cloud pro váš podnik. Použijte Defender for Cloud pro vaše prostředí s více cloudy. Ujistěte se, že zapnete vylepšené funkce zabezpečení pro monitorování prostředků Azure a nápravu rizika konfigurace. Defender for Cloud Protection se rozšiřuje nad rámec Azure, aby vám pomohl zabezpečit hybridní a multicloudová prostředí.
Nasaďte Sentinel a připojte všechny dostupné zdroje dat. Agregujte bezpečnostní signály v systému SIEM, jako je Microsoft Sentinel. Nasaďte Sentinel a připojte všechny zdroje dat signálu zabezpečení konfigurací datových konektorů.
Primární tenanti
V primárním tenantovi byste měli implementovat následující doporučení.
Koncoví uživatelé mají v ID Entra jenom jednu identitu. Synchronizujte místní Active Directory Domain Services s primárním tenantem Microsoft Entra. Synchronizace naplní ID Microsoft Entra uživateli, skupinami a zařízeními pro organizaci. Externí hosté B2B můžou existovat v sekundárních tenantech, ale uživatelé si musí pamatovat jenom jedno uživatelské jméno pro všechny aplikace a služby. Uživatelské prostředí a výsledky nulové důvěryhodnosti jsou nejlepší, když používáte identity v primárním tenantovi pro přístup k přihlášení a aplikaci pro Windows.
Připojení a správa zařízení s primárním tenantem Primární tenant Microsoft Entra obsahuje všechny uživatele a zařízení v organizaci. Připojení k microsoftu Entra (nebo hybridní připojení Microsoft Entra) zařízení s Windows k primárnímu tenantovi a správě pomocí Microsoft Intune. Pomocí zásad Intune nasaďte Microsoft Defender for Endpoint , který umožňuje rozšířenou detekci a odezvu (XDR).
Delegujte oprávnění registrace aplikace. Podnikové aplikace, včetně kódu aplikace spuštěného v libovolném předplatném Azure, používají primárního tenanta Microsoft Entra ID pro identitu uživatele. Udělte vývojářům nárok na roli Vývojář aplikací Microsoft Entra nebo vlastní registrační roli aplikace pomocí Privileged Identity Management. Tato konfigurace umožňuje vývojářům vytvářet aplikace v sekundárních tenantech, aby je zaregistrovali u primárního tenanta pro identitu.
Připojte služby typu platforma jako služba (PaaS), které potřebují identitu koncového uživatele. Některé služby PaaS, jako jsou Azure Files a Azure Virtual Desktop, závisí na konfiguraci hybridní identity nebo nárocích licencí. Tyto služby musíte nasadit do předplatných Azure v primárním tenantovi.
Sekundární tenanti
V sekundárním tenantovi byste měli implementovat následující doporučení.
Pořizovat licence vyžadované pro správu Microsoft Entra. K zapnutí pokročilých funkcí zabezpečení v sekundárních tenantech potřebujete licence. Vezměte v úvahu licence, které potřebujete pro uživatele, úlohy a zařízení.
Identity uživatelů. Musíte mít licence Microsoft Entra ID Premium P2 pro správce tenantů a účty pro nouzový přístup. Pokud používáte model správy externí identity (host B2B), musíte přiřadit alespoň jednu licenci Microsoft Entra ID Premium P2 místnímu uživateli v tenantovi. Toto nastavení umožňuje povolit prémiové funkce, jako je podmíněný přístup a ochrana identit. Další informace najdete v tématu Běžné aspekty správy víceklientských uživatelů.
Identity úloh Identity úloh úrovně Premium byste měli použít k zabezpečení identit úloh s přístupem k prostředkům v primárním tenantovi, jako je rozhraní MS Graph API.
Správa zařízení. Možná budete muset spravovat zařízení pomocí Microsoft Intune v sekundárním tenantovi. Pokud ano, potřebujete získat licence Enterprise Mobility and Security (EMS).
Konfigurace zásad přístupu mezi tenanty (XTAP) Microsoft Entra Externí ID (spolupráce Microsoft Entra B2B) mezi tenanty umožňují sekundárnímu tenantovi důvěřovat určitým deklaracím z domovského primárního tenanta. Přidejte primárního tenanta Microsoft Entra jako organizaci a aktualizujte nastavení příchozí důvěryhodnosti tak, aby zahrnovala:
- Důvěřovat vícefaktorovým ověřováním (MFA) z tenantů Microsoft Entra
- Důvěřovat zařízením vyhovujícím předpisům
- Důvěřovat zařízením připojeným k hybridnímu připojení Microsoft Entra
- Volitelné: Automatické uplatnění pozvánek u tenanta
Spravujte sekundárního tenanta s identitami z primárního tenanta. Snižte režii a náklady na správu pomocí externích uživatelů (hostů B2B) z primárního tenanta za účelem správy sekundárního tenanta a prostředků Azure. Přiřaďte role Microsoft Entra po roli Microsoft Entra s nejnižším oprávněním pomocí služby Microsoft Entra Privileged Identity Management. Pomocí synchronizace přístupu iniciovaného koncovým uživatelem nebo synchronizace mezi tenanty můžete snížit režijní náklady na správu při onboardingu externích identit v sekundárním tenantovi.
Azure Lighthouse slouží k usnadnění přístupu ke službě Sentinel z primárního tenanta. Azure Lighthouse nabízí další způsob správy Azure napříč tenanty. Azure Lighthouse používá šablony Azure Resource Manageru (ARM) k přiřazení rolí Azure k identitám v externím tenantovi. Tento přístup nepoužívá objekty uživatele typu host B2B. Když se správce přihlásí k portálu pro správu Azure, uvidí všechny prostředky ve všech tenantech. Toto konsolidované zobrazení zahrnuje předplatná s oprávněními přiřazenými službou Azure Lighthouse. Vzhledem k tomu, že neexistuje žádný objekt hosta B2B, správce nemusí přepínat adresáře. Využijte Azure Lighthouse k usnadnění správy Služby Microsoft Sentinel napříč tenanty.