Enforce configuration policies for your Amazon RDS databases using AWS Config

In today’s cloud-enabled enterprise, multiple teams take on the responsibility of creating and managing databases. The challenge that you may face is the enforcement of your company’s standard configuration policies—how do you make sure that all databases are following the database configuration standards consistently? This is where AWS Config can help. In this post, I show you how you can detect and enforce standard database configuration policies for your Amazon Relational Database Service (Amazon RDS) and Amazon Aurora databases to ensure that you’re fulfilling your part of the shared responsibility model.

The AWS shared responsibility model states that security and compliance is a shared responsibility between AWS and the customer. The customer assumes responsibility and management of the guest operating system (including updates and security patches) and other associated application software in addition to the configuration of the AWS provided security group firewall. From an Amazon RDS perspective, it means that you are responsible for your data, database identities, network layer around the database instances, and encryption of data at rest and in motion.

Typically, organizations create standard security policies for their databases. These are standard configurations that are applied to all instances of the databases that the organization creates and manages. These standard configuration policies are designed to ensure that customer is fulfilling their part of the shared responsibility model. For example, you may have a policy to ensure that no database instance is placed in a public subnet, or a standard database policy may dictate that the production databases are allowed only in specific VPCs.

Solution overview

AWS Config is a compliance service that allows you to address resource configurations that don’t align with the standard configuration policies. In addition to detection, AWS Config allows you to set up automations for carrying out remediation actions. For example, you may automatically stop an RDS instance that is exposed to the public network.

The configuration policies for the resources are defined in the form of rules. There are multiple predefined rules that are available to you for AWS resources, including Amazon RDS. These rules are referred to as managed rules. You can also define your own custom rules; for example, if your company’s standard configuration requires all databases to have standard tags, you can define a rule to detect and enforce the tagging rule. Later in this post, I show you how to define a custom rule using the domain-specific language Guard.

The AWS Config rules can be triggered when a resource is created, changed, or deleted, or they can be triggered on a periodic basis. If the rule evaluation determines a resource to be noncompliant, it marks the resource instance as such. You can carry out the remediation manually or automate it. Some of the managed rules already have predefined automations that, when enabled, automatically take appropriate actions. You can also create your own auto-remediation steps by way of an AWS Lambda function.

You can check the compliance status for the resources on the AWS Config console. You can also check out the config change history for your resources that are recorded by AWS Config. AWS Config delivers configuration changes data to an Amazon Simple Storage Service (Amazon S3) bucket that you provide as part of the service setup. For some critical resources, you may want to be alerted immediately in case noncompliance is detected; for that AWS Config offers the capability to publish to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribers can subscribe to the SNS topic to receive alerts.

If you have set up multiple AWS accounts for managing your enterprise’s AWS Cloud infrastructure, you can use an AWS Config aggregator, which consolidates the compliance data from all of the accounts (and Regions) into a single view.

Prerequisites

To try out the solutions in this post, you need an AWS account and permissions to create the appropriate resources. Because these solutions involve AWS resource setup and utilization, it will incur the costs on your account. Refer to AWS Pricing for more information.

Enable AWS Config

AWS Config is by default disabled in an AWS account. You need to carry out the following steps in order to try out the exercises suggested in this post. If AWS Config is already enabled in your account, make sure that RDS resources are tracked.

1. On the AWS Config console, choose Get started to start the setup wizard.
2. For Resource types to record, select Record all resources supported in this region.
3. For AWS Config rules, select Create AWS Config service-linked role.
4. For Amazon S3 bucket, select Create a bucket.
5. For Amazon S3 bucket name, enter a name for your bucket.

For this post, we create a bucket called config-bucket-<<AWS account number>>.

6. Choose Next.

7. Choose Next until you reach the final page, then confirm your settings.

Add a managed rule for Amazon RDS

AWS Config offers multiple managed rules for Amazon RDS. I discuss some of the rules in this post, but encourage you to read through all the rules and evaluate how you can use them to detect and enforce your organization’s database configuration policies:

• rds-cluster-default-admin-check – Checks if an RDS database has changed the admin user name from its default value. This rule only runs on RDS database instances. The rule is NON_COMPLIANT if the admin user name is set to the default value. The rule also takes a parameter in which you can set the allowed admin names for the databases. For more information, refer to rds-cluster-default-admin-check.
• rds-cluster-deletion-protection-enabled – Checks if an RDS cluster has deletion protection enabled. This rule is NON_COMPLIANT if an RDS cluster doesn’t have deletion protection enabled.
• rds-instance-public-access-check – Checks whether the RDS instances are not publicly accessible. The rule is NON_COMPLIANT if the publiclyAccessible field is true in the instance configuration item.
• rds-multi-az-enabled – Checks whether high availability is enabled for your RDS DB instances. In a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. This rule is NON_COMPLIANT if an RDS instance isn’t configured with Multi-AZ.
• rds-snapshots-public-prohibited – Checks if RDS snapshots are public. The rule is NON_COMPLIANT if any existing and new RDS snapshots are public.

Now that AWS Config is enabled in your account and you have learned about some of the commonly used rules, let’s add a managed rule to enforce the admin user name policy. To test the rule, you create an RDS instance that violates the admin name policy and as a result, AWS Config will report the instance to be noncompliant. You then carry out manual remediation to get the instance back to a compliant state.

1. On the AWS Config console, choose Rules in the navigation pane.
2. Choose Add rule.

3. Select Add AWS managed rule.
4. Search for and select the rule rds-instance-default-admin-check.

This rule gets triggered when a DB cluster is created, changed, or deleted.

5. Choose Next.

6. Choose Add rule.

Test the setup

To test out the rule, create an RDS DB instance (for example, PostgreSQL) with the default admin user name.

After the database is created, the rule is triggered automatically. You can check the status of the rule on the AWS Config console. If you have any existing RDS DB instances, they are in scope for the rule’s compliance check.

Because you can’t change the primary user name of an RDS DB instance, it’s important to detect such noncompliant clusters early enough to prevent them from getting used. This is where real-time noncompliance notifications or alerts can help.

Clean up

Keep in mind that running resources costs money. Make sure to delete the RDS database instance that you created for testing. Retain the AWS Config rule, because we use it in the next exercise.

Create an alert for noncompliant databases

AWS Config emits events that can be subscribed to via Amazon EventBridge. The event payload is in JSON format and is sent on configuration changes and notifications. You can define an event pattern to capture events related to the detection of noncompliant databases. Events are delivered to an SNS topic that you can subscribe to and get alerts from in real time.

Let’s set up an email alert for noncompliant database clusters for the rule rds-cluster-default-admin-check using an SNS topic and EventBridge rule.

We start by creating the SNS topic.

1. On the Amazon SNS console, choose Topics in the navigation pane.
2. Choose Create topic.
3. Select Standard.
4. Name the topic my-non-compliant-rds-resource.
5. Choose Create topic.

Next, we create the subscription.

6. Choose Subscriptions in the navigation pane.
7. Choose Create subscription.
8. For the topic ARN, choose the topic you created.
9. For the protocol, select Email.
10. For the endpoint, enter your email address.
11. Choose Create subscription.

After the subscription is created, you receive an email.

12. Follow the instructions in the email to confirm the subscription.

Now you’re ready to create your EventBridge rule.

13. On the EventBridge console, choose Rules in the navigation pane.
14. Choose Create rule.
15. For Name, enter my-rds-config-compliance-rule.
16. Set the rule type to Rule with an event pattern.
17. Choose Next.
18. For the event pattern, choose Custom patterns.
19. Enter the following JSON as your pattern:

{
    "source": [
        "aws.config"
    ],
    "detail-type": [
        "Config Rules Compliance Change"
    ],
    "detail": {
        "messageType": [
            "ComplianceChangeNotification"
        ],
        "configRuleName": [
            "rds-instance-default-admin-check"
        ],
        "resourceType": [
            "AWS::RDS::DBInstance"
        ],
        "newEvaluationResult": {
            "complianceType": [
                "NON_COMPLIANT"
            ]
        }
    }
}

20. Choose Next.
21. Set the target as SNS topic and choose the topic you created earlier.
22. Expand Additional settings.
23. For Configure target input, select Input transformer.
24. Choose Configure input transformer.
25. For Input path, enter the following code:

{
    "awsRegion": "$.detail.awsRegion",
    "resourceId": "$.detail.resourceId",
    "awsAccountId": "$.detail.awsAccountId",
    "compliance": "$.detail.newEvaluationResult.complianceType",
    "rule": "$.detail.configRuleName",
    "time": "$.detail.newEvaluationResult.resultRecordedTime",
    "resourceType": "$.detail.resourceType"
}

26. For Template, enter the following:

"On <time> AWS Config rule <rule> evaluated the <resourceType> with Id <resourceId> in the account <awsAccountId> region <awsRegion> as <compliance> For more details open the AWS Config console at https://console.aws.amazon.com/config/home?region=<awsRegion>#/timeline/<resourceType>/<resourceId>"

27. Choose Confirm.
28. Choose Next until you reach the final page to create the rule.

Test the setup

To test out the rule, create an RDS DB instance (for example, PostgreSQL) with the default admin user name. It starts a compliance check, and you will receive an email indicating that the database cluster is in a state of noncompliance.

Clean up

To clean up your resources, complete the following steps:

1. On the Amazon RDS console, delete the test RDS DB instance.
2. On the SNS console, delete the email subscription you created and the topic my-non-compliant-rds-resource.
3. On the EventBridge console, delete the rule my-rds-config-compliance-rule.
4. On the AWS Config menu, delete the rule rds-cluster-defaut-admin-check rule.

Create a custom rule for Amazon RDS

If your organization has database security policies that aren’t covered by one of the available managed rules, then you can create your own custom rules. These custom rules are coded in either AWS Lambda or using the domain-specific language called Guard. In this step, you create a custom rule for checking the RDS instance or Aurora cluster port in use.

Consider a scenario in which your security team decides to ensure that all databases must be configured with non-default DB engine ports. In other words, an Amazon Aurora PostgreSQL-Compatible database instance will be noncompliant if it’s set up to use port 5432; similarly, an Amazon Aurora MySQL-Compatible database will be noncompliant if it’s set up with port 3306. This rule isn’t available as a managed rule; as a result, you need to create it as a custom rule. To simplify the task, you set up the rule such that irrespective of the DB engine, none of the commonly used database ports are allowed. A DB cluster and DB instance are considered compliant if they’re not using the ports 5432 (PostgreSQL) or 3306 (MySQL or MariaDB).

We first set up a custom rule to check the DB port.

1. On the AWS Config console, choose Rules in the navigation pane.
2. Choose Add rule.
3. Select Create custom rule using Guard.
4. Choose Next.

5. For Name, enter my-custom-cluster-db-port-check-rule.
6. Select Enable debug logs to log messages in Amazon CloudWatch every time the rule is triggered.
7. Under Rule content, enter the following code:

rule aws_rds_dbcluster_resources when
resourceType == "AWS::RDS::DBCluster" {
    configuration.port NOT IN[5432, 3306]
}

8. In the Trigger section, for Scope of changes, select Resources.
9. For Resource category, choose AWS resources.
10. Choose the resource type AWS RDS DBCluster.

11. Choose Next, then choose Add rule.

Test the setup

To test the setup, create an Aurora PostgreSQL or Aurora MySQL database with the default port number. If you have any existing Aurora databases, they are in scope for the rule’s compliance check.

Open the AWS Config console to check the resource compliance status; it should be noncompliant.

To make the DB resource compliant, modify the DB cluster to a port that isn’t 5432 or 3306.

Check the AWS Config dashboard for the updated DB resource compliance status. It should now be compliant.

Clean up

To clean up your resources, complete the following steps:

1. On the Amazon RDS console, delete the Aurora database you created for testing.
2. On the AWS Config console, delete the rule results and the rule my-custom-cluster-db-port-check-rule.
3. On the CloudWatch console, delete the CloudWatch log group for the rule.

Deploy an Amazon RDS conformance pack

An AWS Config conformance pack is a collection of AWS Config rules and remediation actions. A conformance pack is deployed to a Region in an account. A compliance score is calculated based on the number of rule-to-resource combinations that are compliant within the scope of a conformance pack. Compliance scores are published to CloudWatch as metrics, and you can set up CloudWatch alarms to notify the team when the compliance score drops below a certain threshold for an extended time period.

Conformance packs are created by authoring a YAML template that contains the list of AWS managed or custom rules and remediation actions. AWS offers sample conformance packs for a number of services. As a best practice, we suggest that you review the RDS conformance pack and adjust it to the database best practices followed by your organization. Keep in mind that you can also include your own custom rules. Let’s try out the RDS conformance pack.

To use a conformance pack, you need to first deploy it.

1. On the AWS Config console, chose Conformance packs in the navigation pane.
2. Choose Deploy conformance pack.

3. For this post, select Use sample template to use the sample conformance pack for Amazon RDS.
4. Search for and choose Security Best Practices for RDS.

This conformance pack is a collection of managed Amazon RDS rules.

5. Choose Next.

6. For Conformance pack name, enter RDS-Best-Practices.
7. Choose Next.

8. Choose Deploy pack to complete the setup.

Test the setup

To test the setup, complete the following steps:

1. Create an RDS for PostgreSQL instance or Aurora MySQL cluster. Adjust the configurations to make them noncompliant with some of the rules in the RDS conformance pack:
   1. Use the default admin user name.
   2. Deselect the auto minor version upgrade.
   3. Deselect the delete protection option.
   4. Deselect the enable encryption option.
2. On the AWS Config console, choose Conformance packs in the navigation pane.
3. Locate the RDS conformance pack and choose View.

4. Check the status of the various rules in the conformance pack.

The compliance score is updated over a period of time and may not be usable right after the pack is deployed. You can also check the conformance pack timeline to learn how the security stance for your database has evolved over time.

Clean up

To clean up your resources, delete the DB cluster or DB instance you created for testing. Then delete the RDS conformance pack.

Final cleanup

If you had to enable AWS Config in your account, you can disable it at this time.

1. On the AWS Config console, choose Settings in the navigation pane.
2. Choose Edit.

3. Deselect Enable recording.

If AWS Config was already enabled in your account and you added the RDS resources in the list of resources, then edit the settings and deselect the resources you used under Record specific resource types.

4. If you no longer need the AWS Config data stored in the S3 bucket, delete the data and the S3 bucket.

Note that all data will be lost when you complete this step.

Conclusion

AWS Config provides a way to detect resources that aren’t in compliance with your security policies. In this post, you learned how to use managed and custom AWS Config rules for continuous detection of noncompliant resources. You also learned how to generate alerts to draw immediate attention to noncompliant resources. You can carry out remediation manually, or automatically using Lambda-based automation. Conformance packs are a collection of best practices that you can deploy across Regions and accounts to achieve consistency in terms of security practices. You can create your own RDS conformance pack template using managed and custom rules.

Now that you have learned how AWS Config can help you detect RDS resources that aren’t in compliance with your database best practices, we recommend that you review your organization’s database practices and take advantage of AWS Config.

About the author

Rajeev Sakhuja is a Solution Architect based out of New York City. He enjoys partnering with customers to solve complex business problems using AWS services. In his free time, he likes to hike, and create video courses on application architecture & emerging technologies; check him out on Udemy.