Best practices for protecting AWS RDS and other cloud databases

It’s no surprise that organizations are increasingly using cloud-native services, including for data storage. Cloud storage offers tremendous benefits such as replication, geographic resiliency, and the potential for cost-reduction and improved efficiency.

The Amazon Web Services (AWS) Relational Database Service (RDS) is one of the most popular cloud database and storage services. At a high-level, RDS streamlines setup, operation, and scaling relational databases in AWS, such as MariaDB, Microsoft SQL Server, MySQL, and others. RDS, much like any other AWS or cloud service offering, makes use of the shared responsibility model. This means the cloud service provider (CSP) — AWS in this case — is responsible for protecting the underlying infrastructure and hosting environments and consumers are responsible for their share of RDS, which includes the OS, configurations, and architecture considerations.

Failing to account for the consumer share of RDS responsibilities can lead to cloud data breaches, of which we have seen plenty. Key areas include configuring access to the virtual private cloud (VPC) the database instance will reside in, application identity and access management (IAM) policies, and security groups to control network traffic and encryption. We will discuss some of those areas below, along with others such as compliance as well.

Authentication is key to RDS security

One of the first key considerations is authentication, or how users validate their identity to access RDS database instances. Among the options are passwords, Kerberos, and IAM database authentication. Consumers need to determine which authentication route they will choose and then implement the appropriate controls such as password complexity, MFA, and IAM policies.

In the areas of data protection, key considerations include using multifactor authentication as well as using SSL/TLS to communicate with other resources and ensuring you’re using an appropriate TLS version such as 1.2. Other recommendations from AWS include using their service Macie, which can help discover and secure sensitive data stored in S3. Macie uses machine learning (ML) to discover sensitive data, build an interactive map, and even automatically generate findings and send them to AWS services such as AWS Security Hub so vulnerable configurations or exposed data can be remediated.

AWS provides various methods for encrypting AWS RDS resources which includes encrypting data-at-rest in the underlying DB instances, automated backups, read replicas, and snapshots. To facilitate this, AWS uses its Key Management Service (KMS). There are various options here, depending on whether you want to maintain management responsibility for the keys yourself or use AWS-managed keys. When going the route of customer-managed keys, you can modify things such as key policies and IAM policies to implement more granular access control and usage constraints for the keys, such as limiting where requests for access to the RDS instance can originate.

Customers can also make use of AWS CloudTrail to audit the KMS key usage to identify potentially malicious behavior or misuse of permissions and access to data. For a deeper dive on AWS encryption and the use of KMS, AWS has a Key Management Service Best Practices whitepaper.

Key considerations when encrypting AWS RDS

That said, there are some key considerations to take into account when encrypting AWS RDS database instances. You must encrypt the database instance at the time of creation; you cannot go back and encrypt it later. You also cannot turn off encryption once it is enabled.

Organizations should also take into consideration securing the traffic between the RDS service and on-premise clients and applications, such as making use of AWS Site-to-Site VPN or AWS Direct Connect to ensure that traffic isn’t exposed to unauthorized parties.

We have all seen the headlines of cloud data storage buckets or instances being publicly exposed. This is where features such as AWS Security Groups come into play. Security groups help control the access of network traffic into and out of RDS instances. Luckily, AWS has taken the approach where network access is off by default and users must specify rules in their security groups to allow traffic from specific IP addresses or ranges. This allows users to implement configurations such as allowing traffic from their application services to the backend RDS database.

AWS provides a useful diagram to help visualize a common scenario, such as having an AWS RDS database instance running in a private subnet (not publicly accessible) and then having an application service running on an EC2 instance in a public subnet with connectivity to the internet. Users can implement and modify security groups on both the web app and database instances to allow the appropriate network flow of traffic to facilitate functionality but also minimize unauthorized access and risk.

Amazon Web Services

Avoid using a jump host

Another often cited recommendation is to avoid the use of a “jump host”, which is where developers or administrators may connect to a host in a public subnet over something such as Port 22, and then “jump” from that to the backend RDS instance running in a private subnet. However, as many have noted, such as in this AWS blog, jump hosts can fall victim to attacks such as IP spoofing and other methods.

Amazon Web Services

Instead, users can use AWS Sessions Manager to remove the use of a jump host and still allow secure entry of network traffic to the RDS instance.

Amazon Web Services

AWS makes a series of other key security best practice recommendations for consumers using AWS RDS as part of their cloud architecture. These include activities such as creating individual user accounts for each person accessing the AWS RDS resources and not using AWS root credentials to manage RDS. This is key because it is a security best practice to avoid shared accounts and the use of individual accounts allow for more granular access control as well as attribution from a logging and monitoring perspective, meaning you know who does what.

Another key recommendation is to implement the longstanding approach of least-permissive access control, which aligns with the industry push for zero trust. This means only granting the minimally required permissions to the accounts to perform their duties and nothing more. However, managing permissions at scale across large user bases can be difficult, which is why AWS also recommends using IAM groups to manage permissions for multiple users, where you can implement role-based access control.

Moving forward with AWS RDS

While the above discussion is far from exhaustive in regards to AWS RDS security best practices, it helps frame the conversation on key considerations when making use of the RDS service and how to ensure your data and that of your customers is safeguarded appropriately when using the service. You’ll also notice key themes that are agnostic of AWS that should be considered when using any cloud data storage service. These include things such as Identity and Access Management (IAM), Network Access Control, Encryption and more.

By thinking about the use of cloud storage through the perspective of these areas you can start to ensure you can reap the benefits of cloud storage and databases but do so without putting the organization at risk.