Skip to main content
emnode
Compliance Medium severity

AWS Security Hub · RDS

RDS.45: Aurora MySQL audit logging is off

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub RDS.45 check?

RDS.45 checks whether an Aurora MySQL cluster has audit logging enabled in its cluster parameter group. Backed by the Config rule AURORA_MYSQL_CLUSTER_AUDIT_LOGGING, it reports FAILED if the parameter group associated with the cluster is not in sync, if server_audit_logging is not set to 1, or if server_audit_events is empty. The control evaluates only the parameter group, not the cluster's CloudWatch Logs export configuration.

Why does RDS.45 matter?

Aurora MySQL's built-in Advanced Auditing records connection events, queries, and schema changes with minimal overhead. Without it you have no record of who connected, what they ran, or which schema changed when: slow-query and error logs tell you nothing about a SELECT against the customers table at 3am from an unrecognised role. A breach investigation against a cluster with no audit log is guesswork, and most regulators (SOC 2, HIPAA, PCI DSS) treat "no log" as equivalent to "no control."

How do I fix RDS.45?

  1. Enable the Advanced Auditing plugin in the cluster parameter group (server_audit_logging=1) and choose a deliberate server_audit_events filter (CONNECT, QUERY_DDL, and QUERY_DCL rather than every statement) to keep ingestion low.
  2. Apply the parameter group to the cluster and confirm it is in sync: this is what clears RDS.45. To then surface the logs for analysis, publish them to CloudWatch Logs with modify-db-cluster --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}'.
  3. Set a retention policy on the resulting log group, archiving older logs to S3/Glacier for the multi-year windows HIPAA and SOX require.
  4. Verify the audit log group is receiving data.

Remediation script · bash

# Enable CloudWatch log export on a flagged RDS instance, then cap retention.
aws rds modify-db-instance \
  --db-instance-identifier prod-orders-pg \
  --cloudwatch-logs-export-configuration EnableLogTypes=postgresql,upgrade \
  --apply-immediately

aws logs put-retention-policy \
  --log-group-name /aws/rds/instance/prod-orders-pg/postgresql \
  --retention-in-days 90

# Enable audit logging on a Redshift cluster to a policy-attached S3 bucket.
aws redshift enable-logging \
  --cluster-identifier analytics-prod \
  --bucket-name redshift-audit-logs-acct123 \
  --s3-key-prefix analytics-prod/

Full walkthrough (console steps, edge cases and verification) in the lesson Enable database audit and log exports.

Is RDS.45 a false positive?

RDS.45 evaluates only the cluster parameter group, so a cluster can pass even if audit logs are not actually being exported to CloudWatch Logs: setting server_audit_logging=1 with a non-empty server_audit_events and a synced parameter group is enough to clear it. If you have edited the parameter group but the cluster still fails, it is usually because the change has not been applied or the cluster has not picked it up yet; confirm the parameter group is in sync (a reboot may be required) rather than assuming the finding is wrong.

Part of the learning path Tighten your databases
  • RDS.1 An RDS snapshot is shared publicly
  • RDS.2 An RDS instance is publicly accessible from the internet
  • RDS.3 RDS DB instances should be encrypted at rest
  • RDS.4 RDS snapshots should be encrypted at rest
  • RDS.5 RDS DB instances should use multiple AZs
  • RDS.6 RDS lacks enhanced monitoring
  • RDS.7 RDS clusters should have deletion protection
  • RDS.8 RDS DB instances should have deletion protection
  • RDS.9 RDS engine logs are not shipped to CloudWatch
  • RDS.10 RDS relies on long-lived database passwords
  • RDS.11 RDS instances should have automatic backups
  • RDS.12 IAM auth should be configured for RDS clusters