Common RDS Misconfigurations That Can Damage Your Cloud Data Security Posture

Relational databases have become the option of choice for organizations wishing to streamline and scale their use, storing and retrieving of data. Many organizations choose AWS Relational Database Service (RDS) in order to forego the resource-intensive tasks related to database administration including management and continuous oversight. A fully managed service, RDS simplifies and automates these processes making it easy to set up, operate and manage relational databases in the cloud, including MySQL, PostgreSQL, MariaDB or Aurora, and their various time-consuming activities. Reducing costs and automating processes makes significant business sense and allows organizations to focus on performance, scalability and cost-effectiveness as their data grows. 

That being said, AWS is not the owner or the party responsible for securing your data - this duty remains in the hands of the organization. As the cloud provider in this case, AWS does offer an impressive suite of security measures for protecting the infrastructure that runs its cloud services, including access controls, database snapshots and encryption. Their policies, however, clearly state that safeguarding data is within the responsibility of the organization and as the moderator of your environment, you will be accountable for what occurs within it. 

The following are the 6 most common RDS misconfigurations related to security and compliance, that DevSecOps teams should be aware of in order to secure their data stores and organizational assets.  

‍

1. Broken Geo-Trust (aka Data Sovereignty): RDS provides the convenient option of distributing data across various AWS Regions. There are various benefits to this data migration, including minimizing latency, disaster recovery capabilities and scaling operations. However, the security and governance risks of cross-geo replication may significantly outweigh these benefits. A common misconfiguration includes migrating replicas or store backups and snapshots to another location. When sensitive data travels and is stored in another geographic location, the organization may be at risk of violating international compliance requirements such as Schrems II (for EU to US data transfer). Additionally, data traveling to various locations may not be visible to security teams or managed by DevOps teams - without a continuously updated inventory, data will spread unobstructed and ungoverned. 

‍

The screenshot below displays a copy-snapshot operation of a US based RDS datastore to a EU region.

‍

‍

2. Inadequate Retention Periods: AWS allows organizations to retain database instances for a specific period of time, as configured by the user. A common misconfiguration of this feature is the existence of unmonitored standalone snapshots, short-lived backups and a failure to permanently delete records. Organizations that retain records for a long period of time may be in breach of their GDPR obligations, whereas short-lived backups may jeopardize the organization’s ability to recover critical data in case of an incident such as data loss or a ransomware attack. Clear guidelines and open communication between DevOps teams and compliance leads is the first step in a healthy environment.

‍

The screenshot below presents a recommended and comprehensive backup retention period configuration from an RDS datastore creation process.

‍

3. Exposed Resources (Network Access): Publicly accessible database ports and RDS instances are a lucrative configuration loophole for malicious actors. Common misconfigurations may cause RDS database snapshots to be publicly accessible, thus providing unauthenticated users with privileges to access and abuse it through brute-force attacks, known CVEs and DDoS attacks - thereby exposing sensitive data. This risk will also impact the organization’s ability to comply with international regulatory requirements and should be a high priority configuration when creating and maintaining such resources.

‍

The screenshot below presents recommended network (public) access and default port configuration from an RDS datastore creation process.

‍

‍

4. Weak Encryption: Encryption of sensitive data, both at rest and in-transit is a necessary security baseline in order to ensure the integrity and confidentiality of organizational data and make it inaccessible to unauthorized users. Common encryption misconfigurations may include implementing inadequate encryption for communication channels such as TLSv1.2 (and higher), weak cipher suites or untrusted CA, which may lead to a false sense of security. For data at rest, another common misstep is a lack of key rotation or exposure of the encryption key to unauthorized entities.

‍

The screenshot below presents the recommended basic encryption-at-rest configuration to be enforced when creating an RDS datastore.

‍

‍

The screenshot below presents recommended basic encryption-in-transit configuration to be enforced when creating an RDS datastore.

‍

5. Improper Authentication & Authorization (RBAC): A cornerstone of adequate data security hygiene is ensuring that access is only associated with a unique account based on the principle of least privilege, using strong identification methods with appropriate justification. With RDS, users may not utilize IAM accounts, provide over-privileged access and permissions to either the main instance or to backups, and refrain from implementing a user-access quarterly review.

‍

The screenshot below presents the recommended authentication configuration to be enforced when creating an RDS datastore.

‍

‍

6. Incomplete Audits: Visibility cannot be considered a point-in-time activity. Monitoring of access and usage of sensitive data is an essential component of tracking organizational assets, and will provide crucial information in case of an incident or potential data breach. Incomplete or misplaced audit records including login/logout events, short-lived audits or a leakage of sensitive data from RDS to audit logs, increase the risk. 

‍

The screenshot below presents the recommended Audit and Log configurations to be enabled when creating an RDS datastore.

‍

‍

Misconfigurations and single points of failure in these cloud environments may be unavoidable for all organizations, especially those operating at scale, due to knowledge gaps, high velocity of data and changes, and a lack of visibility as the amount of data increases. While the security baseline may be covered by RDS configurations, these are only the foundations for protecting your environment. DevSecOps teams are encouraged to work closely with their compliance leads, ensuring that customer data is secured while leveraging RDS for its benefits is a complex and entirely more substantial responsibility. Organizations must view their data as an inherent part of their internal assets. As its owner, they should create appropriate ecosystems that allow continuous oversight and monitoring of the data, gaps that may arise, and - most importantly - the controls in place to secure it. 

‍

How Eureka Can Help

Eureka’s Cloud Data Security Posture Management platform goes well beyond the common cloud security baselines, taking a proactive approach to informing security and compliance teams about existing and shadow risk, and suggesting mitigation approaches. By offering the capabilities required for full cloud data storage security and compliance without requiring deep expertise or manual overhead, Eureka ensures that risky misconfigurations are discovered, assessed and remediated using a single solution across any (or several) cloud providers.

‍