Security with Amazon Aurora MySQL
Security for Amazon Aurora MySQL is managed at three levels:
-
To control who can perform Amazon RDS management actions on Aurora MySQL DB clusters and DB instances, you use AWS Identity and Access Management (IAM). When you connect to AWS using IAM credentials, your AWS account must have IAM policies that grant the permissions required to perform Amazon RDS management operations. For more information, see Identity and access management for Amazon Aurora
If you are using IAM to access the Amazon RDS console, make sure to first sign in to the AWS Management Console with your IAM user credentials. Then go to the Amazon RDS console at https://console.aws.amazon.com/rds/
. -
Make sure to create Aurora MySQL DB clusters in a virtual public cloud (VPC) based on the Amazon VPC service. To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance for Aurora MySQL DB clusters in a VPC, use a VPC security group. You can make these endpoint and port connections by using Transport Layer Security (TLS). In addition, firewall rules at your company can control whether devices running at your company can open connections to a DB instance. For more information on VPCs, see Amazon VPC and Amazon Aurora.
The supported VPC tenancy depends on the DB instance class used by your Aurora MySQL DB clusters. With
default
VPC tenancy, the VPC runs on shared hardware. Withdedicated
VPC tenancy, the VPC runs on a dedicated hardware instance. The burstable performance DB instance classes support default VPC tenancy only. The burstable performance DB instance classes include the db.t2, db.t3, and db.t4g DB instance classes. All other Aurora MySQL DB instance classes support both default and dedicated VPC tenancy.Note
We recommend using the T DB instance classes only for development and test servers, or other non-production servers. For more details on the T instance classes, see Using T instance classes for development and testing.
For more information about instance classes, see Amazon Aurora DB instance classes. For more information about
default
anddedicated
VPC tenancy, see Dedicated instances in the Amazon Elastic Compute Cloud User Guide. -
To authenticate login and permissions for an Amazon Aurora MySQL DB cluster, you can take either of the following approaches, or a combination of them:
-
You can take the same approach as with a standalone instance of MySQL.
Commands such as
CREATE USER
,RENAME USER
,GRANT
,REVOKE
, andSET PASSWORD
work just as they do in on-premises databases, as does directly modifying database schema tables. For more information, see Access control and account managementin the MySQL documentation. -
You can also use IAM database authentication.
With IAM database authentication, you authenticate to your DB cluster by using an IAM user or IAM role and an authentication token. An authentication token is a unique value that is generated using the Signature Version 4 signing process. By using IAM database authentication, you can use the same credentials to control access to your AWS resources and your databases. For more information, see IAM database authentication.
-
Note
For more information, see Security in Amazon Aurora.
In the following sections, see information about user permissions for Aurora MySQL and TLS connections with Aurora MySQL DB clusters.
Master user privileges with Amazon Aurora MySQL
When you create an Amazon Aurora MySQL DB instance, the master user has the default privileges listed in Master user account privileges.
To provide management services for each DB cluster, the admin
and rdsadmin
users are
created when the DB cluster is created. Attempting to drop, rename, change the password, or
change privileges for the rdsadmin
account results in an error.
In Aurora MySQL version 2 DB clusters, the admin
and rdsadmin
users are
created when the DB cluster is created. In Aurora MySQL version 3 DB clusters, the admin
, rdsadmin
, and rds_superuser_role
users are
created.
Important
We strongly recommend that you do not use the master user directly in your applications. Instead, adhere to the best practice of using a database user created with the minimal privileges required for your application.
For management of the Aurora MySQL DB cluster, the standard kill
and
kill_query
commands have been restricted. Instead, use the Amazon RDS commands
rds_kill
and rds_kill_query
to terminate user sessions or
queries on Aurora MySQL DB instances.
Note
Encryption of a database instance and snapshots is not supported for the China (Ningxia) region.
TLS connections to Aurora MySQL DB clusters
Amazon Aurora MySQL DB clusters support Transport Layer Security (TLS) connections from applications using the same process and public key as RDS for MySQL DB instances.
Amazon RDS creates an TLS certificate and installs the certificate on the DB instance when Amazon RDS provisions the instance. These certificates are signed by a certificate authority. The TLS certificate includes the DB instance endpoint as the Common Name (CN) for the TLS certificate to guard against spoofing attacks. As a result, you can only use the DB cluster endpoint to connect to a DB cluster using TLS if your client supports Subject Alternative Names (SAN). Otherwise, you must use the instance endpoint of a writer instance.
For information about downloading certificates, see Using SSL/TLS to encrypt a connection to a DB cluster.
We recommend the AWS JDBC Driver as a client that supports SAN with TLS. For more information about the AWS JDBC Driver and complete instructions for using it, see the
Amazon Web Services (AWS) JDBC Driver GitHub repository
Topics
Requiring a TLS connection to an Aurora MySQL DB cluster
You can require that all user connections to your Aurora MySQL DB cluster use TLS by
using the require_secure_transport
DB cluster parameter. By default,
the require_secure_transport
parameter is set to OFF
. You
can set the require_secure_transport
parameter to ON
to
require TLS for connections to your DB cluster.
You can set the require_secure_transport
parameter value by updating the
DB cluster parameter group for your DB cluster. You don't need to reboot your DB cluster
for the change to take effect. For more information on parameter
groups, see Parameter groups for Amazon Aurora.
Note
The require_secure_transport
parameter is available for Aurora MySQL version 2 and 3.
You can set this parameter in a custom DB cluster parameter group. The parameter isn't available
in DB instance parameter groups.
When the require_secure_transport
parameter is set to ON
for a DB cluster, a
database client can connect to it if it can establish an encrypted connection. Otherwise, an error message similar to the following
is returned to the client:
MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.
TLS versions for Aurora MySQL
Aurora MySQL supports Transport Layer Security (TLS) versions 1.0, 1.1, 1.2, and 1.3. Starting in Aurora MySQL version 3.04.0 and higher, you can use the TLS 1.3 protocol to secure your connections. The following table shows the TLS support for Aurora MySQL versions.
Aurora MySQL version | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | Default |
---|---|---|---|---|---|
Aurora MySQL version 2 |
Supported | Supported |
Supported |
Not supported | All supported TLS versions |
Aurora MySQL version 3 (lower than 3.04.0) |
Supported | Supported | Supported | Not supported | All supported TLS versions |
Aurora MySQL version 3 (3.04.0 and higher) |
Not supported | Not supported | Supported | Supported | All supported TLS versions |
Important
If you're using custom parameter groups for your Aurora MySQL clusters with version 2 and versions lower than 3.04.0, we recommend using TLS 1.2 because TLS 1.0 and 1.1 are less secure. The community edition of MySQL 8.0.26 and Aurora MySQL 3.03 and its minor versions deprecated support for TLS versions 1.1 and 1.0.
The community edition of MySQL 8.0.28 and compatible Aurora MySQL versions 3.04.0 and higher do not support TLS 1.1 and TLS 1.0. If you're using Aurora MySQL version 3.04.0 or higher, do not set the TLS protocol to 1.0 and 1.1 in your custom parameter group.
For Aurora MySQL versions 3.04.0 and higher, the default setting is TLS 1.3 and TLS 1.2.
You can use the tls_version
DB cluster parameter to indicate the
permitted protocol versions. Similar client parameters exist for most client tools
or database drivers. Some older clients might not support newer TLS versions. By
default, the DB cluster attempts to use the highest TLS protocol version allowed by
both the server and client configuration.
Set the tls_version
DB cluster parameter to one of the following values:
-
TLSv1.3
-
TLSv1.2
-
TLSv1.1
-
TLSv1
You can also set the tls_version
parameter as a string of
comma-separated list. If you want to use both TLS 1.2 and TLS 1.0 protocols, the
tls_version
parameter must include all protocols from the lowest to
the highest protocol. In this case, tls_version
is set as:
tls_version=TLSv1,TLSv1.1,TLSv1.2
For information about modifying parameters in a DB cluster parameter group, see Modifying parameters in a DB cluster parameter group in Amazon Aurora. If you use the AWS CLI to modify the tls_version
DB cluster parameter, the ApplyMethod
must be set to pending-reboot
. When the application method is
pending-reboot
, changes to parameters are applied after you stop and restart the DB clusters associated
with the parameter group.
Configuring cipher suites for connections to Aurora MySQL DB clusters
By using configurable cipher suites, you can have more control over the security of your database connections. You can specify a list of cipher suites that you want to allow to secure client TLS connections to your database. With configurable cipher suites, you can control the connection encryption that your database server accepts. Doing this prevents the use of insecure or deprecated ciphers.
Configurable cipher suites are supported in Aurora MySQL version 3 and Aurora MySQL
version 2. To specify the list of permissible TLS 1.2, TLS 1.1, TLS 1.0 ciphers for
encrypting connections, modify the ssl_cipher
cluster parameter. Set
the ssl_cipher
parameter in a cluster parameter group using the
AWS Management Console, the AWS CLI, or the RDS API.
Set the ssl_cipher
parameter to a string of comma-separated cipher
values for your TLS version. For the client application, you can specify the ciphers
to use for encrypted connections by using the --ssl-cipher
option when
connecting to the database. For more about connecting to your database, see
Connecting to an Amazon Aurora MySQL DB cluster.
Starting in Aurora MySQL version 3.04.0 and higher, you can specify TLS 1.3 cipher
suites. To specify the permissible TLS 1.3 cipher suites, modify the
tls_ciphersuites
parameter in your parameter group. TLS 1.3 has
reduced the number of available cipher suites due to changes in the naming
convention that removes the key exchange mechanism and certificate used. Set the
tls_ciphersuites
to a string of comma-separated cipher values for
TLS 1.3.
The following table shows the supported ciphers along with the TLS encryption protocol and valid Aurora MySQL engine versions for each cipher.
Cipher | Encryption protocol | Supported Aurora MySQL versions |
---|---|---|
|
TLS 1.0 | All lower than 3.04.0 for Aurora MySQL version 3 |
|
TLS 1.2 | All lower than 3.04.0 for Aurora MySQL version 3 |
|
TLS 1.2 | All lower than 3.04.0 for Aurora MySQL version 3 |
|
TLS 1.0 | All lower than 3.04.0 for Aurora MySQL version 3 |
|
TLS 1.2 | All lower than 3.04.0 for Aurora MySQL version 3 |
|
TLS 1.2 | All lower than 3.04.0 for Aurora MySQL version 3 |
|
TLS 1.0 | 3.01.0 and higher, 2.11.0 and higher |
|
TLS 1.2 | 3.01.0 and higher, 2.11.0 and higher |
|
TLS 1.2 | 3.01.0 and higher, 2.11.0 and higher |
|
TLS 1.0 | 3.01.0 and higher, 2.11.0 and higher |
|
TLS 1.2 | All lower than 3.04.0 for Aurora MySQL version 3, 2.11.0 and higher |
|
TLS 1.2 | 3.01.0 and higher, 2.11.0 and higher |
|
TLS 1.2 | 3.01.0 and higher, 2.11.0 and higher |
|
TLS 1.2 | 3.01.0 and higher, 2.11.0 and higher |
|
TLS 1.2 | 3.04.0 and higher, 2.11.0 and higher |
|
TLS 1.3 | 3.04.0 and higher |
|
TLS 1.3 | 3.04.0 and higher |
|
TLS 1.3 | 3.04.0 and higher |
Important
DHE-RSA
ciphers are not supported by Aurora MySQL versions starting
from 2.11.0. in Aurora MySQL 2, and starting from 3.04.0 in Aurora MySQL 3.
For information about modifying parameters in a DB cluster parameter group, see
Modifying parameters in a DB cluster parameter group in Amazon Aurora. If you use the
CLI to modify the ssl_cipher
DB cluster parameter, make sure to set the
ApplyMethod
to pending-reboot
. When the application
method is pending-reboot
, changes to parameters are applied after you
stop and restart the DB clusters associated with the parameter group.
You can also use the describe-engine-default-cluster-parameters CLI command to determine
which cipher suites are currently supported for a specific parameter group family.
The following example shows how to get the allowed values for the
ssl_cipher
cluster parameter for Aurora MySQL version 2.
aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-mysql5.7 ...some output truncated... { "ParameterName": "ssl_cipher", "ParameterValue": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384", "Description": "The list of permissible ciphers for connection encryption.", "Source": "system", "ApplyType": "static", "DataType": "list", "AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384", "IsModifiable": true, "SupportedEngineModes": [ "provisioned" ] }, ...some output truncated...
For more information about ciphers, see the ssl_cipher
Encrypting connections to an Aurora MySQL DB cluster
To encrypt connections using the default mysql
client, launch the
mysql client using the --ssl-ca
parameter to reference the public key,
for example:
For MySQL 5.7 and 8.0:
mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com --ssl-ca=
full_path_to_CA_certificate
--ssl-mode=VERIFY_IDENTITY
For MySQL 5.6:
mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com --ssl-ca=
full_path_to_CA_certificate
--ssl-verify-server-cert
Replace full_path_to_CA_certificate
with the full path
to your Certificate Authority (CA) certificate. For information about downloading a
certificate, see Using SSL/TLS to encrypt a connection to a DB
cluster.
You can require TLS connections for specific users accounts. For example, you can
use one of the following statements, depending on your MySQL version, to require TLS
connections on the user account encrypted_user
.
For MySQL 5.7 and 8.0:
ALTER USER 'encrypted_user'@'%' REQUIRE SSL;
For MySQL 5.6:
GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL;
When you use an RDS Proxy, you connect to the proxy endpoint instead of the usual cluster endpoint. You can make SSL/TLS required or optional for connections to the proxy, in the same way as for connections directly to the Aurora DB cluster. For information about using RDS Proxy, see Amazon RDS Proxy for Aurora.
Note
For more information on TLS connections with MySQL, see the MySQL documentation