Sdílet prostřednictvím


Správa identit a přístupu

Tento článek popisuje aspekty návrhu a doporučení pro správu identit a přístupu. Zaměřuje se na nasazení analytické platformy v cloudovém měřítku v Microsoft Azure. Vzhledem k tomu, že analýza na úrovni cloudu je klíčovým prvkem, měly by být do návrhu zahrnuty také pokyny k návrhu cílových zón Azure.

Tento článek vychází z aspektů a doporučení k cílovým zónám Azure. Další informace najdete v tématu Správa identit a přístupu.

Návrh cílové zóny dat

Analýzy na úrovni cloudu podporují model řízení přístupu pomocí identit Microsoft Entra. Model používá řízení přístupu na základě role v Azure (Azure RBAC) i seznamy řízení přístupu (ACL).

Projděte si aktivity správy a správy Azure, které vaše týmy provádějí. Zvažte analýzy v Azure na úrovni cloudu. Určete nejlepší možnou distribuci zodpovědností v rámci vaší organizace.

Přiřazení rolí

Aby bylo možné vyvíjet, dodávat a obsluhovat datové produkty samostatně v rámci datové platformy, vyžadují týmy datových aplikací v rámci prostředí Azure málo přístupových práv. Než začnete s příslušnými požadavky RBAC, musíte zdůraznit, že pro vývoj a vyšší prostředí by se měly používat různé přístupové modely. Skupiny zabezpečení by se také měly používat všude, kde je to možné, aby se snížil počet přiřazení rolí a zjednodušil se proces správy a kontroly práv RBAC. To je důležité kvůli omezenému počtu přiřazení rolí, které je možné vytvořit pro každé předplatné.

Vývojové prostředí by mělo mít přístup vývojovému týmu a jejich příslušným identitám uživatelů, aby bylo možné iterovat rychleji, získat informace o určitých funkcích v rámci služeb Azure a efektivně řešit problémy. Přístup k vývojovému prostředí vám pomůže při vývoji nebo vylepšení infrastruktury jako kódu (IaC) a dalších artefaktů kódu. Jakmile implementace ve vývojovém prostředí funguje podle očekávání, můžete ji průběžně zavádět do vyšších prostředí. Pro tým datových aplikací by se měla uzamknout vyšší prostředí, jako je testování a produžování. K těmto prostředím by měl mít přístup pouze instanční objekt, a proto se všechna nasazení musí spouštět prostřednictvím identity instančního objektu pomocí kanálů CI/CD. Aby bylo možné shrnout, měla by být v přístupových právech vývojového prostředí poskytována instančnímu objektu A identitám uživatelů a ve vyšších přístupových právech prostředí by se měla poskytovat pouze identitě instančního objektu.

Aby bylo možné vytvářet prostředky a přiřazení rolí mezi prostředky v rámci datových skupin Contributor prostředků aplikace a User Access Administrator musí být k dispozici práva. To týmům umožní vytvářet a řídit služby v rámci svého prostředí v rámci hranic služby Azure Policy. Analýzy na úrovni cloudu doporučují použití privátních koncových bodů k překonání rizika exfiltrace dat a vzhledem k tomu, že tým platformy Azure by měl blokovat další možnosti připojení prostřednictvím zásad, týmy datových aplikací budou vyžadovat přístupová práva ke sdílené virtuální síti cílové zóny dat, aby bylo možné úspěšně nastavit požadované síťové připojení pro služby, které plánují používat. Aby bylo možné postupovat podle principu nejnižších oprávnění, překonat konflikty mezi různými týmy datových aplikací a jasně oddělit týmy, analýzy na úrovni cloudu navrhují vytvoření vyhrazené podsítě pro tým datové aplikace a vytvoření Network Contributor přiřazení role k této podsíti (rozsah podřízených prostředků). Toto přiřazení role umožňuje týmům připojit se k podsíti pomocí privátních koncových bodů.

Tato dvě první přiřazení rolí umožní samoobslužné nasazení datových služeb v těchto prostředích. Aby organizace vyřešily problém se správou nákladů, měly by do skupin prostředků přidat značku nákladového střediska, aby bylo možné provádět křížové účtování a vlastnictví distribuovaných nákladů. To zvyšuje povědomí o týmech a vynucuje je, aby se rozhodli, co se týče požadovaných cenových úrovní a úrovní služeb.

Pokud chcete také povolit samoobslužné použití jiných sdílených prostředků v cílové zóně dat, vyžaduje se několik dalších přiřazení rolí. Pokud se vyžaduje přístup k prostředí Databricks, organizace by k poskytnutí přístupu měli použít SCIM Synch z Microsoft Entra ID . Je to důležité, protože tento mechanismus automaticky synchronizuje uživatele a skupiny z Microsoft Entra ID do roviny dat Databricks a automaticky odebere přístupová práva, když jednotlivec opustí organizaci nebo firmu. To se nepovedlo, pokud se v Azure Databricks používají samostatné uživatelské účty. Týmy datových aplikací by měly být přidány do pracovního prostoru Databricks v shared-product-rg a v sadě shared-integration-rg. V Rámci Azure Databricks by týmy datových aplikací měly mít přístupová Can Restart práva k předdefinovanému clusteru, aby mohly spouštět úlohy v rámci pracovního prostoru.

Jednotlivé týmy budou vyžadovat přístup k centrálnímu účtu Purview ke zjišťování datových prostředků v příslušných cílových zónách dat. Týmy proto budou muset být přidány do Data Reader kolekce nejvyšší úrovně Purview. Týmy navíc budou ve většině případů vyžadovat možnost upravit katalogované datové prostředky, které vlastní, aby poskytovaly další podrobnosti, například kontaktní údaje vlastníků dat a odborníků, a také podrobnější podrobnosti o tom, jaké sloupce v datové sadě popisují a jaké informace zahrnují.

Souhrn požadavků na řízení přístupu na základě rolí

Pro účely automatizace nasazení cílových zón dat potřebujete tyto role:

Název role

Popis

Obor

Nasaďte všechny privátní zóny DNS pro všechny datové služby do jednoho předplatného a skupiny prostředků. Instanční objekt musí být Private DNS Zone Contributor v globální skupině prostředků DNS, která byla vytvořena během nasazení cílové zóny správy dat. Tato role se vyžaduje k nasazení záznamů A pro privátní koncové body.

(Rozsah skupiny prostředků) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}

Aby bylo možné nastavit partnerský vztah virtuální sítě mezi sítí cílové zóny dat a sítí cílové zóny správy dat, potřebuje Network Contributor instanční objekt přístupová práva ve skupině prostředků vzdálené virtuální sítě.

(Rozsah skupiny prostředků) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}

Toto oprávnění se vyžaduje ke sdílení místního prostředí Integration Runtime, které se nasadí do integration-rg skupiny prostředků s jinými datovými továrnami. Je také potřeba přiřadit spravované identity Azure Data Factory a Azure Synapse Analytics v příslušných systémech souborů účtu úložiště.

(Rozsah prostředků) /subscriptions/{{dataLandingZone}subscriptionId}

Poznámka:

Počet přiřazení rolí je možné snížit v produkčním scénáři. Přiřazení Network Contributor role se vyžaduje jenom k nastavení partnerského vztahu virtuální sítě mezi cílovou zónou správy dat a cílovou zónou dat. Bez této úvahy nefunguje překlad DNS. Příchozí a odchozí provoz se zahodí, protože není vidět bránu Azure Firewall.

Nevyžaduje se Private DNS Zone Contributor také v případě, že nasazení záznamů DNS A privátních koncových bodů je automatizované prostřednictvím zásad Azure s účinkem deployIfNotExists . Totéž platí i pro to, User Access Administrator že nasazení je možné automatizovat pomocí deployIfNotExists zásad.

Přiřazení rolí pro datové produkty

Pro nasazení datového produktu v cílové zóně dat se vyžadují následující přiřazení rolí:

Název role

Popis

Obor

Nasaďte všechny privátní zóny DNS pro všechny datové služby do jednoho předplatného a skupiny prostředků. Instanční objekt musí být Private DNS Zone Contributor v globální skupině prostředků DNS, která byla vytvořena během nasazení cílové zóny správy dat. Tato role se vyžaduje k nasazení záznamů A pro příslušné privátní koncové body.

(Rozsah skupiny prostředků) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

Nasaďte všechny služby streamování integrace dat do jedné skupiny prostředků v rámci předplatného cílové zóny dat. Instanční objekt vyžaduje přiřazení role pro danou Contributor skupinu prostředků.

(Rozsah skupiny prostředků) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

Aby bylo možné nasadit privátní koncové body do zadané podsítě Private Link, která byla vytvořena během nasazení cílové zóny dat, vyžaduje Network Contributor instanční objekt přístup k této podsíti.

(Obor podřízeného prostředku) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"

Přístup k jiným prostředkům

Mimo Azure budou týmy datového produktu a Integrace Dat také vyžadovat přístup k úložišti pro ukládání artefaktů kódu, efektivně spolupracovat a zavádět aktualizace a změny konzistentně prostřednictvím CI/CD do vyšších prostředí. Kromě toho by měla být poskytována panel projektu, který umožňuje agilní vývoj, plánování sprintů, sledování úkolů a také zpětnou vazbu uživatelů a žádosti o funkce.

Automatizace CI/CD navíc bude vyžadovat nastavení připojení k Azure, které se provádí ve většině služeb prostřednictvím principů služeb. Týmy proto budou vyžadovat přístup k principu služby, aby bylo dosaženo automatizace v rámci svého projektu.

Správa přístupu k datům

Správa přístupu k datům by se měla provádět pomocí skupin Microsoft Entra. Přidejte hlavní názvy uživatelů nebo instanční názvy do skupin Microsoft Entra. Přidejte skupiny do služeb a udělte skupině oprávnění. Tento přístup umožňuje jemně odstupňované řízení přístupu.

U datových produktů v datových jezerech Azure zvažte použití seznamů řízení přístupu (ACL). Další informace najdete v tématu Model řízení přístupu ve službě Azure Data Lake Storage Gen2. Použití předávání Microsoft Entra se seznamy řízení přístupu podporuje většina nativních služeb Azure, včetně Azure Machine Učení, Bezserverové služby Azure Synapse SQL, Apache Spark pro Azure Synapse a Azure Databricks.

Jiné polyglotní úložiště se pravděpodobně použije v analýzách v cloudovém měřítku. Mezi příklady patří Azure Database for PostgreSQL, Azure Database for MySQL, Azure SQL Database, SQL Managed Instance a vyhrazené fondy Azure Synapse SQL. Týmy datových aplikací je můžou používat k ukládání datových produktů.

Doporučujeme používat skupiny Microsoft Entra k zabezpečení databázových objektů místo jednotlivých uživatelských účtů Microsoft Entra. Tyto skupiny Microsoft Entra slouží k ověřování uživatelů a pomáhají chránit databázové objekty. Podobně jako u modelu data Lake můžete k vytvoření těchto skupin ve službě Microsoft Entra použít připojování domén nebo datových produktů.

Tento přístup také poskytuje jedno umístění pro správu a umožňuje kontrolovat přístupová práva v Azure Graphu.

Další informace o tom, jak řídit zabezpečení cílových zón správy dat a cílových zón dat, které spravují vaše datová aktiva, najdete v tématu Zřizování zabezpečení pro analýzy v cloudovém měřítku v Azure.

Další kroky