DevOps Peach

Azure Basics · Azure Storage – Accounts, Replication, Blobs, Security and Files · Lesson 4 of 5

Storage Security — Entra ID, SAS, Encryption and Firewalls

Prefer Entra ID + RBAC; for temporary sharing, issue a SAS (ideally a user delegation SAS) with minimal rights and a short expiry; SSE is always on; firewalls restrict by IP or subnet.

Practice interactively →

Mechanism Meaning
Entra ID + RBAC Roles such as Storage Blob Data Reader/Contributor; recommended for apps and users
Shared Key (account key) Full account access — avoid sharing, rotate or disable it
SAS A limited delegation token that does not reveal the key
SSE AES-256 encryption at rest, always on, cannot be disabled; Microsoft-managed keys or customer-managed keys in Key Vault
Encryption in transit HTTPS (required by default), SMB 3.x
Firewall & VNet default-action Deny + rules for public IPs or subnets (service endpoints) / private endpoints

SAS

https://stdevopslab01.blob.core.windows.net/backups?se=2030-01-01T00%3A00Z&sp=r&spr=https&sv=2022-11-02&sr=c&sig=EXAMPLE

flowchart LR
  U["Admin (Entra)"] -- "generate-sas --as-user" --> T["Read-only, short-lived SAS"]
  T --> C["Partner"]
  C -- "HTTPS + SAS" --> FW{"Storage firewall"}
  FW -- "IP 203.0.113.10 allowed" --> B["Container backups"]

Best practice: always HTTPS; minimal rights and resources; short expiry; use a stored access policy so you can revoke; do not set the start time to exactly "now" (clock skew); monitor logs. Add firewall rules before setting --default-action Deny so you do not lock yourself out.

Command Meaning
az storage container generate-sas ... --permissions r --expiry 2030-01-01T00:00Z --auth-mode login --as-user Read-only SAS
az storage account network-rule add -g rg-devops-lab --account-name stdevopslab01 --ip-address 203.0.113.10 Allow one IP
az storage account update -n stdevopslab01 -g rg-devops-lab --default-action Deny Turn on the firewall

Hardening settings

Setting CLI flag on az storage account update Why
Block anonymous blob access --allow-blob-public-access false No container can be made public by mistake
Disable Shared Key --allow-shared-key-access false Forces Entra ID, so every access is tied to an identity
Minimum TLS version --min-tls-version TLS1_2 Rejects outdated clients
HTTPS only --https-only true No plain HTTP
Public network access --public-network-access Disabled Only private endpoints can connect

Disabling Shared Key also disables SAS tokens signed with account keys; user delegation SAS still works.

Keys and encryption

With customer-managed keys, the encryption key lives in Azure Key Vault or Managed HSM, and the storage account reads it through a managed identity. You control rotation and can revoke access to make data unreadable. Infrastructure encryption adds a second layer of encryption at the hardware level for strict compliance needs. If you still use account keys, rotate them on a schedule and keep connection strings in Key Vault, not in code.

Detecting threats

Microsoft Defender for Storage alerts on unusual access patterns, such as access from a suspicious IP or large data extraction, and can scan uploaded blobs for malware. Send resource logs (for example the StorageBlobLogs table) to Log Analytics to see who read or deleted what, and alert on failed authentication spikes.

Layering the controls

Good storage security combines several controls rather than one: identity (Entra ID roles with least privilege, managed identities for apps), network (private endpoints or firewall rules), data protection (soft delete, versioning, immutability), and monitoring (Defender and logs). A CanNotDelete lock on the account prevents the whole account being deleted by mistake, though it does not stop deleting data inside it.

Practice interactively →