Previously in the series, we have concentrated on the types of storage accounts available and their various roles. Now we are going to look at how to ensure that your data is secure and only services you have authorized can access it.

Encryption

The data stored with Azure storage is encrypted at rest by default. The data is decrypted transparently when you or your authorized services access it. All data tiers and redundancy options have encryption enabled to ensure your data is secure. This encryption extends to the object metadata as well.

The default configuration uses a Microsoft service to manage the encryption keys for your storage accounts. This management is all done behind the scenes with no direct involvement. You can, however, enable customer-managed keys. This gives additional flexibility and auditing capabilities as required. These custom keys can be generated and managed using Azure Key Vault.

On top of the storage account encryption, full disk encryption is available for the virtual hard disks of your virtual machines. This also integrates into Azure Key Vault for managing the keys but uses industry-standard Full Disk Encryption technologies for the specific operating systems.

As previously discussed, the individual data objects can be accessed by URIs, so depending on your authorization policies, your data can be exposed directly to the internet.

Authentication

Depending on the usage of the storage accounts, there are various methods for authentication Microsoft provides so users or applications can access the information they are authorized to see.

Access Keys

For connecting to the azure storage account, Microsoft provides access keys. These can be used to authenticate your applications when requesting data from the storage accounts.

Microsoft highly recommends that you rotate these keys regularly to ensure you maintain security. To assist in this key rotation, Microsoft provides two sets of keys. As long as your application can cope with multiple connection strings, this means you can rotate one key while maintaining the connection to the data source using the second key.

AzureAD

For requests to Blob and Queue services, Microsoft also provides integration with Azure AD for identity-based authorization. You can grant access to individual queues or containers using the RBAC (role-based access control). This enables you to grant granular access (Owner, Contributor, Reader, or Delegator) to your storage accounts for specific Azure AD account.

Shared Access Signature (Delegated Access)

If you have clients or users that you do not want to trust with your full storage account keys but need to give access to specific resources, you can use a shared access signature (SAS). A SAS grants access to specific Azure storage resources in the form of a URI.

A SAS can be set at the account or service level, allowing access to the whole set of services or specifics resource types. Within the last 12 months, Microsoft has also introduced user delegation SAS which is additionally secured by Azure AD credentials.

If you use SAS access, you can use the access policies alongside the URI to control permissions and access times of the data resources under your control. Using an Access Policy allows you to set specific start and expiry times for accessing containers, file shares, queue, or tables.

Networking

In addition to using access keys for authentication to restrict access to your data, you can also use the Firewall and Virtual Network settings to restrict further access to specific networks and IP ranges.

As previously mentioned by default, a storage account can be accessed from anywhere on the Internet using the URI for the specific data containers. Using the firewall, you can restrict access to specific IP addresses or ranges, ensuring that only people from specific locations can access your data. There are also a few exceptions to note, the primary one to know about is “Allow trusted Microsoft services to access this storage account” this setting grants access to several Microsoft services, e.g., Azure Backup or Azure File Sync to access the storage account if they are deployed into the subscription.

To restrict access within the Azure subscription to a subset of your services, you can also place the storage account within a virtual network. This is a private IP space that enables various Azure resources to communicate securely with each other, and this private IP range can then be secured by a Network Security Group (NSG) to manage the ingress and egress rules.

For more information around various security options within Azure, I recommend the Skylines AZ-500 course. Dwayne and Nick go into much more detail around all the security features, including VNets and firewalls.

Example

We are now going to create a small environment with a storage account to explorer the various authentication methods.

Firstly, we need to create the test environment which comprises two VMs and storage account that share a single VNet. These components are placed in a single resource group along with any other resource to ensure quick clean up after completing the investigation.

There are many wises to create the required resources within Azure. You can use the UI, IaC technologies, i.e. ARM Templates (see the blog series from Shannon Kuehn), Terraform (see the Skylines Course about getting started with Terraform), or you can use the command line with either Azure CLI or PowerShell. Below are the steps using PowerShell.

1. Create Resource Group, Networking, and boot diagnostics storage account

Before we can create any of the Virtual Machines or Storage accounts, we need to create the Resource Group and the Networking components used by the azure services.