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
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:
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 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.
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.
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.
