Start preparing for your Next Exam | Use coupon – TOGETHER | Avail 30% discount

Using Shared Access Signatures (SAS) in Azure Storage

  1. Home
  3. Using Shared Access Signatures (SAS) in Azure Storage

This tutorial will help you learn Using Shared Access Signatures (SAS) in Azure Storage. A shared access signature (SAS) provides secure delegated access to resources in your storage account without compromising the security of your data. With a SAS, you have granular control over how a client can access your data. You can control what resources the client may access, what permissions they have on those resources, and how long the SAS is valid, among other parameters.

Shared Access Signatures (SAS) in Azure Storage provide a way to grant limited access to resources in your storage account. By using SAS, you can grant access to a specific resource for a specific period of time, with specific permissions and constraints. To use SAS in Azure Storage, you first need to create a storage account and create one or more containers or blobs within the account. Once you have your resources set up, you can create a SAS that specifies the permissions and constraints for accessing those resources.

To create a SAS, you need to specify the resource(s) you want to grant access to, the permissions that should be granted (such as read, write, or delete), the duration of the SAS (in hours or days), and any other constraints such as IP address restrictions or start/end times. Once you have created a SAS, you can provide it to a client application, which can then use it to access the specified resource(s) within the specified constraints. SAS can be used with a variety of Azure Storage services, including Blob storage, Queue storage, Table storage, and File storage.

It’s important to note that SAS provides a way to grant temporary access to resources, but it does not replace other security measures such as access control lists (ACLs) or role-based access control (RBAC). It’s also important to ensure that SAS are created with appropriate permissions and constraints to minimize the risk of unauthorized access.

Types of Shared Access Signatures (SAS)

Azure Storage supports three types of shared access signatures –

  1. User delegation SAS: A User Delegation SAS allows clients to delegate access to Azure Storage resources without sharing their account key. This is useful for scenarios where clients want to grant access to their resources to a third party, such as a vendor or contractor, without disclosing their account key. User delegation SAS can be generated using Azure AD credentials, which allows the SAS to be managed using Azure AD security policies.
  2. Service SAS: A Service SAS provides access to a specific resource within a storage account, such as a blob container or a queue. With a Service SAS, you can specify the resource to be accessed, the permissions granted (such as read, write, or delete), and the duration of the SAS. You can also specify IP address or protocol restrictions, and you can revoke the SAS at any time. Service SAS is useful for scenarios where you need to grant temporary access to a specific resource within your storage account.
  3. Account SAS: An Account SAS provides access to all resources within a storage account. With an Account SAS, you can specify the permissions granted (such as read, write, or delete), the duration of the SAS, and the IP address or protocol restrictions. You can also limit the SAS to specific services (such as Blob or Queue storage), and you can revoke the SAS at any time. Account SAS is useful for scenarios where you need to grant access to all resources within your storage account, but still want to control the permissions granted.

In summary, Azure Storage supports three types of Shared Access Signatures (SAS): User Delegation SAS, Service SAS, and Account SAS. Each type of SAS provides a way to grant temporary access to resources in Azure Storage with specific permissions and constraints, allowing you to control access to your storage resources and protect them from unauthorized access.

How a shared access signature works?

A shared access signature is a signed URI that points to one or more storage resources and includes a token that contains a special set of query parameters. The token indicates how the resources may be accessed by the client. One of the query parameters, the signature, is constructed from the SAS parameters and signed with the key that was used to create the SAS. This signature is used by Azure Storage to authorize access to the storage resource.

A shared access signature (SAS) is a URI that grants restricted access rights to specific Azure Storage resources. It is essentially a token that provides time-limited access to a resource or a set of resources within an Azure Storage account. Here’s how a shared access signature works:

  1. A user or application requests a shared access signature from Azure Storage.
  2. The user or application specifies the permissions, start time, and expiry time for the SAS. The permissions can include read, write, delete, and list access to one or more storage resources.
  3. Azure Storage generates a unique SAS token based on the specified parameters.
  4. The user or application receives the SAS token, which can be included in a URI to access the specified resources.
  5. When the SAS token is included in a URI, it allows the holder to access the specified resources for the duration and with the permissions specified in the SAS token.
  6. After the expiry time of the SAS token, the token is no longer valid, and access to the specified resources is denied.

Shared access signatures are commonly used in scenarios where you want to give limited access to a resource without sharing the account key, such as granting access to a specific container or blob for a limited time or for specific operations. SAS tokens can be generated programmatically and can be used in conjunction with Azure Storage clients or REST APIs.

How to do SAS signature?

To generate a shared access signature (SAS) for an Azure Storage resource, you can use one of the Azure Storage client libraries, the Azure Storage REST API, or the Azure portal. Here are the basic steps to generate a SAS signature:

  1. Identify the resource you want to generate a SAS for. This could be a blob container, a blob, a file share, or a queue, for example.
  2. Determine the permissions you want to grant to the SAS. You can specify a combination of read, write, delete, and list permissions.
  3. Specify the start time and expiry time for the SAS. These values determine when the SAS is valid and for how long.
  4. Create a shared access policy (optional). A shared access policy is a set of SAS parameters that can be reused for multiple SAS tokens. You can define a policy with a set of permissions, start time, and expiry time, and then generate SAS tokens based on that policy.
  5. Generate the SAS token using your preferred method. If using a client library, there will be a method for generating a SAS token for your chosen resource. If using the REST API, you will need to construct a URI that includes the necessary SAS parameters.
  6. Include the SAS token in the URI to access the resource. The SAS token should be appended to the URI for the resource you want to access, as a query parameter.

Here’s an example SAS token generated for a blob in Azure Storage using the Azure Storage SDK for .NET:

javaCopy codeBlobSasBuilder sasBuilder = new BlobSasBuilder()
{
    BlobContainerName = "mycontainer",
    BlobName = "myblob.txt",
    Resource = "b",
    StartsOn = DateTimeOffset.UtcNow,
    ExpiresOn = DateTimeOffset.UtcNow.AddHours(1),
    Protocol = SasProtocol.Https,
    Permissions = "r"
};

string sasToken = sasBuilder.ToSasQueryParameters(new StorageSharedKeyCredential("mystorageaccount", "myaccountkey")).ToString();

This code creates a SAS token that grants read access (specified by the “r” permission) to a blob named “myblob.txt” in the container “mycontainer”. The SAS token is valid for one hour, starting from the current time. The SAS token is generated using a storage account key. Once you have the SAS token, you can use it to access the specified blob by appending it as a query parameter to the blob URI, like this:

arduinoCopy codehttps://mystorageaccount.blob.core.windows.net/mycontainer/myblob.txt?sasToken

Note that the SAS token is represented by the “sasToken” placeholder in the URI above. You should replace this placeholder with the actual SAS token value.

What are SAS tokens?

The SAS token is a string that you generate on the client side, for example by using one of the Azure Storage client libraries. The SAS token is not tracked by Azure Storage in any way. You can create an unlimited number of SAS tokens on the client side. After you create a SAS, you can distribute it to client applications that require access to resources in your storage account.

When a client application provides a SAS URI to Azure Storage as part of a request, the service checks the SAS parameters and signature to verify that it is valid for authorizing the request. If the service verifies that the signature is valid, then the request is authorized. Otherwise, the request is declined with error code 403 (Forbidden).

Using Shared Access Signatures (SAS) in Azure Storage
Image Source – Microsoft

A SAS token, or Shared Access Signature token, is a security token that provides restricted access to specific resources in an Azure Storage account. It is essentially a string that contains a set of parameters that define the access permissions, start time, expiry time, and other details for accessing a specific Azure Storage resource.

SAS tokens can be used to grant access to a variety of Azure Storage resources, including blob containers, blobs, file shares, tables, and queues. SAS tokens can be generated programmatically using Azure Storage client libraries or the Azure Storage REST API.

When you create a SAS token, you can specify the following parameters:

  • Resource type: The type of Azure Storage resource you want to access, such as a blob container or file share.
  • Permissions: The access permissions you want to grant, such as read, write, delete, and list permissions.
  • Start time and expiry time: The times between which the SAS token is valid.
  • IP restrictions: The IP addresses or ranges that are allowed to use the SAS token.
  • Protocol: The protocol to use when accessing the resource, such as HTTP or HTTPS.
  • Signature: A unique signature that is used to validate the SAS token.

Here’s an example SAS token that grants read access to a blob container for a period of 1 hour:

makefileCopy codesv=2021-08-01
&ss=b
&srt=c
&sp=r
&se=2023-04-06T23:59:59Z
&st=2023-04-06T00:00:00Z
&spr=https
&sig=<signature>

In this example, the SAS token grants read access (specified by “sp=r”) to a blob container (“srt=c”) for a period of 1 hour, starting from April 6, 2023, at midnight UTC (“st=2023-04-06T00:00:00Z”) and ending on April 6, 2023, at 11:59:59 PM UTC (“se=2023-04-06T23:59:59Z”). The SAS token is valid only for HTTPS requests (“spr=https”).

The signature parameter is generated using the storage account key and the SAS parameters. The signature ensures that the SAS token is authentic and has not been tampered with.

SAS tokens are a powerful and flexible way to grant limited access to Azure Storage resources without exposing the storage account keys or compromising the security of the account.

Best practices when using SAS

When you use shared access signatures in your applications, you need to be aware of two potential risks:

  • If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your storage account.
  • If a SAS provided to a client application expires and the application is unable to retrieve a new SAS from your service, then the application’s functionality may be hindered.

The following recommendations for using shared access signatures can help mitigate these risks:

  • Always use HTTPS
  • Use a user delegation SAS when possible etc

Some best practices to follow when using SAS (Shared Access Signature) tokens with Azure Storage

  1. Use the minimum required permissions: When creating a SAS token, grant only the permissions that are required for the operation. For example, if you only need to read data from a blob, grant read access but not write access.
  2. Use short expiration times: Set the expiration time for the SAS token to the shortest duration possible, based on your application requirements. This reduces the risk of unauthorized access to your resources if the SAS token is compromised.
  3. Use HTTPS: Always use HTTPS to access Azure Storage resources when using a SAS token. This ensures that the data is encrypted during transit and helps prevent eavesdropping.
  4. Use IP restrictions: Consider adding IP address restrictions to limit the range of IP addresses that can use the SAS token. This can help prevent unauthorized access to your resources.
  5. Use SAS tokens with stored access policies: You can use stored access policies to manage the parameters of SAS tokens centrally. This simplifies the process of granting and revoking access to resources.
  6. Rotate SAS tokens regularly: Consider rotating SAS tokens periodically to reduce the risk of unauthorized access. You can revoke SAS tokens when they are no longer needed, or set a shorter expiration time to force the creation of new tokens more frequently.
  7. Securely store SAS tokens: Treat SAS tokens as secret credentials and store them securely. Do not embed SAS tokens in code or configuration files that may be accessible to unauthorized users.

By following these best practices, you can ensure that your SAS tokens are used securely and effectively to grant controlled access to your Azure Storage resources.

free practice test for AZ- 303

Go back to home page

Reference documentation – Grant limited access to Azure Storage resources using shared access signatures (SAS)

Menu