From 9838e39e28b81e3b251e040cc1391771e4d4f6e2 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Mon, 23 Mar 2026 18:24:57 +0800 Subject: [PATCH 01/17] cloud-premium: add manual backup support for premium instances - Add manual backup feature with key characteristics and creation steps - Update PITR window to 7 days for premium instances - Fix Premium naming consistency using {{{ .premium }}} variable - Remove manual backup limitation note since it's now supported Co-Authored-By: Claude Opus 4.6 --- .../premium/backup-and-restore-premium.md | 34 +++++++++++++++---- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 392acfacbd4c0..a5438c3eadd07 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -6,12 +6,12 @@ aliases: ['/tidbcloud/restore-deleted-tidb-cluster'] # Back Up and Restore {{{ .premium }}} Data -This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports automatic backup and lets you restore backup data to a new instance as needed. +This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed Backup files can originate from the following sources: - Active {{{ .premium }}} instances -- The Recycle Bin for backups from deleted Premium instances +- The Recycle Bin for backups from deleted {{{ .premium }}} instances > **Tip:** > @@ -67,6 +67,29 @@ To delete an existing backup file for your {{{ .premium }}} instance, perform th 2. Locate the corresponding backup file you want to delete, and click **...** > **Delete** in the **Action** column. +## Manual backups +In addition to automatic backups, {{{ .premium }}} supports manual backups. Manual backups provide a user-controlled, guaranteed restore point, which is highly recommended before performing high-risk actions such as system upgrades, critical data deletion, or irreversible schema/configuration changes. + +### Key characteristics of manual backups: + +- **Retention and Deletion**: Unlike automatic backups, manual backups are not automatically deleted based on retention rules. They are retained indefinitely until you explicitly delete them. If the instance is deleted, its manual backups are moved to the Recycle Bin and will remain there permanently until manual deletion. + +- **Storage Location**: Manual backups are stored in TiDB Managed Cloud Storage. + +- **Cost**: Due to their long-term retention, manual backups are subject to additional charges. + +- **Limitations**: Manual backups do not support Point-in-Time Recovery (PITR) or partial backups (e.g., table-level or database-level). Restoring a manual backup into an existing or running cluster is not supported; each restore requires a new cluster. + +- **Permissions**: Both Organization owners and Instance managers can perform manual backups. However, only Organization owners can perform restore actions for system-managed manual backups. + +### Create a manual backup + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. + +2. In the upper-right corner, click **...**, and then click **Manual Backup**. + +3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the Backup List. It can be restored directly through the UI without requiring external storage credentials. + ## Restore TiDB Cloud provides restore functionality to help recover data in case of accidental loss or corruption. You can restore from backups of active instances or from deleted instances in the Recycle Bin. @@ -75,11 +98,11 @@ TiDB Cloud provides restore functionality to help recover data in case of accide TiDB Cloud supports snapshot restore and point-in-time restore for your instance. -- **Snapshot Restore**: restores your instance from a specific backup snapshot. +- **Snapshot Restore**: restores your instance from a specific backup snapshot. Both automatic and manual backups can be restored this way. Manual backups are displayed in the Backup List with a "Manual" backup type and a "Permanent" expiration status. - **Point-in-Time Restore**: restores your instance to a specific point in time. - - Premium instances: can be restored to any time within the last 33 days, but not earlier than the instance creation time or later than one minute before the current time. + - Premium instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. (Note: PITR is not supported for manual backups) ### Restore destination @@ -194,9 +217,6 @@ To restore backups from cloud storage, do the following: 5. Click **Restore** to restore the backup. -## Limitations - -Currently, manual backups are not supported for {{{ .premium }}} instances. ## References From fdd5c155814233c3311fa63cf2e811ccde1ef2ef Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Tue, 24 Mar 2026 09:41:35 +0800 Subject: [PATCH 02/17] Apply suggestions from code review Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/backup-and-restore-premium.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index a5438c3eadd07..e5dd94bfc4476 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -6,7 +6,7 @@ aliases: ['/tidbcloud/restore-deleted-tidb-cluster'] # Back Up and Restore {{{ .premium }}} Data -This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed +This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed. Backup files can originate from the following sources: @@ -88,7 +88,7 @@ In addition to automatic backups, {{{ .premium }}} supports manual backups. Manu 2. In the upper-right corner, click **...**, and then click **Manual Backup**. -3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the Backup List. It can be restored directly through the UI without requiring external storage credentials. +3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. You can restore it directly through the UI without requiring external storage credentials. ## Restore @@ -102,7 +102,7 @@ TiDB Cloud supports snapshot restore and point-in-time restore for your instance - **Point-in-Time Restore**: restores your instance to a specific point in time. - - Premium instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. (Note: PITR is not supported for manual backups) + - Premium instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. Note that PITR is not supported for manual backups. ### Restore destination From df26b429fb9240483642a5a8b9b4780c769d3d62 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Tue, 24 Mar 2026 10:21:19 +0800 Subject: [PATCH 03/17] Apply suggestions from code review --- tidb-cloud/premium/backup-and-restore-premium.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index e5dd94bfc4476..1af3438f10859 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -68,19 +68,20 @@ To delete an existing backup file for your {{{ .premium }}} instance, perform th 2. Locate the corresponding backup file you want to delete, and click **...** > **Delete** in the **Action** column. ## Manual backups -In addition to automatic backups, {{{ .premium }}} supports manual backups. Manual backups provide a user-controlled, guaranteed restore point, which is highly recommended before performing high-risk actions such as system upgrades, critical data deletion, or irreversible schema/configuration changes. + +In addition to automatic backups, {{{ .premium }}} supports manual backups. Manual backups provide a user-controlled, guaranteed restore point, which is highly recommended before performing high-risk actions such as system upgrades, critical data deletion, and irreversible schema or configuration changes. ### Key characteristics of manual backups: -- **Retention and Deletion**: Unlike automatic backups, manual backups are not automatically deleted based on retention rules. They are retained indefinitely until you explicitly delete them. If the instance is deleted, its manual backups are moved to the Recycle Bin and will remain there permanently until manual deletion. +- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention rules. They are retained indefinitely until you explicitly delete them. If the instance is deleted, its manual backups are moved to the Recycle Bin and will remain there permanently until manual deletion. -- **Storage Location**: Manual backups are stored in TiDB Managed Cloud Storage. +- **Storage location**: manual backups are stored in cloud storage managed by TiDB. -- **Cost**: Due to their long-term retention, manual backups are subject to additional charges. +- **Cost**: due to their long-term retention, manual backups are subject to additional charges. -- **Limitations**: Manual backups do not support Point-in-Time Recovery (PITR) or partial backups (e.g., table-level or database-level). Restoring a manual backup into an existing or running cluster is not supported; each restore requires a new cluster. +- **Limitations**: manual backups do not support Point-in-Time Recovery (PITR) or partial backups (for example, table-level or database-level). Restoring a manual backup into an existing or running instance is not supported. Each restore requires a new instance. -- **Permissions**: Both Organization owners and Instance managers can perform manual backups. However, only Organization owners can perform restore actions for system-managed manual backups. +- **Permissions**: both **Organization owners** and **Instance managers** can perform manual backups. However, only **Organization owners** can perform restore actions for system-managed manual backups. ### Create a manual backup @@ -98,7 +99,7 @@ TiDB Cloud provides restore functionality to help recover data in case of accide TiDB Cloud supports snapshot restore and point-in-time restore for your instance. -- **Snapshot Restore**: restores your instance from a specific backup snapshot. Both automatic and manual backups can be restored this way. Manual backups are displayed in the Backup List with a "Manual" backup type and a "Permanent" expiration status. +- **Snapshot Restore**: restores your instance from a specific backup snapshot. Both automatic and manual backups can be restored this way. Manual backups are displayed in the **Backup List** with a **Manual** backup type and a **Permanent** expiration status. - **Point-in-Time Restore**: restores your instance to a specific point in time. @@ -217,7 +218,6 @@ To restore backups from cloud storage, do the following: 5. Click **Restore** to restore the backup. - ## References This section describes how to configure access for Amazon S3 and Alibaba Cloud OSS. From 03a47b961f39224eeb94fc9677f30b7a9a1a3e6f Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Tue, 24 Mar 2026 11:23:43 +0800 Subject: [PATCH 04/17] Update tidb-cloud/premium/backup-and-restore-premium.md --- tidb-cloud/premium/backup-and-restore-premium.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 1af3438f10859..e102dfba7c42e 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -89,7 +89,9 @@ In addition to automatic backups, {{{ .premium }}} supports manual backups. Manu 2. In the upper-right corner, click **...**, and then click **Manual Backup**. -3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. You can restore it directly through the UI without requiring external storage credentials. +3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. + +You can restore the manual backup directly through the UI without requiring external storage credentials. ## Restore From f070954ad8d0ece2475b01899e2e67f078fb8597 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Tue, 24 Mar 2026 12:56:16 +0800 Subject: [PATCH 05/17] Apply suggestions from code review Co-authored-by: Aolin --- tidb-cloud/premium/backup-and-restore-premium.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index e102dfba7c42e..5276ff6672f16 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -69,19 +69,19 @@ To delete an existing backup file for your {{{ .premium }}} instance, perform th ## Manual backups -In addition to automatic backups, {{{ .premium }}} supports manual backups. Manual backups provide a user-controlled, guaranteed restore point, which is highly recommended before performing high-risk actions such as system upgrades, critical data deletion, and irreversible schema or configuration changes. +In addition to automatic backups, {{{ .premium }}} supports manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. -### Key characteristics of manual backups: +### Key characteristics -- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention rules. They are retained indefinitely until you explicitly delete them. If the instance is deleted, its manual backups are moved to the Recycle Bin and will remain there permanently until manual deletion. +- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention policies. They are retained until you explicitly delete them. If you delete the instance, its manual backups move to the recycle bin and remain there until you manually delete them. - **Storage location**: manual backups are stored in cloud storage managed by TiDB. -- **Cost**: due to their long-term retention, manual backups are subject to additional charges. +- **Cost**: because manual backups are retained long term and incur additional charges. -- **Limitations**: manual backups do not support Point-in-Time Recovery (PITR) or partial backups (for example, table-level or database-level). Restoring a manual backup into an existing or running instance is not supported. Each restore requires a new instance. +- **Limitations**: manual backups do not support point-in-time recovery (PITR) or partial backups (for example, table-level or database-level backups). You cannot restore a manual backup to an existing instance. Each restore operation creates a new instance. -- **Permissions**: both **Organization owners** and **Instance managers** can perform manual backups. However, only **Organization owners** can perform restore actions for system-managed manual backups. +- **Permissions**: both `Organization Owner` and `Instance Manager` can create manual backups. Only `Organization Owner` can restore system-managed manual backups. ### Create a manual backup @@ -91,7 +91,7 @@ In addition to automatic backups, {{{ .premium }}} supports manual backups. Manu 3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. -You can restore the manual backup directly through the UI without requiring external storage credentials. +You can restore a manual backup directly in the TiDB Cloud console without providing external storage credentials. ## Restore @@ -101,7 +101,7 @@ TiDB Cloud provides restore functionality to help recover data in case of accide TiDB Cloud supports snapshot restore and point-in-time restore for your instance. -- **Snapshot Restore**: restores your instance from a specific backup snapshot. Both automatic and manual backups can be restored this way. Manual backups are displayed in the **Backup List** with a **Manual** backup type and a **Permanent** expiration status. +- **Snapshot Restore**: restores your instance from a specific backup snapshot. You can use this method to restore both automatic and manual backups. In the **Backup List**, manual backups are labeled with the **Manual** type and a **Permanent** expiration status. - **Point-in-Time Restore**: restores your instance to a specific point in time. From 4a1eb0b531b3591f2bd2aff57c843bf4f64fa968 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 28 Apr 2026 12:21:37 +0800 Subject: [PATCH 06/17] cloud/premium: add Dual-layer Data Encryption documentation Add documentation for CMEK (Customer-Managed Encryption Key) and Service-Managed Encryption Key features on TiDB Cloud Premium. Co-Authored-By: Claude Opus 4.7 --- .../tidb-cloud-encrypt-cmek-aws-premium.md | 146 ++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md new file mode 100644 index 0000000000000..fed076456e2d0 --- /dev/null +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -0,0 +1,146 @@ +--- +title: Dual-layer Data Encryption +summary: Learn how to enable Dual-layer Data Encryption on {{{ .premium }}} TiDB. +aliases: ['/tidbcloud/premium/tidb-cloud-encrypt-cmek'] +--- + +# Dual-layer Data Encryption + +## Overview +{{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, {{{ .premium }}} allows you to combine TiDB service's storage engine encryption with your cloud provider's KMS, adding another layer of data encryption (Dual-layer Data Encryption). + +### Encryption mechanism + +To provide the highest level of data security, {{{ .premium }}} TiDB adopts a two-tier architecture for data-at-rest encryption. Your data is safeguarded by both Storage-layer and Database-layer protections. + +- Storage-layer Data Encryption + - This is the underlying data encryption directly implemented by cloud service providers on their storage infrastructure. For example, on AWS, this includes EBS volume encryption and S3 bucket encryption. + - This layer of encryption is enabled by default for all {{{ .premium }}} instances and cannot be disabled. It serves as the foundational security baseline for your data. + +- Database-layer Encryption + - Building on top of the storage-layer encryption, TiDB Cloud allows you to add an extra layer of data encryption at the database level (labeled as **Dual-layer Data Encryption** in the console). Once enabled, static data encryption specifically covers TiKV's stored data and BR's backup data. + - The TiDB database system ensures that data remains encrypted at rest within the system, thereby effectively reducing the risk of data leakage during subsequent data transfers. + - Unlike default storage encryption, this feature can be managed by users, allowing you to choose either a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key based on your security compliance and operational requirements. + + +#### Backup & Restore Description +When Dual-layer Data Encryption is enabled, the backup data for your {{{ .premium }}} TiDB instance is also encrypted. Any new instance restored from this backup will natively inherit the encryption attributes and KMS master key of the original instance. + +Since accessing the backup data relies on the originally configured KMS master key, please ensure the following: + +- **Maintain key availability**: Even if you delete the original Premium TiDB instance, the associated KMS master key must remain active to successfully recover the backup data. +- **Ensure correct authorization**: During a restore operation, you must configure the exact same KMS master key associated with the backup and ensure it has the proper permissions for data access. + +### Key Management Mechanism + +Premium's Dual-layer Data Encryption uses AWS KMS to manage master keys for data-at-rest encryption. Depending on your compliance and maintenance requirements, you can choose between two key management options： + +1. **Customer-Managed Encryption Key (CMEK)**: You provide and manage your own AWS KMS master key. This option offers maximum control over your encryption, making it ideal for organizations prioritizing strict security. +- **Important:** You are fully responsible for maintaining the key's security and availability. If the configured CMEK is deleted, your Premium TiDB instance will malfunction, and the encrypted data will become permanently unrecoverable. + +2. **Service-Managed Encryption Key**：TiDB Cloud Premium automatically provisions and maintains the KMS master key for you, offering a balance of security and convenience with zero maintenance overhead. +- Key Characteristics: + - It is a symmetric encryption key. + - It is automatically generated when you create your first encrypted Premium TiDB instance in a specific region. + - TiDB Cloud creates one key per organization per region, which is shared across all your Premium instances within that region. + - The key is automatically removed only after all data encrypted by it within your organization has been completely deleted + +## Limitations + +- Currently, this feature only supports AWS KMS. Support for Alibaba Cloud KMS and Azure Key Vault will be available soon. +- Data encryption applies to TiKV, CDC, and BR components. Support for TiFlash data encryption is coming soon. +- Once Dual-layer Data Encryption is enabled, the encryption properties of the {{{ .premium }}} instance cannot be modified. +- Custom encryption algorithms are not supported. Additionally, you can only rotate the KMS master key; rotation of other keys is not supported. +- Your AWS KMS key must reside in the same region as your TiDB instance. Consequently, cross-region restore operations are not supported for CMEK-encrypted backups. + +## Enable and Manage Encryption + +### Enable encryption during instance creation + +You can enable Dual-layer Data Encryption when creating a new {{{ .premium }}} instance. Depending on your security compliance and maintenance requirements, you can choose between two key management options: **Customer-Managed Encryption Key (CMEK)** or **Service-Managed Encryption Key**. + +#### Option 1: Customer-Managed Encryption Key (CMEK) + +To use your own encryption key, follow these steps: + +- **Step 1. Create a symmetric encryption key in your AWS KMS (Preparation)** + +Before proceeding, you must create a symmetric encryption key in AWS KMS. Ensure the key resides in the **same region** as your planned TiDB service. For detailed instructions, see [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html). + +- **Step 2. Configure CMEK in TiDB Cloud** + +1. On the **My TiDB** page, click **Create Resource**. +2. Select the {{{ .premium }}} plan and complete the basic instance configuration. +3. In **Dual-Layer Data Encryption** section, click **Enable**. +4. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. +5. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. +6. In your AWS KMS Console, add this trust relationship to the your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). +7. Return to the TiDB Cloud console, scroll to the bottom of the key creation page, and enter the **KMS Key ARN** obtained from AWS KMS. +8. Click **Test and Add KMS Key ARN** to verigy the key trust relationship. +9. Once the verification passes, Click **Create** to finish creating your {{{ .premium }}} instance. + +#### Option 2: Service-Managed Encryption Key + +To let TiDB Cloud automatically manage the encryption key for you, follow these steps: + +1. On the **My TiDB** page, click **Create Resource**. +2. Select the {{{ .premium }}} plan and complete the basic instance configuration. +3. In **Dual-Layer Data Encryption** section, click **Enable**. +4. Select **Service-Managed Encryption Key**. +5. Click **Create** to finish creating your {{{ .premium }}} instance. + +### Enable Encryption for an existing instance + +If you did not enable encryption during cluster creation, you can still enable it later. Depending on your requirements, you can choose between a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key. + +> **Note:** +> +> Enable Encryption on an existing instance requires some time to complete the activation process. + +#### Option 1: Customer-Managed Encryption Key (CMEK) + +Before proceeding, ensure you have created a symmetric encryption key in your AWS KMS. Then, follow these steps: + +1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** for in the Dual-layer Data Encryption section. +2. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. +3. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. +4. In your AWS KMS console, add this trust policy to your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). +5. Return to the TiDB Cloud console, scroll to the bottom of the page, and enter the **KMS Key ARN** obtained from AWS KMS. +6. Click **Test and Add KMS Key ARN** to check the key trust relationship. +7. Click **Enable** to enable the Dual-layer Data Encryption feature. + +#### Option 2: Service-Managed Encryption Key + +To let TiDB Cloud automatically manage the encryption key for you, follow these steps: +1. On the Security page of your {{{ .premium }}} instance , click **Enable** in the Dual-layer Data Encryption section. +2. Select **Service-Managed Encryption Key**. +3. Click **Enable**. + +### View encryption status + +Once encryption is enabled, you can verify its status and configuration details in the following two places: +- Check the **Encryption** property on the **Overview** page of the instance to see the active key management method (either **Enabled with Customer-Managed Encryption Key (CMEK)** or **Enabled with Service-Managed Encryption Key**). +- Navigate to the Security page to view the detailed configuration properties of your Dual-layer Data Encryption. + +### Restore from an encrypted backup + +Backups generated from an encrypted {{{ .premium }}} instance are also encrypted. When restoring such a backup to a new instance, the restored instance must maintain consistent encryption properties. + +#### Customer-Managed Encryption Key (CMEK) + +If the backup is encrypted using a CMEK, you must verify that the new instance can correctly access the KMS master key during the restore process: + +1. The key ARN will remain unchanged. Click **Check** to proceed with the trust policy verification. +2. The system will check if the authorized TiDB Cloud account in the key policy matches the one associated with the original backup. +3. If the TiDB Cloud account in the key policy is the same as the TiDB Cloud account associated with the original backup TiDB instance, no further authorization is required +4. If the TiDB Cloud account in the key policy is different from the TiDB Cloud account associated with the original backup TiDB instance, you must copy the provided key policy and update it in your AWS KMS. This re-authorizes the key and ensures the new instance can access it. + +#### Service-Managed Encryption Key + +If the backup is encrypted using a Service-Managed Encryption Key, the restored instance will automatically inherit the same key type. During the restore process, you will see that encryption is enabled by default and the key type is set to **Service-Managed Encryption Key**. + + +### Rotate Customer-Managed Encryption Key (CMEK) + +You can configure [automatic CMEK rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) in AWS KMS. No configuration updates are required in TiDB Cloud. + From 3c20daac0bbfb86817d6a5fefeb9beac3f282710 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 28 Apr 2026 13:28:16 +0800 Subject: [PATCH 07/17] Update tidb-cloud-encrypt-cmek-aws-premium.md --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index fed076456e2d0..5370d49ce8062 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -6,6 +6,11 @@ aliases: ['/tidbcloud/premium/tidb-cloud-encrypt-cmek'] # Dual-layer Data Encryption +> **Note:** +> +> Currently, the Dual-layer Data Encryption feature is only available upon request. To request access, click **?** in the lower-right corner of the [TiDB Cloud console](https://tidbcloud.com), and then click **Support Tickets** to go to the [Help Center](https://tidb.support.pingcap.com/servicedesk/customer/portals). Create a ticket, fill in "Apply for Dual-layer Data Encryption" in the **Description** field, and then click **Submit**. + + ## Overview {{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, {{{ .premium }}} allows you to combine TiDB service's storage engine encryption with your cloud provider's KMS, adding another layer of data encryption (Dual-layer Data Encryption). From 7d9309dfaf61d28eeb68d30e3ec609505f53f9fe Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 28 Apr 2026 15:03:36 +0800 Subject: [PATCH 08/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index 5370d49ce8062..4e039488023af 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -137,7 +137,7 @@ If the backup is encrypted using a CMEK, you must verify that the new instance c 1. The key ARN will remain unchanged. Click **Check** to proceed with the trust policy verification. 2. The system will check if the authorized TiDB Cloud account in the key policy matches the one associated with the original backup. -3. If the TiDB Cloud account in the key policy is the same as the TiDB Cloud account associated with the original backup TiDB instance, no further authorization is required +3. If the TiDB Cloud account in the key policy is the same as the TiDB Cloud account associated with the original backup TiDB instance, no further authorization is required. 4. If the TiDB Cloud account in the key policy is different from the TiDB Cloud account associated with the original backup TiDB instance, you must copy the provided key policy and update it in your AWS KMS. This re-authorizes the key and ensures the new instance can access it. #### Service-Managed Encryption Key From 2ed8a3bd9f89cb29bcdd21856a02c920e9285462 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 28 Apr 2026 15:04:11 +0800 Subject: [PATCH 09/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index 4e039488023af..a58599d03b9b6 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -117,7 +117,7 @@ Before proceeding, ensure you have created a symmetric encryption key in your AW #### Option 2: Service-Managed Encryption Key To let TiDB Cloud automatically manage the encryption key for you, follow these steps: -1. On the Security page of your {{{ .premium }}} instance , click **Enable** in the Dual-layer Data Encryption section. +1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** in the Dual-layer Data Encryption section. 2. Select **Service-Managed Encryption Key**. 3. Click **Enable**. From c21abdd40570553a1cbaba7c0db342d4468b639e Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 29 Apr 2026 10:24:06 +0800 Subject: [PATCH 10/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index a58599d03b9b6..090b67d86bf9f 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -12,7 +12,7 @@ aliases: ['/tidbcloud/premium/tidb-cloud-encrypt-cmek'] ## Overview -{{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, {{{ .premium }}} allows you to combine TiDB service's storage engine encryption with your cloud provider's KMS, adding another layer of data encryption (Dual-layer Data Encryption). +{{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, you can combine the TiDB service's storage engine encryption with your cloud provider's Key Management Service (KMS) to add another layer of data encryption (Dual-layer Data Encryption). ### Encryption mechanism From 10aa38d25c62c08561cf29fd792d8a5b662faf59 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 29 Apr 2026 10:24:25 +0800 Subject: [PATCH 11/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index 090b67d86bf9f..05f43a999be53 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -106,7 +106,7 @@ If you did not enable encryption during cluster creation, you can still enable i Before proceeding, ensure you have created a symmetric encryption key in your AWS KMS. Then, follow these steps: -1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** for in the Dual-layer Data Encryption section. +1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** in the Dual-layer Data Encryption section. 2. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. 3. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. 4. In your AWS KMS console, add this trust policy to your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). From c72cbe8ae5e056548cdf31d43ad06645e80036f8 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 29 Apr 2026 10:25:39 +0800 Subject: [PATCH 12/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index 05f43a999be53..262d5c63c1512 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -81,7 +81,7 @@ Before proceeding, you must create a symmetric encryption key in AWS KMS. Ensure 5. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. 6. In your AWS KMS Console, add this trust relationship to the your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). 7. Return to the TiDB Cloud console, scroll to the bottom of the key creation page, and enter the **KMS Key ARN** obtained from AWS KMS. -8. Click **Test and Add KMS Key ARN** to verigy the key trust relationship. +8. Click **Test and Add KMS Key ARN** to verify the key trust relationship. 9. Once the verification passes, Click **Create** to finish creating your {{{ .premium }}} instance. #### Option 2: Service-Managed Encryption Key From 6c6a111641a21819f4160895fa7ca9ddd840be03 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 29 Apr 2026 10:26:06 +0800 Subject: [PATCH 13/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index 262d5c63c1512..8b5d6cdf32242 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -38,7 +38,7 @@ Since accessing the backup data relies on the originally configured KMS master k ### Key Management Mechanism -Premium's Dual-layer Data Encryption uses AWS KMS to manage master keys for data-at-rest encryption. Depending on your compliance and maintenance requirements, you can choose between two key management options： +Premium's Dual-layer Data Encryption uses AWS KMS to manage master keys for data-at-rest encryption. Depending on your compliance and maintenance requirements, you can choose between two key management options: 1. **Customer-Managed Encryption Key (CMEK)**: You provide and manage your own AWS KMS master key. This option offers maximum control over your encryption, making it ideal for organizations prioritizing strict security. - **Important:** You are fully responsible for maintaining the key's security and availability. If the configured CMEK is deleted, your Premium TiDB instance will malfunction, and the encrypted data will become permanently unrecoverable. From 138b3c89ef6b8ebeccb0725a9953ae4730b79182 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 29 Apr 2026 10:26:19 +0800 Subject: [PATCH 14/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index 8b5d6cdf32242..139591e06a481 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -28,7 +28,7 @@ To provide the highest level of data security, {{{ .premium }}} TiDB adopts a tw - Unlike default storage encryption, this feature can be managed by users, allowing you to choose either a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key based on your security compliance and operational requirements. -#### Backup & Restore Description +#### Backup and restore description When Dual-layer Data Encryption is enabled, the backup data for your {{{ .premium }}} TiDB instance is also encrypted. Any new instance restored from this backup will natively inherit the encryption attributes and KMS master key of the original instance. Since accessing the backup data relies on the originally configured KMS master key, please ensure the following: From 40bb337dc4b394e56febee7a3a687689bdb75811 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 29 Apr 2026 10:26:40 +0800 Subject: [PATCH 15/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index 139591e06a481..f3a11f3c535c6 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -41,7 +41,7 @@ Since accessing the backup data relies on the originally configured KMS master k Premium's Dual-layer Data Encryption uses AWS KMS to manage master keys for data-at-rest encryption. Depending on your compliance and maintenance requirements, you can choose between two key management options: 1. **Customer-Managed Encryption Key (CMEK)**: You provide and manage your own AWS KMS master key. This option offers maximum control over your encryption, making it ideal for organizations prioritizing strict security. -- **Important:** You are fully responsible for maintaining the key's security and availability. If the configured CMEK is deleted, your Premium TiDB instance will malfunction, and the encrypted data will become permanently unrecoverable. +- **Important:** You are fully responsible for maintaining the key's security and availability. If the configured CMEK is deleted, your {{{ .premium }}} TiDB instance malfunctions, and the encrypted data becomes permanently unrecoverable. 2. **Service-Managed Encryption Key**：TiDB Cloud Premium automatically provisions and maintains the KMS master key for you, offering a balance of security and convenience with zero maintenance overhead. - Key Characteristics: From e865fef2094412b9e793ab24aad67c812638cdb1 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Wed, 29 Apr 2026 10:27:02 +0800 Subject: [PATCH 16/17] Update tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md index f3a11f3c535c6..0e4990029642c 100644 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md @@ -100,7 +100,7 @@ If you did not enable encryption during cluster creation, you can still enable i > **Note:** > -> Enable Encryption on an existing instance requires some time to complete the activation process. +Enabling encryption on an existing instance takes some time to complete. #### Option 1: Customer-Managed Encryption Key (CMEK) From 7b5c8de7f1da6cafa946cf4dc945827f74ba84fb Mon Sep 17 00:00:00 2001 From: Aolin Date: Tue, 28 Apr 2026 18:05:56 +0800 Subject: [PATCH 17/17] cloud: update Dual-Layer Data Encryption for Premium --- TOC-tidb-cloud-premium.md | 1 + tidb-cloud/manage-projects-and-resources.md | 5 + .../dual-layer-data-encryption-premium.md | 163 ++++++++++++++++++ .../tidb-cloud-encrypt-cmek-aws-premium.md | 151 ---------------- tidb-cloud/security-concepts.md | 18 ++ tidb-cloud/security-overview.md | 12 ++ 6 files changed, 199 insertions(+), 151 deletions(-) create mode 100644 tidb-cloud/premium/dual-layer-data-encryption-premium.md delete mode 100644 tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md diff --git a/TOC-tidb-cloud-premium.md b/TOC-tidb-cloud-premium.md index 64bae50b8cb26..afb8d3161453c 100644 --- a/TOC-tidb-cloud-premium.md +++ b/TOC-tidb-cloud-premium.md @@ -240,6 +240,7 @@ - [Configure Firewall Rules for Public Endpoints](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md) - [TLS Connections to TiDB Cloud](/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md) - Data Access Control + - [Dual-Layer Data Encryption](/tidb-cloud/premium/dual-layer-data-encryption-premium.md) - [User-Controlled Log Redaction](/tidb-cloud/tidb-cloud-log-redaction.md) - Audit Management - [Database Audit Logging](/tidb-cloud/premium/tidb-cloud-auditing-premium.md) diff --git a/tidb-cloud/manage-projects-and-resources.md b/tidb-cloud/manage-projects-and-resources.md index e3a926f72bbb2..8efd287ad0279 100644 --- a/tidb-cloud/manage-projects-and-resources.md +++ b/tidb-cloud/manage-projects-and-resources.md @@ -97,6 +97,11 @@ To create a new project, take the following steps: 3. Depending on which type of TiDB Cloud resources you are creating the project for, do one of the following: - If the project is created for TiDB X instances, click **Confirm**. + + > **Note:** + > + > For {{{ .premium }}} instances, encryption is configured per instance rather than per project. After you create the instance, you can enable [Dual-Layer Data Encryption](/tidb-cloud/premium/dual-layer-data-encryption-premium.md) to add a database-layer encryption on top of the default storage-layer encryption. + - If the project is created for {{{ .dedicated }}} clusters, select the **Create for Dedicated Cluster** option, configure [Customer-Managed Encryption Keys (CMEK)](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md) and [maintenance window](/tidb-cloud/configure-maintenance-window.md) for the project, and then click **Confirm**. ### Manage a project diff --git a/tidb-cloud/premium/dual-layer-data-encryption-premium.md b/tidb-cloud/premium/dual-layer-data-encryption-premium.md new file mode 100644 index 0000000000000..d9ed1f55f55c8 --- /dev/null +++ b/tidb-cloud/premium/dual-layer-data-encryption-premium.md @@ -0,0 +1,163 @@ +--- +title: Dual-Layer Data Encryption +summary: Learn how to enable and manage Dual-Layer Data Encryption for your {{{ .premium }}} instance hosted on AWS. +--- + +# Dual-Layer Data Encryption + +This document describes how to enable and manage Dual-Layer Data Encryption for your {{{ .premium }}} instance hosted on AWS. + +> **Note:** +> +> Currently, the Dual-Layer Data Encryption feature is only available upon request. To request this feature, click **?** in the lower-right corner of the [TiDB Cloud console](https://tidbcloud.com), and then click **Support Tickets** to go to the [Help Center](https://tidb.support.pingcap.com/servicedesk/customer/portals). Create a ticket, fill in "Apply for Dual-Layer Data Encryption" in the **Description** field, and then click **Submit**. + +## Overview + +By default, {{{ .premium }}} encrypts data at rest on instance storage and snapshot volumes, providing a baseline level of data security. In addition, {{{ .premium }}} supports combining TiDB storage engine encryption with your cloud provider's Key Management Service (KMS). This additional layer is called **Dual-Layer Data Encryption**. + +### Encryption mechanism + +To provide a higher level of data security, {{{ .premium }}} uses a two-layer architecture for data-at-rest encryption. Both storage-layer and database-layer encryption protect your data. + +- **Storage-layer encryption** + + - The underlying cloud service provider provides storage-layer encryption on its storage infrastructure. For example, on AWS, this includes Amazon Elastic Block Store (EBS) volume encryption and Amazon Simple Storage Service (S3) bucket encryption. + - This layer is enabled by default for all {{{ .premium }}} instances and cannot be disabled. It provides the foundational security baseline for data at rest. + +- **Database-layer encryption** + + - In addition to storage-layer encryption, {{{ .premium }}} supports an optional database-layer encryption feature (labeled **Dual-Layer Data Encryption** in the TiDB Cloud console). When you enable it, the feature encrypts data stored in TiKV, changefeed data, and backup data. + - This mechanism keeps data encrypted within the database system, which reduces the risk of data leakage during internal processing and data movement. + - Unlike storage-layer encryption, database-layer encryption is user-configurable. You can choose either a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key, depending on your security compliance and operational requirements. + +### Backup and restore considerations + +When you enable Dual-Layer Data Encryption, the backup data for your {{{ .premium }}} instance is also encrypted. Any new instance restored from this backup inherits the encryption attributes and KMS master key of the original instance. + +Because backup data requires the original KMS master key for access, make sure that you meet the following requirements: + +- **Maintain key availability**: even if you delete the original {{{ .premium }}} instance, keep the associated KMS master key active so that you can recover the backup data. +- **Ensure correct authorization**: during a restore operation, configure the exact same KMS master key that is associated with the backup, and make sure that the key has the required permissions for data access. + +### Key management options + +Dual-Layer Data Encryption uses AWS KMS to manage master keys for data-at-rest encryption. You can choose between two key management options: + +- **Customer-Managed Encryption Key (CMEK)** + + You create, own, and manage your AWS KMS master key. This option provides full control over encryption and is suitable for organizations with strict security requirements. + + > **Warning:** + > + > You are fully responsible for maintaining the key's security and availability. If you delete the configured CMEK, your {{{ .premium }}} instance becomes unusable, and you cannot recover the encrypted data. + +- **Service-Managed Encryption Key** + + {{{ .premium }}} automatically creates and manages the KMS master key on your behalf. This option offers a balance of security and convenience with no maintenance overhead. + + - The key is a symmetric encryption key. + - The key is generated automatically when you create your first encrypted {{{ .premium }}} instance in a given region. + - A single key is created per organization per region and is shared across all {{{ .premium }}} instances in that region. + - The key is automatically deleted only after all data encrypted with it has been removed from your organization. + +## Limitations + +- This feature currently supports only AWS KMS. Support for Alibaba Cloud KMS is planned for a future release. +- Data encryption applies to data stored by TiKV, changefeed data, and backup data. Support for TiFlash data encryption is planned for a future release. +- After you enable Dual-Layer Data Encryption, you cannot modify the encryption configuration of the {{{ .premium }}} instance. +- Custom encryption algorithms are not supported. You can rotate only the KMS master key. Rotating other encryption keys is not supported. +- Your AWS KMS key must be in the same region as your {{{ .premium }}} instance. As a result, cross-region restore operations are not supported for backups that use a CMEK. + +## Enable Dual-Layer Data Encryption + +You can enable Dual-Layer Data Encryption either when you create a {{{ .premium }}} instance or after instance creation. + +### Enable encryption during instance creation + +When you create a {{{ .premium }}} instance, you can enable Dual-Layer Data Encryption. Depending on your security and operational requirements, choose either a **Customer-Managed Encryption Key (CMEK)** or a **Service-Managed Encryption Key**. + +#### Option 1: Customer-Managed Encryption Key (CMEK) + +To use your own encryption key, take the following steps: + +1. Create a symmetric encryption key in AWS KMS. + + The key must be in the **same region** as the planned {{{ .premium }}} instance. For detailed instructions, see [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html). + +2. Configure the CMEK in the [TiDB Cloud console](https://tidbcloud.com): + + 1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click **Create Resource**. + 2. Select the {{{ .premium }}} plan and complete the basic configuration. + 3. In the **Dual-Layer Data Encryption** section, click **Enable**. + 4. Select **Customer-Managed Encryption Key (CMEK)**, and then click **Add KMS Key ARN**. + 5. Copy the displayed JSON policy and save it as `ROLE-TRUST-POLICY.JSON`. This file defines the required trust relationship. + 6. In the AWS KMS console, add this trust policy to your key. For more information, see [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). + 7. Return to the TiDB Cloud console, scroll to the bottom of the key creation page, and enter the **KMS Key ARN** that you obtained from AWS KMS. + 8. To verify the trust relationship, click **Test and Add KMS Key ARN**. + 9. After the verification succeeds, click **Create** to finish creating your {{{ .premium }}} instance. + +#### Option 2: Service-Managed Encryption Key + +To let TiDB Cloud manage the encryption key on your behalf, take the following steps: + +1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click **Create Resource**. +2. Select the {{{ .premium }}} plan and complete the basic configuration. +3. In the **Dual-Layer Data Encryption** section, click **Enable**. +4. Select **Service-Managed Encryption Key**. +5. Click **Create** to finish creating your {{{ .premium }}} instance. + +### Enable encryption for an existing instance + +If you do not enable encryption when creating an instance, you can enable it later. Depending on your requirements, choose either a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key. + +> **Note:** +> +> Enabling encryption on an existing instance might take some time to complete. + +#### Option 1: Customer-Managed Encryption Key (CMEK) + +Before you begin, make sure that you have created a symmetric encryption key in AWS KMS. Then, take the following steps: + +1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** in the **Dual-Layer Data Encryption** section. +2. Select **Customer-Managed Encryption Key (CMEK)**, and then click **Add KMS Key ARN**. +3. Copy the displayed JSON policy and save it as `ROLE-TRUST-POLICY.JSON`. This file defines the required trust relationship. +4. In the AWS KMS console, add this trust policy to your key. For more information, see [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). +5. Return to the TiDB Cloud console, scroll to the bottom of the page, and enter the **KMS Key ARN** that you obtained from AWS KMS. +6. To verify the trust relationship, click **Test and Add KMS Key ARN**. +7. To enable Dual-Layer Data Encryption, click **Enable**. + +#### Option 2: Service-Managed Encryption Key + +To let TiDB Cloud manage the encryption key on your behalf, take the following steps: + +1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** in the **Dual-Layer Data Encryption** section. +2. Select **Service-Managed Encryption Key**. +3. Click **Enable**. + +## View encryption status + +After you enable encryption, check the status in the following places: + +- On the **Overview** page of your {{{ .premium }}} instance, the **Encryption** field shows the active key management method: either **Enabled with Customer-Managed Encryption Key (CMEK)** or **Enabled with Service-Managed Encryption Key**. +- On the **Security** page, you can view detailed configuration of Dual-Layer Data Encryption. + +## Restore from an encrypted backup + +Backups created from an encrypted {{{ .premium }}} instance are also encrypted. When you restore an encrypted backup, the new instance must use consistent encryption settings. + +### Restore a backup encrypted with a CMEK + +If the backup is encrypted with a CMEK, make sure that the new instance can access the KMS master key during the restore. The key ARN remains unchanged. + +To verify access, click **Check** to start the trust policy verification. TiDB Cloud then checks whether the authorized TiDB Cloud account in the key policy matches the account that is associated with the original backup: + +- If the accounts match, no further authorization is required. +- If the accounts do not match, copy the provided key policy and update it in AWS KMS. This update re-authorizes the key and ensures that the new instance can access it. + +### Restore a backup encrypted with a Service-Managed Encryption Key + +If the backup is encrypted with a Service-Managed Encryption Key, the restored instance automatically inherits the same key type. During restore, encryption is enabled by default, and the key type is set to **Service-Managed Encryption Key**. + +## Rotate a Customer-Managed Encryption Key (CMEK) + +To rotate a CMEK, you can [enable automatic key rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotating-keys-enable.html) in AWS KMS. No additional TiDB Cloud configuration is required. diff --git a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md b/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md deleted file mode 100644 index 0e4990029642c..0000000000000 --- a/tidb-cloud/premium/tidb-cloud-encrypt-cmek-aws-premium.md +++ /dev/null @@ -1,151 +0,0 @@ ---- -title: Dual-layer Data Encryption -summary: Learn how to enable Dual-layer Data Encryption on {{{ .premium }}} TiDB. -aliases: ['/tidbcloud/premium/tidb-cloud-encrypt-cmek'] ---- - -# Dual-layer Data Encryption - -> **Note:** -> -> Currently, the Dual-layer Data Encryption feature is only available upon request. To request access, click **?** in the lower-right corner of the [TiDB Cloud console](https://tidbcloud.com), and then click **Support Tickets** to go to the [Help Center](https://tidb.support.pingcap.com/servicedesk/customer/portals). Create a ticket, fill in "Apply for Dual-layer Data Encryption" in the **Description** field, and then click **Submit**. - - -## Overview -{{{ .premium }}} enables data encryption at rest by default on TiDB service instance storage and snapshot volumes. This provides basic encryption capabilities to enhance data security. Building on this, you can combine the TiDB service's storage engine encryption with your cloud provider's Key Management Service (KMS) to add another layer of data encryption (Dual-layer Data Encryption). - -### Encryption mechanism - -To provide the highest level of data security, {{{ .premium }}} TiDB adopts a two-tier architecture for data-at-rest encryption. Your data is safeguarded by both Storage-layer and Database-layer protections. - -- Storage-layer Data Encryption - - This is the underlying data encryption directly implemented by cloud service providers on their storage infrastructure. For example, on AWS, this includes EBS volume encryption and S3 bucket encryption. - - This layer of encryption is enabled by default for all {{{ .premium }}} instances and cannot be disabled. It serves as the foundational security baseline for your data. - -- Database-layer Encryption - - Building on top of the storage-layer encryption, TiDB Cloud allows you to add an extra layer of data encryption at the database level (labeled as **Dual-layer Data Encryption** in the console). Once enabled, static data encryption specifically covers TiKV's stored data and BR's backup data. - - The TiDB database system ensures that data remains encrypted at rest within the system, thereby effectively reducing the risk of data leakage during subsequent data transfers. - - Unlike default storage encryption, this feature can be managed by users, allowing you to choose either a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key based on your security compliance and operational requirements. - - -#### Backup and restore description -When Dual-layer Data Encryption is enabled, the backup data for your {{{ .premium }}} TiDB instance is also encrypted. Any new instance restored from this backup will natively inherit the encryption attributes and KMS master key of the original instance. - -Since accessing the backup data relies on the originally configured KMS master key, please ensure the following: - -- **Maintain key availability**: Even if you delete the original Premium TiDB instance, the associated KMS master key must remain active to successfully recover the backup data. -- **Ensure correct authorization**: During a restore operation, you must configure the exact same KMS master key associated with the backup and ensure it has the proper permissions for data access. - -### Key Management Mechanism - -Premium's Dual-layer Data Encryption uses AWS KMS to manage master keys for data-at-rest encryption. Depending on your compliance and maintenance requirements, you can choose between two key management options: - -1. **Customer-Managed Encryption Key (CMEK)**: You provide and manage your own AWS KMS master key. This option offers maximum control over your encryption, making it ideal for organizations prioritizing strict security. -- **Important:** You are fully responsible for maintaining the key's security and availability. If the configured CMEK is deleted, your {{{ .premium }}} TiDB instance malfunctions, and the encrypted data becomes permanently unrecoverable. - -2. **Service-Managed Encryption Key**：TiDB Cloud Premium automatically provisions and maintains the KMS master key for you, offering a balance of security and convenience with zero maintenance overhead. -- Key Characteristics: - - It is a symmetric encryption key. - - It is automatically generated when you create your first encrypted Premium TiDB instance in a specific region. - - TiDB Cloud creates one key per organization per region, which is shared across all your Premium instances within that region. - - The key is automatically removed only after all data encrypted by it within your organization has been completely deleted - -## Limitations - -- Currently, this feature only supports AWS KMS. Support for Alibaba Cloud KMS and Azure Key Vault will be available soon. -- Data encryption applies to TiKV, CDC, and BR components. Support for TiFlash data encryption is coming soon. -- Once Dual-layer Data Encryption is enabled, the encryption properties of the {{{ .premium }}} instance cannot be modified. -- Custom encryption algorithms are not supported. Additionally, you can only rotate the KMS master key; rotation of other keys is not supported. -- Your AWS KMS key must reside in the same region as your TiDB instance. Consequently, cross-region restore operations are not supported for CMEK-encrypted backups. - -## Enable and Manage Encryption - -### Enable encryption during instance creation - -You can enable Dual-layer Data Encryption when creating a new {{{ .premium }}} instance. Depending on your security compliance and maintenance requirements, you can choose between two key management options: **Customer-Managed Encryption Key (CMEK)** or **Service-Managed Encryption Key**. - -#### Option 1: Customer-Managed Encryption Key (CMEK) - -To use your own encryption key, follow these steps: - -- **Step 1. Create a symmetric encryption key in your AWS KMS (Preparation)** - -Before proceeding, you must create a symmetric encryption key in AWS KMS. Ensure the key resides in the **same region** as your planned TiDB service. For detailed instructions, see [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html). - -- **Step 2. Configure CMEK in TiDB Cloud** - -1. On the **My TiDB** page, click **Create Resource**. -2. Select the {{{ .premium }}} plan and complete the basic instance configuration. -3. In **Dual-Layer Data Encryption** section, click **Enable**. -4. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. -5. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. -6. In your AWS KMS Console, add this trust relationship to the your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). -7. Return to the TiDB Cloud console, scroll to the bottom of the key creation page, and enter the **KMS Key ARN** obtained from AWS KMS. -8. Click **Test and Add KMS Key ARN** to verify the key trust relationship. -9. Once the verification passes, Click **Create** to finish creating your {{{ .premium }}} instance. - -#### Option 2: Service-Managed Encryption Key - -To let TiDB Cloud automatically manage the encryption key for you, follow these steps: - -1. On the **My TiDB** page, click **Create Resource**. -2. Select the {{{ .premium }}} plan and complete the basic instance configuration. -3. In **Dual-Layer Data Encryption** section, click **Enable**. -4. Select **Service-Managed Encryption Key**. -5. Click **Create** to finish creating your {{{ .premium }}} instance. - -### Enable Encryption for an existing instance - -If you did not enable encryption during cluster creation, you can still enable it later. Depending on your requirements, you can choose between a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key. - -> **Note:** -> -Enabling encryption on an existing instance takes some time to complete. - -#### Option 1: Customer-Managed Encryption Key (CMEK) - -Before proceeding, ensure you have created a symmetric encryption key in your AWS KMS. Then, follow these steps: - -1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** in the Dual-layer Data Encryption section. -2. Select **Customer-Managed Encryption Key (CMEK)** and click **Add KMS Key ARN**. -3. Copy the displayed JSON policy and save it as ROLE-TRUST-POLICY.JSON. This file describes the required trust relationship. -4. In your AWS KMS console, add this trust policy to your key. For more information, refer to [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). -5. Return to the TiDB Cloud console, scroll to the bottom of the page, and enter the **KMS Key ARN** obtained from AWS KMS. -6. Click **Test and Add KMS Key ARN** to check the key trust relationship. -7. Click **Enable** to enable the Dual-layer Data Encryption feature. - -#### Option 2: Service-Managed Encryption Key - -To let TiDB Cloud automatically manage the encryption key for you, follow these steps: -1. On the **Security** page of your {{{ .premium }}} instance, click **Enable** in the Dual-layer Data Encryption section. -2. Select **Service-Managed Encryption Key**. -3. Click **Enable**. - -### View encryption status - -Once encryption is enabled, you can verify its status and configuration details in the following two places: -- Check the **Encryption** property on the **Overview** page of the instance to see the active key management method (either **Enabled with Customer-Managed Encryption Key (CMEK)** or **Enabled with Service-Managed Encryption Key**). -- Navigate to the Security page to view the detailed configuration properties of your Dual-layer Data Encryption. - -### Restore from an encrypted backup - -Backups generated from an encrypted {{{ .premium }}} instance are also encrypted. When restoring such a backup to a new instance, the restored instance must maintain consistent encryption properties. - -#### Customer-Managed Encryption Key (CMEK) - -If the backup is encrypted using a CMEK, you must verify that the new instance can correctly access the KMS master key during the restore process: - -1. The key ARN will remain unchanged. Click **Check** to proceed with the trust policy verification. -2. The system will check if the authorized TiDB Cloud account in the key policy matches the one associated with the original backup. -3. If the TiDB Cloud account in the key policy is the same as the TiDB Cloud account associated with the original backup TiDB instance, no further authorization is required. -4. If the TiDB Cloud account in the key policy is different from the TiDB Cloud account associated with the original backup TiDB instance, you must copy the provided key policy and update it in your AWS KMS. This re-authorizes the key and ensures the new instance can access it. - -#### Service-Managed Encryption Key - -If the backup is encrypted using a Service-Managed Encryption Key, the restored instance will automatically inherit the same key type. During the restore process, you will see that encryption is enabled by default and the key type is set to **Service-Managed Encryption Key**. - - -### Rotate Customer-Managed Encryption Key (CMEK) - -You can configure [automatic CMEK rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) in AWS KMS. No configuration updates are required in TiDB Cloud. - diff --git a/tidb-cloud/security-concepts.md b/tidb-cloud/security-concepts.md index 03b6c2fdc7bd2..b94e8978921f4 100644 --- a/tidb-cloud/security-concepts.md +++ b/tidb-cloud/security-concepts.md @@ -225,6 +225,8 @@ TiDB Cloud ensures secure connectivity and data transmission through robust netw TiDB Cloud safeguards static data with advanced encryption capabilities, ensuring security and compliance with industry regulations. + + **Customer-Managed Encryption Key (CMEK)** - Provides organizations full control over encryption for TiDB Cloud Dedicated clusters. @@ -243,6 +245,22 @@ TiDB Cloud safeguards static data with advanced encryption capabilities, ensurin For more information, see [Encryption at Rest Using Customer-Managed Encryption Keys on AWS](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md) and [Encryption at Rest Using Customer-Managed Encryption Keys on Azure](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md). + + + + +**Dual-Layer Data Encryption** + +- Combines storage-layer encryption (provided by the cloud provider) with database-layer encryption to add an additional layer of data-at-rest protection for {{{ .premium }}} instances hosted on AWS. + +- Encrypts data stored by TiKV, changefeed data, and backup data when enabled. + +- Lets you choose between a Customer-Managed Encryption Key (CMEK) and a Service-Managed Encryption Key, depending on your security and operational requirements. + +For more information, see [Dual-Layer Data Encryption](/tidb-cloud/premium/dual-layer-data-encryption-premium.md). + + + ## Audit logging TiDB Cloud provides comprehensive audit logging to monitor user activities and database operations, ensuring security, accountability, and compliance. diff --git a/tidb-cloud/security-overview.md b/tidb-cloud/security-overview.md index be79f77f48377..f18979ee9a636 100644 --- a/tidb-cloud/security-overview.md +++ b/tidb-cloud/security-overview.md @@ -21,12 +21,24 @@ You can encrypt all communications using TLS to ensure the confidentiality and i ## Data access control + + For {{{ .dedicated }}} clusters with Customer-Managed Encryption Keys (CMEK) enabled, TiDB Cloud provides encryption for both data at rest and backups. Combined with robust key management mechanisms, you can control the lifecycle and usage of encryption keys, further enhancing data security and compliance. For more information, see [Encryption at Rest Using Customer-Managed Encryption Keys on AWS](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md) and [Encryption at Rest Using Customer-Managed Encryption Keys on Azure](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md). + + + + +For {{{ .premium }}} instances hosted on AWS, you can enable Dual-Layer Data Encryption to add a database-layer encryption on top of the default storage-layer encryption. With Dual-Layer Data Encryption enabled, TiDB Cloud encrypts data stored by TiKV, changefeed data, and backup data, and you can choose either a Customer-Managed Encryption Key (CMEK) or a Service-Managed Encryption Key. + +For more information, see [Dual-Layer Data Encryption](/tidb-cloud/premium/dual-layer-data-encryption-premium.md). + + + ## Database access control TiDB Cloud provides a user- and role-based access control mechanism, combining static and dynamic privileges. You can assign roles to users to manage and distribute permissions in a more fine-grained way.