Relational databases have become the option of choice for organizations wishing to streamline and scale the use, storage and retrieval of data. Many organizations choose AWS Relational Database Service (RDS) to forego the resource-intensive tasks related to database administration including management and continuous oversight. RDS is a fully managed service that 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 data grows.
That 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, 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 six most common RDS misconfigurations related to security and compliance that DevSecOps teams should be aware of to secure their data stores and organizational assets.
Broken Geo-Trust (aka Data Sovereignty): RDS provides the convenient option to distribute 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 storing backups and snapshots in 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-U.S. 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 U.S.-based RDS datastore to an EU region.
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 data loss or a ransomware attack. Clear guidelines and open communication between DevOps teams and compliance leads is the first step toward a healthy environment.
The screenshot below presents a recommended and comprehensive backup retention period configuration from an RDS datastore creation process.
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.
Weak Encryption: Encryption of sensitive data—both at rest and in transit—is a necessary security baseline 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.
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 use 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.
Incomplete Audits: Visibility cannot be considered a point-in-time activity. Monitoring of access and use 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 leakage of sensitive data from RDS to audit logs increases the risk.Â
The screenshot below presents the recommended audit and log configurations when creating an RDS datastore.
Misconfigurations and single points of failure in 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 minimum required to protect your environment. DevSecOps teams are encouraged to work closely with their compliance leads to ensure that customer data is secured; 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.Â
