Introduction

In today's rapidly evolving digital landscape, organizations increasingly rely on cloud platforms like Amazon Web Services (AWS) to host and manage their databases. According to a recent Cloud adoption study, 94% of enterprises use cloud services and 48% of businesses choose to store their most important data in the cloud^[1]. Security is a critical concern for organizations operating in the cloud, especially when it comes to securing sensitive and vulnerable data. Protecting compute resources, networks, and applications is essential; however, safeguarding data is arguably the highest priority. AWS has built its security infrastructure from the ground up, ensuring that databases running on AWS benefit from its highly secure physical infrastructure, account and role protections, Virtual Private Cloud (VPC) support, and ingress and egress lockdown capabilities. Even though this article is written for AWS, the security infrastructure and controls will largely be similar in other cloud providers like Azure or GCP.

In this article, we will first explore four essential best practices that will help you bolster the security of your databases hosted on AWS. These practices include properly configuring security groups, utilizing Virtual Private Clouds (VPCs), assigning dedicated user roles with minimal privileges, consistently rotating keys and passwords, and diligently reviewing audit logs. By implementing these strategies, you can significantly enhance the security of your databases and minimize the risk of unauthorized access or data breaches.

In the second section of this article, we look at a recent AWS offering - AWS GuardDuty for RDS protection. This will be a deep dive on what is Amazon GuardDuty, how it can uplevel your RDS security with minimal maintenance and most importantly what are some actionable steps you can take with your GuardDuty findings.

Protecting AWS Databases: Best Practices

AWS offers several tools and recommendations for enhancing database security. I will provide concrete steps you can take to implement four AWS best practices below. Organizations should adopt the following best practices to ensure the best possible database security posture:

1. Configure security groups to prevent exposure of the database to the outside world. Ensure resources interacting with the database are connecting from within the same VPC.

Security groups act as virtual firewalls for your AWS resources, controlling inbound and outbound traffic. By properly configuring security groups, you can restrict access to your database and ensure that only authorized resources can interact with it. By configuring security groups and ensuring that resources interact within the same VPC, you can significantly enhance the security of your databases hosted on AWS. Remember to review and update your security group rules regularly and keep your VPC configurations up-to-date to maintain a secure environment. Here are some best practices for configuring security groups for your AWS database:

• Define specific rules: Create fine-grained rules for your security group, specifying the allowed IP ranges, protocols, and ports. For example, only allow traffic from specific IP addresses or CIDR blocks that belong to your organization's network.
• Limit open ports: Open only the necessary ports for your database and avoid using overly permissive rules. For example, if you are using an Amazon RDS instance for MySQL, only open the MySQL port (3306) for inbound traffic.
• Regularly review and update rules: As your organization's infrastructure evolves, ensure that your security group rules are updated accordingly. Remove any outdated or unnecessary rules that could expose your database to potential threats.

A Virtual Private Cloud (VPC) is a logically isolated section of the AWS Cloud where you can launch and manage AWS resources. By keeping your database and the resources that interact with it within the same VPC, you can further enhance security^[2]. Here's how to ensure resources interact within the same VPC:

• Create a VPC: If you haven't already, create a VPC specifically for your database and its associated resources. This will help isolate your database environment from other parts of your AWS infrastructure.
• Configure VPC subnets and route tables: Divide your VPC into multiple subnets and configure route tables to control traffic flow between them. This way, you can segregate your database from other resources and limit the potential attack surface.
• Use VPC peering or AWS PrivateLink: If your database needs to communicate with resources in another VPC, use VPC peering or AWS PrivateLink to establish a secure connection between them without exposing the traffic to the public internet.

Source: CloudBasix VPC whitepaper^[3]

Example:

Suppose you have an Amazon RDS instance for MySQL running in a VPC (VPC-A) and an EC2 instance running a web application in another VPC (VPC-B). To ensure secure communication between the two resources, you can establish a VPC peering connection.

First, configure the security group for the RDS instance to only allow inbound traffic on port 3306 from the CIDR block of VPC-B. Next, create a VPC peering connection between VPC-A and VPC-B. Once the peering connection is established, update the route tables of both VPCs to allow traffic between them. This way, your web application can securely interact with the RDS instance without exposing the database to the outside world.

2. Create separate user roles for each application accessing the database, with minimum necessary privileges and access rights.

To ensure secure access to your database, it's essential to create separate user roles for each application accessing the database and limit their privileges and access rights. The principle of least privilege (POLP) is a security concept that requires giving users and applications the minimum necessary access to perform their tasks^[4]. By adhering to this principle, you can mitigate the risk of unauthorized access and prevent potential damage to your data. Here's how to implement POLP in your database security:

• Identify required privileges: Analyze each application's requirements and determine the necessary privileges for its specific tasks. For instance, an application that only reads data from your database may only need SELECT privileges.
• Create dedicated user roles: For each application, create a separate user role in your database with the identified privileges. This ensures that no single user has excessive access rights, reducing the potential for unauthorized actions.
• Limit access rights: In addition to limiting privileges, restrict the access rights of user roles to specific database objects, such as tables, views, or schemas, as needed. This ensures that each role can only interact with the necessary objects.
• Regularly audit and update user roles: As your applications and infrastructure evolve, review and update user roles and their associated privileges to maintain a secure environment. Remove unnecessary access rights and privileges as needed.

Example:

Consider a classic three-tier web application that consists of a frontend, a backend, and a database. The backend application needs to interact with the database to perform various operations, such as reading data, inserting new records, updating existing records, and deleting records.

To implement the principle of least privilege, you could create three separate user roles in your database:

• read_role: This role has SELECT privileges on relevant tables and is assigned to parts of the application that only require read access to the data.
• write_role: This role has INSERT and UPDATE privileges on relevant tables and is assigned to parts of the application responsible for adding or modifying data.
• delete_role: This role has DELETE privileges on relevant tables and is assigned to parts of the application responsible for removing data.

By creating these separate roles, you ensure that each part of the application has only the minimum necessary privileges to perform its tasks, reducing the risk of unauthorized access or actions.

3. Rotate keys and passwords regularly, and use temporary credentials for human operational maintenance tasks.

Regularly rotating keys and passwords is an essential practice to maintain a high level of security for your database. Using temporary credentials for human operational maintenance tasks helps reduce the risk of unauthorized access by ensuring that long-lived credentials aren't exposed or misused. Here's how to implement these best practices in your AWS environment:

• Key rotation: Rotate your database encryption keys regularly to minimize the potential impact of a compromised key. You can use AWS Key Management Service (KMS) to manage and automatically rotate your encryption keys^[5]. Set a rotation schedule that meets your organization's security requirements, such as every 90 days.
• Password rotation: Enforce a password rotation policy for database users, ensuring that passwords are changed periodically^[6]. This reduces the risk of unauthorized access due to leaked or compromised credentials. Establish a password rotation schedule, such as every 60 days, and implement password complexity rules to ensure strong, unique passwords.
• Temporary credentials: Use AWS Identity and Access Management (IAM) roles and temporary security tokens to grant short-lived access to your database for operational maintenance tasks. Instead of using long-lived credentials, temporary credentials expire after a specified duration, reducing the risk of unauthorized access.

Example:

Suppose you have a team of database administrators (DBAs) who periodically perform maintenance tasks on your Amazon RDS instances. To grant them secure access to your databases, you can create an IAM role and use temporary credentials.

First, create an IAM role with the necessary permissions to access the RDS instances. Then, enable the "AWS Security Token Service (STS)" for this role to generate temporary credentials. When a DBA needs access to perform maintenance tasks, they can assume the IAM role and obtain temporary security tokens, which include an access key, secret key, and a security token.

To further enhance security, set the temporary credentials' expiration time, such as 1 hour. This ensures that once the maintenance task is completed, the temporary credentials will no longer be valid, reducing the risk of unauthorized access.

4. Regularly review audit logs to identify patterns of misuse.

Monitoring and reviewing database audit logs play a crucial role in identifying security threats and patterns of misuse. Audit logs provide valuable information about user activity and access to database resources, enabling you to detect unauthorized access, anomalies, or potential security breaches. We will cover more on how these audit logs are helpful in GuardDuty findings in the next section. Here's how to implement regular audit log reviews in your AWS environment:

1. Enable database auditing: For your AWS databases, such as Amazon RDS or Amazon Aurora, enable auditing features to capture user activity logs. For example, use Amazon RDS's built-in database activity streams^[7] or enable MySQL or PostgreSQL's native auditing capabilities (Refer figure below).
2. Centralize log storage: Store your audit logs in a centralized and secure location, such as Amazon S3, for easy access and analysis. Use AWS services like AWS Glue or Amazon Kinesis Data Firehose to aggregate and transfer logs from multiple sources to a single location.
3. Implement log analysis and monitoring: Use AWS-native services like Amazon CloudWatch (Refer figure below) or Amazon GuardDuty, or third-party log analysis tools to monitor and analyze your audit logs for unusual patterns, unauthorized access attempts, or other potential security incidents.
4. Set up alerts and notifications: Configure alerts and notifications based on specific log events or patterns, such as multiple failed login attempts or unauthorized actions. This allows you to respond quickly to potential security incidents.
5. Regular log reviews: Schedule periodic log reviews to manually inspect your audit logs for signs of misuse or unusual activity that automated monitoring might miss. Establish a cadence for these reviews, such as weekly or monthly, depending on your organization's security requirements.

Example:

Imagine you have an Amazon RDS instance running PostgreSQL. To enable auditing, you can use the pgAudit extension ^[8], which captures detailed session and object audit logs. Configure pgAudit to track specific events, such as login attempts, data modifications, or schema changes.

Store the collected audit logs in Amazon S3 using a combination of Amazon Kinesis Data Firehose and AWS Glue for centralization and easy access. Then, use Amazon CloudWatch to analyze and monitor the logs for patterns of misuse, such as excessive failed login attempts, unauthorized data access, or unexpected database operations. Set up CloudWatch alarms to notify your security team via email or SMS when specific events or patterns are detected. Lastly, schedule regular manual log reviews to ensure your team stays informed about any potential security risks.

Exploring Amazon GuardDuty and Aurora: Enhancing Security and Automation of AWS RDS

In this section let us take a deeper look on how we can leverage Amazon GuardDuty to improve the security of Amazon Aurora database.

What is GuardDuty?

AWS GuardDuty aims to accurately detect threats in your AWS environment and provide unique security value through distinctive detections and threat mitigations. It produces actionable security findings with accurate and contextual information. Customer feedback plays a crucial role in refining these findings, reducing alert fatigue, and improving the accuracy of threat detection for organizations of all sizes. GuardDuty findings are automatically pushed to Amazon Detective for investigation, AWS Security Hub for consolidating findings, and EventBridge for further downstream processing. This integration enables seamless alerting and integration with third-party solutions.

Securing databases in the cloud is crucial for organizations of all sizes. AWS provides multiple layers of protection and offers best practices for database security. With tools like GuardDuty, customers can achieve enhanced security for their AWS databases and ensure the safety of their most sensitive assets.

AWS GuardDuty, provides an additional layer of security for AWS resources. Key features include:

1. Easy deployment: GuardDuty can be activated with a single click, providing organization-wide coverage.
2. Continuous monitoring: GuardDuty monitors different log sources and automatically protects new resources as they are created.
3. Advanced analytics: GuardDuty leverages machine learning capabilities to detect harder-to-identify threats.
4. Threat intelligence: GuardDuty uses its broad visibility into the AWS environment to identify malicious actors and alert you to threats earlier.
5. Integration with diverse environments: GuardDuty is designed to integrate with your existing tools and security solutions.

Amazon Aurora:

Amazon Aurora is a Cloud-Native Database Engine designed to cater to the needs of enterprises requiring advanced features, scaling, and performance. With cloud-native capabilities, Aurora offers a distributed, fault-tolerant, and self-healing storage system that scales up to 128 terabytes per database. Aurora clusters replicate across three availability zones, providing high performance and availability with up to 15 low-latency read replicas.

Before we explore how we secure Aurora wirth GuardDuty, let's go over the security features offered by default in AWS.

1. Aurora offers native security features of MySQL and PostgreSQL, such as encryption, TLS, auditing, and password lifecycle management. It also provides additional features like IAM authentication and database activity streams for monitoring audit logs.
2. AWS provides additional security features like Virtual Private Cloud (VPC), Identity and Access Management (IAM), and security groups to protect your databases.
3. AWS has introduced features like Performance Insights^[9] and DevOps Guru^[10] for RDS to provide a consistent tuning experience, detect, analyze, and recommend resolutions for database performance issues, and reduce manual labor for customers.

GuardDuty RDS Protection

GuardDuty RDS Protection is a new feature in AWS GuardDuty that enhances the security of Amazon RDS instances, including Aurora clusters. This new feature enhances the security of your RDS databases, starting with Amazon Aurora, by identifying suspicious logins and providing comprehensive monitoring without requiring any additional configuration. This feature is currently available in five regions: US East 1, US East 2, US West 2, Europe (Ireland), and Asia Pacific (Tokyo).

How Amazon GuardDuty RDS Protection Works

Amazon GuardDuty RDS protection leverages machine learning techniques to develop tailored machine learning models trained to detect threats and highly suspicious logins. GuardDuty RDS protection integrates seamlessly with existing GuardDuty deployments, automatically consuming new findings without requiring any additional setup. Visibility to the data sources, security analytics, and security findings is enhanced, providing context and insights to answer critical security questions.

Now let us deep dive into how we can enhance RDS security with Amazon GuardDuty RDS Protection. To get started, here is how you can enable RDS protection in your AWS account

aws guardduty update-detector --detector-id acc3b2845ba277826c911c16e19ebcdf --features [{"Name" : "RDS_LOGIN_EVENTS", "Status" : "ENABLED"}]'

If you have multiple environments, you can add in the account ids as follows

aws guardduty update-member-detectors --detector-id acc3b2845ba277826c911c16e19ebcdf --accountids 111111111111,222222222222,333333333333 --features '[{"Name": "RDS_LOGIN_EVENTS", "Status": "ENABLED"}]'

GuardDuty is a regional service, so it must be enabled in each specific region to provide visibility in that region. Enabling it in one region does not automatically grant visibility in other regions. When you enable GuardDuty for the first time, all protection plans, including RDS Protection, are enabled by default. You can choose to disable or opt-out of specific plans if desired. You can also view the RDS Protection status for each account and manage it at the individual account level if necessary using the accounts page in the GuardDuty console. However, maintaining organization-wide visibility is the recommended approach.

Enabling RDS protection through GuardDuty does not need additional infrastructure and it will not affect the performance of your database instances in any way. GuardDuty RDS Protection automatically covers all supported Aurora clusters in your account. There is no need to enable protection for each cluster individually, eliminating operational overhead and potential security coverage gaps. When a suspicious or anomalous login attempt indicating a threat to your database is detected by RDS Protection, GuardDuty will promptly create a new finding that contains important details about any vulnerable databases^[11].

The following are a list of all possible findings are specific to RDS and the severity and details of the findings will differ based on the finding type.

• • CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin
  • CredentialAccess:RDS/AnomalousBehavior.FailedLogin
  • CredentialAccess:RDS/AnomalousBehavior.SuccessfulBruteForce
  • CredentialAccess:RDS/MaliciousIPCaller.SuccessfulLogin
  • CredentialAccess:RDS/MaliciousIPCaller.FailedLogin
  • Discovery:RDS/MaliciousIPCaller
  • CredentialAccess:RDS/TorIPCaller.SuccessfulLogin
  • CredentialAccess:RDS/TorIPCaller.FailedLogin
  • Discovery:RDS/TorIPCaller

For example, CredentialAccess:RDS/AnomalousBehavior.FailedLogin finding denotes that there were one or more anomalous failed logins were observed on an RDS database in your AWS environment. A failed login attempts from public IP addresses may indicate that the RDS database in your account has been subject to an attempted brute force attack by a potentially malicious actor^[12]. By default the severity level of this policy type is set to low, you can change it to high if you want to take action on these FailedLogins. You may also set up an alarm threshold so that you can me notified once it crosses a certain threshold and you can immediately jump into to take appropriate actions.

You can also create sample it creates a copy of each GuardDuty finding Type.

Here is a sample finding specific to RDS(Note the severity):

In practice, when GuardDuty RDS protection is enabled on an Amazon Aurora cluster, Aurora collects and streams incoming connection details to detect suspicious activity. Detected threats are sent to the main GuardDuty service, where findings are presented with detailed information on the threat severity, timeframe, database involved, username, ASN of the connection, and the application involved. The machine learning models employed in GuardDuty RDS protection are designed to identify anomalies and filter out noise effectively.

Handling GuardDuty RDS Protection Findings

When it detects a threat it will not only alert you about there is an unusual behaviour like, there was an unusual log in to your database, but what was unusual about it? What was the expected behavior for, for this database, for this user? It provides all the details on the database, the database name, the username application, and then the actor details, taking that IP address and attributing it geographically to the ASN and as well as GuardDuty threat intelligence

You have all these findings from GuardDuty, now what?

Depending on the nature of the finding, it will provide recommendations for addressing the concern. For instance, if it tells you that connection attempts are coming from an unusual IP address range, it might advise you to tighten your security group posture in order to prevent unauthorized hosts from connecting, especially those outside your VPC. If GuardDuty RDS protection detects a user that you don't recognize and detects that it's connected to the system like the root database, it might advise you to terminate that connection at the database and rotate the credential that was used in order to prevent further connections. And whenever GuardDuty RDS protection detects unusual activity, it's a great opportunity for you or your security team to review database audit records and determine if the issue is part of a larger pattern of misuse or abuse. More information on remediating a compromised database can be found in the AWS GuardDuty docs.

Conclusion

Securing your databases in the cloud is a vital and ongoing responsibility for organizations leveraging AWS. By putting into practice, the security measures discussed in this article, such as configuring security groups, maintaining resources within the same VPC, creating separate user roles, rotating keys and passwords, and analyzing audit logs, you can create a resilient and secure database infrastructure on AWS. As your cloud environment evolves, it's essential to continually assess and update these security measures to address emerging threats and maintain robust protection. By following the insights shared in this article, you can build a solid foundation for database security in the AWS cloud and ensure the safety of your valuable data assets.

Amazon GuardDuty RDS protection offers an advanced, machine learning-driven solution for securing RDS databases, providing comprehensive monitoring and threat detection. This expansion of GuardDuty empowers users to better protect their databases and respond to threats in a timely and efficient manner. GuardDuty RDS Protection is a powerful addition to the AWS GuardDuty service, providing enhanced security for your Amazon RDS instances. With continuous improvement in threat detection and security features, these services aim to reduce the need for manual intervention and make database management more accessible for IT generalists.

To sum it all up, ensuring the security of databases in the cloud is imperative for organizations across the board. AWS delivers numerous layers of defense and recommends best practices for safeguarding your databases. By leveraging tools such as GuardDuty, you can bolster the security of your AWS databases and protect your most valuable data assets.

References

1. Zippia. "25 Amazing Cloud Adoption Statistics [2023]: Cloud Migration, Computing, And More" Zippia.com. Dec. 19, 2022, https://www.zippia.com/advice/cloud-adoption-statistics/ ↑
2. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html ↑
3. https://cloudbasic.net/white-papers/aws-inter-region-cross-region-vpc-peering-cloudbasic-multiar-sqlserver-disaster-recovery-dr-high-availablity-ha/ ↑
4. “Security and Privacy Controlsfor Information Systems and Organizations” https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf ↑
5. https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html ↑
6. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html ↑
7. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/logs-events-streams-console.html ↑
8. PostgreSQL Audit Extension - https://www.pgaudit.org/ ↑
9. Amazon RDS Performance Insights - https://aws.amazon.com/rds/performance-insights/ ↑
10. Amazon DevOps Guru for RDS - https://aws.amazon.com/devops-guru/features/devops-guru-for-rds/ ↑
11. https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html ↑
12. https://docs.aws.amazon.com/guardduty/latest/ug/findings-rds-protection.html ↑