Cloud Database Misconfigurations: What Exposes Your RDS, Cloud SQL, and Cosmos DB to Attackers

Introduction

Cloud databases are not just another resource category in your cloud environment. They are the highest-value target in it. Customer records, financial transactions, health information, authentication credentials, regulated data of every description — it all ends up in a database. When a database is breached, the incident is almost always reportable, almost always material, and almost always traceable back to a misconfiguration that existed long before the attacker arrived.

What makes cloud database misconfigurations particularly dangerous is that managed database services — AWS RDS, Google Cloud SQL, Azure Cosmos DB — are designed to make databases easy to provision. Convenience and security are frequently in tension in those default settings, and the defaults tend to favor convenience. Audit logging is off by default in several managed services. Public accessibility is a checkbox that defaults to enabled in certain provisioning flows. Encryption at rest requires explicit selection of a customer-managed key rather than being enforced automatically. Backup retention is set to minimal windows that would not survive a SOC 2 audit without adjustment.

In 2025, a single publicly accessible RDS instance with a weak master password and no VPC restriction gives any attacker on the internet direct query access to every record it contains. No lateral movement required. No credential theft required. Just a network scan, a connection attempt, and a weak password guess or a credential stuffing attack against a default username.

This guide covers the most critical cloud database misconfigurations across AWS RDS, Google Cloud SQL, and Azure Cosmos DB — why they occur, how to detect them in your current environment, and which remediations have the highest combined impact on breach prevention and SOC 2 audit outcomes.

Why Managed Database Services Default to Misconfiguration

Before examining specific misconfigurations, it helps to understand the structural reason managed database services ship with settings that create security gaps. The answer is product design philosophy: managed databases are built to minimize time-to-first-query. The provisioning experience is optimized to get a developer connected and running queries as fast as possible, which means default settings that eliminate friction at the cost of security posture.

Public accessibility defaults to enabled in some provisioning flows because enabling it eliminates the need to configure VPC networking. Audit logging defaults to off because it adds storage cost and query overhead that developers do not want in early-stage usage. Minimal backup retention windows are set because longer retention requires the user to consciously decide to pay for it. Default database users often carry broad permissions because restricting them requires knowledge of the application's data access patterns that typically does not exist at provisioning time.

None of these defaults are wrong for a developer's local sandbox. All of them are wrong for a production database holding customer data. The problem is that the path from sandbox to production frequently does not include a security review of database configuration, and the defaults that were acceptable in development become the production configuration through deployment automation that was never updated.

This is the mechansim behind most cloud database breaches: not sophisticated attacks, but default configurations that were never hardened because the provisioning experience made them easy to miss.

AWS RDS: Critical Misconfigurations and Fixes

AWS RDS is the most widely deployed managed relational database service in the world, and it carries a well-documented set of misconfigurations that appear consistently in cloud security audits.

Public Accessibility

The PubliclyAccessible parameter on an RDS instance determines whether the instance is assigned a publicly routable DNS endpoint. When set to true, the database is reachable from any IP address on the internet — subject to security group rules, but security group rules are themselves frequently misconfigured to allow broad inbound access.

The correct configuration is PubliclyAccessible: false for every production database instance. Databases should be deployed in private subnets with no internet gateway route, and application connectivity should occur through private network paths within the same VPC or via VPC peering.

Audit your current RDS instances with:

aws rds describe-db-instances \
  --query 'DBInstances[?PubliclyAccessible==`true`].[DBInstanceIdentifier,DBInstanceClass,PubliclyAccessible]' \
  --output table

Any instance returned by this query requires immediate assessment. If the instance is in production, disable public accessibility and verify that application connectivity is maintained through private networking before closing the finding.

Encryption at Rest

RDS supports encryption at rest using AWS KMS. Encryption must be enabled at instance creation — it cannot be enabled on a running unencrypted instance without creating an encrypted snapshot and restoring to a new instance. This means encryption gaps discovered post-deployment carry a remediation path that requires downtime planning.

The correct configuration is encryption enabled on every RDS instance using a customer-managed KMS key (CMK) rather than the AWS-managed default key. CMKs give you control over key rotation policy, key access controls, and the ability to disable or delete the key as a data destruction mechanism.

Audit unencrypted instances:

aws rds describe-db-instances \
  --query 'DBInstances[?StorageEncrypted==`false`].[DBInstanceIdentifier,Engine,StorageEncrypted]' \
  --output table

For SOC 2, unencrypted production databases are a direct gap against the Confidentiality criteria (C1.1) and the Common Criteria around logical access and data protection. Auditors will ask for evidence of encryption configuration across all in-scope database instances.

Audit Logging Disabled

RDS audit logging configuration varies by database engine. For MySQL and MariaDB engines, the general_log and audit_log plugins must be enabled through parameter groups. For PostgreSQL, pgaudit must be configured. For Oracle and SQL Server, native auditing features require explicit configuration.

In all cases, the default RDS parameter group does not enable audit logging. A database provisioned with the default parameter group generates no query logs, no authentication logs, and no DDL change logs — meaning that if an attacker accesses the database, there is no record of what they queried, modified, or extracted.

For SOC 2, the absence of database audit logs is a gap against CC7.2 (monitoring of system components) and CC7.3 (evaluation of security events). Auditors will ask for evidence that database activity is logged and that logs are retained for the audit period.

Enable RDS audit logging by creating a custom parameter group for your engine with audit logging parameters enabled, associating the parameter group with your instance, and configuring log export to CloudWatch Logs for centralized retention and alerting.

Overpermissive Database Users

The RDS master user — the administrative credential created at instance provisioning — carries full database-level permissions including the ability to create and drop schemas, modify user permissions, and access all data. Applications should never connect to a production database using the master user.

Create application-specific database users with permissions scoped to exactly the schemas and operations the application requires. A read-heavy analytics service needs SELECT permissions on specific schemas. An application service needs SELECT, INSERT, UPDATE, and DELETE on specific tables. No application user needs CREATE, DROP, ALTER, or GRANT permissions unless schema migration is part of its function, and schema migration permissions should be held by a separate migration user that is only active during deployment windows.

Audit your database users and their permission grants as part of your quarterly access review process. Document the permissions held by each user, the application or team that uses them, and the business justification for each granted permission.

Automated Backups and Retention

RDS automated backups default to a one-day retention window. For SOC 2, one day of backup retention is insufficient — auditors evaluating availability controls under A1.3 expect backup retention sufficient to support your defined Recovery Point Objective, typically seven to thirty-five days for production databases.

Configure automated backup retention to a minimum of seven days for non-critical databases and thirty-five days (the RDS maximum) for databases holding customer data or regulated information. Enable point-in-time recovery so that the restoration target is not limited to daily snapshots.

Google Cloud SQL: Critical Misconfigurations and Fixes

Google Cloud SQL is GCP's managed relational database service, supporting PostgreSQL, MySQL, and SQL Server. It carries its own set of default settings that create security gaps in production environments.

Authorized Networks Without VPC-Only Connectivity

Cloud SQL instances can be configured to accept connections from specific IP ranges via the Authorized Networks setting, or they can be configured for private IP connectivity only through VPC peering. The Authorized Networks approach — allowing specific public IP addresses to connect — is fundamentally less secure than VPC-only connectivity because it exposes the database endpoint to the public internet and relies on IP allowlisting as the primary network control.

The correct configuration for production Cloud SQL instances is private IP connectivity with no Authorized Networks entries. Applications connect through Cloud SQL Auth Proxy or through private VPC connectivity, with no public IP assigned to the instance.

Audit instances with public IP addresses:

gcloud sql instances list \
  --format="table(name,databaseVersion,ipAddresses[0].ipAddress,settings.ipConfiguration.ipv4Enabled)"

Instances with ipv4Enabled: true have public IP addresses assigned and warrant review of their Authorized Networks configuration.

Data Encryption with Customer-Managed Keys

Cloud SQL encrypts data at rest by default using Google-managed encryption keys. This satisfies a baseline encryption requirement but does not give you control over key lifecycle, rotation schedule, or the ability to cryptographically destroy data by disabling the key.

For databases holding sensitive customer data, configure Cloud SQL to use Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS. CMEK gives you control over key rotation policy, audit logs of key usage via Cloud Audit Logs, and the ability to disable or destroy the key to render data unreadable — a capability that supports data disposal requirements under privacy regulations and SOC 2 Privacy criteria.

Cloud SQL Audit Logging

Cloud SQL does not enable data access audit logs by default. Admin Activity logs are enabled automatically, but Data Access logs — which record queries, authentication events, and data modifications — require explicit enablement in the GCP Audit Logs configuration.

Enable Data Access audit logs for Cloud SQL at the project or organization level:

gcloud projects get-iam-policy <PROJECT_ID> > policy.yaml
# Add DATA_READ and DATA_WRITE audit log configs for cloudsql.googleapis.com
gcloud projects set-iam-policy <PROJECT_ID> policy.yaml

Route Cloud SQL audit logs to Cloud Logging with a log sink to a centralized logging bucket for retention. Configure log retention to match your SOC 2 audit period — a minimum of twelve months for organizations undergoing annual Type 2 audits.

Database Flags for Security Hardening

Cloud SQL supports database flags that control security-relevant behavior. Several security-critical flags are not enabled by default:

For PostgreSQL instances, set log_connections and log_disconnections to on to record authentication events. Set log_min_duration_statement to capture slow queries that may indicate data exfiltration attempts. For MySQL instances, disable local_infile to prevent attackers from using LOAD DATA LOCAL INFILE to read server-side files. Enable require_secure_transport to enforce TLS on all client connections.

Audit your Cloud SQL flags configuration in the GCP Console under your instance's Configuration section, and compare against a security baseline appropriate for your database engine.

Azure Cosmos DB: Critical Misconfigurations and Fixes

Azure Cosmos DB is Microsoft's globally distributed NoSQL database service. Its architecture differs significantly from relational database services, and its misconfiguration patterns reflect that difference.

Public Network Access

Cosmos DB accounts are created with public network access enabled by default, meaning the account endpoint is accessible from any IP on the internet subject to authentication. While authentication is required — unlike some NoSQL services with historical anonymous access issues — a publicly accessible endpoint is a larger attack surface than a private one.

Disable public network access and configure private endpoints to route Cosmos DB traffic through your Azure Virtual Network:

az cosmosdb update \
  --name <ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --public-network-access Disabled

After disabling public access, configure Azure Private Endpoint to connect your application VNet to the Cosmos DB account through a private IP address. This ensures that Cosmos DB traffic never traverses the public internet.

Primary Key Exposure and Entra ID Authentication

Cosmos DB accounts have two primary keys and two secondary keys that grant full administrative access to all databases and containers in the account. These keys are frequently stored in application configuration files, environment variables, or Key Vault secrets with overly broad access policies — and a leaked key gives an attacker complete access to all data in the account.

Migrate to Azure Entra ID (formerly Azure Active Directory) role-based authentication for Cosmos DB access. Entra ID authentication eliminates the need for application code to handle long-lived account keys and enables fine-grained role assignments at the database and container level. Assign the Cosmos DB Built-in Data Reader or Cosmos DB Built-in Data Contributor role to application managed identities instead of granting access via account keys.

Audit whether your Cosmos DB accounts have local authentication (key-based) disabled:

az cosmosdb show \
  --name <ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --query "disableLocalAuth"

Accounts where disableLocalAuth is false are relying on key-based authentication and should be migrated to Entra ID.

Diagnostic Logging and Control Plane Auditing

Cosmos DB diagnostic logging is not enabled by default. Without it, there is no record of data plane operations — queries, inserts, deletes — or control plane operations — configuration changes, key regeneration, network rule modifications.

Enable diagnostic settings to send Cosmos DB logs to a Log Analytics workspace:

az monitor diagnostic-settings create \
  --name cosmosdb-diagnostics \
  --resource <COSMOS_DB_RESOURCE_ID> \
  --workspace <LOG_ANALYTICS_WORKSPACE_ID> \
  --logs '[{"category":"DataPlaneRequests","enabled":true},{"category":"ControlPlaneRequests","enabled":true},{"category":"QueryRuntimeStatistics","enabled":true}]'

For SOC 2, Cosmos DB diagnostic logs satisfy the monitoring evidence requirements under CC7.2. Auditors will request log exports demonstrating that database activity was captured throughout the observation period — logs that cannot be produced retroactively for periods where diagnostic settings were not configured.

Automated Backups and Restore Configuration

Cosmos DB offers two backup modes: periodic backup and continuous backup. Periodic backup — the default — takes backups every one to four hours and retains them for eight to thirty days. Continuous backup enables point-in-time restore to any moment within the last thirty days but must be explicitly selected at account creation.

For production accounts holding customer data, configure continuous backup mode with a thirty-day retention window. Verify that your restore procedures have been tested — Cosmos DB restore creates a new account rather than restoring in-place, which means your runbook for a database restore incident must account for DNS updates and application reconfiguration.

Auditing Your Database Posture Across Providers

A database posture audit examines every in-scope database instance against the misconfiguration categories described above. Run this audit before your SOC 2 observation period begins and at least quarterly thereafter.

For AWS RDS, use AWS Config rules to continuously monitor for public accessibility, encryption status, backup retention, and multi-AZ configuration. The managed Config rules rds-instance-public-access-check, rds-storage-encrypted, and rds-automatic-minor-version-upgrade-enabled cover the highest-impact checks. Combine Config findings with AWS Security Hub's FSBP (Foundational Security Best Practices) standard for a consolidated database security dashboard.

For Google Cloud SQL, use Security Command Center's built-in detectors for Cloud SQL misconfigurations — SQL_PUBLIC_IP, SQL_NO_ROOT_PASSWORD, and SQL_CONTAINED_DATABASE_AUTHENTICATION are the highest-priority findings. Supplement with Organization Policy constraints that enforce private IP requirements at the organization or folder level.

For Azure Cosmos DB, use Microsoft Defender for Cosmos DB within Microsoft Defender for Cloud. Enable the Azure Security Benchmark initiative in Azure Policy and review the Cosmos DB-specific controls within it. Defender for Cosmos DB provides threat detection for anomalous access patterns in addition to posture assessment.

Which Fixes Have the Highest Combined Impact

Not all database misconfigurations carry equal risk or equal audit weight. Prioritize remediation in this order based on combined breach prevention and SOC 2 impact:

Disable public accessibility first. A publicly accessible database with any authentication weakness is a direct path to a breach. Disabling public access eliminates the entire internet as a potential attack source and is the single highest-impact change you can make to database security posture. It directly satisfies CC6.6 (network security controls) in your SOC 2 evidence.

Enable encryption at rest second. Unencrypted databases are a gap against Confidentiality criteria and a question every enterprise security questionnaire will raise. For RDS, the remediation requires downtime planning. Do it before your observation period begins.

Enable audit logging third. The absence of database audit logs is invisible during normal operations and catastrophic during an incident or audit. Without logs, you cannot determine what an attacker accessed, you cannot demonstrate monitoring effectiveness to auditors, and you cannot support forensic investigation. Enable logging before anything else happens that you would need to explain.

Rotate and restrict database credentials fourth. Eliminate master user connections from application code, implement application-specific users with least-privilege permissions, and store credentials in a secrets manager rather than environment variables or configuration files.

Harden backup retention fifth. Increase backup retention to a minimum of seven days for all production databases and verify that restoration procedures work before you need them. Test a restore from backup at least annually and document the test as SOC 2 availability evidence.

Conclusion

Cloud database misconfigurations are not exotic vulnerabilities requiring sophisticated exploitation. They are default settings that ship with managed database services, persist through deployment automation that was never updated for production, and create direct paths to the data that makes a breach reportable and material.

The misconfigurations covered here — public accessibility, missing encryption, disabled audit logging, overpermissive credentials, and inadequate backup retention — appear consistently across AWS RDS, Google Cloud SQL, and Azure Cosmos DB because they reflect the same design tension in all three services: convenience at provisioning time versus security in production.

Remediating them requires deliberate action against default settings, automated detection to catch new instances provisioned without security review, and a quarterly audit cadence that keeps your database posture current as your environment grows. The SOC 2 evidence benefit is significant — each remediation directly satisfies criteria that auditors test — but the primary motivation is simpler: databases hold everything worth stealing, and the misconfigurations that expose them are well-documented, widely scanned for, and entirely preventable.

For a broader framework covering how database security fits within your overall cloud infrastructure security posture — alongside network controls, identity management, and continuous monitoring — read our guide on Cloud Infrastructure Security: Essential Best Practices for 2026.

This content was generated by AI.