Amazon RDS Security

Encrypt communications between your application and your DB Instance using SSL/TLS. Amazon RDS creates an SSL certificate and installs the certificate on the DB instance when the instance is provisioned. For MySQL, you launch the mysql client using the --ssl_ca parameter to reference the public key in order to encrypt connections. For SQL Server, download the public key and import the certificate into your Windows operating system. RDS for Oracle uses Oracle native network encryption with a DB instance. You simply add the native network encryption option to an option group and associate that option group with the DB instance. Once an encrypted connection is established, data transferred between the DB Instance and your application will be encrypted during transfer. You can also require your DB instance to only accept encrypted connections.

Amazon RDS is integrated with AWS Identity and Access Management (IAM) and provides you the ability to control the actions that your AWS IAM users and groups can take on specific resources (e.g., DB Instances, DB Snapshots, DB Parameter Groups, DB Event Subscriptions, and DB Options Groups). In addition, you can tag your resources and control the actions that your IAM users and groups can take on groups of resources that have the same tag (and tag value). For more information about IAM integration, see the IAM Database Authentication documentation.

You can also tag your Amazon RDS resources and control the actions that your IAM users and groups can take on groups of resources that have the same tag and associated value. For example, you can configure your IAM rules to ensure developers are able to modify "Development" database instances, but only Database Administrators can make changes to "Production" database instances.

When you first create a DB Instance within Amazon RDS, you will create a primary user account, which is used only within the context of Amazon RDS to control access to your DB Instance(s). The primary user account is a native database user account that allows you to log on to your DB Instance with all database privileges. You can specify the primary user name and password you want associated with each DB Instance when you create the DB Instance. Once you have created your DB Instance, you can connect to the database using the primary user credentials. Subsequently, you can create additional user accounts so that you can restrict who can access your DB Instance.

Using Amazon Virtual Private Cloud (VPC), you can isolate your DB Instances in your own virtual network, and connect to your existing IT infrastructure using industry-standard encrypted IPSec VPN.

Amazon VPC enables you to isolate your DB Instances by specifying the IP range you wish to use and connect to your existing IT infrastructure through industry-standard encrypted IPsec VPN. Running Amazon RDS in a VPC enables you to have a DB instance within a private subnet. You can also set up a virtual private gateway that extends your corporate network into your VPC, and allows access to the Amazon RDS DB instance in that VPC. Refer to the Amazon VPC User Guide for more details. DB Instances deployed within an Amazon VPC can be accessed from the Internet or from Amazon EC2 Instances outside the VPC via VPN or bastion hosts that you can launch in your public subnet. To use a bastion host, you will need to set up a public subnet with an EC2 instance that acts as a SSH Bastion. This public subnet must have an Internet gateway and routing rules that allow traffic to be directed via the SSH host, which must then forward requests to the private IP address of your Amazon RDS DB instance. DB Security Groups can be used to help secure DB Instances within an Amazon VPC. In addition, network traffic entering and exiting each subnet can be allowed or denied via network ACLs. All network traffic entering or exiting your Amazon VPC via your IPsec VPN connection can be inspected by your on-premises security infrastructure, including network firewalls and intrusion detection systems.

Beyond external security threats, managed databases need to provide protection against insider risks from database administrators (DBAs). Database Activity Streams, currently supported for Amazon Aurora and Amazon RDS for Oracle, provides a real-time data stream of the database activity in your relational database. When integrated with 3rd party database activity monitoring tools, you can monitor and audit database activity to provide safeguards for your database and meet compliance and regulatory requirements.

Database Activity Streams protects your database from internal threats by implementing a protection model that controls DBA access to the database activity stream. Thus the collection, transmission, storage, and subsequent processing of the database activity stream is beyond the access of the DBAs that manage the database.

The stream is pushed to an Amazon Kinesis data stream that is created on behalf of your database. From Kinesis Data Firehose, the database activity stream can then be consumed by Amazon CloudWatch or by partner applications for compliance management, such as IBM Security Guardium. These partner applications can use the database activity stream information to generate alerts and provide auditing of all activity on your Amazon Aurora database.

You can learn more about using Database Activity Streams for the PostgreSQL- and MySQL-compatible editions of Aurora in the documentation page and for Amazon RDS for Oracle in the documentation page.

Amazon RDS is committed to offering customers a strong compliance framework and advanced tools and security measures that customers can use to evaluate, meet, and demonstrate compliance with applicable legal and regulatory requirements. Customers should review the AWS shared responsibility model and map Amazon RDS responsibilities and customer responsibilities. Customers can also use AWS Artifact to access RDS’ audit reports and conduct their assessment of the control responsibilities.

For more information, please visit the AWS Compliance Page.

Amazon RDS provide best practice guidance by analyzing configuration and usage metrics from your database instances. Recommendations cover areas such as security, encryption, IAM, and VPC. You can browse the available recommendations and perform a recommended action immediately, schedule it for their next maintenance window, or dismiss it entirely.

Amazon VPC lets you create a virtual networking environment in a private, isolated section of the AWS cloud where you can exercise complete control over aspects, such as private IP address ranges, subnets, routing tables, and network gateways. With Amazon VPC, you can define a virtual network topology and customize the network configuration to closely resemble a traditional IP network that you might operate in your own data center.

One way that you can take advantage of VPC is when you want to run a public-facing web application while still maintaining non-publicly accessible backend servers in a private subnet. You can create a public-facing subnet for your webservers that has access to the Internet, and place your backend Amazon RDS DB Instances in a private-facing subnet with no Internet access. For more information about Amazon VPC, refer to the Amazon Virtual Private Cloud User Guide.

If your AWS account was created before 2013-12-04, you may be able to run Amazon RDS in an Amazon Elastic Compute Cloud (EC2)-Classic environment. The basic functionality of Amazon RDS is the same regardless of whether EC2-Classic or EC2-VPC is used. Amazon RDS manages backups, software patching, automatic failure detection, read replicas, and recovery whether your DB Instances are deployed inside or outside a VPC. For more information about the differences between EC2-Classic and EC2-VPC, see the EC2 documentation.

A DB Subnet Group is a collection of subnets that you may want to designate for your Amazon RDS DB Instances in a VPC. Each DB Subnet Group should have at least one subnet for every Availability Zone in a given Region. When creating a DB Instance in VPC, you will need to select a DB Subnet Group. Amazon RDS then uses that DB Subnet Group and your preferred Availability Zone to select a subnet and an IP address within that subnet. Amazon RDS creates and associates an Elastic Network Interface to your DB Instance with that IP address.

Please note that we strongly recommend you use the DNS Name to connect to your DB Instance as the underlying IP address can change (e.g., during failover).

For Multi-AZ deployments, defining a subnet for all Availability Zones in a Region will allow Amazon RDS to create a new standby in another Availability Zone should the need arise. You need to do this even for Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.

For a procedure that walks you through this process, refer to Creating a DB Instance in a VPC in the Amazon RDS User Guide.

Visit the Security Groups section of the Amazon RDS User Guide to learn about the different ways to control access to your DB Instances.

DB Instances deployed within a VPC can be accessed by EC2 Instances deployed in the same VPC. If these EC2 Instances are deployed in a public subnet with associated Elastic IPs, you can access the EC2 Instances via the internet. DB Instances deployed within a VPC can be accessed from the Internet or from EC2 Instances outside the VPC via VPN or bastion hosts that you can launch in your public subnet or using Amazon RDS's Publicly Accessible option:

• To use a bastion host, you will need to set up a public subnet with an EC2 instance that acts as a SSH Bastion.This public subnet must have an internet gateway and routing rules that allow traffic to be directed via the SSH host, which must then forward requests to the private IP address of your Amazon RDS DB instance.
• To use public connectivity, simply create your DB Instances with the Publicly Accessible option set to yes. With Publicly Accessible active, your DB Instances within a VPC will be fully accessible outside your VPC by default. This means you do not need to configure a VPN or bastion host to allow access to your instances. 

You can also set up a VPN Gateway that extends your corporate network into your VPC and allows access to the Amazon RDS DB instance in that VPC. Refer to the Amazon VPC User Guide for more details.

We strongly recommend you use the DNS Name to connect to your DB Instance as the underlying IP address can change (e.g., during failover).

If your DB instance is not in a VPC, you can use the AWS Management Console to easily move your DB instance into a VPC. See the Amazon RDS User Guide for more details. You can also take a snapshot of your DB Instance outside VPC and restore it to VPC by specifying the DB Subnet Group you want to use. Alternatively, you can perform a “Restore to Point in Time” operation as well.

Migration of DB Instances from inside to outside VPC is not supported. For security reasons, a DB Snapshot of a DB Instance inside VPC cannot be restored to outside VPC. The same is true with “Restore to Point in Time” functionality. 

You are responsible for modifying routing tables and networking ACLs in your VPC to ensure that your DB instance is reachable from your client instances in the VPC. For Multi-AZ deployments, after failover, your client EC2 instance and Amazon RDS DB Instance may be in different Availability Zones. You should configure your networking ACLs to ensure that cross-AZ communication is possible.

An existing DB Subnet Group can be updated to add more subnets, either for existing Availability Zones or for new Availability Zones added since the creation of the DB Instance. Removing subnets from an existing DB Subnet Group can cause unavailability for instances if they are running in a particular AZ that gets removed from the subnet group. View the Amazon RDS User Guide for more information.

To begin using Amazon RDS you will need an AWS developer account. If you do not have one prior to signing up for Amazon RDS, you will be prompted to create one when you begin the sign-up process. A primary user account is different from an AWS developer account and used only within the context of Amazon RDS to control access to your DB Instance(s). The primary user account is a native database user account that you can use to connect to your DB Instance. 

You can specify the primary user name and password you want associated with each DB Instance when you create the DB Instance. Once you have created your DB Instance, you can connect to the database using the primary user credentials. Subsequently, you may also want to create additional user accounts so that you can restrict who can access your DB Instance.

For MySQL, the default privileges for the primary user include: create, drop, references, event, alter, delete, index, insert, select, update, create temporary tables, lock tables, trigger, create view, show view, alter routine, create routine, execute, trigger, create user, process, show databases, grant option.

For Oracle, the primary user is granted the "dba" role. The primary user inherits most of the privileges associated with the role. Please refer to the Amazon RDS User Guide for the list of restricted privileges and the corresponding alternatives to perform administrative tasks that may require these privileges.

For SQL Server, a user that creates a database is granted the "db_owner" role. Please refer to the Amazon RDS User Guide for the list of restricted privileges and the corresponding alternatives to perform administrative tasks that may require these privileges.

No, everything works the way you are familiar with when using a relational database you manage yourself.

Yes. You have to intentionally turn on the ability to access your database over the internet by configuring Security Groups. You can authorize access for only the specific IPs, IP ranges, or subnets corresponding to servers in your own data center.

Yes, this option is supported for all Amazon RDS engines. Amazon RDS generates an SSL/TLS certificate for each DB Instance. Once an encrypted connection is established, data transferred between the DB Instance and your application will be encrypted during transfer. While SSL offers security benefits, be aware that SSL/TLS encryption is a compute-intensive operation and will increase the latency of your database connection. SSL/TLS support within Amazon RDS is for encrypting the connection between your application and your DB Instance; it should not be relied on for authenticating the DB Instance itself.

For details on establishing an encrypted connection with Amazon RDS, please visit Amazon RDS MySQL User Guide, MariaDB User Guide, PostgreSQL User Guide, or Oracle User Guide.

Amazon RDS supports encryption at rest for all database engines, using keys you manage using AWS Key Management Service (KMS). On a database instance running with Amazon RDS encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, read replicas, and snapshots. Encryption and decryption are handled transparently. For more information about the use of KMS with Amazon RDS, see the Amazon RDS User Guide.

You can also add encryption to a previously unencrypted DB instance or DB cluster by creating a DB snapshot and then creating a copy of that snapshot and specifying a KMS encryption key. You can then restore an encrypted DB instance or DB cluster from the encrypted snapshot.

Amazon RDS for Oracle and SQL Server support those engines' Transparent Data Encryption (TDE) technologies. For more information, see the Amazon RDS User Guide for Oracle and SQL Server.

No, an Oracle instance on Amazon RDS cannot be integrated with AWS CloudHSM. To use transparent data encryption (TDE) with AWS CloudHSM, the Oracle database needs to be installed on Amazon EC2.

You can control the actions that your AWS IAM users and groups can take on Amazon RDS resources. You do this by referencing the Amazon RDS resources in the AWS IAM policies that you apply to your users and groups. Amazon RDS resources that can be referenced in an AWS IAM policy include DB instances, DB snapshots, read replicas, DB security groups, DB option groups, DB parameter groups, event subscriptions, and DB subnet groups. 

In addition, you can tag these resources to add additional metadata to your resources. By using tagging, you can categorize your resources (e.g. "Development" DB instances, "Production" DB instances, and "Test" DB instances), and write AWS IAM policies that list the permissions (i.e. actions) that can be taken on resources with the same tags. For more information, refer to Tagging Amazon RDS Resources.

Yes. AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The AWS API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing. 

Yes, all Amazon RDS database engines are HIPAA-eligible, so you can use them to build HIPAA-compliant applications and store healthcare-related information, including protected health information (PHI) under an executed Business Associate Agreement (BAA) with AWS.

If you already have an executed BAA, no action is necessary to begin using these services in the account(s) covered by your BAA. If you do not have an executed BAA with AWS, or have any other questions about HIPAA-compliant applications on AWS, please contact
your account manager.