Why Azure Storage accounts expose business files

Azure Storage can expose business files when a storage account allows anonymous access, credentials are leaked or network rules are too broad. Excessive permissions can also expose files held in Azure Storage. Azure Storage security depends on controlling these routes separately; encryption at rest doesn’t prevent someone downloading files through authorised access obtained improperly.

The practical priority is to identify which identities, credentials and networks can reach sensitive data. Start with those access paths, then address transport protection, monitoring and recovery.

Key takeaways for Azure Storage security

Use the following priorities to organise remediation. These are operational priorities, not Microsoft severity ratings.

Control area	Priority	Required action
Anonymous access	High	Disallow anonymous Blob access for confidential data.
Identity	High	Use Microsoft Entra ID and scoped data roles.
Credentials	High	Remove unnecessary keys and shorten SAS lifetimes.
Network access	High	Restrict public connectivity and approve exceptions.
Transport	Medium	Require secure transfer and TLS 1.2.
Monitoring and recovery	High	Collect service logs and test restoration.

Apply these controls together. A restricted network does not correct excessive permissions, whilst strong authentication does not remove an anonymous access route.

Distinguish public connectivity from public access

A publicly reachable storage endpoint does not automatically expose its contents anonymously. Requests normally still require authorisation. Anonymous Blob access becomes possible when the storage account permits it and an individual container has an appropriate public access level.

For confidential business files, disable anonymous Blob access on each relevant storage account. This prevents a container owner accidentally making documents publicly readable. It does not invalidate account keys, Shared Access Signatures or Microsoft Entra permissions.

Other exposures involve access that remains technically valid: an old integration retains a key, a departed administrator retains permissions, or a shared download link remains usable.

Identify an owner for each account, record its business purpose and review access when applications or staff responsibilities change. Our guidance on secure IT defences explains why cloud configuration needs ongoing ownership rather than a one-off deployment review.

Replace shared credentials with scoped identities

Use Microsoft Entra ID and data roles

Prefer Microsoft Entra ID, formerly Azure AD, over Shared Key authorisation wherever the workload supports it. Role-based access control (RBAC) ties permissions to a named user, group or application, rather than possession of an account-wide secret.

Apply the principle of least privilege by assigning data roles at the narrowest suitable scope. An application that only downloads blobs normally needs Storage Blob Data Reader, not Storage Blob Data Owner.

Protect human administrator access with multifactor authentication and appropriate Conditional Access policies. Those controls don’t protect requests authenticated directly with a storage account key.

Remove unnecessary account keys

Azure generates 2 account access keys when an account is created. These credentials provide broad access and are difficult to attribute to an individual when shared between applications.

Rotate remaining keys periodically and replace dependencies methodically. Regenerating a key immediately invalidates credentials signed with it, so an unplanned rotation can interrupt production.

Disable Shared Key access after migrating supported dependencies. Microsoft’s storage security recommendations favour identity-based authorisation over account keys.

Use managed identities for applications

A managed identity lets supported workloads authenticate without distributing application secrets. Azure manages and rotates its credentials.

A system-assigned identity is deleted with its associated workload resource. A user-assigned identity has an independent lifecycle. Both still need carefully scoped permissions, an accountable owner and removal when their purpose ends.

Give every SAS token a defined lifetime

A Shared Access Signature (SAS) delegates access through a signed token. Anyone possessing a usable token can exercise its permissions, subject to its restrictions. A token copied into an email, browser history or support ticket can therefore become an exposure route.

Grant only the required service, resource and permissions. Microsoft recommends an expiry of 1 hour or less for a service SAS that is not associated with a stored access policy. This is not a universal limit for every SAS scenario.

Configure an account SAS expiration policy and monitor tokens that exceed the intended lifetime. Prefer user-delegation SAS for Blob access when delegation is necessary, or managed identity when the application supports direct authentication.

Disabling Shared Key blocks account-key authorisation, including account and service SAS. It does not block supported Microsoft Entra access or user-delegation SAS.

Restrict the network paths into storage

Choose private connectivity or a restricted public endpoint

A private endpoint assigns a private IP address within a virtual network. Traffic travels over the Microsoft backbone rather than the public internet. Applications also need working private DNS and connectivity to that network.

Creating a private endpoint does not disable the public endpoint. Restrict public network access separately.

Where public connectivity remains necessary, set the default network action to Deny and use firewall rules to allow approved sources while denying unnecessary connections. Rules can allow specified public IP ranges, virtual-network subnets, resource instances or supported trusted Azure services. Confirm clients use HTTPS when they connect to the storage service.

These exceptions don’t remove authentication requirements. Document the business dependency behind each exception rather than enabling broad access to resolve an application failure.

Microsoft’s Blob Storage 403 troubleshooting guidance distinguishes network rejection from authentication and permission failures. Diagnose the cause before reopening access.

Coordinate multiple accounts and restrict copying

A Network Security Perimeter provides shared inbound and outbound rules across supported platform-as-a-service resources, including storage accounts. It suits environments where individually maintained account rules become inconsistent.

In Enforced mode, public traffic is blocked unless perimeter rules permit it. Private-endpoint traffic is outside those perimeter access rules, so private connectivity still needs separate governance.

Azure also provides a preview control for permitted copy-operation sources. It can restrict sources to the same Microsoft Entra tenant, or use the PrivateLink option for accounts linked to the same virtual network as the destination.

Treat this as an additional copy restriction, not a replacement for permissions or network controls.

Protect traffic and stored data separately

Require secure transfer and TLS 1.2

Enable Secure transfer required so storage REST requests using HTTP are rejected and clients must connect over HTTPS. Set the minimum TLS version to 1.2.

HTTPS protects information whilst it travels between the client and storage service. It does not prevent a valid credential downloading the wrong documents, nor does it restrict where an authorised client subsequently saves them.

Microsoft’s cloud data protection benchmark includes secure transfer amongst its storage protections. Apply the requirement alongside identity and network restrictions rather than treating encrypted connections as sufficient protection.

Select encryption controls for the actual requirement

Azure Storage encrypts data at rest with AES-256 by default, using Microsoft-managed keys. This protects stored data, but the service decrypts information for authorised requests.

Infrastructure encryption adds another layer using a different algorithm and key. It must be enabled when creating the storage account or an encryption scope, so include it in architecture decisions before deployment.

Customer-managed keys can be held in Azure Key Vault or Key Vault Managed HSM. Choose them where the organisation needs additional control over key custody and lifecycle. Document responsibility for key access and recovery, because an unavailable key can also make business data unavailable.

Collect evidence and maintain a recovery route

Enable storage service logs and assign a response owner

The Azure Activity Log records management operations, such as configuration changes. It doesn’t replace storage service logs showing data access.

Configure diagnostic settings for the services in use, including appropriate read, write and delete logs. Send records to the chosen monitoring destination and define retention, investigation access and alert ownership.

Monitor changes to anonymous access, network rules and role assignments. Review failed authorisation attempts and unusual downloads against normal business use, as they may indicate data exfiltration.

Configured Defender for Storage alerts can support detection, but they don’t replace access controls or a named response owner.

Our managed detection and response services can support investigation and response within an agreed scope. Storage activity must be included in that scope; purchasing a monitoring service doesn’t automatically connect every Azure data source.

Keep recovery separate from availability

Blob versioning retains earlier versions after changes, allowing recovery following accidental or malicious modification. Restoring a previous version can require copying it back as the current blob.

Enable blob and container soft delete where supported, and define retention around business requirements. For records that must resist alteration or deletion, assess an immutable blob policy against retention requirements.

Versioning and soft delete remain subject to their configuration, permissions and supported account features. They don’t establish that the business can recover after every compromise.

Our explanation of why cloud data needs backup separates platform availability from recoverability. Test restoration with realistic access restrictions and document who can recover data if normal administrator credentials are compromised.

Enforce the baseline and test legitimate access

Azure Policy helps identify configuration drift and prevent non-compliant changes to Azure Storage configurations. Microsoft’s built-in policy catalogue includes “Storage accounts should prevent shared key access” and “Storage accounts should have the specified minimum TLS version”.

Use audit mode to identify affected workloads before introducing supported Deny effects. Deny prevents non-compliant changes, but it doesn’t repair existing configurations or confirm that every permission is appropriate.

In the Azure portal, review account Configuration for anonymous access, Shared Key, secure transfer and minimum TLS. Review Networking separately, then inspect service diagnostic settings and applicable data-protection options.

Test expected success and expected failure. An approved application should work, whilst anonymous requests, disallowed networks and expired tokens should fail.

Record exceptions with an owner, justification and review date. Repeat the tests after application migrations, permission changes and network redesigns instead of relying on the original deployment record.

Frequently Asked Questions

Does a publicly reachable Azure Storage endpoint make files public?

No. Requests normally still require authorisation, and anonymous Blob access requires both account-level permission and a public access level on the container. Disable anonymous Blob access for accounts that hold confidential files.

Does a private endpoint disable the public endpoint?

No. A private endpoint gives the storage account a private IP address within a virtual network, but you must restrict public network access separately. Private DNS and connectivity to that network must also work for applications to use the endpoint.

What is the difference between a storage account key and a SAS token?

A storage account key provides broad access and can be difficult to attribute when shared. A SAS token grants access with specified permissions and restrictions, but anyone who obtains a usable token can exercise those permissions until it expires or is otherwise invalidated.

Does encryption at rest prevent unauthorised downloads?

No. Azure Storage encrypts stored data by default, but the service decrypts it for authorised requests. Control identity permissions, credentials and network access to prevent improper downloads.

Do Azure Activity Logs show who accessed stored files?

The Azure Activity Log records management operations, such as configuration changes, but it doesn’t replace storage service logs showing data access. Configure diagnostic settings for the services in use and assign an owner to review alerts and investigate activity.

Close the access paths the business does not need

An encrypted storage account can still disclose confidential files through an anonymous container, excessive role assignment or usable leaked token. The strongest baseline removes unnecessary access and makes the remaining routes attributable, restricted and observable.

Start with the account holding the most sensitive information, then apply the same documented controls across the estate.

Speak to our team about reviewing Azure permissions, network access, monitoring and recovery through our business IT security services.