Azure Storage Services – Security

In this part of my Azure Storage series, let me cover some important security components in Azure Storage Services that may help you build more secure applications using cloud storage.

Contents

Storage Account Key
Shared Access Signatures
Azure Key Vault
Encryption
Conclusion

Author
Recent Posts

Follow me:

Anil Erduran

Anil Erduran is a principal consultant and subject matter expert for Hitachi Data Systems EMEA, based in London, UK. He is also a dual category Microsoft Most Valuable Professional in Cloud and Datacenter Management and Microsoft Azure. Anil can be found on Twitter @anil_erduran.

Follow me:

Storage Account Key

If you have read our Azure Storage Services series to this point, you may have noticed that I used storage account keys numerous times to access data objects in the storage account context. We use storage account keys to authenticate endpoints when accessing the account.

When you create your storage account for the first time, the account will generate two 512-bit storage account keys automatically. Having two different keys provides high availability for your applications when you want to regenerate keys without interruption. I recommend regenerating storage access keys regularly for security. However, that process requires good planning, because changing your access keys may affect the availability of your applications. This is the generally recommended process for generating your primary key:

Regenerate the second key, as your applications don’t actively use it.
In your application, change your storage access key to the second key.
Test your applications, if everything looks okay.
Regenerate the first key.

There are several ways to manage your storage account keys, including PowerShell, .NET, and Azure Portal.

Get AzureStorageKey cmdlet

Storage access keys in Azure Portal

Shared Access Signatures

As I mentioned before, your storage account key is the main authorization gate for your objects. But sharing your storage account key with clients or peers to give them limited access to objects in your storage account can backfire. The storage account key grants full administrative access to your storage account as well as all your resources in it.

You can use a Shared Access Signature (SAS) to provide delegated access to your objects in the storage account. SAS is basically a simple URI that includes token and resource information in the query parameters.

There are mainly two types of SASs:

Service-level SAS: Delegates access to a resource for one of the storage services: Blob, Queue, Table, or File.
Account-level SAS: Delegates access to all resources in one or more of the storage services.

Below are some of the important parameters you can use in an SAS URI:

Start Time: An optional parameter. This is the time at which the SAS becomes valid. (st)
Expiry Time: When specified, SAS is no longer valid after that time. (se)
Permission: Specifies what operations can be performed on the resources (read, write). (sp)
IP: IP address range to accept external requests. (sip)
Signature: Main encrypted parameter to authenticate SAS. It’s created by using other parameters. (sig)
Storage Resource: Specifies which storage resources will be accessed: Blob, File, Queue, or Table. (sr)
Protocol: Request protocol. (spr)

As we mentioned before, SAS is just an URI constructed from other parameters specified. Here is an example of an SAS URI:

https://myaccount.blob.core.windows.net/sascontainer/myfile01.txt?sv=2015-04-05&st=2016-08-16T22%3A18%3A26Z&se=2016-08-20T02%3A23%3A26Z&sr=b&sp=rw&sip=192.168.1.1-192.168.1.15&spr=https&sig=Z%2FDUUn03q2rqI3OlWTskdb%33U&%3

Azure Storage PowerShell module has various cmdlets to create SAS tokens for different services:

PowerShell commands related to SAS

You can set permissions for container-level resources in your Blob storage service. I have a Blob container named Container001 and want to delegate access using SAS tokens. You can use New-AzureStorageBlobSASToken for that purpose:

Creating a new Blob SAS token

This simple script creates a new SAS token that will be effective immediately and expiry 10 hours later. Also, it provides read/write and delete access to the entities. In this case, you need to be careful about the start time. If you decide to set the start time to “now,” there may be some failures due to time zone differences.

You can also create two different types of SAS URI. Ad Hoc SAS: Using ad hoc SAS, you can specify parameters such as start time, expiry time, permissions, etc., in the URI and delegate access to a specific resource. It’s a best practices to use near-term expiration times, so that even if your SAS is compromised, it will only be available for a short time.

SAS with stored access policy: You can also create a stored access policy and define parameters. Then you can generate an SAS and associate this SAS with the policy you created earlier. This SAS will inherit all the parameters from the policy you created. The best thing about stored access policies is the option to revoke delegated permissions without having to regenerate storage account keys.

Once the expiry time on an SAS or stored access policy is reached, access to resources will be revoked.

Azure Key Vault

Azure Key Vault is an Azure service to help you encrypt and keep keys and secrets, including storage account keys, data encryption keys, .PXF files, etc. It’s a great way to maintain keys and grant permissions to these keys in minutes.

From an Azure Storage Security perspective, you can put your storage account keys into Azure Key Vault and service them from here to your clients and applications. That will help your applications retrieve access keys directly from Vault. When you regenerate your primary or secondary storage key in Vault, applications will retrieve updated keys without redeploying them.

Another key benefit of using Azure Key Vault is the ability to control access with Azure Active Directory. Once you decide to keep your Azure storage keys in Azure Key Vault, you can grant access to the Azure Vault for your Azure Active Directory users. When your application or service needs to access the resources in a storage account, they need to try to retrieve access keys from Azure Key Vault, depending on the AD permissions.

Once you create Azure Key Vault and configure your storage keys to be kept in Vault, you need to grant read access to your AD user using the Set-AzureRMKeyVaultAccessPolicy cmdlet.

PS C:\> Set-AzureRmKeyVaultAccessPolicy -VaultName 'Contoso03Vault' -UserPrincipalName 'PattiFuller@contoso.com' -PermissionsToSecrets 'Get,List'

You can also easily revoke granted access with the Remove-AzureRMKeyVaultAccessPolicy cmdlet.

PS C:\> Remove-AzureRmKeyVaultAccessPolicy -VaultName 'Contoso03Vault' -UserPrincipalName 'PattiFuller@contoso.com'

Encryption

Azure Disk Encryption is an existing feature used to encrypt the OS and data disks in Azure virtual machines.

Other than that, you can use the Storage Service Encryption (SSE) feature, which is a new Azure Storage Services feature that provides auto-encryption for the data written to Azure Storage. This is a storage account-level setting and encrypts all the data within the storage account once it’s enabled.

One important point is that this feature is only available for block, page, and append Blobs. Currently, tables, queues and files are not supported. Blob support also means that you can encrypt OS and data disks for Azure virtual machines.

When you enable this feature, the service will start to encrypt all the data written to Blob storage and will not impact existing data.

Enabling this feature is quite straightforward; it is only available for new standard/premium storage accounts created with the Azure Resource deployment model.

On the Azure Portal, you can select Encryption -> enabled to enable SSE.

Enable SSE on Azure Portal

As this is a preview feature, you need to sign up and wait for the confirmation email to enable it.

If you want to enable the feature programmatically, you need to use “Update Storage Account” REST API.

https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{accountName}?api-version={api-version}

In the request body parameters, you can use “encryption” property.

"encryption": {    "services": {        "blob": {             "enabled":true }    },    "keySource": "Microsoft.Storage"}

Conclusion

I tried to give you an overview of security capabilities for Azure Storage Services. In summary, you can use RBAC and Azure Active Directory to grant permissions for different levels of service. You can use encryption for the data in transit or for the data written to Azure Storage using SSE.

You can keep your sensitive storage access keys in Azure Key Vault. SAS tokens allow you to provide delegated access to the objects.