规则策略

什么是规则策略 (Policy Rule)

规则策略（PolicyRule）是配置审计规则模版的核心组成部分。它通过声明式的语言，精确地定义了资源的合规检查逻辑（If 条件）以及当条件满足或不满足时应触发的违规效果（Effect）。

借鉴业界标准策略引擎的设计理念，本系统中的规则策略统一使用 OPA (Open Policy Agent) Rego 语法编写。它通过评估目标资源的属性（如类型、标签、配置参数）与期望状态（如安全基线、合规要求）之间的关系，来决定该资源是否符合企业治理要求。

有关OPA的详细介绍和常见语法函数详见 OPA官方文档。

核心评估逻辑

规则策略的评估是一个布尔计算的过程。系统会将云资源的当前状态（资源配置项 ConfigurationItem）作为输入（Input），结合用户配置的规则参数值（Args），通过 OPA 引擎进行逻辑运算，最终输出 compliant (合规) 或相应的 modify (修复) 动作。

编写规范

在 Config 规则模板中，策略代码（PolicyRule）统一使用 OPA Rego 语言编写。根据配置的 AllowedEffects 和具体业务场景，Policy 主要涵盖三种形态：审计策略 (Audit)、修复策略 (Modify) 以及关联资源过滤规则。

审计策略 (Audit Policy)

这是最基础的策略形态，主要用于“只读”评估，判定当前输入资源（ input.ConfigurationItem ）是否符合预期配置。它的作用是发现问题并记录，但不主动改变资源状态。

编写规范要求

命名空间：必须使用 package rules 作为文件的起始声明。

默认回退状态：必须显式声明默认状态为不合规，即 default compliant = false 。这符合安全领域的“默认拒绝”原则。

合规条件定义：通过编写compliant if { ... } 代码块定义合规条件。在大括号 {} 内部的多个表达式之间是隐式的逻辑与（AND）关系，所有条件都必须为真（True），策略才判定为合规。

参数化引用：策略支持使用外部传入的模板参数，通过 input.Args.<Key> 访问。这允许同一个策略模板通过不同的参数赋值，应用于不同的合规标准。

代码示例

修复策略 (Modify Policy)

当规则模板允许 Modify 行为时（例如：自动修复合规漏洞或提供手动一键修复能力），策略不仅要判断是否合规，还要在不合规的情况下，指导系统“如何去修复”。策略需要返回一个标准的 JSON Patch 操作片段，系统会根据该返回值调用上游资源管理层（如 CloudControl）去修改资源状态。

编写规范要求

声明修复规则：必须声明 modify 规则，并返回一个符合 RFC 6902 标准的 JSON Patch 数组。

操作符限制 (op) ：仅支持安全且明确的操作： add （添加）、 remove （移除）、 replace （替换）、 test （测试）。

修改路径限制 (path) ：

必须以 / 开头，且不允许出现空段（例如 /Configuration/Foo//Bar 是非法的，防止路径解析歧义）。

为了保障系统稳定性，只允许对以下两个特定命名空间进行变更产出：

/Tags ：用于修改资源的标签信息（如添加 /Tags/owner ，用于成本分摊或责任人追踪）。

/Configuration/<Property> ：用于修改资源常规配置属性（如降级实例规格 /Configuration/InstanceType ）。

条件触发： modify 动作通常应配合 if { not compliant } 使用，确保仅在资源不合规时才生成修复建议。

代码示例

关联资源过滤规则 (Related Resource Filter)

在复杂的云原生架构中，资源的合规性往往不只取决于其自身，还取决于它所关联的其他资源（例如：ECS 实例是否绑定了特定的安全组，或者子网是否关联了 NAT 网关）。此时，可通过内置函数 config.check_related_resources(rule_name) 评估“当前资源是否存在特定的关联资源”。

编写规范要求

规则签名：被调用的过滤规则必须是单参数函数，并包含形如 some item in items 的迭代生成器，用于遍历关联资源集合。

条件约束（出于性能与评估效率的考量）：

操作符限制：仅支持双元比较符： == 、 != 、 > 、 < 、 >= 、 <= 。不支持 contains 等复杂的内置函数调用。

左操作数：必须是关联资源的内置字段引用（例如 item.ResourceType 、 item.Configuration["..."] 、 item.Tags["..."] ）。

右操作数：只能是静态的字面量（Literal）或外部传入的参数 input.Args.<Key> 。不支持动态索引计算或复杂的数组类型对比。

代码示例

最佳实践建议

保持策略单一性：一个规则模板的 PolicyRule 最好只关注一个特定的合规维度（如：只查标签，或只查网络配置）。避免将复杂的、不相关的逻辑揉合在一个文件中，以提升模板的复用性。

充分利用参数化：对于阈值、特定的标签名、规格列表等经常变动的值，强烈建议提取为 input.Args ，避免在 Rego 代码中硬编码（Hardcode（Hardcode）。

安全测试 Modify 操作：在编写 Modify 策略时，务必先在测试环境或使用 Audit 效果进行模拟运行，确保 JSON Patch 的 path 和 value 不会引发预期之外的资源中断。