安全即代码如何编写策略

本文目录导读：

1. 核心原则
2. 编写策略的三大输出物
3. 编写策略的实战流程（5步法）
4. 高级编写技巧
5. 典型工具组合与落地场景
6. 避免的常见错误
7. 总结一句话

“安全即代码”的核心思想是将安全策略、合规规则和安全配置以代码的形式进行版本管理、自动化测试和持续部署，这不仅仅是写几行YAML，而是建立一套策略即代码的工程体系。

以下是编写“安全即代码”策略的系统性方法论和实操指南：

核心原则

1. 声明式而非命令式：告诉系统“需要什么状态”，而不是“怎么做”。“所有S3存储桶必须禁止公开读”。
2. 不可变与可审计：策略代码一旦合并，应触发自动化执行；所有变更都通过Git记录，可回溯。
3. 左移测试：在代码提交和CI/CD阶段即执行策略检查，而不是等到生产环境被攻破。
4. 最小权限与可分层：策略应粒度细，且能分层覆盖（从全局基线到具体项目例外）。

编写策略的三大输出物

一份完整的“安全即代码”策略应包含以下三个组成部分：

可执行的策略规则（Policy Code）

• 这是核心代码,用于检查资源是否合规。

• 主流工具与语言：

  • Open Policy Agent (OPA)：使用 Rego 语言（最通用，兼容K8s、Terraform、Envoy等）。
  • HashiCorp Sentinel：与Terraform、Vault深度集成。
  • AWS Config / Azure Policy / GCP Organization Policy：云原生策略引擎。
  • Checkov / tfsec / Terrascan：针对IaC文件的静态分析工具。

• 示例（OPA / Rego 语言）： 规则：禁止安全组（Security Group）开放0.0.0.0/0的SSH端口（22）。

  package terraform.aws.security_group
  # 定义一个违规行为
  deny[msg] {
      resource := input.resource.aws_security_group_rule[_]
      resource.type == "ingress"
      resource.from_port == 22
      resource.to_port == 22
      resource.cidr_blocks[_] == "0.0.0.0/0"
      msg := sprintf("禁止公开SSH访问: %v", [resource.name])
  }

策略元数据（Policy Metadata）

• 用于组织、分类和自动化处理。
• 字段建议：
  • id: 唯一标识符（如 CIS-AWS-1.2）。
  • severity: 严重级别（HIGH / MEDIUM / LOW）。
  • category: 分类（加密、网络、访问控制）。
  • framework: 合规框架（PCI-DSS / SOC2 / HIPAA）。
  • remediation: 修复步骤。
• YAML 示例：

  metadata:
    id: "SEC-STORAGE-001"
    severity: "CRITICAL"
    category: "数据保护"
    framework: ["SOC2-CC6.1"]
    remediation: "将Bucket的'Block Public Access'设置为'BlockAll'"

测试脚本（Policy Tests）

• 确保策略本身没有bug,且能正确识别合规/违规资源。

• OPA Rego 测试示例：

  package test.terraform.aws
  # 测试：当安全组允许SSH到0.0.0.0/0时，应该被拒绝
  test_denied_ssh_to_internet {
      deny with input.resource.aws_security_group_rule as [{
          "type": "ingress",
          "from_port": 22,
          "to_port": 22,
          "cidr_blocks": ["0.0.0.0/0"],
          "name": "bad_rule"
      }]
  }

编写策略的实战流程（5步法）

假设你要制定一条策略：“所有EC2实例必须使用加密的EBS卷”。

第1步：编写业务语言描述

• 描述：禁止所有未加密的Amazon EBS卷附加到EC2实例。

第2步：转化为技术检查条件

• 判断条件：aws_ebs_volume.encrypted 属性不等于 true 且被 aws_volume_attachment 关联。
• 资源类型：aws_ebs_volume, aws_instance。

第3步：编写Rego/OPA策略代码

package terraform.aws.ebs
deny[msg] {
    volume := input.resource.aws_ebs_volume[_]
    volume.encrypted != true
    msg := sprintf("卷 %v (ID: %v) 未启用加密", [volume.name, volume.id])
}

第4步：创建单元测试

test_pass_encrypted_volume {
    not deny with input.resource.aws_ebs_volume as [{
        "name": "safe_vol",
        "encrypted": true
    }]
}
test_fail_unencrypted_volume {
    deny with input.resource.aws_ebs_volume as [{
        "name": "risky_vol",
        "encrypted": false
    }]
}

第5步：集成到CI/CD流水线

• 在 .github/workflows/security.yml 中：

  - name: 执行基础设施合规检查
    run: |
      terraform plan -out=plan.tfplan
      terraform show -json plan.tfplan > plan.json
      opa eval --data policy/ --input plan.json "data.terraform.deny" -f values

高级编写技巧

1. 允许带有条件的例外（Exception Handling）：
   • 不要写死拒绝所有规则,应该允许标记了特定标签（Label: auto-compliance-override=true）的资源。
   • 代码示例：not volume.tags["team"] == "nucleus-team"（核心团队可能临时需要）。
2. 聚合多资源规则：
   • 检查“存在aws_s3_bucket_public_access_block资源”，并且该资源绑定了所有aws_s3_bucket。
3. 使用数据驱动策略：
   • 将IP白名单、端口列表等数据放在data.json或data.yaml中，策略只引用，不硬编码。
   • allowed_ports := data.allowed_ports。
4. 策略分层：
   • 层1（强制基线）：全公司必须遵守（如禁止公开RDP）。
   • 层2（项目自定义）：某个项目组允许额外开通某些内网端口。
   • 实现：在OPA中通过input.annotations或input.tags判断应该应用哪个层级的策略。

典型工具组合与落地场景

避免的常见错误

1. 错误：写死环境：
   • ❌ env == "prod"：在测试环境也应在CI中检查，只是阻断级别不同。
   • ✅ 使用参数 input.environment_allowlist。
2. 错误：策略过于宽松：
   • ❌ 只检查端口22，不检查3306或3389。
   • ✅ 检查所有“WAN” (0.0.0.0/0) 的高危端口列表。
3. 错误：缺乏测试：
   • 策略代码本身可能有bug,导致误报或漏报，必须写test_pass和test_fail。

总结一句话

安全即代码不是写几条静态规则，而是建立一套版本控制 + 自动化测试 + 不可变部署 + 持续合规的策略工程体系，用 Rego (OPA) 或 YAML (Kyverno/Checkov) 编写声明式策略，并在CI管道中作为“关卡”强制阻断非合规资源，是实现动态安全治理的最佳实践。