Řízení přístupu migrací modelu role organizace na zásady správného řízení ID Microsoft Entra
Řízení přístupu na základě role (RBAC) poskytuje architekturu pro klasifikaci uživatelů a IT prostředků. Tato architektura umožňuje explicitně vyjádřit jejich vztah a přístupová práva, která jsou v souladu s touto klasifikací vhodná. Například přiřazením atributů uživatele, které určují pracovní pozici uživatele a přiřazení projektu, může být uživateli udělen přístup k nástrojům potřebným pro práci uživatele a datům, které uživatel potřebuje k přispívání do konkrétního projektu. Když uživatel předpokládá jinou úlohu a různá přiřazení projektu, změna atributů, které určují pracovní pozici a projekty uživatele, automaticky zablokuje přístup k prostředkům požadovaným pouze pro předchozí pozici uživatelů.
V Microsoft Entra ID můžete použít modely rolí několika způsoby, jak spravovat přístup ve velkém prostřednictvím zásad správného řízení identit.
- Přístupové balíčky můžete použít k reprezentaci organizačních rolí ve vaší organizaci, jako je například "obchodní zástupce". Přístupový balíček představující danou organizační roli by zahrnoval všechna přístupová práva, která může obchodní zástupce obvykle potřebovat v rámci více prostředků.
- Aplikace mohou definovat své vlastní role. Pokud jste například měli prodejní aplikaci a tato aplikace obsahovala v manifestu roli "prodejce", můžete tuto roli zahrnout z manifestu aplikace do přístupového balíčku. Aplikace můžou také používat skupiny zabezpečení ve scénářích, kdy uživatel může mít současně více rolí specifických pro aplikaci.
- Role můžete použít k delegování přístupu pro správu. Pokud máte katalog pro všechny přístupové balíčky potřebné prodejem, můžete někomu, kdo bude za tento katalog zodpovědný, tím, že mu přiřadíte roli specifickou pro katalog.
Tento článek popisuje, jak modelovat role organizace pomocí přístupových balíčků pro správu nároků, abyste mohli migrovat definice rolí do Microsoft Entra ID a vynutit přístup.
Migrace modelu role organizace
Následující tabulka ukazuje, jak koncepty v definicích rolí organizace, se kterými byste mohli být obeznámeni v jiných produktech, odpovídají možnostem správy nároků.
| Koncept modelování rolí organizace | Reprezentace ve správě nároků |
|---|---|
| Delegovaná správa rolí | Delegování na tvůrce katalogu |
| Kolekce oprávnění napříč jednou nebo více aplikacemi | Vytvoření přístupového balíčku s rolemi prostředků |
| Omezení doby trvání přístupu, která role poskytuje | Nastavení životního cyklu zásad přístupového balíčku tak, aby měla datum vypršení platnosti |
| Individuální přiřazení k roli | Vytvoření přímého přiřazení přístupového balíčku |
| Přiřazení rolí uživatelům na základě vlastností (například jejich oddělení) | Vytvoření automatického přiřazení přístupového balíčku |
| Uživatelé můžou požádat o roli a schválit ji. | Konfigurace nastavení zásad pro uživatele, kteří můžou požádat o přístupový balíček |
| Opětovná certifikace členů rolí v accessu | Nastavení kontroly opakovaného přístupu v zásadách přístupového balíčku |
| Oddělení povinností mezi rolemi | Definování dvou nebo více přístupových balíčků jako nekompatibilních |
Organizace může mít například existující model role organizace podobný následující tabulce.
| Název role | Oprávnění, která role poskytuje | Automatické přiřazení k roli | Přiřazení na základě žádosti k roli | Oddělení kontrol povinností |
|---|---|---|---|---|
| Prodejce | Člen prodejního týmu | Yes | No | Nic |
| Sales Solution Manager | Oprávnění prodejce a role aplikace Správce řešení v aplikaci Sales | Nic | Prodejce může požádat, vyžaduje schválení manažera a čtvrtletní kontrolu. | Žadatel nemůže být manažerem obchodního účtu. |
| Sales Account Manager | Oprávnění prodejce a role aplikace Správce účtů v aplikaci Sales | Nic | Prodejce může požádat, vyžaduje schválení manažera a čtvrtletní kontrolu. | Žádost nemůže být manažerem prodejního řešení. |
| Sales Support | Stejná oprávnění jako prodejce | Nic | Kdokoli, kdo není prodejcem, může požádat, vyžaduje schválení nadřízenýho a čtvrtletní kontrolu. | Žadatel nemůže být prodejcem |
To může být reprezentováno v zásadách správného řízení id Microsoft Entra jako katalog přístupových balíčků obsahující čtyři přístupové balíčky.
| Přístupový balíček | Role zdrojů | Zásady | Nekompatibilní přístupové balíčky |
|---|---|---|---|
| Prodejce | Člen prodejního týmu | Automatické přiřazení | |
| Sales Solution Manager | Role aplikace Správce řešení v aplikaci Sales | Založené na žádostech | Sales Account Manager |
| Sales Account Manager | Role aplikace Správce účtů v aplikaci Sales | Založené na žádostech | Sales Solution Manager |
| Sales Support | Člen prodejního týmu | Založené na žádostech | Prodejce |
Další části popisují proces migrace a vytvoří artefakty zásad správného řízení Microsoft Entra ID a Microsoft Entra ID pro implementaci ekvivalentního přístupu modelu role organizace.
Připojení aplikací, jejichž oprávnění se odkazují v rolích organizace na ID Microsoft Entra
Pokud se vaše organizační role používají k přiřazení oprávnění, která řídí přístup k aplikacím SaaS jiných než Microsoftu, místním aplikacím nebo vašim vlastním cloudovým aplikacím, budete muset aplikace připojit k Microsoft Entra ID.
Aby přístupový balíček představující organizační roli mohl odkazovat na role aplikace jako oprávnění, která mají být součástí role, pro aplikaci, která má více rolí a podporuje moderní standardy, jako je SCIM, byste měli aplikaci integrovat s Microsoft Entra ID a zajistit, aby role aplikace byly uvedené v manifestu aplikace.
Pokud má aplikace jenom jednu roli, měli byste aplikaci přesto integrovat s ID Microsoft Entra. U aplikací, které nepodporují SCIM, může Microsoft Entra ID zapisovat uživatele do existujícího adresáře aplikace nebo databáze SQL nebo přidat uživatele AD do skupiny AD.
Naplnění schématu Microsoft Entra používaných aplikacemi a pro pravidla oborů uživatelů v rolích organizace
Pokud definice vaší role obsahují příkazy formuláře "všichni uživatelé s těmito hodnotami atributů se přiřadí k roli automaticky" nebo "uživatelé s těmito hodnotami atributů mohou požadovat", budete muset zajistit, aby tyto atributy byly přítomné v Microsoft Entra ID.
Schéma Microsoft Entra můžete rozšířit a pak tyto atributy naplnit buď z místní služby AD, přes Microsoft Entra Connect, nebo z personálního systému, jako je Workday nebo SuccessFactors.
Vytváření katalogů pro delegování
Pokud je průběžná údržba rolí delegovaná, můžete delegovat správu přístupových balíčků vytvořením katalogu pro každou část organizace, na kterou delegujete.
Pokud máte k vytvoření více katalogů, můžete k vytvoření jednotlivých katalogů použít skript PowerShellu.
Pokud neplánujete delegovat správu přístupových balíčků, můžete přístupové balíčky ponechat v jednom katalogu.
Přidání prostředků do katalogů
Teď, když jste identifikovali katalogy, přidejte do katalogů aplikace, skupiny nebo weby , které jsou zahrnuté v přístupových balíčcích představujících role organizace.
Pokud máte mnoho prostředků, můžete pomocí skriptu PowerShellu přidat každý prostředek do katalogu. Další informace najdete v tématu Vytvoření přístupového balíčku ve správě nároků pro aplikaci s jednou rolí pomocí PowerShellu.
Vytvoření přístupových balíčků odpovídajících definicem rolí organizace
Každá definice role organizace může být reprezentována přístupovým balíčkem v daném katalogu.
K vytvoření přístupového balíčku v katalogu můžete použít skript PowerShellu.
Jakmile vytvoříte přístupový balíček, propojit jednu nebo více rolí prostředků v katalogu s přístupovým balíčkem. Představuje oprávnění role organizace.
Kromě toho vytvoříte zásadu pro přímé přiřazení v rámci tohoto přístupového balíčku, který se dá použít ke sledování uživatelů, kteří už mají jednotlivá přiřazení rolí organizace.
Vytvoření přiřazení přístupového balíčku pro existující přiřazení jednotlivých rolí organizace
Pokud někteří z vašich uživatelů už mají členství v rolích organizace, že by nedostali prostřednictvím automatického přiřazení, měli byste pro tyto uživatele vytvořit přímá přiřazení k odpovídajícím přístupovým balíčkům.
Pokud máte mnoho uživatelů, kteří potřebují přiřazení, můžete každému uživateli přiřadit přístupový balíček pomocí skriptu PowerShellu. Tím se propojí uživatelé se zásadami přímého přiřazení.
Přidání zásad do přístupových balíčků pro automatické přiřazení
Pokud definice role organizace obsahuje pravidlo založené na atributech uživatele, které automaticky přiřadí a odebere přístup na základě těchto atributů, můžete to vyjádřit pomocí zásad automatického přiřazení. Přístupový balíček může mít maximálně jednu zásadu automatického přiřazení.
Pokud máte mnoho definic rolí, které mají každou definici role, můžete pomocí skriptu PowerShellu vytvořit každou zásadu automatického přiřazení v každém přístupovém balíčku.
Nastavení přístupových balíčků jako nekompatibilních pro oddělení povinností
Pokud máte oddělená omezení povinností, která uživateli brání v převzetí jedné organizační role, pokud už mají jinou, můžete uživateli zabránit v vyžádání přístupu ve správě nároků tím , že tyto kombinace přístupových balíčků označíte jako nekompatibilní.
Pro každý přístupový balíček, který má být označen jako nekompatibilní s jiným, můžete pomocí skriptu PowerShellu nakonfigurovat přístupové balíčky jako nekompatibilní.
Přidání zásad pro přístup k balíčkům, aby si uživatelé mohli vyžádat
Pokud uživatelé, kteří ještě nemají organizační roli, můžou požádat o roli a schválit ji, aby ji mohli převzít, můžete také nakonfigurovat správu nároků tak, aby uživatelům umožňovala požádat o přístupový balíček. Do přístupového balíčku můžete přidat další zásady a v každé zásadě určete, kteří uživatelé můžou požádat a kdo musí schválit.
Konfigurace kontrol přístupu v zásadách přiřazení přístupového balíčku
Pokud vaše organizační role vyžadují pravidelnou kontrolu jejich členství, můžete nakonfigurovat opakované kontroly přístupu v zásadách založených na požadavcích a přímém přiřazení.