DeepDefence security

Securing RDS essentially involves protecting database server (infrastructure) and data. Prevent unauthorized access and recover in the event of a breach. Following are some of the steps to achieve:

1. Restrict access to RDS database

Restrict the users, applications and AWS resources that connect to the RDS instance.

Authentication & Passwords:

  • Create the RDS database instance with a complex master username and password. Remember, the master username does not need to be ‘admin’. Never use the master user in your applications.
  • For each of the databases created in the DB server, create separate users with minimal privileges with access to only that database.
  • Create RDS instance using the option ‘Password and IAM database authentication’, and use IAM authentication for connecting to database. This way, there is no need to manage passwords. For connecting to MySql database from SQL Workbench/J, steps are available at this AWS link. For connecting to RDS db from application code, AWS instructions are here.
  • From your application running in EC2, use instance profile to connect to db instance, without the need of a password.
  • If you must use password authentication (not EC2 instance profile), don’t save database credentials in the application code. Instead, store them in AWS secrets manager and retrieve them from it.
  • Protect all ‘production’ RDS instances from deletion (accidentally or maliciously) with proper IAM policies. See this post for the policy.

2. Network security

Private Subnets & Security groups

  • Create the RDS db instance in the private subnet of a VPC and don’t enable ‘Public access’.
  • Create a security group (e.g. rds-sg) and attach to the RDS instance. Allow this security group to accept inbound traffic on specific port (e.g. port 3306 for MySQL) from your application running on EC2 with a security group. For the RDS security group created (rds-sg), remove all outbound rules.
  • You may have to connect to this RDS database server for development purpose (e.g. from MySql workbench your local machine). For this, create a bastion EC2 host (also called jump host) in public subnet of the VPC and connect to RDS from this bastion host. Details are given in this AWS blog. A more costly option is to use AWS Client VPN or Direct Connect, which does not require a bastion host.
  • Configure the network ACL inbound rules of the subnet to allow only RDS traffic and deny everything else.

3. Encryption

  • Enable data encryption while creating the RDS instance.
  • While connecting to RDS instance from your application or local computer (such as MySql WorkBench), use SSL to encrypt the connection. You can force database users to use SSL using below command: ALTER USER ‘john’@’%’ REQUIRE SSL;
  • Enable automated backups. Also, enable backups in another AWS region which can be useful during disaster recovery.

4. Monitoring and Alerts

Set up monitoring controls on the RDS instance to get alerts in case of breaches, and also help in audit.

  • Enable AWS CloudTrail to record the changes made to RDS instance, either from AWS console or using AWS APIs.
  • Enable ‘audit logs’ for the RDS instance where the logs are available in CloudWatch. The steps to turn on audit logs are given at this AWS blog. You can get alert notifications when someone to your RDS instance.
    • For example, if your VPC address range is 172.31.0.0/16, create a filter with expression given below, for creating the alarm. This finds the audit log events which are new connections, (not triggered from ‘localhost’ which is local to AWS RDS) and not from any of the VPC resources such as EC2.
CONNECT -localhost -172.31