Apply Zero Trust principles to Azure storage

Article
04/12/2024

Summary: To apply Zero Trust principles to Azure storage, you must protect data (at rest, in transit, and in use), verify users and control access, separate or segregate critical data with network controls, and use Defender for Storage for automated threat detection and protection.

This article provides steps to apply the principles of Zero Trust to Azure Storage:

Zero Trust principle	Definition	Met by
Verify explicitly	Always authenticate and authorize based on all available data points.	Verify user credentials and access.
Use least privileged access	Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data protection.	Control access to storage data with least privileges.
Assume breach	Minimize blast radius and segment access. Verify end-to-end encryption and use analytics to get visibility, drive threat detection, and improve defenses.	Protect data at rest, data in transit, and data in use. Separate critical data with network controls. Use Defender for Storage for automated threat detection and protection.

This article is part of a series of articles that demonstrate how to apply the principles of Zero Trust across an environment in Azure that includes Azure Storage services to support an IaaS workload. For an overview, see Apply Zero Trust principles to Azure infrastructure.

Storage architecture in Azure

You apply Zero Trust principles for Azure Storage across the architecture, from the tenant and directory level down to the storage container at the data layer.

The following diagram shows the logical architecture components.

In the diagram:

The storage account for the reference architecture is contained in a dedicated resource group. You can isolate each storage account in a different resource group for more granular role-based access controls (RBAC). You can assign RBAC permissions to manage the storage account at the resource group or resource group level and audit these with Microsoft Entra ID logging and tools such as Privileged Identity Management (PIM). If you're running multiple applications or workloads with multiple corresponding storage accounts in one Azure subscription, it is important to limit each storage account's RBAC permissions to its corresponding owners, data custodians, controllers, etc.
Azure storage services for this diagram are contained within a dedicated storage account. You can have one storage account for each type of storage workload.
For a broader look at the reference architecture, see the Apply Zero Trust principles to Azure IaaS overview.

The diagram doesn't include Azure Queues and Azure Tables. Use the same guidance in this article to secure these resources.

What's in this article?

This article walks through the steps to apply the principles of Zero Trust across the reference architecture.

Step	Task	Zero Trust principle(s) applied
1	Protect data in all three modes: data at rest, data in transit, data in use.	Assume breach
2	Verify users and control access to storage data with least privileges.	Verify explicitly Use least privileged access
3	Logically separate or segregate critical data with network controls.	Assume breach
4	Use Defender for Storage for automated threat detection and protection.	Assume breach

Step 1: Protect data in all three modes: data at rest, data in transit, data in use

You configure most of the settings for protecting data at rest, in transit, and in use, when you create the storage account. Use the following recommendations to be sure you configure these protections. Also consider enabling Microsoft Defender for Cloud to automatically evaluate your storage accounts against the Microsoft cloud security benchmark that outlines a security baseline for each Azure service.

For more information on these storage security controls, see here.

Use encryption in transit

Keep your data secure by enabling transport-level security between Azure and the client. Always use HTTPS to secure communication over the public internet. When you call the REST APIs to access objects in storage accounts, you can enforce the use of HTTPS by requiring Secure Transfer Required for the storage account. Any request originating from an insecure connection is rejected.

This configuration is enabled by default when you deploy a new Azure Storage Account (Secure by Default).

Consider applying a policy to deny the deployment of insecure connections for Azure Storage (Secure by Design).

This configuration also requires SMB 3.0 with Encryption.

Prevent anonymous public read access

By default, public blob access is prohibited, but a user with the proper permissions can configure an accessible resource. To prevent data breaches from anonymous access, you should specify who has access to your data. Preventing this at the storage account level prevents a user from enabling this access at the container or blob level.

For more information, see Prevent anonymous public read access to containers and blobs.

Prevent shared key authorization

This configuration forces the storage account to reject all requests made with a shared key and require Microsoft Entra authorization instead. Microsoft Entra ID is a more secure choice as you can use risk-based access mechanisms to harden access to data tiers. For more information, see Prevent Shared Key authorization for an Azure Storage account.

You configure data protection for all three modes from the configuration settings of a storage account, as shown here.

These settings can't be changed after you create the storage account.

Enforce a minimum required version of transport layer security (TLS)

The highest version Azure Storage currently supports is TLS 1.2. Enforcing a minimum TLS version rejects requests from clients using older versions. For more information, see Enforce a minimum required version of TLS for requests to a storage account.

Define the scope for copy operations

Define the scope for copy operations to restrict copy operations to only those from source storage accounts that are within the same Microsoft Entra tenant or that have a Private Link to the same virtual network (VNet) as the destination storage account.

Limiting copy operations to source storage accounts with private endpoints is the most restrictive option and requires that the source storage account has private endpoints enabled.

You configure a scope for copy operations from the configuration settings of a storage account, as shown here.

Understand how encryption at rest works

All data written to Azure Storage is automatically encrypted by Storage Service Encryption (SSE) with a 256-bit Advanced Encryption Standard (AES) cipher. SSE automatically encrypts data when writing it to Azure Storage. When you read data from Azure Storage, Azure Storage decrypts the data before returning it. This process incurs no additional charges and doesn't degrade performance. Using customer-managed keys (CMK) provides additional capabilities to control rotation of the key encryption key or cryptographically erase data.

You enable CMK from the Encryption blade when creating a storage account, as shown here.

You can also enable infrastructure encryption, which provides double encryption at both the service and infrastructure levels. This setting can't be changed after you create the storage account.

Note

In order to utilize a customer-managed key for storage account encryption, you must enable it during account creation and you should have a Key Vault with Key and Managed Identity with appropriate permissions already provisioned. Optionally, 256-bit AES encryption at the Azure Storage infrastructure level can also be enabled.

Step 2: Verify users and control access to storage data with the least privileges

First, use Microsoft Entra ID to govern access to storage accounts. Using Role-based Access Control with Storage Accounts allows you to granularly define access based job function using OAuth 2.0. You can align your granular access to your Conditional Access Policy.

It is important to note that roles for storage accounts must be assigned at either the management or data level. Thus, if you're using Microsoft Entra ID as the authentication and authorization method, a user should be assigned the appropriate combination of roles to give them the least amount of privilege necessary to complete their job function.

For a list of Storage Account Roles for granular access see Azure built-in roles for Storage. RBAC assignments are done through the Access Control option on the Storage Account and can be assigned at various scopes.

You configure access control from the Access Control (IAM) settings of a storage account, as shown here.

You can check the access levels of users, groups, service principals, or managed identities and add a role assignment.

Another way to provide permissions that are time-bound is through Shared Access Signatures (SAS). Best Practices when using SAS at a high level are the following:

Always use HTTPS. If you have deployed the suggested Azure Policies for Azure landing zones, secure transfer via HTTPS will be audited.
Have a revocation plan.
Configure SAS expiration policies.
Validate permissions.
Use a user delegation SAS wherever possible. This SAS is signed with Microsoft Entra credentials.

Step 3: Logically separate or segregate critical data with network controls

In this step, you use the recommended controls to protect the network connections to and from Azure Storage services.

The following diagram highlights the network connections to the Azure Storage services in the reference architecture.

Task	Description
Prevent public access, create network segmentation with Private Endpoint and Private Link.	Private endpoint allows you to connect to services with the use of a single private IP address on the VNet using Azure Private Link. Enabling private endpoints allows the Azure platform to validate network connections and allow only the connection with explicit access to the private-link resource to gain access to subsequent resources. You'll need a separate private endpoint for each service on the Azure Storage Account.
Use Azure Private Link	Use Azure Private Link to access Azure Storage over a private endpoint in your VNet. Use the approval workflow to automatically approve or manually request, as appropriate.
Prevent public access to your data sources using Service Endpoints	You can do network segmentation using Service Endpoints by enabling private IP addresses in a VNet to reach an endpoint without using public IP addresses.

You configure private endpoints from the Networking settings of a storage account, as shown here.

Step 4: Use Defender for Storage for automated threat detection and protection

Microsoft Defender for Storage provides that additional level of intelligence that detects unusual and potentially harmful attempts to exploit your storage services. Microsoft Defender for Storage is built into Microsoft Defender for Cloud.

Defender for Storage detects anomalous access pattern alerts such as:

Access from unusual locations
Application Anomaly
Anonymous access
Anomalous extract/upload alerts
Data Exfiltration
Unexpected delete
Upload Azure Cloud Service package
Suspicious storage activities alerts
Access permission change
Access Inspection
Data Exploration

For more information about threat protection across the reference architecture, see the Apply Zero Trust principles to Azure IaaS overview.

Once enabled, Defender for Storage notifies you of security alerts and recommendations for improving the security posture of your Azure storage accounts.

Here's an example security alert for a storage account with a description of the alert and prevention measures highlighted.

Recommended training

Configure Storage security

Training	Configure Storage security
	Learn how to configure common Azure Storage security features like storage access signatures. In this module, you learn how to: Configure a shared access signature (SAS), including the uniform resource identifier (URI) and SAS parameters. Configure Azure Storage encryption. Implement customer-managed keys. Recommend opportunities to improve Azure Storage security.

Start >

For more training on security in Azure, see these resources in the Microsoft catalog:
Security in Azure | Microsoft Learn

Next Steps

See these additional articles for applying Zero Trust principles to Azure:

Technical illustrations

This poster provides a single-page, at-a-glance view of the components of Azure IaaS as reference and logical architectures, along with the steps to ensure that these components have the "never trust, always verify" principles of the Zero Trust model applied.

Item	Description
PDF \| Visio Updated March 2024	Use this illustration together with this article: Apply Zero Trust principles to Azure IaaS overview Related solution guides Virtual machines Spoke VNets Hub VNets

This poster provides the reference and logical architectures and the detailed configurations of the separate components of Zero Trust for Azure IaaS. Use the pages of this poster for separate IT departments or specialties or, with the Microsoft Visio version of the file, customize the diagrams for your infrastructure.

Item	Description
PDF \| Visio Updated March 2024	Use these diagrams together with the articles starting here: Apply Zero Trust principles to Azure IaaS overview Related solution guides Virtual machines Spoke VNets Hub VNets

For additional technical illustrations, click here.

References

Refer to the links below to learn about the various services and technologies mentioned in this article.