Automating RDS Security Via Boto3 (AWS API)

When it comes to security in AWS, there is the shared responsibility model for AWS services, which is divided into AWS responsibility ‘security of the cloud’ and customer responsibility ‘security in the cloud’. For more detail on this please check the shared-responsibility-model.

Figure 1: AWS Shared Responsibility Model

Source: shared-responsibility-model 

What are customer responsibilities of RDS security based on the shared-responsibility-model? 

Customer responsibilities in Relational Database Service (RDS) security includes managing your Virtual Private Cloud (VPC) network where our RDS is deployed, assigning Identity and Access Management (IAM) policies to allow permission to RDS instances, creating security groups (EC2 firewall) to determine which IPs connect to your  ; making sure our instances  use SSL/TLS protocols, as well as Amazon RDS encryption to secure our DB instances at rest. For more information, please check RDS security       

When we discuss RDS security there are a lot of metrics to cover and many questions to ask. Such as:

• Who can create and manage RDS instances in our AWS account if we have multiple IAM users in our account?
• Which IP addresses and EC2 instances can connect to our instance remotely?
• How can we secure our data at rest in our RDS instances? 

Customer Managed IAM policy

To answer to the question, ‘Who can create and manage RDS instances?’, we can look into customer managed policies. We can use IAM policy to determine who is allowed to create, describe, modify, and delete DB instances, tag resources, or modify security groups.

To create a policy and assign it to a user we must have Admin privileges. If we want to create an instance specific policy, we need to create the RDS instance beforehand.

Let’s create a policy that will allow a user to create an RDS instance.

Figure 2: Creating an instance specific policy 

After creating the instance specific policy, we created a user to which we attached the newly created Policy.

Figure 2a: Creating an instance specific policy 

To make sure this user is created we can log into our AWS console and search under Users.

Figure 3: Verifying user is created

When creating managed policies, we need to prepare a JSON format policy description that contains the API version (which we can find by looking into AWS managed policies), and statement.

Figure 4: Creating a policy

Figure 4a: Creating a policy 

By allowing or denying the specified action on the resource, we assign this policy certain privileges in the parameter ‘Statement’ of policy description. For the above example, we chose to allow this policy to have a ‘CreateDBInstance’ permission for RDS instances. The parameter ‘Effect’ is by default set to ‘Deny’, so if we want to allow a user access, we need to change that value to ‘Allow’.

Figure 5: Attaching the policy to a user(s) 

Giving proper permissions to policies and attaching AWS users to them allows us to restrict a user’s access to different AWS services, including RDS instances. 

Security Groups

Security groups answer the question of which IPs can access our RDS instances remotely, and how we can limit this access so that data is not exposed to attackers. Security groups for RDS have VPC level access controls that will determine which traffic (IP addresses or EC2 instances within AWS) can connect to our DB instances.  

When you create an RDS instance, by default, any traffic to or from the instance is denied. To be able to connect to our DB instance remotely, we need to add these rules by adding the allowed IPs for the ‘inbound’ and ‘outbound’ rules we can control. 

The process of creating security groups and attaching them to DB instances can be easily automated using boto3. Before creating security groups, you must have an RDS instance created.

Step one: Create VPC security groups.

Figure 6: First step in creating a VPC security group

 Output

Figure 7: Output of creating a VPC security group

Step two:  Create inbound and outbound rules.

As security groups are managed at the EC2 level, we need to send a request for inbound and outbound rules authorization. This is where we create the virtual firewall rule, which IPS can remotely connect to our DB instances.  

Inbound rules

Figure 8: creating inbound rules

Outbound rules

Figure 9: Creating outbound rules

Now that we have created a security group, we need to attach it to the RDS instance to use this virtual firewall.

Figure 10: Creating a virtual firewall

At this point we have successfully limited the incoming traffic for our instance and defined its outgoing traffic. 

KMS Keys 

To add data encryption as an additional layer of security, AWS allows users to create their own customer managed keys to encrypt and decrypt our data at rest in order to secure it from unauthorized access to the storage.

A Customer Master Key (CMK) is a customer managed key used to encrypt data, but the maximum size of data it can encrypt is 4KB. Its main use is to generate, encrypt, and decrypt data keys, which are symmetric keys used to encrypt and decrypt large amount of data, including other data encryption keys. AWS KMS (Key Management System) supports two types of CMKs: Symmetric CMK (a 256-bit symmetric key that never leaves AWS KMS unencrypted by default and is used to created symmetric CMK), and Asymmetric CMK (a key pair where a private key never leaves AWS KMS unencrypted). 

Once we have created an encrypted DB instance, we cannot change the KMS key used by that DB instance. Therefore, it is imperative to determine the KMS key requirements before creating your encrypted DB instance. 

To encrypt data at rest in our RDS, we need to have a privilege that allows a user to generate keys. We do this by assigning a policy with the action ‘kms:GenerateDataKey’  to our user.

Figure 11: Creating a CMK (customer master key)

Now we can create a data key using the master key (CMK) created above.

Figure 12: CMK data key created

Finally, we can create an encrypted RDS instance, as follows:

Figure 13: Encrypted RDS key instance created

Amazon RDS also supports encrypting an Oracle or SQL Server DB instance with Transparent Data Encryption (TDE). TDE can be used with encryption at rest, although using TDE and encryption at rest simultaneously might slightly affect the performance of the database. 

Conclusion

The security metrics discussed above are not the only measures to secure RDS instances. There are many other tools we can use. For example, we can look at our cloud trail log for any unauthorized activities and enable the AWS security hub to check on the general security health of our AWS services, including RDS.  Automating our security measures provides a great deal of flexibility and agility for taking the appropriate security measures and allows us to add more metrics as needed. For detailed security audits, please check Trustwave’s database security audit services.