Bigbadlonewolf/COMPLIANCE_AS_CODE

# 合规即代码 (Compliance as Code) 不要再把合规当成一份文档来处理了。请开始把它当作生产级软件来对待。 大多数云架构师依然受困于使用庞大且过时的电子表格来管理合规性——为了应付又一次的季度签字，将每一个 Terraform 资源映射到 PCI DSS、SOC 2 和 NIST 800-53 控制项。这个肮脏的秘密是什么？那张电子表格只是一个意向声明。它根本无法告诉你上个星期二实际部署到生产环境中的到底是什么。 这个代码库是我试图填补这一空白的尝试。我不依赖似是而非的推诿和手动检查清单，而是使用基于 OPA (Open Policy Agent) 的 Policy-as-Code (策略即代码)。每一个 Terraform 变更在有任何资源进入云环境之前都会被扫描。如果它违反了安全或合规规则，PR 就会被拦截。 ## 核心理念 真正的问题是：我们能否将一项监管要求转化为一个自动化、可重复且可验证的检查，并在每个 pull request 上运行？这正是该项目的核心理念所在。 ## 这是一个工程体系，而不仅仅是策略 这不仅仅是一堆 Rego 文件。它旨在成为一个真正的工程项目，采用与我们对待基础设施相同的标准： - **可追溯性 (Traceability)：** `docs/controls-mapping.md` 将具体的监管法规条款链接到了实际的策略规则上。不再疑惑哪个控制项涵盖了什么内容，也避免了跨框架的重复工作。 - **规范性 (Discipline)：** 这些策略都是经过版本控制、单元测试并在 CI 中强制执行的——就像我们其他的代码一样。 - **客观性 (Honesty)：** 范围限制被明确记录下来。这些策略只能捕捉它们能捕捉到的问题；它们并不能取代 QSA。 ## 仓库布局 ``` compliance-as-code/ ├── policies/ │ ├── lib/utils.rego # Shared constants (primitive roles, sensitive ports, etc.) │ ├── pci_dss/ # req_1 network, req_2 defaults, req_6 encryption, req_7 access, req_10 logging │ ├── soc2/ # cc6 logical access, cc7 system operations │ └── nist_800_53/ # ac access control, au audit logging, sc comms protection ├── tests/ │ ├── pci_dss/ # Unit tests — deny path + allow path for every rule │ ├── soc2/ │ ├── nist_800_53/ │ └── fixtures/ │ ├── compliant.tfplan.json # Should produce 0 violations │ └── noncompliant.tfplan.json # Should trigger violations across all frameworks ├── terraform/ │ ├── compliant/ # Reference-compliant GCP infrastructure │ └── noncompliant/ # Deliberately violating config (for CI validation only) ├── docs/ │ └── controls-mapping.md # Requirement → policy rule citation table ├── scripts/ │ └── check-plan.sh # Local evaluation script └── .github/workflows/ ├── opa-tests.yml # Unit tests (no GCP credentials needed) └── terraform-policy-check.yml # Fixture-based compliance check (no GCP credentials needed) ``` ## 自行尝试（无需云凭证） 代码库中已经提交了预先生成的 Terraform 计划测试夹具，因此你可以在没有 GCP 访问权限的情况下在本地运行策略检查。 ``` # 运行所有 unit tests opa test policies/ tests/pci_dss/ tests/soc2/ tests/nist_800_53/ -v # 检查故意不合规的 fixture — 应输出 violations ./scripts/check-plan.sh tests/fixtures/noncompliant.tfplan.json # 检查合规的 fixture — 应顺利通过 ./scripts/check-plan.sh tests/fixtures/compliant.tfplan.json # 直接评估一个 framework opa eval -d policies/ -i tests/fixtures/noncompliant.tfplan.json \ '[m | m := data.pci_dss[_].deny[_]]' ``` ## OPA 版本 需要 **OPA v0.59+**。新的策略（`req_*`、`cc*`、`ac`、`au`、`sc`）使用 `import rego.v1`。旧版策略（`network_segmentation`、`access_control`、`encryption_at_rest`、`logging_monitoring`、`least_privilege`）使用 `import future.keywords` —— 这两种语法可以无冲突地共存。CI 会安装 OPA v1.0.0。 ``` # 安装 (Linux) curl -fsSL -o /usr/local/bin/opa \ https://github.com/open-policy-agent/opa/releases/download/v1.0.0/opa_linux_amd64_static chmod +x /usr/local/bin/opa # 安装 (macOS) brew install opa ``` ## 框架覆盖范围 | 框架 | 执行的要求 | |---|---| | PCI DSS v4.0 | 1.3.2, 2.2.1, 6.3.5, 6.5.3, 7.2.5, 7.2.6, 10.2.1, 10.3.2 | | SOC2 TSC (2017) | CC6.1, CC6.3, CC6.6, CC6.7, CC7.1, CC7.2, CC8.1 | | NIST SP 800-53 Rev 5 | AC-3, AC-6, AC-17, AU-2, AU-9, AU-12, SC-8, SC-28 | 包含每条规则详细分解的完整引用表：[`docs/controls-mapping.md`](docs/controls-mapping.md) ## CI 两个 GitHub Actions 工作流会在每次涉及策略或 Terraform 的 push 或 PR 时触发：  | 工作流 | 检查内容 | 所需凭证 | |---|---|---| | `opa-tests.yml` | 所有 OPA 单元测试通过；执行 `opa check --strict` 语法验证 | 无 | | `terraform-policy-check.yml` | 不合规的夹具触发 ≥1 个违规；合规的夹具产生 0 个违规 | 无 | ## 该项目的局限性 这为你提供了部署期间强大的预防性合规能力，但它并不是万能的。它无法解决运行时的配置漂移、在控制台中进行的配置更改，也不能取代正规的 QSA/审计员签字。请参阅 [`docs/controls-mapping.md`](docs/controls-mapping.md)，以清晰了解哪些内容已被覆盖，以及哪些部分仍需人工审查。

标签：DevSecOps, ECS, OPA, Terraform, 上游代理, 云安全合规, 合规即代码, 应用安全, 开源框架, 持续集成, 策略即代码, 结构化提示词, 聊天机器人安全, 靶场