每个安全平台最终都会面临同样的基本问题：
如何组织安全规则？
乍听之下，这只是一个简单的数据建模选择。实际上，它决定了安全运营的日常现实：事件调试的速度有多快，政策演变的安全性有多高，新办事处或用户社区的加入有多容易，以及增长是否会带来清晰或混乱。
在过去十年中，SASE 和 SSE 平台已趋同于一小套架构模式。这些模式通常融合在现实世界的产品中，但每种模式都代表了一种独特的设计理念，有自己的优势和失效模式。
了解这些模式–以及它们的不同之处–就能解释为什么现代平台正在摒弃以引擎为中心的思维，转而采用结构更合理、可扩展的方法。
维度 1：规则如何分组
(政策设计的主轴）
1.每个安全引擎的规则库
(支离破碎的模式）
这是最早的方法，目前仍在广泛使用。
每种安全功能都拥有自己独立的规则库 ：
- 防火墙
- IDS / IPS
- DLP
- 恶意软件扫描
- URL 和类别过滤
- SaaS 控制
- 多个 GenAI / LLM 防护栏
在现代环境中，这不再只是少数几个引擎。仅 “GenAI 安全 “就扩展为多个专业子引擎，例如：
- 及时注入检测、
- 工具输入/输出验证
- 代码检测
- 内容安全
- 内容分类和过滤
- 嵌入式 URL 安全
- 语义 DLP
每个引擎都有自己的匹配逻辑、操作、生命周期和运行所有者。
优势
- 深度专业化控制
- 由领域专家明确主导
- 安全引擎的独立发展
结构限制
- 分散的流量可见性
- 发动机之间的决策冲突
- 运营管理费用高
- 发动机数量增加，可扩展性差
这种模式与各自为政的安全团队如出一辙，在协调性和可操作性方面也面临同样的挑战。
2.单一统一规则库
(综合模式）
随着平台的统一，许多平台走向了另一个极端：将所有决策都放在一个全局规则表中。
每条规则定义
- 匹配条件（用户、应用程序、目的地、上下文）
- 参考 DLP、恶意软件、GenAI 和其他引擎的检查配置文件
优势
- 一条规则解释一个决定
- 更易于审计和故障排除
- 与零信任思维（”一个意图 = 一条规则”）完美契合
结构限制
- 在复杂环境中，规则表会变得非常庞大
- 轮廓变化可产生较大的爆炸半径
- 专家失去自主权
- 治理成为瓶颈
这种模式优化了可视性和简便性，但往往难以在大型或快速变化的组织中安全扩展。
3.每个目的地类型的规则库
(目的地优先模式）
最近的演变是围绕流量的去向而不是哪个引擎来检查流量来组织规则。
典型的目的地类别包括
- 互联网
- SaaS 应用程序
- 私人应用程序
每种目标类型都有自己的访问控制规则库，反映了不同的信任模型、风险和语义。规则仍会评估丰富的匹配条件，并生成会话级别的允许或拒绝决定，但分组自然地与流量意图保持一致。
优势
- 明确区分访问意图
- 为管理员提供更直观的心智模式
- 可预测的性能特点
- 减少无关政策逻辑的混合
结构限制
- 本身并不能解决政策无序扩张的问题
- 需要额外的结构，以便在大型组织中干净利落地进行扩展
基于目的地的组织结构提高了清晰度，但还需要另一个维度来管理范围和重复使用。
维度 2：如何界定政策范围和重复使用政策
(与规则分组正交）
以下模型回答了一个不同的问题：
如何在不同地点、用户或环境中打包、重复使用和应用策略？
它们可以与上述任何一种规则分组方法相结合。
4.配置文件
(政策作为一级对象）
配置预案引入了一个包含策略的更高层次的抽象概念，而不是策略本身。
配置文件通常包括
-
- 一个或多个访问控制规则库
- 检查配置文件（”允许但扫描 “逻辑）
特定于引擎的安全对象（DLP 对象、GenAI 控制、IDS 签名等）
该配置文件成为一种可移植的安全态势，可应用于各种情况：
- 实体办公室
- 地区
- 逻辑站点
- 用户社区
与在每条规则中嵌入范围逻辑（如站点或区域）不同，策略是通过应用适当的配置文件来确定范围的。
为什么这很重要
- 减少规则爆炸
- 提高可读性和可维护性
- 实现更清晰的 RBAC 边界
- 使政策变更更安全、更可预测
这种方法在现代 SASE 和 SSE 平台中越来越常见，即使没有明确标明。
5.政策继承
(分层控制模型）
另一个普遍存在但往往是隐含的模式是继承 。
政策的结构按等级划分：
- 全球基线
- 区域或功能重叠
- 针对特定站点或组群的覆盖
继承允许组织共享默认设置，同时允许受控的专业化。
权衡利弊
- 功能强大但复杂
- 调试需要了解解析顺序
- 设计不当的继承会掩盖有效的政策
继承通常与配置文件相结合，以便在重复使用和清晰度之间取得平衡。
将各个层面结合起来
现代安全平台很少依赖单一模式。
相反，它们结合在一起：
- 基于目的地的规则组织（意图明确）
- 配置文件（策略范围界定和重复使用）
- 继承（受控专业化）
- 基于轮廓的检查（发动机模块化）
这种分层方法反映了一个核心认识：
安全的复杂性无法消除，只有结构化。
人工智能>安全的适用范围
人工智能>Secure fromAryaka在这两个维度上都做出了明确的建筑选择：
- 维度 1–规则组织：基于目的地的规则模型，围绕互联网、SaaS 和专用应用程序组织访问控制。
- 维度 2–策略范围界定和重复使用：基于配置文件的方法，将访问规则库、检查配置文件和特定引擎的安全对象捆绑成可重复使用的策略单元，并应用于逻辑站点。
在这个结构中
- 每条规则都会评估丰富的匹配条件（网络属性、URL 和应用程序上下文、用户身份、信誉信号）。
- 首先做出会话级别的允许或拒绝决定。
- 只有在允许会话的情况下，才会执行数据级检测，从而确保可预测的执行和深度检测引擎的高效使用。
- 通过附在规则上的检查配置文件，检查意图是明确的，而不是通过隐藏的规则链隐含的。
通过将目的地优先的规则组织与基于配置文件的范围界定相结合，AI>Secure 可以避免这两种极端情况：
引擎特定规则库的碎片化
单一全球规则表的蔓延和爆炸半径
为什么这种建筑现在很重要
SaaS、私人应用程序和 GenAI 驱动的工作流程的兴起从根本上改变了安全要求：
- 决策取决于更丰富的背景
- 检查费用高昂，必须有意为之
- 许多安全引擎
- 政策必须跨地点、跨用户和跨工作负载扩展
规则架构也必须随之演变。
安全策略设计的未来不在于更多的规则或更智能的引擎。未来的安全策略 设计不在于 更多的规则或更 智能的引擎，而 在于明确的分工、清晰的意图以及可扩展而不会因自身复杂性而崩溃的架构。
这是行业发展的方向，也是人工智能>Secure 的架构基础。