Database & datastore exposure
Managed databases and datastores are where structured, high-value data concentrates -- customer records, transactions, credentials, and PHI -- which makes their reachability the single exposure most worth getting right. This sub-topic looks specifically at the operational databases, caches, warehouses, and NoSQL stores your workloads depend on: relational engines like RDS and Aurora, Azure SQL, and Cloud SQL; in-memory caches like ElastiCache, Azure Cache for Redis, and Memorystore; and NoSQL and analytics stores like DynamoDB, Cosmos DB, and BigQuery. Exposure here is rarely a single toggle -- it is the combination of a network path in, an authentication layer that can be bypassed or brute-forced, and encryption that may or may not be enforced. We assess those three planes together, because a hardened password on a database that anyone can reach, or a private endpoint on a datastore with no authentication, each leaves the same door open. The goal is to confirm that every store is reachable only from the workloads that need it, authenticates every connection, and encrypts data in transit and at rest.
Overview
What this check looks like in practice
Managed databases and datastores are high-value targets, and they are dangerous when reachable from the internet or from over-broad internal networks. A public database endpoint, a cache with no authentication, or a warehouse open to every workload turns one credential or one misconfigured rule into direct access to structured data at scale. We assess network reachability, authentication, and encryption together, since a gap in any one undermines the others.
Why it matters
A database reachable from the internet collapses the distance between one leaked credential and a full data extraction: attackers run continuous internet-wide scans for open database and cache ports, and an unauthenticated Redis, Elasticsearch, or MongoDB instance tends to be found and compromised soon after it becomes reachable. Unlike a single application server, a datastore is the aggregation point -- one direct connection can dump every schema at once, and it can be done quietly over a legitimate database protocol that resembles normal traffic. Auditors and cyber-insurers treat public database endpoints and missing in-transit encryption as high-priority findings, because they map to explicit requirements in PCI-DSS, HIPAA, and the GLBA Safeguards Rule. The exposure is also easy to create by accident -- a "publicly accessible" flag left on at provisioning, an authorized-network range widened for a one-off migration, a cache spun up with authentication disabled for convenience -- and each of those defaults tends to survive long after the reason for it is forgotten.
What we assess
What we look for
- Managed databases (RDS/Aurora, Azure SQL, Cloud SQL, Redshift) with public endpoints or public IPs reachable from the internet, and database security groups, firewall rules, or authorized-network lists opened to broad CIDR ranges (0.0.0.0/0 or large corporate blocks) instead of the specific application subnets or workloads that actually connect
- In-memory and NoSQL stores -- Redis, Memcached, MongoDB, Elasticsearch/OpenSearch -- running with authentication disabled or with a default or weak credential, where the protocol offers no barrier once the port is reachable
- Encryption at rest not enabled, and in-transit TLS available but not enforced (rds.force_ssl or require_secure_transport off, Cosmos DB or Cloud SQL still allowing non-TLS connections)
- Static shared database passwords in use where IAM or managed-identity database authentication is available, and no rotation on the admin or master credential
- Overly permissive database-level roles and grants -- application accounts with owner or superuser rights, broad read across every schema, or public/anonymous roles left with default privileges
- Warehouse and NoSQL datasets shared too broadly at the data layer (BigQuery datasets granted to allAuthenticatedUsers or allUsers, DynamoDB resource-based policies, or Cosmos DB role and firewall scope, wider than the intended consumer)
- Database audit and access logging disabled, so connections and privileged queries against the store leave no reconstructable trail
- Backups, read replicas, and exports that reintroduce exposure -- a private primary fronted by a publicly accessible replica, or exports written to open object storage
Across your clouds
AWS, Azure & Google Cloud
AWS
RDS/Aurora and Redshift 'PubliclyAccessible' flag and subnet-group placement; security-group scope on database ports; IAM database authentication versus static passwords; rds.force_ssl / TLS enforcement and KMS encryption at rest; ElastiCache for Redis AUTH, RBAC, and in-transit and at-rest encryption; DynamoDB resource-based policies and VPC endpoints; RDS Proxy and PrivateLink for private access; and database audit logs delivered to CloudWatch.
Azure
Azure SQL Database and PostgreSQL/MySQL Flexible Server 'public network access' and firewall rules (including the 'Allow Azure services' toggle); Private Link and private endpoints versus public endpoints; Microsoft Entra ID authentication versus SQL logins; enforced TLS (minimum TLS version, require_secure_transport) and Transparent Data Encryption with customer-managed keys in Key Vault; Cosmos DB firewall, IP ranges, and disabling key-based auth; and Azure Cache for Redis non-TLS port and access-key posture.
Google Cloud
Cloud SQL public IP versus private IP, Authorized Networks, and 'require SSL/TLS' with SSL modes; Cloud SQL IAM database authentication and CMEK; Private Service Connect and Private Google Access for private reachability; Memorystore for Redis AUTH and in-transit encryption; BigQuery dataset-level IAM (watching for allUsers or allAuthenticatedUsers) and authorized views; and Firestore/Datastore access governed by IAM (with Firestore Security Rules for Native-mode client SDK access) and VPC Service Controls to bound datastore access.
Example finding
A production PostgreSQL instance marked publicly accessible with a firewall/authorized-network rule of 0.0.0.0/0 and TLS not enforced
Risk: The database is directly reachable from the entire internet and permits plaintext connections, so a single credential -- leaked, reused, or brute-forced against the exposed port -- yields a full, unencrypted dump of every schema, with the connection difficult to distinguish from legitimate traffic. This maps directly to PCI-DSS and HIPAA transmission and access requirements and is the kind of finding an insurer flags on sight.
Fix: Turn off public accessibility and move the instance behind private networking (a private IP with Private Service Connect, PrivateLink, or a private endpoint), replace the 0.0.0.0/0 rule with the specific application subnets, enforce TLS (require SSL / require_secure_transport) and confirm encryption at rest with a controlled key, then rotate the exposed credentials and move the application to IAM database authentication where available.
Remediation
How to close it
- 1 Inventory every managed database, cache, warehouse, and NoSQL store across all accounts, subscriptions, and projects, and flag each one that has a public endpoint, public IP, or 'publicly accessible' setting enabled.
- 2 Move databases onto private networking -- private endpoints, PrivateLink, or Private Service Connect -- and replace broad firewall and authorized-network ranges with the specific application subnets or workloads that actually connect.
- 3 Enable and require in-transit TLS and confirm encryption at rest with a controlled key on every store, rejecting plaintext connections rather than merely allowing encrypted ones.
- 4 Turn on authentication everywhere it can be disabled (Redis AUTH/RBAC, MongoDB and Elasticsearch auth), replace shared static passwords with IAM or managed-identity database authentication, and rotate any admin or master credential that was exposed.
- 5 Tighten database-level roles so application accounts hold least-privilege grants scoped to the schemas they use, and remove owner/superuser rights and default public or anonymous privileges.
- 6 Enable database audit and connection logging to a monitored, access-controlled destination, and extend the review to replicas, backups, and exports so a private primary is not undone by an exposed copy.
Questions
Isn't a database with a strong password safe even if it's publicly reachable?
A strong password reduces one risk but not the exposure itself. A public endpoint is continuously scanned and subject to brute force, credential-stuffing with reused passwords, and any future authentication bypass in the engine -- and if TLS isn't enforced, credentials and query results can be read in transit. The durable control is network isolation: a database that is unreachable from the internet is not exposed to any of those, regardless of the password.
Do you connect to or query our databases during the assessment?
No. The review is read-only and looks at configuration and access around each datastore -- public-accessibility flags, network and firewall rules, authentication mode, TLS enforcement, encryption settings, and role grants as recorded in the cloud provider. We do not open database connections, run queries, or read the data inside.
We use managed databases -- doesn't the cloud provider secure them for us?
The provider secures the underlying platform, but reachability, authentication mode, TLS enforcement, and database-level privileges are yours to configure, and several default to the more open option. Managed engines can still be provisioned with a public IP, a wide authorized-network range, a shared password, or a cache with authentication off. This sub-topic assesses those customer-controlled settings, which are exactly where auditable exposure lives.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
