Microsoft Defender for Cloud · SQL
Public network access on Azure SQL Database should be disabled
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Public network access on Azure SQL Database should be disabled" check?
Flags any Azure SQL logical server whose 'publicNetworkAccess' property is set to 'Enabled', meaning the server is reachable over its public endpoint (the '<server>.database.windows.net' address) and admits any connection that passes an IP or virtual-network firewall rule. It checks the server-level switch only. It does not assess how permissive those firewall rules are, whether a private endpoint exists, the strength of the credentials in use, or the security of the databases themselves once a session is established. A server can therefore pass this control and still be poorly protected in other respects, and vice versa.
Why does "Public network access on Azure SQL Database should be disabled" matter?
While the public endpoint is open, your databases are exposed to the entire internet and defended by nothing but firewall rules and authentication. A single over-broad rule, such as the 0.0.0.0 entry created by the 'Allow Azure services and resources to access this server' option, or one leaked connection string turns that endpoint into a direct path to production data and a target for data exfiltration or ransomware. Credential-stuffing and brute-force attempts against public SQL endpoints are continuous and automated, and a successful login leaves few obvious traces. Setting public access to 'Disabled' forces every connection through a private endpoint on your own virtual network, so an attacker must first gain a foothold inside that network before they can even reach the login prompt, which sharply narrows the attack surface and the blast radius of any stolen credential.
How do I fix "Public network access on Azure SQL Database should be disabled"?
- Provision a Private Endpoint for the SQL server in the subnet your application uses, and confirm the application resolves the server's name to the private IP via Azure Private DNS before you cut off public access.
- Set 'publicNetworkAccess' to 'Disabled' on the server, for example 'az sql server update -n <server> -g <rg> --set publicNetworkAccess="Disabled"'. Note this denies all firewall-rule-based logins, so no public IP or VNet rule will work once it is off.
- Bake the disabled setting into your Bicep or Terraform server definition so newly provisioned servers are private by default, and use the built-in 'Configure Azure SQL Server to disable public network access' policy to remediate any that drift back.
Remediation script · bash
# 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"Full walkthrough (console steps, edge cases and verification) in the lesson Restrict public network access to Azure databases.
Is "Public network access on Azure SQL Database should be disabled" a false positive?
A server reachable only over its public endpoint by design will still flag, because the control judges the switch and not your firewall rules. Common legitimate cases include a server mid-migration before private connectivity is wired up, a non-production instance firewalled down to a single trusted office address, or a managed service that genuinely cannot use private endpoints yet. Each is a valid exception, but treat it as one: record the business reason and an owner, scope the firewall rules as tightly as possible, and set a review date rather than leaving the public endpoint open indefinitely.