# Data protection in Amazon Keyspaces The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon Keyspaces (for Apache Cassandra). 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 Amazon Keyspaces 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. **Topics** + [Encryption at rest in Amazon Keyspaces](EncryptionAtRest.md) + [Encryption in transit in Amazon Keyspaces](encryption-in-transit.md) + [Internetwork traffic privacy in Amazon Keyspaces](inter-network-traffic-privacy.md) # Encryption at rest in Amazon Keyspaces Amazon Keyspaces (for Apache Cassandra) *encryption at rest* provides enhanced security by encrypting all your data at rest using encryption keys stored in [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/). This functionality helps reduce the operational burden and complexity involved in protecting sensitive data. With encryption at rest, you can build security-sensitive applications that meet strict compliance and regulatory requirements for data protection. Amazon Keyspaces encryption at rest encrypts your data using 256-bit Advanced Encryption Standard (AES-256). This helps secure your data from unauthorized access to the underlying storage. Amazon Keyspaces encrypts and decrypts the data in tables and streams transparently. Amazon Keyspaces uses envelope encryption and a key hierarchy to protect data encryption keys. It integrates with AWS KMS for storing and managing the root encryption key. For more information about the encryption key hierarchy, see [Encryption at rest: How it works in Amazon Keyspaces](encryption.howitworks.md). For more information about AWS KMS concepts like envelope encryption, see [AWS KMS management service concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) in the *AWS Key Management Service Developer Guide*. When creating a new table, you can choose one of the following *AWS KMS keys (KMS keys)*: + AWS owned key – This is the default encryption type. The key is owned by Amazon Keyspaces (no additional charge). + Customer managed key – This key is stored in your account and is created, owned, and managed by you. You have full control over the customer managed key (AWS KMS charges apply). Amazon Keyspaces automatically encrypts change data capture (CDC) streams with the same key as the underlying table. For more information about CDC, see [Working with change data capture (CDC) streams in Amazon Keyspaces](cdc.md). You can switch between the AWS owned key and the customer managed key at any given time. You can specify a customer managed key when you create a new table or change the KMS key of an existing table by using the console or programmatically using CQL statements. To learn how, see [Encryption at rest: How to use customer managed keys to encrypt tables in Amazon Keyspaces](encryption.customermanaged.md). Encryption at rest using the default option of AWS owned keys is offered at no additional charge. However, AWS KMS charges apply for customer managed keys. For more information about pricing, see [AWS KMS pricing](https://aws.amazon.com/kms/pricing). Amazon Keyspaces encryption at rest is available in all AWS Regions, including the AWS China (Beijing) and AWS China (Ningxia) Regions. For more information, see [Encryption at rest: How it works in Amazon Keyspaces](encryption.howitworks.md). **Topics** + [Encryption at rest: How it works in Amazon Keyspaces](encryption.howitworks.md) + [Encryption at rest: How to use customer managed keys to encrypt tables in Amazon Keyspaces](encryption.customermanaged.md) # Encryption at rest: How it works in Amazon Keyspaces Amazon Keyspaces (for Apache Cassandra) *encryption at rest* encrypts your data using the 256-bit Advanced Encryption Standard (AES-256). This helps secure your data from unauthorized access to the underlying storage. All customer data in Amazon Keyspaces tables is encrypted at rest by default, and server-side encryption is transparent, which means that changes to applications aren't required. Encryption at rest integrates with AWS Key Management Service (AWS KMS) for managing the encryption key that is used to encrypt your tables. When creating a new table or updating an existing table, you can choose one of the following *AWS KMS key* options: + AWS owned key – This is the default encryption type. The key is owned by Amazon Keyspaces (no additional charge). + Customer managed key – This key is stored in your account and is created, owned, and managed by you. You have full control over the customer managed key (AWS KMS charges apply). **AWS KMS key (KMS key)** Encryption at rest protects all your Amazon Keyspaces data with a AWS KMS key. By default, Amazon Keyspaces uses an [AWS owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk), a multi-tenant encryption key that is created and managed in an Amazon Keyspaces service account. However, you can encrypt your Amazon Keyspaces tables using a [customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in your AWS account. You can select a different KMS key for each table in a keyspace. The KMS key you select for a table is also used to encrypt all its metadata and restorable backups. You select the KMS key for a table when you create or update the table. You can change the KMS key for a table at any time, either in the Amazon Keyspaces console or by using the [ALTER TABLE](cql.ddl.keyspace.md#cql.ddl.keyspace.alter) statement. The process of switching KMS keys is seamless, and doesn't require downtime or cause service degradation. **Key hierarchy** Amazon Keyspaces uses a key hierarchy to encrypt data. In this key hierarchy, the KMS key is the root key. It's used to encrypt and decrypt the Amazon Keyspaces table encryption key. The table encryption key is used to encrypt the encryption keys used internally by Amazon Keyspaces to encrypt and decrypt data when performing read and write operations. With the encryption key hierarchy, you can make changes to the KMS key without having to reencrypt data or impacting applications and ongoing data operations. ![\[Key hierarchy showing the root key, the table encryption key, and the data encryption key used for encryption at rest.\]](http://docs.aws.amazon.com/keyspaces/latest/devguide/images/keyspaces_encryption.png) **Table key** The Amazon Keyspaces table key is used as a key encryption key. Amazon Keyspaces uses the table key to protect the internal data encryption keys that are used to encrypt the data stored in tables, log files, and restorable backups. Amazon Keyspaces generates a unique data encryption key for each underlying structure in a table. However, multiple table rows might be protected by the same data encryption key. When you first set the KMS key to a customer managed key, AWS KMS generates a *data key*. The AWS KMS data key refers to the table key in Amazon Keyspaces. When you access an encrypted table, Amazon Keyspaces sends a request to AWS KMS to use the KMS key to decrypt the table key. Then, it uses the plaintext table key to decrypt the Amazon Keyspaces data encryption keys, and it uses the plaintext data encryption keys to decrypt table data. Amazon Keyspaces uses and stores the table key and data encryption keys outside of AWS KMS. It protects all keys with [Advanced Encryption Standard](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) (AES) encryption and 256-bit encryption keys. Then, it stores the encrypted keys with the encrypted data so that they're available to decrypt the table data on demand. **Table key caching** To avoid calling AWS KMS for every Amazon Keyspaces operation, Amazon Keyspaces caches the plaintext table keys for each connection in memory. If Amazon Keyspaces gets a request for the cached table key after five minutes of inactivity, it sends a new request to AWS KMS to decrypt the table key. This call captures any changes made to the access policies of the KMS key in AWS KMS or AWS Identity and Access Management (IAM) since the last request to decrypt the table key. **Envelope encryption** If you change the customer managed key for your table, Amazon Keyspaces generates a new table key. Then, it uses the new table key to reencrypt the data encryption keys. It also uses the new table key to encrypt previous table keys that are used to protect restorable backups. This process is called envelope encryption. This ensures that you can access restorable backups even if you rotate the customer managed key. For more information about envelope encryption, see [Envelope Encryption](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) in the *AWS Key Management Service Developer Guide*. **Topics** + [AWS owned keys](#keyspaces-owned) + [Customer managed keys](#customer-managed) + [Encryption at rest usage notes](#encryption.usagenotes) ## AWS owned keys AWS owned keys aren't stored in your AWS account. They are part of a collection of KMS keys that AWS owns and manages for use in multiple AWS accounts. AWS services can use AWS owned keys to protect your data. You can't view, manage, or use AWS owned keys, or audit their use. However, you don't need to do any work or change any programs to protect the keys that encrypt your data. You aren't charged a monthly fee or a usage fee for use of AWS owned keys, and they don't count against AWS KMS quotas for your account. ## Customer managed keys Customer managed keys are keys in your AWS account that you create, own, and manage. You have full control over these KMS keys. Use a customer managed key to get the following features: + You create and manage the customer managed key, including setting and maintaining the [key policies](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html), [IAM policies](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html), and [grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) to control access to the customer managed key. You can [enable and disable](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) the customer managed key, enable and disable [automatic key rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html), and [schedule the customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html) for deletion when it is no longer in use. You can create tags and aliases for the customer managed keys you manage. + You can use a customer managed key with [imported key material](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html) or a customer managed key in a [custom key store](https://docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html) that you own and manage. + You can use AWS CloudTrail and Amazon CloudWatch Logs to track the requests that Amazon Keyspaces sends to AWS KMS on your behalf. For more information, see [Step 6: Configure monitoring with AWS CloudTrail](encryption.customermanaged.md#encryption-cmk-trail). Customer managed keys [incur a charge](https://aws.amazon.com/kms/pricing/) for each API call, and AWS KMS quotas apply to these KMS keys. For more information, see [AWS KMS resource or request quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html). When you specify a customer managed key as the root encryption key for a table, restorable backups are encrypted with the same encryption key that is specified for the table at the time the backup is created. If the KMS key for the table is rotated, key enveloping ensures that the latest KMS key has access to all restorable backups. Amazon Keyspaces must have access to your customer managed key to provide you access to your table data. If the state of the encryption key is set to disabled or it's scheduled for deletion, Amazon Keyspaces is unable to encrypt or decrypt data. As a result, you are not able to perform read and write operations on the table. As soon as the service detects that your encryption key is inaccessible, Amazon Keyspaces sends an email notification to alert you. You must restore access to your encryption key within seven days or Amazon Keyspaces deletes your table automatically. As a precaution, Amazon Keyspaces creates a restorable backup of your table data before deleting the table. Amazon Keyspaces maintains the restorable backup for 35 days. After 35 days, you can no longer restore your table data. You aren't billed for the restorable backup, but standard [restore charges apply](https://aws.amazon.com/keyspaces/pricing). You can use this restorable backup to restore your data to a new table. To initiate the restore, the last customer managed key used for the table must be enabled, and Amazon Keyspaces must have access to it. **Note** When you're creating a table that's encrypted using a customer managed key that's inaccessible or scheduled for deletion before the creation process completes, an error occurs. The create table operation fails, and you're sent an email notification. ## Encryption at rest usage notes Consider the following when you're using encryption at rest in Amazon Keyspaces. + Server-side encryption at rest is enabled on all Amazon Keyspaces tables and can't be disabled. The entire table is encrypted at rest, you can't select specific columns or rows for encryption. + By default, Amazon Keyspaces uses a single-service default key (AWS owned key) for encrypting all of your tables. If this key doesn’t exist, it's created for you. Service default keys can't be disabled. + Encryption at rest only encrypts data while it's static (at rest) on a persistent storage media. If data security is a concern for data in transit or data in use, you must take additional measures: + Data in transit: All your data in Amazon Keyspaces is encrypted in transit. By default, communications to and from Amazon Keyspaces are protected by using Secure Sockets Layer (SSL)/Transport Layer Security (TLS) encryption. + Data in use: Protect your data before sending it to Amazon Keyspaces by using client-side encryption. + Customer managed keys: Data at rest in your tables is always encrypted using your customer managed keys. However operations that perform atomic updates of multiple rows encrypt data temporarily using AWS owned keys during processing. This includes range delete operations and operations that simultaneously access static and non-static data. + A single customer managed key can have up to 50,000 [grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html). Every Amazon Keyspaces table associated with a customer managed key consumes 2 grants. One grant is released when the table is deleted. The second grant is used to create an automatic snapshot of the table to protect from data loss in case Amazon Keyspaces lost access to the customer managed key unintentionally. This grant is released 42 days after deletion of the table. # Encryption at rest: How to use customer managed keys to encrypt tables in Amazon Keyspaces You can use the console or CQL statements to specify the AWS KMS key for new tables and update the encryption keys of existing tables in Amazon Keyspaces. The following topic outlines how to implement customer managed keys for new and existing tables. **Topics** + [Prerequisites: Create a customer managed key using AWS KMS and grant permissions to Amazon Keyspaces](#encryption.createCMKMS) + [Step 3: Specify a customer managed key for a new table](#encryption.tutorial-creating) + [Step 4: Update the encryption key of an existing table](#encryption.tutorial-update) + [Step 5: Use the Amazon Keyspaces encryption context in logs](#encryption-context) + [Step 6: Configure monitoring with AWS CloudTrail](#encryption-cmk-trail) ## Prerequisites: Create a customer managed key using AWS KMS and grant permissions to Amazon Keyspaces Before you can protect an Amazon Keyspaces table with a [customer managed key](encryption.howitworks.md#customer-managed), you must first create the key in AWS Key Management Service (AWS KMS) and then authorize Amazon Keyspaces to use that key. ### Step 1: Create a customer managed key using AWS KMS To create a customer managed key to be used to protect an Amazon Keyspaces table, you can follow the steps in [Creating symmetric encryption KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) using the console or the AWS API. ### Step 2: Authorize the use of your customer managed key Before you can choose a [customer managed key](encryption.howitworks.md#customer-managed) to protect an Amazon Keyspaces table, the policies on that customer managed key must give Amazon Keyspaces permission to use it on your behalf. You have full control over the policies and grants on the customer managed key. You can provide these permissions in a [key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html), an [IAM policy](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html), or a [grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html). Amazon Keyspaces doesn't need additional authorization to use the default [AWS owned key](encryption.howitworks.md#keyspaces-owned) to protect the Amazon Keyspaces tables in your AWS account. The following topics show how to configure the required permissions using IAM policies and grants that allow Amazon Keyspaces tables to use a customer managed key. **Topics** + [Key policy for customer managed keys](#encryption-customer-managed-policy) + [Example key policy](#encryption-customer-managed-policy-sample) + [Using grants to authorize Amazon Keyspaces](#encryption-grants) #### Key policy for customer managed keys When you select a [customer managed key](encryption.howitworks.md#customer-managed) to protect an Amazon Keyspaces table, Amazon Keyspaces gets permission to use the customer managed key on behalf of the principal who makes the selection. That principal, a user or role, must have the permissions on the customer managed key that Amazon Keyspaces requires. At a minimum, Amazon Keyspaces requires the following permissions on a customer managed key: + [kms:Encrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html) + [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) + [kms:ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)\$1 (for kms:ReEncryptFrom and kms:ReEncryptTo) + kms:GenerateDataKey\$1 (for [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) and [kms:GenerateDataKeyWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyWithoutPlaintext.html)) + [kms:DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) + [kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) #### Example key policy For example, the following example key policy provides only the required permissions. The policy has the following effects: + Allows Amazon Keyspaces to use the customer managed key in cryptographic operations and create grants—but only when it's acting on behalf of principals in the account who have permission to use Amazon Keyspaces. If the principals specified in the policy statement don't have permission to use Amazon Keyspaces, the call fails, even when it comes from the Amazon Keyspaces service. + The [kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) condition key allows the permissions only when the request comes from Amazon Keyspaces on behalf of the principals listed in the policy statement. These principals can't call these operations directly. Note that the `kms:ViaService` value, `cassandra.*.amazonaws.com`, has an asterisk (\$1) in the Region position. Amazon Keyspaces requires the permission to be independent of any particular AWS Region. + Gives the customer managed key administrators (users who can assume the `db-team` role) read-only access to the customer managed key and permission to revoke grants, including the [grants that Amazon Keyspaces requires](#encryption-grants) to protect the table. + Gives Amazon Keyspaces read-only access to the customer managed key. In this case, Amazon Keyspaces can call these operations directly. It doesn't have to act on behalf of an account principal. Before using an example key policy, replace the example principals with actual principals from your AWS account. ``` { "Id": "key-policy-cassandra", "Version":"2012-10-17", "Statement": [ { "Sid" : "Allow access through Amazon Keyspaces for all principals in the account that are authorized to use Amazon Keyspaces", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111122223333:user/db-lead"}, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey", "kms:CreateGrant" ], "Resource": "*", "Condition": { "StringLike": { "kms:ViaService" : "cassandra.*.amazonaws.com" } } }, { "Sid": "Allow administrators to view the customer managed key and revoke grants", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/db-team" }, "Action": [ "kms:Describe*", "kms:Get*", "kms:List*", "kms:RevokeGrant" ], "Resource": "*" } ] } ``` #### Using grants to authorize Amazon Keyspaces In addition to key policies, Amazon Keyspaces uses grants to set permissions on a customer managed key. To view the grants on a customer managed key in your account, use the [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html) operation. Amazon Keyspaces doesn't need grants, or any additional permissions, to use the [AWS owned key](encryption.howitworks.md#keyspaces-owned) to protect your table. Amazon Keyspaces uses the grant permissions when it performs background system maintenance and continuous data protection tasks. It also uses grants to generate table keys. Each grant is specific to a table. If the account includes multiple tables encrypted under the same customer managed key, there is a grant of each type for each table. The grant is constrained by the [Amazon Keyspaces encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/encryption-context.html), which includes the table name and the AWS account ID. The grant includes permission to [retire the grant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RetireGrant.html) if it's no longer needed. To create the grants, Amazon Keyspaces must have permission to call `CreateGrant` on behalf of the user who created the encrypted table. The key policy can also allow the account to [revoke the grant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) on the customer managed key. However, if you revoke the grant on an active encrypted table, Amazon Keyspaces will not be able to protect and maintain the table. ## Step 3: Specify a customer managed key for a new table Follow these steps to specify the customer managed key on a new table using the Amazon Keyspaces console or CQL. ### Create an encrypted table using a customer managed key (console) 1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home). 1. In the navigation pane, choose **Tables**, and then choose **Create table**. 1. On the **Create table** page in the **Table details** section, select a keyspace and provide a name for the new table. 1. In the **Schema** section, create the schema for your table. 1. In the **Table settings** section, choose **Customize settings**. 1. Continue to **Encryption settings**. In this step, you select the encryption settings for the table. In the **Encryption at rest** section under **Choose an AWS KMS key**, choose the option **Choose a different KMS key (advanced)**, and in the search field, choose an AWS KMS key or enter an Amazon Resource Name (ARN). **Note** If the key you selected is not accessible or is missing the required permissions, see [Troubleshooting key access](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html) in the AWS Key Management Service Developer Guide. 1. Choose **Create** to create the encrypted table. ### Create a new table using a customer managed key for encryption at rest (CQL) To create a new table that uses a customer managed key for encryption at rest, you can use the `CREATE TABLE` statement as shown in the following example. Make sure to replace the key ARN with an ARN for a valid key with permissions granted to Amazon Keyspaces. ``` CREATE TABLE my_keyspace.my_table(id bigint, name text, place text STATIC, PRIMARY KEY(id, name)) WITH CUSTOM_PROPERTIES = { 'encryption_specification':{ 'encryption_type': 'CUSTOMER_MANAGED_KMS_KEY', 'kms_key_identifier':'arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111' } }; ``` If you receive an `Invalid Request Exception`, you need to confirm that the customer managed key is valid and Amazon Keyspaces has the required permissions. To confirm that the key has been configured correctly, see [Troubleshooting key access](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html) in the AWS Key Management Service Developer Guide. ## Step 4: Update the encryption key of an existing table You can also use the Amazon Keyspaces console or CQL to change the encryption keys of an existing table between an AWS owned key and a customer managed KMS key at any time. ### Update an existing table with the new customer managed key (console) 1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home). 1. In the navigation pane, choose **Tables**. 1. Choose the table that you want to update, and then choose the **Additional settings** tab. 1. In the **Encryption at rest** section, choose **Manage Encryption** to edit the encryption settings for the table. Under **Choose an AWS KMS key**, choose the option **Choose a different KMS key (advanced)**, and in the search field, choose an AWS KMS key or enter an Amazon Resource Name (ARN). **Note** If the key you selected is not valid, see [Troubleshooting key access](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html) in the AWS Key Management Service Developer Guide. Alternatively, you can choose an AWS owned key for a table that is encrypted with a customer managed key. 1. Choose **Save changes** to save your changes to the table. ### Update the encryption key used for an existing table To change the encryption key of an existing table, you use the `ALTER TABLE` statement to specify a customer managed key for encryption at rest. Make sure to replace the key ARN with an ARN for a valid key with permissions granted to Amazon Keyspaces. ``` ALTER TABLE my_keyspace.my_table WITH CUSTOM_PROPERTIES = { 'encryption_specification':{ 'encryption_type': 'CUSTOMER_MANAGED_KMS_KEY', 'kms_key_identifier':'arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111' } }; ``` If you receive an `Invalid Request Exception`, you need to confirm that the customer managed key is valid and Amazon Keyspaces has the required permissions. To confirm that the key has been configured correctly, see [Troubleshooting key access](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html) in the AWS Key Management Service Developer Guide. To change the encryption key back to the default encryption at rest option with AWS owned keys, you can use the `ALTER TABLE` statement as shown in the following example. ``` ALTER TABLE my_keyspace.my_table WITH CUSTOM_PROPERTIES = { 'encryption_specification':{ 'encryption_type' : 'AWS_OWNED_KMS_KEY' } }; ``` ## Step 5: Use the Amazon Keyspaces encryption context in logs An [encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/encrypt_context.html) is a set of key–value pairs that contain arbitrary nonsecret data. When you include an encryption context in a request to encrypt data, AWS KMS cryptographically binds the encryption context to the encrypted data. To decrypt the data, you must pass in the same encryption context. Amazon Keyspaces uses the same encryption context in all AWS KMS cryptographic operations. If you use a [customer managed key](encryption.howitworks.md#customer-managed) to protect your Amazon Keyspaces table, you can use the encryption context to identify the use of the customer managed key in audit records and logs. It also appears in plaintext in logs, such as in logs for [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) and [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). In its requests to AWS KMS, Amazon Keyspaces uses an encryption context with three key–value pairs. ``` "encryptionContextSubset": { "aws:cassandra:keyspaceName": "my_keyspace", "aws:cassandra:tableName": "mytable" "aws:cassandra:subscriberId": "111122223333" } ``` + **Keyspace** – The first key–value pair identifies the keyspace that includes the table that Amazon Keyspaces is encrypting. The key is `aws:cassandra:keyspaceName`. The value is the name of the keyspace. ``` "aws:cassandra:keyspaceName": "" ``` For example: ``` "aws:cassandra:keyspaceName": "my_keyspace" ``` + **Table** – The second key–value pair identifies the table that Amazon Keyspaces is encrypting. The key is `aws:cassandra:tableName`. The value is the name of the table. ``` "aws:cassandra:tableName": "" ``` For example: ``` "aws:cassandra:tableName": "my_table" ``` + **Account** – The third key–value pair identifies the AWS account. The key is `aws:cassandra:subscriberId`. The value is the account ID. ``` "aws:cassandra:subscriberId": "" ``` For example: ``` "aws:cassandra:subscriberId": "111122223333" ``` ## Step 6: Configure monitoring with AWS CloudTrail If you use a [customer managed key](encryption.howitworks.md#customer-managed) to protect your Amazon Keyspaces tables, you can use AWS CloudTrail logs to track the requests that Amazon Keyspaces sends to AWS KMS on your behalf. The `GenerateDataKey`, `DescribeKey`, `Decrypt`, and `CreateGrant` requests are discussed in this section. In addition, Amazon Keyspaces uses a [RetireGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RetireGrant.html) operation to remove a grant when you delete a table. **Note** When you work with Amazon Keyspaces, some operations may generate CloudTrail events with an `invokedBy` field of `dynamodb.amazonaws.com`. This is expected and occurs because Amazon Keyspaces integrates with Amazon DynamoDB to provide its service. **GenerateDataKey** Amazon Keyspaces creates a unique table key to encrypt data at rest. It sends a *[GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)* request to AWS KMS that specifies the KMS key for the table. The event that records the `GenerateDataKey` operation is similar to the following example event. The user is the Amazon Keyspaces service account. The parameters include the Amazon Resource Name (ARN) of the customer managed key, a key specifier that requires a 256-bit key, and the [encryption context](#encryption-context) that identifies the keyspace, the table, and the AWS account. ``` { "eventVersion": "1.08", "userIdentity": { "type": "AWSService", "invokedBy": "AWS Internal" }, "eventTime": "2021-04-16T04:56:05Z", "eventSource": "kms.amazonaws.com", "eventName": "GenerateDataKey", "awsRegion": "us-east-1", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "keySpec": "AES_256", "encryptionContext": { "aws:cassandra:keyspaceName": "my_keyspace", "aws:cassandra:tableName": "my_table", "aws:cassandra:subscriberId": "123SAMPLE012" }, "keyId": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111" }, "responseElements": null, "requestID": "5e8e9cb5-9194-4334-aacc-9dd7d50fe246", "eventID": "49fccab9-2448-4b97-a89d-7d5c39318d6f", "readOnly": true, "resources": [ { "accountId": "123SAMPLE012", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111" } ], "eventType": "AwsApiCall", "managementEvent": true, "eventCategory": "Management", "recipientAccountId": "123SAMPLE012", "sharedEventID": "84fbaaf0-9641-4e32-9147-57d2cb08792e" } ``` **DescribeKey** Amazon Keyspaces uses a [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) operation to determine whether the KMS key you selected exists in the account and Region. The event that records the `DescribeKey` operation is similar to the following example event. The user is the Amazon Keyspaces service account. The parameters include the ARN of the customer managed key and a key specifier that requires a 256-bit key. ``` { "eventVersion": "1.08", "userIdentity": { "type": "IAMUser", "principalId": "AIDAZ3FNIIVIZZ6H7CFQG", "arn": "arn:aws:iam::123SAMPLE012:user/admin", "accountId": "123SAMPLE012", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "admin", "sessionContext": { "sessionIssuer": {}, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2021-04-16T04:55:42Z" } }, "invokedBy": "AWS Internal" }, "eventTime": "2021-04-16T04:55:58Z", "eventSource": "kms.amazonaws.com", "eventName": "DescribeKey", "awsRegion": "us-east-1", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "keyId": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111" }, "responseElements": null, "requestID": "c25a8105-050b-4f52-8358-6e872fb03a6c", "eventID": "0d96420e-707e-41b9-9118-56585a669658", "readOnly": true, "resources": [ { "accountId": "123SAMPLE012", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111" } ], "eventType": "AwsApiCall", "managementEvent": true, "eventCategory": "Management", "recipientAccountId": "123SAMPLE012" } ``` **Decrypt** When you access an Amazon Keyspaces table, Amazon Keyspaces needs to decrypt the table key so that it can decrypt the keys below it in the hierarchy. It then decrypts the data in the table. To decrypt the table key, Amazon Keyspaces sends a [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) request to AWS KMS that specifies the KMS key for the table. The event that records the `Decrypt` operation is similar to the following example event. The user is the principal in your AWS account who is accessing the table. The parameters include the encrypted table key (as a ciphertext blob) and the [encryption context](#encryption-context) that identifies the table and the AWS account. AWS KMS derives the ID of the customer managed key from the ciphertext. ``` { "eventVersion": "1.08", "userIdentity": { "type": "AWSService", "invokedBy": "AWS Internal" }, "eventTime": "2021-04-16T05:29:44Z", "eventSource": "kms.amazonaws.com", "eventName": "Decrypt", "awsRegion": "us-east-1", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "encryptionContext": { "aws:cassandra:keyspaceName": "my_keyspace", "aws:cassandra:tableName": "my_table", "aws:cassandra:subscriberId": "123SAMPLE012" }, "encryptionAlgorithm": "SYMMETRIC_DEFAULT" }, "responseElements": null, "requestID": "50e80373-83c9-4034-8226-5439e1c9b259", "eventID": "8db9788f-04a5-4ae2-90c9-15c79c411b6b", "readOnly": true, "resources": [ { "accountId": "123SAMPLE012", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111" } ], "eventType": "AwsApiCall", "managementEvent": true, "eventCategory": "Management", "recipientAccountId": "123SAMPLE012", "sharedEventID": "7ed99e2d-910a-4708-a4e3-0180d8dbb68e" } ``` **CreateGrant** When you use a [customer managed key](encryption.howitworks.md#customer-managed) to protect your Amazon Keyspaces table, Amazon Keyspaces uses [grants](#encryption-grants) to allow the service to perform continuous data protection and maintenance and durability tasks. These grants aren't required on [AWS owned keys](encryption.howitworks.md#keyspaces-owned). The grants that Amazon Keyspaces creates are specific to a table. The principal in the [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) request is the user who created the table. The event that records the `CreateGrant` operation is similar to the following example event. The parameters include the ARN of the customer managed key for the table, the grantee principal and retiring principal (the Amazon Keyspaces service), and the operations that the grant covers. It also includes a constraint that requires all encryption operations use the specified [encryption context](#encryption-context). ``` { "eventVersion": "1.08", "userIdentity": { "type": "IAMUser", "principalId": "AIDAZ3FNIIVIZZ6H7CFQG", "arn": "arn:aws:iam::arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111:user/admin", "accountId": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111", "accessKeyId": "AKIAI44QH8DHBEXAMPLE", "userName": "admin", "sessionContext": { "sessionIssuer": {}, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2021-04-16T04:55:42Z" } }, "invokedBy": "AWS Internal" }, "eventTime": "2021-04-16T05:11:10Z", "eventSource": "kms.amazonaws.com", "eventName": "CreateGrant", "awsRegion": "us-east-1", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "keyId": "a7d328af-215e-4661-9a69-88c858909f20", "operations": [ "DescribeKey", "GenerateDataKey", "Decrypt", "Encrypt", "ReEncryptFrom", "ReEncryptTo", "RetireGrant" ], "constraints": { "encryptionContextSubset": { "aws:cassandra:keyspaceName": "my_keyspace", "aws:cassandra:tableName": "my_table", "aws:cassandra:subscriberId": "123SAMPLE012" } }, "retiringPrincipal": "cassandratest.us-east-1.amazonaws.com", "granteePrincipal": "cassandratest.us-east-1.amazonaws.com" }, "responseElements": { "grantId": "18e4235f1b07f289762a31a1886cb5efd225f069280d4f76cd83b9b9b5501013" }, "requestID": "b379a767-1f9b-48c3-b731-fb23e865e7f7", "eventID": "29ee1fd4-28f2-416f-a419-551910d20291", "readOnly": false, "resources": [ { "accountId": "123SAMPLE012", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111" } ], "eventType": "AwsApiCall", "managementEvent": true, "eventCategory": "Management", "recipientAccountId": "123SAMPLE012" } ``` # Encryption in transit in Amazon Keyspaces Amazon Keyspaces only accepts secure connections using Transport Layer Security (TLS). Encryption in transit provides an additional layer of data protection by encrypting your data as it travels to and from Amazon Keyspaces. Organizational policies, industry or government regulations, and compliance requirements often require the use of encryption in transit to increase the data security of your applications when they transmit data over the network. To learn how to encrypt `cqlsh` connections to Amazon Keyspaces using TLS, see [How to manually configure `cqlsh` connections for TLS](programmatic.cqlsh.md#encrypt_using_tls). To learn how to use TLS encryption with client drivers, see [Using a Cassandra client driver to access Amazon Keyspaces programmatically](programmatic.drivers.md). # Internetwork traffic privacy in Amazon Keyspaces This topic describes how Amazon Keyspaces (for Apache Cassandra) secures connections from on-premises applications to Amazon Keyspaces and between Amazon Keyspaces and other AWS resources within the same AWS Region. ## Traffic between service and on-premises clients and applications 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?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) in the *AWS Site-to-Site VPN User Guide*. + An Direct Connect connection. For more information, see [What is Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) in the *Direct Connect User Guide*. As a managed service, Amazon Keyspaces (for Apache Cassandra) is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*. You use AWS published API calls to access Amazon Keyspaces through the network. 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. Amazon Keyspaces supports two methods of authenticating client requests. The first method uses service-specific credentials, which are password based credentials generated for a specific IAM user. You can create and manage the password using the IAM console, the AWS CLI, or the AWS API. For more information, see [Using IAM with Amazon Keyspaces](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mcs.html). The second method uses an authentication plugin for the open-source DataStax Java Driver for Cassandra. This plugin enables [IAM users, roles, and federated identities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) to add authentication information to Amazon Keyspaces (for Apache Cassandra) API requests using the [AWS Signature Version 4 process (SigV4)](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html). For more information, see [Create and configure AWS credentials for Amazon Keyspaces](access.credentials.md). ## Traffic between AWS resources in the same Region Interface VPC endpoints enable private communication between your virtual private cloud (VPC) running in Amazon VPC and Amazon Keyspaces. Interface VPC endpoints are powered by AWS PrivateLink, which is an AWS service that enables private communication between VPCs and AWS services. AWS PrivateLink enables this by using an elastic network interface with private IPs in your VPC so that network traffic does not leave the Amazon network. Interface VPC endpoints don't require an internet gateway, NAT device, VPN connection, or Direct Connect connection. For more information, see [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) and [Interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html). For example policies, see [Using interface VPC endpoints for Amazon Keyspaces](vpc-endpoints.md#using-interface-vpc-endpoints).