Turning up Security on Database Services Part 1

• Managed database platforms (RDS, Aurora, DynamoDB, etc.) reduce operational burden compared with self-managed databases on EC2, but the AWS shared responsibility model still applies.
• AWS maintains the underlying platform and infrastructure; customers remain responsible for access control, configuration, data protection, and monitoring.
• Recurring customer security responsibilities include:
  • Controlling API and console access via IAM.
  • Centralized logs and audit trails (CloudWatch Logs, CloudTrail, AWS Config).
  • Network isolation and encryption controls where applicable.

​

IAM Database Authentication (RDS)

• Enable IAM DB authentication on the DB instance (during creation or by modifying the instance).
• Generate short-lived authentication tokens for IAM principals to use instead of static DB passwords.
• Create IAM policies that allow the rds-db:connect action for the specific DB user and attach these policies to IAM roles or users.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": "arn:aws:rds-db:`<region>`:`<account-id>`:dbuser:`<dbi-resource-id>`/db_user_name"
    }
  ]
}

​

Kerberos / Native Authentication Differences

• PostgreSQL: supports native DB authentication and can be configured for Kerberos (GSSAPI).
• SQL Server: supports Windows Authentication (Kerberos) when integrated with AWS Managed Microsoft AD.
• Oracle and SQL Server commonly rely on native DB credentials, Kerberos, or AD integration.

​

Secrets Management and Automatic Rotation

• Use AWS Secrets Manager when you need automatic credential rotation, built-in versioning, and easy retrieval via SDKs.
• Secrets Manager uses AWS KMS for server-side encryption of secret values and supports resource policies and cross-account access.
• If you require a central security team to manage DB credentials for applications in multiple accounts, use cross-account secrets or resource policies with least privilege.

​

RDS Networking and Placement

• Subnets and route tables control reachability.
• Security groups act as stateful firewalls (allow rules only).
• Network ACLs provide optional stateless filtering at the subnet boundary.
• When creating a DB instance, the Publicly Accessible option controls whether the DB gets a public IP. A DB in a public subnet without a public IP is not reachable from the internet.

​

Performance and Instance Types

​

IAM Roles and EC2 Applications

• Attach the minimum IAM permissions required to the EC2 instance role.
• Retrieve secrets at runtime from Secrets Manager or Parameter Store rather than hard-coding them.

​

Monitoring, Logging, and Detection

​

Database Logs

• Use the RDS console for quick ad-hoc access and troubleshooting.
• Export logs to S3 or CloudWatch Logs for long-term retention and integration with SIEM tools.
• Correlate logs with CloudTrail and application logs to build a comprehensive timeline during investigations.

​

Encryption in Transit

• Enable TLS/SSL on the DB engine (engine-specific setting).
• Configure clients to validate the server certificate chain using the RDS root CA.
• Optionally deploy mutual TLS where supported for stronger client authentication.

• Enable SSL/TLS and validate the DB server certificate on clients (standard approach).
• Use client-side encryption when true end-to-end encryption is needed (application encrypts data before sending to the DB), but note the added complexity.
• KMS and TDE address encryption at rest, not in transit.

​

SQL Example Snippet

WITH cte AS (
  SELECT id
  FROM authors
  LIMIT ?
)
UPDATE authors s
SET email = ?
FROM cte
WHERE s.id = cte.id;

SELECT count(*) FROM authors
WHERE id < (SELECT max(id) - ? FROM authors)
  AND id > (SELECT max(id) - ? FROM authors)
UNION
SELECT ...;

DELETE FROM authors
WHERE id < (SELECT max(id) - ? FROM authors)
  AND id > (SELECT max(id) - ? FROM authors);

​

Final checklist and recommendations

• Prefer IAM authentication where supported to avoid long-lived DB passwords.
• Use AWS Secrets Manager for secret storage and automatic rotation of DB credentials.
• Keep databases in private subnets and limit access with security groups, bastions, or proxies.
• Enable Enhanced Monitoring for OS-level diagnostics and Performance Insights for SQL-level diagnostics.
• Always enable TLS/SSL for data in transit and validate server certificates from clients.
• Avoid hard-coded credentials — use IAM roles and Secrets Manager.

• AWS RDS documentation: https://docs.aws.amazon.com/rds/
• AWS Secrets Manager: https://docs.aws.amazon.com/secretsmanager/
• AWS KMS: https://docs.aws.amazon.com/kms/
• Amazon VPC: https://docs.aws.amazon.com/vpc/
• CloudWatch metrics and logs: https://docs.aws.amazon.com/cloudwatch/