Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

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.

 19271_picture4

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.

19272_figure2 

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.

 19273_figure-2a

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.

 19274_figure3

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.

19275_figure4 

Figure 4: Creating a policy

19276_figure4a 

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

19277_figure5

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.

19278_figure6

Figure 6: First step in creating a VPC security group

 Output

19279_figure7 

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

19280_figure8

Figure 8: creating inbound rules

Outbound rules

19281_figure9

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.

19282_figure10 

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.

19283_figure11 

Figure 11: Creating a CMK (customer master key)

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

19284_figure12 

Figure 12: CMK data key created

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

19285_figure13 

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.  

 

Latest SpiderLabs Blogs

Why We Should Probably Stop Visually Verifying Checksums

Hello there! Thanks for stopping by. Let me get straight into it and start things off with what a checksum is to be inclusive of all audiences here, from Wikipedia [1]:

Read More

Agent Tesla's New Ride: The Rise of a Novel Loader

Malware loaders, critical for deploying malware, enable threat actors to deliver and execute malicious payloads, facilitating criminal activities like data theft and ransomware. Utilizing advanced...

Read More

Evaluating Your Security Posture: Security Assessment Basics

This is Part 4 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More