用户授权密钥与帐户密钥 - 安全性？

Question

在 Microsoft 的用户委托密钥文档中，它说：

可以使用 Azure AD 凭据或帐户密钥来保护用于访问容器、目录或 blob 的 SAS 令牌。 使用 Azure AD 凭据保护的 SAS 称为用户委托 SAS。 Microsoft 建议您尽可能使用 Azure AD 凭据作为安全最佳实践，而不是使用帐户密钥，因为后者更容易受到攻击。 当您的应用程序设计需要共享访问签名时，请使用 Azure AD 凭据创建用户委托 SAS 以实现卓越的安全性。

为什么这种方法会提供“卓越的安全性”？ 我猜 SAS 令牌都是安全的？ 那么为什么一种方法比另一种方法更安全呢？ 如果您使用存储访问策略，您还可以在 SAS 令牌与帐户密钥有关时撤销它们。

Answer 1

用户委托 SAS 令牌更安全，因为它不依赖于仅包含在 SAS 令牌中的权限。 它还考虑了创建此 SAS 令牌的用户的 RBAC 权限。 使用共享访问密钥创建的 SAS 令牌仅考虑 SAS 令牌中包含的权限。

例如，假设创建用户委托 SAS 的用户仅对 blob 容器具有Read权限（即，他们只能列出或下载 blob 容器中的 blob）。 现在假设用户创建了一个具有Write权限的 SAS 令牌。 当使用此 SAS 令牌上传 Blob 时，操作将失败，因为用户对该 Blob 容器没有Write权限，而如果 SAS 令牌是使用共享访问密钥创建的，则上传操作会成功。

可以在here找到更多信息（重点是我的）：

When a client accesses a Blob storage resource with a user delegation SAS, the request to Azure Storage is authorized with the Azure AD credentials that were used to create the SAS. 为该 Azure AD 帐户授予的基于角色的访问控制 (RBAC) 权限与在 SAS 上明确授予的权限一起确定了客户端对资源的访问权限。 这种方法提供了额外的安全级别，并且避免了将您的帐户访问密钥与您的应用程序代码一起存储的需要。 由于这些原因，使用 Azure AD 凭据创建 SAS 是一种安全最佳实践。

授予拥有 SAS 的客户端的权限是授予请求用户委托密钥的安全主体的权限与使用 signedPermissions (sp) 字段授予 SAS 令牌上的资源的权限的交集。 如果通过 RBAC 授予安全主体的权限也未在 SAS 令牌上授予，则该权限不会授予尝试使用 SAS 访问资源的客户端。 创建用户委托 SAS 时，请确保通过 RBAC 授予的权限和通过 SAS 令牌授予的权限都与客户端所需的访问级别保持一致。