策略即代码与基础设施即代码安全：真正的区别是什么？

以及为什么你的团队不能混淆它们

原文由 Gomboc 发布。
作者：John Kamenik，Gomboc 首席 DevSecOps 工程师。

直言不讳：如果你的团队将策略即代码（PaC）和基础设施即代码（IaC）安全视为可互换的，那么你正在为自己埋下合规漏洞、安全事件和无休止的 Slack 线程争论的隐患。

我多年来一直在解决云安全问题——从因 Terraform 模块配置错误导致 S3 存储桶开放而引发的数十个漏洞赏金支付，到“已批准”策略仅存在于纸上但代码中被忽略的合规失败。现实是：PaC 和 IaC 安全解决的是不同的问题。将它们结合使用，你可以更快、更安全地交付。将它们视为同义词，你将花更多时间救火而不是构建。

穿透术语：这些术语的实际含义

策略即代码（PaC）：你的规则手册，自动化

PaC 是关于将组织的防护栏编码为可执行逻辑。像 Open Policy Agent（OPA）或 HashiCorp Sentinel 这样的工具允许你定义规则，例如：

• “没有加密的数据库不允许存在。”
• “所有云资源必须具有成本分配标签。”

但关键在于：PaC 不会自动修复违规行为。它就像有一个限速标志——它告诉你规则，但不会在有人加速时猛踩刹车。

真实示例：我曾与一个团队合作，他们强制执行了一项要求多可用区 RDS 实例的 PaC 策略。然而，开发人员为了测试“临时”在 Terraform 中覆盖 multi_az = false……并忘记恢复它。策略存在，但执行是手动的。在区域中断期间，混乱随之而来。

IaC 安全：你的代码安全网

IaC 安全工具（如 Checkov、TFsec 或其他现代扫描器）在部署前扫描你的 Terraform/CloudFormation，以捕获违反最佳实践或 PaC 规则的错误配置。它们回答：

• “这个安全组是否允许 0.0.0.0/0 在端口 22 上？”
• “这个 S3 存储桶是否配置为阻止公共访问？”

最好的工具不仅仅是喊“失败”——它们给你一个准备就绪的 PR 修复。在我上一个组织中，将 IaC 安全集成到 CI/CD 管道中，在 3 个月内将生产环境中的“糟糕，我忘了”错误配置减少了 70%。

关键区别：意图与实施

• PaC 定义了应该发生什么：它是理想化的。你可以编写一个要求“所有 EC2 实例必须仅使用 IMDSv2”的策略，但如果工程师没有扫描他们的 Terraform，该策略就只是合规文件夹中的一个 PDF。
• IaC 安全确保如何发生：它是可操作的。当开发人员编写 metadata_options { http_endpoint = "enabled" } 而没有 http_tokens = "required" 时，扫描器会阻止 PR 并说：“这是强制执行 IMDSv2 的确切代码更改。”

没有 PaC，你的 IaC 安全工具就没有北极星——你会被动地追逐每一个 CVE 和合规复选框。
没有 IaC 安全，你的 PaC 就是一列未执行的“可有可无”。

为什么成熟团队结合两者

在高性能的 DevOps 文化中，PaC 和 IaC 安全就像安全带和安全气囊：

• PaC 设定标准（例如，“所有部署必须标记为 ’env’”）。
• IaC 安全自动修复（例如，为未标记的资源添加 tags = merge(var.tags, { env = "prod" })）。

在规模上，这种组合是不可协商的。我曾见过一个金融服务客户因为他们的 PaC 策略要求“月度访问审查”但他们的 IaC 允许具有通配符（*）权限的 IAM 角色而审计失败。策略是完美的。代码不是。

现代团队如何弥合差距

如今，许多团队淹没在无人遵循的策略文档中。更好的方法弥合差距：

• 将策略编码化（例如，“没有版本控制的云存储不允许”）。
• 扫描 IaC 并自动生成符合这些策略的修复。
• 将防护栏嵌入开发工作流——在 IDE 中快速失败，而不是在部署后审计期间。

示例：如果你的 PaC 要求所有 Lambda 函数具有 15 分钟超时，正确的验证会检测到 Terraform 中的 timeout = 20，标记它，并建议确切的编辑——无需开会。

底线

• 没有 IaC 安全的策略即代码 = “我们有一个规则手册，但祝你好运遵循它。”
• 没有策略即代码的 IaC 安全 = “我们修复问题，但不知道它们是否与我们的目标一致。”

你的行动？将 PaC 视为你的战术手册，将 IaC 安全视为你的即时回放系统。 together，它们将合规从复选框练习转变为竞争优势。

附言：如果你的安全团队仍在通过电子邮件发送“已批准”配置的电子表格，也许是时候制定一个更好的计划了。人生苦短，不要手动执行策略。