Compliance

Restrict public network access to Azure databases

One capability across Azure SQL Database, Azure Database for PostgreSQL and Azure Cosmos DB: make sure no managed database is reachable from the open internet, and that the only paths in are a private endpoint or a tightly scoped set of trusted networks.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-cosmos-firewall-rules azure-postgresql-public-access-disabled azure-sql-mi-public-network-access-disabled azure-sql-public-network-access-disabled

Restricting database public access: the basics

What does a database open to the internet actually look like in Azure?

A managed database is one of the highest-value targets in an Azure subscription, because it usually holds the data the rest of the estate is built around. Exposure shows up in a few distinct shapes rather than one setting, and each Azure database service expresses it slightly differently. Azure SQL Database has a public network access toggle: when it is set to Enabled, the server answers on its public endpoint and lets through anything that matches an IP or virtual-network firewall rule. Azure Database for PostgreSQL has the same idea: a server deployed with public access can be reached on its public endpoint, gated only by firewall rules. Azure Cosmos DB defaults to accepting traffic from all networks unless you define firewall rules or disable public access outright. Each is its own Defender for Cloud recommendation, but the underlying risk is identical: a database that more of the internet can reach than you meant.

Microsoft Defender for Cloud turns each of these into its own recommendation, which is why one data-heavy subscription can fail several database checks at once. 'Public network access on Azure SQL Database should be disabled', 'Public network access should be disabled for PostgreSQL servers' and 'Azure Cosmos DB accounts should have firewall rules' read as three separate problems on the report, but they are one job: stop databases from being reachable on a public endpoint, and route the legitimate traffic through a private endpoint or a known, named set of trusted networks instead.

Most of this exposure is drift, not intent. A SQL server created before private endpoints were standard, a PostgreSQL server spun up with public access for a quick connection test, a Cosmos DB account that nobody ever put firewall rules on. A firewall rule of 0.0.0.0 to 255.255.255.255, or the 'Allow access from Azure services' checkbox left ticked, quietly turns a database into an internet-facing one. The work is to find every database that is reachable more widely than intended, decide which genuinely need a public path, scope those down to named networks, and move the rest behind a private endpoint.

In this lesson you will learn how Azure's managed databases express public reachability, how SQL Database, PostgreSQL and Cosmos DB each differ in the detail, how to find every over-exposed database in a subscription, and how to lock them down without breaking the applications that legitimately connect to them. 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 firewall rule that let the whole internet in

One of the most common ways an Azure database ends up exposed is a single firewall rule with a start address of 0.0.0.0 and an end address of 255.255.255.255, added during a connectivity test and never removed. It reads like a narrow allow-list entry, but it permits every address on the internet. The 'Allow access from Azure services' option has caused similar surprises: it opens the database to traffic from any Azure tenant, not just your own, which means another customer's compromised workload can reach your endpoint. Setting public network access to Disabled sidesteps both, because firewall rules stop being evaluated at all and only private-endpoint connections are accepted.

Finding database exposure across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows database findings spread across several SQL servers, a couple of PostgreSQL servers and a Cosmos DB account in two subscriptions that pre-date the team's current guardrails.

Rather than work the findings one by one, Sam starts by listing which SQL servers still have public network access enabled, so the databases that are reachable on a public endpoint can be separated from the ones already behind a private endpoint before anything changes.

Start by listing the SQL servers that still answer on their public endpoint. These are the widest-open doors.

$ az sql server list --query "[].{name:name, public:publicNetworkAccess}" -o table

Name Public

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

custrecords-prod Enabled

reporting-stage Enabled

ledger-prod Disabled

# custrecords-prod is reachable on the public endpoint. Close it first.

A production server holding customer records and answering on a public endpoint is the highest-value target in this group. Fix these before the staging servers.

How Defender for Cloud decides a database is exposeddeep dive

Each service exposes the same idea through a slightly different property. Azure SQL Database and Azure Database for PostgreSQL both have a 'publicNetworkAccess' setting: when it is Enabled, the server answers on its public endpoint and lets through any connection that matches an IP or virtual-network firewall rule, so the firewall rules are the only thing between the internet and the database. When it is Disabled, the public endpoint stops answering entirely, firewall rules are no longer evaluated, and the only path in is a private endpoint inside your virtual network. Azure Cosmos DB is assessed differently: the 'Azure Cosmos DB accounts should have firewall rules' recommendation is satisfied when the account has at least one IP rule with the virtual-network filter enabled, or when public network access is disabled outright, so an account that accepts traffic from all networks fails the check.

Two settings quietly widen exposure on SQL and PostgreSQL servers. A firewall rule from 0.0.0.0 to 255.255.255.255 allows the entire internet despite looking like a narrow entry, and the 'Allow Azure services and resources to access this server' option admits traffic from any Azure tenant, not only yours. On Cosmos DB, the equivalent trap is the 0.0.0.0 IP rule, which Microsoft treats as 'accept connections from Azure datacentres' and which the 'should not allow traffic from all Azure data centers' recommendation flags separately.

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. The strongest position combines the per-server setting with an Azure Policy backstop: a deny policy on 'publicNetworkAccess' for SQL and PostgreSQL means no new server can be created on a public endpoint, which is the difference between checking nothing is exposed today and guaranteeing nothing can be exposed tomorrow.

What is the impact of leaving a database public?

The direct impact is data exposure at the most sensitive point in the estate. A database reachable on its public endpoint is discoverable by automated scanners and exposed to credential-stuffing, brute-force and exploitation of any unpatched engine vulnerability. Unlike a single leaked file, a compromised database often means the whole dataset: every customer record, every transaction, every secret stored in a row. The overwhelming majority of these incidents are accidents: a public-access toggle left Enabled, a 0.0.0.0 firewall rule from a test, an 'allow Azure services' box nobody unticked.

The second-order impact is blast radius. Every database answering on a public endpoint is attack surface that has to be defended continuously, and it sits right next to the data you most need to protect. Moving databases behind private endpoints shrinks that surface to traffic that originates inside your own virtual network, which is the traffic you can actually reason about, monitor and contain.

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 directly reachable from the public internet and that access is restricted to known networks. A passing set of database recommendations across every subscription, with public network access disabled and private endpoints in place, is one of the most defensible artefacts you can hand an auditor.

How do you lock databases down safely?

Work the capability as one loop rather than chasing individual findings. The order matters: find out how each database is actually connected to before you start closing public endpoints, so you do not cut off a live application that has no private path yet.

1. Inventory every database by exposure

List the SQL and PostgreSQL servers with public network access enabled, and the Cosmos DB accounts without firewall rules or with an open 0.0.0.0 rule. Treat this inventory as the source of truth, not the Defender finding count, because the three services express the same risk differently and one subscription can trigger several recommendations at once.

2. Map how each database is reached before you close anything

For each database, confirm how the applications that use it connect today. A database whose clients already run inside the virtual network can move behind a private endpoint with no disruption. A database reached over the public endpoint needs its clients re-pointed to a private endpoint, or a tightly scoped firewall rule, before you disable public access, or the application breaks.

3. Close the public endpoints, highest impact first

For SQL and PostgreSQL, create a private endpoint, then set public network access to Disabled. For Cosmos DB, add firewall rules scoped to your virtual network or disable public access outright, and remove any 0.0.0.0 rule. Prioritise production databases that hold sensitive data over empty ones. Remember that on SQL and PostgreSQL, disabling public access stops firewall rules being evaluated, so the private endpoint must already be in place.

4. Ratchet it shut with Azure Policy

Assign deny policies so no new SQL or PostgreSQL server can be created with public network access enabled, and audit Cosmos DB accounts for firewall rules. Back this with a private-endpoint requirement for the regulated workloads that need it, so the safe configuration is enforced rather than merely encouraged.

# Close the highest-impact database exposure first: production servers on a public endpoint.
# Make sure a private endpoint is in place BEFORE disabling public access,
# otherwise in-VNet clients lose their path in.

# Azure SQL Database server
az sql server update --name custrecords-prod --resource-group data-prod \
  --set publicNetworkAccess=Disabled

# Azure Database for PostgreSQL flexible server
az postgres flexible-server update --name billing-prod --resource-group data-prod \
  --public-access Disabled

# Azure Cosmos DB: scope to the VNet and drop the open Azure-datacentres rule
az cosmosdb update --name sandbox-cosmos --resource-group data-prod \
  --ip-range-filter "" --public-network-access Disabled

# Ratchet it shut: deny any future SQL server that allows public network access.
az policy assignment create \
  --name deny-sql-public-access \
  --policy 1b8ca024-1d5c-4dec-8995-b1a932b41780 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud shows public-access findings across an Azure SQL server, a PostgreSQL server and a Cosmos DB account. What is the most efficient way to think about them?

Keep learning

Go deeper on how each Azure database service expresses public reachability and how to route the legitimate traffic privately.

You can now treat Azure database exposure as one capability rather than a scatter of findings across SQL, PostgreSQL and Cosmos DB: inventory what is reachable on a public endpoint or lacks firewall rules, map how each database is reached before you close anything, move the production stores behind private endpoints 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

Restricting database public access: the cost and risk view

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

A database open to the internet is among the highest expected-loss findings on any Azure security report, and almost every control in this group costs nothing in Azure spend to fix. Setting public network access to Disabled on a SQL or PostgreSQL server, or adding firewall rules to a Cosmos DB account, does not change your bill. The cost sits entirely in the few exceptions: the databases that genuinely need a private path adopt an Azure Private Endpoint, which carries a small hourly charge plus a per-gigabyte data-processing fee, and the workloads that previously connected over the public endpoint may need a short, bounded change to route through a virtual network instead.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A production SQL Database holding customer records reachable on its public endpoint carries a far higher expected loss than an empty developer Cosmos DB 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 private-endpoint charge for the databases that need one. The downside of leaving it is the documented cost of a database breach: regulatory fines, breach notification, forensics, legal fees and reputational damage, against data that is usually the most sensitive the organisation holds.

This lesson is for the finance partner who sees a cluster of database 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, why the private-endpoint exception carries only a small bounded charge, and how to turn a list of red findings into a risk-ordered remediation plan led by the sensitivity of the data each database holds.

Fun fact

The firewall rule that let the whole internet in

How a finance partner frames the database decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with nine database findings spread across several SQL and PostgreSQL servers and a Cosmos DB account 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. Setting public network access to Disabled on a SQL or PostgreSQL server, or adding firewall rules to a Cosmos DB account, changes nothing on the Azure bill, so the spend question is narrow: only the databases that need a private path carry a real cost, and a private endpoint is a small hourly charge plus a per-gigabyte data-processing fee, not a large capital line.

Sam asks the team to map each failing database to the data sitting behind it. The production SQL Database holds customer records, one PostgreSQL server backs the billing service, the Cosmos DB account is a developer sandbox, and a couple of servers are empty staging environments. The list is reframed on the risk register: the customer-records and billing databases are high expected-loss items to move behind a private endpoint first, each at a small bounded charge; the staging servers are zero-cost closures to sweep up; the sandbox is low-value drift. The finance pack reads: 'Seven findings close at no incremental spend; two production databases need a private endpoint at a small monthly charge each; the only thing standing between us and a clean posture is engineering time, not budget.'

Why database exposure belongs on the risk register

The cost model here is asymmetric in a way that is rare for security work. Locking a database down costs nothing in Azure spend for the great majority of servers, and only a small bounded private-endpoint charge for the ones that need a private path, while leaving it open creates an unbounded tail risk against the most sensitive data the organisation holds. Each failing recommendation is a database where a future accident or a stolen credential could expose its entire contents, and while the probability per event is low, the probability across all databases over years is not.

The documented cost of a database breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn, all weighted by the fact that a database breach usually means the full dataset rather than a fragment. Against that, the remediation is engineering time plus a small per-endpoint charge for the databases that need a private path. The finance role is to attach expected loss to each failing database, weighted by the sensitivity of the data behind it, so the work is prioritised by risk, not by the order the report lists it.

What finance can do about the database gap

Finance cannot disable a public endpoint, 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 private-endpoint exceptions

Make explicit that the majority of database findings cost nothing in Azure spend to fix: disabling public network access or adding firewall rules does not move the bill. The only real cost sits in the databases that adopt a private endpoint, which is a small hourly charge plus a per-gigabyte data-processing fee per endpoint. 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, weighted by the data behind each database

A production SQL Database holding customer records and an empty staging server both show up as a single red finding, but their expected loss differs by orders of magnitude, and a database breach usually means the full dataset. Ask the team to map each failing recommendation to the data behind it and prioritise the production data stores first. The metric that belongs on the cost-and-security review is the count of database findings weighted by the sensitivity of what they hold, not the raw total.

3. Require documented exceptions for any database with an external path

Any database that has to remain reachable from outside the virtual network, a partner integration endpoint, a managed analytics connector, should carry a recorded, finance-visible reason and the named, scoped networks it allows. The distinction between 'we reviewed this and scoped it deliberately' and 'we never noticed public access was on' 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 nine database public-access findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how each Azure database service expresses public reachability and how to route the legitimate traffic privately.

You have finished the finance view of restricting database public access. You know the cost model is one-sided: closing the great majority of findings is free in Azure spend, only the databases that adopt a private endpoint carry a small bounded charge, and the downside of leaving exposure open is the documented and unbounded cost of a breach of the most sensitive data the organisation holds. Next time a cluster of database findings lands, you will order them by expected loss weighted by the data behind each one, ring-fence the real exceptions, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Restricting database public access: the headline

Whether the databases that hold the organisation's data can be reached from the internet at all

A database is where the organisation's data lives, and one that answers on a public endpoint is one stolen credential or one brute-forced login away from being read at scale. The report shows this as a scatter of separate findings across SQL, PostgreSQL and Cosmos DB, but the question behind all of them is the same.

The leadership question is not 'are we compliant today?' It is 'can the databases that hold our most important data be reached from the public internet?' The defensible end state is that public network access is disabled by policy on the managed databases, the legitimate traffic flows through private endpoints inside the virtual network, and the small number of databases that genuinely need an external path are scoped to named, documented networks rather than left open to all.

None of this is a cost decision. Locking databases down is essentially free in Azure terms, give or take a small private-endpoint charge. It is a governance decision about whether the front door to the organisation's data is closed by design or only by everyone remembering to set a firewall rule.

A short read for the leader who needs to know what an internet-reachable database exposes, why locking it down is a governance decision rather than a budget one, and what a defensible end state looks like across Azure SQL Database, PostgreSQL and Cosmos DB.

Fun fact

The firewall rule that let the whole internet in

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

After a peer company disclosed a breach that traced back to a database server left reachable on its public endpoint, 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 disable public access and set firewall rules, because reachability across the database estate was governed by habit rather than policy.

The team's response was to stop treating databases as a per-server cleanup and start treating it as a guardrail. They listed every SQL and PostgreSQL server that still answered on a public endpoint and every Cosmos DB account without firewall rules, moved the production databases behind private endpoints, scoped the few that needed an external path to named networks, and then set an Azure Policy that denies the creation of any new SQL or PostgreSQL server with public network access enabled. 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 handful of databases with an external path are documented.' That shift, from relying on everyone remembering to set a firewall rule to making the mistake structurally hard, is the one-line confidence signal this capability delivers, and it costs almost nothing in Azure spend to reach.

Why this is a board-level risk

Nearly every major cloud breach that exposed a full customer dataset came back to the same root cause: a database that could be reached by more of the internet than intended was, because of an internal change or a forgotten test rule. Locking databases down is the capability that makes that root cause structurally difficult, and an Azure Policy backstop on public network access makes it close to impossible.

The cost of getting this wrong is large, well documented and concentrated on the most sensitive data the organisation holds, while the cost of fixing it is essentially engineering time plus a small private-endpoint charge. 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 database access

The executive handle is not to approve each closure individually; it is to require that database public access is prevented by policy and that the small number of databases with an external path are scoped to named networks, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, the production databases are behind private endpoints, the rest have public access disabled, and Azure Policy denies the creation of any new SQL or PostgreSQL server with public network access enabled. A backstop that no individual server 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 database recommendations across every subscription plus evidence that the deny policies are assigned and the private endpoints are in place. 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 databases with an external path as named, owned exceptions

A small number of databases may genuinely need to be reachable from outside the virtual network, and that can be fine. The leadership requirement is that each is a deliberate, documented decision with an owner and a scoped, named set of trusted networks, not a public endpoint left open to all. The goal is not zero external paths; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a database breach 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 each Azure database service expresses public reachability and how to route the legitimate traffic privately.

Two takeaways. A database open to the internet is the rare control where the risk of inaction is severe, concentrated on your most sensitive data, and the cost of action is essentially engineering time plus a small private-endpoint charge, 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 public network access on the managed databases, making accidental exposure structurally hard, with the few deliberate external paths documented, owned and scoped to named networks.

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 SQL Managed Instance

Azure SQL Managed Instances should disable public network access Medium A public endpoint on a managed instance widens the attack surface beyond the virtual network and private links

Databases

SQL

Public network access on Azure SQL Database should be disabled Medium Azure SQL Database is reachable from any network rather than a private endpoint

Part of the learning path Close Azure network exposure

Restrict public network access to Azure databases

Restricting database public access: the basics

The firewall rule that let the whole internet in

Finding database exposure across a subscription

How Defender for Cloud decides a database is exposeddeep dive

What is the impact of leaving a database public?

How do you lock databases down safely?

1. Inventory every database by exposure

2. Map how each database is reached before you close anything

3. Close the public endpoints, highest impact first

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Restricting database public access: the cost and risk view

The firewall rule that let the whole internet in

How a finance partner frames the database decision

Why database exposure belongs on the risk register

What finance can do about the database gap

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

2. Order the work by expected loss, weighted by the data behind each database

3. Require documented exceptions for any database with an external path

Quick quiz

Keep learning

Restricting database public access: the headline

The firewall rule that let the whole internet in

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

Why this is a board-level risk

The leadership move on database access

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat databases with an external path as named, owned exceptions

Quick quiz

Keep learning

Controls this lesson covers

Azure SQL Managed Instance

Databases

SQL

Related compliance lessons