Securing Azure Blob Storage: Set-Up Guide

Security is vital in today’s cloud-first environment. Cloud services are often enabled to solve an issue quickly, but no one goes back to verify if security best practices have been followed. One particular cloud service that is often misconfigured is cloud storage like Azure Blob storage.

In this article, you’ll learn more about the security features available to you to secure your Azure Blob storage.

• What is Azure Blob Storage? 
• Meeting Encryption Requirements
• Utilizing Access Keys
• Generating Shared Access Signatures (SAS)
• Integrating with Azure Active Directory
• Managing Anonymous Access
• Configuring the Storage Account Firewall

What is Azure Blob Storage?

Azure Blob storage is a cloud-optimized storage solution for unstructured (file) data. Microsoft designed the service for the storage of massive amounts of unstructured data, non-database. 

Examples of unstructured data include text and binary data, such as images, videos, pictures, and documents. The word “Blob” itself is an industry-wide acronym for Binary Large OBject.

Azure Blob storage is a component of an Azure storage account. Storage accounts also provide storage for other data objects, like file shares, queues, tables, and disks. Storage accounts organize a set of blobs into containers, similar to a directory or folder in a file system. Storage accounts can have unlimited containers, and containers can store an unlimited number of blobs.

Securing access to your Blob storage is a critical step for any Azure administrator or engineer. The following sections outline available security features to help you configure your Blob storage to meet your requirements.

Meeting Encryption Requirements

Azure Storage encrypts your data using server-side encryption. This encryption method protects your data and helps you meet any organizational security and compliance requirements. Azure automatically enables encryption for all storage accounts, and it cannot be disabled. Storage accounts support encryption across all performance tiers, access tiers, and redundant copies.

By default, storage accounts encrypt the data using Microsoft-managed keys. You can continue using these Microsoft-managed keys for data encryption, or you can manage encryption using your keys.

If you choose to use your own encryption keys, you have two options, and you can use either type of key management or both.

• Use a customer-managed key. These keys must be stored in an Azure Key Vault.
• Use a customer-provided key. These keys are used for Blob storage operations. A client who makes read or write requests against Blob storage can use an encryption key on the request. This method provides granular control over how blob data is encrypted and decrypted.

Check out the following table that compares key managed options for Azure Storage encryption.

To configure a storage account to use a customer-managed key stored in a Key Vault:

1. Create a Key Vault if you don’t have an existing one available. Check out this quickstart on creating a key vault using the Azure portal.
   
   If creating a new Key Vault, place the Key Vault in the same region as the storage account and enable purge protection. If you have an existing key vault, go to the Key Vault’s Settings, then choose Properties to enable purge protection.
2. In the storage account, navigate to Security + Networking, then choose Encryption.
3. For Encryption type, select the radio button for Customer-managed keys.
4. For the Key selection, ensure the Select from key vault value is selected, then choose the link for Select a key vault and key.
   
5. In the Select a key step, select the subscription, key store type, and key vault to store the customer-managed encryption key.
   
   If you have an existing key stored in the key vault, select the key from the dropdown. Otherwise, select Create a new key. This tutorial is going to create a new key.
   
6. In the Create a key step, select the Generate option, give the key a descriptive name, choose the key type and size, and set any activation and expiration dates. Ensure Enabled is set to Yes, then click Create.
7. 
   
8. In the Select a key window, ensure the newly created key is selected in the Key dropdown, then click Select.
9. Back in the Encryption settings, click Save.

Utilizing Access Keys

Storage accounts have two 512-bit access keys used to authorize access to storage account data. These account keys are essentially root access to the storage account. You should use the account keys sparingly and treat these access keys like a highly sensitive password. Microsoft recommends storing access keys in an Azure Key Vault and then using available commands and APIs to access the account keys via the Key Vault.

To view your current access keys, navigate to the storage account resource. Under Security + networking, select Access keys. Here you can view key1 and key2 for the storage account by selecting the Show keys icon. When the key value is no longer hidden, you can copy the key value to the clipboard.

Each key also has the option to rotate or generate a new key. Microsoft recommends regularly rotating keys or if you suspect the key has been compromised. You should avoid widely distributing keys to other users, hard-coding keys in a script or application, or saving the key in plain text.

Generating Shared Access Signatures (SAS)

Shared access signatures, or SAS, are a lot like access keys. SAS provides access to storage account resources, but you have more granular control over that access. You can control what resources they have access to, what permissions they have on those resources, and how long they have access to the resources.

Azure Storage supports three kinds of shared access signatures:

• User delegation SAS: Secured using Azure Active Directory credentials and also permissions specified for the SAS. SAS applies to Blob storage only.
• Service SAS: Secured using the storage account access key (outlined in the previous section). Service SAS provides access to resources only in Blob storage, Queue storage, Table storage, or Azure Files.
• Account SAS: Also secured using the storage account access key. Account SAS delegates access to resources in one or more storage services. You can also delegate to service-level operations as well as read, write, and delete operations not available with Service SAS.

Shared access signatures work through a signed URI that includes a token and a set of query parameters. The token determines which resources the client can access. To create a shared access signature:

1. Navigate to the storage account resource in the Azure portal.
2. In the storage account, navigate to Security + networking, then choose Shared access signature.
3. In the Shared access signature pane, choose the storage account services and options the shared access signature should have. This example gives Read and List permissions to Blobs in a container. Always use the principle of least privilege when assigning permissions to a SAS.
   
4. Choose a start and end time for how long the SAS should be valid.
5. If needed, you can also limit what IP addresses can send requests to the storage account using the SAS.
6. As a best practice, only allow the HTTPS protocol when using the SAS URI.
7. Finally, choose which access key to sign the shared access signature. If you revoke the access key, any shared access signature created from the access key is invalidated.
8. Once you configured all the options, select Generate SAS and connection string.
9. The wizard produces three options for using the SAS: a connection string for applications, a SAS token, and a Blob service SAS URL.
   

Integrating with Azure Active Directory

In addition to access and shared access signatures, Azure Storage supports Azure Active Directory (AD) to authorize client requests to storage. You can use role-based access control (RBAC) to grant permissions to a user, group, or application service principal. Examples of roles include:

• Storage Blob Data Owner
• Storage Blob Data Contributor
• Storage Blob Data Reader
• Storage Blob Delegator

Azure AD returns an OAuth 2.0 token when authenticating the client, and the client uses this token to access Blob storage.

Using Azure AD for authorizing requests against Azure Blob storage is better than access keys and SAS. Clients use their existing accounts, and you ensure the client access the Blob storage with the minimum required privileges. Using Azure AD also prevents shared access keys and SAS URIs from falling into the wrong hands.

To read more about misconfigured cloud privileges, check out Varonis’ 2021 SaaS Risk Report available here!

To assign a user or client access using Azure AD:

1. Navigate to the storage account in the Azure portal
2. Navigate to Access Control (IAM) for the storage account. Alternatively, you can navigate to Data Storage > Containers and choose a specific container to give a client access.
3. In the Access Control (IAM) window, select Add, then Add role assignment from the menu.
   
4. Select one of the Storage Blob roles mentioned earlier in this section in the Add role assignment window.
5. Search for the name of the user, group, or service principal and select the account(s) from the results.
   
6. Once all users have been selected, click Save.

Managing Anonymous Access

Containers and blobs in Azure Storage are a great way to host and share lots of data. By default, public access to Blob data is disabled and prohibited. Microsoft recommends disabling public access to a storage account unless you specifically require it.

Multiple data breaches trace back to incorrectly configured cloud storage accounts across Microsoft, AWS, and Google.

• Pharma Giant Pfizer Suffers Patient Data Leak Due to Cloud Misconfiguration
• ShinyHunters Leak 2.28M Dating Site Users’ Personal Info Online
• Microsoft’s Cloud Misconfiguration Blunder May Have Cost Them 63 GB of Sensitive Data

Learn how to set up and secure an AWS S3 bucket in Jeff Petters How to Use AWS S3 Securely: Setup Guide.

When you disallow public Bloc access for the storage account, Azure rejects anonymous requests coming to it. When you disallow public access, you cannot enable public access for any containers within the account. If your storage account contains a mixture of containers, some are requiring public while some do not, Microsoft recommends moving public containers to a separate storage account dedicated to public access.

To verify your Blob public access configuration, navigate to Settings, then select Configuration in the storage account. Look for the setting Allow Blob public access and ensure it is set to Disabled.

Enabling Secure Client Communication

Azure storage accounts have additional settings to enforce secure communication with client applications. You can find these settings by navigating to Settings, then selecting Configuration.

• Secure transfer required: Requires the use of the HTTPS protocol by client applications. When enabled, the storage account rejects any communication using HTTP.
• Minimum TLS version: Azure encrypts client communication using Transport Layer Security (TLS). This setting enforces higher versions of the TLS protocol, currently at v1.2. Client communication using older versions of TLS is rejected.

Configuring the Storage Account Firewall

Azure storage accounts have several networking components that you use to secure access. One of these is the storage account firewall. The firewall consists of network rules that specify which network resources can access the storage account. These network resources include IP addresses, IP ranges, subnets in an Azure Virtual Network (VNet), or resource instances of some Azure services.

By default, the storage account is accessible from all networks. To change this setting, navigate to the storage account resource. From there, go to Security + networking, then choose Networking. Here there are two options: All networks and Selected networks.

To limit access to specific networks, select the Selected networks radio button. From here, you select an existing virtual network or create a new virtual network to add to the list. You can also add an IP address or CIDR range, such as a specific server or your on-premises network.

Finally, you can specify Azure resources instances that have access to the storage account. Azure resources include servers, Key Vaults, and data factories.

Closing

Azure Blob storage contains many settings and features for securing your data. This article highlighted only a few of the options available to you. For a complete list of security settings and options, check out this Microsoft Doc’s article Security recommendations for Blob storage.