Someone minted an account SAS with read, write, delete, and list on blob, file, and queue for one year and allowed HTTP. What should the security engineer issue instead?
Select an answer to reveal the explanation.
Short Explanation
That year-long, all-service, HTTP-OK account SAS is a skeleton key mailed on a postcard. Cut a tiny one: one container, read, short clock, HTTPS only.
Full Explanation
Someone who minted an account SAS with read, write, delete, and list on blob, file, and queue for one year and allowed HTTP should instead issue the narrowest SAS practical: one container, read-only, hours-scale lifetime, and HTTPS-only. SAS hardening limits resource scope, permissions, validity period, and permitted protocol. A year-long, all-service, HTTP-OK account SAS is a skeleton key on a postcard—especially dangerous for lock-photo and related civic data if the URI leaks.
Keeping the account SAS unchanged because account SAS is always the least-privilege form fails by concept: account SAS is often the broadest form and is not inherently least privilege. Widening the SAS to include table service and removing the HTTPS requirement for older browsers fails by expanding blast radius and permitting cleartext transport. Replacing the SAS with the storage account key in application settings for simpler renewals fails because the raw key is standing full data-plane power with no scoped lifetime.
Exam caveat: harden SAS on four axes—scope, permissions, lifetime, protocol—and prefer user-delegation SAS when Entra is available. Operational check: replace the oversized account SAS with a container-scoped, read-only, short-lived, HTTPS-only signature (user-delegation if possible), revoke or rotate anything that signed the old URI, scan app settings and tickets for leftover broad SAS, and add a checklist item to the canal change process for SAS minimum privilege.