11 configurations you must make to secure your Azure Storage Accounts

Storage accounts are often the security weak point in an Azure environment. You must actively harden them against insider threats, data exfiltration, and external attack vectors.

Data protection in Azure must be layered. To truly secure your data, you need a defense-in-depth strategy that covers authentication, network isolation, encryption, and recovery.

I have compiled this 11-point non-negotiable checklist to help you lock down your Azure Storage Accounts. These configurations cover the critical control plane and data plane settings you need to implement today.

1. Set “Allow storage account key access” to Disabled

Why it matters: This is arguably the single most important action on this list. Storage Account Keys (and the connection strings derived from them) provide full, unrestricted access to your data. If a key is leaked or checked into code, an attacker has total control.

The Fix: Set Allow storage account key access to Disabled. This eliminates static secrets entirely and forces all applications and users to authenticate using Microsoft Entra ID, which supports MFA, conditional access, and identity lifecycle management.

2. Set “Allow Blob anonymous access” to Disabled

Why it matters: Anonymous access is a common cause of high-profile data leaks. It allows unauthenticated users to access data via public URLs.

The Fix: Set Allow Blob anonymous access to Disabled. This ensures that absolutely no data can be read without a verified identity, closing the door on accidental public exposure.

3. Set “Default to Microsoft Entra authorization in the Azure portal” to Enabled

Why it matters: By default, the Azure Portal might try to use the Storage Account Key to list containers and blobs for you. This creates a reliance on the keys we just tried to disable in step 1.

The Fix: Set Default to Microsoft Entra authorization in the Azure portal to Enabled. This forces the Azure Portal to use your personal Entra ID credentials for browsing data, ensuring that your audit logs accurately reflect who accessed the data, rather than just showing “Account Key.”

4. Set “Secure transfer required” to Enabled

Why it matters: Data in transit is vulnerable to interception (Man-in-the-Middle attacks) if unencrypted protocols are allowed.

The Fix: Set Secure transfer required to Enabled. This configuration rejects all requests made over HTTP and forces every data transfer to use HTTPS, ensuring encryption in transit.

5. Set “Minimum TLS version” to the highest version available (e.g., 1.2)

Why it matters: Older security protocols like TLS 1.0 and 1.1 have known vulnerabilities and are being deprecated by major industry standards.

The Fix: Set Minimum TLS version to Version 1.2 (or 1.3 if available). This ensures your storage account automatically rejects connections from clients attempting to use legacy, insecure protocols.

6. Set “Permitted scope for copy operations” to Private Endpoint & same VNet

Why it matters: Data exfiltration often happens when a malicious insider or compromised identity copies data from your secure corporate storage account to their own personal, untrusted storage account.

The Fix: Change the Permitted scope for copy operations from “From any storage account” to a restricted scope, such as Specific Entra ID Tenant or PrivateLink. This prevents data from being copied to unauthorized external accounts.

7. Set “Public network access” to Disabled (or Secure by Perimeter)

Why it matters: Leaving your storage account accessible from the public internet increases your attack surface significantly.

The Fix: The most secure posture is to set Public Network Access to Disabled and rely exclusively on Private Endpoints (Private Link). This routes all traffic over the Microsoft backbone and keeps it entirely off the public internet. If that is not feasible, use the firewall to “Secure by perimeter,” restricting access to specific VNets or corporate IP ranges.

8. Set “Blob soft delete” & “Container soft delete” to Enabled & add Versioning

Why it matters: Security isn’t just about preventing access; it’s about resilience. Ransomware or accidental scripts can wipe data in seconds.

The Fix: Navigate to the Data Protection blade and enable Blob Soft Delete, Container Soft Delete, and Blob Versioning. These features act as a rigorous safety net, allowing you to recover data that was modified or deleted within a specified retention window (e.g., 7 to 14 days).

9. Prioritize Least Privilege RBAC

Why it matters: Granting broad roles like “Contributor” or “Owner” on a storage account is dangerous. It allows users to change firewall settings or delete the resource.

The Fix: Use specific Data Plane roles. For example, assign Storage Blob Data Reader to users who only need to read data. Avoid using “Storage Blob Data Contributor” unless write access is strictly necessary. Furthermore, always prefer Managed Identities for Azure services (like App Service or Functions) to avoid managing credentials altogether.

10. Enable Infrastructure Encryption during account creation

Why it matters: Standard Azure Storage encryption protects data at rest using Microsoft-managed keys. However, highly regulated industries often require a higher standard known as “double encryption.”

The Fix: Enable Infrastructure Encryption at the time of account creation. This adds a second layer of encryption at the infrastructure level, using a separate key and algorithm, providing defense in depth against a theoretical compromise of the primary encryption layer.

11. Add Management Locks for Read-only or CanNotDelete

Why it matters: Even with RBAC, mistakes happen. An admin might accidentally delete the wrong resource group, wiping out your critical storage account.

The Fix: Apply a CanNotDelete Management Lock to the storage account. This acts as a fail-safe, preventing the resource from being deleted—even by an owner—unless the lock is explicitly removed first.

Assurance: Governance & Monitoring

Implementing these 11 settings manually is a great start, but how do you ensure they stay that way?

1. Azure Policy: Use Azure Policy to enforce these configurations at scale. You can create policies that “Deny” the creation of storage accounts that do not have TLS 1.2 or Soft Delete enabled.
2. Microsoft Defender for Storage: Enable Defender to get automated alerts on anomalous behavior, such as unusual location access or potential malware uploads.
3. Diagnostic Logging: You can’t secure what you don’t monitor. Send your Activity Logs and Blob Diagnostic logs to a Log Analytics workspace to hunt for suspicious access patterns.

Check your current governance strategy against this list. How many of these 11 configurations are you enforcing today?