2. 配置漂移检测基础：手动检测 vs 自动化检测、配置漂移的典型场景

配置漂移（Configuration Drift）是指基础设施的实际运行状态与预期声明式配置（如 Terraform、CloudFormation 或 Git 仓库中的定义）之间产生的偏差。这种偏差是导致生产故障、安全漏洞和审计不合规的首要原因之一。本章将系统讲解漂移检测的两种基本模式，并通过三个高频场景（安全组、IAM 策略、实例标签）建立对漂移的直观认知。

2.1 手动检测 vs 自动化检测

检测配置漂移的方式决定了发现问题的时效性和修复成本。下表从多个维度对比了两种模式的差异：

下图展示了两种检测模式在时间轴上的典型差异：

2.2 配置漂移的典型场景

不同资源类型的漂移表现形式和影响范围差异很大。以下三个场景是生产环境中出现频率最高、破坏性最强的漂移类型。

2.2.1 安全组（Security Group）规则漂移

安全组是云网络的第一道防线。漂移通常表现为：

• 非预期开放端口： 运维人员临时放通 22/3389 端口用于排障，事后未回滚。
• 源 IP 范围扩大： 将 /32 误改为 /0，导致公网任意 IP 可访问。
• 规则顺序变化： 手动插入拒绝规则后，原有允许规则被覆盖或失效。
• 孤立安全组： 资源释放后安全组未被清理，成为潜在攻击面。

2.2.2 IAM 策略（Policy）漂移

IAM 策略漂移直接影响权限边界，是合规审计的高频发现项：

• 内联策略附加： 直接给用户或角色附加内联策略，绕过 Group/Role 的权限管控基线。
• 托管策略版本回退： 手动将策略版本从 v5 回退到 v2，导致旧权限重新生效。
• 信任策略过度宽松： 将 Principal 设为 "*" 或 Condition 缺失，造成跨账号越权。
• 未使用的权限： 策略中包含大量未使用的 Action，违反最小权限原则。

# 漂移示例：Terraform 定义 vs 实际 IAM 策略
# Terraform 期望（基线）：
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::prod-bucket/*"
}

# 实际运行时（漂移后）：
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
  "Resource": "*"
}
# 漂移点：多出 PutObject/DeleteObject，Resource 从限定桶变为通配符

2.2.3 实例标签（Tag）漂移

标签是云资源成本分摊、自动化运维和环境隔离的核心元数据。标签漂移的典型表现：

• 标签键值缺失： 新创建的实例未继承自动标签策略，缺少 Environment、CostCenter 等必填标签。
• 标签值不一致： 同一环境出现 prod、production、prd 三种写法，导致成本报表和自动化脚本失效。
• 标签被手动修改： 运维人员手动修改实例标签用于临时测试，测试结束后未恢复。
• 标签传播中断： Auto Scaling 新启动的实例未从启动模板继承标签。

下图展示了标签漂移对成本分摊流程的影响链路：

2.3 漂移检测的核心原则

在进入自动化检测工具和 Runbook 设计之前，需要建立以下三条核心原则：

1. 声明式基线是唯一真理： 所有检测必须以 Git 仓库中的 IaC 代码或配置管理数据库（CMDB）中的期望状态为基准，而非以运行时状态为基准。
2. 检测频率必须高于变更频率： 如果环境每天发生 50 次变更，检测周期不应超过 30 分钟，否则漂移窗口将不可控。
3. 漂移分级处理： 并非所有漂移都需要立即修复。建议按风险等级分级：
   • P0（严重）： 安全组开放高危端口、IAM 策略越权 → 立即告警 + 自动回滚
   • P1（高）： 标签缺失、非核心资源配置偏差 → 告警 + 创建工单
   • P2（中）： 描述信息变更、非功能性属性漂移 → 记录日志，定期汇总