We're reviewing Azure Storage accounts that still allow anonymous access to Blob containers. For anyone who's completed this kind of remediation, how did you handle external consumers that needed SAS tokens versus internal applications that could use Entra ID or managed identities? What methods did you use to discover which systems were still calling anonymous endpoints, and what lessons did you learn before disabling public access?
3 Answers
If anonymous blobs are genuinely required, they’re often being served through a CDN or similar distribution layer. For traffic that is already authenticated but still relies on account keys or SAS, Blob diagnostic logs can help identify the callers so you can transition them to Entra ID and role-based access control.
Start by enabling Blob diagnostic logs for at least a week before changing access settings. Look for requests without an Authorization header or identity information so you can build a list of real consumers. For internal applications, Entra ID with managed identities is generally cleaner than keeping long-lived account SAS tokens. For external partners, consider short-lived user-delegation or account SAS tokens, restrict them by IP where practical, and manage rotation through Key Vault. Once everything has been migrated, disable “Allow Blob public access” at the storage-account level; container settings won't override that account-wide restriction.
The most difficult part is usually identifying anonymous consumers before shutting access off. Disabling the setting first can create failures that are hard to trace, so use request logs and application inventories to map the callers and give owners time to move to authenticated access.
Also check less obvious dependencies, such as Power Automate flows, old websites, and platform-managed tools. One overlooked public URL can cause an unexpected outage right after the account-level setting is changed.