2. Terraform敏感数据识别

在Terraform工程中，“敏感数据”并不是一个单一概念。很多团队把API Key、访问密钥、密码、Token、证书、连接串统称为“密钥”，结果在治理时无法区分风险等级，也无法判断哪些数据一旦泄露会直接导致云账号被接管，哪些只是配置信息。要建立有效的密钥凭据安全管理体系，第一步不是加密，而是识别：把不同类别的敏感对象分开，再定位它们会在Terraform生命周期的哪些环节留下痕迹。

一、五类敏感对象的边界与风险差异

从Terraform实际使用场景出发，可以把敏感数据分为五类：密钥、凭据、令牌、证书和配置。它们的共同点是“不应公开”，但泄露后的影响路径完全不同。

• 密钥（Key）：通常指云厂商的长期访问密钥，例如AWS的access_key与secret_key、阿里云的AccessKey Secret。它是最典型的“账号级”凭据，一旦泄露，攻击者可以直接调用云API，风险最高。Terraform中常见于provider块或terraform.tfvars。
• 凭据（Credential）：指用于登录或连接某个系统的用户名/密码组合，例如RDS数据库密码、Redis密码、对象存储的登录口令。它通常作用于单个资源或服务，泄露后影响范围相对可控，但仍可能导致数据被读取或篡改。
• 令牌（Token）：具有时效性的临时凭据，例如STS Token、OAuth Access Token、GitLab Runner Token、Kubernetes ServiceAccount Token。它的特点是“短期有效”，但如果在有效期内被截获，同样可以完成未授权操作。Terraform中常出现在CI/CD变量或远程后端认证配置里。
• 证书（Certificate）：包括TLS证书、私钥、CA证书链。证书本身是公开的，但私钥必须严格保密。Terraform中常见于tls_private_key资源、acme_certificate资源或Kubernetes Secret。
• 配置（Configuration）：指不含直接认证能力、但可能暴露内部拓扑或安全弱点的信息，例如内网地址、账号ID、区域、VPC ID、安全组规则、环境变量名。它单独泄露通常不致命，但会为攻击者提供侦察信息，属于“低敏感但需关注”的类别。

区分这五类的关键判断标准是：该数据是否可以直接用于认证或解密。可以直接认证的（密钥、凭据、令牌、私钥）属于高敏感；只能辅助攻击的（配置）属于中低敏感。这个判断决定了后续加密、掩码和审计的优先级。

二、Terraform生命周期中的敏感信息暴露面

Terraform的工作流大致是：编写配置 → terraform plan → terraform apply → 写入state → 后续plan/refresh。敏感数据会在多个环节被“物化”成可读文本，而这些文本往往被开发者忽略。

1. State文件是最大的暴露面。 Terraform会把资源的实际属性写入terraform.tfstate，包括数据库密码、密钥、证书私钥等。即使变量标记了sensitive = true，state中仍然以明文存储。例如一个RDS实例的password属性、一个tls_private_key的private_key_pem，都会完整出现在state里。如果state放在本地磁盘或未加密的S3桶中，等于把凭据直接暴露。

2. Plan输出会回显敏感值。 执行terraform plan时，Terraform会展示将要创建或修改的资源属性。对于标记为sensitive的变量，CLI会显示(sensitive value)，但资源属性本身如果来自未标记的变量或数据源，仍可能以明文出现在plan输出中。例如：

# 示例：plan输出中可能出现的敏感回显
+ resource "aws_db_instance" "example" {
    + password = "Example-Passw0rd-2024"   # 若未标记sensitive，会明文显示
    + username = "admin"
  }

此外，terraform plan -out=tfplan生成的plan文件是二进制格式，但其中同样包含敏感值，不能随意分发。

3. 日志与CI/CD输出。 在CI流水线中，TF_LOG=DEBUG会输出provider与API的交互细节，可能包含请求头中的Token、请求体中的密码。很多CI系统会把日志持久化并开放给团队成员查看，这等于把敏感数据写入了可检索的日志系统。即使使用了TF_LOG，也应在流水线中限制日志保留时间并做脱敏。

4. 变量文件与版本控制。 terraform.tfvars、*.auto.tfvars、.env文件如果被提交到Git，密钥就会进入版本历史。即使后续删除，历史提交中仍然可以恢复。这是最常见的人为暴露路径。

三、识别暴露面的实操方法

识别不是靠感觉，而是靠可执行的检查。以下给出一个可落地的排查流程，适用于已有Terraform仓库的团队。

1. 扫描仓库中的明文敏感值。 使用gitleaks或trufflehog对Git历史做扫描，重点匹配AWS Access Key（AKIA[0-9A-Z]{16}）、私钥头（-----BEGIN PRIVATE KEY-----）、常见密码字段。示例命令：gitleaks detect --source . --verbose。
2. 检查state存储位置与加密状态。 确认backend是否为S3、GCS、Azure Blob或Terraform Cloud，并检查是否启用了服务端加密、版本控制和访问日志。本地state必须立即迁移到远程后端。
3. 审查变量声明。 对所有包含密码、密钥、Token的变量添加sensitive = true，并确认没有在output中直接输出。示例：

variable "db_password" {
  type      = string
  sensitive = true
}

output "db_endpoint" {
  value     = aws_db_instance.example.endpoint
  # 不要输出 password 字段
}

4. 检查plan与日志的留存策略。 确认CI中是否开启了TF_LOG，如果开启，日志是否会被长期保存；plan文件是否被上传为制品。建议plan文件仅在流水线内短期保留，且不对外公开。

5. 建立敏感字段清单。 把每个模块中会接触敏感数据的资源属性列出来，例如aws_db_instance.password、aws_iam_access_key.secret、tls_private_key.private_key_pem、kubernetes_secret.data。这份清单是后续加密和审计的基础。

四、暴露面关系图

下图把五类敏感对象与Terraform生命周期中的四个主要暴露面放在同一张关系图中，帮助快速定位“什么数据、在哪个环节、以什么形式暴露”。

这张图的核心价值在于把“分类”和“暴露面”对应起来：密钥和凭据主要威胁State与变量文件，令牌主要威胁日志与CI输出，证书私钥则同时威胁State和plan文件。识别出这些对应关系后，后续的加密、掩码、审计和轮换才有明确的靶点，而不是笼统地“把所有东西都加密”。