Harden Azure MySQL and PostgreSQL

Database exposure is one of the highest-consequence findings in Azure, because the data is live and structured, and almost every control in this group costs nothing in Azure spend to fix. Disabling public network access, enforcing SSL, provisioning a Microsoft Entra administrator or turning on pgaudit does not change your bill. The cost sits in a few exceptions: a private endpoint adds a small Private Link hourly charge, geo-redundant backup roughly doubles backup storage for the protected servers, and customer-managed keys add a small Key Vault charge for the regulated workloads that genuinely require them.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A production PostgreSQL server holding customer records with public access enabled and SSL off carries a far higher expected loss than an empty development MySQL instance, yet both can surface as a single red finding. Map the failures to the data behind them and prioritise by exposure, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time plus a small, bounded, recurring cost on the servers that adopt a private endpoint, geo-redundant backup or a customer-managed key. The downside of leaving it is the documented cost of a database breach or a regional data loss: regulatory fines, breach notification, forensics, legal fees, lost data and reputational damage.

Priya is the finance partner supporting the platform team's ISO 27001 push. The security report lands with sixteen database findings spread across a dozen MySQL and PostgreSQL servers in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Disabling public access, enforcing SSL, provisioning a Microsoft Entra administrator or turning on pgaudit changes nothing on the Azure bill, so the spend question is narrow: only the servers that adopt a private endpoint carry a small Private Link charge, only the servers that turn on geo-redundant backup roughly double their backup storage, and only the regulated workloads that adopt a customer-managed key add a small Key Vault charge.

Priya asks the team to map each failing server to the data sitting behind it. Two PostgreSQL servers hold live customer data with public access on and SSL off, one MySQL server is a reporting replica, and the rest are development or staging servers with audit and Entra simply never configured. The list is reframed on the risk register: the two customer-data servers are high expected-loss items to close today at near-zero Azure cost, the production servers get private endpoints and geo-redundant backup as small bounded recurring lines, and the development servers are low-value drift to sweep up for free. The finance pack reads: 'Thirteen findings close at no incremental spend; three production servers take a small, bounded private-endpoint and geo-backup cost; the only thing standing between us and a clean posture is engineering time, not budget.'

The cost model here is asymmetric in a way that is rare for security work. Locking databases down costs nothing in Azure spend for the great majority of controls, public access, SSL enforcement, Entra administrators and pgaudit are all free, and leaving them open creates an unbounded tail risk on live, structured data. Each failing recommendation is a server where a future accident could expose or lose its contents, and while the probability per event is low, the probability across all servers over years is not.

The documented cost of a database breach or a regional data loss includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, lost data and customer churn. Against that, the remediation is engineering time plus a small, bounded recurring cost on the servers that adopt a private endpoint or geo-redundant backup, and a small Key Vault charge for customer-managed keys where a workload needs one. The finance role is to attach expected loss to each failing server so the work is prioritised by risk, not by the order the report lists it.

Open-source databases are where the live customer data sits, so a configuration mistake here turns straight into a headline. A MySQL or PostgreSQL server reachable from the public internet, accepting cleartext connections or signed in with a shared password is one bad change away from exposing data, and the report shows this as a scatter of separate findings.

The leadership question is not 'are we compliant today?' It is 'if a deployment makes a mistake tomorrow, can it expose, or quietly drain, a production database?' The defensible end state is that public access is disabled by policy, connections are encrypted, identity runs through Microsoft Entra, activity is audited and the important servers are backed up across regions.

Almost none of this is a cost decision. Locking down database access and identity is essentially free in Azure terms, and only private endpoints, geo-redundant backup and customer-managed keys carry a small, bounded charge. It is a governance decision about whether exposure is prevented by design or only by everyone remembering not to make a mistake.

After a peer company made the news for a customer database that turned out to be an Azure server left open to the public internet, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to check, because public access, SSL enforcement and identity across the database estate were governed by habit rather than policy.

The team's response was to stop treating databases as a per-server cleanup and start treating them as a guardrail. They listed every MySQL and PostgreSQL server that allowed public network access or accepted cleartext connections, moved the production servers onto private endpoints, enforced SSL everywhere, provisioned a Microsoft Entra administrator, turned on pgaudit, enabled geo-redundant backup on the servers that mattered, and then set Azure Policy to deny the creation of any new server with public access enabled. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the platform prevents it by design, and every production database is private, encrypted, audited and recoverable.' That shift, from relying on everyone remembering not to make a mistake to making the mistake structurally hard, is the one-line confidence signal this capability delivers, and almost all of it costs nothing in Azure spend to reach.

Nearly every major cloud data breach that involved a database came back to the same root cause: a server that could be reached, read or signed into by more of the internet than intended was, because of an internal change. Locking databases down is the capability that makes that root cause structurally difficult, and an Azure Policy backstop on public access makes it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is mostly engineering time plus a small, bounded charge for private endpoints, geo-redundant backup and customer-managed keys on the servers that matter. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.