# Database-level Encryption
In ScyllaDB Cloud, your data is always encrypted on the [storage-level](https://cloud.docs.scylladb.com/stable/security/storage-level-encryption.md) by
your cloud provider – AWS or GCP.
In addition, database-level encryption is automatically enabled for all new clusters.
This page describes database-level encryption in ScyllaDB Cloud.
## Overview
Database-level encryption is a method of encrypting all data before it is stored in the database. In ScyllaDB Cloud, database-level encryption is extended with Customer Managed Keys (CMK) encryption control. This ensures that the data is securely stored – and the customer manages the key. The keys are stored and protected separately from the database, creating [separation of privileges](https://en.wikipedia.org/wiki/Privilege_separation).
ScyllaDB Cloud provides full database-level encryption using the Customer Managed Keys (CMK) concept. It is based on envelope encryption to encrypt the data and decrypt only when the data is needed.
A key quality of CMK is that the customer has full control of the encryption keys. The data encryption keys (DEK) used to encrypt the data are encrypted with customer keys; if the customer revokes access to them, the data cannot be decrypted until the access is restored.
The customer can:
> * Revoke data access at any time
> * Restore data access at any time
> * Manage the master keys needed for decryption
> * Log all access attempts to keys and data
Customers can also delegate all key management operations to ScyllaDB Cloud.
To do this, choose the *ScyllaDB key* option when creating a cluster.
To do this, the customer can choose the ScyllaDB key option when creating the cluster.
To ensure customer data is secure and adheres to all privacy regulations we encrypt the data by default.
ScyllaDB Cloud encryption uses the symmetrical algorithm AES-128 by default. You can increase the strength to AES-256.
**Encryption**
To ensure all user data is protected, ScyllaDB encrypts:
* All user tables
* Commit logs
* Batch logs
* Hinted handoff data
This ensures all customer data is properly encrypted.
The first step of the encryption process is to encrypt every new record with a data encryption key (DEK). Once the data is encrypted with the DEK, it is sent to the Cloud KMS, where the master key (MK) resides. The DEK is then encrypted with the master key (MK), producing an encrypted DEK (EDEK or a wrapped key).
The master key remains in the Cloud KMS, while the EDEK is returned and stored with the data. The DEK used to encrypt the data is destroyed to ensure data protection. A new DEK will be generated the next time new data needs to be encrypted.
> 
**Decryption**
Because the original non-encrypted DEK is destroyed when the EDEK was produced, the data cannot be decrypted with it. The DEK it contains has to be decrypted first, and for that, the master key, will be required again.
This can only be decrypted with the master key(MK) in the KMS.
> 
Once the DEK is unwrapped, the data can be decrypted.
The data cannot be decrypted without the master key, which is protected at all times in the KMS and cannot be “copied” outside of KMS.
By revoking the master key, the customer can disable access to the data independently from the database or application authorization.
#### NOTE
Cloud providers will charge you for maintaining your keys in their KMS.
You can manage your own keys, or you can use ScyllaDB-managed keys.
When you create a cluster, the encryption using ScyllaDB keys is applied by default. Note that using ScyllaDB keys does not incur additional costs.
## Prerequisites
These requirements apply when using **Customer Managed Keys (CMK)** for database-level
encryption (see [Create Customer Key](#create-customer-key)).
* **For AWS:**
Database encryption requires AWS Key Management Service (AWS KMS) to be
available in the same region as your ScyllaDB Cloud cluster.
* **For GCP:**
Database encryption requires Google Cloud Key Management Service (Cloud KMS)
to be enabled in the cluster’s project.
## Configuring Database-level Encryption
#### NOTE
You must have the **Admin** role to add, use, and delete encryption keys.
See [User Roles](https://cloud.docs.scylladb.com/stable/access-management/user-management.md#access-management-user-roles) for details.
When you create a new cluster, you can configure which key will be used
to encrypt data. Select one of the following in the **Database-level Encryption (CMK)** section:
* **ScyllaDB Key** (default) - Your cluster data will be encrypted with a key provided by *ScyllaDB*. No further action is required on your side, as encryption at rest will be managed by ScyllaDB Cloud.
* **Customer Key** - Your cluster data will be encrypted with a key stored
in Key Management Service (KMS) on AWS or GCP. You need to provide
the key you want to use for encryption: select a key from the drop-down
(if available) or click **Create new key** to add a new key to your account.
See [Create customer key](#create-customer-key) for instructions on
adding your own key to your ScyllaDB Cloud account.
After the cluster is created, you can see the encryption at rest
information on the cluster details page is enabled.
## Create Customer Key
Available with the Premium plan
You can use a customer-managed encryption key stored in the user Key Management Service
(KMS) on AWS or GCP. The customer key is not accessible in ScyllaDB Cloud; it is used to encrypt the database encryption key (DEK).
To encrypt stored data with your customer encryption key, you need to:
1. Add reference to your key to your ScyllaDB Cloud account.
2. Provide the key reference (*Customer Key*) when creating a new cluster.
See [Enable Database-level Encryption](#ear-enable-encryption-at-rest)
### Encryption with Multiple Datacenters
When you add one or more new DC (datacenter), your key will be replicated across the DCs you added.
> 
Adding new datacenters to the ScyllaDB cluster will create additional local keys in those regions. All customer managed keys support multi-region, and a copy of each key resides locally in each region – ensuring those multi-regional setups are protected from regional outages for the cloud provider or against any disaster.
> 
The keys are available in the same region as the datacenter and can be controlled independently.
## Add Your Key to ScyllaDB Cloud
This section explains how to add your key to ScyllaDB Cloud.
When you add and provision the key, you can provide it when creating a cluster.
Once you complete the cluster deployment, the encryption at rest icon will be enabled
in your cluster status.
### CMK on Amazon Web Services
To create and assign your AWS CMK to ScyllaDB Cloud:
1. Go to **Managed Resources** via the drop-down in
the top right corner next to your username.
2. Open the **Customer Managed Key** tab.
3. Click **Add Key** to open the *Add Key* pop-up.
4. Choose **Amazon Web Services** from the **Provider** drop-down.
5. Select the region where you want the key to be valid using the **Region** drop-down
(the default is *US East (N. Virginia)*).
6. Click **Set Key** to store the key entry in ScyllaDB Cloud and display
the summary pop-up.
This will be the key for your starting datacenter. If you add more datacenters later,
the key will be automatically replicated in each region.
Note that the key is not ready for use yet. You need to proceed to
provision the key in AWS.
7. Click **Launch Stack** in the summary pop-up to open the (AWS) CloudFormation
Stack in a new tab to provision your key in the AWS KMS store.
8. Once created, you can go back to the ScyllaDB Cloud to click **I’m done provisioning**
in the pop-up.
### CMK on Google Cloud Platform
To create and assign your GCP CMK to ScyllaDB Cloud:
1. Go to **Managed Resources** via the drop-down in
the top right corner next to your username.
2. Open the **Customer Managed Key** tab.
3. Click **Add Key** to open the *Add Key* pop-up.
4. Choose your **Google Cloud Platform** from the **Provider** drop-down.
The *Region* drop-down will become inactive as the key will be valid globally.
5. Click **Next** to open the *Add GCP Key* pop-up.
6. In the **Add GCP Key** pop-up, you can determine whether you want to use
a key ring that already exists in your GCP or create a new one.
A key ring organizes keys in a specific GCP location. It allows you to manage
access control on groups of keys and organize keys by project or application.
See [Key rings](https://cloud.google.com/kms/docs/resource-hierarchy#key_rings)
in the GCP KMS documentation for details.
**To create a new key ring:**
1. Enable the **Create new key Ring for me** checkbox.
2. Click **Next**.
3. In the **Project ID** field, specify your project ID.
You can copy your project ID from the [Google Cloud Console](https://console.cloud.google.com/).
**To use an existing key ring:**
1. Leave the **Create new key Ring for me** checkbox disabled.
2. Click **Next**.
3. In the **Key ring** field, specify an existing key ring.
To obtain a list of existing key rings, go to the [Google Cloud Console](https://console.cloud.google.com/)
and navigate to **Security> Key Management**. Here, you can review the existing
key rings and keys associated with each key ring. NOTE: Make sure your desired
project is selected.
> 1. Click **Generate template** to generate a Terraform template that includes all
> files required for provisioning the cloud resources.
> 2. Click **Download template** to download the Terraform template (a ZIP archive).
> 3. Unzip the archive.
> 4. In a terminal, navigate to the unzipped directory and run the following terraform
> commands to provision the key:
> ```default
> terraform init // Prepare
> terraform plan // Dry run
> terraform apply // Execute
> You will be prompted to enter the Template Secret:
> ```
> ```default
> 316CeQo8Ioj2RHiGBdaCt1NkEA0ZC3oJrtP1
> ```
> Type “yes” to confirm.
> 5. Once the script completes successfully, go back to the *Add GCP Key* pop-up
> in ScyllaDB Cloud and click **Done**.
You can review your newly added key in the *Customer Managed Key* section.
## Reviewing and Managing Your Keys
To review the list of your customer keys that you added to ScyllaDB Cloud,
go to **Managed Resources** via the drop-down and open the **Customer Managed Key** tab.
It will display the following information:
* **Key Alias** - The key alias you provided in the Cloudformation Stack.
If not provided, the key ID will be displayed.
* **Provider** - Your cloud provider name.
* **Region** - The regions where the key is valid.
* **Date Added** - The date when the key entry was added to ScyllaDB Cloud.
* **Status** - The status of the key in ScyllaDB Cloud:
* *Available* - The key is added to ScyllaDB Cloud and provisioned in AWS.
You can use it when creating a new cluster.
* *Pending Action* - The key has not been provisioned or deleted in the cloud
provider’s stack.
* Pending provision - The key was added to ScyllaDB Cloud, but it was not
provisioned in AWS. You can click the **Launch Stack** link next to
the status to open the Cloudformation Stack and provision the key.
* Pending deletion - The key was decommissioned and then deleted in Scylla Cloud,
but not in AWS. You can click the **Delete Stack** link next to
the status to open the Cloudformation Stack and delete the key.
* *In Use* - The key is in use by an existing cluster. You can click
the **Cluster Name** link next to the status to view the information about
the cluster.
* *Decommissioned* - The key was used on a cluster that was deleted (the key cannot be reused).
* You can use the trash icon to delete any key that is not in use.