Security Hub controls for Amazon RDS
These AWS Security Hub controls evaluate the Amazon Relational Database Service (Amazon RDS) service and resources.
These controls may not be available in all AWS Regions. For more information, see Availability of controls by Region.
[RDS.1] RDS snapshot should be private
Related requirements: PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v3.2.1/7.2.1, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)
Category: Protect > Secure network configuration
Severity: Critical
Resource type:
AWS::RDS::DBClusterSnapshot
, AWS::RDS::DBSnapshot
AWS Config rule:
rds-snapshots-public-prohibited
Schedule type: Change triggered
Parameters: None
This control checks whether Amazon RDS snapshots are public. The control fails if RDS snapshots are public. This control evaluates RDS instances, Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters.
RDS snapshots are used to back up the data on your RDS instances at a specific point in time. They can be used to restore previous states of RDS instances.
An RDS snapshot must not be public unless intended. If you share an unencrypted manual snapshot as public, this makes the snapshot available to all AWS accounts. This may result in unintended data exposure of your RDS instance.
Note that if the configuration is changed to allow public access, the AWS Config rule may not be able to detect the change for up to 12 hours. Until the AWS Config rule detects the change, the check passes even though the configuration violates the rule.
To learn more about sharing a DB snapshot, see Sharing a DB snapshot in the Amazon RDS User Guide.
Remediation
To remove public access from RDS snapshots, see Sharing a snapshot in the Amazon RDS User Guide. For DB snapshot visibility, we choose Private.
[RDS.2] RDS DB Instances should prohibit public access, as determined by the PubliclyAccessible configuration
Related requirements: CIS AWS Foundations Benchmark v3.0.0/2.3.3, PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v3.2.1/7.2.1, NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5)
Category: Protect > Secure network configuration
Severity: Critical
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-instance-public-access-check
Schedule type: Change triggered
Parameters: None
This control checks whether Amazon RDS instances are publicly accessible by evaluating the
PubliclyAccessible
field in the instance configuration item.
Neptune DB instances and Amazon DocumentDB clusters do not have the PubliclyAccessible
flag and cannot be evaluated. However, this control can still generate findings for these
resources. You can suppress these findings.
The PubliclyAccessible
value in the RDS instance configuration indicates
whether the DB instance is publicly accessible. When the DB instance is configured with
PubliclyAccessible
, it is an Internet-facing instance with a publicly resolvable
DNS name, which resolves to a public IP address. When the DB instance isn't publicly accessible,
it is an internal instance with a DNS name that resolves to a private IP address.
Unless you intend for your RDS instance to be publicly accessible, the RDS instance should
not be configured with PubliclyAccessible
value. Doing so might allow unnecessary
traffic to your database instance.
Remediation
To remove public access from RDS DB instances, see Modifying an Amazon RDS DB instance in the Amazon RDS User Guide. For Public access, choose No.
[RDS.3] RDS DB instances should have encryption at-rest enabled
Related requirements: CIS AWS Foundations Benchmark v3.0.0/2.3.1, CIS AWS Foundations Benchmark v1.4.0/2.3.1, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)
Category: Protect > Data Protection > Encryption of data-at-rest
Severity: Medium
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-storage-encrypted
Schedule type: Change triggered
Parameters: None
This control checks whether storage encryption is enabled for your Amazon RDS DB instances.
This control is intended for RDS DB instances. However, it can also generate findings for Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. If these findings are not useful, then you can suppress them.
For an added layer of security for your sensitive data in RDS DB instances, you should configure your RDS DB instances to be encrypted at rest. To encrypt your RDS DB instances and snapshots at rest, enable the encryption option for your RDS DB instances. Data that is encrypted at rest includes the underlying storage for DB instances, its automated backups, read replicas, and snapshots.
RDS encrypted DB instances use the open standard AES-256 encryption algorithm to encrypt your data on the server that hosts your RDS DB instances. After your data is encrypted, Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance. You do not need to modify your database client applications to use encryption.
Amazon RDS encryption is currently available for all database engines and storage types. Amazon RDS encryption is available for most DB instance classes. To learn about DB instance classes that do not support Amazon RDS encryption, see Encrypting Amazon RDS resources in the Amazon RDS User Guide.
Remediation
For information about encrypting DB instances in Amazon RDS, see Encrypting Amazon RDS resources in the Amazon RDS User Guide.
[RDS.4] RDS cluster snapshots and database snapshots should be encrypted at rest
Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)
Category: Protect > Data Protection > Encryption of data-at-rest
Severity: Medium
Resource type:
AWS::RDS::DBClusterSnapshot
, AWS::RDS::DBSnapshot
AWS Config rule:
rds-snapshot-encrypted
Schedule type: Change triggered
Parameters: None
This control checks whether an RDS DB snapshot is encrypted. The control fails if an RDS DB snapshot isn't encrypted.
This control is intended for RDS DB instances. However, it can also generate findings for snapshots of Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. If these findings are not useful, then you can suppress them.
Encrypting data at rest reduces the risk that an unauthenticated user gets access to data that is stored on disk. Data in RDS snapshots should be encrypted at rest for an added layer of security.
Remediation
To encrypt an RDS snapshot, see Encrypting Amazon RDS resources in the Amazon RDS User Guide. When you encrypt an RDS DB instance, the encrypted data includes the underlying storage for the instance, its automated backups, read replicas, and snapshots.
You can only encrypt an RDS DB instance when you create it, not after the DB instance is created. However, because you can encrypt a copy of an unencrypted snapshot, you can effectively add encryption to an unencrypted DB instance. That is, you can create a snapshot of your DB instance, and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance.
[RDS.5] RDS DB instances should be configured with multiple Availability Zones
Related requirements: NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)
Category: Recover > Resilience > High availability
Severity: Medium
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-multi-az-support
Schedule type: Change triggered
Parameters: None
This control checks whether high availability is enabled for your RDS DB instances. The control fails if an RDS DB instance isn't configured with multiple Availability Zones (AZs).
Configuring Amazon RDS DB instances with AZs helps ensure the availability of stored data. Multi-AZ deployments allow for automated failover if there is an issue with AZ availability and during regular RDS maintenance.
Remediation
To deploy your DB instances in multiple AZs, Modifying a DB instance to be a Multi-AZ DB instance deployment in the Amazon RDS User Guide.
[RDS.6] Enhanced monitoring should be configured for RDS DB instances
Related requirements: NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2
Category: Detect > Detection services
Severity: Low
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-enhanced-monitoring-enabled
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
|
Number of seconds between monitoring metric collection intervals |
Enum |
|
No default value |
This control checks whether enhanced monitoring is enabled for an Amazon Relational Database Service (Amazon RDS) DB
instance. The control fails if enhanced monitoring isn't enabled for the instance. If you provide a custom value for the
monitoringInterval
parameter, the control passes only if enhanced monitoring metrics are collected for the instance
at the specified interval.
In Amazon RDS, Enhanced Monitoring enables a more rapid response to performance changes in underlying infrastructure. These performance changes could result in a lack of availability of the data. Enhanced Monitoring provides real-time metrics of the operating system that your RDS DB instance runs on. An agent is installed on the instance. The agent can obtain metrics more accurately than is possible from the hypervisor layer.
Enhanced Monitoring metrics are useful when you want to see how different processes or threads on a DB instance use the CPU. For more information, see Enhanced Monitoring in the Amazon RDS User Guide.
Remediation
For detailed instructions on enabling Enhanced Monitoring for your DB instance, see Setting up for and enabling Enhanced Monitoring in the Amazon RDS User Guide.
[RDS.7] RDS clusters should have deletion protection enabled
Related requirements: NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)
Category: Protect > Data protection > Data deletion protection
Severity: Low
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
rds-cluster-deletion-protection-enabled
Schedule type: Change triggered
Parameters: None
This control checks whether an RDS DB cluster has deletion protection enabled. The control fails if an RDS DB cluster doesn't have deletion protection enabled.
This control is intended for RDS DB instances. However, it can also generate findings for Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. If these findings are not useful, then you can suppress them.
Enabling cluster deletion protection is an additional layer of protection against accidental database deletion or deletion by an unauthorized entity.
When deletion protection is enabled, an RDS cluster cannot be deleted. Before a deletion request can succeed, deletion protection must be disabled.
Remediation
To enable deletion protection for an RDS DB cluster, see Modifying the DB cluster by using the console, CLI, and API in the Amazon RDS User Guide. For Deletion protection, choose Enable deletion protection.
[RDS.8] RDS DB instances should have deletion protection enabled
Related requirements: NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)
Category: Protect > Data protection > Data deletion protection
Severity: Low
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-instance-deletion-protection-enabled
Schedule type: Change triggered
Parameters:
-
databaseEngines
:mariadb,mysql,custom-oracle-ee,oracle-ee-cdb,oracle-se2-cdb,oracle-ee,oracle-se2,oracle-se1,oracle-se,postgres,sqlserver-ee,sqlserver-se,sqlserver-ex,sqlserver-web
(not customizable)
This control checks whether your RDS DB instances that use one of the listed database engines have deletion protection enabled. The control fails if an RDS DB instance doesn't have deletion protection enabled.
Enabling instance deletion protection is an additional layer of protection against accidental database deletion or deletion by an unauthorized entity.
While deletion protection is enabled, an RDS DB instance cannot be deleted. Before a deletion request can succeed, deletion protection must be disabled.
Remediation
To enable deletion protection for an RDS DB instance, see Modifying an Amazon RDS DB instance in the Amazon RDS User Guide. For Deletion protection, choose Enable deletion protection.
[RDS.9] RDS DB instances should publish logs to CloudWatch Logs
Related requirements: NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)
Category: Identify > Logging
Severity: Medium
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-logging-enabled
Schedule type: Change triggered
Parameters: None
This control checks whether an Amazon RDS DB instance is configured to publish the following logs to Amazon CloudWatch Logs. The control fails if the instance isn’t configured to publish the following logs to CloudWatch Logs:
-
Oracle: (Alert, Audit, Trace, Listener)
-
PostgreSQL: (Postgresql, Upgrade)
-
MySQL: (Audit, Error, General, SlowQuery)
-
MariaDB: (Audit, Error, General, SlowQuery)
-
SQL Server: (Error, Agent)
-
Aurora: (Audit, Error, General, SlowQuery)
-
Aurora-MySQL: (Audit, Error, General, SlowQuery)
-
Aurora-PostgreSQL: (Postgresql, Upgrade).
RDS databases should have relevant logs enabled. Database logging provides detailed records of requests made to RDS. Database logs can assist with security and access audits and can help to diagnose availability issues.
Remediation
To publish RDS database logs to CloudWatch Logs, see Specifying the logs to publish to CloudWatch Logs in the Amazon RDS User Guide.
[RDS.10] IAM authentication should be configured for RDS instances
Related requirements: NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6
Category: Protect > Secure access management > Passwordless authentication
Severity: Medium
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-instance-iam-authentication-enabled
Schedule type: Change triggered
Parameters: None
This control checks whether an RDS DB instance has IAM database authentication
enabled. The control fails if IAM authentication is not configured for RDS DB instances.
This control only evaluates RDS instances with the following engine types: mysql
,
postgres
, aurora
, aurora-mysql
, aurora-postgresql
, and mariadb
.
An RDS instance must also be in one of the following states for a finding to be generated:
available
, backing-up
, storage-optimization
, or storage-full
.
IAM database authentication allows authentication to database instances with an authentication token instead of a password. Network traffic to and from the database is encrypted using SSL. For more information, see IAM database authentication in the Amazon Aurora User Guide.
Remediation
To activate IAM database authentication on an RDS DB instance, see Enabling and disabling IAM database authentication in the Amazon RDS User Guide.
[RDS.11] RDS instances should have automatic backups enabled
Related requirements: NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)
Category: Recover > Resilience > Backups enabled
Severity: Medium
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
db-instance-backup-enabled
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
|
Minimum backup retention period in days |
Integer |
|
|
|
Checks whether RDS DB instances have backups enabled for read replicas |
Boolean |
Not customizable |
|
This control checks whether an Amazon Relational Database Service instance has automated backups enabled, and a backup retention period greater than or equal to the specified time frame. Read replicas are excluded from evaluation. The control fails if backups aren't enabled for the instance, or if the retention period is less than the specified time frame. Unless you provide a custom parameter value for the backup retention period, Security Hub uses a default value of 7 days.
Backups help you more quickly recover from a security incident and strengthens the resilience of your systems. Amazon RDS lets you configure daily full instance volume snapshots. For more information about Amazon RDS automated backups, see Working with Backups in the Amazon RDS User Guide.
Remediation
To enable automated backups on an RDS DB instance, see Enabling automated backups in the Amazon RDS User Guide.
[RDS.12] IAM authentication should be configured for RDS clusters
Related requirements: NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6
Category: Protect > Secure access management > Passwordless authentication
Severity: Medium
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
rds-cluster-iam-authentication-enabled
Schedule type: Change triggered
Parameters: None
This control checks whether an Amazon RDS DB cluster has IAM database authentication enabled.
IAM database authentication allows for password-free authentication to database instances. The authentication uses an authentication token. Network traffic to and from the database is encrypted using SSL. For more information, see IAM database authentication in the Amazon Aurora User Guide.
Remediation
To enable IAM authentication for a DB cluster, see Enabling and disabling IAM database authentication in the Amazon Aurora User Guide.
[RDS.13] RDS automatic minor version upgrades should be enabled
Related requirements: CIS AWS Foundations Benchmark v3.0.0/2.3.2, NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5)
Category: Identify > Vulnerability, patch, and version management
Severity: High
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-automatic-minor-version-upgrade-enabled
Schedule type: Change triggered
Parameters: None
This control checks whether automatic minor version upgrades are enabled for the RDS database instance.
Enabling automatic minor version upgrades ensures that the latest minor version updates to the relational database management system (RDBMS) are installed. These upgrades might include security patches and bug fixes. Keeping up to date with patch installation is an important step in securing systems.
Remediation
To enable automatic minor version upgrades for an existing DB instance, see Modifying an Amazon RDS DB instance in the Amazon RDS User Guide. For Auto minor version upgrade, select Yes.
[RDS.14] Amazon Aurora clusters should have backtracking enabled
Related requirements: NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SI-13(5)
Category: Recover > Resilience > Backups enabled
Severity: Medium
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
aurora-mysql-backtracking-enabled
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
|
Number of hours to backtrack an Aurora MySQL cluster |
Double |
|
No default value |
This control checks whether an Amazon Aurora cluster has backtracking enabled. The control fails if the cluster doesn't
have backtracking enabled. If you provide a custom value for the BacktrackWindowInHours
parameter, the control passes
only if the cluster is backtracked for the specified length of time.
Backups help you to recover more quickly from a security incident. They also strengthens the resilience of your systems. Aurora backtracking reduces the time to recover a database to a point in time. It does not require a database restore to do so.
Remediation
To enable Aurora backtracking, see Configuring backtracking in the Amazon Aurora User Guide.
Note that you cannot enable backtracking on an existing cluster. Instead, you can create a clone that has backtracking enabled. For more information about the limitations of Aurora backtracking, see the list of limitations in Overview of backtracking.
[RDS.15] RDS DB clusters should be configured for multiple Availability Zones
Related requirements: NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)
Category: Recover > Resilience > High availability
Severity: Medium
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
rds-cluster-multi-az-enabled
Schedule type: Change triggered
Parameters: None
This control checks whether high availability is enabled for your RDS DB clusters. The control fails if an RDS DB cluster isn't deployed in multiple Availability Zones (AZs).
RDS DB clusters should be configured for multiple AZs to ensure availability of stored data. Deployment to multiple AZs allows for automated failover in the event of an AZ availability issue and during regular RDS maintenance events.
Remediation
To deploy your DB clusters in multiple AZs, Modifying a DB instance to be a Multi-AZ DB instance deployment in the Amazon RDS User Guide.
Remediation steps differ for Aurora global databases. To configure multiple Availability Zones for an Aurora global database, select your DB cluster. Then, choose Actions and Add reader, and specify multiple AZs. For more information, see Adding Aurora Replicas to a DB cluster in the Amazon Aurora User Guide.
[RDS.16] RDS DB clusters should be configured to copy tags to snapshots
Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)
Category: Identify > Inventory
Severity: Low
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
rds-cluster-copy-tags-to-snapshots-enabled
(custom Security Hub rule)
Schedule type: Change triggered
Parameters: None
This control checks whether RDS DB clusters are configured to copy all tags to snapshots when the snapshots are created.
Identification and inventory of your IT assets is a crucial aspect of governance and security. You need to have visibility of all your RDS DB clusters so that you can assess their security posture and take action on potential areas of weakness. Snapshots should be tagged in the same way as their parent RDS database clusters. Enabling this setting ensures that snapshots inherit the tags of their parent database clusters.
Remediation
To automatically copy tags to snapshots for an RDS DB cluster, see Modifying the DB cluster by using the console, CLI, and API in the Amazon Aurora User Guide. Select Copy tags to snapshots.
[RDS.17] RDS DB instances should be configured to copy tags to snapshots
Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)
Category: Identify > Inventory
Severity: Low
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-instance-copy-tags-to-snapshots-enabled
(custom Security Hub rule)
Schedule type: Change triggered
Parameters: None
This control checks whether RDS DB instances are configured to copy all tags to snapshots when the snapshots are created.
Identification and inventory of your IT assets is a crucial aspect of governance and security. You need to have visibility of all your RDS DB instances so that you can assess their security posture and take action on potential areas of weakness. Snapshots should be tagged in the same way as their parent RDS database instances. Enabling this setting ensures that snapshots inherit the tags of their parent database instances.
Remediation
To automatically copy tags to snapshots for an RDS DB instance, see Modifying an Amazon RDS DB instance in the Amazon RDS User Guide. Select Copy tags to snapshots.
[RDS.18] RDS instances should be deployed in a VPC
Related requirements: NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)
Category: Protect > Secure network configuration > Resources within VPC
Severity: High
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-deployed-in-vpc
(custom Security Hub rule)
Schedule type: Change triggered
Parameters: None
This control checks whether an Amazon RDS instance is deployed on an EC2-VPC.
VPCs provide a number of network controls to secure access to RDS resources. These controls include VPC Endpoints, network ACLs, and security groups. To take advantage of these controls, we recommend that you create your RDS instances on an EC2-VPC.
Remediation
For instructions on moving RDS instances to a VPC, see Updating the VPC for a DB instance in the Amazon RDS User Guide.
[RDS.19] Existing RDS event notification subscriptions should be configured for critical cluster events
Related requirements: NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2
Category: Detect > Detection services > Application monitoring
Severity: Low
Resource type:
AWS::RDS::EventSubscription
AWS Config rule:
rds-cluster-event-notifications-configured
(custom Security Hub rule)
Schedule type: Change triggered
Parameters: None
This control checks whether an existing Amazon RDS event subscription for database clusters has notifications enabled for the following source type and event category key-value pairs:
DBCluster: ["maintenance","failure"]
The control passes if there are no existing event subscriptions in your account.
RDS event notifications uses Amazon SNS to make you aware of changes in the availability or configuration of your RDS resources. These notifications allow for rapid response. For additional information about RDS event notifications, see Using Amazon RDS event notification in the Amazon RDS User Guide.
Remediation
To subscribe to RDS cluster event notifications, see Subscribing to Amazon RDS event notification in the Amazon RDS User Guide. Use the following values:
Field | Value |
---|---|
Source type |
Clusters |
Clusters to include |
All clusters |
Event categories to include |
Select specific event categories or All event categories |
[RDS.20] Existing RDS event notification subscriptions should be configured for critical database instance events
Related requirements: NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2
Category: Detect > Detection services > Application monitoring
Severity: Low
Resource type:
AWS::RDS::EventSubscription
AWS Config rule:
rds-instance-event-notifications-configured
(custom Security Hub rule)
Schedule type: Change triggered
Parameters: None
This control checks whether an existing Amazon RDS event subscription for database instances has notifications enabled for the following source type and event category key-value pairs:
DBInstance: ["maintenance","configuration change","failure"]
The control passes if there are no existing event subscriptions in your account.
RDS event notifications use Amazon SNS to make you aware of changes in the availability or configuration of your RDS resources. These notifications allow for rapid response. For additional information about RDS event notifications, see Using Amazon RDS event notification in the Amazon RDS User Guide.
Remediation
To subscribe to RDS instance event notifications, see Subscribing to Amazon RDS event notification in the Amazon RDS User Guide. Use the following values:
Field | Value |
---|---|
Source type |
Instances |
Instances to include |
All instances |
Event categories to include |
Select specific event categories or All event categories |
[RDS.21] An RDS event notifications subscription should be configured for critical database parameter group events
Related requirements: NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2
Category: Detect > Detection services > Application monitoring
Severity: Low
Resource type:
AWS::RDS::EventSubscription
AWS Config rule:
rds-pg-event-notifications-configured
(custom Security Hub rule)
Schedule type: Change triggered
Parameters: None
This control checks whether an Amazon RDS event subscription exists with notifications enabled for the following source type, event category key-value pairs. The control passes if there are no existing event subscriptions in your account.
DBParameterGroup: ["configuration change"]
RDS event notifications use Amazon SNS to make you aware of changes in the availability or configuration of your RDS resources. These notifications allow for rapid response. For additional information about RDS event notifications, see Using Amazon RDS event notification in the Amazon RDS User Guide.
Remediation
To subscribe to RDS database parameter group event notifications, see Subscribing to Amazon RDS event notification in the Amazon RDS User Guide. Use the following values:
Field | Value |
---|---|
Source type |
Parameter groups |
Parameter groups to include |
All parameter groups |
Event categories to include |
Select specific event categories or All event categories |
[RDS.22] An RDS event notifications subscription should be configured for critical database security group events
Related requirements: NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2
Category: Detect > Detection Services > Application monitoring
Severity: Low
Resource type:
AWS::RDS::EventSubscription
AWS Config rule:
rds-sg-event-notifications-configured
(custom Security Hub rule)
Schedule type: Change triggered
Parameters: None
This control checks whether an Amazon RDS event subscription exists with notifications enabled for the following source type, event category key-value pairs. The control passes if there are no existing event subscriptions in your account.
DBSecurityGroup: ["configuration change","failure"]
RDS event notifications use Amazon SNS to make you aware of changes in the availability or configuration of your RDS resources. These notifications allow for a rapid response. For additional information about RDS event notifications, see Using Amazon RDS event notification in the Amazon RDS User Guide.
Remediation
To subscribe to RDS instance event notifications, see Subscribing to Amazon RDS event notification in the Amazon RDS User Guide. Use the following values:
Field | Value |
---|---|
Source type |
Security groups |
Security groups to include |
All security groups |
Event categories to include |
Select specific event categories or All event categories |
[RDS.23] RDS instances should not use a database engine default port
Related requirements: NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5)
Category: Protect > Secure network configuration
Severity: Low
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-no-default-ports
(custom Security Hub rule)
Schedule type: Change triggered
Parameters: None
This control checks whether an RDS cluster or instance uses a port other than the default port of the database engine. The control fails if the RDS cluster or instance uses the default port.
If you use a known port to deploy an RDS cluster or instance, an attacker can guess information about the cluster or instance. The attacker can use this information in conjunction with other information to connect to an RDS cluster or instance or gain additional information about your application.
When you change the port, you must also update the existing connection strings that were used to connect to the old port. You should also check the security group of the DB instance to ensure that it includes an ingress rule that allows connectivity on the new port.
Remediation
To modify the default port of an existing RDS DB instance, see Modifying an Amazon RDS DB instance in the Amazon RDS User Guide. To modify the default port of an existing RDS DB cluster, see Modifying the DB cluster by using the console, CLI, and API in the Amazon Aurora User Guide. For Database port, change the port value to a non-default value.
[RDS.24] RDS Database clusters should use a custom administrator username
Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2
Category: Identify > Resource Configuration
Severity: Medium
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
rds-cluster-default-admin-check
Schedule type: Change triggered
Parameters: None
This control checks whether an Amazon RDS database cluster has changed the admin username from its default value. The control does not apply to engines of the type neptune (Neptune DB) or docdb (DocumentDB). This rule will fail if the admin username is set to the default value.
When creating an Amazon RDS database, you should change the default admin username to a unique value. Default usernames are public knowledge and should be changed during RDS database creation. Changing the default usernames reduces the risk of unintended access.
Remediation
For changing the admin username associated with the Amazon RDS database cluster, create a new RDS database cluster and change the default admin username while creating the database.
[RDS.25] RDS database instances should use a custom administrator username
Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2
Category: Identify > Resource Configuration
Severity: Medium
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-instance-default-admin-check
Schedule type: Change triggered
Parameters: None
This control checks whether you've changed the administrative username for Amazon Relational Database Service (Amazon RDS) database instances from the default value. The control does not apply to engines of the type neptune (Neptune DB) or docdb (DocumentDB). The control fails if the administrative username is set to the default value.
Default administrative usernames on Amazon RDS databases are public knowledge. When creating an Amazon RDS database, you should change the default administrative username to a unique value to reduce the risk of unintended access.
Remediation
To change the administrative username associated with an RDS database instance, first create a new RDS database instance. Change the default administrative username while creating the database.
[RDS.26] RDS DB instances should be protected by a backup plan
Category: Recover > Resilience > Backups enabled
Related requirements: NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)
Severity: Medium
Resource type:
AWS::RDS::DBInstance
AWS Config rule:
rds-resources-protected-by-backup-plan
Schedule type: Periodic
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
|
The control produces a |
Boolean |
|
No default value |
This control evaluates if Amazon RDS DB instances are covered by a backup plan. This control fails if the RDS DB instance isn't
covered by a backup plan. If you set the backupVaultLockCheck
parameter equal to true
, the control passes only if the instance is backed up in an AWS Backup locked vault.
AWS Backup is a fully managed backup service that centralizes and automates the backing up of data across AWS services. With AWS Backup, you can create backup policies called backup plans. You can use these plans to define your backup requirements, such as how frequently to back up your data and how long to retain those backups. Including RDS DB instances in a backup plan helps you protect your data from unintended loss or deletion.
Remediation
To add an RDS DB instance to an AWS Backup backup plan, see Assigning resources to a backup plan in the AWS Backup Developer Guide.
[RDS.27] RDS DB clusters should be encrypted at rest
Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)
Category: Protect > Data Protection > Encryption of data-at-rest
Severity: Medium
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
rds-cluster-encrypted-at-rest
Schedule type: Change triggered
Parameters: None
This control checks if an RDS DB cluster is encrypted at rest. The control fails if an RDS DB cluster isn't encrypted at rest.
Data at rest refers to any data that's stored in persistent, non-volatile storage for any duration. Encryption helps you protect the confidentiality of such data, reducing the risk that an unauthorized user can access it. Encrypting your RDS DB clusters protects your data and metadata against unauthorized access. It also fulfills compliance requirements for data-at-rest encryption of production file systems.
Remediation
You can enable encryption at rest when you create an RDS DB cluster. You can't change encryption settings after creating a cluster. For more information, see Encrypting an Amazon Aurora DB cluster in the Amazon Aurora User Guide.
[RDS.28] RDS DB clusters should be tagged
Category: Identify > Inventory > Tagging
Severity: Low
Resource type:
AWS::RDS::DBCluster
AWS Config rule:tagged-rds-dbcluster
(custom Security Hub rule)
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
requiredTagKeys
|
List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. | StringList | List of tags that meet AWS requirements | No default value |
This control checks whether an Amazon RDS DB cluster has tags with the specific keys defined in the parameter
requiredTagKeys
. The control fails if the DB cluster doesn’t have any tag keys or if it doesn’t have all the keys specified in the
parameter requiredTagKeys
. If the parameter requiredTagKeys
isn't provided, the control only checks for the existence
of a tag key and fails if the DB cluster isn't tagged with any key. System tags, which are automatically applied and begin with aws:
,
are ignored.
A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.
Note
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.
Remediation
To add tags to an RDS DB cluster, see Tagging Amazon RDS resources in the Amazon RDS User Guide.
[RDS.29] RDS DB cluster snapshots should be tagged
Category: Identify > Inventory > Tagging
Severity: Low
Resource type:
AWS::RDS::DBClusterSnapshot
AWS Config rule:tagged-rds-dbclustersnapshot
(custom Security Hub rule)
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
requiredTagKeys
|
List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. | StringList | List of tags that meet AWS requirements | No default value |
This control checks whether an Amazon RDS DB cluster snapshot has tags with the specific keys defined in the parameter
requiredTagKeys
. The control fails if the DB cluster snapshot doesn’t have any tag keys or if it doesn’t have all the keys specified in the
parameter requiredTagKeys
. If the parameter requiredTagKeys
isn't provided, the control only checks for the existence
of a tag key and fails if the DB cluster snapshot isn't tagged with any key. System tags, which are automatically applied and begin with aws:
,
are ignored.
A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.
Note
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.
Remediation
To add tags to an RDS DB cluster snapshot, see Tagging Amazon RDS resources in the Amazon RDS User Guide.
[RDS.30] RDS DB instances should be tagged
Category: Identify > Inventory > Tagging
Severity: Low
Resource type:
AWS::RDS::DBInstance
AWS Config rule:tagged-rds-dbinstance
(custom Security Hub rule)
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
requiredTagKeys
|
List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. | StringList | List of tags that meet AWS requirements | No default value |
This control checks whether an Amazon RDS DB instance has tags with the specific keys defined in the parameter
requiredTagKeys
. The control fails if the DB instance doesn’t have any tag keys or if it doesn’t have all the keys specified in the
parameter requiredTagKeys
. If the parameter requiredTagKeys
isn't provided, the control only checks for the existence
of a tag key and fails if the DB instance isn't tagged with any key. System tags, which are automatically applied and begin with aws:
,
are ignored.
A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.
Note
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.
Remediation
To add tags to an RDS DB instance, see Tagging Amazon RDS resources in the Amazon RDS User Guide.
[RDS.31] RDS DB security groups should be tagged
Category: Identify > Inventory > Tagging
Severity: Low
Resource type:
AWS::RDS::DBSecurityGroup
AWS Config rule:tagged-rds-dbsecuritygroup
(custom Security Hub rule)
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
requiredTagKeys
|
List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. | StringList | List of tags that meet AWS requirements | No default value |
This control checks whether an Amazon RDS DB security group has tags with the specific keys defined in the parameter
requiredTagKeys
. The control fails if the DB security group doesn’t have any tag keys or if it doesn’t have all the keys specified in the
parameter requiredTagKeys
. If the parameter requiredTagKeys
isn't provided, the control only checks for the existence
of a tag key and fails if the DB security group isn't tagged with any key. System tags, which are automatically applied and begin with aws:
,
are ignored.
A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.
Note
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.
Remediation
To add tags to an RDS DB security group, see Tagging Amazon RDS resources in the Amazon RDS User Guide.
[RDS.32] RDS DB snapshots should be tagged
Category: Identify > Inventory > Tagging
Severity: Low
Resource type:
AWS::RDS::DBSnapshot
AWS Config rule:tagged-rds-dbsnapshot
(custom Security Hub rule)
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
requiredTagKeys
|
List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. | StringList | List of tags that meet AWS requirements | No default value |
This control checks whether an Amazon RDS DB snapshot has tags with the specific keys defined in the parameter
requiredTagKeys
. The control fails if the DB snapshot doesn’t have any tag keys or if it doesn’t have all the keys specified in the
parameter requiredTagKeys
. If the parameter requiredTagKeys
isn't provided, the control only checks for the existence
of a tag key and fails if the DB snapshot isn't tagged with any key. System tags, which are automatically applied and begin with aws:
,
are ignored.
A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.
Note
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.
Remediation
To add tags to an RDS DB snapshot, see Tagging Amazon RDS resources in the Amazon RDS User Guide.
[RDS.33] RDS DB subnet groups should be tagged
Category: Identify > Inventory > Tagging
Severity: Low
Resource type:
AWS::RDS::DBSubnetGroup
AWS Config rule:tagged-rds-dbsubnetgroups
(custom Security Hub rule)
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
requiredTagKeys
|
List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. | StringList | List of tags that meet AWS requirements | No default value |
This control checks whether an Amazon RDS DB subnet group has tags with the specific keys defined in the parameter
requiredTagKeys
. The control fails if the DB subnet group doesn’t have any tag keys or if it doesn’t have all the keys specified in the
parameter requiredTagKeys
. If the parameter requiredTagKeys
isn't provided, the control only checks for the existence
of a tag key and fails if the DB subnet group isn't tagged with any key. System tags, which are automatically applied and begin with aws:
,
are ignored.
A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.
Note
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.
Remediation
To add tags to an RDS DB subnet group, see Tagging Amazon RDS resources in the Amazon RDS User Guide.
[RDS.34] Aurora MySQL DB clusters should publish audit logs to CloudWatch Logs
Related requirements: NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)
Category: Identify > Logging
Severity: Medium
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
rds-aurora-mysql-audit-logging-enabled
Schedule type: Change triggered
Parameters: None
This control checks whether an Amazon Aurora MySQL DB cluster is configured to publish audit logs to Amazon CloudWatch Logs. The control fails if the cluster isn't configured to publish audit logs to CloudWatch Logs. The control doesn't generate findings for Aurora Serverless v1 DB clusters.
Audit logs capture a record of database activity, including login attempts, data modifications, schema changes, and other events that can be audited for security and compliance purposes. When you configure an Aurora MySQL DB cluster to publish audit logs to a log group in Amazon CloudWatch Logs, you can perform real-time analysis of the log data. CloudWatch Logs retains logs in highly durable storage. You can also create alarms and view metrics in CloudWatch.
Note
An alternative way to publish audit logs to CloudWatch Logs is by enabling advanced auditing and setting the cluster-level DB
parameter server_audit_logs_upload
to 1
. The default for the server_audit_logs_upload parameter
is 0
. However, we recommend you use the following remediation instructions instead to pass this control.
Remediation
To publish Aurora MySQL DB cluster audit logs to CloudWatch Logs, see Publishing Amazon Aurora MySQL logs to Amazon CloudWatch Logs in the Amazon Aurora User Guide.
[RDS.35] RDS DB clusters should have automatic minor version upgrade enabled
Related requirements: NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5)
Category: Identify > Vulnerability, patch, and version management
Severity: Medium
Resource type:
AWS::RDS::DBCluster
AWS Config rule:
rds-cluster-auto-minor-version-upgrade-enable
Schedule type: Change triggered
Parameters: None
This control checks if automatic minor version upgrade is enabled for an Amazon RDS Multi-AZ DB cluster. The control fails if automatic minor version upgrade isn't enabled for the Multi-AZ DB cluster.
RDS provides automatic minor version upgrade so that you can keep your Multi-AZ DB cluster up to date. Minor versions can introduce new software features, bug fixes, security patches, and performance improvements. By enabling automatic minor version upgrade on RDS database clusters, the cluster, along with the instances in the cluster, will receive automatic updates to the minor version when new versions are available. The updates are applied automatically during the maintenance window.
Remediation
To enable automatic minor version upgrade on Multi-AZ DB clusters, see Modifying a Multi-AZ DB cluster in the Amazon RDS User Guide.
[RDS.36] RDS for PostgreSQL DB instances should publish logs to CloudWatch Logs
Category: Identify > Logging
Severity: Medium
Resource type:
AWS::RDS::DBInstance
AWS Config rule: rds-postgresql-logs-to-cloudwatch
Schedule type: Change triggered
Parameters:
Parameter | Description | Type | Allowed custom values | Security Hub default value |
---|---|---|---|---|
|
Comma-separated list of log types to be published to CloudWatch Logs |
StringList |
Not customizable |
|
This control checks whether an Amazon RDS for PostgreSQL DB instance is configured to publish logs to Amazon CloudWatch Logs. The
control fails if the PostgreSQL DB instance isn't configured to publish the log types mentioned in the logTypes
parameter to CloudWatch Logs.
Database logging provides detailed records of requests made to an RDS instance. PostgreSQL generates event logs that contain useful information for administrators. Publishing these logs to CloudWatch Logs centralizes log management and helps you perform real-time analysis of the log data. CloudWatch Logs retains logs in highly durable storage. You can also create alarms and view metrics in CloudWatch.
Remediation
To publish PostgreSQL DB instance logs to CloudWatch Logs, see Publishing PostgreSQL logs to Amazon CloudWatch Logs in the Amazon RDS User Guide.
[RDS.37] Aurora PostgreSQL DB clusters should publish logs to CloudWatch Logs
Category: Identify > Logging
Severity: Medium
Resource type:
AWS::RDS::DBCluster
AWS Config rule: rds-aurora-postgresql-logs-to-cloudwatch
Schedule type: Change triggered
Parameters: None
This control checks whether an Amazon Aurora PostgreSQL DB cluster is configured to publish logs to Amazon CloudWatch Logs. The control fails if the Aurora PostgreSQL DB cluster isn't configured to publish PostgreSQL logs to CloudWatch Logs.
Database logging provides detailed records of requests made to an RDS cluster. Aurora PostgreSQL generates event logs that contain useful information for administrators. Publishing these logs to CloudWatch Logs centralizes log management and helps you perform real-time analysis of the log data. CloudWatch Logs retains logs in highly durable storage. You can also create alarms and view metrics in CloudWatch.
Remediation
To publish Aurora PostgreSQL DB cluster logs to CloudWatch Logs, see Publishing Aurora PostgreSQL logs to Amazon CloudWatch Logs in the Amazon RDS User Guide.