IaC (基础设施即代码)

什么是 IaC (基础设施即代码)

IaC (Infrastructure as Code) 是一种将服务器、网络、存储等基础设施配置以代码形式定义和管理的方法。它不依赖手动 GUI 操作或命令执行，而是通过声明式代码描述基础设施的"期望状态"，由工具自动实现该状态。

从安全角度来看，IaC 的重要性在于其可重现性和可审计性。由于所有基础设施变更都以代码形式记录，可以通过版本控制追踪谁在何时做了什么更改。这使得检测未授权变更和快速回滚到已知安全状态成为可能。

IaC 的安全优势

• 配置标准化：安全组、IAM 策略、加密设置等可以模板化，并在所有环境中统一应用。构建新环境时不会遗漏安全配置
• 通过代码审查实现治理：基础设施变更以拉取请求的形式可视化，安全团队可以在部署前进行审查。可以在审查阶段发现危险变更，如将安全组开放给 0.0.0.0/0 或禁用加密
• 漂移检测：通过将实际基础设施状态与代码定义进行比较，可以检测未授权的手动更改（配置漂移）。这对维护合规性和防止影子 IT 至关重要
• 快速恢复：如果环境遭到入侵，可以在几分钟内从代码重建干净的环境。与手动重建相比，大幅缩短了恢复时间

策略即代码护栏

策略即代码 (Policy as Code) 通过代码自动验证基础设施配置是否符合组织的安全策略，进一步增强 IaC 的安全性。

代表性工具包括 Open Policy Agent (OPA)、Checkov、tfsec 和 AWS CloudFormation Guard。将这些工具集成到 CI/CD 流水线中，可以自动阻止违反策略的部署。例如，可以强制执行"S3 存储桶必须启用加密"或"安全组不得允许来自 0.0.0.0/0 的入站访问"等规则。

策略即代码的关键是从少量关键规则开始，逐步扩大覆盖范围。一次性强制执行过多规则会增加误报，导致开发团队绕过检查。

主要 IaC 工具比较

IaC 工具大致分为两类：使用声明式 DSL（领域特定语言）编写的类型和使用通用编程语言编写的类型。根据组织的技术栈和运维需求进行选择。

IaC 安全最佳实践

以下是安全运维 IaC 的实用最佳实践。

密钥管理的分离是最重要的原则。绝不能将数据库密码、API 密钥、证书等敏感信息直接写入 IaC 代码中。应使用 AWS Secrets Manager、HashiCorp Vault 或 Azure Key Vault 等专用服务，并从 IaC 代码中引用。

IaC 执行角色的最小权限同样至关重要。CI/CD 流水线用于执行 IaC 的 IAM 角色应仅具有所需的最小权限。为方便而授予 AdministratorAccess 意味着一旦流水线被入侵，整个环境都将面临风险。

状态文件保护对 Terraform 用户至关重要。状态文件包含所有资源的实际值，可能包含敏感信息。应加密状态文件，将其存储在受访问控制保护的位置（如启用版本控制的 S3），并实施状态锁定以防止并发修改。

常见误解

采用 IaC 就能自动提升基础设施安全性

IaC 为提升安全性提供了基础，但如果代码本身包含脆弱的配置，这些漏洞将被一致地部署到所有环境中。只有结合策略即代码的自动验证和代码审查流程，才能真正发挥效果。

IaC 代码不包含敏感信息，可以放在公开仓库中

IaC 代码包含对攻击者有价值的信息，如账户 ID、内部网络配置和安全组规则。此外还存在意外提交密钥的风险。应在私有仓库中管理，并启用密钥扫描。

相关术语