通过

使用共享访问签名授权访问事件中心资源

  • 项目

使用共享访问签名 (SAS) 可以授予对事件中心命名空间中的资源的受限访问权限。 SAS 基于授权规则保护对事件中心资源的访问。 这些规则是针对命名空间或事件中心配置的。 本文提供 SAS 模型的概述，并探讨 SAS 最佳做法。

注意

本文介绍如何使用 SAS 授权访问事件中心资源。 若要了解如何使用 SAS 授权访问事件中心资源，请参阅使用 SAS 进行身份验证。

什么是共享访问签名？

共享访问签名 (SAS) 基于授权规则提供对事件中心资源的委托访问权限。 授权规则具有与特定权限关联的名称，并包含一个加密密钥对。 可以通过事件中心客户端或者在自己的代码中使用规则名称和密钥生成 SAS 令牌。 然后，客户端可将令牌传递给事件中心，以证明请求的操作获得授权。

SAS 是使用简单令牌的基于声明的授权机制。 使用 SAS 时，永远不会通过网络传递密钥。 密钥用于以加密方式将信息签名，以后，服务可以验证这些信息。 可以像使用用户名和密码一样使用 SAS。在用户名和密码方案中，客户端直接拥有授权规则名称和匹配的密钥。 可以像在联合安全模型中一样使用 SAS。在此模型中，客户端从安全令牌服务接收限时且经过签名的访问令牌，而无需拥有签名密钥。

注意

Azure 事件中心还支持使用 Microsoft Entra ID 授权事件中心资源。 使用 Microsoft Entra ID 返回的 OAuth 2.0 令牌的授权用户或应用程序可提供比共享访问签名 (SAS) 更高的安全性和易用性。 使用 Microsoft Entra ID，不需要在代码中存储令牌，也不需要承担潜在的安全漏洞风险。

Microsoft 建议尽量对 Azure 事件中心应用程序使用 Microsoft Entra ID。 有关详细信息，请参阅使用 Microsoft Entra ID 授权访问 Azure 事件中心资源。

重要

若要保护资源，SAS（共享访问签名）令牌至关重要。 在提供粒度的同时，SAS 可以授予客户端访问事件中心资源的权限。 不应公开共享这些资源。 如果出于故障排除原因而需要共享，请考虑使用日志文件的化简版本或者将 SAS 令牌从日志文件中删除（如果存在），并确保屏幕截图也不包含 SAS 信息。

共享访问授权策略

每个事件中心命名空间和事件中心实体（事件中心或 Kafka 主题）都有一个由规则构成的共享访问授权策略。 命名空间级别的策略应用到该命名空间中的所有实体，不管这些实体各自的策略配置如何。

对于每个授权策略规则，需要确定三个信息片段：名称、范围和权限。 名称是该范围内的唯一名称。 范围是相关资源的 URI。 对于事件中心命名空间，范围是完全限定的域名 (FQDN)，例如 https://<yournamespace>.servicebus.chinacloudapi.cn/。

策略规则提供的权限可以是以下各项的组合：

  • 发送 - 向实体授予发送消息的权限
  • 侦听 - 授权侦听实体或从实体接收消息
  • 管理 - 授予管理命名空间的拓扑的权限，包括创建和删除实体。 “管理”权限包括“发送”和“侦听”权限。

一个命名空间或实体策略最多可以包含 12 个共享访问授权规则，为三组规则提供空间。其中每个规则涵盖了基本权限，以及“发送”和“侦听”权限的组合。 根据此项限制，很明显 SAS 策略存储并不适合用作用户或服务帐户存储。 如果应用程序需要根据用户或服务标识授予事件中心资源的访问权限，应实现安全令牌服务，以便在执行身份验证和访问检查后颁发 SAS 令牌。

将为授权规则分配“主要密钥”和“辅助密钥”。 这些密钥是加密形式的强密钥。 请不要遗失或透漏这些密钥。 在 Azure 门户中总要用到它们。 可以使用其中一个生成的密钥，并且随时可以重新生成密钥。 如果重新生成或更改策略中的密钥，以前基于该密钥颁发的所有令牌会立即失效。 但是，基于此类令牌创建的现有连接会继续工作，直到该令牌过期。

创建事件中心命名空间时，系统会自动为该命名空间创建名为 RootManageSharedAccessKey 的策略规则。 此策略具有整个命名空间的“管理”权限。 建议将此规则视为 root 管理帐户，且不要在应用程序中使用它。 可以通过门户上命名空间的“配置”选项卡、PowerShell 或 Azure CLI 创建更多策略规则。

使用 SAS 的最佳实践

在应用程序中使用共享访问签名时，需要知道以下两个可能的风险：

  • 如果 SAS 泄露，则获取它的任何人都可以使用它，这可能会使事件中心资源遭到入侵。
  • 如果提供给客户端应用程序的 SAS 到期，并且应用程序无法从服务检索新 SAS，则可能会影响该应用程序的功能。

下面这些针对使用共享访问签名的建议可帮助降低这些风险：

  • 如果需要，让客户端自动续订 SAS：客户端应在到期时间之前很久就续订 SAS，这样，即使提供 SAS 的服务不可用，客户端也有时间重试。 如果 SAS 旨在用于少量即时的短期操作，这些操作应在到期时间内完成，则上述做法可能是不必要的，因为不应续订 SAS。 但是，如果客户端定期通过 SAS 发出请求，则有效期可能就会起作用。 需要考虑的主要方面就是在以下两者间进行权衡：对短期 SAS 的需求（如前文所述）以及确保客户端尽早请求续订（以免在成功续订前因 SAS 到期而中断）。
  • 注意 SAS 开始时间：如果将 SAS 的开始时间设置为“现在”，则由于时钟偏移（因计算机不同而存在的当前时间差异），在前几分钟可能会间歇地观察到失败。 通常，将开始时间至少设置为 15 分钟前。 或者根本不设置，这会使它在所有情况下都立即生效。 同样的原则也适用于过期时间。 请记住，对于任何请求，在任一方向你可能会观察到最多 15 分钟的时钟偏移。
  • 对要访问的资源要具体：一种安全性最佳做法是向用户提供所需最小权限。 如果某一用户仅需要对单个实体的读取访问权限，则向该用户授予对该单个实体的读取访问权限，而不要授予针对所有实体的读取/写入/删除访问权限。 如果 SAS 泄露，这也有助于降低损失，因为攻击者手中掌握的 SAS 的权限较为有限。
  • 不要总是使用 SAS：有时，与针对事件中心的特定操作相关联的风险要超过 SAS 所带来的好处。 对于此类操作，应创建一个中间层服务，该服务在执行业务规则验证、身份验证和审核后写入事件中心。
  • 始终使用 HTTPs：始终使用 HTTPs 创建或分发 SAS。 如果某一 SAS 通过 HTTP 传递并且被截取，则执行中间人攻击的攻击者将能够读取 SAS、并使用它，就像目标用户本可执行的操作一样，这可能会暴露敏感数据或者使恶意用户能够损坏数据。

结束语

共享访问签名用于向客户端提供对事件中心资源的受限权限。 它们是安全模型中的重要环节，适合使用 Azure 事件中心的任何应用程序。 如果遵循本文中所列的最佳做法，则可以使用 SAS 更灵活地访问资源，且不会损害应用程序的安全性。

相关内容

请参阅以下相关文章：