2.4 IaC安全基线演练

2.4 IaC 安全基线演练

本节摘要：基础设施即代码（Infrastructure as Code，IaC）让环境可以像软件一样版本化与审查，也让安全基线第一次拥有了"自动执行"的载体。本节走完一次完整演练：把前三节的评审结论写成带安全约束的部署模板，在上线前用静态检查拦截违规，再用漂移检测守住运行期。读完全节，你会拥有一套可搬走的基线落地方法。

为什么基线必须长在模板里

先看没有 IaC 时基线的命运。某团队把"存储位置必须私有加密"写进了安全规范文档，半年后审计发现：规范还在文档里，环境里已经多出七个公开的存储位置——每个都是某次赶工时手工点的。文档型基线依赖人的记忆，而人的记忆敌不过交付压力。

IaC 改变了游戏规则：环境由模板描述，模板进代码仓库、走版本审查。安全基线从"文档里的要求"变成"模板里的属性"与"流水线里的检查"，基线的执行者从人变成机器。安全责任的位置也随之移动——从"运维记得配"变成"模板没配就部署不了"。这是安全左移在基础设施层的具体形态，也是 CCSP 架构域与开发域的交汇点。

演练第一步：把基线写进模板

以一个应用加数据库的最小环境为例，模板用主流 IaC 工具的声明式风格书写（不同工具语法有别，属性项相通）。基线要求：数据库不公开访问、存储强制加密并拒绝公开、主机登录密钥统一托管、所有资源打环境标签便于归属追踪。

# 环境模板（声明式，节选关键安全属性）
resource "app_database" {
  engine        = "mysql"
  instance_class = "db.mid"
  # 基线1：数据库实例不允许公网访问
  public_access = false
  # 基线2：静态加密开启，密钥走自管密钥服务
  storage_encrypted = true
  kms_key_id    = module.kms.db_key
  # 基线3：强制加密连接
  require_tls   = true
  # 基线4：审计日志外送到日志服务
  audit_log_target = module.loghub.db_stream
}

resource "app_bucket" {
  # 基线5：默认私有，且显式拒绝一切公开策略
  public_access_block = ["acl", "policy", "port"]
  # 基线6：静态加密与版本化
  server_side_encryption = module.kms.obj_key
  versioning = true
}

resource "app_server" {
  ami_id    = data.trusted_image.golden_latest
  # 基线7：仅密钥登录，且密钥来自统一托管
  login     = { password = false, key_pair = module.keyhub.app_key }
  # 基线8：元数据服务强制令牌校验
  metadata_tokens = "required"
  tags      = { env = "prod", owner = "team-order" }
}
​

模板审查的方法与 2.3 的点检一脉相承，只是位置从"已建资源"移到了"将要建的资源"。逐条基线都对应一个可查询的属性，审查即比对。相比人工点检，模板审查有复利：问题在部署前修一次，之后每次部署自动继承修复。

演练第二步：静态检查拦截违规

模板进仓库后，第一步防线是静态检查工具——用规则集扫描模板，违规项在合并请求阶段就挡下来。下面是一条典型的策略检查输出：

# 静态策略检查（合并请求触发，节选）
$ iac-scan check --policy security-baseline/
  PASS  app_database.public_access = false          对应基线1
  PASS  app_database.storage_encrypted = true       对应基线2
  FAIL  app_server.metadata_tokens 未声明           对应基线8
  WARN  app_server.tags.owner 缺失                  对应基线9
  结果: 1 FAIL 2 PASS 1 WARN —— 合并被阻断

# 违规修复提示由工具自动给出：
#   建议补丁: metadata_tokens = "required"
#   参考基线: 基线8 元数据服务令牌校验（第 2.3 节 计算组件点检表）
​

策略规则库的来源就是 2.3 的组件点检表：每张表里的"关键核对项"翻译成一条机器可判定的规则。规则本身同样进版本管理，谁加的、为什么加、对应哪次事故，提交记录里全有——这套"规则也有出处的"治理，是审计时最好用的证据链。

演练第三步：漂移检测守运行期

模板管住了"出生"，管不住"长大"——上线后有人绕过流水线手工改配置，环境与模板出现偏差，这就是配置漂移。漂移检测的原理是把实际环境定期与模板比对，差异即告警。用一张图把三步串起来：

漂移处置有个实务要点：告警之后别急着改回。先判断漂移是误操作还是应急操作——若是故障时手工放宽的临时规则，直接改回可能扩大故障。正确流程是：确认漂移原因、若属应急则补记变更单并约定回滚时限、到点归还基线。第六章运营域会把这套流程长成完整的配置合规体系，这里的漂移检测就是它的技术底座。

演练复盘与变式

把整场演练收个尾。背景：订单系统要搭生产环境。操作：评审结论转成九条基线写进模板，静态检查与漂移检测双闸把守。结果：赶工期的手工变更被合并卡点挡下两次，上线后三个月零基线外资源。解读：基线的执行力来自"违规动作的成本高于守规动作"，模板让守规成为最省力的路，这与 2.2 职责分离一节"让守规矩的路最短"的原则完全同构。

变式一：多账号环境。基线加一条组织级约束，由管理账号强制下发，任何子账号的模板都逃不开——适合中大厂。变式二：存量资源。历史环境没有模板，先逆向生成模板再逐步收口，优先级按 2.3 点检的风险排序，暴露面类先行。

基线的组织落位：谁写、谁审、谁守

技术之外，基线要回答三个组织问题。谁写：基线规则由安全团队起草、平台团队评审可执行性，双方共同签字——安全单独写的规则常因"没法落地"被绕开，平台单独写的又缺安全判断，合写是唯一可持续的形态。谁审：模板变更的评审人里必须有安全视角，最轻的实现是在代码仓库里给模板目录设置强制评审人。谁守：基线的日常守护者是流水线与漂移检测，但例外审批需要一个明确的人——没有例外通道的组织会发明自己的例外通道（直接绕过流水线），那是最坏结局。

给基线治理定一个健康的度量：例外率。例外单占比长期低于百分之五，说明基线设计贴合实际；高于两成，说明基线脱离现实、正在训练全员绕行——这时该改基线而不是抓违反。基线是活的规则集，它随平台能力、威胁态势与团队成熟度定期修订，修订记录本身就是最好的安全治理证据。

本节要点回顾

• 基线的执行力来自载体：文档型基线靠记忆，模板型基线靠机器；违规成本高于守规成本时，守规才成为默认选择。
• 三步闭环：基线写进模板、静态检查卡在合并请求、漂移检测守运行期，三步分别管住出生、入口与日常。
• 规则库要有出处：每条检查规则对应一次评审结论或一场事故，规则自身的版本史就是审计证据链。
• 漂移处置先问原因再动手：应急性漂移直接改回可能扩大故障，补记变更单、约定期限、到点归还。
• 度量例外率而不是违规率：例外率长期过高，该修订的是基线本身。

本节是第二章的落点，也是全册"安全结论必须可执行"理念的第一示范。下一章进入数据安全域——基线里最重的两条（加密与密钥）在那里展开成完整体系。