Data protection in Amazon Aurora DSQL
The shared responsibility model
For data protection purposes, we recommend that you protect credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management. That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
-
Use multi-factor authentication (MFA) with each account.
-
Use SSL/TLS to communicate with resources. We require TLS 1.2 and recommend TLS 1.3.
-
Set up API and user activity logging with AWS CloudTrail. For information about using trails to capture activities, see Working with trails in the User Guide.
-
Use encryption solutions, along with all default security controls within AWS services.
-
Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
We strongly recommend that you never put confidential or sensitive information, such as your customers email addresses, into tags or free-form text fields such as a Name field. This includes when you work with or other using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
Data encryption
Amazon Aurora DSQL provides a highly durable storage infrastructure designed for mission-critical and primary data storage. Data is redundantly stored on multiple devices across multiple facilities in an Aurora DSQL Region.
Encryption in transit
By default, encryption in transit is configured for you. Aurora DSQL uses TLS to encrypt all traffic between your SQL client and Aurora DSQL.
Encryption and signing of data in transit between AWS CLI, SDK, or API clients and Aurora DSQL endpoints:
-
Aurora DSQL provides HTTPS endpoints for encrypting data in transit.
-
To protect the integrity of API requests to Aurora DSQL, API calls must be signed by the caller. Calls are signed by an X.509 certificate or the customer's AWS secret access key according to the Signature Version 4 Signing Process (Sigv4). For more information, see Signature Version 4 Signing Process in the AWS General Reference.
-
Use the AWS CLI or one of the AWS SDKs to make requests to AWS. These tools automatically sign the requests for you with the access key that you specify when you configure the tools.
For encryption at rest, see Encryption at rest in Aurora DSQL.
Inter-network traffic privacy
Connections are protected both between Aurora DSQL and on-premises applications and between Aurora DSQL and other AWS resources within the same AWS Region.
You have two connectivity options between your private network and AWS:
-
An AWS Site-to-Site VPN connection. For more information, see What is AWS Site-to-Site VPN?
-
An AWS Direct Connect connection. For more information, see What is AWS Direct Connect?
You get access to Aurora DSQL through the network by using AWS-published API operations. Clients must support the following:
-
Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
-
Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.