Control access to private data using Azure storage shared access signatures

Introduction

When it comes to the cloud journey, many customers face challenges related to security and governance. In today’s digital world, data security is a major concern for everyone. Whether it’s personally identifiable information (PII) data or compliance with local laws like GDPR in Europe, organizations need to ensure that their data is protected.

Business Problem

During a review assignment, I encountered an application that was using Azure Storage Shared access signatures (SAS) to distribute access to private data. While the developer followed best practices by using SAS tokens, there were still some challenges:

The shared access signature:

1. Had a very long duration, up to 2 years.
2. Had unlimited privileges.
3. Was hardcoded in JavaScript files.
4. Provided access at the container level.
5. Required regeneration whenever storage account credentials were changed.

What are Shared access signatures?

Azure Storage Shared Access Signatures (SAS) are security tokens that grant limited access rights and permissions to Azure Storage resources. SAS tokens are used to provide temporary and granular access to specific resources within an Azure Storage account. These tokens allow control over operations, duration of access, and the accessible resources.

Key points about Azure Storage SAS

1. Access Control
2. Time-Limited
3. Resource-Level Access
4. Secure Sharing
5. Granular Permissions
6. Signature-Based Authentication

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

Solution

Instead of using long-duration SAS tokens, the proposed solution involves introducing a middleware service as a SAS generator.

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

Architecture of the proposed solution

The middleware services are capable of generating SAS tokens on demand.

Listing of files from the container

When a user successfully logs in to the application, the application calls the middleware API to generate a token for listing the files in the container. This SAS token only has listing privileges. Even if this token is compromised, an attacker can only see the list of file names, but cannot read or download the files.

Example: 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

We can use Azure Storage Explorer to access the Azure storage and demonstrate the SAS concept.

Using this limited privileged SAS token, we can retrieve the list of files from the Azure storage container. However, if we try to download a file using the same token, the download operation will fail.

Reading a file

To read a file, the file name is passed as input to the SAS-Gen API. The API returns a SAS token specific to that file, with read privileges. If this token is compromised, the attacker can only read that specific file within the specified time. This SAS token is specific to the blob and cannot be used for any other blob in the container.

Example: 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 successfully download the file.

What if an attacker knows the SAS generator API endpoint?

If an attacker knows the API endpoint and tries to access it, they will receive an authentication failure response.

The API endpoint is Azure Active Directory (AAD) authentication-enabled, and a valid bearer token needs to be sent with every request. During login, the user receives an authentication bearer token, which is then passed to the API.

Best practices with SAS

When using Shared Access Tokens (SAS), it is important to follow best practices to ensure security. Some of these practices include:

• Use the principle of least privilege: Grant only the necessary permissions for each operation when creating a Shared Access Token. Avoid granting excessive permissions to minimize the impact of compromised tokens.
• Set an appropriate expiration time: Configure the Shared Access Token to expire based on your application’s needs. Shorter expiration times reduce the window for potential token abuse.
• 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 overexposure.
• Regularly rotate tokens: Implement a token rotation policy to enhance security. By periodically rotating Shared Access Tokens, you can minimize the impact of stolen or leaked tokens.
• Secure token transmission: Ensure that Shared Access Tokens are transmitted securely over HTTPS to prevent interception and abuse.
• Implement token revocation: If immediate access revocation is needed, consider implementing token revocation mechanisms within your application. This can be done through a centralized token management system or an external access control mechanism.
• Limit exposure of tokens: Minimize the distribution of Shared Access Tokens. Instead of embedding tokens directly in client applications, 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 anomalies.

Conclusion

By implementing the principle of least privilege and using server-side SAS generation, the application team gains confidence in granting only necessary permissions to their resources. Setting appropriate expiration times and regularly rotating tokens adds an extra layer of protection and peace of mind.