Shared access signatures

Storage resources are secured by SAS tokens. SAS tokens indicate how the resources can be accessed by the client and is signed with the key that was used to create the SAS.

There are three kinds of SAS:

• User delegation
  Secured with Entra credentials and also by the SAS specified permissions. Blob and Data Lake storage only.
• Service
  Secured with the storage account key. Blob, Queue, Table and Files.
• Account
  Secured with the storage account key. One or more of the storage services.

User delegation is recommended where possible as the most secure form of SAS token.

SAS tokens are essentials a collection of query parameters that get appended to a storage resource request.

https://medicalrecords.blob.core.windows.net/patient-images/patient-1.jpg?
	sp=r&                          # read
	st=2020-01-20T11:42:32Z&       # access starts
	se=2020-01-20T19:42:32Z&       # access ends
	spr=https&
	sv=2019-02-02&                 # API version
	sr=b&                          # b is for blob (storage kind)
	sig=SrW1HZ5Nb6MbRzTbXCaPm%2BJiSEn15tC91Y4umMPwVZs%3D        # signature

• Always use HTTPS
• Use user delegation where possible
• Smallest expiration time possible
• Minimum required privileges
• Sometimes SAS is too risky a solution and a middle tier service is more appropriate

A middle tier service is more secure than using SAS, however it may struggle to meet demand for high volume scenarios. Many real-world services might use a hybrid of direct SAS usage and a a front-end proxy service.

Copy operations sometimes require SAS to authorise access to the source object:

• When copying a blob/file from a different storage account
• When copying a blob to a file for vice versa, even if within the same storage account

Stored access policies

Stored access policies provide extra control over service-level SAS on the server side. You can use a stored access policy to change the start, expiry and permissions of a SAS or to revoke it entirely.

Support: Blob, File, Queue, Table

A shared access policy consists of a start time, expiry time and permissions for the signature. These parameters can either be specified on the policy or the signature URI but not both.

Creation

To create a stored access policy, call the Set ACL HTTP operation for the resource, or use C# or the Azure CLI:

BlobSignedIdentifier identifier = new BlobSignedIdentifier
{
    Id = "stored access policy identifier",
    AccessPolicy = new BlobAccessPolicy
    {
        ExpiresOn = DateTimeOffset.UtcNow.AddHours(1),
        Permissions = "rw"
    }
};

blobContainer.SetAccessPolicy(
	permissions: new BlobSignedIdentifier[] { identifier }
);

az storage container policy create \ 
	--name <stored access policy identifier> \ 
	--container-name <container name> \ 
	--start <start time UTC datetime> \ 
	--expiry <expiry time UTC datetime> \ 
	--permissions <(a)dd, (c)reate, (d)elete, (l)ist, (r)ead, or (w)rite> \ 
	--account-key <storage account key> \ 
	--account-name <storage account name> 

Modification

To modify the parameters of the stored access policy you can call the Set ACL operation for the resource type to replace the existing policy.

To revoke a stored access policy, you can delete it, change the signed identifier or change the expiry time to some value in the past. Changing the signed identifier breaks the association between existing SAS tokens and the policy.

To remove a single policy, call the resource's Set ACL operation and pass the set of signed identifiers that you want to keep. To remove all policies pass you can pass an empty body