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

  • Článek

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

Z: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. Podle potřeby omezte přístup výhradně na. Pro všechny implementace ověřování a autorizace používejte moderní oborové standardy. Omezte a důsledně 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í získat přístup k prostředkům vašich úloh.

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

  • Lidi. 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 

Terminologie Definice
Ověřování (AuthN) Proces, který ověřuje, že identita je to, o koho 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.
Přihlašovací Zprostředkovatel identity, například id Microsoft Entra.
Persona Pracovní funkce nebo název, který má sadu odpovědností a akcí.
Předsdílené klíče Typ tajného kódu, který se sdílí mezi poskytovatelem a spotřebitelem a používá se prostřednictvím zabezpečeného a schváleného mechanismu.
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 role povolena k provozu. 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. Členové skupiny získají stejnou úroveň přístupu.
Identita uživatele Identita osoby, jako je zaměstnanec nebo externí uživatel.
Identita úlohy Identita systému pro aplikaci, službu, skript, kontejner nebo jinou komponentu úlohy, která se používá k ověřování 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řazeným objektem zabezpečení. Skupina zabezpečení je příkladem objektu zabezpečení. Tento hierarchický vztah zjednodušuje údržbu a zlepšuje konzistenci. Vzhledem k tomu, že atributy identity se nezpracují na individuální úrovni, snižuje se také pravděpodobnost chyb. V tomto článku je pojem identita zahrnující objekty 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 pro správu identit a přístupu. Neimplementujte vlastní systémy, které by nahradily 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říč několika tenanty. Microsoft Entra ID je zprostředkovatele identity pro cloudovou platformu Azure.

Authentication

Ověřování je proces, který ověřuje identity. K poskytnutí určité formy ověřitelné identifikace se vyžaduje žádající identita. Příklad:

  • Uživatelské jméno a heslo.

  • Předsdí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á při vzájemném ověřování TLS.

Proces ověření by měl co nejvíce zpracovávat váš zprostředkovatel identity.

Autorizace

Autorizace je proces, který povoluje nebo zakazuje akce požadované ověřenou identitou. Akce může být funkční nebo může souviset se správou prostředků.

Autorizace vyžaduje, abyste identitám přiřadili oprávnění, což musíte udělat pomocí funkce poskytované vaším zprostředkovatelem identity.

Klíčové strategie návrhu

Pokud chcete získat ucelený přehled o potřebách identit pro úlohu, musíte katalogizace toků, prostředků a osob úloh a akcí, 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é přistupují k úloze nebo jejím komponentám (přístup z vnějšku), a toky, které se z úlohy dostanou do jiných zdrojů (vnitřní přístup).

Každý případ použití bude pravděpodobně mít svou vlastní sadu ovládacích prvků, které budete muset navrhnout s předpokladem porušení mysli. 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é, abyste zaváděli zbytečné režijní náklady na správu.

Musíte protokolovat přístupovou cestu identity. To vám pomůže ověřit kontroly a protokoly můžete použít pro audity dodržování předpisů.

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

  • Přístup zvenku. Návrh identity musí ověřit všechny uživatele, kteří k úloze přistupují 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 z vnějšku. Například operátor, který potřebuje přístup prostřednictvím portálu nebo přístup k výpočetním prostředkům ke spouštění příkazů.

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

  • Přístup zevnitř. Vaše aplikace bude potřebovat přístup k dalším prostředkům. Například čtení z datové platformy nebo zápis na datovou platformu, 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. Tyto požadavky na přístup vyžadují identitu úlohy, která aplikaci umožňuje ověřit se vůči ostatním prostředkům.

    Tento koncept platí 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. Tyto požadavky na přístup vyžadují identitu prostředku.

Všechny tyto identity by měl ověřit váš zprostředkovatel identity.

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

Diagram znázorňující, jak je možné implementovat identitu 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 bylo možné tyto akce autorizovat. Akce je možné rozdělit podle typu přístupu, který vyžadují:

  • Přístup k rovině dat. Akce, které probíhají v rovině dat, způsobují přenos dat pro přístup zevnitř nebo zvenčí. Například aplikace, která č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 komponent se výpočetní prostředky, které načítají nebo nasdílí image do registru nebo z registru, považují za operace roviny dat.

  • Řízení přístupu k rovině. Akce, které probíhají v řídicí rovině, způsobí vytvoření, změnu nebo odstranění prostředku Azure. Například změny ve vlastnostech prostředku.

Aplikace obvykle cílí na operace roviny dat, zatímco operace často přistupují k rovinám řízení i dat. Pokud chcete identifikovat potřeby autorizace, poznamenejte si provozní akce, které je možné s prostředkem provést. 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 za každou identitu povolte akce, které by měly být povoleny. Identitě nesmí být dovoleno dělat víc, než potřebuje. Než nastavíte autorizační pravidla, musíte mít jasnou představu o tom, kdo nebo co vytváří požadavky, co tato role může dělat a do jaké míry to může udělat. Tyto faktory vedou k možnostem, 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 musí být povolené akce čtení a zápisu do datového prostředku. Potřebuje ale aplikace přístup řídicí roviny k úložišti tajných kódů? Pokud je identita úlohy ohrožena chybovým aktérem, jaký by to mělo 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é umožňují dokončení úkolu pouze identitě, a nic dalšího. Pokud jsou oprávnění uživatele omezena na požadavky jeho úlohy, je snazší identifikovat podezřelé nebo neoprávněné chování v systému.

Položte otázky, jako jsou tyto:

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

Omezení úrovně přístupu uživatelů, aplikací nebo služeb k prostředkům Azure snižuje potenciální prostor pro útoky. Pokud udělíte pouze minimální oprávnění potřebná k provádění konkrétních úkolů, 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 k atributům zabezpečení jen pro čtení pro všechna technická prostředí. Tato úroveň je dostatečná k posouzení rizikových faktorů, identifikaci možných zmírnění rizik a hlášení o rizicích.

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 mohou jednotliví uživatelé provádět více standardních rolí. V tomto případě místo vytvář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. Tím usnadníte správu rolí.

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á se obtížně udržuje a negativně ovlivňuje 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 riskantní. 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 k identitám se přiřazují pomocí řízení přístupu na základě role (RBAC). Vždy používejte RBAC poskytovaný zprostředkovatelem identity, abyste mohli využívat funkce, které umožňují používat řízení přístupu konzistentně a důsledně ho odvolávat.

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

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

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

Volba podmíněného přístupu

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

  • Čas. Jak dlouho může identita přistupovat 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 trvání přístupu, může získat větší kontrolu nad systémem a daty nebo tento přístup použít k dalším změnám prostředí. Omezte tyto faktory přístupu jako preventivní opatření i pro řízení poloměru výbuchu.

  • Přístupy just in Time (JIT) 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, platí další podmínky. K nastavení zásad můžete například použít také zařízení, síť a umístění, ze kterého přístup pochází.

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

Například k vaší úloze může být potřeba přistupovat 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ů.

Vaše 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 integrovanou analýzu hrozeb. To zahrnuje monitorování žádostí o přístup a přihlášení. Azure Zprostředkovatel identity je Microsoft Entra ID. Další informace najdete v tomto článku v části Věnované usnadnění Azure .

Účty 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í zabezpečení nebo zneužití může mít nepříznivý dopad na vaši firmu a její informační systémy. Jednou z nejdůležitějších oblastí zabezpečení je zabezpečení správy.

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

  • Minimalizujte počet účtů s kritickým dopadem.

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

  • Vyhněte se trvalému nebo trvalému přístupu pomocí funkcí JIT vašeho zprostředkovatele identity. V situacích s rozbitým sklem postupujte podle postupu 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řadíte účty 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ým a místním prostředím snižuje lidské chyby a související bezpečnostní rizika. Týmy v obou prostředích, které spravují prostředky, potřebují konzistentní a autoritativní zdroj, aby splňovaly záruky zabezpečení. Ve spolupráci s vaším centrálním týmem identit zajistíte synchronizaci identit v hybridních prostředích.

Riziko: Se synchronizací identit s vysokými oprávněními je spojeno riziko. Útočník může získat plnou kontrolu nad místními prostředky, což může vést k úspěšnému ohrožení cloudového účtu. Vyhodnoťte strategii synchronizace odfiltrováním účtů, které se můžou přidat do prostoru útoku.

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 identita přistupuje. Ujistěte se, že máte proces pro zakázání nebo odstranění identit v případě, že dojde ke změnám struktury týmu nebo softwarových komponent.

Tyto pokyny se týkají správy zdrojového kódu, dat, řídicích rovin, uživatelů úloh, infrastruktury, nástrojů, monitorování dat, protokolů, metrik a dalších entit.

Vytvořte proces zásad správného řízení identit pro správu životního cyklu digitálních identit, uživatelů s vysokými oprávněními, externích uživatelů nebo uživatelů hosta a uživatelů úloh. Implementujte kontroly přístupu, abyste zajistili, že když identity opustí organizaci nebo tým, odeberou se jim 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 měly být v systému považovány za zranitelné body. Pokud je v obousměrné komunikaci ohrožen poskytovatel nebo spotřebitel, mohou být zavedena významná bezpečnostní rizika. Tyto klíče mohou být také zatěžující, protože zavádějí provozní procesy.

Pokud je to možné, 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 jejím prostředkům.

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

  • Nakládat s těmito tajnými kódy 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 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 obměně klíčů a vypršení platnosti.

Informace o zásadách obměně najdete v tématech Automatizace obměně tajného kódu pro prostředky, které mají dvě sady přihlašovacích údajů pro ověřování, a Kurz: Aktualizace frekvence automatické obměně certifikátů v Key Vault.

Udržujte vývojová prostředí v bezpečí

Všechny kódy a skripty, nástroje kanálů a systémy správy zdrojového kódu by měly být považovány za prostředky úloh. Přístup k zápisům by měl být chráněn automatizací a peer review. Přístup ke čtení zdrojového kódu by měl být omezen na role podle potřeby. Úložiště kódu musí mít správu verzí a kontroly bezpečnostního kódu od partnerských partnerů musí být běžným postupem, který je integrovaný s životním cyklem vývoje. Potřebujete mít zavedený proces, který pravidelně kontroluje prostředky a identifikuje nejnovější ohrožení zabezpečení.

Pomocí identit úloh můžete udělit 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 zajistit, aby systém byl auditovatelný. Audity ověřují, jestli jsou strategie převzetí zabezpečení efektivní. Údržba záznamu auditu vám pomůže:

  • Ověřte, že je identita ověřená pomocí silného ověřování. Všechny akce musí být vysledovatelné, aby se zabránilo útokům na odmítnutí.

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

  • 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é nastavíte.

  • 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 k diagnostice zabezpečení.

Další informace najdete v tématu Doporučení k monitorování zabezpečení a analýze 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. Microsoft Entra ID je tenant přidružený k předplatnému úloh. 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 identit a oprávnění Microsoft Entra pro uživatelské segmenty:

ID Microsoft Entra můžete použít k ověřování a autorizaci vlastních aplikací prostřednictvím knihovny MSAL (Microsoft Authentication Library) nebo funkcí platformy, jako je ověřování pro webové aplikace. Pokrývá 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 microsof Microsoft Entra je jediným bodem selhání stejně jako jakákoli jiná základní služba. Dokud microsoft výpadek nevyřeší, neexistuje žádné alternativní řešení. Bohatá sada funkcí Microsoft Entra však převáží riziko použití vlastních řešení.

Azure podporuje otevřené protokoly, jako jsou OAuth2 a OpenID Connect. Doporučujeme místo návrhu vlastních toků používat tyto standardní mechanismy ověřování a autorizace.

Azure RBAC

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

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

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 úlohy

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

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

Instanční objekt se také abstrahuje, když použijete spravovanou identitu. 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žít spravované identity, můžete použít instanční objekty. Použití instančních objektů ale zvyšuje režii správy. 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 se můžou pomocí spravovaných identit ověřovat 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, která jsou pro případ použití vyžadována. Nakonfigurujte Microsoft Entra podmíněný přístup 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 ke skupinám

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 ujistit se, že jsou oprávnění aktuální. Skupinu můžete použít také k jiným účelům, jako jsou seznamy adresátů.

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

Detekce hrozeb

Microsoft Entra ID Protection vám můžou pomoct zjišťovat, prošetřovat 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 upozornění na podezřelou aktivitu nebo aktivního vyhledávání neobvyklých událostí v protokolech aktivit. Analýza chování uživatelů a entit (UEBA) ve službě Microsoft Sentinel 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 Microsoft Entra ID, které mají ve vaší stávající službě Active Directory vysoká oprávnění. Tato synchronizace je ve výchozí konfiguraci synchronizace Microsoft Entra Connect Zablokovaná, takže stačí jenom ověřit, že jste tuto konfiguraci nepřizpůsobili.

Informace o filtrování v id Microsoft Entra najdete v tématu synchronizace Microsoft Entra Connect: Konfigurace filtrování.

Protokolování identity

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í získat přístup ke kterým prostředkům, a výsledek těchto pokusů. Shromážděné protokoly se odesílají do služby Azure Monitor.

Kompromis: Protokolování způsobuje náklady kvůli úložišti dat, které se používá k ukládání protokolů. Může to také způsobit dopad na výkon, zejména na kód a na ř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.

Diagram znázorňující implementaci identity

Komponenty identit

  • Identity spravované systémem. Microsoft Entra ID poskytuje přístup k rovinám dat služby, které nemají přístup k uživatelům, jako jsou 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ěřování v jiných komponentách v řešení.

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

  • Lidské identity. Ověřování uživatelů a operátorů je delegováno na Microsoft Entra ID nebo id Microsoft Entra (nativní, B2B nebo B2C).

Zabezpečení předsdílených tajných kódů je zásadní pro každou aplikaci. Azure Key Vault poskytuje mechanismus zabezpečeného úložiště pro tyto tajné kódy, včetně Redisu a tajných kódů třetích stran.

Mechanismus obměty se používá k zajištění toho, aby se tajné kódy neohrožovaly. Tokeny pro Microsoft identity platform implementaci OAuth 2 a OpenID Connect se používají k ověřování uživatelů.

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

Protokoly přístupu jsou povoleny ve všech komponentách prostřednictvím Azure Diagnostics nebo prostřednictvím kódu pro komponenty kódu.

Kontrolní seznam zabezpečení

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

Kontrolní seznam zabezpečení