安当TDE云上数据主权：把数据库搬到ECS之后，密钥到底该握在谁手里

一、上云之后，"数据在谁机器上"这件事彻底变了

企业把自己的数据库和文件搬到云主机之前，很多安全假设是默认成立的：服务器在自己的机房，磁盘在自己能上锁的机柜里，备份磁带或备份盘锁在档案室，谁能物理接触到介质是清楚的，谁有权限登录主机是清楚的，数据要跨地域流转需要走一遍审批和物流。

一旦搬到云主机上，这些假设全部失效。

• 磁盘不再是某块具体的盘，而是分布式存储系统里的一组数据块，你不知道它在哪台物理机上；
• 备份和快照是一键生成的，生成过程不需要经过你，删除过程同样；
• 云厂商的运维人员在底层拥有对存储介质的访问能力，这是云平台能够提供"数据恢复"“迁移”"扩容"这类服务的技术前提，无法被合同取消；
• 跨地域复制、镜像导出、快照共享，都是控制台上几次点击的事，操作者可能就是你自己的某个管理员，也可能是被窃取了凭证的人。

需要强调一点：这并不等于说云厂商会作恶。主流云厂商在内部权限管控、操作审计、人员背景审查上的投入远超绝大多数企业。问题在于，安全架构的基本原则是"信任要被技术约束，而不是被承诺支撑"。把数据的可解读性完全托付给另一方的权限模型，本质上是一种无法自我验证的信任。

对金融、医疗、政务、能源等强监管行业，这甚至不是选择题。数据安全相关法规要求重要数据的处理者对其处理活动负责，而"负责"的前提是"可控"。如果数据的明文可读性取决于云厂商的权限边界，就很难说这个责任是可控的。

很多团队在百度搜索"云上数据加密"时，真正想确认的其实只有一句话：数据存在别人机器上，但我能不能让它只有我能读懂。这句话翻译成技术语言就是：密文可以放在云上，密钥必须留在自己手里。

二、云上 ECS 的六类真实风险面

要选对方案，得先把风险面拆细。笼统地说"云不安全"没有意义，说"云很安全"同样没有意义。我们按企业在云主机上实际会遇到的场景，逐项列出来。

2.1 云盘快照被越权访问或带走

不少运维负责人在百度搜索"备份加密怎么做"时，脑子里想的往往不是备份软件，而是云控制台上那个"创建快照"的按钮——因为云上最危险的复制动作，恰恰是最不需要专业知识的那一个。快照是云上最方便的功能，也是最容易失控的功能。管理员在控制台点一下，就能生成一份完整的磁盘副本；这个副本可以被共享给其他账号、可以被导出、可以被复制到其他地域。

风险来自三处：一是凭证泄露，攻击者拿到控制台权限后，生成一个快照共享到自己的账号，然后把数据拖走，全程可能只留下几条控制台操作日志；二是内部人员，拥有快照权限的运维或外包，可以以"做测试环境"为由把生产数据整体复制到另一个账号；三是快照本身长期留存，很多企业的快照保留策略是"永不删除"，于是历史快照成了数据持续暴露的面。

关键点是：快照继承的是磁盘上的数据形态。磁盘上是明文，快照就是明文；磁盘上是密文，快照就是密文。这是云上加密方案最重要的一个性质。

2.2 云平台侧运维权限

云厂商需要运维能力来保障服务可用性。这意味着在hypervisor层、存储层，存在拥有技术访问能力的角色。企业无法通过合同或者配置取消这种能力，只能通过加密让这种能力"即便行使也读不懂"。

这里有个容易混淆的点：云厂商提供的"运维审计"“操作留痕”“双人授权"这类功能，解决的是"操作可追溯”，不解决"数据不可读"。两者不在同一层面。可追溯能让你事后知道发生了什么，不可读能让你事前就不必担心。

2.3 跨区域与跨账号复制

合规要求数据不出境、不出省、不出指定区域的场景非常普遍。云上的复制能力让"数据在哪里"变成了一个动态问题：一次跨地域复制，数据就多了一份副本在另一个法域；一次跨账号共享，数据就可能进入另一家主体的控制范围。

如果数据以密文形态存储，且密钥由企业侧控制在指定地域内，那么即使副本被复制到其他地域，那份副本也是不可解读的——这在合规举证时是一个非常有力的技术事实。

2.4 镜像与实例的导出

云主机支持导出镜像到本地或其他环境。镜像里包含操作系统、应用以及数据盘内容。如果镜像未加密，导出的文件在任何一台机器上都能被挂载读取。加密后的镜像即便被导出，脱离了密钥环境同样打不开。

2.5 备份、对象存储与中间产物

数据库备份、逻辑导出文件、ETL 中间结果、临时目录的落盘文件，这些"非主路径"数据往往是最容易被忽略的。很多企业给主库做了加密，却把备份明文放在对象存储里，或者把导出文件明文放在某台跳板机上。从泄露事件复盘看，备份和导出文件造成的暴露面，往往比主库本身更大。

2.6 多租户与残留介质

云是多租户环境。虽然主流平台在实例释放、磁盘回收时有擦除机制，但"数据残留"在理论上无法被企业自我验证。密文存储让这个问题自动消失——残留的是密文，没有价值。

把这六类风险放在一起看，会发现它们的共同点：全部作用于"存储介质"这一层。攻击者要拿到的东西，是磁盘、快照、镜像、备份文件。这恰恰是透明加密的主场——它保护的就是静态数据的存储形态。

三、云厂商原生加密 vs 自持密钥：主权边界在哪

理清风险之后，来看方案。云厂商其实提供了不少加密能力，问题在于这些能力的"密钥主权"程度各不相同。

工程人员在百度搜索"磁盘加密方案对比"时，最容易被一堆名词绕晕——云盘加密、服务端加密、自带密钥、外部密钥管理，听起来都叫"加密"，主权含义却相差甚远。下面这张表按"密钥在哪、谁能解密"来分，是最直观的判据。

3.1 四类密钥托管形态

多数企业用的默认是第一种：在控制台勾一个"云盘加密"，密钥由平台托管。这个动作有价值——它确保了介质被物理带走时无法读取，也满足了不少合规条款中"静态数据加密"的字面要求。但它不解决数据主权问题，因为密钥仍在云侧。

3.2 一个判据：删掉密钥之后，云还能不能读出数据

判断主权归属，有一个非常实用的判据：当我在自己这一侧删除或吊销密钥之后，云平台还能不能读出我的数据？

• 平台托管密钥：不能通过你的操作让平台读不出，因为密钥不由你独占控制；
• 用户托管密钥（云内）：你删除密钥后云上数据确实打不开了，但密钥材料曾经并且仍然存在于云侧密钥服务中，可被平台的密钥管理流程使用；
• 外部密钥管理 / 主机内自持密钥：密钥材料全程在企业自持的硬件安全模块或密钥系统中，云侧拿到的只是加密后的数据密钥或没有密钥，你吊销之后云侧无论如何都解不开。

这个判据的好处是它可验证。选型时可以直接向厂商提这个要求：请演示在企业侧吊销密钥后，云侧是否仍然能读取数据。

3.3 透明加密在云上为什么依然有效

有一种常见的误解：既然用了云盘加密，就没必要在主机内再做一层。还有另一种误解：云主机里做驱动层加密，会不会和云平台冲突？

实际上，主机内的透明加密与云盘加密是串行叠加的关系，数据路径是这样的：

应用写入明文 ↓ ① 主机内透明加密（驱动/代理层） ← 数据密钥由企业侧密钥系统下发 ↓ 密文 ② 文件系统 / 卷管理层 ↓ ③ 云盘加密（平台托管密钥，可选） ↓ 密文 ④ 分布式存储 / 快照 / 备份 / 镜像

云平台在第④层看到的是已经经过第①层加密的密文。无论第③层是否被平台解密，第④层的内容对企业以外的任何一方都是不可解读的。这就是"云上 ECS 有效"的技术含义——云管理员见到的是密文，而且解开这层密文的钥匙不在云上。

以安当TDE为例，其工作位置正是第①层：操作系统驱动层透明加密，数据落盘即为密文，应用零行改造，支持 Windows、Linux 与国产操作系统，不限数据库类型，采用国密 SM4 与国际 AES 算法，根密钥由硬件安全模块托管。

四、在云主机内做透明加密的架构

4.1 整体架构

企业自持侧（IDC / 办公网 / 独立 VPC） ┌─────────────────────────────────────────┐ │ 密钥管理系统（KSP） │ │ ├ HSM：根密钥（KEK）永不明文导出 │ │ ├ 密钥全生命周期：生成/激活/更新/归档/销毁│ │ └ 策略中心：加密策略、进程白名单、账号授权 │ └──────────────┬──────────────────────────┘ │ 加密通道（TLS/国密传输，双向认证） │ ① 实例注册与身份鉴别 │ ② 密钥申请与下发（数据密钥受KEK保护） │ ③ 心跳续期 / 吊销广播 ───────────────┼────────────────────────────────── 云边界 云上 ECS 实例 ┌──────────────┴──────────────────────────┐ │ 加密代理 / 驱动层 │ │ ├ 进程白名单：仅授权进程可读明文 │ │ ├ 账号+进程双控：Root/SA 非授权只见密文 │ │ ├ 密钥缓存：内存受保护，不落盘 │ │ └ 落盘加密：SM4 / AES，页级或文件级 │ ├─────────────────────────────────────────┤ │ 应用 / 数据库进程（无感知，零改造） │ ├─────────────────────────────────────────┤ │ 云盘 / 快照 / 镜像 / 备份（均为密文） │ └─────────────────────────────────────────┘

几个设计要点：

加密位置在主机内，而不是在存储层。这决定了密钥不需要交给云平台，也决定了加密对数据库类型没有要求——不管是关系型数据库、文档数据库、大数据组件还是普通文件目录，走的都是同一条落盘路径。

密钥由企业侧密钥系统统一下发。云上实例启动后，先向企业侧密钥系统做身份鉴别（通常基于实例标识、证书或预置凭据），鉴别通过后申请数据密钥；密钥系统用根密钥加密数据密钥后下发，实例在内存中解封使用。根密钥自始至终不出硬件安全模块。

密钥在实例侧只存在于受保护的内存中。不落盘、不写入配置文件、不进入普通进程可读取的地址空间。这是"云侧只见密文"能够成立的前提——如果密钥以文件形式躺在云主机的磁盘上，那么拿到快照的人同时拿到了密文和密钥，加密就失效了。

进程与账号双控。光有加密还不够：如果任何进程都能读到明文，那么勒索软件或恶意脚本同样能读到。所以配套的进程白名单与账号校验是必需的——只有授权的操作系统账号 + 授权进程（如数据库服务进程）才能获得明文，其他进程包括以管理员身份运行的进程，读到的都是密文。

4.2 密钥分发链路怎么设计

密钥分发是这套架构中最需要仔细设计的环节，因为它同时决定了安全性与可用性。

信封加密结构。采用两层密钥：数据加密密钥（DEK）用于加密实际数据页或文件，密钥加密密钥（KEK，即根密钥）用于保护 DEK。DEK 以被加密的形态随密文存储或缓存在实例内存中，KEK 永不明文离开硬件安全模块。这样做的好处是：根密钥轮换时只需重新加密 DEK，不必重写全部数据。

申请与续期。实例首次启动时申请 DEK，之后按心跳续期。心跳中断超过阈值，实例侧自动清除内存中的密钥并停止明文服务。这个"失联即锁死"的设计是数据主权的最后一道保险：企业侧可以主动吊销，让指定的云上实例立刻失去解密能力。

断网容忍。这里有个工程权衡：如果企业侧密钥系统不可达，云上实例是否还能继续服务？完全不容忍，则密钥系统故障会导致云上业务全面中断；过度容忍，则吊销机制形同虚设。合理的做法是分级：正常状态下按周期续期；续期失败进入宽限期（如数小时），宽限期内服务继续但告警；宽限期结束仍未恢复，则停止解密。宽限期的长度要由业务的容灾等级和数据的敏感等级共同决定。

传输保护。密钥下发通道必须双向认证并加密，建议采用国密算法套件以符合密码应用要求。通道中要防重放、防篡改，密钥请求要带实例身份证明。

4.3 进程白名单与加密的组合

在云上环境，进程白名单的作用比本地更突出。原因是云主机的运维方式发生了变化：大量操作通过自动化脚本、配置管理工具、远程执行通道完成，这些通道本身就是攻击面。

进程白名单的逻辑是默认拒绝：只有被显式授权的进程（数据库服务进程、备份代理、应用进程等）可以对受保护目录做读写；其他一切进程，包括新上传的脚本、被替换的二进制、以最高权限运行的命令行，全部被拒绝或只能读到密文。

这个设计直接化解了一类高频风险：勒索软件或挖矿木马拿到云主机权限后，即便拥有管理员身份，也无法批量读取并加密受保护目录里的数据——它读到的要么是密文，要么被直接拒绝。

五、混合云与多云：密钥怎么统一管理

现实中很少有企业是纯云或者纯本地的。更常见的是：核心库在本地机房，业务系统在公有云，灾备在另一朵云，还有一部分在行业云或政务云。这种形态下，密钥管理如果各搞一套，运维复杂度和风险都会成倍上升。

5.1 统一密钥平面的三个层次

层次一：根密钥统一。所有环境的数据密钥，最终都由同一套企业自持的密钥系统保护。根密钥在硬件安全模块中生成、存储、使用，永不明文导出。这是"主权统一"的基础。

层次二：策略统一。加密策略、进程白名单、账号授权、密钥轮换周期，在同一套策略中心定义并按环境分发。避免"本地一套规则、云上另一套规则"导致的管控缝隙。

层次三：审计统一。所有环境的密钥使用记录、加解密调用、密钥生命周期事件，汇入统一的审计视图。这在等保测评与密评时尤其重要——测评人员要看的是完整证据链，而不是分环境拼接的材料。

5.2 多云场景下的几个具体问题

跨云迁移时的密钥跟随。数据从一朵云迁到另一朵云，如果密钥跟着走，迁移过程就是明文搬运；如果不跟着走，目标环境解不开。正确做法是在目标云的实例上先完成注册与身份鉴别，由企业侧密钥系统向其下发新的数据密钥份额，密文在迁移过程中始终保持密文形态，落位后再由新实例解密服务。也就是说，迁移的是密文，密钥在目标侧重新授权。

多地域部署的密钥域划分。建议按地域或者按业务域划分密钥域，而不是全局一个密钥。这样做有两个好处：一是吊销的影响面可控，某个地域的密钥被吊销不会波及全局；二是满足数据本地化的合规要求——某地域的密钥材料不出该地域的密钥节点。

云上密钥节点的部署形态。如果企业侧密钥系统与云上实例之间的网络时延较大，可以在云内部署密钥系统的从属节点或缓存节点，但其内只保存受保护的密钥份额，且需要定期回主节点续期。主节点与根密钥始终在企业自持侧。

5.3 与云厂商密钥服务的关系

不冲突，可以共存。合理分工是：云厂商密钥服务保护云平台层面的对象（如对象存储的服务端加密、云盘的底层加密），企业自持的密钥系统保护主机内透明加密的数据密钥。两者叠加，形成"平台层 + 主机层"的双重保护。关键原则只有一条：企业自持的这一层，密钥不能交给平台。

六、密钥不出企业侧时，云上运维和备份怎么做

这是上加密方案时最常被质疑的问题：密钥在自己手里，那云上的运维怎么办？备份怎么办？会不会为了安全把可用性搭进去？

逐项回答。

6.1 日常运维

云主机的日常运维（装补丁、改配置、重启服务、扩容）几乎不涉及数据明文读取，因此不受影响。运维人员登录云主机后看到的是密文文件，这与他们的职责并不冲突——他们本来也不该看业务数据。

真正需要明文的是数据库服务进程本身，而它是被授权进程，正常工作。也就是说，加密改变的是"谁能读到"，而不是"系统能不能跑"。

需要额外设计的是两类场景：

• 数据库排障：DBA 需要查询数据，这时应通过运维管控网关或应用层访问，而不是直接读文件。密文文件对 DBA 本就无用。
• 数据修复：涉及直接修改数据文件的极端场景，需要在授权进程内操作，或走临时解密流程（审批 + 时间盒 + 全程录制）。

6.2 备份与快照

这是加密方案最体现价值的地方。因为备份、快照、镜像继承的都是磁盘上的数据形态，加密后它们自动变为密文，不需要为备份单独设计一套加密流程，也不会出现"主库加密了、备份是明文"的经典漏洞。

需要注意三点：

1. 恢复要验：备份是密文，恢复时必须有密钥。所以备份策略里要明确"这份备份对应的密钥版本"，并在恢复演练中验证；
2. 异地备份的密钥可达性：备份副本放到另一个地域或另一朵云后，恢复时该环境必须能够向企业侧密钥系统完成身份鉴别并申请密钥。这要求密钥系统本身具备多地域服务能力或跨域授权机制；
3. 老备份的密钥归档：密钥轮换后，历史备份仍由旧版本密钥保护。因此密钥归档策略要与备份保留周期对齐——备份保留三年，对应的密钥就要归档保留三年以上，不能提前销毁。

6.3 容灾与切换

云上做同城或异地容灾时，灾备端的实例同样需要向企业侧密钥系统注册。这意味着密钥系统是容灾架构中的关键依赖，其自身的可用性必须与容灾等级匹配：通常需要多节点集群、跨地域热备、以及离线恢复能力。

一个实用的设计是：灾备端实例预注册并预取加密的数据密钥份额（受保护存储），正常状态下不启用，切换时由企业侧发出激活指令。这样既保证了切换的时效性，又保持了吊销能力。

6.4 扩容与弹性伸缩

弹性伸缩场景下，新实例会随时创建。自动化流程里必须包含"实例注册与密钥申请"这一步，且这一步要在实例接入流量之前完成。建议将密钥代理作为基础镜像的一部分，随实例启动自动完成注册，避免人工介入成为瓶颈。

七、迁移上云时的加密改造路径

上加密不是"装个软件"就完事，尤其是存量数据的迁移。下面给出一条经过实践检验的路径。

7.1 第一步：资产盘点与分级

列出要迁移的数据库、文件目录、备份文件，按敏感程度分级。不必一次性全量覆盖，优先覆盖含个人信息的核心库、财务库、以及会被快照长期留存的数据。这一步的输出是一张"迁移加密清单"。

7.2 第二步：密钥系统先行落地

密钥系统必须在加密之前就位。顺序反了会出现"数据已加密但密钥没处托管"的被动局面。这一步要做的事包括：硬件安全模块上线、根密钥生成与分片托管、密钥策略定义、与企业侧密钥节点的网络打通、与云上实例的身份鉴别机制联调。

7.3 第三步：存量数据在线加密

存量数据往往有几百 GB 到几十 TB，停机重加密不现实。工程上采用在线渐进式加密：

1. 在云主机上部署加密驱动与代理，配置为"新写入加密、历史数据待加密"模式；
2. 后台任务按文件页或数据块的顺序扫描历史数据，逐个加密并打标记；
3. 扫描过程中业务正常读写：读到未加密块时先加密再返回，读到已加密块直接解密返回；
4. 扫描进度可查询、可暂停、可限速（避免影响业务 IO）；
5. 扫描完成后切换为"全量加密"模式，此后所有写入均加密。

这个过程的时长取决于数据量与 IO 余量。经验做法是先限速到较低比例跑几天观察，确认对业务无影响后再提速。

7.4 第四步：灰度切换

不要一次性把所有实例都切过去。建议顺序是：

• 先切非核心的测试环境，验证兼容性（操作系统版本、内核版本、数据库版本、文件系统类型）；
• 再切预发环境，验证性能与备份恢复；
• 然后切生产环境的从库或只读副本，观察一到两周；
• 最后切生产主库，并在切换窗口内保留回滚能力。

每一轮灰度都要验证四件事：业务功能正常、性能指标达标、备份可恢复、密钥续期与吊销机制有效。

7.5 第五步：回滚预案

必须提前准备好回滚路径，并且演练过。回滚的关键在于：加密后的数据在加密驱动卸载后是不可读的。因此回滚方案通常是：

• 轻度回滚：保留加密驱动，仅回退策略（如放宽进程白名单、关闭某个目录的保护）。这是最常用的，风险最低；
• 中度回滚：暂停加密驱动但保留数据，此时数据不可读，需要走解密流程。解密流程与加密流程对称，同样支持在线渐进式；
• 完全回滚：全量解密并卸载驱动。这需要预留停机窗口或足够的 IO 余量，且耗时通常与加密过程相当。

回滚预案中要明确触发条件（如性能下降超过阈值、某类业务报错率上升）、决策人、以及每个级别的预计耗时。没有演练过的回滚预案等于没有预案。

7.6 第六步：切换后的验证清单

切换完成后，至少验证：加密覆盖率是否达到 100%（有没有漏掉的目录）、进程白名单是否覆盖了所有必要的进程、备份是否可恢复、密钥续期是否正常、吊销演练是否成功、审计日志是否完整。

八、密钥丢失的兜底与恢复演练

加密方案里最危险的一句话是"密钥丢了"。因为一旦根密钥和数据密钥同时不可用，数据就是永久丢失，任何技术手段都无能为力。所以兜底设计不是可选项，而是方案的一部分。

8.1 根密钥的多层保护

硬件安全模块托管。根密钥在硬件安全模块内生成和使用，永不以明文形式导出。所有加解密运算在模块内完成。

分片托管（门限方案）。将根密钥的备份材料分成若干份，按门限（如 5 份中任意 3 份）恢复。分片由不同角色的管理者分别保管，存放于不同物理位置。这样既避免了单人丢失导致整体不可用，也避免了单人可以独立恢复密钥的作恶风险。

异地冷备。至少保留一份离线、异地、物理隔离的备份。这份备份的启用需要严格的流程与多人在场，平时处于封存状态。

8.2 数据密钥的归档与版本管理

数据密钥随数据走，且会被根密钥保护后存储。要注意两点：一是密钥版本要可追溯，任何一份密文都要能查到它对应的密钥版本；二是归档周期要与数据保留周期对齐，备份保留多久，对应密钥就要归档多久。

8.3 恢复演练怎么做才有效

很多团队说"我们做了备份"，但从未真正恢复过。有效的恢复演练至少要覆盖四种场景：

演练必须记录三个指标：实际耗时、参与人数、发现的问题。演练报告要归档，测评时能拿出来。

8.4 兜底的最后一条：可解密的离线副本

对于极端敏感或极端重要的数据，建议在密钥体系之外，保留一份经过独立加密、由不同密钥保护的离线归档副本，存放于物理隔离的环境。这不是常规方案，但作为"最后一道"是值得的成本。前提是这份副本的密钥管理同样严格，否则等于新开一个后门。

九、方案对比与选型建议

选型建议：

• 如果诉求只是"满足静态加密的合规字面要求"，云盘加密足够，成本最低；
• 如果诉求是"数据主权、密钥自持、可被验证"，必须做主机内透明加密或外部密钥管理；
• 如果业务跨多云、混合云，优先选择具备统一密钥平面的方案，避免密钥体系碎片化；
• 如果有国密与信创要求，确认方案是否原生支持国密 SM4 以及国产操作系统与芯片；
• 不要忽略性能与可运维性。加密方案如果损耗过高或运维复杂，最终会被业务部门绕过。以安当TDE为例，其设计吞吐约 45 Gb/s、性能损耗低于 3%、应用零行改造，这类工程指标决定了方案能否真正铺开——毕竟上不去的方案，安全价值等于零。

十、合规与落地检查清单

10.1 合规映射

• 等保 2.0：数据完整性与保密性条款要求重要数据在存储过程中保密；透明加密可直接对应，且审计记录满足安全审计要求；
• 商用密码应用安全性评估：要求使用合规密码算法并对密钥全生命周期进行管理；国密 SM4 加密配合硬件安全模块托管的密钥体系，可对应密码应用技术与管理要求；
• 数据安全相关法规：重要数据加密存储、数据出境与跨域流转控制，密文 + 自持密钥可提供技术举证材料；
• 行业监管：金融、医疗、政务等行业对数据本地化与密钥自持多有明确要求，透明加密的"密文可跨域、密钥不出域"特性正好匹配。

10.2 落地检查清单

规划阶段

1. 已完成云上资产盘点与数据分级，明确需加密的数据库、目录、备份；
2. 已确定密钥主权目标（平台托管 / 外部密钥 / 主机内自持），并写入架构决策记录；
3. 已用"吊销密钥后云侧是否仍可读"这一判据验证过候选方案；
4. 已确认算法要求（国密 SM4 是否必须、是否需要国际算法兼容）；
5. 已完成操作系统、内核、数据库、文件系统的兼容性验证清单。

实施阶段

6. 密钥系统先于加密落地，根密钥已在硬件安全模块中生成并完成分片托管；
7. 云上实例与密钥系统之间已建立双向认证的加密通道，并完成身份鉴别联调；
8. 存量数据采用在线渐进式加密，具备限速、暂停、进度查询能力；
9. 已按测试→预发→从库→主库的顺序灰度，每轮验证功能、性能、备份恢复、密钥续期；
10. 已验证云盘快照、镜像导出、备份文件继承密文形态；
11. 已验证进程白名单与账号双控生效（非授权进程与管理员身份均只见密文）；
12. 已配置密钥续期失败后的宽限期与失联锁死策略，并明确告警接收人。

运维阶段

13. 备份保留周期与密钥归档周期已对齐，历史备份可追溯到具体密钥版本；
14. 已建立密钥轮换策略，并验证轮换后历史数据仍可正常读取；
15. 已配置弹性伸缩实例自动完成注册与密钥申请，无需人工介入；
16. 已完成至少一次完整恢复演练，并归档演练报告（含耗时与发现的问题）；
17. 已建立吊销演练机制，验证企业侧吊销后云上实例立即失去解密能力；
18. 异地灾备环境的密钥可达性已验证，切换演练已执行；
19. 回滚预案已编写并演练，明确触发条件、决策人与各级别预计耗时；
20. 密钥使用日志与加解密调用日志已纳入统一审计视图，满足测评举证要求。

十一、FAQ

Q1：云盘加密已经勾上了，还需要主机内透明加密吗？
取决于你要解决什么问题。云盘加密解决的是"介质被物理带走后读不出"，主机内透明加密解决的是"密钥主权与平台侧不可读"。前者防的是外部窃贼，后者防的是权限模型。如果合规或风险诉求涉及数据主权，就需要后者。两者可以叠加，不存在冲突。

Q2：密钥放在自己手里，云厂商还需要配合什么吗？
基本不需要。主机内加密工作在云主机的操作系统内部，云厂商只看到被加密的数据块，不参与密钥流程。唯一需要规划的是企业侧密钥系统与云上实例之间的网络连通性——需要一条稳定的加密通道，企业侧密钥系统要具备公网或专线可达的服务端点，并做好访问控制。

Q3：密钥系统不可达，云上业务会立刻中断吗？
取决于宽限期配置。合理设计是分级：正常周期续期；续期失败进入宽限期，业务继续但持续告警；宽限期结束仍未恢复则停止解密。宽限期长度按业务容灾等级与数据敏感等级设定，从数十分钟到数小时不等。这个参数本身就是安全性与可用性之间的权衡，需要业务方和安全方共同确认。

Q4：性能损耗有多大？
取决于实现方式与硬件。驱动层加密配合现代 CPU 的指令集加速（如 AES 相关指令），损耗可以很低。工程上更需要注意的是 IO 模式：随机小写密集的场景损耗通常高于顺序大块写。建议在选型时用自己的真实业务做压测，而不是看厂商的通用指标。

Q5：存量数据在线加密期间，业务会受影响吗？
会有一定 IO 占用，但可以通过限速控制。关键是采用"读写时顺带加密 + 后台扫描补齐"的方式，业务不需要停机。上线前建议先在测试环境用同等数据量跑一遍，测出加密速率与 IO 影响曲线，再据此规划生产环境的限速参数与预计工期。

Q6：数据库自带的透明加密和主机内透明加密选哪个？
前者是数据库内核能力，配置方便，与数据库紧耦合，但只覆盖该数据库的数据文件，不覆盖日志、临时文件、导出文件和其他类型的数据存储，且密钥通常在数据库或云侧管理。后者覆盖整个落盘路径，不限数据库类型，密钥由企业自持。如果环境里有多种数据存储或者对密钥主权有要求，后者更合适；两者也可叠加。

Q7：多云场景下，密钥系统是不是会成为新的单点？
是潜在风险，所以需要针对性设计：密钥系统自身做多节点集群与跨地域热备，云侧部署从属节点或缓存节点承载日常续期，主节点与根密钥始终在企业自持侧。同时保留离线恢复能力，确保最坏情况下仍能通过分片重建根密钥。

Q8：加密后，云上的数据库运维还能正常做吗？
可以。数据库服务进程是授权进程，正常读写明文；运维人员登录主机看到的是密文文件，这与他们的职责不冲突。需要查询数据时，应通过应用层或运维管控网关访问，而不是直接读文件。需要提醒的是，涉及直接操作数据文件的极端修复场景，要走临时授权流程并全程录制。

Q9：密钥被吊销后，还能恢复吗？
吊销与销毁是两个概念。吊销是停止对该实例的密钥服务，密钥材料仍在企业侧，重新授权即可恢复。销毁是彻底删除密钥材料，不可恢复。日常操作中应使用吊销而非销毁，并为销毁设置严格的审批与冷却期，避免误操作导致数据永久丢失。

Q10：上云之后还需要在本地保留密钥节点吗？
如果业务是纯云的，可以在办公网或本地机房保留一个轻量节点作为根密钥的物理锚点，也可以全部部署在企业自有的独立虚拟网络内。关键不是物理位置，而是密钥系统是否处于企业独占控制之下，以及是否具备离线恢复能力。对强监管行业，保留本地物理锚点通常在合规举证时更有说服力。

方案参考

安当TDE（透明数据加密）工作在操作系统驱动层，对数据库文件、表空间及任意落盘文件实现透明加密，应用零行改造。在云上 ECS 场景中，其价值集中体现在数据主权回归租户：密文可以存在云上，密钥始终握在企业自己手里。

核心能力要点：

• 部署形态：在云主机操作系统内部署驱动与代理层，落盘即加密；云盘、快照、镜像、备份自动继承密文形态，云管理员与平台侧只见密文；
• 密钥主权：根密钥由企业自持的硬件安全模块托管，永不明文导出；数据密钥由企业侧密钥系统统一下发并受根密钥保护，支持续期、轮换、吊销与全生命周期管理；
• 细粒度管控：支持操作系统账号 + 进程双控，未授权进程即便以管理员身份运行也只见密文；结合进程白名单可阻断非授权批量读取与二次加密；
• 算法与合规：支持国密 SM4 与国际 AES，适配 Windows、Linux 与国产操作系统，不限数据库类型，可支撑等保 2.0、商用密码应用安全性评估以及数据本地化相关合规举证；
• 工程指标：实测吞吐约 45 Gb/s，性能损耗低于 3%，应用零改造，支持混合云与多云统一密钥管理、在线渐进式加密与灰度回滚；
• 组合建议：与字段级加密网关组合形成"文件层 + 字段层"双层防护，密钥统一交由密钥管理系统托管，已在激光科技云上 CRM、地方国投、地理信息与地图军工等场景落地。

如需进一步了解产品能力，可重点参考「安当TDE透明加密」相关技术文档与最佳实践。