10.3 Selecting and Configuring Access to Azure Blob Storage

Choosing an Authorization Method

The previous section catalogued what the authorization mechanisms are. This section is about choosing between them for a stated requirement, and about the two capabilities — data-plane roles and ABAC conditions — that make Microsoft Entra ID authorization precise enough to replace shared keys entirely.

The control-plane / data-plane trap

Assigning Owner or Contributor on a storage account does not grant access to blob data. Those are control-plane roles: they let the principal manage the account and, critically, read the account keys, which is an indirect path to the data. The data-plane roles are separate:

• Storage Blob Data Reader — read blobs and list containers.
• Storage Blob Data Contributor — read, write, delete.
• Storage Blob Data Owner — full access including POSIX ACL management on Data Lake Storage Gen2.

If a scenario says "the auditor must read blobs but must not be able to manage the account", assign Storage Blob Data Reader and nothing else. If it says "the operator must manage the account but must never read customer data", assign Contributor and set allowSharedKeyAccess = false so the indirect key path is closed.

---

Operational Rules for Shared Access Signatures

Beyond the SAS types themselves, four operational rules decide whether a SAS is safe:

1. A user delegation SAS has a maximum validity of seven days, tied to the lifetime of the delegation key. There is no way to issue a year-long user delegation SAS.
2. The permissions of a user delegation SAS are the intersection of the SAS grant and the signing identity's RBAC role. A Storage Blob Data Reader cannot mint a write SAS, which means SAS issuance cannot be used to escalate privilege.
3. A SAS expiration policy on the account defines a recommended maximum SAS lifetime and logs a diagnostic entry whenever a longer one is issued, turning "someone created a ten-year SAS" from an invisible event into a detectable one.
4. Always constrain a SAS with an allowed IP range and HTTPS-only protocol, and scope it to the single blob and single permission it needs. A SAS is a bearer credential in a URL — it will end up in a browser history, a proxy log, or a support ticket.

Revoking a user delegation SAS means revoking the delegation key (az storage account revoke-delegation-keys) or removing the signing identity's role; revoking a key-signed SAS means changing the stored access policy it references, or rotating the account key.

---

Attribute-Based Access Control Conditions

Azure ABAC adds conditions to a data-plane role assignment, evaluated by the storage service at request time:

• Restrict by blob path prefix, so one Storage Blob Data Contributor assignment covers only /finance/2026/ and nothing else in the container.
• Restrict by blob index tag, so a principal reaches only blobs tagged classification=public regardless of where they sit.
• Restrict by request attributes such as the operation being performed, or whether the request arrived over a private endpoint.

A condition is expressed against the request and resource attributes, for example allowing read only where @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs:path] starts with a given prefix.

ABAC turns "one role assignment per container" sprawl into a single assignment with a precise boundary, and it is the answer whenever a scenario needs sub-container granularity without creating dozens of assignments or splitting data across accounts. It also composes with the SAS rules above: a user delegation SAS minted by a condition-limited identity inherits that limit, because SAS permissions are the intersection of the grant and the signer's effective access.

---

Shutting Down the Weak Paths

These account-level settings are the practical hardening checklist, and each one closes a distinct bypass:

Note the interaction that catches people out: setting allowSharedKeyAccess = false breaks every existing service and account SAS, because those are signed with the account key. Inventory the consumers, migrate them to user delegation SAS or managed identities, and only then flip the switch — otherwise the change reads as an outage rather than a hardening win.

Encryption scopes belong in the same conversation. They apply a different key — including a customer-managed key in Key Vault — to an individual container or even an individual blob within one storage account. That lets a multi-tenant application isolate tenants cryptographically without provisioning one storage account per tenant, and it lets you revoke one tenant's access to their own data by disabling that scope's key.

Finally, monitor the paths you have not yet closed. Send StorageRead, StorageWrite, and StorageDelete diagnostic logs to Log Analytics and alert on any request where AuthenticationType == "AccountKey" once you believe key usage has been migrated away. That single query is the most reliable way to find the application nobody remembered before it breaks in production.