你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 中云规模分析的授权
授权是指向经过身份验证的一方授予执行某项操作的权限的操作。 访问控制 的主要原则是仅向用户提供执行工作所需的访问权限，并仅允许在特定范围内进行某些操作。 基于角色的安全性对应于访问控制。 许多组织使用基于角色的安全性来控制基于定义的角色或作业功能（而不是单个用户）的访问。 为用户分配了一个或多个安全角色，每个角色都被授予执行特定任务的授权权限。
Microsoft Entra ID 是一个集中式标识提供者，可授予基于 Microsoft Entra 标识访问每个用户或每个应用程序的数据服务和存储的授权。
数据服务授权
Azure 基于角色的访问控制（RBAC）和访问控制列表（ACL）在管理访问并确保安全性方面发挥着关键作用。 Azure RBAC 和 ACL 都要求用户或应用程序在 Microsoft Entra ID 中具有标识。 在云规模分析中，RBAC 对数据库和 Azure Data Lake Storage 有效。 ACL 主要用于 Data Lake Storage，在文件和目录级别提供精细的访问控制。 ACL 通过在存储层次结构中提供更详细的权限来补充 RBAC。
Azure RBAC 提供内置角色，例如 所有者、参与者和 读取者，但也可以根据特定需求创建自定义角色。 以下内置角色是所有 Azure 资源类型（包括 Azure 数据服务）的基础：
| 角色 | 说明 |
|---|---|
| 所有者 | 此角色对资源具有完全访问权限，可以管理有关资源的所有内容，包括授予其访问权限的权限。 |
| 参与者 | 此角色可以管理资源，但不能授予对资源的访问权限。 |
| 读取者 | 此角色可以查看资源和关于资源的信息，但无法查看访问密钥或机密等敏感信息。 它们无法对资源进行任何更改。 |
注意
某些服务具有特定的 RBAC 角色，例如 存储 Blob 数据参与者 或 数据工厂参与者，因此应将这些角色用于这些服务。 RBAC 是一种累加模型，在其中添加角色分配是活动权限。 RBAC 还支持优先于角色分配的拒绝分配。
提示
规划访问控制策略时，建议仅向用户授予执行作业所需的访问权限量。 还应仅允许在特定范围内执行某些操作。
Azure 数据库中的访问控制
Azure 数据库中的 RBAC 围绕角色、作用域和权限展开。 Azure 提供了多个用于数据库管理的内置角色。 其中一个角色是 SQL Server 参与者，它允许管理 SQL 服务器和数据库。 另一个角色是 SQL 数据库贡献者，允许管理 SQL 数据库，但不允许管理服务器本身。 此外，还可以创建自定义角色，这些角色具有满足独特要求的特定权限。
可以在不同的范围内分配角色，包括：
- 在订阅级别，角色应用于订阅中的所有资源。
- 在资源组级别，角色应用于指定资源组中的所有资源。
- 在资源级别，你可以将角色直接分配给单个数据库或服务器。 此方法提供精确的控制。
权限定义了角色可以执行的操作，例如读取、写入、删除或安全设置管理。 这些权限分为角色，以简化管理。
Azure SQL 数据库中，可以将角色分配给用户、组或应用程序来控制访问权限。 例如，可以为数据库管理员分配 SQL Server 参与者 角色来管理服务器和数据库。 SQL 数据库参与者 等角色允许用户创建、更新和删除数据库，而 SQL 安全管理器 角色侧重于安全配置。
Azure Cosmos DB中，可以分配角色来管理对 Azure Cosmos DB 帐户、数据库和容器的访问权限。 Cosmos DB 帐户读取者 和 Cosmos DB 帐户参与者等内置角色 提供不同级别的访问。
在 Azure Database for MySQL、Azure Database for PostgreSQL和 Azure Database for MariaDB中，可以分配角色来管理数据库服务器和单个数据库。 可以使用 参与者 和 读者 等角色来控制访问。
有关详细信息，请参阅 数据库的 Azure 内置角色。
Data Lake Storage 中的访问控制
Azure RBAC 允许向所有存储帐户数据授予粗粒度访问权限，例如读取或写入访问权限。 ACL 允许授予精细访问权限，例如对特定目录或文件的写入访问权限。
在许多情况下，可以使用 RBAC 和 ACL 在 Data Lake Storage 中提供全面的访问控制。 可以使用 RBAC 管理对数据的高级别访问，这有助于确保只有经过授权的用户才能访问该服务。 然后，可以在存储帐户中应用 ACL 来控制对特定文件和目录的访问，从而提高安全性。
Azure 基于属性的访问控制是在 Azure RBAC 的基础上，通过在特定操作的上下文中添加基于属性的角色分配条件来构建的。 它实质上允许你通过添加条件来细化 RBAC 角色分配。 例如，你可以授予对存储帐户中具有特定标记的所有数据对象的读取或写入访问权限。
以下角色允许安全主体访问存储帐户中的数据。
| 角色 | 说明 |
|---|---|
| 存储 Blob 数据所有者 | 此角色提供对 Blob 存储容器和数据的完整访问权限。 此访问权限允许安全主体设置项目的所有者，并修改所有项目的访问控制列表。 |
| 存储 Blob 数据参与者 | 此角色提供对 Blob 存储容器和 Blob 的读取、写入和删除访问权限。 此访问不允许安全主体设置项目的所有权，但可以修改安全主体拥有的项目的访问控制列表（ACL）。 |
| 存储 Blob 数据读取者 | 此角色可以读取和列出存储容器与 Blob。 |
所有者、参与者、读取者和 存储帐户参与者等角色 允许安全主体管理存储帐户，但它们不提供对该帐户中的数据的访问权限。 但是，这些角色（不包括 读取者）可以获取对存储密钥的访问权限，这些密钥可用于各种客户端工具来访问数据。 有关详细信息，请参阅 Data Lake Storage 中的访问控制模型。
Azure Databricks 中的访问控制
Azure Databricks 提供访问控制系统，用于管理 Azure Databricks 环境中的访问。 这些系统侧重于安全对象和数据治理。 Azure Databricks 中的三个主要访问控制系统是：
- ACL，可用于配置访问工作区对象（如笔记本）的权限。 有关详细信息，请参阅访问控制概述。
- 帐户 RBAC，可用于配置使用帐户级对象（例如服务主体和组）的权限。
- Unity 目录，可用于保护和管理数据对象。
除了对对象进行访问控制外，Azure Databricks 还提供平台上的内置角色。 可以将角色分配给用户、服务主体和组。 有关详细信息，请参阅 管理员角色和工作区权利。
云规模分析中的授权最佳做法
本指南讨论在云规模分析环境中实现 RBAC 的最佳做法。 它包括一般 RBAC 原则、数据库访问控制和 Data Lake 访问控制最佳做法，以帮助确保安全高效的资源管理。
云规模分析的一般 RBAC 最佳做法
以下最佳做法可帮助你开始使用 RBAC：
使用 RBAC 角色执行服务管理和操作，并使用特定于服务的角色执行数据访问和与工作负载相关的任务。 使用 Azure 资源上的 RBAC 角色向需要执行资源管理和操作任务的安全主体授予权限。 需要访问存储中数据的安全主体不需要在资源上具备 RBAC 角色，因为他们无需管理资源。 而是直接向数据对象授予权限。 例如，授予对 Data Lake Storage 中的文件夹的读取访问权限，或授予对 SQL 数据库中数据库包含的数据库用户和表权限。
使用内置 RBAC 角色。 首先，使用内置的 RBAC Azure 资源角色来管理服务和分配操作角色以控制访问。 仅当内置角色不满足特定需求时，才为 Azure 资源创建和使用自定义角色。
使用组来管理访问权限。 为 Microsoft Entra 组分配访问权限，并管理组成员资格以进行持续的访问管理。
考虑订阅和资源组范围。 在非生产环境中，应在资源组范围内授予访问权限，以区分服务管理和运营访问需求，而不是对单个资源授予访问权限。 此方法有意义，因为在非生产环境中，开发人员和测试人员需要管理资源。 例如，他们可能需要在 Data Lake Storage 中创建 Azure 数据工厂引入管道或容器。
但是，在生产环境中，对于特定于工作负载的任务（例如数据湖文件系统支持和运营），你可以授予对各个资源的访问权限。 此方法在生产环境中有意义，因为用户只需使用资源，例如查看计划的数据工厂引入管道的状态或读取 Data Lake Storage 中的数据文件。
不要在订阅范围内授予不必要的访问权限。 订阅范围涵盖订阅中的所有资源。
使用最低特权访问。 为该工作选择唯一正确的角色。
数据库访问控制最佳做法
实现有效的 RBAC 对于在分析环境中保持安全性和可管理性至关重要。 本部分提供了使用 Microsoft Entra 组和内置角色的最佳做法，并避免直接用户权限，以帮助确保简化且安全的访问管理过程。
云规模分析环境通常包含多种类型的存储解决方案，包括 PostgreSQL、MySQL、SQL 数据库、Azure SQL 托管实例和 Azure Synapse Analytics。
使用Microsoft Entra 组而不是单个用户帐户。 建议使用 Microsoft Entra 组来保护数据库对象，而不是单独的 Microsoft Entra 用户帐户。 使用 Microsoft Entra 组对用户进行身份验证和保护数据库对象。 与 Data Lake 模式类似，可以使用数据应用程序载入来创建这些组。
使用内置角色管理访问权限。 仅当需要满足特定要求或内置角色授予过多权限时，才创建自定义角色。
避免将权限分配给单个用户。 改为以一致的方式使用角色（例如数据库角色或服务器角色）。 角色能够为报告权限和排查权限问题提供帮助。 Azure RBAC 仅支持通过角色分配权限。
注意
数据应用程序可以将敏感数据产品存储在 SQL 数据库、SQL 托管实例或 Azure Synapse Analytics 池中。 有关详细信息，请参阅 Azure 中云规模分析数据隐私。
Data Lake Storage 访问控制最佳做法
在现代数据环境中，安全高效的访问控制至关重要。 Data Lake Storage 提供可靠的机制来管理通过 ACL 的访问。 本部分概述了在 Data Lake Storage 中实现 RBAC 和应用 ACL、Microsoft Entra 安全组以及维护更安全且可管理的 Data Lake 环境的最小特权原则的最佳做法。 此外，它还突出了将 ACL 与数据分区方案保持一致的重要性，并使用 Azure Databricks 用户的 Unity 目录来帮助确保全面的安全性和治理。
使用 ACL 进行精细的访问控制。 ACL 在定义粒度级别的访问方面发挥了重要作用。 在 Data Lake Storage 中，ACL 使用安全主体来管理对文件和目录的精细访问。
在文件和文件夹级别应用 ACL。 若要控制对 Data Lake 中的数据的访问，建议在文件和文件夹级别使用 ACL。 Data Lake Storage 还采用类似于可移植作系统接口 （POSIX） 的 ACL 模型。 POSIX 是操作系统的一组标准。 一个标准定义了一种简单但功能强大的权限结构，用于访问文件和文件夹。 POSIX 通常用于网络文件共享和 Unix 计算机。
使用 Microsoft Entra 安全组作为 ACL 条目中的指定主体。 如果不直接分配单个用户或服务主体，请使用此方法来添加和删除用户或服务主体，而无需将 ACL 重新应用到整个目录结构。 只需从相应的Microsoft Entra 安全组添加或删除用户和服务主体。
分配对 Microsoft Entra 组的访问权限，并管理组的成员身份，以便进行持续访问管理。 有关详细信息，请参阅 Data Lake Storage 中的访问控制模型。
将最小特权原则应用于 ACL。 在大多数情况下，用户应该只对数据湖中他们所需的文件和文件夹具有读取权限。 数据用户不应具备访问存储帐户容器的访问权限。
将 ACL 与数据分区方案保持一致。 ACL 和数据分区设计必须一致，以帮助确保有效的数据访问控制。 有关详细信息，请参阅数据湖分区。
对于 Azure Databricks 用户，使用 Unity 目录专门控制对数据对象的访问。 授予对 Data Lake Storage 中外部位置存储的直接存储级访问权限不会遵守 Unity Catalog 授予的任何权限或维护的审核。 直接访问绕过了 Unity Catalog 的审核、数据沿袭和其他包括访问控制和权限在内的安全和监控功能。 因此，不应为 Azure Databricks 用户提供对 Unity 目录托管表和卷的直接存储级访问权限。