1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Configuring Azure Application and Data Security

Granting Limited Access to Azure Storage Resources with Shared Access Signatures (SAS)

The course is part of this learning path

Start course
Microsoft Azure offers a wide range of options to secure and protect your data, regardless of the format. Whether you're dealing with documents, SQL databases or big data, there are multiple solutions ranging from authentication to virtual networks.
In this course, we will cover the protection of your data from external and internal threats, whether those threats be malicious or accidental. We will see how good design combined with the right configuration can secure your organization's most precious asset: its data.

Learning Objectives

  • Configure security policies to classify, protect, and manage data
  • Configure data retention for storage and databases
  • Set up Azure SQL security features and auditing
  • Learn how to configure storage account security and access
  • Learn how to secure HDInsight clusters
  • Configure Cosmos DB security
  • Configure Data Lake security
  • Learn good design features of an Azure application
  • See how Azure App Services can secure your app
  • See how a governance policy can help formalize security requirements

Intended Audience

  • People preparing for Microsoft’s AZ-500 exam
  • System administrators
  • App developers


  • Experience with Microsoft Azure
  • Experience with Office 365
  • Basic knowledge of computer security principles
  • Basic networking knowledge



A Shared access signature, or SAS, is a URI that provides access to an Azure storage resource for users that you don’t want to give the storage account key to. The URI has parameters that specify the type of access and when the resource can be accessed as well as an authentication key specific to that resource. Shared access signatures come in 3 flavors. 

A user delegation SAS is based on Azure Active Directory credentials. Those credentials along with permissions specified for the SAS define the access to the blob storage. It’s called a user delegation SAS because it is signed with a user delegation key. 

A service SAS provides access to a storage service, and just that service. So, you can provide access to either blob storage, queue storage, table storage, or file storage. If you need to specify what type of access should be allowed on the service this can be done by referencing a stored access policy. 

An account SAS allows you to provide access to multiple services within a storage account. While service SAS requires a stored access policy to define the type of access permitted, an account SAS allows you to specify the type of operations that can be performed on those services within the URI. That is, you can specify whether read, list, add, create, write, update, or delete operations are allowed. These operations will vary slightly from resource to resource. For example, you can only assign process permission to a queue service.

Both service and account shared access signatures are secured with the storage account key. You can define a shared access signature as a standalone self-contained entity called an Ad hoc SAS, or you can associate a service SAS with a stored access policy. Essentially this makes your service SAS configurable and dynamic. 

Creating and referencing a store access policy through the Azure portal UI is reasonably straight-forward. It involves setting access on the resource, in this case read and list permissions on a blob container. You then navigate to the container within Storage Explorer and right click on it selecting the Get Shared Access Signature menu option. Finally select your access policy from the drop-down list and save.

You can now change how your resource is accessed without having to generate and distribute a new Shared Access Signature, just by editing your access policy

Here we can see the structure of a shared access signature. It is a URL with the signature's properties defined as parameters, starting with the blob address, type of access allowed, times of access, the supported access request types, storage version, and finally, the authentication signature.

About the Author
Learning Paths

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.