Doporučení pro správu identit a přístupu

Platí pro toto doporučení kontrolního seznamu zabezpečení architektury Azure Well-Architected Framework:

SE:05	Implementujte striktní, podmíněnou a auditovatelnou správu identit a přístupu (IAM) pro všechny uživatele úloh, členy týmu a systémové komponenty. Omezte přístup výhradně podle potřeby. Používejte moderní oborové standardy pro všechny implementace ověřování a autorizace. Omezte a pečlivě auditujte přístup, který není založený na identitě.

Tato příručka popisuje doporučení pro ověřování a autorizaci identit, které se pokoušejí o přístup k prostředkům úloh.

Z hlediska technické kontroly je identita vždy primárním hraničním zařízením. Tento obor nezahrnuje jenom okraje vaší úlohy. Zahrnuje také jednotlivé komponenty, které jsou uvnitř vaší úlohy. Mezi typické identity patří:

• Lidé. Uživatelé aplikací, správci, operátoři, auditoři a špatní aktéři.

• Systémy. Identity úloh, spravované identity, klíče rozhraní API, instanční objekty a prostředky Azure

• Anonymní. Entity, které neposkytly žádné důkazy o tom, kdo jsou.

Definice 

Termíny	Definice
Ověřování (AuthN)	Proces, který ověří, že identita je kdo nebo co říká.
Autorizace (AuthZ)	Proces, který ověřuje, jestli má identita oprávnění k provedení požadované akce.
Podmíněný přístup	Sada pravidel, která umožňují akce založené na zadaných kritériích.
Federační	Zprostředkovatel identity, jako je ID Microsoft Entra.
Osoba	Funkce úlohy nebo název, který má sadu zodpovědností a akcí.
Předsdílené klíče	Typ tajného klíče, který je sdílený mezi poskytovatelem a spotřebitelem a používán zabezpečeným a dohodnutým mechanismem.
Identita prostředku	Identita definovaná pro cloudové prostředky spravované platformou.
Role	Sada oprávnění, která definují, co může uživatel nebo skupina dělat.
Obor	Různé úrovně organizační hierarchie, kde je povolena činnost role. Také skupina funkcí v systému.
Objekt zabezpečení	Identita, která poskytuje oprávnění. Může to být uživatel, skupina nebo instanční objekt. Každý člen skupiny získá stejnou úroveň přístupu.
Identita uživatele	Identita osoby, jako je zaměstnanec nebo externí uživatel.
Identita úloh	Systémová identita pro aplikaci, službu, skript, kontejner nebo jinou komponentu úlohy, která se používá k ověření v jiných službách a prostředcích.

Poznámka:

Identitu je možné seskupit s jinými, podobnými identitami pod nadřazenou položkou označovanou jako objekt zabezpečení. Příkladem objektu zabezpečení je skupina zabezpečení. Tento hierarchický vztah zjednodušuje údržbu a zlepšuje konzistenci. Vzhledem k tomu, že atributy identity se nezpracují na jednotlivých úrovních, snižuje se také pravděpodobnost chyb. V tomto článku je pojem identita inkluzivní z objektů zabezpečení.

Role zprostředkovatele identity

Zprostředkovatel identity (IdP) je služba hostovaná v cloudu, která ukládá a spravuje uživatele jako digitální identity.

Využijte možnosti poskytované důvěryhodným zprostředkovatelem identity a správy přístupu. Neimplementujte vlastní systémy pro nahrazení zprostředkovatele identity. Systémy zprostředkovatele identity se často vylepšují na základě nejnovějších vektorů útoku tím, že každý den zachytávají miliardy signálů napříč více tenanty. ID Microsoft Entra je zprostředkovatele identity pro cloudovou platformu Azure.

Ověřování

Ověřování je proces, který ověřuje identity. Žádost o identitu je nutná k poskytnutí určité formy ověřitelné identifikace. Příklad:

• Uživatelské jméno a heslo.

• Předem sdílený tajný klíč, jako je klíč rozhraní API, který uděluje přístup.

• Token sdíleného přístupového podpisu (SAS).

• Certifikát, který se používá v vzájemném ověřování TLS.

Proces ověření by měl co nejvíce zpracovat váš zprostředkovatele identity.

Autorizace

Autorizace je proces, který umožňuje nebo zakazuje akce, které jsou požadovány ověřenou identitou. Akce může být funkční nebo související se správou prostředků.

Autorizace vyžaduje, abyste identitám přiřadili oprávnění, která musíte provést pomocí funkcí poskytovaných vaším zprostředkovatele identity.

Klíčové strategie návrhu

Pokud chcete získat holistický přehled o potřebách identity pro úlohu, musíte katalogovat toky, prostředky úloh a osoby a akce, které budou prostředky a osoby provádět. Vaše strategie musí zahrnovat všechny případy použití, které zpracovávají toky, které se dostanou k úloze nebo jeho komponentám (mimo přístup) a toky, které se dostanou z úlohy do jiných zdrojů (přístup uvnitř ven).

Každý případ použití bude mít pravděpodobně vlastní sadu ovládacích prvků, které potřebujete navrhnout s ohledem na předpokládat porušení zabezpečení. Na základě požadavků na identitu případu použití nebo osob identifikujte podmíněné volby. Nepoužívejte jedno řešení pro všechny případy použití. Naopak ovládací prvky by neměly být tak podrobné, že zavádíte zbytečné režijní náklady na správu.

Potřebujete protokolovat záznam přístupu k identitě. To pomáhá ověřit ovládací prvky a můžete použít protokoly pro audity dodržování předpisů.

Určení všech identit pro ověřování

• Přístup mimo přístup. Návrh vaší identity musí ověřovat všechny uživatele, kteří přistupují k úloze pro různé účely. Například koncový uživatel, který přistupuje k aplikaci voláním rozhraní API.

  Na podrobné úrovni můžou komponenty úlohy také potřebovat přístup zvenčí. Například operátor, který potřebuje přístup přes portál nebo přístup k výpočetnímu objektu ke spouštění příkazů.

  Oba jsou příklady identit uživatelů, které mají různé osoby.

• Vnitřní přístup. Vaše aplikace bude potřebovat přístup k jiným prostředkům. Například čtení z datové platformy nebo zápis do datové platformy, načítání tajných kódů z úložiště tajných kódů a protokolování telemetrie do monitorovacích služeb. Může dokonce potřebovat přístup ke službám třetích stran. Tento přístup vyžaduje identitu úlohy, která aplikaci umožní ověřit se vůči ostatním prostředkům.

  Koncept se vztahuje na úrovni komponenty. V následujícím příkladu může kontejner potřebovat přístup ke kanálům nasazení, aby získal svoji konfiguraci. Tento přístup vyžaduje identitu prostředku.

Všechny tyto identity by měly být ověřeny vaším zprostředkovatele identity.

Tady je příklad implementace identity v architektuře:

Určení akcí pro autorizaci

Dále potřebujete vědět, co se každá ověřená identita pokouší udělat, aby tyto akce mohly být autorizované. Akce je možné rozdělit podle typu přístupu, který vyžadují:

• Přístup k rovině dat. Akce, které se provádějí v rovině dat, způsobují přenos dat pro vnitřní nebo vnější přístup. Aplikace například čte data z databáze a zapisuje data do databáze, načítá tajné kódy nebo zapisuje protokoly do jímky monitorování. Na úrovni komponenty se výpočetní prostředky, které načítají nebo načítají image do nebo z registru, se považují za operace roviny dat.

• Řízení přístupu k rovině. Akce, které se provádějí v řídicí rovině, způsobují, že se prostředek Azure vytvoří, upraví nebo odstraní. Například změny vlastností prostředku.

Aplikace obvykle cílí na operace roviny dat, zatímco operace často přistupují k řídicím rovinám i rovinám dat. Pokud chcete identifikovat potřeby autorizace, poznamenejte si provozní akce, které je možné provést u prostředku. Informace o povolených akcích pro jednotlivé prostředky najdete v tématu Operace poskytovatele prostředků Azure.

Poskytnutí autorizace na základě role

Na základě odpovědnosti každé identity povolte akce, které by měly být povoleny. Identita nesmí dělat víc, než je potřeba. Než nastavíte autorizační pravidla, musíte mít jasné znalosti o tom, kdo nebo co provádí žádosti, co tato role může dělat, a v jakém rozsahu to může udělat. Tyto faktory vedou k volbám, které kombinují identitu, roli a obor.

Představte si jako příklad identitu úlohy. Aplikace musí mít přístup k databázi roviny dat, takže akce čtení a zápisu do datového prostředku musí být povolené. Potřebuje ale aplikace přístup řídicí roviny k úložišti tajných kódů? Pokud je identita úlohy ohrožena špatným aktérem, jaký bude dopad na systém z hlediska důvěrnosti, integrity a dostupnosti?

Přiřazení role

Role je sada oprávnění přiřazených k identitě. Přiřaďte role, které identitě umožňují dokončit úkol, a ne další. Pokud jsou oprávnění uživatele omezena na požadavky na úlohu, je snazší identifikovat podezřelé nebo neoprávněné chování v systému.

Ptejte se na tyto otázky:

• Je přístup jen pro čtení dostatečný?
• Potřebuje identita oprávnění k odstranění prostředků?

Omezení úrovně přístupu, kterou uživatelé, aplikace nebo služby musí mít k prostředkům Azure, snižuje potenciální prostor pro útok. Pokud udělíte pouze minimální oprávnění potřebná k provádění konkrétních úloh, riziko úspěšného útoku nebo neoprávněného přístupu se výrazně sníží. Například bezpečnostní týmy potřebují přístup jen pro čtení k atributům zabezpečení pro všechna technická prostředí. Tato úroveň stačí k posouzení rizikových faktorů, identifikaci možných zmírnění rizik a hlášení rizik.

Existují scénáře, ve kterých uživatelé potřebují větší přístup kvůli organizační struktuře a organizaci týmu. Mezi různými rolemi může docházet k překrývání nebo můžou jednotliví uživatelé provádět více standardních rolí. V tomto případě místo vytvoření vlastní role pro každého z těchto uživatelů použijte více přiřazení rolí, která jsou založená na obchodní funkci. Díky tomu se role snadněji spravují.

Vyhněte se oprávněním, která konkrétně odkazují na jednotlivé prostředky nebo uživatele. Podrobná a vlastní oprávnění vytvářejí složitost a nejasnosti, protože nepředávají záměr novým prostředkům, které jsou podobné. To může vytvořit složitou starší konfiguraci, která je obtížně udržovat a negativně ovlivnit zabezpečení i spolehlivost.

Kompromis: Podrobný přístup k řízení přístupu umožňuje lepší auditování a monitorování aktivit uživatelů.

Role má také přidružený obor. Role může fungovat v povolené skupině pro správu, předplatném, skupině prostředků nebo oboru prostředků nebo v jiném vlastním oboru. I když má identita omezenou sadu oprávnění, rozšíření oboru tak, aby zahrnoval prostředky, které jsou mimo funkci úlohy identity, je rizikové. Například přístup pro čtení ke všem zdrojovým kódům a datům může být nebezpečný a musí být řízen.

Role přiřadíte identitám pomocí řízení přístupu na základě role (RBAC). Vždy používejte RBAC poskytovaný zprostředkovatele identity, abyste mohli využívat funkce, které umožňují konzistentně používat řízení přístupu a odvolávat ho přísně.

Použijte předdefinované role. Jsou navržené tak, aby zahrnovaly většinu případů použití. Vlastní role jsou výkonné a někdy užitečné, ale měli byste je rezervovat pro scénáře, ve kterých předdefinované role nebudou fungovat. Přizpůsobení vede ke složitosti, která zvyšuje záměny a zkompiluje automatizaci složitější, náročnou a křehkou. Všechny tyto faktory mají negativní vliv na zabezpečení.

Udělte role, které začínají nejnižšími oprávněními, a přidejte více na základě vašich provozních potřeb nebo potřeb přístupu k datům. Vaše technické týmy musí mít jasné pokyny k implementaci oprávnění.

Pokud chcete jemně odstupňovanou kontrolu na řízení přístupu na základě role, přidejte podmínky pro přiřazení role na základě kontextu, jako jsou akce a atributy.

Nastavení možností podmíněného přístupu

Neudělujte všem identitám stejnou úroveň přístupu. Založte rozhodnutí na dvou hlavních faktorech:

• Čas. Jak dlouho má identita přístup k vašemu prostředí.

• Oprávnění. Úroveň oprávnění.

Tyto faktory se vzájemně nevylučují. Ohrožená identita, která má více oprávnění a neomezenou dobu přístupu, může získat větší kontrolu nad systémem a daty nebo tento přístup použít k pokračování v změně prostředí. Omezte tyto přístupové faktory jako preventivní opatření a kontrolujte poloměr výbuchu.

• Přístupy JIT (Just in Time) poskytují požadovaná oprávnění jenom v případě, že jsou potřeba.

• Just Enough Access (JEA) poskytuje pouze požadovaná oprávnění.

I když jsou čas a oprávnění primárními faktory, existují další podmínky, které platí. Můžete například použít zařízení, síť a umístění, ze kterého přístup pochází, a nastavit zásady.

Používejte silné ovládací prvky, které filtrují, detekují a blokují neoprávněný přístup, včetně parametrů, jako je identita uživatele a umístění, stav zařízení, kontext úloh, klasifikace dat a anomálie.

Vaše úloha může být například potřeba získat přístup k identitám třetích stran, jako jsou dodavatelé, partneři a zákazníci. Potřebují odpovídající úroveň přístupu, nikoli výchozí oprávnění, která poskytujete zaměstnancům na plný úvazek. Jasné rozlišení externích účtů usnadňuje prevenci a detekci útoků, které pocházejí z těchto vektorů.

Volba zprostředkovatele identity musí být schopná zajistit toto rozlišení, poskytovat integrované funkce, které uděluje oprávnění na základě nejnižších oprávnění, a poskytovat integrované inteligentní informace o hrozbách. To zahrnuje monitorování žádostí o přístup a přihlášení. Azure IdP je Microsoft Entra ID. Další informace najdete v části Usnadnění Azure v tomto článku.

Ochrana účtů s kritickým dopadem

Identity pro správu představují některá z největších rizik zabezpečení, protože úlohy, které provádějí, vyžadují privilegovaný přístup k široké sadě těchto systémů a aplikací. Ohrožení nebo zneužití může mít negativní vliv na vaši firmu a její informační systémy. Zabezpečení správy je jednou z nejdůležitějších oblastí zabezpečení.

Ochrana privilegovaného přístupu před určenými nežádoucími osobami vyžaduje úplný a promyšlený přístup k izolaci těchto systémů před riziky. Tady je několik možných strategií:

• Minimalizujte počet účtů kritického dopadu.

• Místo zvýšení oprávnění pro existující identity používejte samostatné role .

• Vyhněte se trvalému nebo stálému přístupu pomocí funkcí JIT vašeho zprostředkovatele identity. V případě prolomení situací postupujte podle procesu nouzového přístupu.

• Používejte moderní přístupové protokoly , jako je ověřování bez hesla nebo vícefaktorové ověřování. Externalizujte tyto mechanismy do zprostředkovatele identity.

• Vynucujte klíčové atributy zabezpečení pomocí zásad podmíněného přístupu.

• Vyřazení účtů pro správu, které se nepoužívají

Použijte jednu identitu napříč prostředími a přidružte jednu identitu k uživateli nebo objektu zabezpečení. Konzistence identit napříč cloudovými a místními prostředími snižuje lidské chyby a výsledné bezpečnostní rizika. Týmy v obou prostředích, která spravují prostředky, potřebují konzistentní a autoritativní zdroj, aby splňovaly bezpečnostní záruky. Spolupracujte s týmem centrální identity, abyste zajistili synchronizaci identit v hybridních prostředích.

Riziko: Existuje riziko spojené se synchronizací identit s vysokými oprávněními. Útočník může získat úplnou kontrolu nad místními prostředky a to může vést k úspěšnému ohrožení cloudového účtu. Vyhodnoťte strategii synchronizace filtrováním účtů, které se můžou přidat na prostor pro útoky.

Vytvoření procesů pro správu životního cyklu identit

Přístup k identitám nesmí trvat déle než prostředky, ke kterým identitám přistupuje. Pokud dojde ke změnám struktury týmu nebo softwarových komponent, ujistěte se, že máte proces zakázání nebo odstranění identit.

Tyto pokyny platí pro správu zdrojového kódu, data, roviny řízení, uživatele úloh, infrastrukturu, nástroje, monitorování dat, protokoly, metriky a další entity.

Vytvořte proces zásad správného řízení identit pro správu životního cyklu digitálních identit, vysoce privilegovaných uživatelů, externích a hostovaných uživatelů a uživatelů úloh. Implementujte kontroly přístupu, abyste zajistili, že když identity opustí organizaci nebo tým, odeberou se jejich oprávnění k úlohám.

Ochrana tajných kódů založených na neidentitě

Tajné kódy aplikací, jako jsou předsdílené klíče, by se měly v systému považovat za zranitelné body. V obousměrné komunikaci je možné zavést významná bezpečnostní rizika, pokud je poskytovatel nebo spotřebitel ohrožen. Tyto klíče můžou být také náročné, protože zavádějí provozní procesy.

Pokud můžete, vyhněte se používání tajných kódů a zvažte použití ověřování na základě identit pro přístup uživatelů k samotné aplikaci, nejen k prostředkům.

Následující seznam obsahuje souhrn pokynů. Další informace najdete v tématu Doporučení pro tajné kódy aplikací.

• S těmito tajnými kódy můžete zacházet jako s entitami, které je možné dynamicky načíst z úložiště tajných kódů. Neměly by být pevně zakódované v kódu vaší aplikace, skriptech IaC, kanálech nasazení ani v žádném jiném artefaktu.

• Ujistěte se, že máte možnost odvolat tajné kódy.

• Použijte provozní postupy, které zpracovávají úlohy, jako je rotace klíčů a vypršení platnosti.

Informace o zásadách obměny najdete v tématu Automatizace obměny tajného kódu pro prostředky se dvěma sadami přihlašovacích údajů pro ověřování a kurz: Aktualizace frekvence automatické obměny certifikátů ve službě Key Vault.

Udržování vývojového prostředí v bezpečí

Všechny kódy a skripty, nástroje kanálu a systémy správy zdrojového kódu by se měly považovat za prostředky úloh. Přístup k zápisům by měl být bránován pomocí automatizace a partnerské kontroly. Přístup ke čtení ke zdrojovému kódu by měl být omezen na role na základě potřeb. Úložiště kódu musí mít správu verzí a kontroly kódu zabezpečení podle partnerských vztahů musí být pravidelnou praxí, která je integrovaná s životním cyklem vývoje. Musíte mít zaveden proces, který pravidelně kontroluje prostředky a identifikuje nejnovější chyby zabezpečení.

Pomocí identit úloh udělte přístup k prostředkům z prostředí nasazení, jako je GitHub.

Údržba záznamu auditu

Jedním z aspektů správy identit je zajištění, aby systém byl auditovatelný. Audity ověřují, jestli jsou strategie předpokládaného porušení zabezpečení účinné. Údržba záznamu auditu vám pomůže:

• Ověřte, že se identita ověřuje pomocí silného ověřování. Jakákoli akce musí být trasovatelná , aby se zabránilo útokům na odvrácení.

• Detekujte slabé nebo chybějící ověřovací protokoly a získejte přehled o přihlašování uživatelů a aplikací.

• Vyhodnoťte přístup z identit k úloze na základě požadavků na zabezpečení a dodržování předpisů a zvažte riziko uživatelského účtu, stav zařízení a další kritéria a zásady, které jste nastavili.

• Sledujte průběh nebo odchylku od požadavků na dodržování předpisů.

Většina prostředků má přístup k rovině dat. Potřebujete znát identity, které přistupují k prostředkům, a akce, které provádějí. Tyto informace můžete použít pro diagnostiku zabezpečení.

Další informace najdete v tématu Doporučení týkající se monitorování zabezpečení a analýzy hrozeb.

Usnadnění azure

Doporučujeme vždy používat moderní ověřovací protokoly, které berou v úvahu všechny dostupné datové body a používají podmíněný přístup. Microsoft Entra ID poskytuje správu identit a přístupu v Azure. Pokrývá rovinu správy Azure a je integrovaná s rovinami dat většiny služeb Azure. ID Microsoft Entra je tenant, který je přidružený k předplatnému úlohy. Sleduje a spravuje identity a jejich povolená oprávnění a zjednodušuje celkovou správu, aby se minimalizovalo riziko dohledu nebo lidské chyby.

Tyto funkce se nativně integrují do stejného modelu identity a oprávnění Microsoft Entra pro uživatelské segmenty:

• Microsoft Entra ID. Zaměstnanci a zdroje organizace.

• Microsoft Entra Externí ID. Partnery.

• Azure AD B2C. Zákazníci.

• Seznam kompatibility federace Microsoft Entra Řešení federace třetích stran.

Pro ověřování a autorizaci vlastních aplikací prostřednictvím knihovny Microsoft Authentication Library (MSAL) nebo funkcí platformy, jako je ověřování webových aplikací, můžete použít ID Microsoft Entra. Zahrnuje rovinu správy Azure, roviny dat většiny služeb Azure a možnosti integrace pro vaše aplikace.

Aktuální informace najdete v tématu Co je nového v Microsoft Entra ID.

Kompromis: Id Microsoft Entra je kritickým bodem selhání stejně jako jakákoli jiná základní služba. Dokud microsoft neřekne výpadek, neexistuje žádné alternativní řešení. Bohatá sada funkcí Microsoft Entra ale převáží nad rizikem používání vlastních řešení.

podpora Azure otvírá protokoly, jako je OAuth2 a OpenID Connect. Místo návrhu vlastních toků doporučujeme používat tyto standardní ověřovací a autorizační mechanismy.

Azure RBAC

Azure RBAC představuje objekty zabezpečení v Microsoft Entra ID. Všechna přiřazení rolí se provádí prostřednictvím Azure RBAC. Využijte výhod předdefinovaných rolí, které poskytují většinu potřebných oprávnění. Další informace najdete v tématu Předdefinované role Microsoft Entra.

Tady je několik případů použití:

• Přiřazením uživatelů k rolím můžete řídit přístup k prostředkům Azure. Další informace naleznete v tématu Přehled řízení přístupu na základě role v Microsoft Entra ID.

• Privileged Identity Management můžete použít k zajištění aktivace role založené na čase a schválení pro role, které jsou přidružené k vysoce ovlivněným identitám. Další informace najdete v tématu Co je Privileged Identity Management?

Další informace o RBAC najdete v tématu Osvědčené postupy pro Azure RBAC.

Informace o ovládacích prvcích založených na atributech najdete v tématu Co je Azure ABAC?.

Identita úloh

Id Microsoft Entra může zpracovávat identitu vaší aplikace. Instanční objekt přidružený k aplikaci může určovat jeho rozsah přístupu.

Další informace najdete v tématu Co jsou identity úloh?

Instanční objekt se také abstrahuje při použití spravované identity. Výhodou je, že Azure spravuje všechny přihlašovací údaje pro aplikaci.

Ne všechny služby podporují spravované identity. Pokud nemůžete používat spravované identity, můžete použít instanční objekty. Použití instančních objektů ale zvyšuje režijní náklady na správu. Další informace najdete v tématu, které vysvětluje, co jsou spravované identity pro prostředky Azure.

Identita prostředku

Koncept spravovaných identit je možné rozšířit na prostředky Azure. Prostředky Azure můžou používat spravované identity k ověřování v jiných službách, které podporují ověřování Microsoft Entra. Další informace najdete v tématu Služby Azure, které můžou používat spravované identity pro přístup k jiným službám.

Zásady podmíněného přístupu

Podmíněný přístup popisuje zásady pro rozhodnutí o přístupu. Pokud chcete použít podmíněný přístup, musíte porozumět omezením požadovaným pro případ použití. Nakonfigurujte podmíněný přístup Microsoft Entra nastavením zásad přístupu na základě vašich provozních potřeb.

Další informace najdete v tématu Podmíněný přístup: Uživatelé, skupiny a identity úloh.

Správa přístupu skupin

Místo udělení oprávnění konkrétním uživatelům přiřaďte přístup ke skupinám v ID Microsoft Entra. Pokud skupina neexistuje, vytvořte ji ve spolupráci s týmem identit. Potom můžete přidávat a odebírat členy skupiny mimo Azure a zajistit, aby oprávnění byla aktuální. Skupinu můžete také použít pro jiné účely, například seznamy adresátů.

Další informace naleznete v tématu Zabezpečení řízení přístupu pomocí skupin v Microsoft Entra ID.

Detekce hrozeb

Microsoft Entra ID Protection vám může pomoct zjišťovat, zkoumat a opravovat rizika založená na identitách. Další informace najdete v tématu Co je Identity Protection?

Detekce hrozeb může mít podobu reakce na výstrahu podezřelé aktivity nebo proaktivně vyhledávat neobvyklé události v protokolech aktivit. Analýza chování uživatelů a entit (UEBA) v Microsoft Sentinelu usnadňuje detekci podezřelých aktivit. Další informace najdete v tématu Identifikace pokročilých hrozeb pomocí UEBA.

Hybridní systémy

V Azure nesynchronizujete účty s ID Microsoft Entra s vysokými oprávněními ve vaší stávající službě Active Directory. Tato synchronizace je zablokovaná ve výchozí konfiguraci synchronizace Microsoft Entra Connect, takže stačí ověřit, že jste tuto konfiguraci nepřizpůsobili.

Informace o filtrování v Microsoft Entra ID naleznete v tématu Microsoft Entra Connect Sync: Konfigurace filtrování.

Protokolování identit

Povolte nastavení diagnostiky u prostředků Azure, abyste mohli generovat informace, které můžete použít jako záznam auditu. Diagnostické informace ukazují, které identity se pokoušejí o přístup k prostředkům a výsledku těchto pokusů. Shromážděné protokoly se odesílají do služby Azure Monitor.

Kompromis: Protokolování způsobuje náklady z důvodu úložiště dat, které se používá k ukládání protokolů. Může také způsobit dopad na výkon, zejména na kód a řešení protokolování, která přidáte do aplikace.

Příklad

Následující příklad ukazuje implementaci identity. Různé typy identit se používají společně k poskytování požadovaných úrovní přístupu.

Komponenty identit

• Identity spravované systémem Microsoft Entra ID poskytuje přístup k rovinám dat služeb, které nemají tváře uživatelům, jako je Azure Key Vault a úložiště dat. Tyto identity také řídí přístup prostřednictvím RBAC k rovině správy Azure pro komponenty úloh, agenty nasazení a členy týmu.

• Identity úloh Aplikační služby v clusteru Azure Kubernetes Service (AKS) používají identity úloh k ověření v jiných komponentách řešení.

• Spravované identity. Systémové komponenty v klientské roli používají identity spravované systémem, včetně agentů sestavení.

• Lidské identity. Ověřování uživatele a operátora se deleguje na ID Microsoft Entra nebo Microsoft Entra ID (nativní, B2B nebo B2C).

Zabezpečení předsdílených tajných kódů je důležité pro všechny aplikace. Azure Key Vault poskytuje zabezpečený mechanismus úložiště pro tyto tajné kódy, včetně Redis a tajných kódů třetích stran.

Mechanismus obměně slouží k zajištění, že tajné kódy nejsou ohroženy. K ověřování uživatelů se používají tokeny pro implementaci platformy Microsoft Identity Platform OAuth 2 a OpenID Connect.

Azure Policy se používá k zajištění toho, aby komponenty identit, jako je Key Vault, místo zásad přístupu používaly RBAC. JIT a JEA poskytují tradiční stálé oprávnění pro lidské operátory.

Protokoly přístupu jsou povolené napříč všemi komponentami prostřednictvím azure Diagnostics nebo prostřednictvím kódu pro komponenty kódu.

Související odkazy

• Kurz: Automatizace obměně tajného kódu pro prostředky, které mají dvě sady přihlašovacích údajů pro ověřování
• Kurz: Aktualizace frekvence automatické obměny certifikátů ve službě Key Vault
• Co je nového v Microsoft Entra ID?
• Předdefinované role Microsoft Entra
• Přehled řízení přístupu na základě role v Microsoft Entra ID
• Co jsou identity úloh?
• Co jsou spravované identity pro prostředky Azure?
• Podmíněný přístup: Uživatelé, skupiny a identity úloh
• Synchronizace Microsoft Entra Connect: Konfigurace filtrování

Kontrolní seznam zabezpečení

Projděte si kompletní sadu doporučení.

Kontrolní seznam zabezpečení