A service SAS for lock photos was emailed with expiry baked into the URI; the contractor left and the URI still works. How should the security engineer make future service SAS revocable?

When a service SAS for lock photos was emailed with expiry baked into the URI and still works after the contractor left, make future service SAS revocable by tying them to a stored access policy on the container. The policy centralizes start time, expiry, and permissions; changing or deleting the policy revokes outstanding signatures that reference it. Ad-hoc SAS with only URI-embedded expiry cannot be shortened without rotating signing keys—so civic operators inherit a lost wristband they cannot void until the clock runs out.

Preferring only ad-hoc service SAS URIs with long embedded expiries and never using stored access policies fails by concept: that design deliberately forgoes centralized revocation. Switching exclusively to user-delegation SAS because those are the only SAS type that support stored access policies fails because stored access policies apply to service SAS on containers or shares; user-delegation SAS use different lifetime and revocation models and are not the only type with stored access policies. Ignoring revocation and waiting for a multi-year embedded expiry fails by leaving an unnecessary access window open after personnel changes.

Exam caveat: service SAS plus a stored access policy enables revocation by policy change or delete; ad-hoc URI-only expiry does not. Operational check: create a container stored access policy for partner lock-photo reads, mint service SAS that reference the policy identifier, revoke the departed contractor by deleting or tightening the policy, confirm the old URI fails, and ban long ad-hoc emailed SAS from the municipal partner process.