Azure Cosmos DB accounts should have firewall rules

What does the recommendation "Azure Cosmos DB accounts should have firewall rules" check?

Flags any Azure Cosmos DB account that accepts traffic from any source IP, meaning it has no IP firewall rule, no virtual network filter and public network access left open. An account is treated as compliant once it has at least one IP rule defined ('ipRules', or the older 'ipRangeFilter' on API versions before 2020-04-01), a virtual network filter enabled, or public network access disabled outright. It checks the account-level network boundary only: it does not validate authorization tokens, role-based access, key rotation, encryption settings or whether your allowed IP ranges are actually narrow. A wide-open range such as 0.0.0.0/0 will still register as compliant even though it offers no real protection, so a pass here is necessary but not sufficient.

Why does "Azure Cosmos DB accounts should have firewall rules" matter?

A Cosmos DB account with no firewall is reachable from the entire internet, so its only defence is the access key or token. Keys leak through committed config files, CI logs, browser bundles and shared scripts, and once one does there is nothing left to stop an attacker reading or exfiltrating your whole dataset from anywhere on the planet. The ChaosDB disclosure showed how quickly exposed Cosmos endpoints become mass-scanning targets, and a breach of customer data here carries direct regulatory and contractual consequences. An IP allow-list or virtual network restriction means a stolen key alone is no longer enough, because the request must also originate from a source you trust, which buys you time to rotate the key before any data leaves.

How do I fix "Azure Cosmos DB accounts should have firewall rules"?

1. Decide the access model: for app traffic inside Azure, set 'publicNetworkAccess' to Disabled and use a private endpoint or a VNet service endpoint rule; for a fixed set of office or gateway IPs, populate 'ipRules' with those CIDR ranges instead of leaving it empty.
2. Apply it with the az CLI: 'az cosmosdb update --name <acct> --resource-group <rg> --ip-range-filter "<comma-separated-ranges>"', or in Bicep set the account's 'ipRules' array and 'isVirtualNetworkFilterEnabled' to true; remember that setting public network access to Disabled overrides the 'Accept connections from within Azure datacenters' option.
3. Bake the locked-down network boundary into your Bicep or Terraform module so every new Cosmos account ships with a firewall by default rather than depending on someone remembering to add one.

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