How to use IAM multifactor authentication with Amazon RDS

A common request that we get from customers is how to protect their resources from an accidental or malicious deletion, such as instances, snapshots, clusters, and so on. Doing this is especially important when you are using a common AWS account for multiple users or teams. Although you want the flexibility to innovate within the account, you also need security to protect from losing critical data.

One option is to use AWS Identity and Access Management (IAM) policies with multifactor authentication (MFA). MFA requires users to type a unique authentication code from an approved authentication device or SMS text message when they attempt to perform AWS operations. This blog post shows a demo of how to achieve this.

As an example, we create an IAM policy that restricts the ability to delete assets protected through tagging with a naming convention such as *prod*.

Next, we create a second IAM policy that requires MFA authentication to access the AWS Management Console and only gives certain delete privileges to this account. This way, you can audit all users that have access and be sure that only the select individuals have the privileges required.

We make use of two policies. One is an AWS managed policy, AmazonRDSFullAccess. The other is customer managed and is called RDSDenyDelete. This policy restricts users from running commands that might delete resources.

First step: Start in the IAM console

Start by going to the IAM console. Choose Create policy and paste the following JSON code into the policy editor box.

{
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "rds:DeleteDBClusterSnapshot",
                "rds:DeleteDBSnapshot",
                "rds:DeleteDBCluster",
                "rds:DeleteDBInstance"
            ],
            "Resource": "*"
        }
    ]
}

Choose Review policy, and then give the policy a name and description.

Now, we create a group that combines the AmazonRDSFullAccess policy with the RDSDenyDelete policy.

From Groups on the IAM console, choose Create new group, and then set the group name. We choose AWSDevelopmentTeam for this example.

Choose Next step. Check the boxes next to AmazonRDSFullAccess and RDSDenyDelete.

Choose Next step, and then Create group.

Now, when you add new users to the AWSDevelopmentTeam group, they have full Amazon RDS access but are restricted from deleting any critical resources.

Next step: Restrict deletion only to resources tagged for production

The policy so far might be overly restrictive for your development team. Let’s make this policy less restrictive to only protect resources tagged as production. Doing this allows developers in the AWSDevelopmentTeam group to delete their test instances while still protecting productions resources. To do this, go back to RDSDenyDelete in the policy editor and add lines 11 through 16 from the following JSON code.

1 {
2     "Statement": [
3         {
4             "Effect": "Deny",
5             "Action": [
6                 "rds:DeleteDBClusterSnapshot",
7                 "rds:DeleteDBSnapshot",
8                 "rds:DeleteDBCluster",
9                 "rds:DeleteDBInstance"
10             ],
11            "Resource": "*",
12             "Condition": {
13                 "StringLikeIfExists": {
14                     "aws:TagKeys": "production"
15                  } 
16              }
17         }
18     ]
19 }

Note: This is a simple example. In a production environment, you also need to include protection for AddTagsToResouce and RemoveTagsFromResounce because the tags themselves protect these resources. This approach implies that you need to tag production resources with the AddTagToResource API action.

Next step: Create a group with permissions to delete production resources

Now we show how to create another policy to use to delete production resources. You only need to grant this permission in the situation where it is necessary to delete resources. Your AWS security officer can selectively choose to grant this permission on an as-needed basis.

Again, create the policy in the policy editor by adding the following code.

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DeleteDBClusterSnapshot",
                "rds:DeleteDBSnapshot",
                "rds:DeleteDBCluster",
                "rds:DeleteDBInstance"
            ],
            "Resource": "*"
        }
    ]
}

Choose Review policy, and then give the policy a name and description.

Final step: Protect this policy with MFA

To add MFA to our RDSDeleteResources policy, again open the policy editor and add lines 12 through 17 from the following JSON code to require MFA authentication.

Note: MFA protection is available only with temporary security credentials, which must be obtained with AssumeRole or GetSessionToken. Refer to Configuring MFA-protected API access to learn more.

1 {
2     "Version": "2012-10-17",
3     "Statement": [
4         {
5             "Effect": "Allow",
6             "Action": [
7                 "rds:DeleteDBClusterSnapshot",
8                 "rds:DeleteDBSnapshot",
9                 "rds:DeleteDBCluster",
10                 "rds:DeleteDBInstance"
11             ],
12             "Resource": "*",
13             "Condition": {
14                 "BoolIfExists": {
15                     "aws:MultiFactorAuthPresent": "true"
16                 }
17             }
18         }
19     ]
20 }

Now when the policy is applied to users by your AWS security officer, users are required to authenticate with MFA before being granted access to the AWS Management Console or API.

Setting up MFA

There are a number of free MFA applications available. For example, I have downloaded one called Authy. AWS users need to register their MFA device (a cell phone with Authy installed for example) to answer the MFA login challenge.

For directions about how to select and set up an MFA device, see Enabling a Virtual Multifactor Authentication (MFA) Device in the IAM User Guide.

When working with a policy like the one we just created, we recommend restricting users’ access to just the console. Thus, when you create these users with delete privileges, you only grant them “AWS Management Console access”.

Summary

This blog post shows you how to set up IAM security policies that provide the flexibility to innovate within your account while at the same time providing a mechanism to protect critical data resources. Also, we showed how to use MFA to provide an extra layer of security for destructive actions. Now you have a method to restrict destructive requests to only specified individuals with a means to control access.

About the Author

Phil Intihar is a database engineer at Amazon Web Services.