Securing Cloud Databases: From Default Configs to Defense in Depth

Cloud databases are targets because they're exposed and enterprises rush through deployment. Default configurations are nearly always wrong—public accessibility, minimal encryption, missing audit logging. Here's the defense-in-depth strategy that stops attackers from the network all the way to the data.

The Default Configuration Trap

Every major cloud provider—AWS, GCP, Azure—ships database services with defaults that prioritize ease of setup. Public accessibility flags, wide-open network rules, and disabled encryption at rest are common starting points. Your first job is to eliminate these.

For example, when provisioning an AWS RDS instance with Terraform, enforce private access and encryption from the start:

resource "aws_db_instance" "production" {
  engine               = "postgresql"
  instance_class       = "db.r6g.large"
  allocated_storage    = 100
  publicly_accessible  = false
  storage_encrypted    = true
  kms_key_id           = aws_kms_key.db_encryption.arn

  vpc_security_group_ids = [aws_security_group.db_private.id]
  db_subnet_group_name   = aws_db_subnet_group.private.name

  deletion_protection = true
}

Setting publicly_accessible = false and binding the instance to a private subnet group ensures the database never gets a public IP. This alone eliminates an entire class of attack.

Network Isolation: More Than Security Groups

Security groups are necessary but insufficient. A layered network strategy should include:

• Private subnets with no internet gateway route
• VPC endpoints for service-to-service communication that never traverses the public internet
• Network ACLs as a secondary stateless filter
• PrivateLink or VPC peering for cross-account access instead of exposing endpoints

Restrict your database security group to accept traffic only from your application layer's security group—never from a CIDR range unless absolutely necessary:

resource "aws_security_group_rule" "db_ingress" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.app_layer.id
  security_group_id        = aws_security_group.db_private.id
}

Authentication and Access Control

Passwords stored in environment variables or config files are a liability. Instead, use IAM-based database authentication where supported. On AWS RDS for PostgreSQL, you can generate short-lived authentication tokens:

export PGPASSWORD=$(aws rds generate-db-auth-token \
  --hostname mydb.cluster-abc123.us-east-1.rds.amazonaws.com \
  --port 5432 \
  --username app_readonly)

psql -h mydb.cluster-abc123.us-east-1.rds.amazonaws.com -U app_readonly -d myapp

This eliminates static credentials entirely. The token expires in 15 minutes, limiting the blast radius of any credential leak.

Beyond authentication, enforce the principle of least privilege at the database level. Create role-specific accounts—app_readonly, app_readwrite, migration_admin—instead of granting a single user full access.

Encryption: At Rest and In Transit

Encryption at rest (via KMS or provider-managed keys) protects against physical media theft and unauthorized snapshot access. Enforce SSL/TLS for connections in transit by setting parameter group values:

-- PostgreSQL: Verify SSL is enforced
ALTER SYSTEM SET ssl = on;
SELECT * FROM pg_stat_ssl;  -- Confirm active connections use SSL

On RDS, use the rds.force_ssl parameter to reject any unencrypted connection attempt.

Auditing and Monitoring

Security without visibility is guesswork. Enable database activity logging and ship those logs to a centralized system:

• AWS: Enable RDS Audit Logs and route to CloudWatch, then forward to your SIEM
• GCP: Use Cloud SQL Insights and Audit Logs
• Azure: Enable Azure SQL Auditing to Log Analytics

Set alerts for anomalous patterns: connections from new IP ranges, privilege escalation queries, or bulk data exports outside business hours.

The Bottom Line

Cloud database security isn't a single control—it's a stack. Network isolation keeps attackers out. IAM authentication eliminates static secrets. Encryption protects data at every stage. Monitoring catches what prevention misses.

Audit one production database this week against these controls. You'll almost certainly find a gap worth closing before an attacker does.

Have questions about securing cloud databases? I'm always happy to talk shop — reach out or connect with me on LinkedIn.