企业官网建设流程全解析

• 应用安全
• SAST
• IaC

导读

本文以 tfsec 内置检查google-kms-rotate-kms-keys为线索，系统讲解 Google Cloud KMS（Cloud Key Management Service）加密密钥定期轮换的安全意义、触发告警的不安全配置形态、通过检查的安全配置写法，以及如何在真实 Terraform 工程中运行 tfsec 完成验证与修复。读完本文，你将能够准确理解rotation_period参数与 90 天轮换阈值的对应关系，掌握可复制、可运行的 Terraform 配置示例，并学会在 CI 与命令行环境中落地这项高严重级别检查。

该检查的官方规则文档位于仓库 docs/checks/google/kms/rotate-kms-keys/index.md，对应索引页可见于 docs/checks/google/kms/index.md，检查导航配置在 mkdocs.yml。

一、检查概览：规则 ID、严重级别与判定逻辑

google-kms-rotate-kms-keys是 tfsec 针对 Google Cloud 平台提供的静态检查规则，其核心判定逻辑可用一句话概括：

Google Cloud KMS 加密密钥（Crypto Key）必须配置定期轮换，且轮换周期不得超过 90 天。

与 AWS 平台中对应的同类检查aws-kms-auto-rotate-keys（默认严重级别为 medium，见 docs/checks/aws/kms/auto-rotate-keys/index.md）相比，Google KMS 轮换检查的严重级别更高，反映出 tfsec 对长期不轮换密钥风险更严格的默认态度。

为什么轮换周期以秒为单位？

在 Google Cloud 的 Terraform Provider 中，rotation_period参数直接采用Go 语言的time.Duration字符串格式（RFC 3339 时长语法），即以秒为单位的数字后跟s后缀：

• 15552000s= 15552000 秒 =180 天（约半年），不安全；
• 7776000s= 7776000 秒 =90 天，为本文检查所要求的安全阈值。

常见周期速查：

二、为什么会触发：风险原理与影响分析

安全检查的初衷

官方文档对这项检查的解释非常直接：

Keys should be rotated on a regular basis to limit exposure if a given key should become compromised.（密钥应定期轮换，以限制密钥一旦失窃后造成的暴露面。）

也就是说，KMS 密钥本质上是一种长期有效的加密凭据。如果某个密钥由于代码泄露、内部人员窃取、供应链攻击等原因被泄露，而密钥又不定期轮换，攻击者就可以在无限长的窗口期内持续解密数据、伪造签名或访问受保护资源。

可能造成的实际影响

官方文档将其概括为：

Exposure is greater if the same keys are used over a long period（同一密钥长期使用会导致更大的暴露风险）。

具体而言，长期不轮换 KMS 密钥会带来三类后果：

1. 失窃后的损失不可控：密钥一旦泄露，其覆盖的所有历史数据密文都可能被解密；
2. 违背合规基线：众多安全框架与行业规范（如 PCI DSS、ISO 27001 以及 Google Cloud 自身的安全最佳实践）都要求加密密钥定期轮换；
3. 轮换成本随时间放大：数据量越大、依赖该密钥的资源越多，后续手动轮换的迁移成本就越高。

推荐的修复方向

官方建议的修复方案是：

Set key rotation period to 90 days（将密钥轮换周期设置为 90 天）。

注意，tfsec 在本文档语境下以90 天为安全上限，因此在生产环境中设置rotation_period时必须确保其换算后的秒数不超过7776000s。

三、不安全配置示例（会触发检查）

以下 Terraform 配置会触发google-kms-rotate-kms-keys检查，因为密钥的轮换周期被设置为15552000s（180 天），超过了 90 天阈值。

resource "google_kms_key_ring" "keyring" { name = "keyring-example" location = "global" } resource "google_kms_crypto_key" "example-key" { name = "crypto-key-example" key_ring = google_kms_key_ring.keyring.id rotation_period = "15552000s" lifecycle { prevent_destroy = true } }

逐行解读

• google_kms_key_ring用于在指定location（此处为全局global）创建密钥环，是组织与隔离密钥的逻辑容器；
• google_kms_crypto_key引用密钥环的id作为key_ring，声明实际加密密钥；
• 关键点：rotation_period = "15552000s"明确将轮换周期设置为 180 天，超过 90 天安全阈值，构成检查失败的直接原因；
• lifecycle { prevent_destroy = true }防止密钥被意外销毁，这是生产密钥的常见保护手段，与轮换检查本身无冲突，可一并保留。

四、安全配置示例（通过检查）

将轮换周期改为 90 天（7776000s），即可通过google-kms-rotate-kms-keys检查：

resource "google_kms_key_ring" "keyring" { name = "keyring-example" location = "global" } resource "google_kms_crypto_key" "example-key" { name = "crypto-key-example" key_ring = google_kms_key_ring.keyring.id rotation_period = "7776000s" lifecycle { prevent_destroy = true } }

推荐做法：结合变量降低硬编码

在实际工程中，建议将轮换周期抽成变量，便于按环境差异化控制且便于审计：

variable "kms_rotation_period" { type = string description = "KMS 密钥轮换周期（Go duration 格式，秒为单位）" default = "7776000s" } resource "google_kms_crypto_key" "example-key" { name = "crypto-key-example" key_ring = google_kms_key_ring.keyring.id rotation_period = var.kms_rotation_period lifecycle { prevent_destroy = true } }

注意：将轮换周期抽为变量后，tfsec 仍会基于静态分析对字面量取值进行判断；若变量被覆盖为超过 90 天的值，在扫描时需结合.tfvars文件（--tfvars-file）或实际解析结果才能完整校验。

五、在真实工程中运行与验证

安装 tfsec

根据仓库 README.md 的说明，tfsec 支持多种安装方式：

# Homebrew / Linuxbrew brew install tfsec # Chocolatey（Windows） choco install tfsec # Scoop（Windows） scoop install tfsec # Go 直接安装 go install github.com/aquasecurity/tfsec/cmd/tfsec@latest

使用go install会直接安装自master分支的代码，tfsec --version不会报告版本号，生产环境建议优先使用带版本号的二进制发布物。

扫描目录

tfsec 会扫描指定目录下的所有 Terraform 文件；未指定目录时默认扫描当前工作目录。扫描退出码在发现问题时非零，否则为零：

tfsec .

仓库中已有大量可直接用于验证的示例目录，例如 _examples 与 test/testdata，可以创建包含上述不安全配置的临时 Terraform 文件后运行tfsec观察输出；修复后再次扫描，退出码应恢复为 0。

用 Docker 运行

如果不希望在本机安装，也可以使用容器镜像（详见 README.md）：

docker run --rm -it -v "$(pwd):/src" aquasec/tfsec /src

在 CI 流水线中落地

将检查嵌入 CI 时，可结合 GitHub Actions 或 Azure DevOps 任务运行 tfsec；仓库 README.md 对这两种集成方式均有说明。当扫描发现google-kms-rotate-kms-keys这类 high 级别问题时，流水线将以非零退出码失败，从而在密钥轮换配置回归前拦截变更。

六、相关配套能力：排除检查与忽略规则

用-e排除检查

如果某些场景下确实需要临时豁免该检查（例如短期密钥、非生产环境），可以使用-e参数排除（参考 README.md）：

tfsec . -e google-kms-rotate-kms-keys

用行内注释忽略

更精细的做法是使用tfsec:ignore:<rule>注释，将其放在问题行或资源块上方（参考 README.md）：

resource "google_kms_crypto_key" "example-key" { name = "crypto-key-example" key_ring = google_kms_key_ring.keyring.id rotation_period = "15552000s" #tfsec:ignore:google-kms-rotate-kms-keys }

忽略规则还可以附加过期时间，避免“忽略后遗忘”（参考 README.md）：

#tfsec:ignore:google-kms-rotate-kms-keys:exp:2026-01-01 resource "google_kms_crypto_key" "example-key" { name = "crypto-key-example" key_ring = google_kms_key_ring.keyring.id rotation_period = "15552000s" }

过期日期格式为yyyy-mm-dd，到期后该忽略自动失效，检查将重新生效，从而强制团队在期限内完成轮换整改。

七、在 tfsec 检查体系中的定位

• 该检查收录于 Google 平台 KMS 服务分组，索引页 docs/checks/google/kms/index.md 中将其描述为KMS keys should be rotated at least every 90 days；
• 规则全量清单可参考仓库根目录 rules.md，其中以表格形式集中列出了各平台检查的规则 ID、平台、服务与简述；
• tfsec 同样支持通过自定义 Rego 策略扩展检查能力（示例见 test/testdata/rego/policies/rego.rego，使用指南见 docs/guides/rego/rego.md），团队可以在内置的 90 天规则之上叠加组织内部的更严格策略（例如 60 天轮换）。

八、实践清单与要点总结

1. 阈值牢记：google_kms_crypto_key的rotation_period超过7776000s（90 天）即触发 high 级别告警；
2. 格式正确：轮换周期使用 Go duration 字符串（如"7776000s"），不要遗漏s后缀，也不要使用天数单位；
3. 生产必配：KMS 密钥应默认设置轮换周期，并在密钥环与密钥上启用prevent_destroy防止误删；
4. 流水线拦截：将tfsec .接入 CI，对 high 级别问题默认失败门禁；
5. 忽略要有期限：确需豁免时使用tfsec:ignore:google-kms-rotate-kms-keys:exp:yyyy-mm-dd，让豁免自动过期；
6. 持续审计：定期检查 rules.md 与 Google KMS 官方资源文档（原文档 Links 节指向的kms_crypto_key#rotation_period参考页），保持配置与最新最佳实践一致。

通过上述配置与流程，你的 Google Cloud KMS 密钥轮换将始终处于 tfsec 的 90 天安全基线之内，密钥失窃场景下的暴露窗口得到有效收敛。

• 应用安全
• SAST
• IaC