SAS Tokens Decoded: How to Ensure Data Security in Azure Blob Storage?

Microsoft Azure offers various cloud storage services through Azure Storage Accounts. These services include Azure Disks, Blob Storage, File Shares, Tables, and Queues, and they have been designed to manage data at scale.

But how to provide secured access to these services and the data stored in them?

Let’s talk about Storage Account Access Keys 🔑….

Access Keys (aka Shared Access Keys)

Every Azure Storage Account provides two access keys by default, which we can consider as Primary and Secondary keys.

An access key would look like the one given below. These are cryptographic keys and unique to a Storage account.

Z1uwQdMP8E9flStlhdxC5vJQ3lJcw68tE+uTMOANnSsCV7T7zVHeCjmS+3pPoFCMKvp3htsVp1Mg+AStZdb2+w==

Access Keys have full permission to a Storage Account. Therefore, they can be used to manage all the aspects of a Storage Account and its data.

Microsoft recommends not using access keys unless they are stored and accessed by a trusted application through Azure Key Vault. ( ⚠️ better avoid using Access Keys at any cost! )

Then, How can we provide controlled and fine-grained Access to the Storage Account for external users?

The Answer is the SAS token (Shared Access Signature tokens)….

Shared Access Signature Tokens

The main issue with the Access Keys is that they cannot provide restricted access like Read-only access, Time-bounded access, etc.

Let’s quickly explore the organization of Azure Blob Storage to understand how SAS tokens provide restricted access at various levels of a Storage Account….

We know that Blob Storage is used to store unstructured data such as Text documents, Images, Videos, Audio, etc. They are stored as Blobs ( consider a blob to be an entity that contains both data and metadata ) in the Blob Storage and they can be accessed using HTTP. These blobs are logically grouped inside the entity called Containers.

For instance, we can create a container named ‘Images’ to store image files (blobs) and another container named ‘Documents’ to store documents.

So, if we picturise it….

SAS tokens can be used to restrict access at the Storage Account level, Container level, and even at the Blob level.

For example, we can generate a SAS token to provide write access to an entire container for an external user or generate a SAS token to provide temporary read-only access to a specific file (blob) stored in a container. That’s how flexible SAS tokens are.

Let’s generate a SAS token to provide read-only, time-bounded, and IP Address-restricted access to a blob ….

The generated Blob SAS token and SAS URL are as follows.

sp=r&st=2024-03-03T17:30:06Z&se=2024-03-04T01:30:06Z&sip=86.21.251.79&sv=2022-11-02&sr=b&sig=dQkX7R%2BXHrQLP9qiNdS0zMhYNpmQwLW0D86UUrEgGao%3D

https://teststorageaccount.blob.core.windows.net/images/Blob%20Storage%20Org.jpg?sp=r&st=2024-03-03T17:30:06Z&se=2024-03-04T01:30:06Z&sip=86.21.251.79&sv=2022-11-02&sr=b&sig=dQkX7R%2BXHrQLP9qiNdS0zMhYNpmQwLW0D86UUrEgGao%3D

This SAS URL can be distributed to external users to access the blob.

In general, any token used for authentication and authorization contains information about the access rights associated with the authenticated user or the token itself. A SAS token is not an exception to this.

Let’s decode each parameter of the generated SAS token one by one….

sp = r

Signed Permissions: Specifies the permissions granted for the SAS token. In this case, “r” indicates read access.

st = 2024–03–03T17:30:06Z

Signed Start: Specifies the start time for the SAS token’s validity.

se = 2024–03–04T01:30:06Z

Signed Expiry: Specifies the expiry time for the SAS token’s validity.

sip = 86.21.251.79

Signed IP: Specifies an IP address or a range of IP addresses from which to accept requests using the SAS token.

sv = 2022–11–02

Signed Version: Specifies the signed storage service version.

sr = b

Signed Resource type: Specifies the resource type to which access is granted. In this case, “b” indicates access to a Blob resource.

You may have this Question.

Given this information is explicitly available in the SAS token, can someone tamper with the information?…

For example, can an external user who has this token modify the expiry time information ( se ) in the token in such a way that they gain indefinite access to the resource? 😨

No, that’s not possible. The signature parameter ( sig ) in the SAS token comes to the rescue here.🛡️

sig = dQkX7R%2BXHrQLP9qiNdS0zMhYNpmQwLW0D86UUrEgGao%3D

SAS tokens are signed tokens. When we generate a SAS token, we have to select an Access Key (discussed above) to sign the token.

The string-to-sign is a unique string that’s constructed from the fields that must be verified to authorize the request.

These fields are nothing but the values of the parameters sr, sp, sip, st, se, etc that define the access rights.

The signature is a hash-based message authentication code (HMAC) that’s computed over the string-to-sign and key by using the SHA256 algorithm and then encoded by using Base64 encoding.

When an external user makes a request to the storage account using the SAS token, the signature ( sig ) in the token is verified against the calculated signature on the server side. If the signatures match, it confirms that the SAS token is authentic and has not been tampered with.

But what if we need to alter the permissions associated with a SAS token after it has been distributed to the users? Is it possible?

Yes, but not through plain SAS tokens. We have to use Stored Access Policies.

Stored Access Policy

Access Policies offer several advantages over plain SAS tokens in terms of Centralized Management, Revocation & Expiry, Security & Compliance, and auditability.

We can define stored access policies for a Blob Container and generate SAS tokens based on the defined policy to provide access at the container level or blob level.

Defining a Stored Access Policy….

Generating a SAS token using the Stored Access Policy….

Generated SAS token….

si=ReadAccessMarToApr2024&spr=https&sv=2022-11-02&sr=b&sig=nSDyjuWGo77lzG136M0GL9y0XRxQvc26zDoybfXHM1w%3D

SAS tokens are useful for providing restricted access control to Azure Storage resources for external users. However, they have certain disadvantages in terms of manageability and flexibility. Microsoft recommends using Microsoft Entra (fka Azure AD) user identities or managed identities, along with Role-Based Access Control (RBAC), whenever possible. But how do we implement that? ….That’s a topic for a future post😊.