4.3 SAS Tokens, Stored Access Policies, and Access Keys

Delegating access without overexposing the account

Azure Storage supports several access patterns: Microsoft Entra authorization with Azure RBAC, shared key authorization, shared access signatures, and anonymous public access when allowed for blob containers. For administrator scenarios, the key decision is whether a user or application should receive identity-based permission, a temporary delegated token, or a shared account secret. The safest answer is usually the most specific permission for the shortest workable time.

A shared access signature, or SAS, is a signed URI query string that grants access to storage resources. A service SAS delegates access to a specific service resource, such as a blob container or file share, and is signed with an account key. An account SAS can delegate access across services and resource types and is also signed with an account key. A user delegation SAS applies to Blob Storage and is signed using a user delegation key obtained through Microsoft Entra ID. In many exam scenarios, user delegation SAS is preferred because it avoids directly using the account key.

SAS permissions are compact but important. For blobs, common permissions include read, add, create, write, delete, list, and sometimes permanent delete depending on feature support. Resource scope matters: a token for a container with list and read is very different from a token for one blob with read only. Set HTTPS-only where possible. Add a start time only when necessary, because client clock skew can make a token invalid before it appears active. A common operational practice is to set the start time a few minutes in the past or omit it for immediate use, while keeping the expiry short.

Stored access policies give you a named policy on a container, queue, table, or file share that can define start time, expiry time, and permissions for service SAS tokens. The advantage is revocation and centralized change. If many SAS tokens reference the policy and you shorten the policy expiry or delete the policy, those tokens are affected. A user delegation SAS and account SAS do not use stored access policies in the same way, so read the scenario carefully.

Portal path example: Storage account > Data storage > Containers > select container > Shared access tokens for a container-level SAS. For account-level SAS, use Storage account > Security + networking > Shared access signature. For keys, use Storage account > Security + networking > Access keys. For a stored access policy, open the container or share, then Access policy.

CLI examples:

az storage container policy create \
  --account-name staz104prod01 \
  --container-name reports \
  --name readonly-2h \
  --permissions rl \
  --expiry 2026-05-05T22:00Z \
  --auth-mode login

az storage container generate-sas \
  --account-name staz104prod01 \
  --name reports \
  --policy-name readonly-2h \
  --https-only \
  --as-user

The exact CLI parameters depend on the SAS type and command version, but the administrator logic stays the same: define the resource, permissions, expiry, protocol, optional IP range, and signing method. For automation, avoid printing long-lived SAS values into logs. Store secrets in Key Vault when a workflow must reuse them. Prefer managed identities and RBAC for Azure-hosted applications when possible, because the app can obtain tokens without embedding a storage key or SAS in configuration.

Access keys require special care. Each storage account has two account keys so you can rotate one while applications use the other. A common rotation sequence is: identify apps using key1, update apps to key2 or a Key Vault reference, regenerate key1, move apps to key1, regenerate key2, and confirm no stale clients remain. If the organization disables shared key access on the storage account, clients must use Microsoft Entra authorization or supported SAS patterns. This can break tools or legacy applications that silently depend on keys.

Troubleshooting SAS problems is systematic. If a SAS worked yesterday but fails today, check expiry first. If list operations fail but direct blob reads work, the token may have read but not list. If uploads fail, confirm write or create permissions and that the signed resource type matches the operation. If a token fails only from a corporate network or only from home, check the SAS IP range and storage firewall. If every key-signed SAS fails after a security change, check whether the account key was regenerated or shared key access was disabled.

Case scenario: a vendor needs to upload one CSV file into a landing container by Friday, but must not list other files or reuse access next month. A good answer is a short-lived SAS scoped to the target container or blob path with only create and write as needed, HTTPS-only, optional IP restriction if the vendor has stable egress, and storage firewall rules that still allow the network path. Do not give the vendor an account key. Do not assign subscription Contributor. If revocation before expiry is required for many similar tokens, use a service SAS tied to a stored access policy where supported.