28、基于Petri网和代理的分布式网络安全建模探索

基于Petri网和代理的分布式网络安全建模探索

在当今数字化时代，计算机网络已经无处不在，分布式系统的需求也日益增长。然而，分布式网络的安全问题成为了一个重要的挑战。本文将介绍一种基于Petri网和代理的分布式网络安全建模方法，探讨其概念、技术背景、实现方式以及与相关工作的区别。

1. 背景与动机

计算机网络在近年来变得越来越普遍，分布式系统的需求也随之增加。分布式系统利用不同网络节点的特性，提供了在传统集中式系统中难以实现的功能。而代理导向的范式特别适合设计分布式系统，因为代理可以使用异步消息进行通信，并能在一定程度上智能适应不可预见的情况。

但分布式功能在开放网络上的部署也带来了安全风险。传统的网络安全防护采用边界模型，即网络安全组件（NSCs）保护网络的虚拟边界。然而，一旦边界被突破，攻击者几乎可以不受阻碍地访问整个网络。为了解决这个问题，Herold研究项目提出了一种新的方法，将网络划分为多个子网（称为单元），每个单元由自己的NSC保护，NSCs通过合作执行网络范围的安全策略。

2. 相关工作对比

Herold项目位于多代理系统、基于策略的管理和网络安全的交叉点。与以往的工作相比，Herold具有独特的特点：
- 与基于代理的网络管理方法对比 ：虽然Herold与一些基于代理的网络管理方法有密切关系，但它专注于网络安全，并仅依赖固定代理。此外，Herold是基于策略的，解决了策略的本地化问题，并将策略转换为NSC特定的配置。
- 与KAoS方法对比 ：Uszok等人提出的KAoS方法用于代理框架的策略表示、冲突解决和执行。与KAoS不同，Herold使用不同的策略语言，专注于网络安全，具有不同的架构，并且可以被视为KAoS方法的泛化，因为KAoS方法没有解决策略的细化问题。
- 与Ponder2对比 ：Ponder2是一个支持策略细化的基于策略的管理系统。与Herold不同，它依赖于对等架构，而不是基于代理的架构。并且，Ponder2细化策略的概念与Herold的策略转换有很大不同，Ponder2通过向层次“域”添加额外对象或向下移动策略来细化策略，而Herold通过将策略映射到用不同语言定义的NSC特定配置来细化策略。

3. 技术背景

• Mulan架构 ：我们的代理遵循Mulan架构，它代表多代理网。Mulan中的代理各个方面都使用参考网进行建模，参考网是一种高级Petri网形式。参考网的令牌可以再次是参考网，允许网络的层次嵌套，从而可以建模完整的多代理系统。最低层是代理行为，通过协议网建模，协议网是代理层的令牌，代理网位于平台网中，平台网又位于系统网中。
• Capa架构 ：Capa是Mulan的扩展，专注于互操作性和通信。它提供了与智能物理代理基金会（FIPA）标准的完全合规性，通过为Mulan代理提供标准化消息格式，并替换Mulan参考架构的上层Petri网层。
• Renew工具 ：Petri网编辑器和模拟器Renew作为使用Mulan和Capa的系统的构建和运行时环境。
• Paose方法 ：Paose（基于Petri网和代理导向的软件工程）软件开发方法特别适合Mulan和Capa架构。它具有快速原型的特点，结合了UML、模型驱动方法和敏捷软件开发的概念。最初使用UML子集定义粗略设计，直接转换为Petri网模型，这些模型只需稍作修改即可提供所需功能，并且可以在后续迭代中循环使用。

4. 概念视图

4.1 Herold项目愿景

Herold项目旨在提供一种新颖的基于代理的方法来管理和控制NSCs，包括主动（如防火墙）和被动（如入侵检测系统）的NSCs。安全属性和规则在覆盖整个网络的抽象全局策略中定义，该策略由Herold系统控制下的NSCs本地和协作执行。全局策略由不同的网络管理员合作创建和维护，并自动转换为NSCs的技术配置。

4.2 概念模型的三个方面

• 网络模型 ：假设网络拓扑是连通的，每个节点有唯一地址。Herold用户提供NSCs的描述，包括网络接口、关联地址、路由表和配置信息。这些信息用于为每个NSC本地化全局策略。由于该模型没有明确描述网络拓扑，某些类型的NSCs可能不被覆盖，这将在更复杂的模型中解决。此外，网络描述还包括用于组织网络组件的组以及组件到组的分配。
• 策略模型 ：Herold系统的用户共享一个始终活动的全局策略。策略以5元组定义，包含源和目标地址、端口以及动作。语义上，策略为每个可能的5元组包含一个允许或拒绝动作的规则。组的使用允许更简洁地描述策略。Herold系统为每个管理的NSC本地化全局策略，并将本地化策略转换为NSC特定的配置格式，然后部署到相应的NSC。
• 用例 ：模型包括编辑全局策略和网络描述、策略转换和配置部署的用例。多个用户可以同时编辑策略和网络描述，需要明确的设计决策来处理并发编辑带来的问题。具体用例如下表所示：
  |用例类型|具体用例|
  | ---- | ---- |
  |全局策略相关用例|查看当前规则列表和系统状态；添加/删除/修改/移动规则|
  |网络描述相关用例|查看当前NSCs集合；添加/删除/修改NSC；查看当前组集合；添加/删除/重命名组；在组中添加/删除网络组件|

NSCs作为外部系统，仅参与部署NSC特定配置的用例。

这个概念模型虽然只是实现Herold整体愿景的一步，但已经包含了Herold的关键方面：全局策略的协作创建、全局策略的本地化以及自动转换为NSC配置。Paose方法在Herold系统的开发中发挥了重要作用，它允许快速迭代的过程，自然支持分布式系统的开发。

5. 模型零的实现

为了展示Paose方法的效果，我们实现了一个名为模型零的原型，它包含了Herold应用的关键功能。
- 网络子模型 ：模型零的网络子模型假设存在一个具有完美路由子网的唯一地址空间，但没有进一步的网络拓扑和明确的网络描述。它没有网络位置或NSCs的概念，也不支持组件分组。
- 策略子模型 ：策略子模型假设存在一个始终活动的全局策略，该策略描述了由协议、源和目标地址以及源和目标端口表征的通信关系。每个策略被认为是完整的，即对于每个可能的通信关系，它暗示了允许或拒绝的判断。由于不可能指定所有单个规则，策略可以写成有序的规则列表，每个规则写成一个可以匹配许多可能通信关系的模式，列表按“先匹配者获胜”的语义进行评估。为了使策略完整，有一个隐式的最后规则，它匹配所有内容并为该策略指定默认决策。由于网络模型是非本地的，因此没有策略的本地化，策略可以看作是一个单一的全能NSC的配置。

模型零包含六个用例，涉及三个参与者：
- Admin Proxy ：代表系统管理员，对全局策略具有管理控制权，可以发起不同的用例。
- Policy Manager ：负责管理中央规则列表。
- NSC Proxy ：代表NSC，仅参与部署规则用例，因为其他操作仅处理由策略管理器管理的全局策略。

以下是模型零的用例流程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([开始]):::startend --> B(Admin Proxy发起用例):::process
    B --> C{用例类型}:::process
    C -->|add rule| D(Policy Manager添加规则):::process
    C -->|delete rule| E(Policy Manager删除规则):::process
    C -->|modify rule| F(Policy Manager修改规则):::process
    C -->|move rule| G(Policy Manager移动规则):::process
    C -->|view rules| H(Policy Manager返回规则):::process
    C -->|deploy policy| I(Policy Manager部署策略到NSC Proxy):::process
    D --> I
    E --> I
    F --> I
    G --> I
    H --> B
    I --> J([结束]):::startend

以添加规则用例为例，其交互过程如下：
1. AdminProxy DC ui（代表管理员的用户界面）启动交互。
2. AdminProxy addrule协议首先从知识库中查找并找到策略管理器的地址。
3. 发送包含添加规则请求和新规则信息的消息给策略管理器。
4. 消息传递到策略管理器代理的决策组件进行处理。

通过模型零的实现，我们展示了Paose方法在分布式网络安全建模中的有效性和灵活性。它不仅提供了一个可行的解决方案，还为进一步的扩展和优化奠定了基础。在后续的工作中，我们可以根据实际需求对模型进行改进，例如完善网络模型以覆盖更多类型的NSCs，优化策略转换算法以提高效率等。同时，我们也可以探索如何将该模型应用于更复杂的实际场景，为分布式网络安全提供更强大的保障。

基于Petri网和代理的分布式网络安全建模探索

6. 模型零用例分析

模型零中的各个用例在分布式网络安全管理中都有着独特的作用，下面对这些用例进行详细分析：
|用例名称|作用|操作步骤|
| ---- | ---- | ---- |
|deploy policy|将当前全局策略配置并部署到NSC。该用例虽不是由参与者直接调用，但包含在所有会改变全局策略的用例中，在全局策略成功更改且释放全局策略锁之前被调用。|1. 确认全局策略已成功更改；2. 在释放全局策略锁之前，将策略配置并部署到NSC。|
|add rule|在给定的评估顺序位置向策略中添加新规则。|1. Admin Proxy发起添加规则请求；2. 从知识库中查找策略管理器地址；3. 发送包含新规则信息的请求给策略管理器；4. 策略管理器处理请求并添加规则。|
|delete rule|从全局策略中移除规则。|1. Admin Proxy发起删除规则请求；2. 策略管理器接收请求并移除相应规则。|
|modify rule|修改全局策略中的一条规则，交互参数包括旧规则和新规则。|1. Admin Proxy发起修改规则请求，提供旧规则和新规则信息；2. 策略管理器接收请求并进行规则修改。|
|move rule|可看作modify rule用例的特殊情况，仅修改规则在全局策略中的位置，规则本身不变。|1. Admin Proxy发起移动规则请求；2. 策略管理器接收请求并调整规则位置。|
|view rules|返回当前全局策略的所有规则。|1. Admin Proxy发起查看规则请求；2. 策略管理器返回所有规则。|

7. 基于用例生成后续建模工件

利用Renew工具集，可以根据模型零的用例自动生成后续建模所需的工件。在Mulan和Capa架构中，用例通过代理之间的交互来实现，这些交互由代理交互协议定义，进而可以生成实际的代理行为协议。代理的非交互行为（如内部决策）通过决策组件建模，代理的知识在知识库中定义，知识库在建模时确定，但在执行过程中可以改变。

以add rule用例为例，其交互过程的详细分析有助于理解整个系统的运行机制。该用例的代理交互协议如图所示（前文已给出图2），它与其他用例有相似的结构。其交互流程如下：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([开始]):::startend --> B(AdminProxy DC ui启动交互):::process
    B --> C(AdminProxy addrule协议查找策略管理器地址):::process
    C --> D(发送添加规则请求及新规则信息给策略管理器):::process
    D --> E(消息传递到策略管理器决策组件):::process
    E --> F(策略管理器处理请求并添加规则):::process
    F --> G([结束]):::startend

8. 总结与展望

通过对基于Petri网和代理的分布式网络安全建模方法的研究，我们可以看到这种方法在解决分布式网络安全问题上具有显著的优势。
- 优势总结
- 灵活性 ：Mulan和Capa架构的使用，以及Paose方法的支持，使得系统具有很高的灵活性，可以根据不同的需求进行定制和扩展。
- 安全性 ：采用单元化的网络划分和协作式的安全策略执行方式，提高了网络的安全性，减少了单点故障带来的风险。
- 可维护性 ：通过策略的本地化和自动转换，降低了策略管理的复杂性，提高了系统的可维护性。
- 未来展望
- 模型完善 ：进一步完善网络模型，使其能够覆盖更多类型的NSCs，考虑更复杂的网络拓扑结构。
- 算法优化 ：优化策略转换算法，提高策略转换的效率和准确性，减少系统的响应时间。
- 实际应用 ：将该模型应用于更复杂的实际场景，如大型企业网络、云计算环境等，为分布式网络安全提供更强大的保障。
- 技术融合 ：探索与其他安全技术的融合，如人工智能、区块链等，进一步提升网络安全的防护能力。

总之，基于Petri网和代理的分布式网络安全建模方法为解决分布式网络安全问题提供了一种新的思路和方法。随着技术的不断发展和完善，相信这种方法将在未来的网络安全领域发挥重要的作用。