Terraform 安全审查：为什么扫描通过并不能证明基础设施安全

Terraform 把基础设施变更转化为可审查的工件，但成功的流水线并不会自动成为安全结论。扫描器只能读取提交给它的材料，按照已配置的规则检查，并在其分析模型内报告结果。它不会天然知道 CI 角色是否符合信任模型、谁能读取 state、哪些资源在 Terraform 之外被修改，也不能确认修复是否已在云环境中验证。因此，采购方需要的是从 HCL 到实际运行资源的完整审查，而不是 CI 中新增一个勾选项。

有效评估应回答一个实际问题：团队能否解释并证明检查了什么、在什么上下文中检查，以及哪些内容仍在边界之外？下面的方法帮助采购这一结果，同时避免承诺绝对安全，也避免用自动报告替代专业判断。

绿色扫描结果只是信号，不是结论

首先要区分语法、已求值的 plan 与线上环境。terraform validate 检查配置是否在内部一致，但不会验证远程服务。plan 加入某次运行的输入值和拟执行动作。扫描 plan JSON 可以为工具提供更多上下文和依赖关系，但部分 HCL 信息不会进入 plan，plan 本身还可能包含敏感值。每一层都很有用，却回答不同的问题。

扫描结果还取决于启用的策略集合。资源级 suppression、严重性过滤或 soft-fail 行为都可能让任务显示通过，却没有消除原始条件。因此，审查范围应包括扫描器配置：实际运行了哪些规则、哪些位置存在 suppression、由谁批准、何时复核，以及被跳过的检查是否仍保留在构建工件中。

采购的评估应包含哪些内容

最小审查对象不只是一个包含 .tf 文件的目录。审查人员需要根模块、自研与外部模块、provider 版本、dependency lock 文件、变量契约以及不含秘密值的 backend 配置。还需要针对约定环境生成的已保存 plan，因为它呈现计算后的值和预期动作。CI workflow、身份矩阵、state 访问策略以及云中人工变更说明共同构成证据集。

采购方应提前决定项目仅阅读代码，还是把代码与云环境进行比较。只看代码可以发现危险 HCL 和薄弱的流水线设置，却无法确认不存在 drift、外部策略或由其他方式创建的资源。若要形成与 production 相关的结论，需要对约定账户和日志提供受控只读访问，或由系统所有者在联合取证会话中展示相关事实。

State 与秘密构成独立信任边界

sensitive 标记会在普通输出中隐藏值，但本身不会把该值从 state 或 plan 中移除。Terraform 为部分临时值提供 ephemeral 机制，但是否可用取决于 Terraform 版本、provider 支持以及具体参数。审查不能只看到一个标记就结束，而应确定秘密的完整路径：秘密存储、CI 发放、日志、plan、state、备份和管理员访问。

应把 state 当作敏感资产。范围需要明确 backend、加密、锁定、workspace 隔离、紧急访问、读取审计和恢复流程，还要检查谁能修改 backend 设置或执行 state 命令。采购方无需通过邮件把 state 发给供应商；在约定环境中提供受限访问，或通过联合会话展示必要属性和证据，通常更安全。

Plan、CI 与云身份必须一起审查

受保护的流水线不会在扫描器运行后结束。评估需要连接触发事件、已审查 commit、生成的 plan 以及有权执行 apply 的身份。对于 GitHub Actions，应检查 permissions、不可信输入、第三方 actions、可复用 workflow、environments 和云令牌发放条件。OIDC 可以避免保存长期云密钥，但云端 trust policy 仍应使用受支持的 audience 与 subject 条件，限制仓库及适用的执行上下文，例如分支、environment 或 reusable workflow。

Provider 与 action 都是可执行依赖。Terraform lock 文件记录选定的 provider 版本与校验值，以支持可复现安装，因此其变更应进入 code review。第三方 action 引用、令牌权限和任何执行 pull request 代码的路径属于同一边界。即使没有发现缺陷，报告也应列出未阅读的依赖，以及对 hosted 或 self-hosted runner 作出的假设。

1. Commit标识本次审查的 HCL、模块引用、lock 文件和 workflow
2. Plan针对选定 workspace 计算变更
3. Review对照策略、例外和预期影响
4. Apply identity仅获得约定权限
5. Live verification确认结果与剩余 drift

Drift 会改变仅代码结论的意义

Terraform 根据配置、state 和 provider 返回的数据作出判断。控制台修改、紧急变更或另一套自动化都可能造成不一致。Refresh-only plan 用于显示远程对象变化并预览拟议的 state 更新；只有执行 refresh-only apply 才会写入该更新，而不会修改远程资源本身。是否接受或撤销 drift 仍由所有者决定。干净的 HCL 不能回答 production 是否与仓库一致。

项目应记录证据时间，并列明纳入的账户、区域和 workspace。对于关键资源，需要把线上云环境中的权限、网络边界、加密和日志与预期模型比较。每个差异应分类为已接受例外、未记录变更、未管理资源或代码缺陷。这样才能形成可执行修复，而不是含糊的“Terraform 错误”。

修复验证应该是什么样

设想一个明确的虚构场景：某团队用 HCL 创建存储和角色，扫描器通过，CI 通过 OIDC 应用 plan。审查发现 sensitive output 仍进入 state，一条 suppression 隐藏了公共访问规则，trust policy 多允许了一个分支，而且 bucket 设置曾被人工修改。这不是现实事件，而是说明四个局部绿色组件仍可能组成薄弱系统。

每项修复都应针对原因验证。对于秘密，需要展示新的数据路径，并在支持合适 ephemeral 或 write-only 机制时证明新 plan 或 state 不再包含该值。对于 suppression，应保留可辩护的例外，或者恢复规则。对于 OIDC，应收紧 trust policy，并演示未批准上下文被拒绝。对于 drift，应先确定期望状态，再重新运行 plan 并比较线上资源。复测应记录 commit hash、workspace、时间和实际观察结果，而不只是绿色任务截图。

采购矩阵与有用的交付物

若目标是快速检查新模块，可以选择范围明确的 HCL 与 plan 审查。重要发布前，更适合加入 state、CI 身份、已求值 plan 和云端只读比较。面对多个账户、共享模块和不同流水线，应采用抽样设计：深入检查关键 trust boundary，对重复配置选择有代表性的样本，并在报告中列出所有排除项。

采购方应获得覆盖矩阵、带证据的发现、suppression 与未检查组件清单、影响场景、修复优先级和复测结果。关于报告标准，可阅读有用的渗透测试报告应包含什么；相关的基础设施即代码评估则有助于区分通用 IaC 流程与 Terraform 特有问题。

Pentest.red 可以在约定 Terraform 边界和修复验证要求下开展云安全审计。申请评估前，请在范围规划器中记录仓库、workspace、云账户、允许的访问和所需证据。这样，不同报价才是在比较相同工作，最终结果也不会退化为再次运行扫描器。