# Protecting data in your Amazon Neptune database Protecting data in Neptune databases The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon Neptune. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*. For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). 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 AWS 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 CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*. + Use AWS 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. + If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). 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 Neptune or other AWS services 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. **Important** TLS 1.3 is only supported for Neptune engine version 1.3.2.0 and up. You use AWS published API calls to manage Neptune through the network. Clients must support Transport Layer Security (TLS) 1.2 or later using strong cipher suites, as described in [Encrypting connects to Neptune databases](security-ssl.md). Most modern systems such as Java 7 and later support these modes. The following sections describe further how Neptune data is protected. **Topics** + [ # Securing your Amazon Neptune database with Amazon VPC ](security-vpc.md) + [ # Encrypting connections to your Amazon Neptune database with SSL/HTTPS ](security-ssl.md) + [ # Encrypting data at rest in your Amazon Neptune database ](encrypt.md) # Securing your Amazon Neptune database with Amazon VPC Securing Neptune databases with Amazon VPC An Amazon Neptune DB cluster can *only* be created in an Amazon Virtual Private Cloud (Amazon VPC), and its endpoints are accessible within that VPC, usually from an Amazon Elastic Compute Cloud (Amazon EC2) instance running in that VPC. Alternatively, it can be accessed using a public endpoint. For more information on public endpoints, see [Neptune public endpoints](neptune-public-endpoints.md). You can secure your Neptune data by limiting access to the VPC where your Neptune DB cluster is located, as described in [Connecting to an Amazon Neptune cluster](get-started-connecting.md). # Encrypting connections to your Amazon Neptune database with SSL/HTTPS Encrypting connects to Neptune databasesAmazon Neptune SSL Support Neptune now supports SSL connections. Amazon Neptune only allows Secure Sockets Layer (SSL) connections through HTTPS to any instance or cluster endpoint. Neptune requires at least TLS version 1.2, using the following strong cipher suites: + `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` + `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` + `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` + `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` Starting with Neptune engine version 1.3.2.0, Neptune supports TLS version 1.3 using the following cipher suites: + TLS\$1AES\$1128\$1GCM\$1SHA256 + TLS\$1AES\$1256\$1GCM\$1SHA384 Even where HTTP connections are allowed in earlier engine versions, any DB cluster that uses a new DB cluster parameter group is required to use SSL by default. *To protect your data, Neptune endpoints in engine version `1.0.4.0` and above only support HTTPS requests.* See [Using the HTTP REST endpoint to connect to a Neptune DB instance](access-graph-sparql-http-rest.md) for more information. Neptune automatically provides SSL certificates for your Neptune DB instances. You don't need to request any certificates. The certificates are provided when you create a new instance. Neptune assigns a single wildcard SSL certificate to the instances in your account for each AWS Region. The certificate provides entries for the cluster endpoints, cluster read-only endpoints, and instance endpoints. **Certificate Details** The following entries are included in the provided certificate: + Cluster endpoint — `*.cluster-a1b2c3d4wxyz.region.neptune.amazonaws.com` + Read-only endpoint — `*.cluster-ro-a1b2c3d4wxyz.region.neptune.amazonaws.com` + Instance endpoints — `*.a1b2c3d4wxyz.region.neptune.amazonaws.com` Only the entries listed here are supported. **Proxy Connections** The certificates support only the hostnames that are listed in the previous section. If you are using a load balancer or a proxy server (such as HAProxy), you must use SSL termination and have your own SSL certificate on the proxy server. SSL passthrough doesn't work because the provided SSL certificates don't match the proxy server hostname. **Root CA Certificates** The certificates for Neptune instances are normally validated using the local trust store of the operating system or SDK (such as the Java SDK). If you need to provide a root certificate manually, you can download the [Amazon Root CA certificate](https://www.amazontrust.com/repository/AmazonRootCA1.pem) in PEM format from the [Amazon Trust Services Policy Repository](https://www.amazontrust.com/repository/). **More Information** For more information about connecting to Neptune endpoints with SSL, see [Set up the Gremlin console to connect to a Neptune DB instance](access-graph-gremlin-console.md) and [Using the HTTP REST endpoint to connect to a Neptune DB instance](access-graph-sparql-http-rest.md). # Encrypting data at rest in your Amazon Neptune database Encrypting data at Rest Neptune encrypted instances provide an additional layer of data protection by helping to secure your data from unauthorized access to the underlying storage. You can use Neptune encryption to increase data protection of your applications that are deployed in the cloud. You can also use it to fulfill compliance requirements for data-at-rest encryption. To manage the keys used for encrypting and decrypting your Neptune resources, you use [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/). AWS KMS combines secure, highly available hardware and software to provide a key management system scaled for the cloud. Using AWS KMS, you can create encryption keys and define the policies that control how these keys can be used. AWS KMS supports AWS CloudTrail, so you can audit key usage to verify that keys are being used appropriately. You can use your AWS KMS keys in combination with Neptune and supported AWS services such as Amazon Simple Storage Service (Amazon S3), Amazon Elastic Block Store (Amazon EBS), and Amazon Redshift. For a list of services that support AWS KMS, see [How AWS Services Use AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services.html) in the *AWS Key Management Service Developer Guide*. All logs, backups, and snapshots are encrypted for a Neptune encrypted instance. ## Enabling Encryption for a Neptune DB Instance Enabling Encryption To enable encryption for a new Neptune DB instance, choose **Yes** in the **Enable encryption** section on the Neptune console. For information about creating a Neptune DB instance, see [Creating an Amazon Neptune cluster](get-started-create-cluster.md). When you create an encrypted Neptune DB instance, you can also supply the AWS KMS key identifier for your encryption key. If you don't specify an AWS KMS key identifier, Neptune uses your default Amazon RDS encryption key (`aws/rds`) for your new Neptune DB instance. AWS KMS creates your default encryption key for Neptune for your AWS account. Your AWS account has a different default encryption key for each AWS Region. After you create an encrypted Neptune DB instance, you can't change the encryption key for that instance. So, be sure to determine your encryption key requirements before you create your encrypted Neptune DB instance. You can use the Amazon Resource Name (ARN) of a key from another account to encrypt a Neptune DB instance. If you create a Neptune DB instance with the same AWS account that owns the AWS KMS encryption key that's used to encrypt that new Neptune DB instance, the AWS KMS key ID that you pass can be the AWS KMS key alias instead of the key's ARN. **Important** If Neptune loses access to the encryption key for a Neptune DB instance—for example, when Neptune access to a key is revoked—the encrypted DB instance is placed into a terminal state and can only be restored from a backup. We strongly recommend that you always enable backups for encrypted NeptuneDB instances to guard against the loss of encrypted data in your databases. ## Key permissions needed when enabling encryption Key permissions The IAM user or role creating an encrypted Neptune DB instance must have at least the following permissions for the KMS key: + `"kms:Encrypt"` + `"kms:Decrypt"` + `"kms:GenerateDataKey"` + `"kms:ReEncryptTo"` + `"kms:GenerateDataKeyWithoutPlaintext"` + `"kms:CreateGrant"` + `"kms:ReEncryptFrom"` + `"kms:DescribeKey"` Here is an example of a key policy that includes the necessary permissions: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "key-consolepolicy-3", "Statement": [ { "Sid": "Allow use of the key for Neptune", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/NeptuneFullAccess" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey", "kms:ReEncryptTo", "kms:GenerateDataKeyWithoutPlaintext", "kms:CreateGrant", "kms:ReEncryptFrom", "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "rds.us-east-1.amazonaws.com" } } }, { "Sid": "Deny use of the key for non Neptune", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:role/NeptuneFullAccess" }, "Action": [ "kms:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "kms:ViaService": "rds.us-east-1.amazonaws.com" } } } ] } ``` ------ + The first statement provides access to all the required AWS KMS APIs for this role, scoped down to the RDS Service Principal. + The second statement tightens the security more by enforcing that this key is not usable by this role for any other AWS service. You could also scope `createGrant` permissions down further by adding: ``` "Condition": { "Bool": { "kms:GrantIsForAWSResource": true } } ``` ## Limitations of Neptune Encryption Limitations The following limitations exist for encrypting Neptune clusters: + You cannot convert an unencrypted DB cluster to an encrypted one. However, you can restore an unencrypted DB cluster snapshot to an encrypted DB cluster. To do this, specify a KMS encryption key when you restore from the unencrypted DB cluster snapshot. + You cannot convert an unencrypted DB instance to an encrypted one. You can only enable encryption for a DB instance when you create it. + Also, DB instances that are encrypted can't be modified to disable encryption. + You can't have an encrypted Read Replica of an unencrypted DB instance, or an unencrypted Read Replica of an encrypted DB instance. + Encrypted Read Replicas must be encrypted with the same key as the source DB instance.