An Azure SQL database is created with a public endpoint and a firewall in front of it, which means the only thing standing between your customer records and the internet is a list of allowed addresses. That is workable when the list is short and reviewed. It stops being workable the moment somebody adds a broad range to make a deployment work, and the Information Commissioner’s Office takes a close interest in databases exposed that way.
The firewall rule that undoes the rest
Two settings cause most of the exposure. The first is a rule permitting a wide address range, often added during troubleshooting and never narrowed. The second is the option allowing Azure services to connect, which sounds internal and is not: it permits connections from resources in other tenants, so an attacker with any Azure subscription can attempt to reach your server. Turn it off and use explicit rules or private connectivity instead, then check the rule list for anything wider than a single address you can attribute.
Moving to private endpoints
A private endpoint gives the database an address inside your virtual network and lets you disable public access entirely. That removes the internet as an attack path and shifts the question to who can reach it from inside, which is a much better problem to have. Plan the DNS side carefully, since the private endpoint depends on a private DNS zone resolving the server name to the internal address, and applications that resolve the public name will fail in ways that look like a database outage rather than a naming issue. Test the change in a non-production subscription first so the DNS behaviour is understood before it matters.
“Check who is connecting before you close the public path, not afterwards. Every estate has a reporting tool, an integration or somebody’s laptop that connects directly, and finding out during the change window is how a security improvement becomes an incident. Turn on connection auditing for a fortnight and read the list.”
William Fieldhouse, Director, Aardwolf Security Ltd
Authentication and the accounts nobody removes
Prefer Entra ID authentication over server logins, because it gives you conditional access, group-based management and a leaver process that actually reaches the database. Where SQL logins remain, check for accounts created during migrations, shared logins used by several applications, and passwords stored in application settings rather than a vault. Set an Entra administrator group rather than an individual, and make sure the account used by your monitoring tools has read access to what it monitors and nothing more. Review the login list whenever an application is retired, since its credentials usually outlive it.
Verifying rather than assuming
Test from outside the network and from a machine inside it, since the two answers are different and both matter. Azure infrastructure penetration testingcovers whether the database is reachable, what the firewall rules actually permit and which identities can reach it through other resources. Database vulnerability scanning covers configuration and patching on the platform side, including whether auditing is enabled and retained long enough to answer a question after an incident.
Frequently asked questions about Azure SQL exposure
These questions come up whenever a cloud database is reviewed.
Is a firewall rule list enough?
It is a real control and a fragile one, because rules accumulate and nobody removes them. Private endpoints remove the class of problem, so treat the firewall as an interim measure where private connectivity is not yet possible.
Does encryption at rest help here?
Not against this. Transparent encryption protects the stored files against theft of the underlying media, and an attacker connecting with valid credentials reads the data exactly as your application does.
