PolarDB:Confidential database

Prerequisites

The PolarProxy version in PolarDB is 2.8.36 or later. For information about how to view or update the version of your PolarProxy, see Revision version management.

Background information

The regulatory requirements and industrial standards nowadays necessitate the adoption of robust security measures that span the entire lifecycle of data, and the traditional third-party security hardening and client-based encryption no longer suffice due to their deficiencies in cost, architecture adaptation, and database performance. In this context, databases that support end-to-end encryption is gaining popularity across the industry. PolarDB also provides PolarDB always-confidential as the answer to such requirements.  

This feature can best deliver its advantages in the following scenarios:

• Storing your data in untrusted environments: These scenarios include storing your data on the cloud or in on-premises data centers of your customers, which may lead to unauthorized access by the cloud service provider and the O&M personnel of your organization and your customers.  

• Using data management services by third-party providers: This may expose your business secrets to the service providers. This is especially risky if your data includes sensitive data such as personal identification information and genetic data.  

• Sharing your data with other organizations: These scenarios include collaborative risk management and international service provision, where organizations involved are restricted by data compliance requirements and cannot share plaintext data directly. They also include the scenarios where you conduct marketing with other companies and want to protect your data due to the competitive relationships.

Features

• This feature supports all existing SQL operators and is transparent to applications. You can switch to the EncJDBC confidential client driver by changing only a few lines of configuration. No changes to your business code are required, which simplifies the upgrade process. For more information about the configuration, see Integrate EncJDBC.

• Query results are returned encrypted. This protects against data theft from database account leaks or by development and O&M personnel. You can configure encryption rules to specify which sensitive data requires protection. When the confidential database returns data marked as sensitive, it automatically encrypts that data using your key. Only users who have the key can decrypt the content and view the plaintext. Therefore, even if a database account is compromised, the sensitive data in query results remains unreadable. This means that development and O&M engineers can view only the ciphertext.

• This feature supports custom master keys. You can use a trusted existing or third-party Key Management Service (KMS). After you obtain the desired key, you can pass it dynamically to the confidential client. This ensures that only you hold the key. At runtime, the key participates in database queries through a secure distribution mechanism and is automatically destroyed when the service ends. This prevents the key from being stolen by external or internal parties.

• Performance is comparable to that of a standard, non-encrypted database. Query performance is inversely proportional to the number of specified sensitive fields. The more sensitive data a query involves, the greater the performance impact. In TPC-C tests where 20%, 50%, and 100% of fields were encrypted, the performance was 93%, 86%, and 79% of a plaintext database, respectively. For more performance data, see Confidential Database Performance Test Report.

Scenarios

We developed PolarDB always-confidential in a bid to deliver the next-generation database framework and products that come with the capabilities to ensure data confidentiality and integrity. With an optimal design, the database can provide security capabilities while ensuring high performance, stability, and cost-efficiency.

The following are several typical scenarios for PolarDB always-confidential:

• Encrypting data to be transmitted from applications to databases

  In most cases, application providers are the owners of data, who commonly want to prevent the database service and its O&M personnel from accessing the business data.

• Encrypting data to be transmitted from users to applications

  In some applications for personal use, part of the data such as those related to health and finance, is owned by the users, who commonly expect the applications not to be able to access the data itself in plaintext when managing and analyzing their data.

• Sharing encrypted data in a secure and reliable manner

  The key used for encryption is available only to the data owners. When the data owners need to share data with others, they want to do it without exposing the keys, thereby meeting compliance requirements.

Limitations

• The encryption rules do not take effect on primary endpoints. You need to use the cluster endpoint or a custom cluster endpoint.

• The PolarDB always-confidential feature supports only COM_QUERY commands. Other command types such as COM_STMT_PREPARE are not supported. EncJDBC only supports Text Protocol. Binary Protocol is not supported. Operations that leverage prepared statements are always completed through Text Protocol queries.

• PolarDB always-confidential and dynamic masking cannot be enabled at the same time.

• If dynamic masking rules exist, to enable PolarDB always-confidential, you need to delete all existing masking rules and create new rules whose type is encryption.

• CMKs cannot be modified after they are specified. The entire cluster uses the same CMK.

• If you bypass SecureGW and directly connect to the native MySQL kernel, the encryption feature does not take effect. We recommend that you avoid doing this. To minimize the impact of unauthorized access, we also recommend that you enable other security features like log auditing.

Usage

For more information, see Mange encryption rules.