云安全进阶

1 云安全进阶要回答什么

订单服务已经能部署到云上：应用运行在私有网络中，数据库保存订单，对象存储保存导出的对账文件，运维人员通过身份系统管理资源。现在出现了新的问题：如果导出文件被复制走，谁还能读它？如果应用令牌泄露，攻击者能否借它读取其他业务的数据？如果管理员调整了密钥权限，团队能否在事后证明调整者、调整内容和随后发生的访问？

这些问题把安全从“有没有打开加密”推进到“谁在什么条件下，借助哪把密钥，对什么数据做了什么”。本课的中心是密钥管理服务 KMS，以及身份、授权和审计怎样围绕密钥形成闭环。网络防护、威胁检测和响应也会出现，但它们都服务于这个具体问题：让敏感数据的访问有边界、有证据，并且在身份失陷时能够收缩影响。

先区分 3 个容易混淆的判断。数据被加密，说明没有相应解密能力的人通常无法直接理解密文；身份通过认证，说明系统确认了某个凭据所代表的主体；请求获得授权，才说明该主体可以执行当前操作。攻击者拿着有效令牌时，认证可能正常通过。如果这个身份还拥有解密权限，静态加密本身不会判断拿令牌的人是不是攻击者。

C6 已介绍块存储静态加密开关。本课只接上它背后的问题：磁盘由哪把密钥保护，谁能改变密钥策略，停用密钥会影响哪些挂载、启动或快照恢复路径。卷类型和性能不在这里重讲。C19 已介绍审计日志的开启与检索，本课则要求把敏感用钥和密钥策略变化放进同一条调查路径，核对权限变化是否真的导致了数据访问。

沿用订单服务作为例子：运行身份只访问生产订单所需的数据，导出任务有独立身份，对账文件采用信封加密，密钥管理人员负责密钥生命周期。我们追求的结果不是“任何事故都不会发生”，而是让攻击者很难扩大权限，让异常尽早暴露，并让值班人员知道该先撤销什么。硬件安全模块内部设计、复杂密码算法证明和自动攻击分析留给后续专题；这里先把可以执行的边界讲清楚。

2 身份、密钥与机密分发边界

身份回答“谁在请求”，机密分发回答“程序怎样取得运行需要的敏感材料”，密钥管理回答“加密密钥由谁控制、允许怎样使用”。数据库密码、第三方接口令牌属于机密，通常由机密管理系统保存和按权限分发。KMS 主要管理加密密钥和用钥操作，不能因为接入 KMS 就省略机密访问控制。应用取到了数据库密码后，仍然要受数据库自身权限约束。

客户主密钥在这里指客户管理的主密钥，常写作 CMK。不同平台对 CMK 的历史名称和当前术语可能不同，阅读文档时要确认实际指向的是哪类密钥。本课采用 1 个简单模型：客户控制密钥资源的策略、状态和生命周期，密钥材料通常留在 KMS 的受保护边界内，通过接口使用。客户管理不代表应用需要下载主密钥材料，更不代表管理员应该把它复制到配置文件。

信封加密把主密钥和数据密钥分开。导出任务向 KMS 请求 GenerateDataKey，典型结果包含明文数据密钥和被主密钥包裹的数据密钥。程序在本地用明文数据密钥加密文件，再把密文文件、被包裹的数据密钥以及必要的算法元数据一起保存。明文数据密钥只在受控内存中短暂存在，使用后尽快释放，不能写进日志、临时文件或错误报告。完整文件不必送进 KMS，因此 KMS 不承担所有文件字节的加解密工作。

读取时，程序取出被包裹的数据密钥，请求 KMS 执行 Decrypt，再在本地解密文件。Encrypt 则可用于直接加密平台允许大小的小段明文，或者在适用接口中包裹已有材料；它不是处理任意大文件的通用入口。授权 GenerateDataKey 意味着允许调用者取得新数据密钥的明文，不能把它当成风险很低的“只创建”权限。加密程序也要使用可靠的加密库、认证加密算法和正确的随机参数，避免自行拼装密码方案。

授权必须细到动作。订单读取身份只需要解开既有文件时，不应顺带获得 Encrypt、GenerateDataKey 或策略修改权限；导出身份需要生成数据密钥，也不因此自动获得读取历史文件的资格。还要同时限制存储对象范围，否则身份可能取得不属于自己的密文和包裹密钥。数据权限与密钥权限共同决定访问能力，缺少任何 1 层都可能失败，拥有任何 1 层也不等于已经拥有明文。

密钥管理员负责轮换、状态和策略，数据使用者负责业务用钥，审计人员负责读取证据。角色可以按组织规模调整，但要防止某个管理员仅凭现有权限就能随意给自己添加解密资格。部分平台还通过密钥策略、身份策略和授权凭据共同判断请求，不能只查看身份策略中的 Allow。显式拒绝、组织级限制以及服务代调用条件都可能改变最终结果，应以目标平台的授权规则为准。

加密上下文可以把用途、环境或租户标识绑定到用钥操作；在支持的实现中，它也可作为授权条件，并参与认证校验。读取时应提供匹配的上下文，防止把生产订单的包裹密钥拿到其他用途下使用。上下文通常不是机密，还可能进入审计记录，因此不要把姓名、密码或完整订单内容写进去。服务应从可信业务状态生成上下文，不能直接信任客户端随意传来的租户标识。

多账号和多区域需要明确画边界。生产账号的身份不能仅凭名称相似就使用测试账号的密钥；跨账号使用通常还需要资源侧与调用方相应授权，并非所有托管服务都支持相同方式。不同区域中的密钥资源也不能默认互换，多区域关联密钥的材料关系、策略和日志位置要分别确认。方案至少记录账号、区域、密钥标识和允许的服务用途。别名便于引用，但别名可以改指向，取证时还应保存实际密钥标识。

3 检测、响应与取证路径

“用钥即审计”首先是一项设计要求：敏感 KMS 操作和密钥策略变更必须产生可核对的证据，并被可靠收集。它不是“每读 1 条订单，KMS 就一定出现 1 条日志”的承诺。应用可能缓存数据密钥，也可能由托管存储服务代为调用 KMS。后续本地解密未必再次访问 KMS，因此要结合应用访问记录、存储读取记录和密钥审计，才能解释数据究竟被谁读过。

先核对平台是否记录目标事件类型，覆盖哪些区域、账号及服务代调用路径，再设计告警。记录应尽量保留事件时间、主体、会话与请求标识、密钥标识、操作、结果、来源线索和相关上下文。不要假设每个字段都一定存在，也不要把“没有查到事件”直接解释成“没有发生”。日志到达可能延迟，采集范围可能遗漏，调用还可能发生在另 1 个账号或区域。

订单服务可以先设置几类有业务含义的检测：平时只生成新文件的导出身份突然请求 Decrypt；某个身份在短时间内尝试多个无关密钥；策略放宽后紧接着出现成功解密；密钥停用、计划删除或别名改指向发生在变更窗口之外。来源地址变化只是辅助线索，托管服务出口和网络代理都会影响它。告警应同时带上身份、密钥和关联变更，减少值班人员反复搜索的时间。

关联时按请求标识、会话标识和时间窗口逐步拼接，不强求不同服务提供完全相同的关联字段。比如先找到策略修改事件，再定位修改后的密钥标识，检查随后是谁使用了 Decrypt，最后寻找对应对象读取和应用导出记录。成功调用 KMS 能证明服务返回了某种用钥结果，却不能单独证明攻击者已取得完整文件；失败调用也有价值，它显示攻击者曾经尝试越界。

响应应区分“阻止身份继续请求”和“阻止某把密钥继续被使用”。令牌泄露时，先限制相关会话与角色的后续访问，并确认现有会话是否真的受影响；具体撤销方式随平台和令牌类型变化。密钥停用可以扩大阻断范围，也可能使正常订单读取、后台任务和恢复任务一起失败。值班人员应根据影响面选择动作，而不是看到解密告警就删除密钥。已经交付给进程的明文数据密钥不会因停用主密钥而自动消失。

取证要保存原始事件、查询条件、导出时间、时区和证据存放位置，并限制调查人员修改证据的能力。对日志设置独立权限与保留策略，必要时使用不可随意覆盖的保存方式。证据中只保留分析所需的标识和摘要，避免为了调查再次集中复制敏感明文。这样才能回答“发生了什么、证据覆盖到哪里、还有哪些未知”，而不是只留 1 张告警截图。

4 动手：核对一次最小权限与密钥轮换

这次练习在隔离的测试账号或测试环境完成，只使用合成订单。准备 1 把测试主密钥、1 个导出身份、1 个读取身份和独立的管理身份。保存当前策略和密钥状态，确认审计采集覆盖相关事件，设置回退负责人。不要对生产密钥执行停用、删除或权限实验。若没有实际环境，也可以使用下面的预期结果表做设计评审，但应明确那只能验证思路，不能证明真实平台已配置正确。

先写下权限预期，再执行请求。导出身份仅获得指定测试密钥上的 GenerateDataKey；读取身份仅获得相同密钥上的 Decrypt；管理身份负责测试轮换但没有业务解密资格。按平台要求补齐必要的资源策略与条件。权限表中的“拒绝”是最终结果要求，不意味着每项都必须手工添加 1 条显式拒绝；精确授予必要权限、阻断其他授权路径，同样可能实现它。

随后生成 1 份合成文件，保存密文、包裹密钥、上下文与实际主密钥标识。用读取身份解密，核对恢复内容与原内容一致；再查审计中的身份、操作和结果。测试输出只展示摘要与请求标识，不输出明文数据密钥。若本地缓存导致第 2 次读取没有 KMS 事件，应记录缓存行为，并用应用访问日志补上这次读取的证据。

接着核对轮换。自动轮换通常是在同一密钥资源下生成新的密钥材料版本，新加密使用当前版本，旧版本继续支持历史解密；支持的密钥类型、周期和触发方式因平台而异。手动轮换常见做法是创建新密钥、更新新写入的引用，再迁移旧数据。不要把“别名已切换”当作“所有历史密文已经迁移”，也不要默认应用缓存和托管服务配置会立即跟随别名变化。

轮换前保存测试旧密文，轮换后再生成新密文，分别验证两者可读，并核对新写入实际使用的密钥或版本证据。对于托管自动轮换，历史解密可能自动选择旧材料；对于换到新密钥资源的手动轮换，旧密文通常仍需旧密钥。平台若不在审计中暴露材料版本，就用可获取的配置与行为证据说明验证范围，不要编造版本字段。

需要迁移时，可以根据平台与数据格式选择重新包裹数据密钥，或完整重新加密数据。重新包裹一般只更换数据密钥外层保护，不改动文件密文；若怀疑明文数据密钥也已泄露，仅重新包裹不能消除风险。最后恢复测试配置、清理测试身份并记录旧密钥保留条件。只有确认历史数据、备份和恢复依赖都不再需要它，才能进入有等待期和复核的退役流程。

5 零信任与边界防护取舍

零信任在这里意味着，不因为请求来自内网就默认可信。每次访问都要依据身份、动作、资源和适用条件做授权。它不要求每个文件块都重新向身份服务登录，也不意味着取消网络分区。订单服务仍应把数据库放在适当的网络边界内，限制出口，让运行身份只能访问业务需要的对象和密钥。身份约束与网络约束配合，才能减少单点失守后的扩散。

私有访问入口可以减少服务暴露范围，出口控制有助于限制数据外传，但它们不会自动修复过宽的 Decrypt 权限。反过来，正确的密钥策略也不能阻止已获授权的进程把解密结果发送出去。边界防护应同时覆盖入口请求、运行身份、数据访问和出口去向。对公网接口的限流与恶意请求拦截有价值，但若攻击者使用合法后台令牌，它们可能看不到真正的越权路径。

授权条件要选平台实际支持、业务也能稳定提供的信号。例如限制服务代调用、特定网络入口或预期加密上下文，可以收窄可用路径；但同样可能误伤备份、跨区域恢复和管理员应急流程。先画出正常请求与恢复请求的路径，再在测试环境逐条验证。不要把某个条件写进策略后，就仅凭策略文字宣布边界已经成立。

数据密钥缓存展示了安全与可用性的具体取舍。缓存能减少 KMS 请求与延迟，也让进程在短暂故障时继续工作；缓存时间越长，明文数据密钥在进程中的可用窗口通常越长，主密钥撤权对已有缓存的即时影响也越小。缓存上限还可能受内存、消息数量或加密库约束，不能只看时间。对高敏感导出，可以选择更短缓存并加强读取审计，对普通批处理则依据实际风险设定边界。

交互里的数字只是帮助比较趋势，不是推荐配置。真实服务要测量访问频率、峰值负载、配额、延迟和失败处理。遇到 KMS 拒绝时不能偷偷改为明文保存，也不能无限重试把故障放大。程序应明确失败、保持密文和元数据完整，并给出可重试或需要人工处理的状态。必要的应急访问应预先限制时效与范围，并有完整审计，不能依赖长期开放的超级权限。

6 常见坑：长期密钥写进流水线

持续集成流水线需要发布订单服务，于是有人把云访问密钥放进变量，再把变量传给构建脚本。变量在界面里显示为掩码，并不代表它不会流进调试日志、构建缓存、测试报告或容器镜像。只要脚本能读取它，脚本依赖和被插入的步骤也可能读取它。更危险的情况是生产和测试共用同一套凭据，泄露后攻击者无需再跨过环境边界。

这里要分清云 API 访问密钥与 KMS 加密密钥。前者证明调用者身份，后者保护数据。轮换 KMS 主密钥不会自动撤销流水线里的访问密钥；换掉访问密钥也不会重新加密已经泄露的数据。处置时应先确定泄露材料的类型，再判断攻击者能调用哪些服务、能读取哪些密文、是否取得明文数据密钥或业务明文。名称里都有“密钥”，并不表示修复动作相同。

更合适的分发方式是让流水线基于可信执行身份或受限的身份联合换取短期凭据。信任条件要限制仓库、分支、工作流、受众和运行环境等实际可验证属性，防止任意代码都能换到生产角色。短期凭据减少长期暴露时间，但在有效期内仍可能被滥用。若角色权限过大，改成短期凭据只是缩短攻击窗口，不能代替最小权限。

构建身份通常不需要解密生产订单。将构建、发布与运行身份分开，可以避免“为了部署方便”把读取业务数据的权限一起交给构建脚本。必须传入的数据库密码等机密，应从受控机密系统按需取得，限制读取身份，并避免打包进发布产物。日志脱敏只是补充措施，首要目标是减少敏感材料进入构建过程的机会。

发现长期凭据泄露后，应撤销或禁用相关凭据、替换受影响的机密，并查明它曾经获得的权限。只从最新提交删除字符串，无法消除仓库历史、缓存和已下载副本中的泄露。调查还要寻找新增身份、角色信任修改、密钥策略变化和持久授权，这些可能让攻击者在原凭据失效后继续访问。修复完成的证据应包含授权收缩和复测结果，不能只有“日志已经打码”。

7 案例：被盗令牌横向移动

假设订单导出任务的短期令牌从调试输出中泄露，攻击者在有效期内取得它。原设计允许导出任务读取当日订单并生成数据密钥，但某次排障留下了宽泛的角色切换权限。目标角色又能够修改对账密钥策略。攻击者并不需要破解密码算法，而是沿着合法接口寻找权限组合：先换成权限更高的角色，再把自己的会话加入解密范围，最后读取历史对账文件。

横向移动是从最初立足点扩展到其他资源或身份。这里跨越的关键边界包括运行身份到管理身份、当日导出到历史文件、生成新数据密钥到解开旧数据密钥。若只看“令牌由合法身份签发”，很容易漏掉这种变化。应追问业务是否需要这条路径，以及策略、角色信任和授权凭据是否让这条路径成为现实。

攻击链的每段都有不同证据。身份切换记录显示原会话与目标角色，策略变更记录显示权限如何放宽，对象访问记录显示历史文件是否被读取，KMS 记录显示包裹密钥是否被成功解开。若托管服务代调用，要结合服务与用户身份信息理解事件。缺少对象访问证据时，可以确认发生过用钥，但应保留“是否拿到完整业务明文”的不确定性。

值班人员先限制泄露身份继续获取会话，并按平台机制处理现有会话；同时撤回攻击者新增的策略与授权，阻断进入目标角色的路径。随后评估是否需要停用相关密钥。若历史对账文件仍在持续外泄，停用可能有必要，但要同时通知订单和财务流程的负责人，准备业务降级。不能用删除日志或直接销毁密钥来代替响应，否则会丢失证据，也可能造成不可恢复的数据损失。

调查中发现 1 次 Decrypt 被拒绝，不等于整次攻击失败；后面可能有成功请求，也可能已有缓存。发现 1 次成功请求，也不能推断所有订单已泄露。应建立时间线，列出已确认事件、可能影响的数据范围和缺失证据，再决定通知与修复范围。对于已取得的明文，即使撤销权限也无法远程收回，需要进入数据泄露处置流程。

复盘后的改动应切断具体路径：导出角色失去非必要的角色切换权限，管理角色信任范围收窄，密钥策略修改需要受控流程，导出与读取职责分离，历史对象权限按业务范围限制。把“策略变化后出现异常解密”的关联检测纳入告警，再用合成数据重放受控测试。这样才能证明攻击链确实被截断，而不是只把令牌的有效期改短了。

8 把身份与检测写进安全方案

安全方案要把原则变成可以核对的对象。不要只写“使用 KMS 加密”，而要写出订单导出由哪个身份生成数据密钥，历史读取由哪个身份执行 Decrypt，使用哪把主密钥，密文和包裹密钥存在哪里，以及哪些人可以改变这些关系。密钥标识应附上账号、区域和用途，避免把测试配置误当成生产证据，也便于恢复时找到真正需要的密钥。

权限矩阵至少覆盖 Encrypt、Decrypt、GenerateDataKey、策略修改、轮换、停用和删除。矩阵之外还要检查谁能授予这些权限，包括角色切换、修改信任关系、创建授权凭据及管理高层限制的能力。一个表面上没有 Decrypt 的管理员，如果能无限制地把它授予自己，仍然可能绕过职责划分。方案应明确这种提升权限的路径由什么流程或独立约束控制。

轮换计划应区分自动更新材料、手动切换到新密钥，以及历史数据迁移。写明触发条件、执行身份、兼容性测试、回退条件和旧密钥保留规则。常规轮换主要缩短长期依赖同一材料的时间；泄露后的应急处理还要评估数据密钥与明文是否已经暴露。把常规轮换写成“发生泄露后自动安全”会夸大它的作用，也会漏掉重新加密和凭据撤销等动作。

审计部分既要列事件，也要列核对方法。对敏感用钥记录主体、动作、密钥、结果和可用的关联字段；对策略变化保存变更前后内容或可追溯版本，并关联变更申请。若审计事件只包含策略变更动作、没有完整策略正文，方案要补上安全保存的配置快照。对缓存与服务代调用说明证据覆盖范围，确保读者知道哪些读取需要通过应用或存储日志补齐。

检测规则应有负责人和处置入口。比如导出身份首次成功解密历史文件时，由值班人员核对预期行为、关联会话与对象访问，必要时限制身份并保全证据。告警阈值要结合基线与变更窗口，不能把任意次数的失败都视为入侵，也不能为了降低噪声而永久忽略拒绝事件。演练应验证从告警到找到证据、再到实施阻断的实际耗时。

验收可以选取少量具有代表性的请求：允许的导出成功，越界解密失败，轮换后新旧密文都能按预期读取，策略变更能与用钥事件关联，失陷身份被限制后无法再次取得所需权限。把请求结果、审计标识和剩余限制一起交付。验收不是证明系统永远安全，而是证明约定的边界在明确条件下确实有效，并为将来变更保留可重复的核对方法。

9 从云安全进阶走向高可用设计（C43）

密钥服务也是业务依赖。即使数据库副本和应用实例都健康，KMS 不可达、权限被误删或主密钥被停用，订单读取仍可能失败。判断可用性时，不能只问“数据还有几份”，还要问“这些副本能否在恢复位置被合法解密”。备份完整但找不到对应密钥，实际恢复结果可能仍然不可用。

进入 C43 前，先整理密钥依赖清单：哪些请求每次都需要 KMS，哪些只在进程启动或数据密钥缓存失效时需要，哪些由存储服务代调用。短暂故障时，已有实例和新启动实例可能表现不同。已经缓存数据密钥的进程可能继续服务，新扩容实例却无法初始化；因此只观察旧实例成功，不能证明故障期间扩容和恢复也成功。

跨区域恢复尤其要核对密钥是否在目标区域可用、恢复身份是否获得授权、包裹密钥是否能按预期处理，以及审计是否覆盖恢复期间的操作。复制对象不等于复制了可用的解密路径，关联的多区域密钥也不意味着所有策略自动一致。具体复制与恢复机制取决于服务支持，应在恢复演练中验证，不能只看架构图上连了线。

安全与可用性需要共同安排变更。轮换、策略收紧和旧密钥退役，都应有分批验证与回退窗口；回退通常依赖仍可使用的旧密钥和完整元数据，不能先删除再考虑恢复。故障时可以限制敏感导出、保留排队任务或明确返回暂时不可用，但不能以绕过加密作为常规降级路径。

带着这些依赖进入 C43，我们才有条件讨论冗余、故障转移和恢复目标。真正要交付的是一条在正常、失陷和故障状态下都能解释的访问路径：正常请求有必要权限，异常请求能被阻断和调查，恢复请求也具备受控授权。高可用设计会继续检查这条路径在部分组件失效时是否仍然成立。

放进方案里

订单服务将生产、测试身份与密钥资源分开登记，清单包含账号、区域、实际密钥标识、用途和负责人。生产对账文件使用信封加密，导出身份只在指定密钥与业务上下文中请求 GenerateDataKey，读取身份按对象范围取得密文，并在授权条件满足时请求 Decrypt。构建与发布身份使用受限的短期凭据，不获得生产订单解密权限；数据库密码等机密通过受控机密分发路径取得。

密钥管理与数据使用职责分开，策略修改、授权创建和角色信任变化进入受控变更流程，防止管理员未经复核就给自己增加业务解密资格。自动轮换按平台支持的类型配置，手动换钥先验证新写入，再核对旧密文、备份与恢复任务。历史数据需要旧密钥时继续保留，退役前确认依赖已解除；疑似数据密钥泄露时另行评估重新加密，不能只切换别名。

敏感用钥及策略变更必须可在审计中核对，记录主体、操作、密钥、结果和可用的关联字段，并与对象读取、应用访问和变更记录关联。缓存引起的本地解密由应用记录补充，服务代调用按实际身份链解释。日志采用独立权限和保留策略，避免业务身份修改调查证据。异常解密、越界尝试及变更后突增访问由值班人员核实并保全原始记录。

令牌失陷时先限制相关身份和会话，撤回新增授权，再按影响决定是否停用密钥，同时评估已交付的明文与数据密钥。上线验收使用合成数据证明允许请求成功、越界请求失败、轮换后新旧数据可读、异常操作可追溯。跨区域恢复另行验证密钥可用性、恢复身份与日志覆盖，把密钥服务依赖纳入 C43 的恢复演练。

10 小结：下一步高可用设计（C43）

本课把加密开关展开为密钥归属、信封加密、动作授权、轮换和审计联动。轮换不等于重新加密全部历史数据，撤权也不能收回已经交付的明文。保护效果取决于身份、数据访问和用钥权限是否共同收窄。

进入 C43 前，用自己的方案回答 3 个问题：读取身份为什么不需要 GenerateDataKey？发生异常 Decrypt 时，如何关联身份、对象与策略变化？目标区域已有备份时，还需要什么条件才能成功恢复明文？能说明这些条件，才算把密钥边界接到了高可用设计上。