How to Prevent Public Database Exposure With Azure Policy and Private Endpoints

Retrospective: this article looks back at events from January 2020, written in 2026 with the benefit of hindsight.

A single network rule change exposed a Microsoft database to the internet in 2019. Azure Policy and private endpoints let you prevent that class of mistake across your environment. Here is how.

Step 1: Inventory public exposure

Use Microsoft Defender for Cloud recommendations and Azure Resource Graph to list:

• Storage accounts, SQL servers, Cosmos DB accounts, Key Vaults and other PaaS services with public network access enabled.
• VMs with public IPs and NSGs allowing inbound traffic from the internet.

Step 2: Move data services to private endpoints

For each data service:

1. Create a private endpoint in the appropriate virtual network.
2. Configure private DNS zones so names resolve to private IPs.
3. Set public network access to Disabled.
4. Test application connectivity.

Step 3: Assign Azure Policy to prevent regression

Assign built-in policies at the management group level, for example:

• "Storage accounts should disable public network access."
• "Azure SQL Database should disable public network access."
• "Azure Cosmos DB accounts should disable public network access."
• "Azure Key Vault should disable public network access."

Start with Audit effect to measure impact, then switch to Deny for new resources.

Step 4: Control network rules

Use policies and change management to restrict NSG rules allowing inbound from Internet or *, and alert on new ones.

Step 5: Handle exceptions

Some services need public endpoints. Require documented exemptions in Azure Policy with an expiry date.

Verify

Defender for Cloud's recommendations for public network access should trend to zero, and new non-compliant resources should be blocked at deployment.