什么是策略即代码 (PaC)？

不再依赖人工检查合规性或记住安全规则，这些规则以可执行逻辑的形式存在，每次开发者或系统提出变更或请求时都会运行。如果有人提交变更，策略引擎会根据编码的规则自动评估该变更，并予以允许、拒绝或标记。

这一过程将策略管理实践从静态文档转向嵌入软件交付管道中的、持续执行的活动控制面。

基于代码的规则有助于确保相同的策略以可重复、可扩展的方式在所有地方应用。策略引擎可以在构建或部署期间于数秒内运行自动化检查，缩短反馈周期，帮助 DevOps 团队避免后期出现安全或合规意外。

PaC 使企业能够改善整体网络安全态势，并保持对行业和监管标准的合规性。此外，将策略当作代码来对待，与更广泛的“一切皆代码”转型相一致，该转型将基础设施请求等事物转变为可审查的代码文件，开发团队可以围绕这些文件开展协作。

在 DevOps 术语中，策略是关于 IT 基础设施和应用程序必须如何配置、访问或运行的清晰、可执行的规则。更准确地说，策略规定了哪些操作是允许的、必需的或被禁止的，以使系统保持在其理想状态运行。 

例如，“所有存储桶必须加密”或“任何公共服务都不能暴露 22 端口”都是策略，因为它们对系统行为规定了具体的约束。

借助 PaC，策略使用结构化编程语言编写，策略引擎和自动化工具就可以确定性地解析和评估它们。这样一来，策略就变成了系统和工程师必须满足的可执行护栏，而不是人们可能会有不同解读的指南。

策略即代码工具使开发者能够将可执行代码写入运行时环境和持续集成/持续交付 (CI/CD) 管道，因此每次变更都会自动接受合规性检查。

从技术上讲，大多数 PaC 设置都遵循相同的核心步骤：

• 开发者以代码文件的形式编写策略。他们可以使用一系列高级命令式和声明式语言，包括 Python、YAML、JavaScript 对象表示法 (JSON) 或 Rego（通常与开源策略引擎 Open Policy Agent，即 OPA 一起使用）。每个策略文件声明其所关心的输入（例如“resource.kind”、“metadata.labels”），并对条件（也称为“谓词”）和结果（允许/拒绝、严重性、消息）进行编码。

• 代码被提交到版本控制系统（如 Git 或 GitHub），并经过与应用程序代码相同的 工作流，包括拉取请求、代码审查和严格的语法测试。

• 策略引擎读取代码文件，进行解析，并将其转换为内部可理解的数据结构和指令。然后这些结构和指令被转换成紧凑的低级指令格式（字节码），以便快速评估。

• 调用方（向策略引擎请求决策的那段代码）对数据输入进行规范化。调用方处理不同的输入格式，包括来自 IaC 工具的 HashiCorp 配置语言 (HCL) 文件和 JSON 模板、来自 Kubernetes 和云平台的 YAML 清单、来自 API 调用的 HTTP 请求，以及来自运行时和生产环境的应用数据和遥测数据。它清理原始输入并将其重塑为一种标准结构，以便策略能以一致的方式读取输入。

• 调用方将规范化后的数据交还给策略引擎，策略引擎开始根据这些数据输入运行策略代码。  

• 策略引擎遍历规则，根据输入检查每条规则的谓词，以确定哪些谓词适用。可以这样理解：策略引擎在问，“对于这个输入，这条规则是怎么规定的？”

• 策略引擎从所有规则中获取结果，将其合并为单一的策略决策（这一过程称为决策聚合），并生成一个消息列表。消息提供关于失败代码的更多细节（违反了哪条规则、哪个对象违规），有时还会给出如何修复的建议。

• 策略引擎返回决策，包括相关消息、标签和严重性信息。如果决策是“拒绝”，策略引擎会阻止所有拉取请求和代码合并，并停止部署，直到开发者修复该策略违规。如果决策是“允许”，引擎会创建构建产物（一个编译、打包并测试过的代码文件）并部署代码。如果存在警告，代码会被放行，但引擎会将警告写入日志文件或评论中。 

策略检查可以发生在软件开发生命周期 (SDLC) 的任何节点，从代码集成到线上生产环境与监控。

因为策略是代码，它们也可以像任何其他软件制品一样对待。

开发团队可以编写自动化测试，将样本输入送入策略并验证其返回的决策，从而在策略变更时加快反馈循环。

当策略被编码后，开发人员可以将公共逻辑提取为可复用的模块或函数。多个高层级策略就可以调用共享的策略，而不必在各处重复条件。

开发人员还可以重命名、重构或将大型策略拆分成更小的策略，而不改变其行为，就像将一个大型应用函数重构为多个小函数一样。

这些能力使团队能够将现有的软件工程实践应用于治理逻辑，从而帮助他们在 IT 架构扩展和演进的过程中保持安全与合规要求。

假设某公司 X 想实施一项“仅 HTTPS”策略，要求所有 Web 服务都必须使用 HTTPS，而不是普通的 HTTP。 为了将该策略代码化，一位平台工程师编写了一条简单的规则，内容如下：

• 如果服务的协议是 HTTP，则该变更应被拒绝。
• 如果服务的协议是 HTTPS，则该变更被允许。

工程师将此策略文件放在与应用程序相同的代码仓库中的“policies”文件夹内，并开启一个拉取请求来添加该策略。该拉取请求会触发对策略文件的自动语法检查，并由另一位工程师进行代码审查。只有策略通过了必要的测试，它才会被合并到主分支。

在持续集成 (CI) 管道中，所有策略文件都会从“policies”文件夹加载到策略引擎。策略引擎读取该策略，将其转换为内部表示形式，并编译成紧凑的低级形式。这种紧凑形式使引擎能够针对管道检查的每个服务快速回答“允许还是拒绝？”

无论文件格式如何，CI 作业会获取现有配置文件，提取重要字段（名称、协议、端口），并为每个服务构建一个简单的 JSON 描述。

调用方通过发送标准化服务描述作为输入，并指明应应用“仅 HTTPS”策略包，向策略引擎请求决策。

策略引擎随后根据规则评估输入。它检查服务的协议字段。如果协议是 HTTP，就意味着输入匹配策略中的“拒绝”条件。引擎会指示该变更应被拒绝，并生成一条消息，告知开发者该服务必须使用 HTTPS 而不是 HTTP。如果服务使用 HTTPS，则不满足任何拒绝条件，引擎会指示该变更被允许。

然后，策略引擎将规则评估结果汇总为该服务的单一决策对象。决策对象通常会指明总体决策是“允许”还是“拒绝”，以及问题的严重程度（高、中、低）。它们还包含一个消息列表，解释输入被拒绝的原因以及引擎在评估过程中发现的所有警告。如果一切合规，决策对象会指示该变更被允许，并仅附带信息性说明（或完全不包含任何消息）。

最后，CI 工具执行该决策。如果决策是“拒绝”，该变更将无法合并到主代码分支。工程师会看到一条错误消息，指出该服务必须使用 HTTPS 并进行特定的修改。如果决策是“允许”，制品将被打包并部署，CI 管道照常继续。

策略即代码源于现代 DevOps 和云工程中更广泛的“一切皆代码”运动。

最初，基础设施即代码 (IaC) 是那次重大转变。团队不再让系统管理员通过用户界面点击操作或遵循运行手册，而是用声明式代码文件来描述服务器、网络和其他资源。这些文件存储在版本控制系统中，并通过自动化管道进行应用。

随着企业看到其好处，这种方法扩展到了 IT 架构的其他组件。应用程序配置转向了基于代码的方法。CI/CD 管道变成了存放在代码仓库中的脚本。监控和告警规则也开始以代码形式存在。这些实践合在一起被称为“一切皆代码”。

“一切皆代码”的核心理念是，如果系统的某个部分可以被描述，就应该被描述为代码，并像管理软件应用一样进行管理。

PaC 本质上是将该理念应用于规则、治理和合规领域。传统上，策略存在于 PDF 和 wiki 中，或由委员会决定，并由人工执行。在发布周期缓慢且基础设施相对静态的情况下，这种流程是可行的。

随着云原生和微服务架构成为主流，团队开始每天多次部署代码，人工流程无法跟上。PaC 通过以机器可读的格式表达策略来应对这一挑战，因此它们可以在 Git 中进行版本控制、像代码文件一样接受审查、在 CI 中进行测试，并在管道或运行时自动执行。

策略即代码是一种像管理软件代码一样管理 IT 策略的实践。基础设施即代码 (IaC) 与此类似，但侧重点不同。它使工程团队能够使用应用程序代码来定义和管理 IT 基础设施 。

IaC 让开发者能够通过编写代码来描述虚拟机 (VM) 和负载均衡器等网络资产的期望状态，而不是手动创建和配置这些资产。然后，IaC 工具会获取这些代码，并创建或修改指定的资源。

IaC 使基础设施的扩展和自动化变得容易得多。如果团队需要更多服务器，他们只需更改代码中的一个数字（例如，将实例数从六个改为九个）。自动化工具会处理供应这些额外资源的细节。

从高层次来看，IaC 规定应存在哪些基础设施以及应如何配置，而 PaC 则侧重于基础设施必须遵守的规则和约束。IaC 代码创建并配置资源，而 PaC 代码有助于确保这些资源（及其使用方式）遵循既定的安全要求、合规标准和运维护栏。

在许多现代 IT 架构和 CI/CD 设置中，IaC 与 PaC 提供了互补的益处。IaC 自动执行资源供应，而 PaC 在此基础上添加自动化治理。

当开发者更改 IaC 文件时，PaC 引擎可以检查新的计划或配置。如果一切符合既定策略，变更会被放行并继续，基础设施得以更新。如果有内容违反了规则，管道就会失败，在问题修复之前不会部署任何内容。

DevSecOps 旨在将安全与合规嵌入到 DevOps 生命周期中，而不是在最后才附加进去。这是一种在软件开发生命周期的每个阶段都优先考虑并执行安全流程的开发方法。

PaC 通过以下方式支持 DevSecOps 实践：

PaC 通过将安全检查移到开发流程的最早阶段，帮助团队实现安全左移，而不是等到部署后再运行检查——那时问题可能已经影响到用户。如果开发者引入了有风险的配置或不安全的模式，自动化策略可以帮助检测问题并使构建失败。

PaC 工具通过将安全规则直接嵌入 CI/CD 管道和运行时系统来自动执行策略，因此每次代码或基础设施变更时都会自动进行检查。不再依赖人工记住每一条安全标准并手动审查每一次变更，系统会一致地评估变更，确保不会意外跳过任何步骤。

PaC 帮助开发者在保持部署速度的同时，不牺牲一致性和安全性。它在每个环境、每个阶段（开发、测试、预发布和生产）都运行相同的策略定义。此功能使团队能够频繁发布，因为他们可以相信同一套规则在所有地方都得到应用。这也有助于他们避免不同环境之间出现配置漂移或对规则有稍许不同解读的情况。

PaC 将应用程序安全策略视为存储在版本控制系统中的任何其他代码制品。开发、运维和安全团队都可以通过熟悉的工作流（代码审查、分支策略）来审查、讨论和更新策略，这使得策略讨论更透明，也更融入日常开发工作。

策略即代码在企业 IT 架构中有广泛的应用。

开发人员和安全专业人员正在探索策略即代码，将其作为一种创建分层护栏模型的方法，该模型涵盖 AI 或智能体工作流的整个生命周期。尽管该实践仍处于新兴阶段，但初步研究已经揭示了 PaC 在 AI 工作流中的许多可能应用。

PaC 有助于在 AI 的推理与决定其实际允许执行哪些操作的系统之间建立清晰的分离。AI 工具可以提出操作或计划，但策略引擎会在触及任何底层系统之前，根据编码规则评估这些提议。

在输入阶段，PaC 可以帮助过滤或转换用户提示、编辑敏感数据、执行租户隔离并阻止已知的攻击模式。在规划期间，PaC 可以要求 AI 智能体生成结构化的计划，并在允许执行之前，根据允许的工具、操作和风险条件验证每一步。

在执行时，每次工具调用或 API 调用都可以由策略执行层进行检查。该层决定是允许、拒绝还是修改某个操作，或者将其升级给人类。执行之后，策略可以驱动日志记录、审计跟踪、保留规则以及对模型输出的后过滤，以帮助确保响应符合必要的要求。

• 一致性。使用 PaC，策略在所有环境中以相同的方式应用，因为相同的代码在所有地方运行。这种一致性减少了偶发的、“雪花”式配置，并使团队无需记住每个环境稍有不同的手动流程。

• 效率。当策略被代码化后，它们可以在 CI/CD 管道或部署时自动执行，从而消除了手动检查和审批的需要。

• 自动化。PaC 支持自动验证和策略测试，这有助于团队最大限度地减少人为错误的影响，在错误配置进入生产环境之前捕获它们，并解决安全漏洞。

• 可见性。 通过以代码编写并集中存储策略，利益相关者可以准确了解有哪些规则，而无需依赖分散的文档和人们的记忆。

• 可扩展性。策略评估是自动化的，因此组织可以在许多服务、集群或账户中大 规模执行策略，而无需成比例地增加人力。

• 协作。PaC 简化了围绕策略代码的协作。这些共享工作流打破了孤岛，使安全与治理同 DevOps 实践保持一致，并让策略讨论更加具体、可测试。