你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 中云规模分析的身份验证
身份验证是验证用户或应用程序标识的过程。 首选单一来源标识提供程序，这种提供程序可处理身份管理和身份验证。 这种提供程序称为目录服务。 它提供了存储目录数据并使这些数据可供网络用户和管理员使用的方法。
任何数据湖解决方案都应该使用并与已经在使用的目录服务集成。 对于大多数组织，Active Directory 是所有与标识相关的服务的目录服务。 它是所有服务和用户帐户的主要集中式数据库。
在云中，Microsoft Entra ID 是集中式标识提供者，也是标识管理的首选源。 将身份验证和授权委派给 Microsoft Entra ID 可启用要求用户位于特定位置的条件访问策略等方案。 它支持多因素身份验证，可提高访问安全级别。 尽可能使用 Microsoft Entra 集成配置 Data Lake 数据存储服务。
对于不支持 Microsoft Entra ID 的数据服务，请使用访问密钥或令牌进行身份验证。 客户端应将访问密钥存储在密钥管理存储中，例如 Azure 密钥保管库。
云规模分析的身份验证方案包括：
- 用户身份验证
- 应用程序和服务到服务的身份验证
用户身份验证
连接到数据服务或资源的用户必须出示凭据。 此凭据证明用户就是他们声称的人。 然后，他们便可以访问服务或资源。 身份验证还允许服务知晓用户的身份。 该服务决定用户在身份验证后可以查看的内容和执行的操作。
Azure Data Lake 存储 Gen2、Azure SQL 数据库 和 Azure Synapse 支持 Microsoft Entra 集成。 交互式用户身份验证模式要求用户在对话框中提供凭据。
重要
不要将用户凭据硬编码到应用程序中来进行身份验证。
应用程序和服务到服务的身份验证
这些请求未与特定用户关联，或者没有可用于输入凭据的用户。
服务到服务身份验证
即使一个服务在没有人工交互的情况下访问另一个服务，该服务也必须提供一个有效的身份。 这个身份证明服务是真实的。 被访问的服务可以使用身份来决定服务可以执行哪些操作。
对于服务到服务的身份验证，验证 Azure 服务的首选方法是托管标识。 Azure 资源的托管标识允许向任何支持 Microsoft Entra 身份验证的服务进行身份验证，而无需任何显式凭据。 有关详细信息，请参阅什么是 Azure 资源的托管标识。
托管标识是服务主体，它们只能与 Azure 资源配合使用。 例如，可以直接为 Azure 数据工厂实例创建托管标识。 此托管标识是注册到 Microsoft Entra ID 的对象。 它表示此数据工厂实例。 然后，此标识可用于对任何服务（例如 Data Lake Storage）进行身份验证，而无需在代码中提供任何凭据。 Azure 负责处理服务实例使用的凭据。 该标识可以授予对 Azure 服务资源的授权，例如 Azure Data Lake Storage 中的文件夹。 删除此数据工厂实例时，Azure 会清理 Microsoft Entra ID 中的标识。
使用托管标识的优势
托管标识应用于向另一个 Azure 服务或资源验证 Azure 服务。 它们具有以下优势：
- 托管标识表示为其创建的服务。 并非表示交互式用户。
- 托管标识凭据在 Microsoft Entra ID 中维护、管理和存储。 用户无需保留密码。
- 使用托管身份，客户端服务不使用密码。
- 删除服务实例时，系统分配的托管标识将被删除。
这些好处意味着凭据登录区域保护更充分，安全性泄露的可能性更小。
应用程序到服务身份验证
另一种访问方案是应用程序（例如移动 Web 应用程序）访问 Azure 服务。 无论谁访问 Azure 服务，访问者都必须提供其标识并且系统必须验证该身份。
对于不支持使用托管标识向 Azure 进行身份验证的应用程序和服务来说，替代方案是 Azure 服务主体。 Azure 服务主体是为与应用程序、托管服务和自动化工具配合使用以访问 Azure 资源而创建的标识。 此访问权限受分配给服务主体的角色的限制。 出于安全原因，我们建议将服务主体与自动化工具或应用程序一起使用，而不是允许它们使用用户身份登录。 有关详细信息，请参阅 Microsoft Entra ID 中的应用程序和服务主体对象。
注意
托管标识和服务主体仅在 Microsoft Entra ID 中创建和维护。
托管标识和服务主体之间的区别
| 服务主体 | 托管的标识 |
|---|---|
| 在 Microsoft Entra ID 中手动创建的安全标识，供应用程序、服务和工具用来访问特定 Azure 资源。 | 一种特殊类型的服务主体。 是在创建 Azure 服务时创建的自动标识。 |
| 可以由任何应用程序或服务使用。 不会绑定到特定的 Azure 服务。 | 表示 Azure 服务实例本身。 不能用于表示其他 Azure 服务。 |
| 具有独立的生命周期。 你必须显式将其删除。 | 删除 Azure 服务实例时自动将其删除。 |
| 基于密码或基于证书的身份验证。 | 无需为身份验证提供显式密码。 |
数据库身份验证和权限
云规模分析可能包含多语言存储。 示例包括 PostgreSQL、MySQL、Azure SQL 数据库、SQL 托管实例和 Azure Synapse Analytics。
- 使用 Microsoft Entra ID 通过 PostgreSQL 进行身份验证
- 将 Microsoft Entra 身份验证与 Azure SQL 数据库、SQL 托管实例 和 Azure Synapse Analytics 配合使用
- 使用 Microsoft Entra ID 通过 MySQL 进行身份验证
建议使用 Microsoft Entra 组来保护数据库对象，而不是单独的 Microsoft Entra 用户帐户。 使用这些 Microsoft Entra 组对用户进行身份验证和保护数据库对象。 与数据湖模式类似，你可以使用数据应用程序加入来创建这些组。
注意
数据应用程序可以将敏感数据产品存储在 Azure SQL 数据库、SQL 托管实例或 Azure Synapse Analytics 池中。 有关详细信息，请参阅敏感数据。
云规模分析中的 Azure Data Lake 安全性
要控制对数据湖中数据的访问，我们建议在文件和文件夹级别使用访问控制列表 (ACL)。 Azure Data Lake 还采用了类似 POSIX 的访问控制列表模型。 POSIX（便携式操作系统接口）是一系列操作系统标准。 一个标准定义了一种简单但功能强大的权限结构，用于访问文件和文件夹。 POSIX 已被广泛用于网络文件共享和 Unix 计算机。
与 Azure RBAC 一般做法类似，以下规则应适用于 ACL：
使用组管理访问权限。 分配对 Microsoft Entra 组的访问权限并管理组的成员身份，以便进行持续访问管理。 请参阅 Azure Data Lake Storage 中的访问控制和数据湖配置。
最低特权。 在大多数情况下，用户应该只对数据湖中所需的文件夹和文件具有读取权限。 托管标识或服务主体（例如 Azure 数据工厂使用的主体）具有读取、写入和执行权限。 数据用户不应具备访问存储帐户容器的访问权限。
与数据分区方案一致。 ACL 和数据分区设计必须保持一致，以确保有效的数据访问控制。 有关详细信息，请参阅 [数据湖分区]。