10.1 Storage Account Security & Access Controls

6.4 Storage Account Security & Access Controls

Azure Storage accounts host critical enterprise data across Blobs, Files, Queues, and Tables. Securing storage assets requires enforcing robust authentication controls, eliminating legacy access keys, implementing double encryption at rest, guaranteeing data immutability for compliance, and enabling real-time threat protection.

---

Storage Authentication & Access Control Hierarchy

Azure Storage supports multiple authentication mechanisms ranging from legacy shared keys to modern Zero Trust Entra ID governance.

+-----------------------------------------------------------------------------------+
|                    STORAGE ACCOUNT ACCESS CONTROL HIERARCHY                       |
+-----------------------------------------------------------------------------------+
|  1. Shared Key Access (Root Key 1 & 2) ----> Full Account Admin Access (High Risk)|
|  2. Account & Service SAS (Key Signed) ----> Delegated URI Access (Medium Risk)   |
|  3. User Delegation SAS (Entra Signed) ----> OAuth Signed, Keyless (Low Risk)     |
|  4. Microsoft Entra ID Azure RBAC -------> Keyless, Fine-Grained (Recommended)   |
+-----------------------------------------------------------------------------------+

Account Access Keys

Every storage account generates two 512-bit master access keys (key1 and key2). Presenting an access key grants full administrative and data plane control over every service and container within the storage account.

• Risk Vector: Access keys cannot be scoped by permission, expiration, or resource path. If leaked, an attacker gains complete control.
• Key Rotation: Managed key rotation requires updating application configuration to use key2, rotating key1, switching applications back to key1, and rotating key2.

Disabling Shared Key Access (allowSharedKeyAccess = false)

To enforce a Zero Trust identity model, organizations should explicitly disable account key authentication by setting allowSharedKeyAccess = false on the storage account configuration:

• Enforced Result: Any incoming data plane request authenticated via storage account keys or SAS tokens signed with account keys is rejected by Azure Storage.
• Mandatory Entra ID Authentication: Forces all client applications and users to authenticate using Microsoft Entra ID credentials (via Azure RBAC roles such as Storage Blob Data Contributor or Storage Blob Data Reader).

Shared Access Signatures (SAS) Comparison

A Shared Access Signature (SAS) is a signed URI string granting constrained access rights to storage resources:

Stored Access Policies

A Stored Access Policy is defined on a specific blob container or file share (up to 5 policies per container). Linking a Service SAS to a Stored Access Policy provides centralized management:

• Allows administrators to modify SAS start time, expiration time, or permissions without reissuing SAS strings.
• Enables instant revocation of issued SAS tokens by deleting or modifying the underlying Stored Access Policy.

---

Encryption Architecture: SSE, CMK & Infrastructure Encryption

All data written to Azure Storage is automatically encrypted at rest using 256-bit AES Server-Side Encryption (SSE).

Platform-Managed vs. Customer-Managed Keys (CMK)

• Platform-Managed Keys (PMK): Keys are generated, rotated, and managed automatically by Microsoft.
• Customer-Managed Keys (CMK): Keys are stored in Azure Key Vault or Managed HSM. Enables customer key rotation, access revocation (by disabling key access), and cryptographic audit logging.

Infrastructure Encryption (Double Encryption)

Infrastructure Encryption adds a second, independent layer of AES-256 hardware-level encryption at the physical storage infrastructure layer:

• Data is encrypted twice using two different encryption keys and algorithms (one at the service layer, one at the storage infrastructure layer).
• Must be enabled at storage account creation time (requireInfrastructureEncryption = true) and cannot be disabled later.

---

Immutable Blob Storage for WORM Compliance

Immutable Blob Storage enforces Write Once, Read Many (WORM) compliance for financial and legal mandates (e.g., SEC Rule 17a-4, FINRA 4511).

+-----------------------------------------------------------------------------------+
|                         IMMUTABLE BLOB POLICY STATES                              |
+-----------------------------------------------------------------------------------+
|  +-----------------------------------------------------------------------------+  |
|  | Legal Hold: Indefinite immutability, set/cleared by authorized users.       |  |
|  +-----------------------------------------------------------------------------+  |
|  | Time-Based Retention Policy (Unlocked): Retention period active; changeable.|  |
|  +-----------------------------------------------------------------------------+  |
|  | Time-Based Retention Policy (LOCKED): IMMUTABLE! Retention period CANNOT be |  |
|  | reduced or deleted by ANY user, Subscription Owner, or Microsoft Support.   |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

1. Time-Based Retention Policies

Retains blob data immutably for a designated duration (e.g., 2,555 days for 7 years):

• Unlocked State: The retention policy can be tested, extended, shortened, or removed.
• Locked State: Once a time-based policy is explicitly Locked:
  • The retention period cannot be shortened or removed by any user.
  • Data within the container cannot be modified, overwritten, or deleted by anyone—including Subscription Owners, Global Administrators, or Microsoft Support—until the retention period expires.

2. Legal Holds

A Legal Hold is an indefinite immutability lock applied during active litigation or audits. Unlike locked time-based policies, a Legal Hold can be cleared by users possessing the Storage Blob Data Owner role once litigation resolves.

---

Defender for Storage Threat Protection

Microsoft Defender for Storage provides advanced AI-driven threat intelligence and real-time security monitoring for blob containers:

Malware Scanning on Upload

• Agentless In-Line Scanning: Automatically scans newly uploaded blobs for malware in near-real-time without requiring host agents.
• Automated Quarantine Workflows: If malware is detected, Defender tags the blob's Index Tags (e.g., MalwareScanningResult = Malicious), enabling Event Grid topics to trigger automated quarantine or deletion workflows.

Sensitive Data Threat Detection & Anomaly Monitoring

Detects suspicious access patterns, including:

• Unusual data exfiltration spikes or anonymous access attempts.
• Access originating from known malicious IP addresses or Tor exit nodes.
• Compromised credential usage patterns.