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

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

从安全角度来看，IaC 的重要性在于基础设施配置的可重现性与可审计性。以代码形式用 Git 管理之后，谁在何时做了什么更改都会留下历史记录，从而能够检测出意料之外的配置变更，也能快速回滚到已知的安全状态。它还能防止手动配置容易引发的「配置漂移」(生产环境与定义之间的偏离)，为漏洞管理确保作为其基础的基础设施一致性。

IaC 的安全优势

配置标准化：安全组、IAM 策略、加密设置等可以模板化，并在所有环境中统一应用。构建新环境时不会遗漏安全配置
通过代码审查实现治理：基础设施变更以拉取请求的形式可视化，安全团队可以在部署前进行审查。像把安全组开放给 0.0.0.0/0、允许 S3 存储桶的公开访问、禁用加密这类危险变更，都能在应用到生产环境之前被发现
漂移检测：IaC 工具会检出定义与实态之间的差异，从而发现手动加入的未授权变更。Terraform 的 plan、AWS CloudFormation 的漂移检测都属于这类功能，对维持合规性也很关键
快速恢复：发生事件时可以从代码重建基础设施，大幅缩短恢复时间。从干净状态重建，还能排除被入侵系统的残留风险

策略即代码护栏

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

代表性工具包括 Open Policy Agent (OPA)、Checkov、tfsec 和 AWS CloudFormation Guard。将这些工具集成到 CI/CD 流水线中，就能自动阻止违反策略的基础设施变更。

应当验证的策略示例：

存储的加密是否已启用
安全组是否允许来自 0.0.0.0/0 的 SSH (端口 22)
日志记录是否已启用
代码中是否硬编码了密钥

对容器的镜像构建和无服务器函数的部署也应施加同样的策略检查，在整个基础设施范围内维持一致的安全基准。

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

主要 IaC 工具比较

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

Terraform

声明式 DSL (HCL)

HashiCorp 开发，用 HCL (HashiCorp Configuration Language) 编写。支持 AWS、Azure、GCP 等 3,000 多个 Provider，在多云环境中使用最广。状态文件 (tfstate) 的管理容易成为运维上的课题

AWS CloudFormation

声明式 (YAML/JSON)

AWS 原生的 IaC 服务。与 AWS 资源的集成最深，对新服务的支持也最快，并内置漂移检测与回滚。AWS SAM (Serverless Application Model) 就构建在它之上，是面向无服务器的框架。仅限 AWS

AWS CDK

通用编程语言

用 TypeScript、Python、Java 等通用语言定义基础设施，在内部生成 CloudFormation 模板。可以充分利用条件分支、循环等语言特性，通过高级抽象 (L2/L3 构造) 简化复杂基础设施的配置

Pulumi

通用编程语言

用 TypeScript、Python、Go 等编写的多云工具。思路与 CDK 相近，但不依赖 CloudFormation，由自有引擎管理状态。易于与测试框架集成

从安全角度看，无论选择哪种工具，重要的都是构建「代码审查 → 自动测试 → 审批 → 部署」的流水线。应把工具专用的安全扫描器 (Terraform 用 tfsec、CloudFormation 用 cfn-nag) 集成到 CI 中，形成在危险配置被合并之前就将其检出的机制。

IaC 安全最佳实践

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

密钥管理的分离是最重要的原则。绝不能将数据库密码、API 密钥、证书等敏感信息直接写入 IaC 代码中。应使用 AWS Secrets Manager、HashiCorp Vault、AWS Systems Manager Parameter Store 等专用服务保存，IaC 代码中只做引用。密钥一旦留在 Git 历史里，就会泄露给所有能访问该仓库的人，因此要用 git-secrets、gitleaks 等预提交钩子防止误提交。

漂移检测的自动化同样不可或缺。IaC 中定义的状态与实际基础设施发生偏离的「配置漂移」，多由手动的紧急变更或控制台操作造成。应建立定期执行 Terraform 的 terraform plan 来检出差异、或用 AWS Config 规则监控配置变更的机制。检测到漂移后，要判断是把它反映进 IaC 代码，还是把手动更改回退，以维持代码与实态的一致。

IaC 执行角色的最小权限也要一并落实。CI/CD 流水线用于执行 IaC 的 IAM 角色应仅具有部署所需的最小权限。为方便而授予 AdministratorAccess，意味着一旦流水线被入侵，整个环境都将面临风险。面向生产环境的部署应经过审批流程，使开发者无法直接对生产环境应用 IaC。

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

模块化与复用可以保持安全配置的一致性。把安全组、加密设置、日志设置等定义为公共模块，在所有项目中复用。对模块做版本管理，形成只要在一处修复安全补丁就能反映到所有环境的机制。

常见误解

采用 IaC 就能自动提升基础设施安全性: IaC 为提升安全性提供了基础，但如果代码本身包含脆弱的配置，这些漏洞将被一致地部署到所有环境中。只有结合策略即代码的自动验证和代码审查流程，才能真正发挥效果。
IaC 代码不包含敏感信息，可以放在公开仓库中: IaC 代码包含对攻击者有价值的信息，如账户 ID、内部网络配置和安全组规则。此外还存在意外提交密钥的风险。应在私有仓库中管理，并启用密钥扫描。

IaC (基础设施即代码)