Storage Security and Encryption

Securing your Azure Storage accounts is essential for protecting sensitive data. Azure provides multiple layers of security — from network controls and authentication mechanisms to encryption at rest and in transit. This lesson covers the full security stack for Azure Storage, including identity-based access, shared access signatures, network security, encryption, and advanced threat protection.

---

Authentication and Authorisation

Azure Storage supports several methods for authenticating and authorising requests:

1. Microsoft Entra ID and RBAC (Recommended)

The recommended approach for production workloads. Use Azure Role-Based Access Control (RBAC) to assign granular permissions.

Role	Description
Storage Blob Data Owner	Full access to Blob Storage data, including managing POSIX ACLs
Storage Blob Data Contributor	Read, write, and delete blobs
Storage Blob Data Reader	Read-only access to blobs
Storage Queue Data Contributor	Read, write, and delete queue messages
Storage Table Data Contributor	Read, write, and delete table entities

# Assign Blob Data Reader role to a user
az role assignment create \
  --assignee user@example.com \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/<sub>/resourceGroups/rg-demo/providers/Microsoft.Storage/storageAccounts/mystorageaccount

2. Shared Access Signatures (SAS)

A SAS is a URI that grants restricted access to storage resources for a limited time. There are three types:

SAS Type	Scope	Description
Account SAS	Entire storage account	Access to multiple services (Blob, File, Queue, Table)
Service SAS	Single service	Access to a specific service (e.g., Blob only)
User delegation SAS	Single service	Signed with Entra ID credentials (most secure SAS type)

SAS Components

A SAS token includes:

Component	Description
Signed resource	Which resource the SAS grants access to
Signed permissions	Read, write, delete, list, etc.
Start and expiry time	When the SAS becomes valid and when it expires
Signed IP	Restrict to specific IP addresses (optional)
Signed protocol	HTTPS only, or HTTP and HTTPS
Signing key	Account key (account/service SAS) or Entra ID (user delegation SAS)

# Generate a SAS token for a blob container (valid for 1 hour)
az storage container generate-sas \
  --account-name mystorageaccount \
  --name mycontainer \
  --permissions rl \
  --expiry $(date -u -d "+1 hour" +%Y-%m-%dT%H:%MZ) \
  --auth-mode login \
  --as-user

3. Storage Account Keys

Each storage account has two 512-bit access keys that grant full control over the entire account.

Warning: Account keys are like root passwords. Anyone with a key has complete access to the storage account. Always prefer Entra ID authentication. If you must use keys, store them in Azure Key Vault and rotate them regularly.

4. Stored Access Policies

A stored access policy provides an additional level of control over service-level SAS tokens. You can modify or revoke a SAS by changing the stored access policy it references — without regenerating the account key.

# Create a stored access policy
az storage container policy create \
  --account-name mystorageaccount \
  --container-name mycontainer \
  --name read-policy \
  --permissions rl \
  --expiry 2025-12-31

---

Network Security

Storage Account Firewall

By default, storage accounts accept connections from any network. You can restrict access using the storage firewall:

# Deny all traffic by default
az storage account update \
  --name mystorageaccount \
  --resource-group rg-demo \
  --default-action Deny

# Allow access from a specific VNet subnet
az storage account network-rule add \
  --account-name mystorageaccount \
  --resource-group rg-demo \
  --vnet-name myVNet \
  --subnet app-subnet

# Allow access from a specific IP address
az storage account network-rule add \
  --account-name mystorageaccount \
  --resource-group rg-demo \
  --ip-address 203.0.113.50

Private Endpoints

Private endpoints provide a private IP address within your VNet for the storage account, eliminating exposure to the public internet: