安全即代码如何编写策略

wen 网络安全 2026-07-17 1

本文目录导读：

安全即代码如何编写策略

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

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

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

核心原则

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

编写策略的三大输出物

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

可执行的策略规则（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

高级编写技巧

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

典型工具组合与落地场景

场景	工具链	代码形式
IaC扫描 (Terraform/CloudFormation)	Checkov / tfsec / KICS	YAML + Python (Checkov) 或 Rego
K8s Admission Control	OPA Gatekeeper / Kyverno	Rego (OPA) 或 Yaml (Kyverno)
云原生策略 (AWS/Azure)	AWS Config Rules (Lambda)	Python / JavaScript
API/微服务授权	OPA / OAuth2 + Casbin	Rego / ACL文件
CI/CD 安全	Sentry / CodeQL + 策略引擎	YAML + Rego

避免的常见错误

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

总结一句话

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