多云与混合云统一防护第4页：配置一致性、策略即代码与CSPM/CNAPP

01 · 配置漂移：多云一致性的头号敌人

CSA Top Threats to Cloud Computing（第11版，2021年）将「配置错误与变更控制不足」（Misconfiguration and Inadequate Change Control）列为头号云威胁——它既包括对象存储公开、安全组过宽这类显性错误，也包括「同一策略在不同云以不同方式实现」的隐性漂移。多云放大了漂移的三种成因：多入口（N个控制台+N套CLI/API，人工改配置无从审计）、多团队（平台组、应用组、数据组各自为政）、多事件流（并购、灾备切换、应急变更绕过流水线）。治理的答案是明确的：所有云配置必须经IaC流水线产生，所有变更必须可回溯到代码提交——「控制台只读，变更走Git」应成为多云组织的工程铁律。

02 · IaC与GitOps：单一事实源工程

基础设施即代码（IaC）工具将云资源以声明式代码描述：Terraform（开源生态事实标准，社区分支OpenTofu于2023年在Linux基金会下成立）、Pulumi（通用编程语言）、Bicep（Azure原生）、Crossplane（CNCF项目，以Kubernetes API统一管理多云资源）。GitOps（以Argo CD、Flux为代表）进一步将「Git仓库状态=集群/环境实际状态」作为持续对账目标，使配置漂移自动可见、可回滚。

• 单一事实源：每环境唯一代码仓库+唯一流水线入口；禁止双头维护（控制台与代码并存必然漂移）
• 状态文件安全：Terraform state含全部资源属性与敏感值，须远端加密存储+访问审计（state泄露=架构全图泄露）
• 变更治理：Code Review+计划（plan）输出强制评审；生产变更与回滚方案绑定审批
• 模块化复用：以组织级模块封装「默认安全」基线（加密、日志、私有子网），应用组只消费、不发明
• 凭证最小化：流水线对云只持有部署所需的窄权限角色（配合第3页OIDC短期令牌）

module "secure_bucket" {
  source = "./modules/storage"
  # 默认即合规：强制私有、强制加密、强制日志、强制锁定
  public_access_block = true
  encryption = { type = "SSE-KMS", key_rotation = true }
  logging    = { target_bucket = var.audit_bucket }
  object_lock = { mode = "GOVERNANCE", days = 30 }
  # 版本与生命周期策略纳入基线
  versioning = true
}
# CI准入：fmt/validate静态检查 + OPA策略测试 + Checkov扫描全绿方可合并

2.1 IaC供应链与流水线自身的安全

IaC把配置风险收敛为代码，也把供应链风险引入流水线本身。2021年Codecov供应链事件（攻击者篡改其Bash Uploader脚本，窃取使用CI环境变量的企业凭证）表明：流水线凭证与IaC工具链是多云边界上最敏感的信任根。防护基线：

• 模块来源固定：外部Terraform模块锁定版本与哈希（或经内部镜像仓库/私有Registry代理），禁止「latest」直接进入生产。
• 流水线凭证隔离：CI/CD秘密经OIDC短期令牌（第3页）注入，禁止在脚本、日志与制品中留痕；环境变量最小化、凭证作用域按任务拆分。
• 工具链完整性：CI运行器加固（临时runner、无持久化、出站白名单）；第三方Action/插件固定commit SHA并评审。
• 状态与计划保护：plan输出含资源全量敏感信息，其评审权限与日志留存按机密管理；state后端启用对象锁与访问审计。

参考：Codecov官方事件复盘：about.codecov.io/apr-2021-post-mortem。

03 · 策略即代码：安全意图的编译与执行

策略即代码（Policy as Code）用可版本化、可测试的代码表达安全意图，在IaC拉取请求（PR）阶段即拦截违规，把「事后审计」前移到「事前门禁」。主流工具链：OPA（Open Policy Agent）/Rego——云原生通用策略引擎，可嵌入Terraform计划、Kubernetes准入与CI步骤；Checkov/TFsec——IaC静态扫描；Conftest——以OPA策略测试任意结构化配置（JSON/YAML）。

package cloud.storage

default allow := false

allow if {
  input.resource.type == "storage_bucket"      # AWS/GCS/阿里OSS抽象资源类型
  input.change.actions[_] != "create"           # 非新建直接放行
}

allow if {
  input.resource.type == "storage_bucket"
  input.resource.values.public_access == false # 统一抽象字段
  input.resource.values.encryption.enabled == true
}

# 平台适配层：将各云原生字段映射到上述抽象字段（semantic adapter），
# 映射规则本身纳入代码评审，残留语义间隙在此显式登记。

3.1 跨云编译的语义间隙登记

04 · CSPM、CIEM与CNAPP：持续审计的平台化

策略即代码管「未来变更」，持续审计管「存量与漂移」。Gartner 2021年《Market Guide for Cloud-Native Application Protection Platforms》定义了CNAPP品类：将CSPM（云安全态势管理）、CWPP（云工作负载保护）与CIEM（云基础设施权限管理）整合为「构建—部署—运行」全周期统一平台，其出发点正是解决多云客户「单点工具碎片化、告警疲劳」的现实痛点。国内实践建议：能力域可分别建设（配置审计用CSPM、权限治理用CIEM、运行时防护用CWPP），但数据模型与告警管道必须统一（对接第7页检测工程）。

4.1 CIS Foundations跨云基线映射（节选）

本节参考来源（第4页）