本文主要介绍了PolarDB数据库代理（Proxy）提供的全密态PolarMySQL功能。

前提条件

PolarDB数据库代理版本需为2.8.36或以上。如何查看和升级当前数据库代理版本，请参见小版本升级。

背景信息

随着国家对数据安全和个人敏感信息的加强监管，原子化的数据安全能力无法满足监管要求，国家标准和行业标准逐渐提出数据全生命周期的安全保障的需求，传统的三方安全加固和客户端加密都在客户成本、架构改造、数据库性能等带来了不同层面的弊端，因此全密态数据库得到了快速发展和行业认可。

从应用视角看，全密态数据库可以解决不同应用场景下的数据安全问题，几种典型场景如下：

平台安全运维：该场景主要针对在不可信环境（如第三方平台）下提供的数据库服务的安全防护，保证用户数据在运维过程中的安全。例如，业务将应用数据库迁移到云上，需要应对云平台以及运维人员越权访问数据的潜在威胁；再如，数据应用需要将数据库整体线下部署到客户线下环境，需要防止数据被客户运维非授权获取。
敏感数据合规：该场景主要针对在不可信环境（如第三方平台）下提供的应用服务的安全防护，保证终端用户敏感数据的安全。例如，企业使用第三方服务管理其商业数据时，需要应对商业秘密被服务商获取的潜在威胁；再如，个人识别数据（PII）、基因等隐私数据在被第三方管理过程中，要满足全程加密的合规要求。
多源数据融合：该场景主要针对多源数据的联合分析，保证在多方数据融合计算时，数据不会被其他参与方获取。例如，在联合风控、跨国服务等场景下，有严格的数据合规要求，组织间无法进行明文数据的合规化获取；再如，在合作营销等场景下，存在组织间的既合作又竞争的复杂关系，难以进行明文数据共享。

功能介绍

支持所有已有的SQL算子，且应用透明无感知，升级“0”成本。仅需几行配置即可切换到全密态客户端驱动EncJDBC，已有业务代码无需任何修改即可接入。具体配置过程请参见集成EncJDBC。
全密态MySQL也提供了EncDB SDK，应用可以基于业务逻辑，灵活调用SDK提供的安全接口。EncDB SDK的使用说明请参见集成EncDB SDK。
查询结果加密返回，无惧数据库账号泄露、研发运维窃取数据。用户可以基于业务需要，配置加密规则，指定需要被加密保护的敏感数据；全密态数据库在查询返回标记的敏感数据时，使用用户密钥，自动对敏感数据进行加密，加密后内容仅持有密钥的用户可以解密获得对应的明文内容。因此，即使数据库账号泄露，也无法看到查询结果中的敏感数据内容，甚至数据库研发运维人员也只能看到密文查询内容。
支持用户指定密钥。用户可以任意选择信任的已有或者第三方密钥管理服务，获取期望密钥后，动态传递给全密态客户端。密钥仅由用户持有，运行时通过安全分发机制参与数据库查询，服务结束时自动销毁，无需担心密钥被外部或者内部用户窃取。
性能贴近现有非密态数据库性能。查询性能与用户指定的敏感字段数量成反比，即查询涉及敏感数据越多，性能损耗响应增加。TPCC下测试分别对20%、50%、100%字段加密的数据库时，其性能分别为明文数据库的93%、86%、79%。更多性能数据请参见全密态MySQL数据库性能测试报告。

应用场景

全密态云数据库的长期目标是设计和研发以数据机密性和完整性为原生能力的新型数据库架构及系统产品。通过相应的设计优化和架构调整，在引入安全能力的同时，仍然保障数据库系统的高性能、高稳定和低成本。

针对不同业务场景所面临的不同数据安全问题，以下列举了一些全密态云数据库适用的典型场景：

应用服务面向数据库服务的数据加密
在一般的应用场景中，数据的拥有者即为应用服务方。他们希望防止数据库服务及其运维人员接触到任何应用数据，同时保证数据库的正常运作。
终端客户面向应用服务的数据加密
在面向终端用户的应用场景中，部分数据（如健康数据、财务数据等）的拥有者为客户本人。他们希望应用服务只提供数据管理和分析的能力，不能接触私人明文数据。
安全可靠的加密数据共享
由于加密数据的密钥只由数据拥有者持有，任何其他角色都无法接触明文数据。在需要将部分数据与第三方分享时，用户希望在不泄漏自身密钥的前提下完成加密数据的分享，同时满足合规要求。

注意事项

加密规则在主地址上不生效，您需要使用集群地址或自定义集群地址。
当前只支持普通的COM_QUERY，不支持COM_STMT_PREPARE等其它命令。EncJDBC只支持text protocol，并不支持binary protocol。在所有情况下，客户端的prepared statament操作都通过text protocol来完成。
当前加密功能与动态脱敏功能互斥，两者不能同时开启。
如果之前已经开通过动态脱敏功能，则需要先把所有的脱敏规则先删除掉，然后重新建立规则并选中规则类型为加密。
用户指定密钥后，目前暂不支持更新密钥。整个数据库集群共享同一个用户密钥。
请勿绕过数据库代理Proxy（SecureGW）直接连接访问原生MySQL Kernel，否则您的数据库集群将丧失敏感数据保护能力。此外，为防止恶意访问，建议您开启日志审计等功能，通过日志等管理手段进行事后审计追责。

使用方法

详情请参见管理加密规则。