Stage 5 · Platform
Storage & Secrets
Storage Security
Private endpoints, SAS tokens, RBAC for storage, and immutable blobs.
Storage Security Model
Azure Storage security involves multiple layers: network access control (firewalls, private endpoints), identity-based access (RBAC), data encryption (platform or customer-managed keys), and data integrity (immutable storage).
- Network — Firewalls, private endpoints, VNet rules
- Identity — Azure AD authentication, RBAC roles
- Encryption — At-rest (AES-256), in-transit (TLS 1.2+)
- Integrity — Immutability policies, soft delete
- Auditing — Diagnostic logs, Azure Monitor integration
Private Endpoints
Private Endpoints assign a private IP from your VNet to the storage account. Traffic between your VNet and storage never traverses the public internet, reducing attack surface and eliminating egress costs.
# Create a private endpoint for storage
az network private-endpoint create \
--resource-group rg-payments \
--name pe-storage-payments \
--vnet-name vnet-prod \
--subnet subnet-pe \
--private-connection-resource-id "/subscriptions/{sub-id}/resourceGroups/rg-payments/providers/Microsoft.Storage/storageAccounts/stpaymentsprod" \
--group-id blob \
--connection-name conn-storage-payments
# Block all public access
az storage account update \
--name stpaymentsprod \
--resource-group rg-payments \
--default-action Deny
# Verify the private endpoint connection
az network private-endpoint list \
--resource-group rg-payments \
--query "[].{name:name, status:privateLinkServiceConnectionState.status}" --output tableBlocking public access ensures all traffic flows through the private endpoint. Without this step, the storage account remains accessible from the public internet.
Always run az storage account update --default-action Deny after creating private endpoints. Without this, the storage account is still publicly accessible.
RBAC for Storage
Azure provides specific RBAC roles for storage data access. These roles grant permissions to the data plane (blob, file, queue, table) rather than the control plane.
| Role | Permissions | Scope |
|---|---|---|
| Storage Blob Data Owner | Full access to blobs | Account, container, or blob |
| Storage Blob Data Contributor | Read/write/delete blobs | Account, container, or blob |
| Storage Blob Data Reader | Read blobs and metadata | Account, container, or blob |
| Storage Queue Data Contributor | Full queue access | Account or queue |
# Assign Storage Blob Data Contributor to a user
az role assignment create \
--assignee "user@contoso.com" \
--role "Storage Blob Data Contributor" \
--scope "/subscriptions/{sub-id}/resourceGroups/rg-payments/providers/Microsoft.Storage/storageAccounts/stpaymentsprod"
# Assign to a managed identity
az role assignment create \
--assignee-object-id "$(az identity show --name mi-app --query principalId --output tsv)" \
--role "Storage Blob Data Reader" \
--scope "/subscriptions/{sub-id}/resourceGroups/rg-payments/providers/Microsoft.Storage/storageAccounts/stpaymentsprod/blobServices/default/containers/uploads"RBAC data plane roles work alongside Azure AD authentication. They are the recommended approach over account keys for production workloads.
SAS Tokens
Shared Access Signatures (SAS) provide time-limited, scoped access to storage resources without exposing account keys. Use User Delegation SAS (backed by Azure AD) instead of Account SAS for better security.
# Get a user delegation key
KEY=$(az storage account keys list --account-name stpaymentsprod --query "[0].value" --output tsv)
# Generate a SAS token for a blob
az storage blob generate-sas \
--account-name stpaymentsprod \
--account-key "$KEY" \
--container-name uploads \
--name report.pdf \
--permissions r \
--expiry 2025-01-31 \
--full-uri \
--output tsvSAS tokens are included in the URL. They are useful for granting temporary read access to specific blobs without changing RBAC permissions.
User Delegation SAS is backed by Azure AD credentials, making it auditable and revocable. Account SAS uses the storage account key, which cannot be traced to an individual identity.
Immutable Blobs
Azure Blob Storage supports immutability policies that prevent blobs from being modified or deleted for a specified retention period. This is required for regulatory compliance (SEC 17a-4, CFTC, FINRA).
# Create a container with an immutability policy
az storage container create \
--account-name stpaymentsprod \
--name audit-logs
# Set an immutability policy (365-day retention)
az storage container immutability-policy create \
--account-name stpaymentsprod \
--container-name audit-logs \
--period 365
# Lock the policy (cannot be shortened or removed)
az storage container immutability-policy lock \
--account-name stpaymentsprod \
--container-name audit-logsOnce locked, an immutability policy cannot be removed until it expires. Blobs in the container cannot be modified or deleted during the retention period.
Customer-Managed Keys
By default, Azure Storage encrypts data with Microsoft-managed keys. Customer-managed keys (CMK) let you control the encryption keys in Key Vault, giving you the ability to revoke access and audit key usage.
# Create an encryption key in Key Vault
az keyvault key create \
--vault-name kv-payments-prod \
--name storage-encryption-key \
--kty RSA \
--size 2048
# Update storage account to use CMK
az storage account update \
--name stpaymentsprod \
--resource-group rg-payments \
--encryption-key-source Microsoft.Keyvault \
--encryption-key-vault https://kv-payments-prod.vault.azure.net \
--encryption-key-name storage-encryption-keyCMK encryption requires the storage account to have access to Key Vault. Use a managed identity for the storage account to authenticate to Key Vault.
Azure Storage encrypts all data at rest by default with Microsoft-managed keys. CMK adds an additional layer of control but does not change the encryption algorithm — it changes who controls the key.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.