你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
标识和访问管理
本文介绍标识和访问管理的设计注意事项和建议。 它专注于在 Microsoft Azure 上部署云规模分析平台。 由于云规模分析是一项任务关键型元素，因此设计中还应包含有关 Azure 登陆区域设计方面的指南。
本文基于有关 Azure 登陆区域的注意事项和建议。 有关详细信息，请参阅标识和访问管理。
数据登陆区域设计
云规模分析支持使用 Microsoft Entra 标识的访问控制模型。 该模型同时使用 Azure 基于角色的访问控制 (Azure RBAC) 和访问控制列表 (ACL)。
请查看团队执行的 Azure 管理活动。 考虑在 Azure 上进行云规模分析。 确定组织中可能的最佳责任分配。
角色分配
为了在数据平台中自主开发、交付和提供数据产品，数据应用程序团队在 Azure 环境中需要很少的访问权限。 在讨论各自的 RBAC 要求之前，必须强调不同的访问模型应该用于开发和更高级环境。 此外，应尽可能使用安全组来减少角色分配的数量并简化 RBAC 权限的管理和评审过程。 这很关键，因为每个订阅可以创建的角色分配数量有限。
应允许开发团队及其各自的用户标识访问开发环境，以使其能够更快地迭代、了解 Azure 服务中的某些功能并有效地解决问题。 在开发或增强基础结构即代码 (IaC) 和其他代码项目时，访问开发环境将有所帮助。 一旦开发环境中的实现按预期工作，它就可以持续推广到更高级环境。 更高级环境（例如测试和生产环境）应仅面向数据应用程序团队。 只有服务主体应具有对这些环境的访问权限，因此必须使用 CI/CD 管道通过服务主体标识执行所有部署。 总而言之，在开发环境中，访问权限应该提供给服务主体和用户标识，而在更高级环境中，只能向服务主体标识提供访问权限。
为了能够在数据应用程序资源组内的资源之间创建资源和角色分配，必须提供 Contributor 和 User Access Administrator 权限。 这将允许团队在 Azure Policy 边界内的环境中创建和控制服务。 云规模分析建议使用专用终结点来克服数据外泄风险，并且由于 Azure 平台团队应通过策略阻止其他连接选项，数据应用程序团队将需要访问数据登陆区域的共享虚拟网络的权限，以能够为其计划使用的服务成功设置所需的网络连接。 为了遵循最小权限原则，克服不同数据应用程序团队之间的冲突并明确区分团队，云规模分析建议为每个数据应用程序团队创建一个专用子网，并为该子网创建一个 Network Contributor 角色分配（子资源范围）。 此角色分配允许团队使用专用终结点加入子网。
这两个最初的角色分配将支持在这些环境中自助部署数据服务。 为解决成本管理问题，组织应向资源组添加成本中心标记，以实现交叉收费和分布式成本所有权。 这提高了团队内部的意识，并强制其就所需的 SKU 和服务层做出正确的决策。
如果还要能够自助使用数据登陆区域内的其他共享资源，需要一些额外的角色分配。 如果需要访问 Databricks 环境，组织应使用 Microsoft Entra ID 中的 SCIM Synch 提供访问权限。 这一点很重要，因为此机制会自动将用户和组从 Microsoft Entra ID 同步到 Databricks 数据平面，并在个人离开组织或业务时自动删除访问权限。 如果在 Azure Databricks 中使用单独的用户帐户，则不会出现这种情况。 数据应用程序团队应添加到 Databricks 工作区中 shared-product-rg 和工作区中 shared-integration-rg。 在 Azure Databricks 中，应向数据应用程序团队授予对预定义群集的 Can Restart 访问权限，以便能够在工作区中运行工作负载。
各个团队将需要访问中心 Purview 帐户以发现各自数据登陆区域内的数据资产。 因此，必须将团队作为 Data Reader 添加到 Purview 顶级集合中。 此外，在大多数情况下，团队需要选择编辑其拥有的编录数据资产，以提供额外的详细信息，例如数据所有者和专家的联系方式，以及数据集中列描述和所含信息的更精细的详细信息。
关于基于角色的访问控制要求的总结
为了自动化部署数据登陆区域，需要以下角色：
角色名称
说明
范围
将所有数据服务的所有专用 DNS 区域部署到单个订阅和资源组中。 服务主体需要是在数据管理登陆区域部署期间创建的全局 DNS 资源组上的 Private DNS Zone Contributor。 部署专用终结点的 A 记录时需要此角色。
（资源组范围）/subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
为了在数据登陆区域网络和数据管理登陆区域网络之间设置虚拟网络对等互连，服务主体需要对远程虚拟网络的资源组具有 Network Contributor 访问权限。
（资源组范围）/subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
需要此权限才能与其他数据工厂共享部署到 integration-rg 资源组的自承载集成运行时。 还需要在相应的存储帐户文件系统上分配 Azure 数据工厂和 Azure Synapse Analytics 托管标识访问权限。
（资源范围）/subscriptions/{{dataLandingZone}subscriptionId}
注意
可以在生产方案中减少角色分配数。 仅当在数据管理登陆区域和数据登陆区域之间设置虚拟网络对等互连时，才需要 Network Contributor 角色分配。 如果不考虑这一点，DNS 解析将不起作用。 入站和出站流量会被删除，因为无法访问 Azure 防火墙。
如果通过具有 deployIfNotExists 效果的 Azure 策略自动部署专用终结点的 DNS A 记录，则也不需要 Private DNS Zone Contributor。 对于 User Access Administrator 也是如此，因为可以使用 deployIfNotExists 策略执行自动部署。
数据产品的角色分配
在数据登陆区域内部署数据产品时需要以下角色分配：
角色名称
说明
范围
将所有数据服务的所有专用 DNS 区域部署到单个订阅和资源组中。 服务主体需要是在数据管理登陆区域部署期间创建的全局 DNS 资源组上的 Private DNS Zone Contributor。 部署相应的专用终结点的 A 记录时需要此角色。
（资源组范围）/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
将所有数据集成流式处理服务部署到数据登陆区域订阅内的单个资源组中。 服务主体需要对该资源组进行 Contributor 角色分配。
（资源组范围）/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
为了将专用终结点部署到在数据登陆区域部署期间创建的指定专用链接子网，服务主体需要对该子网具有 Network Contributor 访问权限。
（子资源范围）/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
访问其他资源
在 Azure 之外，数据产品和数据集成团队还需要访问存储库来存储代码项目、有效协作并通过 CI/CD 持续向更高环境推出更新和更改。 此外，还应提供项目板，以便实现敏捷开发、冲刺规划、跟踪任务以及用户反馈和功能请求。
最后，CI/CD 自动化需要设置与 Azure 的连接，该连接通过服务主体在大多数服务中完成。 因此，团队将需要访问服务主体以在其项目中实现自动化。
管理对数据的访问
应使用 Microsoft Entra 组管理对数据的访问权限。 将用户主体名称或服务主体名称添加到 Microsoft Entra 组。 将组添加到服务，并授予对组的权限。 此方法可实现精细访问控制。
对于 Azure 数据湖中的数据产品，请考虑使用访问控制列表 (ACL)。 有关详细信息，请参阅 Azure Data Lake Storage Gen2 中的访问控制模型。 大多数本机 Azure 服务都支持将 Microsoft Entra 直通与访问控制列表配合使用，包括 Azure 机器学习、Azure Synapse SQL Serverless、Apache Spark for Azure Synapse 和 Azure Databricks。
其他多语言存储可能会用于云规模分析。 示例包括 Azure Database for PostgreSQL、Azure Database for MySQL、Azure SQL 数据库、SQL 托管实例和 Azure Synapse SQL 专用池。 数据应用程序团队可以使用它们来存储数据产品。
- 使用 Microsoft Entra ID 通过 Azure Database for PostgreSQL 进行身份验证
- 将 Microsoft Entra 身份验证与 Azure SQL 数据库、SQL 托管实例 和 Azure Synapse Analytics 配合使用
- 使用 Microsoft Entra ID 通过 Azure Database for MySQL 进行身份验证
建议使用 Microsoft Entra 组来保护数据库对象，而不是单独的 Microsoft Entra 用户帐户。 这些 Microsoft Entra 组用于对用户进行身份验证并帮助保护数据库对象。 与 Data Lake 模式类似，可以使用加入域或数据产品在 Microsoft Entra 服务中创建这些组。
此方法还提供了一个单一的管理位置，并可以在 Azure Graph 中查看访问权限。
有关如何提高数据管理登陆区域和管理数据资产的数据登陆区域的安全性的详细信息，请参阅在 Azure 中为云规模分析提供安全性。