Amazon’s Relational Database Service (AWS RDS) allows you to offload the responsibility of managing a database, but it also comes with the risk of another external dependency. Fortunately, AWS provides some tools and settings to help with this.
When you combine your existing data security policy with the AWS tooling and the advice in this article, you’ll be well on your way to managing risk more effectively. Let’s dive in with 15 AWS RDS data security best practices.
Encrypt RDS databases
AWS allows you to encrypt RDS databases when they are created. It’s important to make this decision at creation, as encrypting existing databases is not a simple process. There are workarounds, but RDS does not allow you to toggle encryption on or off for an existing database. You also can’t create encrypted backups of unencrypted databases.
Database-level encryption, or encryption at rest, protects sensitive data from leaks and breaches by ensuring that the data cannot be read by an unauthorized party.
Monitor unsecure database connections
AWS RDS allows you to connect securely via SSL/TSL. To do so, make sure your applications are connecting with the AWS provided certificates. You can find the global bundle, or the region specific certificates, in the RDS documentation.
Note that different database engines will require different configurations, so if your applications utilize RDS, but different database types, you’ll need to configure in transit encryption for each.
Enable KMS
When you encrypt an RDS database, the easiest way to do so is using AWS’ built in Key Management Service (AWS KMS). KMS will handle the generation, storage, and even cycling of encryption keys. These keys are used not only to encrypt databases themselves, but also their snapshots and backups.
Unless you already rely on a dedicated key management system, it’s best to stick with the one built into AWS.
Check for new data processing
Even after a database has been secured, it is important to monitor any new additions or changes to it’s schema. This can be done at the application level via scanning (static code analysis) of the application code itself or schema analysis of the schema files. It can also be done in AWS by monitoring database changes with AWS CloudTrail.
Audit database access rights
A well managed Identity and Access Management (IAM) setup is crucial to using AWS securely. Ensure that only the necessary applications and services have access to each database. Avoid providing mixed access rights—such as allowing a single user to access all databases—unless it is necessary. Limited, granular IAM controls help avoid accidentally leaking data.
In general, start with minimal access rights and add additional permissions as needed. Rights should be reassessed once development on a feature is complete to ensure no “temporary” changes were accidentally carried over to the final user role.
Ensure proper AWS regions are used
While more of a data privacy issue than specifically a security concern, ensuring that regional AWS usage matches your internal data policies will avoid any regulatory concerns in the future. Especially when concerning GDPR and other regulations that strictly define where data can be stored and transmitted.
This can be harder to keep track of manually, so it’s best to carefully define these policies at the beginning when building features, or use an automated tool that can match database regions to the applications that access them.
Ensure regular backups exist
Enable regular backups and/or snapshots of your databases. It can be valuable to also encrypt these backups, even if the databases themselves are not encrypted. In some scenarios, AWS will now allow you to easily encrypt a snapshot of an unencrypted database, so keep that in mind when creating new services.
Consider your data retention policies when generating backups to make sure you aren’t storing user data longer than your policies indicate.
Ensure backups and snapshots are encrypted at rest
As mentioned earlier, AWS does not allow encrypted backups or snapshots of unencrypted databases, so make sure the database is encrypted in order to generate encrypted backups and snapshots. Backups are full copies of the data, while snapshots can be thought of as smaller, versioning steps.
Consider your data security policies and ensure that data in backups receives the same level of protection as data in the database.
Avoid cross-region backups
Just as with storing data in the correct region in accordance with compliance and regulatory requirements, make sure your backups are also meeting those requirements.
It can be common for an organization to think of backups differently than the data itself. This leads to problems where data accidentally crosses borders.
Monitor database access
Once you’ve set the appropriate IAM roles, mentioned earlier in this list, it is good practice to monitor access to RDS databases. This can be done with AWS CloudTrail.
Monitoring access allows you to confirm that only the required users and applications are interacting with the database. It’s an easy way to see if an unexpected user account is in use, or if a new account was created without going through the correct approval process. This can be a precursor to a data leak or breach.
Monitor RDS configuration changes
Configuration changes are an overlooked aspect in database security, as services are “set and forget” as long as they are working. CloudTrail can be configured to watch for configuration change events and other changes to your databases.
Prune unused RDS instances
As your application changes over time, you may end up with unused or developer-facing instances of RDS databases. It’s good to regularly check that these are necessary, and audit whether they are in compliance with your current data security policies.
Avoid unrestricted access groups
We mentioned IAM users earlier, but they are worth mentioning again. In addition to setting individual rights for specific users and services, make sure to avoid setting up super accounts when you can avoid it. Unrestricted access to services creates a massive risk, especially if that IAM user manages anything programmatically via an app or service.
Enhance your notifications with GuardDuty
We’ve mentioned CloudTrails a few times, but you can take it a step further by combining it with GuardDuty. GuardDuty lets you set “detectors” to look for unexpected or suspicious events from a variety of data sources. This way you don’t need to directly monitor CloudTrail or other logs.
Monitor policy adherence regularly
All of this advice only serves you well if it becomes a regular part of your data security posture. Many organizations still put data security at the end of the development process. Instead, shift it left by bringing data security into the modern DevSecOps workflow. Work with your developers, without getting in their way, to monitor and mitigate risks right in the software development lifecycle.
