An Azure SAS needs a signing scope and a revocation path

An Azure Shared Access Signature (SAS) requires both a signing scope and a revocation path to ensure secure access to resources. While SASes offer convenience by embedding permissions in a URL, this convenience is also a potential security risk, as anyone who acquires the URL can attempt operations until the signature expires or the server-side policy changes.

Without a proper revocation plan, an SAS design assumes the URL will never leak. Azure Storage distinguishes between account SAS, service SAS, and user delegation SAS, each with distinct scopes and revocation methods.

Service SASes are bound to a single storage service like Blob, Queue, Table, or Files, and can be controlled server-side through stored access policies. These policies enable revoking access without rotating the storage account key. However, account SASes support storage-account-level operations and do not accommodate stored access policies directly.

User delegation SASes leverage a key obtained through Microsoft Entra ID and have a separate revocation path. To mitigate risks, it's crucial to incorporate revocation into the design. When using service SASes, tie the signature to a stored access policy, recording the policy identifier, resource, permissions, and expiry. Microsoft highlights that policies can be altered or removed after issuance, necessitating authorized and logged actions.

Even with short SAS lifetimes, they do not guarantee security. Short durations merely reduce the exposure window but fail to provide an emergency response if a token surfaces in logs or applications. Always redact the signature portion during debugging, store SAS values as secrets, and refrain from placing them in analytics parameters or public error pages.

When examining SASes, scrutinize start and expiry times, permissions, protocol restrictions, and resource scope together. A policy with extensive permissions and a distant start time is not safer than a narrower policy with a shorter lifespan. A failing signature to access a container used for an object outside its scope should be tested to verify its effectiveness.

Maintain an inventory of services issuing SAS URLs, documenting the issuing identity, signing method, target resource, maximum permissions, intended lifetime, and the revocation owner. Test a benign object by issuing a read-only SAS, confirming the allowed read, then narrow or delete its stored policy and ensure the same URL is rejected. Avoid testing revocation against production secrets or sensitive data.

Be cautious of account-key regeneration as a recovery action, as it can invalidate numerous signatures and disrupt unrelated services simultaneously. A stored policy or user delegation key may offer a more targeted revocation path, but only if it was designed beforehand. The crucial question is not whether SASes have short expiries but whether operators can identify every signature dependent on a resource and revoke them without disabling the service. If this capability is uncertain, refrain from issuing further access requests.