Azure Storage is a versatile service that underpins most of the Azure infrastructure. Because of its low cost and high elasticity, it’s one of the best ways to store many types of structured and unstructured data (BLOBs, tables and files) in the Cloud. However, the one aspect that is usually overlooked when setting up a system using Azure Storage is security. In this article, we will look at ways to secure Azure Storage data such as data encryption at rest and in transit. We will describe various mechanisms for controlling access to these resources.

Storage Account Keys

To begin with, there are two types of access, public and private, that apply to either containers or BLOBs that can be defined when they are created: Their effect can be one of three types of access because public access containers allow anonymous listing.

Storage Type	Access Type	Description
BLOB or Container	Private	Authenticated access only
BLOB	Public	Anonymous reading of fully-specified BLOBs
Container	Public	Anonymous listing and reading of container contents

Public access to BLOB and containers is usually configured for resources that need to be publicly accessible and don’t require any protection. These might include images and CSS files used by web applications. I left JavaScript files out of the list because they can be a security liability because any manipulation of these files can result in a compromise.

Private access means that resources can only be accessed using either the Master or Secondary Storage Account Keys.

You could, therefore, use the “private access” model to secure access to your storage account. Unfortunately, this approach is neither secure nor recommended. By using either the primary or secondary keys, the user gains full administrative access to the whole storage account. Therefore, having an application accessing the storage account using access keys would violate the ‘least privilege’ security principle. If your application is compromised, your whole account is susceptible to a malicious attack. Anyone with access to these keys is in control of the whole storage account and so can perform any operation. One way to mitigate this would be to frequently rotate the keys so that older keys (compromised or not) become invalid. However, this still doesn’t solve the problem because the new keys will have the same elevated privileges. Consequently, it’s generally recommended that these keys are never shared or even used by (un)trusted applications to access the storage account. We will go on to consider alternative ways that can create fine-grained access keys with limited permissions so that applications and users can access the data securely. But first, lets start with the security mechanisms that are already built-in to the Azure Storage service.

Encryption at Rest and in Transit

All communication with the Azure Storage via connection strings and BLOB URLs enforce the use of HTTPS, which provides Encryption in Transit. You can enforce the use of “Always HTTPS” by setting the connection string like this: “DefaultEndpointsProtocol=https;AccountName=myblob1…” or in SAS signatures, as in the example below:

https://myblob1.blob.core.windows.net/?sv=2015-04-05&ss=bfqt&srt=sco&sp=rwdlacup&se=2016-09-22T02:21:41Z&st=2016-09-21T18:21:41Z&spr=https&sig=hxInpKBYAxvwdI9kbBglbrgcl1EJjHqDRTF2lVGeSUU%3D

To protect data at rest, the service provides an option to encrypt the data as they are stored in the account. There’s no additional cost associated with encrypting the data at rest and it’s a good idea to switch it on as soon as the account is created. There is a one-click setting at the Storage Account level to enable it, and the encryption is applied on both new and existing storage accounts. The data is encrypted with AES 256 cipher and it’s now generally available to all Azure regions and Azure clouds (public, government etc)

Client-Side Encryption

The Azure Storage SDKs provide the option to further enhance security by encrypting data client-side using the built-in providers in the SDK. The API supports BLOB, table and queue storage encryption and uses AES-256 cipher to encrypt the data prior to sending them to Azure. The provider has the option to integrate with on-premises Key Management tools or Azure Key Vault.

Securing account management RBAC

it is fundamentally important that permissions to manage a Storage Account are properly managed. Azure Resource Manager (ARM) and Resource Based Access Control (RBAC) can be effectively used to lock down permissions to the account and ensure that only authorised users can access and manage the service. Since RBAC is driven by Azure AD, it’s very easy to implement organisation-wide security policies that can be managed centrally. The Storage resource provider permissions are listed below:

Roles can be assigned to a specific user account, a group of users, or to a specific application. Roles can be assigned to a specific user account, a group of users, or to a specific application. To further extend the flexibility of the RBAC security model, you can create custom roles composed of a set of actions from a list of available actions that can be performed on Azure resources. For user access to be managed with RBAC, the user needs to be present in Azure AD. Finally, because all user activity is logged in Azure, you can use tools such Azure Monitor and Log Analytics to monitor and report on user actions, hence improving security and compliance.

Enforcing default security settings with ARM templates

With the recent introduction of better resource management policies, and an easier management model in the Portal, you can enforce security default settings within your ARM templates. For example, you could force all Storage Accounts Containers to be created with private access and any other access to be forbidden by default. This way, no one should be able to create new storage accounts with public access switched on accidentally.

Securing access using SAS tokens

The use of Shared Access Signature (SAS) tokens is the best mechanism for defining and granting truly fine-grained and manageable access to storage accounts. This is because SAS tokens can grant limited, action-specific, privileges with explicit expiration and easy revocation. Once issued, the authorisation token must be supplied with the request or operation (URL or SDK).

Below is a sample SAS-based request (SAS highlighted) and a breakdown of each parameter

https://myaccount.blob.core.windows.net/mycontainer/myblob?sv=2015-04-05&ss=b&srt=o&sp=r&se=2016-09-30T23:57:53Z&st=2016-09-14T15:57:53Z&spr=https&sig=BWLBIFazbsn96gJl2I0wKjkRRBaH9qvtF5qtsluulPk%3D

Based on this breakdown it’s easy to understand how SAS tokens can make access particularly explicit, and mapped only to a specific operation. To improve the usability of SAS tokens, there’s an option to store the Access Policy separately. This allows for separation of concern between the access policy and the SAS. It also allows for the modification and revocation of permissions even after the SAS has been issued. Each container, table and queue can have up to five stored access policies. An example SAS-based request with stored access policy is provided below:

https://myaccount.blob.core.windows.net/mycontainer/myblob?sv=2015-04-05&si=readonlypolicy&sig=GFC…lPk%3D

SAS is supported by the following Storage account types:

• BLOB
• File
• Queue
• Table

To generate a SAS you can use one of the following methods:

• Azure Portal
• Azure Storage Explorer
• PowerShell
• Azure CLI
• Azure SDK (.NET, Node.js etc)

Below is an example of creating a SAS through the portal

Notice that SAS also support IP white-listing to further enhance security.

Securing access with CORS

Cross Origin Resource Sharing (CORS) can be used in conjunction with the other policies to lock down access to storage resources. CORS is a W3C standard that allows web sites to grant exceptions to permit resource access from external domains. For example, if your API runs under the contoso.com domain, only those other sites that are under the same domain can access the API. To allow external access, CORS access needs to be configured. Browsers by default limit scripts to the “same origin”. Azure Storage service can be configured with CORS policies to enable cross-origin, browser-based applications.

Compliance and control using Storage Analytics

Azure Storage Analytics can be used for explicit logging and for storing data about metrics. Performance metrics of a storage account are important, especially when used in conjunction with Virtual Machines (VMs). You can also use the same metrics to troubleshoot various performance issues on a storage account.

Furthermore, logs of storage analytics can be used to enhance the security of your infrastructure and proactively monitor for suspicious activity. For example, with BLOB Storage, you can monitor whether an action used a Shared Access Signature or the storage account keys, or if the BLOB accessed was public.

This means that you can tightly guard access to storage. For example, if you’ve set all of the containers to private, and have enforce access through the use of an SAS, then a log entry that shows access using one of the storage account keys would indicate a security breach.

Summary

Azure Storage is central to Microsoft’s Azure infrastructure. Now that an increasing number of customers are trusting their data to the cloud, it’s important to choose a service that provides the appropriate tools to protect from unauthorized access and that allows us to set up policies that are able to monitor and identify irregular behavior. Throughout this article, we examined the various security features that are available on the Azure Storage Service, and we described the recommended practices that are used to ensure that your data remains protected both at rest and in transit.