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.
The screenshot below displays a copy-snapshot operation of a US based RDS datastore to a EU region.
The screenshot below presents a recommended and comprehensive backup retention period configuration from an RDS datastore creation process.
The screenshot below presents recommended network (public) access and default port configuration from an RDS datastore creation process.
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.
The screenshot below presents the recommended authentication configuration to be enforced when creating an RDS datastore.
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.