使用共享访问签名授权访问事件中心资源Authorizing access to Event Hubs resources using Shared Access Signatures

使用共享访问签名 (SAS) 可以授予对事件中心命名空间中的资源的受限访问权限。A shared access signature (SAS) provides you with a way to grant limited access to resources in your Event Hubs namespace. SAS 基于授权规则保护对事件中心资源的访问。SAS guards access to Event Hubs resources based on authorization rules. 这些规则是针对命名空间或实体(事件中心或主题)配置的。These rules are configured either on a namespace, or an entity (event hub or topic). 本文提供 SAS 模型的概述,并探讨 SAS 最佳做法。This article provides an overview of the SAS model, and reviews SAS best practices.

什么是共享访问签名?What are shared access signatures?

共享访问签名 (SAS) 基于授权规则提供对事件中心资源的委托访问权限。A shared access signature (SAS) provides delegated access to Event Hubs resources based on authorization rules. 授权规则具有与特定权限关联的名称,并包含一个加密密钥对。An authorization rule has a name, is associated with specific rights, and carries a pair of cryptographic keys. 可以通过事件中心客户端或者在自己的代码中使用规则名称和密钥生成 SAS 令牌。You use the rule’s name and key via the Event Hubs clients or in your own code to generate SAS tokens. 然后,客户端可将令牌传递给事件中心,以证明请求的操作获得授权。A client can then pass the token to Event Hubs to prove authorization for the requested operation.

SAS 是使用简单令牌的基于声明的授权机制。SAS is a claim-based authorization mechanism using simple tokens. 使用 SAS 时,永远不会通过网络传递密钥。Using SAS, keys are never passed on the wire. 密钥用于以加密方式将信息签名,以后,服务可以验证这些信息。Keys are used to cryptographically sign information that can later be verified by the service. 可以像使用用户名和密码一样使用 SAS。在用户名和密码方案中,客户端直接拥有授权规则名称和匹配的密钥。SAS can be used similar to a username and password scheme where the client is in immediate possession of an authorization rule name and a matching key. 可以像在联合安全模型中一样使用 SAS。在此模型中,客户端从安全令牌服务接收限时且经过签名的访问令牌,而无需拥有签名密钥。SAS can be used similar to a federated security model, where the client receives a time-limited and signed access token from a security token service without ever coming into possession of the signing key.

Note

Azure 事件中心支持使用 Azure Active Directory (Azure AD) 对事件中心资源授权。Azure Event Hubs supports authorizing to Event Hubs resources using Azure Active Directory (Azure AD). 使用 Azure AD 返回的 OAuth 2.0 令牌授权用户或应用程序可提供比共享访问签名 (SAS) 更高的安全性和易用性。Authorizing users or applications using OAuth 2.0 token returned by Azure AD provides superior security and ease of use over shared access signatures (SAS). 使用 Azure AD,不需要在代码中存储令牌,也不需要冒潜在的安全漏洞风险。With Azure AD, there is no need to store the tokens in your code and risk potential security vulnerabilities.

Microsoft 建议尽量对 Azure 事件中心应用程序使用 Azure AD。Microsoft recommends using Azure AD with your Azure Event Hubs applications when possible. 有关详细信息,请参阅使用 Azure Active Directory 授权访问 Azure 事件中心资源For more information, see Authorize access to Azure Event Hubs resource using Azure Active Directory.

Important

若要保护资源,SAS(共享访问签名)令牌至关重要。SAS (Shared Access Signatures) tokens are critical to protect your resources. 在提供粒度的同时,SAS 可以授予客户端访问事件中心资源的权限。While providing granularity, SAS grants clients access to your Event Hubs resources. 不应公开共享这些资源。They should not be shared publicly. 如果出于故障排除原因而需要共享,请考虑使用日志文件的化简版本或者将 SAS 令牌从日志文件中删除(如果存在),并确保屏幕截图也不包含 SAS 信息。When sharing, if required for troubleshooting reasons, consider using a reduced version of any log files or deleting the SAS tokens (if present) from the log files, and make sure the screenshots don’t contain the SAS information either.

共享访问授权策略Shared access authorization policies

每个事件中心命名空间和事件中心实体(事件中心实例或 Kafka 主题)都有一个由规则构成的共享访问授权策略。Each Event Hubs namespace and each Event Hubs entity (an event hub instance or a Kafka topic) has a shared access authorization policy made up of rules. 命名空间级别的策略应用到该命名空间中的所有实体,不管这些实体各自的策略配置如何。The policy at the namespace level applies to all entities inside the namespace, irrespective of their individual policy configuration. 对于每个授权策略规则,需要确定三个信息片段:名称、范围和权限。For each authorization policy rule, you decide on three pieces of information: name, scope, and rights. 名称是该范围内的唯一名称。The name is a unique name in that scope. 范围是相关资源的 URI。The scope is the URI of the resource in question. 对于事件中心命名空间,范围是完全限定的域名 (FQDN),例如 https://<yournamespace>.servicebus.chinacloudapi.cn/For an Event Hubs namespace, the scope is the fully qualified domain name (FQDN), such as https://<yournamespace>.servicebus.chinacloudapi.cn/.

策略规则提供的权限可以是以下各项的组合:The rights provided by the policy rule can be a combination of:

  • 发送 - 授予向实体发送消息的权限Send – Gives the right to send messages to the entity
  • 侦听 - 授予侦听或引入实体的权限Listen – Gives the right to listen or receive to the entity
  • 管理 - 授予管理命名空间的拓扑的权限,包括创建和删除实体Manage – Gives the right to manage the topology of the namespace, including creation and deletion of entities

Note

“管理”权限包括“发送”和“侦听”权限。 The Manage right includes the Send and Listen rights.

一个命名空间或实体策略最多可以包含 12 个共享访问授权规则,为三组规则提供空间。其中每个规则涵盖了基本权限,以及“发送”和“侦听”权限的组合。A namespace or entity policy can hold up to 12 shared access authorization rules, providing room for the three sets of rules, each covering the basic rights, and the combination of Send and Listen. 根据此项限制,很明显 SAS 策略存储并不适合用作用户或服务帐户存储。This limit underlines that the SAS policy store isn't intended to be a user or service account store. 如果应用程序需要根据用户或服务标识授予事件中心资源的访问权限,应实现安全令牌服务,以便在执行身份验证和访问检查后颁发 SAS 令牌。If your application needs to grant access to Event Hubs resources based on user or service identities, it should implement a security token service that issues SAS tokens after an authentication and access check.

将为授权规则分配主要密钥辅助密钥An authorization rule is assigned a primary key and a secondary key. 这些密钥是加密形式的强密钥。These keys are cryptographically strong keys. 请不要遗失或透漏这些密钥。Don’t lose them or leak them. 在 Azure 门户中总要用到它们。They’ll always be available in the Azure portal. 可以使用其中一个生成的密钥,并且随时可以重新生成密钥。You can use either of the generated keys, and you can regenerate them at any time. 如果重新生成或更改策略中的密钥,以前基于该密钥颁发的所有令牌会立即失效。If you regenerate or change a key in the policy, all previously issued tokens based on that key become instantly invalid. 但是,基于此类令牌创建的现有连接将继续工作,直到该令牌过期。However, ongoing connections created based on such tokens will continue to work until the token expires.

创建事件中心命名空间时,系统会自动为该命名空间创建名为 RootManageSharedAccessKey 的策略规则。When you create an Event Hubs namespace, a policy rule named RootManageSharedAccessKey is automatically created for the namespace. 此策略具有整个命名空间的“管理”权限。 This policy has manage permissions for the entire namespace. 建议将此规则视为 root 管理帐户,且不要在应用程序中使用它。It’s recommended that you treat this rule like an administrative root account and don’t use it in your application. 可以通过门户上命名空间的“配置”选项卡、PowerShell 或 Azure CLI 创建更多策略规则。 You can create additional policy rules in the Configure tab for the namespace in the portal, via PowerShell or Azure CLI.

使用 SAS 的最佳实践Best practices when using SAS

在应用程序中使用共享访问签名时,需要知道以下两个可能的风险:When you use shared access signatures in your applications, you need to be aware of two potential risks:

  • 如果 SAS 泄露,则获取它的任何人都可以使用它,这可能会使事件中心资源遭到入侵。If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your Event Hubs resources.
  • 如果提供给客户端应用程序的 SAS 到期并且应用程序无法从服务检索新 SAS,则可能会影响该应用程序的功能。If a SAS provided to a client application expires and the application is unable to retrieve a new SAS from your service, then application’s functionality may be hindered.

下面这些针对使用共享访问签名的建议可帮助降低这些风险:The following recommendations for using shared access signatures can help mitigate these risks:

  • 如果需要,让客户端自动续订 SAS:客户端应在到期时间之前很久就续订 SAS,这样,即使提供 SAS 的服务不可用,客户端也有时间重试。Have clients automatically renew the SAS if necessary: Clients should renew the SAS well before expiration, to allow time for retries if the service providing the SAS is unavailable. 如果 SAS 旨在用于少量即时的短期操作,这些操作应在到期时间内完成,则上述做法可能是不必要的,因为不应续订 SAS。If your SAS is meant to be used for a small number of immediate, short-lived operations that are expected to be completed within the expiration period, then it may be unnecessary as the SAS is not expected to be renewed. 但是,如果客户端定期通过 SAS 发出请求,则有效期可能就会起作用。However, if you have client that is routinely making requests via SAS, then the possibility of expiration comes into play. 需要考虑的主要方面就是在以下两者间进行权衡:对短期 SAS 的需求(如前文所述)以及确保客户端尽早请求续订(以免在成功续订前因 SAS 到期而中断)。The key consideration is to balance the need for the SAS to be short-lived (as previously stated) with the need to ensure that client is requesting renewal early enough (to avoid disruption due to the SAS expiring prior to a successful renewal).
  • 要注意 SAS 开始时间:如果将 SAS 的开始时间设置为“现在”,则由于时钟偏移(根据不同计算机,当前时间的差异),在前几分钟将会间歇地观察到失败。 Be careful with the SAS start time: If you set the start time for SAS to now, then due to clock skew (differences in current time according to different machines), failures may be observed intermittently for the first few minutes. 通常,将开始时间至少设置为 15 分钟前。In general, set the start time to be at least 15 minutes in the past. 或者根本不设置,这会使它在所有情况下都立即生效。Or, don’t set it at all, which will make it valid immediately in all cases. 同样的原则也适用于过期时间。The same generally applies to the expiry time as well. 请记住,对于任何请求,在任一方向你可能会观察到最多 15 分钟的时钟偏移。Remember that you may observer up to 15 minutes of clock skew in either direction on any request.
  • 对要访问的资源要具体:一种安全性最佳做法是向用户提供所需最小权限。Be specific with the resource to be accessed: A security best practice is to provide user with the minimum required privileges. 如果某一用户仅需要对单个实体的读取访问权限,则向该用户授予对该单个实体的读取访问权限,而不要授予针对所有实体的读取/写入/删除访问权限。If a user only needs read access to a single entity, then grant them read access to that single entity, and not read/write/delete access to all entities. 如果 SAS 泄露,这也有助于降低损失,因为攻击者手中掌握的 SAS 的权限较为有限。It also helps lessen the damage if a SAS is compromised because the SAS has less power in the hands of an attacker.
  • 不要总是使用 SAS:有时,与针对事件中心的特定操作相关联的风险要超过 SAS 所带来的好处。Don’t always use SAS: Sometimes the risks associated with a particular operation against your Event Hubs outweigh the benefits of SAS. 对于此类操作,应创建一个中间层服务,该服务在执行业务规则验证、身份验证和审核后写入事件中心。For such operations, create a middle-tier service that writes to your Event Hubs after business rule validation, authentication, and auditing.
  • 始终使用 HTTPs:始终使用 HTTPs 创建或分发 SAS。Always use HTTPs: Always use Https to create or distribute a SAS. 如果某一 SAS 通过 HTTP 传递并且被截取,则执行中间人攻击的攻击者将能够读取 SAS、并使用它,就像目标用户本可执行的操作一样,这可能会暴露敏感数据或者使恶意用户能够损坏数据。If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attach is able to read the SAS and then use it just as the intended user could have, potentially compromising sensitive data or allowing for data corruption by the malicious user.

结论Conclusion

共享访问签名用于向客户端提供对事件中心资源的受限权限。Share access signatures are useful for providing limited permissions to Event Hubs resources to your clients. 它们是安全模型中的重要环节,适合使用 Azure 事件中心的任何应用程序。They are vital part of the security model for any application using Azure Event Hubs. 如果遵循本文中所列的最佳做法,则可以使用 SAS 更灵活地访问资源,且不会损害应用程序的安全性。If you follow the best practices listed in this article, you can use SAS to provide greater flexibility of access to your resources, without compromising the security of your application.

后续步骤Next steps

请参阅以下相关文章:See the following related articles: