Azure database firewall permits broad access

Review broad Azure database firewall ranges and service-access exceptions, and allow only the clients that need access.

Description

Allowing a broad address range on a public database endpoint can let clients that do not need access attempt connections. An appropriate scope cannot be determined by counting addresses alone. Review the actual sources used by applications and administration tools together with all firewall rules.

In Azure SQL Database, setting both start_ip_address and end_ip_address to 0.0.0.0 enables an exception for Azure service connections. This can include other customers' Azure resources; it is not restricted to your subscription. Check the meaning of firewall exceptions for each service. Allowing a network connection does not replace authentication or database permissions.

Potential impact

  • Unnecessary sources or a broad set of services can attempt database connections.
  • Additional access paths can increase opportunities to misuse leaked credentials or excessive data permissions.

Remediation

  • Identify approved applications' and administration tools' actual source addresses and allow only those required. On public paths, use the public address after NAT. Review all firewall rules and remove unnecessary Azure-service exceptions. Splitting a range into multiple rules does not reduce the access granted.
  • If public access is unnecessary, configure and test the service's supported private connectivity, DNS, and client paths before disabling public access.
  • Use the syntax for your AzureRM version and review Terraform state and the change plan. After applying changes, verify required connections, rejection of unwanted sources, authentication, and least-privilege data permissions.

Examples

These partial examples use AzureRM v4.50.0 azurerm_mssql_firewall_rule to narrow a range to one client address. Define azurerm_mssql_server.example and replace the documentation addresses with actual approved sources. Review Terraform state and the plan when migrating from a former resource type.

Before

hcl
resource "azurerm_mssql_firewall_rule" "wide_firewall_rule" {
  name                = "FirewallRule1"
  server_id           = azurerm_mssql_server.example.id
  start_ip_address    = "203.0.113.0"
  end_ip_address      = "203.0.113.255"
}

After

hcl
resource "azurerm_mssql_firewall_rule" "wide_firewall_rule" {
  name                = "FirewallRule1"
  server_id           = azurerm_mssql_server.example.id
  start_ip_address    = "203.0.113.10"
  end_ip_address      = "203.0.113.10"
}

Explanation:

  • Before: The entire example range is allowed. Review whether every address in it is needed.
  • After: The range is narrowed to the single source 203.0.113.10. Also check the combined access granted by other rules and service exceptions.

References