企业 AI 自持加密密钥值得投入吗:明文边界、停用演练与完整成本

企业自己管理加密密钥,可以增加对静态数据和密钥使用的控制,却不自动阻止已获授权的应用读取明文。本文拆解密钥、服务身份与数据副本的关系,用构造预算比较默认托管、自管密钥和应用层隔离,给出停用、恢复与退出验收方法,帮助采购和技术团队把安全承诺写成可验证的边界。

如果采购目标是控制哪些服务可以解密存储数据,客户管理密钥可能有价值;如果目标是让运行中的 AI 服务完全看不到输入,仅更换密钥所有者通常不够。先说明谁不能看到哪份数据、在什么时点停止访问,再选择加密层次。本篇面向企业技术、安全和采购负责人,讨论常规解密后计算的系统,不把方案分析当作任何产品的现成功能,也不替代具体合规判断。

先把“密钥归我”改成可验收的访问要求

一次 AI 业务请求至少可能产生原始文件、解析文本、检索索引、模型输入、生成结果和运行记录。它们不必使用同一存储,也不一定由同一主体控制。只问数据库是否加密,容易遗漏已经导出的文本;只问谁持有主密钥,又容易忽略哪个服务身份获准调用解密。采购清单应从数据流开始,为每个副本登记存储位置、加密覆盖、解密身份、接收者及删除方式。

本文把目标拆为三类。第一类是存储介质或备份泄露时,未经授权者不能直接读取内容;第二类是企业能够单独撤销某个业务域的后续解密能力;第三类是某个运营方或模型处理方始终不能看到明文。这三个目标不等价。尤其第三类必须重新检查计算发生在哪里、输入如何进入模型,不能用第一类的证据替代。

Google Cloud 的 CMEK 文档说明,客户管理密钥用于支持服务中的静态数据保护,而实际加解密可由服务代理透明完成。[1] 这说明“最终用户没有密钥权限”与“用户无法通过应用读到数据”不是同一判断。服务代理有权解密,应用又允许访问时,数据仍可正常呈现。企业应同时检查业务授权与服务身份,不能只截图密钥控制台。

把需求写成一句可测试的约定,例如:停用合同资料域的指定密钥后,新启动且不命中已解密缓存的读取应失败,其他资料域不受影响;恢复授权后,指定版本资料能够重新读取。至于旧请求、内存明文和下载文件,另列处理约定。这比笼统的“数据完全由客户掌握”更窄,也更便于供应方提交真实证据。

信封加密解释了控制力,也暴露了边界

信封加密通常用数据密钥 DEK 加密正文,再用密钥加密密钥 KEK 包裹 DEK;保存的是正文密文与被包裹的数据密钥。读取时先解包,再在计算环境中处理数据。[2] 因而中心密钥没有离开密钥管理服务,并不意味着业务内容一直是密文。画架构图时,应分别标出密钥管理边界和明文处理边界。

由此可推导两个采购问题。一个是被包裹的数据密钥与正文是否始终对应,迁移或恢复时能否找到正确的密钥版本;另一个是应用取得明文之后还会写到哪里。对象存储加密、传输加密和进程内使用是不同阶段,某一阶段的机制无法自动覆盖其他阶段。这里的推导属于工程分析,不能反过来宣称所有采用信封加密的系统都具有相同缺陷。

AWS KMS 的加密上下文可以把非秘密的键值信息与密文绑定,并可用于访问控制条件;官方也明确它可能以明文进入日志,不能放敏感信息。[3] 对企业而言,适合考虑受控的用途代码或不含业务秘密的对象标识,并验证错误上下文不能解密。不能把客户姓名、合同条款或原始提问塞入上下文,误以为这是又一层加密存储。

密钥粒度决定故障和退出的影响范围。所有业务共用一个控制点,管理较少,但停用可能同时中断多个部门;按业务域拆分,便于限定影响,却增加策略、版本、恢复和清单管理。不要直接按用户数量机械建钥,也不要为了省管理工时把应独立退出的客户混在一个不可拆分的范围内。先确定最小独立停用单位,再估算维护量。

三条可行路径,需要不同的组织前提

路径一是保留已有托管加密,优先补齐身份权限、副本清单和出口控制。适用于主要问题仍是账号过宽、随意导出或没有资料分类的团队。它并非放弃安全,而是把资金投向已确认的风险路径。验收要证明未授权身份被拒绝、必要日志可追踪以及备份恢复可用;不能因为暂不自管密钥,就省略供应方静态加密和运维权限的核查。

路径二是在实际支持的服务上采用客户管理密钥。前提是明确服务与资源覆盖、密钥管理员和值班责任、跨环境恢复流程,并能识别所有依赖该密钥的业务。它适合需要独立控制密钥生命周期或按业务域停用的场景。新增控制同时带来失误成本:错误策略、不可用的密钥或恢复遗漏,都可能让合法业务无法读取资料。

路径三是在受控边界内做应用层加密与解密,外部存储只接收密文;是否外送模型输入另作决定。它可能更贴近特定明文隔离目标,但会改变搜索、索引、去重和故障定位方式。如果仍在同一外部运行环境解密后调用模型,就没有实现让该环境看不到明文的目标。更强隔离不是给方案换一个名字,而是改变受信任的计算路径。

三条路径的成本不能只比较密钥服务账单。第一条需要权限和副本治理,第二条增加策略及恢复运维,第三条还可能增加应用改造与功能限制。若业务要求外部处理方不能接收某类明文,而候选服务只能明文处理,应先缩小输入或换处理边界;不能用增加一项自管密钥选配,掩盖功能与保护目标之间的冲突。

用构造预算判断什么成本值得承担

以下为构造决策案例,全部金额、工时和频率是假设,不是厂商报价、客户成果或事故预测。企业有三个资料域,其中合同域需要独立停用,其余两域已有可接受的托管方案。团队比较未来十二个月新增投入,内部完全工时成本假设为每小时三百元;三个方案共同承担的既有算力和权限治理成本不计入差额,但仍需另行列账。

保留现状并补合同域清单与访问验收,假设一次性四十小时,每月四小时维护,年度新增工时为四十加四乘十二,合计八十八小时,即二万六千四百元。客户管理密钥方案假设一次性八十小时,每月八小时维护,另有每月一千元的假设服务费用;年度为一百七十六小时乘三百,加一万二千,共六万四千八百元。

应用层隔离方案假设一次性二百四十小时,每月十六小时维护,另有每月二千元的假设附加运行成本。年度工时四百三十二小时,折合十二万九千六百元,再加二万四千,共十五万三千六百元。相对第一条路线,第二条多三万八千四百元,第三条多十二万七千二百元。该算例只给预算结构,不证明新增投入必然换来等额风险降低。

团队现在必须回答增量买到了什么。若合同域独立停用是必须通过的条件,第一条即使最便宜,也不满足该项需求;若第二条能够按目标范围停用且完成恢复演练,它可能进入候选。如果目标提升为外部模型永不接收合同明文,第二条预算不再对应需求,必须重新核查第三条及其功能可行性,而不是比较三项价格后选中间档。

再做敏感性检查:第二条若实际维护需要每月二十小时,年度变为三百二十小时乘三百,加一万二千,即十万八千元,比原估算高四万三千二百元。若另有一次半小时受控停用演练,按每小时六千元业务影响的假设,应另列三千元演练成本。不要把这笔确定的演练代价与未经验证的年度事故概率相乘混为一个“安全收益率”。

停用测试要同时覆盖冷读取、热缓存与恢复

先在隔离测试范围准备两份虚构资料,分别使用合同域与其他域的密钥,并记录资源、版本、服务身份及调用时间。正常读取两份应成功;停用合同域密钥后,重新启动一个不持有旧明文或数据密钥的读取路径,合同资料应按设计失败,另一域继续成功。记录失败发生在解密、资源访问还是应用授权,避免把某次网络故障误认成密钥隔离有效。

再测试热路径。AWS Encryption SDK 文档指出,数据密钥缓存会复用密码材料,并提供年龄、消息量和字节量等限制。[4] 这只说明一种明确存在的缓存机制,不代表每个云服务使用相同策略。供应方必须说明实际部署缓存什么、何时失效、由谁控制。仅有冷读取失败,不能推出已解密数据立即不可用。

若测试发现热缓存仍返回旧内容,先判断是否违背原承诺:是仅要求停止新的解密,还是要求受控出口不再放行内容。后者还需要缓存失效、请求终止与出口协调。可以参考既有的 RAG 撤权一致性分析来区分检查和输出,但密钥停用与用户撤权仍是两类控制,不应混成同一个状态。明确无法撤回的已交付内容,并把未知时延留作未通过项。

恢复演练不能只看控制台重新启用。必须让新进程读取原版本,核对内容校验结果,再读取新写入版本,并检查异常期间是否出现待处理积压、重复任务或静默换用其他密钥。密钥不可用时自动回退到无保护存储,不是可用性优化。合法降级应是停止相关处理、返回明确状态或使用事先批准的不含受限数据的功能。

两个反例会改变原先看似合理的选择

第一种反例是主要泄露路径发生在解密之后:分析员获得正常权限,却把生成结果导出到不受控空间。此时新增密钥所有权不直接修复出口问题。发现证据应来自数据流、导出记录和受控测试,不是猜测员工动机。修正方向是缩小输入、限制导出与接收范围,并复验被禁止的出口确实不再交付;密钥项目可以继续,但不能把这项风险列为已经消除。

第二种反例是团队没有持续维护能力。密钥管理员与恢复人员是同一名偶尔兼职的员工,且没有交接测试时,控制权可能转化成业务单点。发现线索包括依赖清单不全、轮换后旧备份无法恢复、授权变更无人复核。应先补角色分离与恢复证据,或缩小到一个可管理业务域;不能一边缺值班安排,一边承诺所有资料随时可用。

退出时还要区分禁用与删除。AWS 官方将删除密钥描述为不可逆且可能导致资料无法恢复,并建议不确定时先考虑禁用。[5] 本文据此建议先盘点所有密文、备份和独立副本,确认保留责任,再走经过批准的处置流程。控制台删除成功,不证明已经清除外部明文副本,也不证明其他密钥保护的备份已经失效。

密钥轮换也不自动证明历史数据已重新加密。采购方应要求分清新写入使用哪个版本、旧密文依赖哪个版本、恢复时需要哪些材料,以及迁移完成如何核对。若目标是缩小一次既有暴露的影响,单纯让未来写入换钥可能不足;需检查已暴露的数据密钥、明文副本和读取权限,按实际范围提出补救措施。

交付一张能决定推进或暂缓的证据卡

证据卡至少包含六个实际条目:保护对象和副本清单;被排除的主体及允许的服务身份;加密发生层次和明文处理位置;独立停用单位及波及范围;冷、热、在途和恢复四类测试;年度增量成本与持续负责人。每条填写证据位置、核对日期、未覆盖范围与责任人,不能只填“支持”“已加密”或产品名称。

推进条件是目标明确、覆盖可追踪、停用与恢复的实际表现满足书面约定,且维护成本有承担者。缩小范围适用于只有部分服务支持、只有一个业务域需要独立控制的情况;暂缓适用于明文边界与目标冲突、恢复未通过或依赖清单缺失。不同条件对应不同决定,而不是要求每家企业都采购同一等级的密钥服务。

日志和告警属于这张卡里的数据副本。企业 AI 日志脱敏方法可帮助检查哪些排障证据确有必要、哪些原文不应再复制;加密管理不替代采集最小化。最终交付应把“谁控制密钥”“谁有权读业务数据”“何时停止新的读取”分别写清,附上真实测试结果和仍未验证的范围,让安全投入的价值能够被复核。

参考资料

  1. [1] Google Cloud — Customer-managed encryption keys (CMEK)
  2. [2] Google Cloud — Envelope encryption
  3. [3] AWS KMS — Encryption context
  4. [4] AWS Encryption SDK — Setting cache security thresholds
  5. [5] AWS KMS — Delete an AWS KMS key
返回洞察
鲁ICP备2024109755号-2
可拖动移动。右键、长按或按 Shift+F10 可选择停靠位置。