事件中心的共享访问签名授权

共享访问签名（SAS）提供了一种授予对事件中心命名空间中资源的有限访问权限的方法。 SAS 基于授权规则保护对事件中心资源的访问。 可以在命名空间或事件中心上配置这些规则。 本文概述了 SAS 模型并查看 SAS 最佳做法。

什么是共享访问签名？

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

SAS 是使用简单令牌的基于声明的授权机制。 使用 SAS 时，永远不会在网络上传递密钥。 而是使用密钥对服务稍后可以验证的信息进行加密签名。 可以使用类似于用户名和密码方案的 SAS，其中客户端立即拥有授权规则名称和匹配密钥。 还可以使用类似于联合安全模型的 SAS，客户端从安全令牌服务接收受时间限制且已签名的访问令牌，而无需拥有签名密钥。

共享访问授权策略

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

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

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

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

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

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

创建事件中心命名空间时，会自动为命名空间创建名为 RootManageSharedAccessKey 的策略规则。 此策略具有整个命名空间的“管理”权限。 像管理根帐户一样对待此规则，并且不要在应用程序中使用它。 可以通过 PowerShell 或 Azure CLI 在门户中命名空间的 Configure 选项卡中创建更多策略规则。

使用 SAS 的最佳实践

在应用程序中使用共享访问签名时，请注意两个潜在风险：

• 如果 SAS 泄漏，任何获得它的人都可以使用它，这可能会损害 Event Hubs 资源。
• 如果提供给客户端应用程序的 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 更灵活地访问资源，且不会损害应用程序的安全性。

相关内容

请参阅以下相关文章：

• 使用共享访问签名对 Azure 事件中心的请求进行身份验证
• 使用 Microsoft Entra ID 对来自应用程序的 Azure 事件中心的请求进行身份验证
• 使用 Microsoft Entra ID 对托管标识进行身份验证以访问事件中心资源