用户委托密钥与帐户密钥 - 安全性?

Zig*_*000 6 azure azure-storage azure-active-directory azure-security

在微软的用户委托密钥文档中,它说:

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

为什么这种方法能够提供“卓越的安全性”?我想 SAS 令牌都是安全的?那么为什么一种方法比另一种方法更安全呢?如果您使用存储访问策略,当帐户密钥出现问题时,您还可以撤销 SAS 令牌。

Gau*_*tri 10

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

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

有关这方面的更多信息可以找到here(重点是我的):

当客户端使用用户委派 SAS 访问 Blob 存储资源时,对 Azure 存储的请求将使用用于创建 SAS 的 Azure AD 凭据进行授权。为该 Azure AD 帐户授予的基于角色的访问控制 (RBAC) 权限以及在 SAS 上显式授予的权限决定了客户端对资源的访问权限。此方法提供了额外的安全级别,并且无需将帐户访问密钥与应用程序代码一起存储。由于这些原因,使用 Azure AD 凭据创建 SAS 是一种安全最佳实践。

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