Sdílet prostřednictvím

Osvědčené postupy pro všechny architektury izolace

  • Článek

Níže jsou uvedené aspekty návrhu pro všechny konfigurace izolace. V tomto obsahu existuje mnoho odkazů. Místo toho, abychom ho tady duplikovali, propojili jsme obsah, takže budete mít vždy přístup k nejaktuálnějším informacím.

Obecné pokyny ke konfiguraci tenantů Microsoft Entra (izolovaných nebo ne) najdete v průvodci nasazením funkcí Microsoft Entra.

Poznámka:

Pro všechny izolované tenanty doporučujeme použít jasné a diferencované branding, abyste se vyhnuli lidské chybě při práci v nesprávném tenantovi.

Principy zabezpečení izolace

Při navrhování izolovaných prostředí je důležité vzít v úvahu následující principy:

  • Používejte pouze moderní ověřování – Aplikace nasazené v izolovaných prostředích musí používat moderní ověřování založené na deklaracích (například SAML, * Auth, OAuth2 a OpenID Connect), aby bylo možné používat funkce, jako je federace, spolupráce, delegování a architektura souhlasu microsoft Entra B2B. Starší verze aplikací, které mají závislost na starších metodách ověřování, jako je NT LAN Manager (NTLM), se tak nebudou přenášet v izolovaných prostředích.

  • Vynucení silného ověřování – Silné ověřování musí být vždy použito při přístupu ke službám a infrastruktuře izolovaného prostředí. Kdykoli je to možné, měli byste použít ověřování bez hesla, jako je Windows for Business Hello nebo klíče zabezpečení FIDO2.

  • Nasaďte zabezpečené pracovní stanice Zabezpečené pracovní stanice - poskytují mechanismus, který zajišťuje, že platforma a identita, kterou platforma představuje, je řádně potvrzena a zabezpečena před zneužitím. Mezi další dva přístupy, které je potřeba vzít v úvahu, patří:

    • Používejte cloudové počítače s Windows 365 (Cloud PC) s rozhraním Microsoft Graph API.

    • Jako podmínku použijte podmíněný přístup a vyfiltrujte zařízení.

  • Eliminujte starší mechanismy důvěryhodnosti – Izolované adresáře a služby by neměly navazovat vztahy důvěryhodnosti s jinými prostředími prostřednictvím starších mechanismů, jako jsou vztahy důvěryhodnosti služby Active Directory. Všechny vztahy důvěryhodnosti mezi prostředími by měly být vytvořeny pomocí moderních konstruktorů, jako je federace a identita založená na deklaracích.

  • Izolované služby – Minimalizujte prostor pro útok na povrch tím, že chráníte základní identity a infrastrukturu služeb před vystavením. Povolte přístup pouze prostřednictvím moderního ověřování pro služby a zabezpečený vzdálený přístup (chráněný také moderním ověřováním) pro infrastrukturu.

  • Přiřazení rolí na úrovni adresáře – Vyhněte se nebo snižte počet přiřazení rolí na úrovni adresáře (správce uživatelů v oboru adresáře místo oboru AU) nebo role adresáře specifické pro službu s akcemi řídicí roviny (správce znalostí s oprávněními ke správě členství ve skupinách zabezpečení).

Kromě pokynů v obecné provozní příručce Microsoft Entra doporučujeme také následující aspekty izolovaných prostředí.

Zřizování lidských identit

Privilegované účty

Zřiďte účty v izolovaném prostředí pro pracovníky pro správu a IT týmy, které prostředí provozují. To vám umožní přidat silnější zásady zabezpečení, jako je řízení přístupu na základě zařízení pro zabezpečené pracovní stanice. Jak je popsáno v předchozích částech, neprodukční prostředí mohou potenciálně využít spolupráci Microsoft Entra B2B k zapojování privilegovaných účtů do neprodukčních tenantů pomocí stejného stavu a kontrolních mechanismů zabezpečení navržených pro privilegovaný přístup v produkčním prostředí.

Účty jen pro cloud představují nejjednodušší způsob, jak zřídit lidské identity v tenantovi Microsoft Entra a je vhodný pro prostředí zeleného pole. Pokud ale existuje místní infrastruktura, která odpovídá izolovanému prostředí (například předprodukční doménová struktura nebo doménová struktura služby Active Directory pro správu), můžete zvážit synchronizaci identit z této struktury. To platí zejména v případě, že se místní infrastruktura popsaná zde používá pro řešení IaaS, která vyžadují přístup k serveru pro správu roviny dat řešení. Další informace o tomto scénáři najdete v tématu Ochrana Microsoftu 365 před místními útoky. Synchronizaci z izolovaných místních prostředí může být potřeba také v případě, že existují specifické požadavky na dodržování právních předpisů, jako je například ověřování jenom pomocí čipové karty.

Poznámka:

K ověření identity pro účty Microsoft Entra B2B neexistují žádné technické kontroly. Externí identity zřízené pomocí Microsoft Entra B2B se spouští jedním faktorem. Zmírněním rizik je, aby organizace měla proces pro ověření požadovaných identit před vystavením pozvánky B2B a pravidelné kontroly přístupu externích identit pro správu životního cyklu. Zvažte povolení zásad podmíněného přístupu k řízení registrace vícefaktorového ověřování.

Outsourcing vysoce rizikových rolí

Pokud chcete zmírnit vnitřní hrozby, je možné přístup k rolím globálního správce a správce privilegovaných rolí zmírnit pomocí spolupráce Azure B2B nebo delegování přístupu prostřednictvím partnera nebo lighthouse CSP. Tento přístup můžou řídit interní pracovníci prostřednictvím toků schválení ve službě Azure Privileged Identity Management (PIM). Tento přístup může výrazně snížit vnitřní hrozby. Jedná se o přístup, který můžete použít ke splnění požadavků na dodržování předpisů pro zákazníky, kteří mají obavy.

Zřizování nelidských identit

Nouzové přístupové účty

Microsoft doporučuje, aby organizace měly dva účty pro nouzový přístup jen pro cloud trvale přiřazené roli globálního správce . Tyto účty jsou vysoce privilegované a nepřiřazují se konkrétním jednotlivcům. Účty jsou omezené na scénáře tísňového volání nebo prolomení skla, kdy se nedají použít normální účty nebo všichni ostatní správci jsou omylem uzamčeni. Tyto účty by se měly vytvořit podle doporučení k účtu pro nouzový přístup.

Spravované identity Azure

Použijte spravované identity Azure pro prostředky Azure, které vyžadují identitu služby. Projděte si seznam služeb, které podporují spravované identity při navrhování řešení Azure.

Pokud spravované identity nejsou podporované nebo nejsou možné, zvažte zřízení objektů instančního objektu.

Účty hybridních služeb

Některá hybridní řešení můžou vyžadovat přístup k místním i cloudovým prostředkům. Příkladem případu použití by byla aplikace, která používá účet služby ve službě AD DS pro přístup k místním serverům připojeným k doméně a má také účet v MICROSOFT Entra ID, protože vyžaduje přístup ke službám Microsoft Online Services.

Místní účty služeb obvykle nemají možnost se přihlásit interaktivně, což znamená, že ve scénářích cloudu nemůžou splňovat silné požadavky na přihlašovací údaje, jako je vícefaktorové ověřování. V tomto scénáři nepoužívejte účet služby, který byl synchronizován z místního prostředí, ale použijte spravovanou identitu \ instanční objekt. Pro instanční objekt (SP) použijte certifikát jako přihlašovací údaje nebo chraňte sp pomocí podmíněného přístupu.

Pokud existují technická omezení, která tuto možnost nepodporují, a pro místní i cloud se musí použít stejný účet, implementujte kompenzační ovládací prvky, jako je podmíněný přístup, aby se hybridní účet uzamknul z konkrétního síťového umístění.

Přiřazení zdroje

Podnikové řešení se může skládat z několika prostředků Azure a jeho přístup by se měl spravovat a řídit jako logická jednotka přiřazení – skupina prostředků. V tomto scénáři je možné vytvořit a přidružit skupiny zabezpečení Microsoft Entra ke správným oprávněním a přiřazení rolí ve všech prostředcích řešení, aby přidání nebo odebrání uživatelů z těchto skupin mělo za následek povolení nebo zamítnutí přístupu k celému řešení.

Před poskytnutím přístupu (například Dynamics 365, Power BI) doporučujeme používat skupiny licencování a skupiny zabezpečení založené na skupinách pro služby Microsoft, které se spoléhají na přiřazení licencí uživatelům, kteří mají přiřazenou licenci.

Nativní skupiny cloudu Microsoft Entra se dají nativně řídit z cloudu v kombinaci s kontrolami přístupu Microsoft Entra a správou nároků Microsoft Entra.

Id Microsoft Entra také podporuje přímé přiřazení uživatelů ke službám SaaS třetích stran (například Salesforce, Service Now) a místním aplikacím pro jednotné přihlašování a zřizování identit. Přímá přiřazení k prostředkům se dají nativně řídit z cloudu v kombinaci s kontrolami přístupu Microsoft Entra a správou nároků Microsoft Entra. Přímé přiřazení může být vhodné pro přiřazení určené koncovým uživatelem.

Některé scénáře můžou vyžadovat udělení přístupu k místním prostředkům prostřednictvím místní Active Directory skupin zabezpečení. V těchto případech zvažte cyklus synchronizace s MICROSOFT Entra ID při návrhu smlouvy SLA.

Správa ověřování

Tato část popisuje kontroly provádění a akce, které se mají provést při správě přihlašovacích údajů a zásadách přístupu na základě stavu zabezpečení vaší organizace.

Správa přihlašovacích údajů

Silné přihlašovací údaje

Všechny lidské identity (místní účty a externí identity zřízené prostřednictvím spolupráce B2B) v izolovaném prostředí musí být zřízeny pomocí přihlašovacích údajů silného ověřování, jako je vícefaktorové ověřování nebo klíč FIDO. Prostředí s základní místní infrastrukturou se silným ověřováním, jako je například ověřování pomocí čipových karet, můžou dál používat ověřování pomocí čipových karet v cloudu.

Přihlašovací údaje bez hesla

Řešení bez hesla je nejlepším řešením pro zajištění nejpohodlnější a nejbezpečnější metody ověřování. Pro lidské identity s privilegovanými rolemi se doporučují přihlašovací údaje bez hesla, jako jsou klíče zabezpečení FIDO a Windows Hello pro firmy.

Ochrana hesel

Pokud je prostředí synchronizované z doménové struktury místní Active Directory, měli byste nasadit ochranu heslem Microsoft Entra, abyste odstranili slabá hesla ve vaší organizaci. Inteligentní uzamčení Microsoft Entra by se také mělo použít v hybridních nebo cloudových prostředích k uzamčení špatných herců, kteří se snaží uhodnout hesla uživatelů nebo použít metody hrubou silou, aby se dostali.

Samoobslužná správa hesel

Uživatelé, kteří potřebují změnit nebo resetovat svá hesla, je jedním z největších zdrojů objemu a nákladů na hovory helpdesku. Kromě nákladů představuje změna hesla jako nástroje pro zmírnění rizika uživatelů zásadní krok při vylepšování stavu zabezpečení ve vaší organizaci. Minimálně nasaďte samoobslužnou správu hesel pro lidské a testovací účty s hesly, která odpočinou volání helpdesku.

Hesla externích identit

Díky spolupráci Microsoft Entra B2B umožňuje proces pozvání a uplatnění pozvánky externím uživatelům, jako jsou partneři, vývojáři a subdodavatelé, používat pro přístup k prostředkům vaší společnosti vlastní přihlašovací údaje. Tím se zmírní nutnost zavést do izolovaných tenantů další hesla.

Poznámka:

Některé aplikace, infrastruktura nebo pracovní postupy můžou vyžadovat místní přihlašovací údaje. Vyhodnoťte to podle případu.

Přihlašovací údaje instančních objektů

Ve scénářích, ve kterých jsou potřeba instanční objekty, použijte pro instanční objekty nebo podmíněný přístup pro identity úloh přihlašovací údaje certifikátu. V případě potřeby používejte tajné kódy klienta jako výjimku pro zásady organizace.

V obou případech je možné službu Azure Key Vault použít se spravovanými identitami Azure, aby prostředí runtime (například funkce Azure) mohl načíst přihlašovací údaje z trezoru klíčů.

V tomto příkladu zkontrolujte, jestli chcete vytvořit instanční objekty s certifikátem podepsaným svým držitelem pro ověřování instančních objektů pomocí přihlašovacích údajů certifikátu.

Zásady přístupu

V následujících částech najdete doporučení pro řešení Azure. Obecné pokyny k zásadám podmíněného přístupu pro jednotlivá prostředí najdete v osvědčených postupech podmíněného přístupu, v provozní příručce Microsoft Entra a podmíněném přístupu pro nulová důvěra (Zero Trust):

  • Definujte zásady podmíněného přístupu pro cloudovou aplikaci API pro správu služeb Windows Azure, které při přístupu k Azure Resource Manageru vynucují stav zabezpečení identit. To by mělo zahrnovat ovládací prvky vícefaktorového ověřování a ovládacích prvků založených na zařízeních, které umožňují přístup pouze prostřednictvím zabezpečených pracovních stanic (další informace najdete v části Privilegované role v části Zásady správného řízení identit). Kromě toho použijte podmíněný přístup k filtrování zařízení.

  • Všechny aplikace nasazené do izolovaných prostředí musí mít v rámci procesu onboardingu explicitní zásady podmíněného přístupu.

  • Definujte zásady podmíněného přístupu pro registraci informací o zabezpečení, které odrážejí zabezpečený kořen procesu důvěryhodnosti v místním prostředí (například pro pracovní stanice ve fyzických umístěních, identifikovatelné podle IP adres, které zaměstnanci musí osobně navštívit kvůli ověření).

  • Zvažte použití podmíněného přístupu k omezení identit úloh. Vytvořte zásadu pro omezení nebo lepší řízení přístupu na základě umístění nebo jiných relevantních okolností.

Problémy s ověřováním

  • Externí identity zřízené pomocí Microsoft Entra B2B můžou v tenantovi prostředků potřebovat znovu zřídit přihlašovací údaje vícefaktorového ověřování. To může být nutné v případě, že u tenanta prostředku nebyly nastaveny zásady přístupu mezi tenanty. To znamená, že onboarding do systému se spustí jedním faktorem. Při tomto přístupu je pro organizaci potřeba, aby měla proces kontroly profilu rizika uživatele a přihlašovacích údajů před vystavením pozvánky B2B. Kromě toho definujte podmíněný přístup k procesu registrace, jak je popsáno výše.

  • Pomocí externích identit můžete spravovat způsob spolupráce s jinými organizacemi Microsoft Entra a dalšími cloudy Microsoft Azure prostřednictvím spolupráce B2B a přímého připojení B2B.

  • Pro konkrétní konfiguraci a řízení zařízení můžete pomocí filtrů zařízení v zásadách podmíněného přístupu cílit nebo vyloučit konkrétní zařízení. To vám umožní omezit přístup k nástrojům pro správu Azure z určené pracovní stanice zabezpečené správy (SAW). Mezi další přístupy, které můžete využít, patří používání služby Azure Virtual Desktop, Azure Bastion nebo Cloud PC.

  • Aplikace pro správu fakturace, jako je portál Azure EA nebo fakturační účty MCA, nejsou reprezentovány jako cloudové aplikace pro cílení na podmíněný přístup. Jako kompenzační řízení definujte samostatné účty pro správu a zásady podmíněného přístupu k těmto účtům pomocí podmínky Všechny aplikace.

Zásady správného řízení identit

Privilegované role

Níže jsou uvedené některé principy zásad správného řízení identit, které je potřeba zvážit napříč všemi konfiguracemi tenantů za účelem izolace.

  • Žádný trvalý přístup – žádné lidské identity by neměly mít stálý přístup k provádění privilegovaných operací v izolovaných prostředích. Řízení přístupu na základě role v Azure (RBAC) se integruje se službou Microsoft Entra Privileged Identity Management (PIM). PIM poskytuje včasnou aktivaci určenou branami zabezpečení, jako je vícefaktorové ověřování, pracovní postup schvalování a omezená doba trvání.

  • Počet správců – Organizace by měly definovat minimální a maximální počet lidí, kteří mají privilegovanou roli, aby se zmírnit rizika provozní kontinuity. U příliš málo privilegovaných rolí nemusí být dostatek časového pásma pokrytí. Zmírnit rizika zabezpečení tím, že po zásadě nejnižších oprávnění bude mít co nejmenší počet správců.

  • Omezte privilegovaný přístup – Vytvořte skupiny určené jen pro cloud a přiřazovatelné role pro vysoká oprávnění nebo citlivá oprávnění. To nabízí ochranu přiřazených uživatelů a objektu skupiny.

  • Nejméně privilegovaný přístup – Identitám by se měla udělit jenom oprávnění potřebná k provádění privilegovaných operací podle jejich role v organizaci.

    • Vlastní role Azure RBAC umožňují navrhovat nejméně privilegované role na základě potřeb organizace. Doporučujeme, aby definice vlastních rolí byly vytvořené nebo zkontrolovány specializovanými bezpečnostními týmy a zmírnit rizika nezamýšlených nadměrných oprávnění. Vytváření vlastních rolí je možné auditovat prostřednictvím služby Azure Policy.

    • Pokud chcete zmírnit náhodné použití rolí, které nejsou určené pro širší použití v organizaci, definujte pomocí služby Azure Policy explicitně, které definice rolí je možné použít k přiřazení přístupu. Další informace najdete v této ukázce GitHubu.

  • Privilegovaný přístup ze zabezpečených pracovních stanic – Veškerý privilegovaný přístup by měl probíhat ze zabezpečených uzamčených zařízení. Oddělení těchto citlivých úloh a účtů od každodenních pracovních stanic a zařízení chrání privilegované účty před útoky phishing, ohrožením zabezpečení aplikací a operačního systému, různými útoky zosobnění a útoky na krádež přihlašovacích údajů, jako je protokolování stisknutí kláves, pass-the-hash a pass-the-ticket.

Mezi přístupy, které můžete použít k používání zabezpečených zařízení v rámci scénáře privilegovaného přístupu, patří použití zásad podmíněného přístupu k cílení nebo vyloučení konkrétních zařízení, použití virtuální plochy Azure, služby Azure Bastion nebo cloudového počítače nebo vytváření pracovních stanic spravovaných Azure nebo pracovních stanic s privilegovaným přístupem.

  • Ochranné mantinely procesu privilegovaných rolí – Organizace musí definovat procesy a technické mantinely, aby bylo možné privilegované operace spouštět, kdykoli je to potřeba při splnění zákonných požadavků. Mezi příklady kritérií mantinely patří:

    • Kvalifikace lidí s privilegovanými rolemi (například zaměstnanec/dodavatel na plný úvazek, úroveň clearance, občanství)

    • Explicitní nekompatibilitu rolí (označovaných také jako oddělení povinností). Mezi příklady patří týmy s rolemi adresáře Microsoft Entra, které by neměly být zodpovědné za správu privilegovaných rolí Azure Resource Manageru atd.

    • U kterých rolí se upřednostňuje přímé přiřazení uživatelů nebo skupin.

  • Monitorování přiřazení IAM mimo Microsoft Entra PIM není automatizované prostřednictvím zásad Azure. Zmírněním rizik není udělení rolí vlastníka předplatného ani správce uživatelských přístupů technickým týmům. Místo toho vytvořte skupiny přiřazené k nejméně privilegovaným rolím, jako je přispěvatel, a delegujte správu těchto skupin na technické týmy.

Přístup k prostředkům

  • Ověření identity – Identity, které obsahují privilegované role, by se měly pravidelně kontrolovat, aby členství zůstalo aktuální a odůvodněné. Kontroly přístupu Microsoft Entra se integrují s rolemi Azure RBAC, členstvím ve skupinách a externími identitami Microsoft Entra B2B.

  • Životní cyklus – Privilegované operace můžou vyžadovat přístup k více prostředkům, jako jsou obchodní aplikace, aplikace SaaS a skupiny prostředků Azure a předplatná. Microsoft Entra Entitlement Management umožňuje definovat přístupové balíčky, které představují nastavený prostředek přiřazený uživatelům jako jednotku, stanovit dobu platnosti, schvalovací pracovní postupy atd.

Správa životního cyklu tenanta a předplatného

Životní cyklus tenanta

  • Doporučujeme implementovat proces pro vyžádání nového podnikového tenanta Microsoft Entra. Proces by měl odpovídat:

    • Obchodní odůvodnění pro jeho vytvoření Vytvoření nového tenanta Microsoft Entra výrazně zvýší složitost, takže je klíčem zjistit, jestli je nový tenant nezbytný.

    • Cloud Azure, ve kterém by se měl vytvořit (například komerční, státní správa atd.).

    • Bez ohledu na to, jestli se jedná o produkční nebo neprodukční

    • Požadavky na rezidenci dat adresáře

    • Kdo ho bude spravovat

    • Školení a porozumění běžným požadavkům na zabezpečení

  • Po schválení se vytvoří tenant Microsoft Entra, nakonfiguruje se s nezbytnými základními ovládacími prvky a připojí se v rovině fakturace, monitorování atd.

  • Pravidelná kontrola tenantů Microsoft Entra v rovině fakturace musí být implementována, aby bylo možné detekovat a zjišťovat vytváření tenantů mimo řízený proces. Další podrobnosti najdete v části Inventář a viditelnost tohoto dokumentu.

  • Vytváření tenanta Azure AD B2C je možné řídit pomocí Azure Policy. Tato zásada se spustí, když je předplatné Azure přidružené k tenantovi B2C (požadavek na fakturaci). Zákazníci můžou omezit vytváření tenantů Azure AD B2C na konkrétní skupiny pro správu.

  • Neexistují žádné technické kontroly, které by podřízeny vytváření tenantů organizaci. Aktivita se však zaznamenává v protokolu auditu. Onboarding do fakturační roviny je kompenzační ovládací prvek na bráně. Místo toho je potřeba ho doplnit monitorováním a výstrahami.

Životní cyklus předplatného

Níže jsou uvedeny některé aspekty návrhu řízení procesu životního cyklu předplatného:

  • Definujte taxonomii aplikací a řešení, která vyžadují prostředky Azure. Všechny týmy, které požadují předplatná, by měly při žádosti o předplatná zadat svůj "identifikátor produktu". Tato taxonomieinformacích

    • Tenant Microsoft Entra pro zřízení předplatného

    • Účet Azure EA, který se má použít k vytvoření předplatného

    • Konvence pojmenování

    • Přiřazení skupiny pro správu

    • Další aspekty, jako je označování, křížové účtování, využití zobrazení produktů atd.

  • Nepovolujte vytváření ad hoc předplatného prostřednictvím portálů ani jinými prostředky. Místo toho zvažte programovou správu předplatných pomocí Azure Resource Manageru a programové načítání sestav o spotřebě a fakturaci. To může pomoct omezit zřizování předplatného autorizovaným uživatelům a vynutit cíle zásad a taxonomie. Pokyny k používání následujících objektů zabezpečení AZOps můžete použít k vytvoření praktického řešení.

  • Po zřízení předplatného vytvořte cloudové skupiny Microsoft Entra, které budou obsahovat standardní role Azure Resource Manageru, které vyžadují aplikační týmy, jako je přispěvatel, čtenář a schválené vlastní role. To umožňuje spravovat přiřazení rolí Azure RBAC s řízeným privilegovaným přístupem ve velkém měřítku.

    1. Nakonfigurujte skupiny tak, aby byly způsobilé pro role Azure RBAC pomocí nástroje Microsoft Entra PIM s odpovídajícími ovládacími prvky, jako jsou zásady aktivace, kontroly přístupu, schvalovatelé atd.

    2. Pak delegujte správu skupin vlastníkům řešení.

    3. Jako mantinely nepřiřazujte vlastníky produktů k rolím Správce uživatelských přístupů nebo Vlastník, abyste se vyhnuli neúmyslnému přímému přiřazení rolí mimo Microsoft Entra PIM nebo potenciálně změnili předplatné na jiného tenanta úplně.

    4. Pro zákazníky, kteří se rozhodnou povolit správu předplatných napříč tenanty v neprodukčních tenantech prostřednictvím Služby Azure Lighthouse, se ujistěte, že se při ověřování pro správu předplatných vynucují stejné zásady přístupu z produkčního privilegovaného účtu (například privilegovaný přístup pouze ze zabezpečených pracovních stanic).

  • Pokud má vaše organizace předem schválené referenční architektury, je možné zřizování předplatného integrovat s nástroji pro nasazení prostředků, jako jsou Azure Blueprints nebo Terraform.

  • Vzhledem k přidružení tenanta k předplatným Azure by zřizování předplatného mělo vědět o několika identitách stejného lidského aktéra (zaměstnance, partnera, dodavatele atd.) napříč několika tenanty a odpovídajícím způsobem přiřazovat přístup.

Role EA a MCA

  • Portál smlouvy Azure Enterprise (Azure EA) se neintegruje s Azure RBAC ani podmíněným přístupem. Zmírněním tohoto rizika je použití vyhrazených účtů pro správu, na které se dají cílit zásady a další monitorování.

  • Portál Azure EA Enterprise neposkytuje protokol auditu. Pokud chcete tento problém zmírnit, zvažte automatizovaný proces řízení zřizování předplatných s ohledem na výše popsané aspekty a použití vyhrazených účtů EA a auditování protokolů ověřování.

  • role Smlouva se zákazníkem Microsoftu (MCA) se neintegrují nativně s PIM. Pokud chcete tento problém zmírnit, použijte vyhrazené účty MCA a monitorujte využití těchto účtů.

Tenanti Azure AD B2C

  • V tenantovi Azure AD B2C předdefinované role nepodporují PIM. Pokud chcete zvýšit zabezpečení, doporučujeme použít spolupráci Microsoft Entra B2B k nasazení technických týmů, které spravují správu správy přístupu k identitám zákazníků (CIAM) z vašeho tenanta Azure, přiřaďte je k privilegovaným rolím Azure AD B2C a na tyto vyhrazené účty pro správu použijte zásady podmíněného přístupu.

  • Privilegované role tenanta Azure AD B2C nejsou integrované s recenzemi přístupu Microsoft Entra. Zmírněním rizik je vytvoření vyhrazených účtů v tenantovi Microsoft Entra organizace, přidání těchto účtů do skupiny a pravidelné kontroly přístupu u této skupiny.

  • Podle výše uvedených pokynů pro nouzový přístup pro MICROSOFT Entra ID zvažte vytvoření ekvivalentních účtů pro nouzový přístup a také externí správci popsané výše.

  • Doporučujeme logické vlastnictví základního předplatného Microsoft Entra tenanta B2C v souladu s technickými týmy CIAM stejným způsobem, jakým se pro řešení B2C používají zbývající předplatná Azure.

Operace

Následují další provozní aspekty pro ID Microsoft Entra, které jsou specifické pro několik izolovaných prostředí. Podrobné pokyny k provozování jednotlivých prostředí najdete v azure Cloud Adoption Frameworku, srovnávacím testu zabezpečení cloudu Microsoftu a průvodci provozem Microsoft Entra Operations.

Role a zodpovědnosti mezi prostředími

Architektura SecOps na podnikové úrovni – Členové provozních a bezpečnostních týmů ze všech prostředí v organizaci by měli společně definovat následující:

  • Principy definování, kdy je potřeba vytvořit, konsolidovat nebo zastaralá prostředí.

  • Principy definování hierarchie skupin pro správu v jednotlivých prostředích

  • Stav zabezpečení v rovině fakturace (portál EA / MCA), provozní stav a přístup k delegování

  • Proces vytváření tenanta

  • Taxonomie podnikových aplikací

  • Proces zřizování předplatného Azure

  • Hranice samostatnosti izolace a správy a hodnocení rizik napříč týmy a prostředími.

  • Běžné standardní konfigurace a kontrolní mechanismy zabezpečení (technické a kompenzační) a provozní směrné plány, které se mají použít ve všech prostředích.

  • Běžné standardní provozní postupy a nástroje, které zahrnují více prostředí (například monitorování, zřizování).

  • Odsouhlasené delegování rolí napříč několika prostředími.

  • Oddělení povinností napříč prostředími

  • Běžná správa dodavatelského řetězce pro privilegované pracovní stanice

  • Zásady vytváření názvů.

  • Mechanismy korelace mezi prostředími

Vytvoření tenanta – Konkrétní tým by měl vlastnit vytvoření tenanta podle standardizovaných postupů definovaných architekturou SecOps na podnikové úrovni. Sem patří:

  • Zřizování základních licencí (například Microsoft 365)

  • Onboarding do firemního fakturačního plánu (například Azure EA nebo MCA).

  • Vytvoření hierarchie skupin pro správu Azure

  • Konfigurace zásad správy pro různé hraniční sítě, včetně identity, ochrany dat, Azure atd.

  • Nasazení zásobníku zabezpečení na základě schválené architektury kybernetické bezpečnosti, včetně nastavení diagnostiky, onboardingu SIEM, onboardingu CASB, onboardingu PIM atd.

  • Konfigurace rolí Microsoft Entra na základě odsouhlaseného delegování

  • Konfigurace a distribuce počátečních privilegovaných pracovních stanic

  • Zřizování účtů pro nouzový přístup

  • Konfigurace zásobníku zřizování identit

Architektura nástrojů mezi prostředími – Některé nástroje, jako je zřizování identit a kanály správy zdrojového kódu, můžou potřebovat pracovat napříč několika prostředími. Tyto nástroje by měly být pro infrastrukturu považovány za důležité a musí být navrženy, implementovány a spravovány jako takové. V důsledku toho by se architekti ze všech prostředí měli zapojit vždy, když je potřeba definovat nástroje pro různé prostředí.

Inventarizace a zajištění přehledu

Zjišťování předplatného Azure – Pro každého zjištěného tenanta může globální správce Microsoftu zvýšit úroveň přístupu , aby získal přehled o všech předplatných v prostředí. Toto zvýšení oprávnění jim přiřadí integrovanou roli Správce uživatelských přístupů v kořenové skupině pro správu.

Poznámka:

Tato akce je vysoce privilegovaná a může správci udělit přístup k předplatným, která obsahují extrémně citlivé informace, pokud tato data nebyla řádně izolovaná.

Povolení přístupu pro čtení ke zjišťování prostředků – Skupiny pro správu umožňují přiřazování RBAC ve velkém měřítku napříč několika předplatnými. Zákazníci můžou centrálnímu IT týmu udělit roli Čtenář tím, že nakonfigurují přiřazení role v kořenové skupině pro správu, která se rozšíří do všech předplatných v prostředí.

Zjišťování prostředků – Po získání přístupu ke čtení prostředků v prostředí je možné azure Resource Graph použít k dotazování prostředků v prostředí.

Protokolování a monitorování

Centrální správa protokolů zabezpečení – Ingestování protokolů z každého prostředí centralizovaným způsobem, dodržování konzistentních osvědčených postupů napříč prostředími (například nastavení diagnostiky, uchovávání protokolů, příjem dat SIEM atd.). Azure Monitor se dá použít k ingestování protokolů z různých zdrojů, jako jsou zařízení koncových bodů, síť, protokoly zabezpečení operačních systémů atd.

Podrobné informace o používání automatizovaných nebo ručních procesů a nástrojů k monitorování protokolů v rámci operací zabezpečení jsou k dispozici v průvodci operacemi zabezpečení Microsoft Entra.

Některá prostředí můžou mít zákonné požadavky, které omezují, která data (pokud existuje) můžou dané prostředí opustit. Pokud centralizované monitorování napříč prostředími není možné, týmy by měly mít provozní postupy ke korelaci aktivit identit napříč prostředími pro účely auditování a forenzních účelů, jako jsou pokusy o laterální přesun mezi prostředími. Doporučuje se, aby bylo možné zjistit jedinečné identifikátory lidských identit patřících stejné osobě, které mohou být součástí systémů zřizování identit.

Strategie protokolu musí obsahovat následující protokoly Microsoft Entra pro každého tenanta používaného v organizaci:

  • Aktivita přihlášení

  • Protokoly auditu

  • Rizikové události

ID Microsoft Entra poskytuje integraci služby Azure Monitor pro protokol aktivit přihlašování a protokoly auditu. Rizikové události je možné ingestovat prostřednictvím rozhraní Microsoft Graph API.

Následující diagram znázorňuje různé zdroje dat, které je potřeba začlenit jako součást strategie monitorování:

Tenanty Azure AD B2C je možné integrovat se službou Azure Monitor. Ke sledování Azure AD B2C doporučujeme použít stejná kritéria uvedená výše pro ID Microsoft Entra.

Předplatná, která povolila správu napříč tenanty pomocí služby Azure Lighthouse, můžou povolit monitorování mezi tenanty, pokud azure Monitor shromažďuje protokoly. Odpovídající pracovní prostory služby Log Analytics se můžou nacházet v tenantovi prostředků a je možné je analyzovat centrálně ve správě tenanta pomocí sešitů služby Azure Monitor. Další informace najdete v tématu Monitorování delegovaných prostředků ve velkém měřítku – Azure Lighthouse.

Protokoly zabezpečení operačního systému hybridní infrastruktury

Všechny protokoly operačního systému infrastruktury hybridní identity by se měly archivovat a pečlivě monitorovat jako systém vrstvy 0 vzhledem k dopadům na oblast. Sem patří:

  • Servery služby AD FS a webové proxy aplikací

  • Microsoft Entra Connect

  • agenti proxy aplikací

  • Agenti pro zpětný zápis hesla

  • Počítače brány ochrany heslem

  • NPS s vícefaktorovým rozšířením RADIUS microsoft Entra

Služba Microsoft Entra Connect Health musí být nasazena pro monitorování synchronizace identit a federace (pokud je k dispozici) pro všechna prostředí.

Uchovávání protokolů – Všechna prostředí by měla mít strategii, návrh a implementaci úložiště protokolů, která usnadňují konzistentní sadu nástrojů (například systémy SIEM, jako je Azure Sentinel), běžné dotazy, šetření a forenzní playbooky. Azure Policy se dá použít k nastavení diagnostiky.

Monitorování a kontrola protokolů – Provozní úlohy související s monitorováním identit by měly být konzistentní a měly by mít vlastníky v jednotlivých prostředích. Jak je popsáno výše, snažte se tyto odpovědnosti konsolidovat napříč prostředími v rozsahu povoleném zákonnými požadavky na dodržování předpisů a izolaci.

Následující scénáře musí být explicitně monitorovány a prošetřovány:

  • Podezřelá aktivita – Všechny rizikové události Microsoft Entra by měly být monitorovány pro podezřelou aktivitu. Všichni tenanti by měli definovat síťová pojmenovaná umístění , aby se zabránilo hlučným detekci na signálech založených na poloze. Služba Microsoft Entra ID Protection je nativně integrovaná se službou Azure Security Center. Doporučuje se, aby jakékoli šetření detekce rizik zahrnovalo všechna prostředí, která je identita zřízená (například pokud má lidská identita aktivní detekci rizik v podnikovém tenantovi, tým provozující tenanta, který se zabývá zákazníkem, by měl také prozkoumat aktivitu odpovídajícího účtu v daném prostředí).

  • Výstrahy analýzy chování entit uživatele (UEBA) – UEBA by se měly použít k získání přehledných informací na základě detekce anomálií. Microsoft Microsoft 365 Defender for Cloud Apps poskytuje UEBA v cloudu. Zákazníci můžou integrovat místní rozhraní UEBA z Microsoftu 365 Defenderu for Identity. MCAS čte signály z Microsoft Entra ID Protection.

  • Aktivita účtů tísňového přístupu – Veškerý přístup pomocí účtů tísňového volání by se měl monitorovat a vytvářet výstrahy pro šetření. Toto monitorování musí zahrnovat:

    • Přihlášení

    • Správa přihlašovacích údajů

    • Všechny aktualizace členství ve skupinách

    • Přiřazení aplikací

  • Účty pro správu fakturace – Vzhledem k citlivosti účtů s rolemi správy fakturace v Azure EA nebo MCA a jejich významným oprávněním se doporučuje monitorovat a upozorňovat:

    • Pokusy o přihlášení podle účtů s fakturačními rolemi

    • Všechny pokusy o ověření v jiných aplikacích než na portálu EA.

    • Všechny pokusy o ověření v jiných aplikacích než Azure Resource Management, pokud používáte vyhrazené účty pro úlohy fakturace MCA.

    • Přiřazení k prostředkům Azure pomocí vyhrazených účtů pro úlohy fakturace MCA

  • Aktivita privilegované role – Konfigurace a kontrola výstrah zabezpečení generovaných nástrojem Microsoft Entra PIM Pokud uzamčení přímých přiřazení RBAC není plně vynucovatelné pomocí technických kontrolních mechanismů (například role vlastníka musí být udělena produktovému týmu, aby mohli provádět svou úlohu), pak monitorujte přímé přiřazení privilegovaných rolí mimo PIM generováním výstrah pokaždé, když je uživatel přiřazený přímo pro přístup k předplatnému pomocí Azure RBAC.

  • Klasická přiřazení rolí – Organizace by měly místo klasických rolí používat moderní infrastrukturu rolí Azure RBAC. V důsledku toho by se měly monitorovat následující události:

    • Přiřazení klasických rolí na úrovni předplatného

  • Konfigurace pro celého tenanta – Každá služba konfigurace pro celého tenanta by měla vygenerovat výstrahy v systému.

    • Aktualizace vlastních domén

    • Aktualizace brandingu

    • Seznam povolených a blokovaných položek Microsoft Entra B2B

    • Zprostředkovatelé identity Microsoft Entra B2B (IP adresy SAML prostřednictvím přímé federace nebo přihlášení k sociálních sítím)

    • Změny zásad podmíněného přístupu

  • Aplikační a instanční objekty

    • Nové aplikace / Instanční objekty, které můžou vyžadovat zásady podmíněného přístupu

    • Aktivita souhlasu aplikace

  • Aktivita skupiny pro správu – Měly by se monitorovat následující aspekty identit skupin pro správu:

    • Přiřazení rolí RBAC v mg

    • Zásady Azure použité v mg

    • Předplatná přesunutá mezi MG

    • Všechny změny zásad zabezpečení kořenové mg

  • Vlastní role

    • Aktualizace definic vlastních rolí

    • Vytvořené nové vlastní role

  • Vlastní oddělení pravidel povinností – Pokud vaše organizace nastavily nějaké oddělení pravidel povinností, použijte nekompatibilní přístupové balíčky microsoft Entra Entitlement Management k vynucení oddělení povinností a vytvořte výstrahy nebo nakonfigurujte pravidelné kontroly pro detekci porušení správců.

Další aspekty monitorování – Předplatná Azure, která obsahují prostředky používané pro správu protokolů, by se měly považovat za kritickou infrastrukturu (úroveň 0) a zamknout provoznímu týmu zabezpečení odpovídajícího prostředí. Zvažte použití nástrojů, jako je Azure Policy, k vynucení dalších ovládacích prvků pro tato předplatná.

Provozní nástroje

Aspekty návrhu nástrojů napříč prostředími :

  • Kdykoli je to možné, měly by být provozní nástroje, které se použijí napříč více tenanty, navrženy tak, aby běžely jako aplikace Microsoft Entra s více tenanty, aby se zabránilo opětovnému nasazení více instancí v každém tenantovi a vyhnuli se provozní efektivitě. Implementace by měla zahrnovat autorizační logiku, aby se zajistila izolace mezi uživateli a daty.

  • Přidejte výstrahy a detekce pro monitorování jakékoli automatizace napříč prostředími (například zřizování identit) a prahových limitů pro bezpečné selhání. Pokud například zrušení zřízení uživatelských účtů dosáhne určité úrovně, může to znamenat chybu nebo provozní chybu, která by mohla mít široký dopad.

  • Všechny automatizace, které orchestrují úlohy mezi prostředími, by se měly provozovat jako vysoce privilegovaný systém. Pokud se vyžadují data z jiných prostředí, měl by být tento systém domovem nejvyššího prostředí zabezpečení a přijímat z externích zdrojů. Aby se zachovala integrita systému, je potřeba použít ověřování dat a prahové hodnoty. Běžnou úlohou mezi prostředími je správa životního cyklu identit, která odebere identity ze všech prostředí pro ukončeného zaměstnance.

Nástroje pro správu it služeb – Organizace používající systémy SPRÁVY IT služeb (ITSM), jako je ServiceNow, by měly nakonfigurovat nastavení aktivace role Microsoft Entra PIM tak, aby v rámci aktivačních účelů požadovaly číslo lístku.

Podobně je možné Azure Monitor integrovat se systémy ITSM prostřednictvím konektoru IT Service Management Connector.

Provozní postupy – Minimalizujte provozní aktivity, které vyžadují přímý přístup k prostředí k lidským identitám. Místo toho je modelujte jako Azure Pipelines, které provádějí běžné operace (například přidejte kapacitu do řešení PaaS, spusťte diagnostiku atd.) a modelujte přímý přístup k rozhraním Azure Resource Manageru pro scénáře "přerušení skla".

Provozní výzvy

  • Aktivita monitorování instančního objektu je pro některé scénáře omezená.

  • Upozornění Microsoft Entra PIM nemají rozhraní API. Zmírnění rizik spočívá v pravidelné kontrole těchto upozornění PIM.

  • Azure EA Portal neposkytuje možnosti monitorování. Zmírněním rizik je mít vyhrazené účty pro správu a monitorovat aktivitu účtu.

  • MCA neposkytuje protokoly auditu pro úlohy fakturace. Zmírněním rizik je mít vyhrazené účty pro správu a monitorovat aktivitu účtu.

  • Některé služby v Azure potřebné k provozu prostředí je potřeba znovu nasadit a překonfigurovat napříč prostředími, protože nemůžou být víceklientní nebo multicloudové.

  • Neexistuje žádné úplné pokrytí rozhraní API napříč online službami Microsoftu, aby bylo plně dosaženo infrastruktury jako kódu. Zmírněním rizik je co nejvíce používat rozhraní API a používat portály pro zbytek. Tato opensourcová iniciativa vám pomůže určit přístup, který by mohl fungovat pro vaše prostředí.

  • Neexistuje žádná programová schopnost zjišťovat tenanty prostředků, kteří mají delegovaný přístup k předplatným identitám ve spravovaném tenantovi. Pokud například e-mailová adresa povolila skupinu zabezpečení v tenantovi contoso.com ke správě předplatných v tenantovi fabrikam.com, správci v contoso.com nemají rozhraní API ke zjištění, že k tomuto delegování došlo.

  • Není k dispozici monitorování konkrétních aktivit účtu (například rozsklený účet, účet pro správu fakturace). Omezení rizik je pro zákazníky, aby vytvořili vlastní pravidla upozornění.

  • Monitorování konfigurace pro celého tenanta není k dispozici. Omezení rizik je pro zákazníky, aby vytvořili vlastní pravidla upozornění.

Další kroky