How to Govern Azure Storage SAS Tokens and Disable Shared Key Access

Retrospective: this article looks back at events from September 2023, written in 2026 with the benefit of hindsight.

SAS tokens grant time-limited access to Azure Storage — but poorly scoped tokens can expose entire accounts for years. Here is how to govern them and remove the riskiest type entirely.

Understand the three SAS types

• Account SAS: signed with the storage account key; can grant access to multiple services. Hardest to govern.
• Service SAS: signed with the account key; limited to one service.
• User delegation SAS: signed with an Entra ID credential; limited to Blob Storage and Data Lake; maximum lifetime of seven days; can be revoked by revoking the user delegation key.

Step 1: Prefer user delegation SAS

Update applications that generate SAS tokens to use user delegation SAS with managed identities. Keep lifetimes short (minutes to hours).

Step 2: Disable shared key authorization

Once applications use Entra ID and user delegation SAS, set Allow storage account key access to Disabled. This invalidates account and service SAS tokens and shared key requests.

Check first: some Azure services and tools still require shared key access. Use storage diagnostic logs to identify requests using shared key or SAS.

Step 3: Set a SAS expiration policy

On storage accounts that still allow shared key, configure a SAS expiration policy to log or block tokens with long validity periods.

Step 4: Use stored access policies

For service SAS that must remain, associate them with a stored access policy so you can revoke them by changing the policy.

Step 5: Scan for exposed tokens

Enable secret scanning in repositories (GitHub detects Azure SAS tokens) and review documentation and notebooks for embedded URLs.

Step 6: Enforce with Azure Policy

Audit or deny storage accounts with shared key access enabled.

Verify

Storage diagnostic logs should show requests authenticated with OAuth or user delegation SAS, not account keys.