In my last blog, I explained why building your compute infrastructure from the ground up on maintainable and supported operating systems is a highly recommended best practice. In this post, I explain why you should encrypt your data at rest in the cloud and include a number of best practices to consider. If you build on the type of solid foundation I described in my last blog, you can certainly build an encrypted data storage platform for yourself. But, if you also want to take advantage of economies of scale and the reduced management overhead of operating basic databases on your compute infrastructure (EC2), then Amazon’s Relational Database Service (RDS) is an excellent option. And it can be just as secure — provided you are configuring your network and database instances correctly.
Encryption for RDS
Before addressing networking and user considerations, I need to address encryption for RDS. It is simple and it’s available as a managed service action. But unlike the other steps I describe below, this action will require downtime unless you enable encryption at the time you create any new RDS instances.
There are no performance implications to enabling encryption. In addition to AWS’s assurances of performance SLAs and monitoring the performance of their managed database instances, the Threat Stack team has been running Encrypted RDS instances for thousands of hours over the last year since AWS made RDS encryption available.
So if you are creating a new RDS instance, turn on encryption! It’s free, and it’s easy to do. You just check the box:
Remember the last time you had to set up encryption? It wasn’t this easy, was it? So again, just check the box!!!
Do not make your database public. Just don’t do it! If you have to work with a third party that requires access, configure a VPN and connect it to your database with security groups. This will give you further points of monitoring for your database access, instead of having to deal with a more complicated authentication scheme. Control the network layer, and use security groups to provide access ONLY to the servers that need to be accessed. This is a fairly common best practice. But using security groups to segment your network will greatly reduce lateral attacks on your databases. It is very easy to create and allow access between RDS-specific security groups and the compute security groups you have enabled on your servers with no downtime by simply enabling and testing new secure security groups before disabling more permissive security group configurations.
User Access and Monitoring
Do not allow users to connect to your database directly from outside your VPC because your users’ machines are more vulnerable to social engineering when they are outside your office and/or VPN. It’s a best practice to put connection tools on a jump host and control user access from there because it reduces the endpoints that require monitoring from all user systems to a single system for management and human access to the database. However, because these hosts are also very vulnerable to lateral movement if your network has been breached, it is strongly recommended that you increase user logging on these boxes and perform security monitoring and alerting on the user interactions from, ideally, a much more constrained network access. Using tools like DUO, you could provide 2FA to these data access systems. You can also use tools like the Vault Project’s database secrets backends (available for PostgreSQL, MySQL, and MSSQL, and all compatible with Amazon RDS) to provide a more secure access pattern for developers with self-rotating/expiring credentials. But monitoring user access is of the utmost importance for actual security as well as oft-required compliance standards. Threat Stack is an excellent choice to use to help monitor the access patterns of your database using either CloudTrail auditing, as I will mention below, or monitoring your hosts that have database access and setting up rules to increase the alerting and monitoring of data access user behavior on these hosts. For example, you could alert whenever any psql command is passed on these hosts or when new ports are opened on these servers, or put a fim rule on a .pgpass file to alert whenever the file is read to authorize a session. Locking them down will require the same security patterns your operations teams have developed over their careers, but using Threat Stack to further monitor the user behaviors on the system can help you plan and monitor the security behaviors around your own data access.
ENCRYPT YOUR DATABASES!!! This is very easy to do — but you will have to do it when you create an instance, and you will have to manually migrate your databases to encrypted nodes. If you need to enable encryption on an existing database, you will require some downtime, but Amazon has still made it a very simple process. Encryption is most easily configured on existing databases by taking a snapshot, encrypting that snapshot, and then restoring that snapshot to a new instance that simply has a new endpoint . You can configure user and access management separately, and you should consider this as a standalone operation. If you further need column-specific or encrypted data on transfer, tools such as pgcrypto for PostgreSQL or MySQLs encryption functions are available for each platform. Specifically with Amazon, this encryption option does not affect your performance guarantees with any disk type, but Amazon does recommend Provisioned IOPS for larger workloads to guarantee that you are covered by a specific performance SLA. These mechanisms are simple and use the Amazon KMS to encrypt your data on a file/disk level:
Amazon RDS encrypted instances provide an additional layer of data protection by securing your data from unauthorized access to the underlying storage … All logs, backups, and snapshots are encrypted for an Amazon RDS encrypted instance. A Read Replica of an Amazon RDS encrypted instance is also encrypted using the same key as the master instance.
Using CloudTrail and Threat Stack, you can further monitor AWS console and API activity, and alert on RDS instance events and console logins of users who have administrative access. The event type can be one of the following values:
- AwsApiCall – An API was called.
- AwsServiceEvent – The service generated an event relevant to your trail. For example, this can occur when another account made a call with a resource that you own.
- ConsoleSignin – A user in your account (root, IAM, federated, SAML, or SwitchRole) signed in to the AWS Management Console. 
These events can all be captured, parsed, and alerted on by Threat Stack’s cloud security platform.
Even with all this monitoring available, encrypting your data at rest in the cloud is too easy of an option to pass up. And remember, the combination of security and user monitoring on data access, and administration of an encrypted database, will make every compliance and operations professional happier and more comfortable with storing data in the cloud.