User delegation key vs account key - security?

7.2k Views Asked by At

In Microsoft's documentation for user delegation key, it says:

A SAS token for access to a container, directory, or blob may be secured by using either Azure AD credentials or an account key. A SAS secured with Azure AD credentials is called a user delegation SAS. Microsoft recommends that you use Azure AD credentials when possible as a security best practice, rather than using the account key, which can be more easily compromised. When your application design requires shared access signatures, use Azure AD credentials to create a user delegation SAS for superior security.

Why do this approach give "superior security"? I guess the SAS tokens are both safe? So why exactly is one approach safer than the other? If you use Stored Access Policy, you can also revoke SAS tokens when they have been issues with account keys.

1

There are 1 best solutions below

1
On BEST ANSWER

A user-delegation SAS token is more secure that it does not rely on the permissions included in the SAS token only. It also takes into consideration the RBAC permissions of the user who created this SAS token. A SAS token created using shared access key simply considers the permissions included in the SAS token.

For example, let's say the user who's creating a user-delegation SAS only has Read permissions on a blob container (i.e. they can only list or download blobs in a blob container). Now let's say the user creates a SAS token with Write permission. When this SAS token is used to upload a blob, the operation will fail because the user does not have Write permissions on that blob container whereas the upload operation would have succeeded if the SAS token was created using shared access key.

More information on this can be found here (emphasis mine):

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. The role-based access control (RBAC) permissions granted for that Azure AD account, together with the permissions explicitly granted on the SAS, determine the client's access to the resource. This approach provides an additional level of security and avoids the need to store your account access key with your application code. For these reasons, creating a SAS using Azure AD credentials is a security best practice.

The permissions granted to a client who possesses the SAS are the intersection of the permissions granted to the security principal that requested the user delegation key and the permissions granted to the resource on the SAS token using the signedPermissions (sp) field. If a permission granted to the security principal via RBAC is not also granted on the SAS token, then that permission is not granted to the client who attempts to use the SAS to access the resource. When creating a user delegation SAS, make sure that the permissions granted via RBAC and the permissions granted via the SAS token both align to the level of access required by the client.