Azure SQL Managed Instances should disable public network access

What does the recommendation "Azure SQL Managed Instances should disable public network access" check?

Flags any SQL Managed Instance where the public data endpoint is enabled, by reading the 'publicDataEndpointEnabled' property. When that property is true, the instance is reachable on its public endpoint over TCP port 3342, so clients can connect from the internet rather than only over the virtual network. This is specifically about the public data endpoint: it does not check the management endpoint, the firewall or NSG rules that gate port 3342, whether a private endpoint exists, or how individual databases inside the instance authenticate. An instance can satisfy the check while still being privately reachable through its VNet integration.

Why does "Azure SQL Managed Instances should disable public network access" matter?

The public data endpoint puts a managed database engine, often holding production or regulated data, on a routable internet address. Even with strong credentials and an NSG, every exposed instance is one weak password, leaked connection string or unpatched gateway away from an unauthenticated reach attempt, and these endpoints are scanned continuously. A breach here is rarely contained: managed instances frequently hold whole application datasets, so the business consequence is bulk data exfiltration, a reportable incident and the recovery cost that follows. Disabling the public endpoint removes that internet attack surface entirely, leaving the VNet and private endpoints as the only paths in.

How do I fix "Azure SQL Managed Instances should disable public network access"?

1. Set the public data endpoint to off on the instance. In the portal this is under Security, Networking, where you clear 'Public endpoint (data)'. With the CLI: az sql mi update --resource-group <rg> --name <instance> --public-data-endpoint-enabled false. In Bicep, set properties.publicDataEndpointEnabled to false on the Microsoft.Sql/managedInstances resource.
2. Move clients onto a private path before or alongside the change: connect over the VNet, peering or VPN/ExpressRoute, or create a private endpoint, since existing port 3342 connections will not reconnect once public access is removed.
3. Enforce the safe default at scale by assigning the built-in policy with its Deny effect so new instances cannot enable the endpoint. Look the definition up by name rather than hardcoding a GUID: pid=$(az policy definition list --query "[?displayName=='Azure SQL Managed Instances should disable public network access'].name" -o tsv); az policy assignment create --name deny-mi-public --policy "$pid" --params '{"effect":{"value":"Deny"}}' --scope <scope>.

# 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"