Shared access signatures are convenient because they move a narrow permission into a URL. The convenience is also the risk. Anyone who obtains the URL can attempt the operation until the signature expires or its server-side policy changes. A SAS design without a revocation plan is an access-control design that assumes the URL will never leak.
Azure Storage distinguishes account SAS, service SAS, and user delegation SAS. A service SAS is scoped to one storage service, such as Blob, Queue, Table, or Files. A stored access policy can provide server-side control over a service SAS and can revoke access without rotating the storage account key. Account SAS supports storage-account-level operations and does not support stored access policies in the same way. User delegation SAS uses a key obtained through Microsoft Entra ID and has a separate revocation path.
Put revocation into the design
For a service SAS, associate the signature with a stored access policy when the workload permits it. Record the policy identifier, the resource it applies to, the allowed permissions, and the expiry. Microsoft notes that the policy can change or remove access after the SAS has been issued. Deleting, renaming, or making the policy expire is an operational action that must be authorized and logged.
Do not assume that a SAS URL is harmless because it has a short lifetime. Short lifetimes reduce the window but do not provide an emergency response when a token appears in a support ticket, browser cache, or application log. Redact the signature portion during debugging, store SAS values as secrets, and avoid placing them in analytics parameters or public error pages.
Start and expiry times, permissions, protocol restrictions, and resource scope must be checked together. A policy with broad permissions and a future start time is not safer than a narrow policy with a shorter lifetime. A signature that names a container but is used for an object outside that scope should fail, and the test should prove it.
Inventory and exercise the control
List every service that issues SAS URLs. Record the issuing identity, the signing method, the target resource, the maximum permission, the intended lifetime, and the revocation owner. Test a harmless object: issue a read-only SAS, verify the allowed read, then narrow or delete its stored policy and verify that the same URL is rejected. Do not test revocation against a production secret or an object that contains customer data.
Watch for account-key regeneration as a blunt recovery action. It can invalidate many signatures and break unrelated services at the same time. A stored policy or user delegation key can provide a more targeted path, but only if it was designed before the incident.
The useful question is not whether a SAS has a short expiry. It is whether an operator can identify every signature that depends on a resource and revoke the intended set without disabling the service. If that answer is unknown, the next access request should not be issued.