Microsoft Defender for Cloud · Databases
Public network access should be disabled for PostgreSQL flexible servers
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Public network access should be disabled for PostgreSQL flexible servers" check?
Flags any Azure Database for PostgreSQL flexible server whose 'publicNetworkAccess' property is set to Enabled, meaning the server is reachable over a public endpoint and is governed by IP firewall rules rather than confined to a private network. It checks the server-level access mode only: it does not inspect which firewall rules exist, whether the 'allow public access from any Azure service' rule is present, or whether a private endpoint has already been added alongside the public one. A server can therefore pass this control while still carrying a loose firewall, and the reverse is also true, so treat it as the first gate rather than a complete network review.
Why does "Public network access should be disabled for PostgreSQL flexible servers" matter?
A publicly reachable database server is exposed to credential-stuffing, brute-force login attempts and exploitation of any unpatched engine vulnerability from anywhere on the internet, with a permissive firewall rule the only thing standing between an attacker and your data. One overly broad rule, often added during a rushed migration or a 'temporary' debugging session, turns the server into an open target, and PostgreSQL servers commonly hold the most sensitive records an organisation owns: customer identities, financial transactions and application secrets. A breach there means regulatory exposure and notification obligations, not just an incident ticket. Disabling public network access forces all connections through a private endpoint inside your virtual network, so a leaked connection string or weak password is no longer enough to reach the server.
How do I fix "Public network access should be disabled for PostgreSQL flexible servers"?
- Confirm every legitimate client can reach the server privately before you close the public door: add an Azure Private Endpoint, or use VNet integration, so applications connect over a private IP rather than the public hostname.
- Disable the public endpoint with 'az postgres flexible-server update --resource-group <rg> --name <server> --public-access disabled', which sets 'network.publicNetworkAccess' to Disabled. Be aware that existing firewall rules are no longer enforced and edits to them are discarded once public access is off.
- Bake the safe default into your Bicep or Terraform modules by setting 'publicNetworkAccess' to 'Disabled' on the flexible server resource, so new databases ship private and an Azure Policy assignment can audit any that drift back to a public endpoint.
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 should be disabled for PostgreSQL flexible servers" a false positive?
A server kept on the public endpoint for a genuine reason, for example a SaaS analytics tool or a partner integration that cannot route through your virtual network, will still flag, because the control measures whether the public endpoint is open rather than whether you tightened the firewall around it. Where that is a deliberate, reviewed decision, document the exception and lock the firewall rules to specific source IP ranges rather than leaving the server reachable from everywhere. Suppress the finding through Defender for Cloud so the exception is recorded and revisited rather than silently ignored.