Compliance

Harden Azure Storage accounts

One capability across Blob, File, Table and Queue: make sure no storage account is reachable from, or shareable with, the public internet, and that nothing it serves travels unencrypted, unless you genuinely intend it.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-storage-firewall-network-access-restricted azure-storage-migrate-to-arm azure-storage-prevent-shared-key-access azure-storage-public-blob-access-disallowed azure-storage-restrict-network-vnet-rules azure-storage-secure-transfer-required

Hardening storage accounts: the basics

What does an exposed Azure Storage account actually look like?

A storage account is the most data-dense object in an Azure subscription, and exposure shows up in a handful of distinct shapes rather than one setting. Anonymous public read can be left enabled so a container is downloadable without credentials. Secure transfer can be off so the account still answers plain HTTP. The account firewall can be open to all networks instead of restricted to a private endpoint or a known set of addresses. Encryption can rely on the platform key when a regulated workload needs a customer-managed key. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: a store of data that more of the internet can reach, or read in transit, than you meant.

Microsoft Defender for Cloud turns each of these into its own recommendation, which is why one storage-heavy subscription can fail several storage checks at once. 'Storage accounts should prevent anonymous public read access' and 'Secure transfer to storage accounts should be enabled' are the two that close the widest doors, and they pair with private-endpoint, network-restriction and customer-managed-key recommendations to form a single capability. They read as separate problems on the report, but they are one job: close the doors you did not mean to leave open, and encrypt what you serve.

Most of this exposure is drift, not intent. A storage account created before anonymous access was disabled by default, a module that never set secure transfer, a firewall left open because a quick test needed it and nobody closed it again. The work is to find every account that is reachable or readable more widely than intended, decide which handful are public on purpose, route those through a controlled front door such as Azure Front Door, and lock the rest down.

In this lesson you will learn how Azure Storage expresses public reachability and in-transit protection, how to find every over-exposed account in a subscription, and how to lock them down without breaking the few that are public on purpose. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The blob that briefed the breach

Misconfigured cloud storage has been behind some of the largest data exposures on record, and Azure Blob containers left open for anonymous read have appeared in their share of them, from leaked recruitment data to exposed internal documents. The pattern is always the same: a container that could be made public was made public by accident, then found by an automated scanner long before anyone noticed. Azure now disables anonymous access by default on new accounts, but every account created before that default still needs to be checked and locked explicitly.

Finding storage exposure across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows storage findings spread across a dozen accounts in two subscriptions that pre-date the team's current guardrails.

Rather than work the findings one by one, Sam starts by listing which accounts still allow anonymous access and which still accept plain HTTP, so the genuinely public stores can be separated from drift before anything changes.

Start by listing the accounts that still allow anonymous public read. These are the widest-open doors.

$ az storage account list --query "[?allowBlobPublicAccess].{name:name, https:enableHttpsTrafficOnly}" -o table

Name Https

------------------ -------

custexportsprod False

analyticsstaging True

# custexportsprod allows anonymous read AND answers plain HTTP. Close it first.

An account that is both anonymously readable and plain-HTTP is the highest-value target in this group. Fix these first.

How Defender for Cloud decides a storage account is exposeddeep dive

Most storage recommendations resolve to one of three properties on the account. The first is 'allowBlobPublicAccess': when it is true, a container can be set to anonymous read, so the account can serve data without credentials. The second is 'supportsHttpsTrafficOnly': when it is false, the REST endpoints still answer plain HTTP, so requests and any shared access signature token in the URL travel unencrypted. The third is the network rule set: when default action is Allow, the account is reachable from any network rather than restricted to a private endpoint or an approved address range.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly. The control-plane change itself is immediate, but the posture catches up on the next assessment. This matters when you are gathering audit evidence against a deadline.

The strongest position combines the account setting with an Azure Policy backstop: a deny policy on 'allowBlobPublicAccess' and on secure transfer means no individual account can be created in the open state again. Turning those policies on is the difference between checking that nothing is exposed today and guaranteeing that nothing can be exposed tomorrow.

What is the impact of leaving storage exposed?

The direct impact is data exposure. An anonymously readable container is reachable by anyone who finds it, and internet-facing stores are found quickly by automated scanners. An account answering plain HTTP leaks request data and any SAS token in the URL to anyone able to observe the traffic, and a stolen SAS token grants whatever it allows until it expires. The overwhelming majority of storage incidents were accidents: a setting that could be left open was left open by a module or a flag nobody intended.

The second-order impact is blast radius. Every open account and plain-HTTP endpoint is attack surface that has to be defended continuously. Locking storage down shrinks that surface to the handful of front doors you actually operate, which are the ones you can monitor, rate-limit and put a web application firewall in front of.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence that data stores are not publicly readable and that data in transit is encrypted. A passing set of storage recommendations across every subscription is the cheapest and most defensible artefact you can hand an auditor.

How do you lock storage down safely?

Work the capability as one loop rather than chasing individual findings. The order matters: find the legitimate public stores before you start closing things, so you do not take a live service offline.

1. Inventory every account by exposure

List the accounts that allow anonymous public read, that accept plain HTTP, and that have an open network rule set. Treat this inventory as the source of truth, not the Defender finding count, because one account can trigger several recommendations at once.

2. Separate genuine public stores from drift

Most exposure is unintended. For each account, decide whether it is public on purpose. Genuine public content, such as a static site or a public download store, belongs behind Azure Front Door over a private origin, never exposed directly. Everything else is drift and can be closed.

3. Close the doors, highest impact first

Disable anonymous access, require secure transfer, set a minimum TLS version of 1.2, and switch the network default action to Deny with a private endpoint or an approved address range. Prioritise accounts that hold data over empty ones. Each change is a single command per account and takes effect immediately.

4. Ratchet it shut with Azure Policy

Assign deny policies so no new account can be created with anonymous access enabled or secure transfer off, and audit for private-endpoint use. Back this with customer-managed keys for the regulated workloads that need them, so the safe configuration is enforced rather than merely encouraged.

# Close the highest-impact storage exposure first: anonymous read AND plain HTTP.
for acct in $(az storage account list \
    --query "[?allowBlobPublicAccess].name" -o tsv); do
  az storage account update --name "$acct" \
    --allow-blob-public-access false \
    --https-only true \
    --min-tls-version TLS1_2
  echo "$acct: anonymous access disabled, secure transfer required, min TLS 1.2"
done

# Ratchet it shut: deny any future account that allows anonymous access.
az policy assignment create \
  --name deny-anon-blob \
  --policy 13e6c4f1-e83f-4b50-a677-2cf6e2b9c885 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud shows storage findings across anonymous access, secure transfer and network rules on several accounts. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure Storage expresses reachability and in-transit protection across the settings in this capability.

You can now treat Azure Storage as one capability rather than a scatter of findings: inventory what is reachable or readable too widely, separate the genuine public stores and route them through a controlled front door, close the rest highest-impact first, and ratchet the estate shut with Azure Policy. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Hardening storage accounts: the cost and risk view

A near-zero-cost capability that removes the largest class of Azure data-breach liability

Storage exposure is the single biggest source of accidental data loss in Azure, and almost every control in this group costs nothing in Azure spend to fix. Disabling anonymous access, requiring secure transfer or tightening the account firewall does not change your bill. The cost sits entirely in the few exceptions: the accounts that genuinely serve public traffic and need to move behind Azure Front Door first, and the regulated workloads that adopt a customer-managed key, which adds a small Key Vault charge.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A storage account holding customer exports with anonymous access enabled carries a far higher expected loss than an empty staging account, yet both surface as a single red finding. Map the failures to the data behind them and prioritise by exposure, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time plus a small, bounded migration for the legitimate exceptions. The downside of leaving it is the documented cost of a public-exposure breach: regulatory fines, breach notification, forensics, legal fees and reputational damage.

This lesson is for the finance partner who sees a cluster of storage findings on the security report and wants to know what the right response is and what it costs. It covers why most of these controls are free to fix, which exceptions carry a real cost, and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The blob that briefed the breach

How a finance partner frames the storage decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with eleven storage findings spread across a dozen accounts in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Disabling anonymous access or requiring secure transfer changes nothing on the Azure bill, so the spend question is narrow: only the handful of accounts that genuinely serve public traffic carry a real cost when they move behind Front Door, and only the regulated workloads that adopt a customer-managed key add a small Key Vault charge.

Sam asks the team to map each failing account to the data sitting behind it. Two accounts hold customer exports with anonymous access enabled, one is a public download store that is meant to be reachable, and the rest are empty or staging accounts with secure transfer simply never set. The list is reframed on the risk register: the two customer-data accounts are high expected-loss items to close today at zero Azure cost, the public download store is a small, bounded Front Door migration to schedule, and the staging accounts are low-value drift to sweep up. The finance pack reads: 'Nine findings close at no incremental spend; one legitimate public store needs a bounded migration; the only thing standing between us and a clean posture is engineering time, not budget.'

Why storage exposure belongs on the risk register

The cost model here is asymmetric in a way that is rare for security work. Locking storage down costs nothing in Azure spend for the great majority of accounts, and leaving it open creates an unbounded tail risk. Each failing recommendation is an account where a future accident could expose its contents, and while the probability per event is low, the probability across all accounts over years is not.

The documented cost of a storage breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn. Against that, the remediation is engineering time plus a bounded migration for the few legitimately public stores and a small Key Vault charge for customer-managed keys where a workload needs one. The finance role is to attach expected loss to each failing account so the work is prioritised by risk, not by the order the report lists it.

What finance can do about the storage gap

Finance cannot tighten an account setting, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with almost no incremental Azure spend and a clearly bounded set of exceptions. Three levers.

1. Separate the zero-cost closures from the bounded exceptions

Make explicit that the overwhelming majority of storage findings cost nothing in Azure spend to fix: disabling anonymous access, requiring secure transfer or tightening the firewall does not move the bill. The only real cost sits in the few legitimately public stores that need to move behind Front Door, and the small Key Vault charge for customer-managed keys where a regulated workload needs one. Budget those as discrete lines and treat everything else as engineering time, so nobody can claim the whole capability is a spending decision.

2. Order the work by expected loss, not by finding count

An account holding customer exports with anonymous access enabled and an empty staging account both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing recommendation to the data behind it and prioritise the data stores first. The metric that belongs on the cost-and-security review is the count of storage findings weighted by the sensitivity of what they hold, not the raw total.

3. Require documented exceptions for intentionally public stores

Any account left readable from the internet on purpose, the public download store, the marketing asset origin, should carry a recorded, finance-visible reason and the controlled front door it sits behind. The distinction between 'we reviewed this and routed it through Front Door deliberately' and 'we never noticed it was open' is exactly what makes the posture defensible at audit and in the aftermath of any breach.

Quick quiz

Question 1 of 5

A security report shows eleven storage findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure Storage expresses reachability and in-transit protection across the settings in this capability.

You have finished the finance view of hardening storage. You know the cost model is one-sided: closing the great majority of findings is free in Azure spend, only the genuinely public stores and a few customer-managed keys carry a bounded cost, and the downside of leaving exposure open is the documented and unbounded cost of a breach. Next time a cluster of storage findings lands, you will order them by expected loss, ring-fence the real exceptions, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Hardening storage accounts: the headline

Whether any store of data in the estate is reachable from the internet by accident

Storage is the category of risk that turns a configuration mistake into a headline. An account that can be read anonymously, or that answers plain HTTP, is one bad change away from exposing data, and the report shows this as a scatter of separate findings across the estate.

The leadership question is not 'are we compliant today?' It is 'if a deployment makes a mistake tomorrow, can it expose data to the internet?' The defensible end state is that anonymous access is prevented by policy, secure transfer is enforced everywhere, and the small number of genuinely public stores are routed through a controlled front door rather than left open.

None of this is a cost decision. Locking down storage is essentially free in Azure terms. It is a governance decision about whether exposure is prevented by design or only by everyone remembering not to make a mistake.

A short read for the leader who needs to know what an exposed storage account reveals, why locking it down is a governance decision rather than a budget one, and what a defensible end state looks like across the estate.

Fun fact

The blob that briefed the breach

What it looks like when storage exposure is prevented by design, not luck

After a peer company made the news for a leaked customer file store that turned out to be an Azure container nobody meant to leave open, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to check, because anonymous access and secure transfer across the estate were governed by habit rather than policy.

The team's response was to stop treating storage as a per-account cleanup and start treating it as a guardrail. They listed every account that allowed anonymous read or accepted plain HTTP, routed the one genuinely public store through Front Door, locked the rest down, and then set an Azure Policy that denies the creation of any new account with anonymous access enabled or secure transfer off. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the platform prevents it by design, and the one intentional public store is documented.' That shift, from relying on everyone remembering not to make a mistake to making the mistake structurally hard, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Why this is a board-level risk

Nearly every major cloud data breach that involved exposed storage came back to the same root cause: a store that could be read by more of the internet than intended was, because of an internal change. Locking storage down is the capability that makes that root cause structurally difficult, and an Azure Policy backstop makes it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on storage

The executive handle is not to approve each closure individually; it is to require that storage exposure is prevented by policy and that the small number of deliberately public stores are routed through a controlled front door, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, the genuine public stores are behind Front Door, the rest are locked down, and Azure Policy denies the creation of any new account with anonymous access enabled or secure transfer off. A backstop that no individual account can override is the difference between checking nothing is exposed today and guaranteeing nothing can be exposed tomorrow.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are on it.' It is a passing set of storage recommendations across every subscription plus evidence that the deny policies are assigned. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat the genuinely public stores as named, owned exceptions

A small number of stores are public on purpose, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and a controlled front door, not an accident left open. The goal is not zero public stores; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a leaked-storage incident like a competitor's could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure Storage expresses reachability and in-transit protection across the settings in this capability.

Two takeaways. Storage exposure is the rare control where the risk of inaction is severe and the cost of action is essentially engineering time, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and nothing is public today'; it is Azure Policy that denies anonymous access and enforces secure transfer, making accidental exposure structurally hard, with the few deliberate public stores documented and owned.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Azure Storage

Storage

Part of the learning path Close Azure network exposure

Harden Azure Storage accounts

Hardening storage accounts: the basics

The blob that briefed the breach

Finding storage exposure across a subscription

How Defender for Cloud decides a storage account is exposeddeep dive

What is the impact of leaving storage exposed?

How do you lock storage down safely?

1. Inventory every account by exposure

2. Separate genuine public stores from drift

3. Close the doors, highest impact first

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Hardening storage accounts: the cost and risk view

The blob that briefed the breach

How a finance partner frames the storage decision

Why storage exposure belongs on the risk register

What finance can do about the storage gap

1. Separate the zero-cost closures from the bounded exceptions

2. Order the work by expected loss, not by finding count

3. Require documented exceptions for intentionally public stores

Quick quiz

Keep learning

Hardening storage accounts: the headline

The blob that briefed the breach

What it looks like when storage exposure is prevented by design, not luck

Why this is a board-level risk

The leadership move on storage

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat the genuinely public stores as named, owned exceptions

Quick quiz

Keep learning

Controls this lesson covers

Azure Storage

Storage

Related compliance lessons