通过

访问控制概述

  • 项目

适用于：✅Azure 数据资源管理器

访问控制基于身份验证和授权。 针对 Azure 数据资源管理器资源（例如群集或数据库）的每个查询和命令都必须同时通过身份验证和授权检查。

  • 身份验证：验证进行请求的安全主体的标识
  • 授权：验证发出请求的安全主体是否可以对目标资源上发出此请求

身份验证

若要以编程方式进行身份验证，客户端必须与 Microsoft Entra ID 通信，并请求特定于 Kusto 服务的访问令牌。 然后，客户端可以在向数据库发出请求时使用获取的访问令牌作为身份证明。

主要身份验证场景如下所示：

注意

对于用户和应用程序身份验证，建议使用 Kusto 客户端库。 如果需要代表 (OBO) 或单页应用程序 (SPA) 身份验证，则需要直接使用 MSAL，因为客户端库不支持这两种流。 有关详细信息，请参阅使用 Microsoft 身份验证库 (MSAL) 进行身份验证。

用户身份验证

当用户将凭据提供给 Microsoft Entra ID 或者与 Microsoft Entra ID 联合的标识提供者（例如 Active Directory 联合身份验证服务）时，会进行用户身份验证。 用户将获得一个安全令牌，它可提供给 Azure 数据资源管理器服务。 Azure 数据资源管理器会确定令牌是否有效、令牌是否由受信任的颁发者颁发，以及令牌包含哪些安全声明。

Azure 数据资源管理器支持以下用户身份验证方法，包括通过 Kusto 客户端库进行身份验证：

  • 通过用户界面进行登录的交互式用户身份验证。
  • 使用为 Azure 数据资源管理器颁发的 Microsoft Entra 令牌进行用户身份验证。
  • 使用为另一个资源颁发的 Microsoft Entra 令牌进行用户身份验证，其中可使用代表 (OBO) 身份验证将此令牌交换为 Azure 数据资源管理器令牌。

应用程序身份验证

当请求未与特定用户关联，或者没有用户来提供凭据时，需要应用程序身份验证。 在这种情况下，应用程序通过提供机密信息向 Microsoft Entra ID 或进行联合身份验证的 IdP 进行身份验证。

Azure 数据资源管理器支持以下应用程序身份验证方法，包括通过 Kusto 客户端库进行身份验证：

  • 使用 Azure 托管标识进行应用程序身份验证。
  • 使用安装在本地的 X.509v2 证书进行应用程序身份验证。
  • 使用作为字节流提供给客户端库的 X.509v2 证书进行应用程序身份验证。
  • 使用 Microsoft Entra 应用程序 ID 和 Microsoft Entra 应用程序密钥进行应用程序身份验证。 应用程序 ID 和应用程序密钥类似于用户名和密码。
  • 使用之前获得的有效的 Microsoft Entra 令牌（颁发给 Azure 数据资源管理器）进行应用程序身份验证。
  • 使用为另一个资源颁发的 Microsoft Entra 令牌进行应用程序身份验证，其中可使用代表 (OBO) 身份验证将此令牌交换为 Azure 数据资源管理器令牌。

授权

在对资源执行操作之前，所有经过身份验证的用户都必须通过授权检查。 使用 Kusto 基于角色的访问控制模型，其中会将主体分配给一个或多个安全角色。 只要分配给用户的某个角色允许用户执行指定的操作，就可以授予授权。 例如，“数据库用户”角色向安全主体授予读取特定数据库的数据、在数据库中创建表等操作的权限。

安全主体与安全角色的关联可单独进行定义，也可使用 Microsoft Entra ID 中定义的安全组进行定义。 若要详细了解如何分配安全角色，请参阅安全角色概述。

组授权

可以通过向组分配一个或多个角色，向 Microsoft Entra ID 组授予授权。

检查用户或应用程序主体的授权时，系统会首先检查允许特定操作的显式角色分配。 如果不存在此类角色分配，则系统会分析主体在可能授权该操作的所有组中的成员身份。 如果主体被确认为其中任一组的成员，则请求的操作将得到授权。 否则，如果主体不是任何此类组的成员，则操作不会通过授权检查，并且不允许进行该操作。

注意

检查组成员身份可能会占用大量资源。 由于组成员身份不会频繁更改，因此会缓存成员身份检查的结果。 缓存持续时间各不相同，并受成员身份结果（主体是否为成员）、主体类型（用户或应用程序）等因素的影响。 最长缓存持续时间可延长至 3 小时，最小持续时间为 30 分钟。

相关内容