A Managed Database Is Not a Secured Database

“It runs on a managed database service, so the provider handles the database’s security.”

Split that sentence in half before it becomes a line in somebody’s risk acceptance.

A managed database is not a secured database.

A managed service changes who patches the engine.

It does not change who decides whether the engine answers a stranger.

Both of these are true on the same instance, on the same afternoon.

On Amazon RDS, the provider operates the infrastructure layer, the underlying operating system and the database platform itself.

It patches the engine.

It secures the host.

You keep data classification, encryption configuration and the identity-and-access-management policy layered on top.

That is a real allocation, and a useful one.

It is also an allocation of work, not a description of an outcome.

“Managed” names who maintains the platform.

“Secured” is a property of the whole system, including every part the provider never touches.

Nobody would say “the landlord services the boiler, so the front door locks itself.”

Put the building in a cloud region and it starts to sound like an architecture decision.

1. “But the Provider Patches the Database Engine for Us.”

Yes.

And that matters.

Self-host the same engine on a virtual machine and the work comes straight back.

Guest operating-system patching.

Database software installation and hardening.

Network-level firewall configuration.

All of it becomes your deploying team’s job, while the provider’s share recedes to the physical infrastructure and the hypervisor beneath it.

So a managed service removes an entire category of failure: an unpatched database engine version with a known vulnerability.

That category is gone from your backlog.

Take the win.

Now look at what did not move.

Access control, encryption policy and audit logging are yours to configure in both models.

Managed or self-hosted, the provider is not choosing who can connect, which roles exist, which settings are on, or where the copies go.

Patching is a maintenance task. Reachability and access are configuration decisions.

A managed service takes the maintenance task.

It cannot take the decisions, because it has no way of knowing your answers.

It does not know that this instance should only answer the application subnet.

It does not know that the reporting role was supposed to be temporary.

It does not know that the export bucket was meant for one migration and never deleted.

Those are your facts.

They stay in your column.

2. “But NoSQL Databases Were Only Insecure Years Ago.”

The history is real, and it is dated.

Mainstream relational engines have required authentication by default for essentially their entire modern history.

A fresh PostgreSQL or MySQL install with no configured users is, in practice, unusable rather than open.

MongoDB’s early default ran the other way.

Any connecting client got full access with no authentication, a choice aimed at frictionless local development.

It became a liability the moment an instance was bound to a public interface.

In December 2015, Chris Vickery, then an independent researcher, used Shodan-style internet scanning to find an unsecured MongoDB instance exposing emails, phone numbers and account data for over 13 million MacKeeper users.

Kromtech, which owned MacKeeper, secured the database rapidly once notified.

The same scanning found accessible, unauthenticated MongoDB databases across thousands of systems.

Then, a separate event two years later: in January 2017, criminal groups scanned for open MongoDB instances, wiped or exfiltrated their contents and left ransom notes.

More than 10,000 MongoDB databases were hit within weeks.

No exploit.

No stolen credential.

No injected payload.

A client pointed at a public address, an open port and no password.

The vendor has since reversed the default.

So the objection is half right: the product changed.

What did not change is the failure the product exposed.

The incidents that followed were not about document stores.

They were about reachability without authentication, and that failure works on any engine.

Exactis’s roughly 340-million-record exposure in June 2018 sat on a publicly accessible Elasticsearch server.

Cam4’s March 2020 exposure involved a production Elasticsearch cluster logging an estimated 10.88 billion rows, reachable with no password.

A database attributed to Shanghai’s police system, holding a claimed one billion records, turned up on an unsecured Elasticsearch instance in mid-2022.

Documented exposures in the last decade skew heavily toward cloud-hosted or internet-facing instances.

That is not because cloud infrastructure is weaker.

Elasticsearch and MongoDB can be run identically misconfigured on-premises.

It is because an on-premises database behind a corporate firewall is not reachable by internet-wide scanning unless somebody deliberately opens a path.

In a cloud account, standing up an internet-reachable instance is the path of least resistance.

Cloud lowers the friction of accidental reachability. It does not make misconfiguration more likely.

And a managed service does not decide reachability for you.

3. “But the Console Shows Encryption Enabled.”

Enabled on what?

Encryption configuration is in the customer column on a managed service.

The console reports the setting you, or a default, chose for the live instance.

That is one object.

Encryption applied to a live instance does not automatically apply to a snapshot exported to object storage.

A replica stood up for read scaling or disaster recovery can inherit the primary’s schema without inheriting its firewall rules or its row-level policies.

So a green tick on the primary answers a narrower question than the one being asked in the review.

It says this instance’s storage is encrypted.

It does not say which data classes live there, which copies exist elsewhere, or whether the encryption decision was made per classification at all.

Nor does encryption at rest decide who may query.

An engine that holds the keys it needs will decrypt pages for any connection it has already accepted.

If the instance answers the internet without a password, encrypted storage protects nothing in that path.

“Encryption enabled” is a setting on an object. It is not a statement about reachability, copies or access.

4. “But Encryption Would Slow the Database Down.”

This is the objection with a number behind it, so use the number properly.

Benchmarking of MySQL’s on-disk encryption found roughly 9% throughput overhead at low thread counts on a disk-bound workload.

At high concurrency, and on fully in-memory workloads, the overhead fell close to zero.

The low-concurrency case is exactly where a latency-sensitive transactional workload is most likely to show it.

So the DBA is not making it up.

The security team’s answer is not that the benchmark is wrong.

It is that the two costs have different shapes.

A throughput cost of that size is known, bounded and engineering-solvable: add compute headroom, confirm hardware AES support.

The cost of an exposed unencrypted database or backup has no comparable ceiling.

In practice the argument rarely resolves on the benchmark.

It resolves on who answers for a latency regression and who answers for a breach, and they are usually different people on different review cycles.

The workable middle is common: encryption on data classified as sensitive, off on ephemeral or already-anonymized tables.

Which moves the argument into classification.

And classification is, again, in your column on a managed service.

Anonymized test copies bring their own dispute.

Masking has to conceal identifying data and still keep keys joinable across tables.

Mask a customer ID one way here and another way there, and you get orphan records and failing tests.

Every one of those copies is another dataset somebody has to own.

Measure the workload you actually run. Decide per data class. Write the decision down.

“It might be slow” is a hypothesis.

It is not a classification.

5. “But the Snapshot Inherits the Primary’s Settings.”

This is where the managed-service story gets its sharpest test.

The shared-responsibility line for a managed service is clean on paper.

The provider secures the platform and operating system.

The customer is responsible for data classification, encryption configuration and access controls on top.

Backups and exports of your data sit on the customer side of that line.

Inside your organization, the line is not clean at all.

Backups are frequently owned by a different team than the live database: a storage or infrastructure group running scheduled snapshots and retention policies.

Sometimes nobody on the database side can see where a given backup landed once it left the primary instance.

Now watch the two reasonable assumptions.

The DBA configured the primary’s access controls and assumes they travel with any snapshot or replica derived from it.

The team that provisioned the storage bucket or export destination assumes access policy was the database team’s to specify, because they own the data, not the storage layer.

Neither assumption is negligent by its owner’s own lights.

Together they describe a copy with no owner.

The backup administrator’s goal is recoverability within a retention window and a recovery-time objective.

Not confidentiality.

That is not a character flaw.

It is what the job is measured on.

This gap between teams, not an exposed primary, is where exposed-backup incidents keep originating.

The dispute is rarely settled by a rule.

It is settled, or reopened, when an incident forces somebody to write the assignment down.

A RACI entry for “who configures access control on a database export” is often proposed after the fact.

It works better beforehand.

The provider will not write that line for you. It does not know your org chart.

6. “But Our Posture Tool Would Flag an Exposed Database.”

Possibly.

Then what?

CNAPP tools, and the CSPM tools folded into them, read configuration state through the provider’s own APIs and flag drift against policy.

That is visibility.

It is worth buying.

It is also what the money buys, and it is useful to be precise about that.

A December 2022 market analysis projected CNAPP spending to reach $19.3 billion by 2027, at a 19.9% compound annual growth rate.

Its named vendor set included Check Point, Trend Micro, Palo Alto Networks, CrowdStrike and Fortinet.

The category is a consolidation of what used to be separate products: CSPM, cloud workload protection and container security.

Containerized and microservices workloads widen the number of resources a tenant has to keep re-scanning.

So the cost of the category scales with the number of resources instrumented and the polling frequency.

Not with incidents prevented.

There is no shared industry fund that reimburses a tenant’s misconfiguration-remediation hours.

Each tenant buys its own watching, and pays its own fixing.

Even the providers treat the residual risk as real.

Google Cloud’s Risk Protection Program is a cyber-insurance collaboration with Munich Re and Allianz, offering tenants quantified risk data through a Cyber Insurance Hub.

An insurance market priced against tenant configuration risk is evidence that the risk does not net to zero once the subscription is paid.

A finding that says “database port open to the internet” is a sentence in a queue.

Whether it matters depends on whether the finding has an owner and a deadline.

A posture tool can tell you the door is open. Someone on your side still has to close it.

7. No, This Does Not Mean Managed Services Are No Safer.

They are safer against the failure they take on.

An unpatched engine with a known vulnerability is a real risk, and moving it to the provider is a real improvement.

Nor are cloud databases inherently less secure than on-premises ones.

The same engine can be misconfigured identically in either place.

The honest answer to “is RDS more secure than running my own Postgres?” is: against which failure?

Unpatched engine: the managed service wins.

Reachable without authentication: the managed service is not the variable.

Snapshot in an export destination with no named owner: the managed service is not the variable either.

Compliance does not collapse the distinction.

PCI DSS is a global card-network standard applying to anyone handling cardholder data.

HIPAA’s technical safeguards apply to US covered entities and business associates handling protected health information.

A PCI DSS Qualified Security Assessor, the certified role that produces a Report on Compliance, wants documented evidence that access controls, encryption and audit logging exist and were checked on a schedule.

“The service is managed” is not that evidence.

“Managed” names who patches the engine. It does not name who decides who can reach the data.

8. What You Should Actually Do

Write down the split, per database. For each instance, record which party owns engine patching, network reachability, encryption configuration, access policy and backup export destinations.

The provider’s published model covers its half.

Your record covers the rest, including the parts that fall between two internal teams.

Name an owner for access control on every snapshot and export. Not a team in general.

An owner.

If the DBA owns the primary and the infrastructure group owns the bucket, the record says which of them configures the export’s policy.

Scan your own address space and cloud accounts for database ports that answer without authentication.

Attackers and researchers use the same discovery method.

It is cheaper to be the first to look.

Decide encryption per data classification, using latency measured on the actual workload rather than a remembered benchmark.

If the answer is “off” for a table, record why, and which classification made that acceptable.

Give every posture-tool database finding an owner and a deadline. A finding with neither is a report, not a control.

Treat test and analytics copies as databases. A masked copy still needs an owner, a reachability decision and a place in the export record.

None of this is exotic.

It is the part of the work that “managed” is often used to avoid naming.

9. The Model Is Not Complicated.

The provider operates the infrastructure, the operating system and the database platform.

It patches the engine.

You decide who can reach the instance, what is encrypted, who may query, and where every copy goes and who owns it.

The documented exposures, from Exactis to Cam4 to the MongoDB ransom wave, sit in your half.

A managed service removes one failure class.

It leaves the configuration and ownership failures exactly where they were.

A managed service reallocates patching. It does not reallocate configuration.

Use the managed service.

Take the patching win.

Then close the port.

Name the snapshot’s owner.

And stop reading the word “managed” as if it meant “secured.”