In this article, lets have a look at the security and encryption features offered by Azure Storage.

In this article, we will see some basics about security and how to enable the data plane security features using Azure portal.

Security Overview

The data you store in Azure storage can be accessed from anywhere in the world. Azure provides comprehensive set of security capabilities that enable you to develop and build the secure applications.

There are two important aspects that we should understand:

• Firstly, you may want to control access levels related to who can manage the storage account, who can create new blobs, who can change access of users, etc. This is called as Management Plane security. This is not related to accessing data from the storage but about managing the storage features and storage itself.
• Second, you may want to control access of who can access the data from the storage, Data Plane security.

Management Plane security

The management plane security is about the operations which can affect storage account itself. You can allow a person to change anything in storage account by providing the storage account keys. But rather than providing the access at subscription level, you can now control the access using Azure Active Directory Role Based Access Control.

Each Azure subscription has an Azure Active Directory. Users, groups, and applications from that directory can be granted access to manage resources in the Azure subscription that use the Resource Manager deployment model. This type of security is referred to as Role-Based Access Control (RBAC). 

When you assign access, you basically assign a role to the account that you want to have access. You can control access to the operations used to manage that storage account, but not to the data objects in the account.

For example, you can grant permission to retrieve the properties of the storage account (such as redundancy), but not to a container or data within a container inside Blob Storage.

There are different roles available e.g. owner, contributor, reader, user access administrator etc.

Network Security

Network security allows you to restrict access to Azure storage from specific networks. You can configure the network access rules for your storage account through the Firewalls and Virtual Networks tab in the Azure portal. Using the storage firewall, you can deny access for public internet traffic, and grant access to select clients based on the configured network rules.

You can use Azure storage firewall rules to restrict the access for certain public IP address range. You can also configure rules to allow access only from specified virtual networks.

You can also use Private Endpoints to privately and securely connect to a storage account from a VNet using Private Links.

Data Plane Security

The data plane security is related to securing the data objects in the storage. you can secure the data objects in storage by allowing access to only limited machines instead of exposing service to whole internet. You can also enable data plane security by providing only required accesses to the data.

For example, some accounts may just want to read the data and some account may want to update the data.

Authorization

This section explains how are you going to control which data objects should be accessed by which user. Ideally there are three ways:

• You can configure Azure AD authentication to get to know about user. This will work to authorize access to containers and queues.
• You can also share the storage account keys of your storage account
• You can also choose to generate shared access signatures

Storage Account Keys

Every storage account has two keys. A storage account key is the 512 bit string that is created by Azure. It can be used to access the storage account.

Many of us may draw a conclusion that one key will have to be used on client side and other on server side in order to communicate with storage account using Client SDKs. But this is not correct.

You need only 1 key to perform any operation. You can copy the whole connection string from Azure Portal, which includes key, storage account name.

Below snapshot shows the access keys and the connection string of a storage account in Azure portal.

So the obvious question may be, why we have two keys. Before coming to this question, you will have to note down a fact that these keys are like master keys. Anyone who has this key can perform any operation on your storage account. So you may not want to provide these keys to everyone.

Also, you may want to regenerate this keys periodically to avoid any compromise.

So the two keys are provided to make sure that you can regenerate the keys without having any downtime. Microsoft recommends that you should only use 1 key in all your applications – at any given point of time.

Once you feel that you need to regenerate the key, you can update all applications to use key-2 instead of key-1. Once these configuration modifications are done, you can then regenerate the key-2.

Please note that the access keys cannot be automatically invalidated. They are valid until you regenerate them.

Shared Access Signatures

Sharing the access key of storage account is not a recommended practice as it grants complete access on the storage account. With shared access signatures, you can give only the required permissions to the clients who want to access data objects – that too only for required duration.

A Shared Access Signature is a set of query parameters appended to the URL pointing at the resource, which provides information about the access allowed and the length of time for which the access is permitted.

You can create a SAS which can work at the storage account level, or you can create the Shared access signatures at the specific service (e.g. blob, table) level.

The shared access signatures are generated at the client level and Azure does not track them. So, 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.

The shared access signature is just appended to the resource URL like a query string.

Below snapshot shows how can you create the account level shared access signature. You can select services to which this will be applicable. The start and end time of its validity and key which can be used to sign the shared access signature. As stated earlier you can create it number of times, and Azure will not remember how many SAS you created.

Stored Access Policies

Let’s say you have application which is using shared access signature and the shared access signature is compromised. Now, how will you revoke access ?

It depends on how you created the shared access signature. If you directly created the shared access signature, then you there is no easy way to revoke it from Azure. Azure does not remember the signature or its validity. The only way to revoke is to regenerate the storage account access keys.

You will have to remember which key was used for creating the shared access signature (either key-1 or key-2). If you do not remember, then you will have to regenerate both keys. This may have significant impact on your application depending upon how many services are using these keys.

To solve this problem, instead of directly generating the shared access signature, you can generate stored access policy.

When you create stored access policy, Azure remembers it. So if you derive the shared access signature using stored access policy, it would be very easy to revoke it. You can just change the end time of policy to past time, or you can altogether delete the policy.

Below snapshot shows how can we derive the shared access signature from stored access policy using storage explorer. You have to specify the access policy name (“first” in this case) and then you are not required to enter any other input. For revoking, just delete “first” access policy from “myfirsttable”.

I hope this article helps you to understand some basic concepts about Azure storage security. Let me know your thoughts.