Control access to private data using Azure storage shared access signatures

Introduction

Security and governance are two major blockers that either stop or delay the cloud journey of various customers. In this era of the digital world, almost everyone has shown their concerns about the security of their data. Some are concerned due to the nature of data like PII data, and some are concerned due to local compliance laws like GDPR in Europe.

Business Problem

While I was working on a review assignment, I found that application was using the Azure Storage Shared access signature for distributing access to private data. Even the developer of the application was using the SAS token as best practice, but it was still having below challenges.

The shared access signature

Created for a very longer duration, like 2 years.
Shared access token was having unlimited privileges
The shared Access token was hardcoded in Java Script Files.
The scope of the shared access token was on the container level.
Every time they changed the storage account credentials, they need to regenerate the SAS token.

What are Shared access signatures?

Azure Storage SAS (Shared Access Signature) is a security token that provides limited access rights and permissions to Azure Storage resources. SAS tokens are used to grant temporary and granular access to specific resources within an Azure Storage account. With a SAS token, you can control the allowed operations (such as read, write, delete), the duration of access, and the resources accessible.

Some key points to understand about Azure Storage SAS

Access Control
Time-Limited
Resource-Level Access
Secure Sharing
Granular Permissions
Signature-Based Authentication

SAS tokens provide a flexible and secure way to grant temporary access to Azure Storage resources. They offer control over permissions, duration, and resource-level access, making them an essential tool for managing and securing storage access in Azure.

Solution

Instead of using the long-duration SAS token, we can use the proposed change in architecture and can introduce a middleware service as a SAS generator.

Note: SAS token used in this article/description is already expired.

Architecture of the proposed solution

Architecture of proposed solution

These middleware services were capable to generate the SAS token on demand.

Listing of files from the container

When a user successfully login to the application, the application calls this middleware API to generate a token to get the list of files from that container. This time SAS token has only listed privileges. In case of compromise of this token, an attacker can only see the listing of file names, but files cannot be read or downloaded.

Ex : https://tra********a.blob.core.windows.net/rawdata?sp=l&st=2023-07-15T11:30:37Z&se=2023-07-15T19:30:37Z&spr=https&sv=2022-11-02&sr=c&sig=Vim*******************%3D

Let's use Azure Storage Explorer to access the Azure storage and demonstrate the SAS concept.

SAS concept

Connection Info

Resources

Interface

By using this limited privileged SAS token, we can retrieve the list of the files from the Azure storage container. if we try to download the file by using the same SAS token, the Download operation will get failed.

Download Operation

Reading a file, this file name is passed as input to the SAS-Gen api

The API returned a SAS token applicable for that file and having only read privileges. If this SAS token is compromised, then the attacker can read only that specific file within the specified time. This SAS token is blob specific and cannot be used for any other blob from the container.

Ex : https://tra********a.blob.core.windows.net/rawdata/csvdata/1.csv?sp=r&st=2023-07-15T11:32:35Z&se=2023-07-15T19:32:35Z&spr=https&sv=2022-11-02&sr=b&sig=4TTRn*****************************************%3D

if we try to use this SAS token in the browser, we can see that file is downloaded successfully.

API Endpoint

What if an attacker knows the SAS generator API endpoint?

If an attacker knows the API endpoint and will try to access the API, it will get an authentication failure response.

The API endpoint is Azure AAD authentication enabled, and a valid bearer token need to send with every request. During the login into the application with the correct user id and password, the user gets the authentication bearer token. This same token is further passed to API.

Best practices with SAS

Shared Access Tokens provide a secure way to grant limited access to your Azure Storage resources. Here are some best practices to consider when using Shared Access Tokens:

Use the principle of least privilege: When creating a Shared Access Token, ensure that you grant only the permissions required for the specific operation. Avoid granting excessive permissions to limit the potential impact of compromised tokens.
Set an appropriate expiration time: Configure the Shared Access Token with an expiration time that aligns with your application's needs. Shorter expiration times minimize the window of opportunity for an attacker to abuse the token.
Use stored access policies: Azure Storage provides stored access policies that allow you to manage shared access permissions for multiple resources using a single access policy. This simplifies access management and reduces the risk of accidental overexposure.
Regularly rotate tokens: To enhance security, consider implementing a token rotation policy. By rotating the Shared Access Tokens periodically, you can reduce the potential impact of stolen or leaked tokens.
Secure token transmission: Ensure that the Shared Access Tokens are transmitted securely over HTTPS. Avoid transmitting tokens over unencrypted channels to prevent interception and abuse.
Implement token revocation: In scenarios where you need to immediately revoke access, consider implementing token revocation mechanisms within your application. This can be achieved by maintaining a centralized token management system or by using an external access control mechanism.
Limit exposure of tokens: Minimize the distribution of Shared Access Tokens. Avoid embedding tokens directly in client applications and instead, consider server-side authentication mechanisms where possible.
Monitor token usage: Implement logging and monitoring mechanisms to track Shared Access Token usage. Regularly review access logs and monitor token usage patterns to detect any suspicious activity or anomalous behavior.

Conclusion

Implementing the principle of least privilege and using server-side SAS generation has given the application team confidence that they are only granting the necessary permissions to their resources. The ability to set appropriate expiration times and regularly rotate tokens adds an extra layer of protection, giving us peace of mind.