Swarm中分布式ABAC系统

Swarm的基于属性的访问控制与分布式策略管理

摘要

物联网通过为日常生活物品赋予处理和通信能力，正在彻底改变社会。Swarm 是一种以边缘为中心的物联网方法，其中独立、跨领域和异构设备能够协同合作执行任务。访问控制对于 Swarm 至关重要，因为它可确保机密性和所有权，并防止网络攻击，仅允许授权服务进行通信。尽管已存在多种访问控制模型，但在消费电子领域仍缺乏基于边缘且易于使用的访问控制系统。本文提出了一种面向 Swarm 的分布式基于属性的访问控制系统（ABAC）。该系统具备分布式策略管理图形用户界面（GUI），使用户能够以去中心化方式为物联网设备设置策略。所提出的系统依据一组 NIST 质量指标进行了评估，同时也进行了性能评估。结果表明，该系统具有良好的可用性因素，在分别考虑 20% 的任意图密度和 0.000034% 的基于社交的图密度时，可支持从 10,000 到 60亿项服务的处理。

索引术语

物联网，访问控制，物联网 Swarm，边缘计算，可用安全性。

I. 引言

THE 物联网（IoT）将联网计算实体集成到日常生活的对象中。随着物联网逐渐进入终端用户，设备开始收集个人信息，并与其环境及其他设备进行交互，这引发了关于安全和隐私的诸多担忧 [1]。

为了保护消费电子产品，需要某种形式的访问控制，特别是考虑到人均设备数量预计将出现显著增长 [2]。所有这些设备都需要一种“哪个实体可以访问哪个设备”的保护机制，在用户家中拥有数百甚至数千台设备的情况下，这些设备之间的授权管理将成为一个可用性挑战 [3]。为解决此问题，必须开发一种可扩展且易于使用的访问控制系统。

实现访问控制的传统方法，例如访问控制列表（ACL）（例如，[4],[5]）和基于角色的访问控制（RBAC）在可扩展性和管理性方面存在一些问题[6]，尤其是在物联网（IoT）背景下。为了解决这些问题，提出了基于属性的访问控制（ABAC）作为一种更优的方法。在ABAC中，主体请求对客体执行操作时，其“授予或拒绝是基于主体的分配属性、客体的分配属性、环境条件以及以这些属性和条件定义的一组策略”[6]。通过考虑主体、客体和环境的属性，而非静态和预定义的角色，基于属性的访问控制实现了更灵活和可扩展的访问控制规则。

一种在物联网（IoT）中需要动态和灵活管理支持的新兴方法是Swarm[7],[8]。该方法设想大量独立、跨领域和异构设备能够自主协同工作，以协同方式执行任务[9]。

为了实现Swarm，一种名为Swarm Broker的软件模块被集成到参与Swarm的每个设备中。Swarm Broker帮助Swarm节点相互发现、建立信任并进行通信。由于 Swarm是一个开放且异构的环境，其节点涵盖从资源受限的嵌入式设备到高端服务器的各种设备，因此Swarm Broker被设计为一种分布式异构软件代理（见图1）。在Swarm中，访问控制尤为重要，因为计算资源将像数字共享经济一样广泛可用。

在此背景下，提出了一种面向Swarm的基于属性的访问控制（ABAC）系统。在设计过程中考虑了若干需求：分布式（Swarm服务分布在多个设备上）、异构性（服务和设备的异构性）以及物联网规模（数十亿设备）。该系统还必须作为 Swarm Broker中的平台服务提供，并可供最终用户管理。

开发并评估了一个概念验证，以验证其质量和在物联网环境中的适用性。采用了两种方法：一种是由美国国家标准与技术研究院（NIST）[26]开发的用于评估访问控制系统的质量度量集，以及性能

表I 近期采用访问控制的工作，主要在物联网背景下。

前期工作	访问控制模型	轻量级	可扩展的	去中心化的策略分发	策略管理
Galka, et al. [4], Wang, et al. [5], Corcoran, et al. [10], S.-H. Lee, 等[11], D. Lee, 等[12]	ACL (生物识别) ACL (开放授权)	X	X
Windley [1]	ACL	X	X
Novo [13]	CapBAC	X	X	X
Diaz [14]	CapBAC	X	X	X
Alliance 15	ABAC	X	X	X（能力）	X（能力）
Gusmeroli 等 [16]	基于属性的访问控制 (可扩展访问控制标记语言)	X	X	X	X（JSON 声明）
Hernandez 等 [17]	基于属性的访问控制 (可扩展访问控制标记语言)	X	X	X	X
Ferraiolo, et al.[18]	ABAC	X	X	X	X（形式模型）
Servos, et al. [19]	ABAC	X	X	X
Seitz, et al.[20]	ABAC	X	X	X
Wang, et al. [21]	ABAC	X	X
Fernandez, et al.[22], Salama, et al.[23], Ye 等[24] Swetina 等 25	ABAC	X	X
所提系统的目标	ABAC	X	X	X	X

在单板计算机（SBC）上执行的评估，旨在评估该系统在物联网环境中的适用性。结果表明，该系统的可扩展性可以从数千台设备扩展到数十亿台设备，具体取决于 Swarm服务之间的交互密度。此外，由于该系统以平台服务的形式实现，因此具备可组合性和水平可扩展性，非常适合Swarm的异构性和规模需求。最后，策略分发机制提升了可用性，用户只需访问单一界面即可同时管理大量设备。

本文的结构如下。第二节描述了物联网中访问控制的最新进展。第三节讨论了作者在Swarm中实现访问控制的方法，并解释了提议的架构。第四节描述并评估了一个概念验证的实现。最后，第五节提出了最终想法和未来方向。

II. 研究现状

当前关于访问控制的研究主要集中在物联网设备上，如表I所示。每项工作所涵盖的方面用X标记；通用的框架、标准或协议显示在括号内。值得注意的是，在消费电子领域，迄今为止大多数研究采用访问控制列表（ACL），虽然其提供了轻量级规则，但随着网络中设备数量线性增长，可扩展性较差。

在基于能力的访问控制（CapBAC）模型中，主体自身携带一组用于访问资源的加密签名权限，即可被视为一种反向且分布式的访问控制列表。根据Gusmeroli等人 [16]的观点，CapBAC被提出作为物联网的一种替代方案，因其满足物联网对可扩展性和可管理性的需求。尽管 CapBAC具有优势，但在大规模环境下进行管理可能较为困难，因为它直接针对资源的身份进行操作。此外，现有的CapBAC解决方案均未提供易于使用的策略管理工具。

基于属性的访问控制系统提供了更高的可扩展性，因为它允许更灵活的策略规则，并且还考虑了周围环境在物联网设备的环境中，这是一个常见需求。然而，并非所有ABAC系统都是轻量级的，特别是那些基于可扩展访问控制标记语言（XACML）的系统，XACML是一种基于XML的ABAC标准，在工业界被广泛使用。为了提供更轻量级的解决方案，Seitz等人[20]使用XACML策略生成基于 JSON的SAML断言。在物联网框架中，oneM2M[28]提出了一种基于XACML的授权架构，但采用更简单的基于 JSON的策略模型。只有一项ABAC研究提出了策略管理方案，但仅作为形式化模型，没有实际的实现。

目前可用的访问控制解决方案无法满足Swarm的需求。对于一个真正的去中心化系统，用户需要能够无缝地管理自己的一组设备，这就需要一种新颖的解决方案。本文借鉴了XACML标准架构和oneM2M简单策略模型的思想，并引入了分布式概念，旨在实现更用户友好的授权管理。诸如认证以及更丰富的策略模型等方面，留待未来工作进一步研究。

III. 拟议的访问控制系统

本节概述了Swarm环境下ABAC系统的需求，并描述了提出系统。

A. 需求

Swarm 内的访问控制系统必须具备以下特性：
- 异构：必须支持轻量级策略，以便在资源稀缺的设备以及具有高处理能力的平台上均可行地运行该系统。
- 可扩展的：该系统必须支持为大量服务定义和实施策略。
- 分布式与去中心化：遵循Swarm理念，系统应在策略执行与管理上独立于中央实体。
- 平台服务：该系统必须集成到Swarm Broker中，使应用服务无需承担评估策略的责任。
- 用户友好：Swarm的大规模可能会给终端用户的访问控制策略管理带来困难。例如，如果一个用户拥有数千项服务，则逐个管理每项服务可能并不可行。

B. 通用ABAC系统

基于属性的访问控制（ABAC）的主要特征是使用分配给主体和客体的属性，或从环境中提取的属性。在 ABAC系统中定义访问控制规则的结构是策略，该策略由一组权限、禁止或义务组成，这些均基于属性构建。此外，还需要一种机制来验证请求是否应被允许或拒绝[29]。该机制实现了拦截请求并处理相关策略以验证其授权的逻辑。

该机制涉及主体、对象、数据源以及一些“点”。策略执行点（PEP）负责拦截从主体到对象的消息，并将访问请求转发至策略决策点（PDP）。随后，PDP从策略库中读取策略，从策略信息点（PIP）获取属性和环境条件，并利用这些信息做出决策，即判断该访问请求应被“允许”或“拒绝”。此决策结果将返回给PEP，若请求被“允许”，则PEP将消息转发至对象；否则向主返回“未授权”消息。最后，策略管理点（PAP）负责提供用户界面，以便管理员创建、查看和编辑策略。

C. Swarm中的ABAC系统

在Swarm中集成ABAC系统时，必须考虑前述要求以及所述ABAC机制在Swarm内部的适配。首先讨论提出方案的高层架构设计，然后详细解释其各组件的功能。

1) 架构

Swarm 提出了一种微服务的分布式图，分为平台服务和应用服务。应用服务提供通过网络支持机器对机器的资源共享。平台服务实现 Swarm 的核心功能，其目标是为应用服务提供通用功能。平台服务的示例包括服务发现（Discovery）、服务注册（Registry）以及协议间的绑定（Binding）。这些平台服务被集成在一个单一的软件模块内，即Swarm Broker[9]。

访问控制机制可以作为平台服务提供，即在代理内部实现，并在每个设备中实施。这种方法的优势在于能够更准确地提取有关服务环境的信息，增强系统的灵活性和代表性这些属性。应用服务可以使用代理提供的访问控制服务。应用服务可以通过直接通信或间接通信进行交互（见图2）。

如所述，在ABAC架构中，所有请求均由策略执行点 （PEP）拦截。这意味着，如果将PEP实现在代理内部，为了使每个请求都受到访问控制的约束，每个请求都必须经过代理，即所有请求及其相应的响应都必须是间接的。

为了解决这一限制，应将策略执行点（PEP）实现在每个应用服务内部，而不是平台服务中。这使得服务本身能够拦截每一个传入的请求，并向代理查询该请求的授权情况。服务中的PEP功能非常简单，包含一个与代理通信的REST客户端，以及一个验证授权决策的条件判断，该决策结果只能是“允许”或“拒绝”。图3展示了所提出的Swarm ABAC架构。

请注意，PDP、PIP、PAP 和策略存储库被聚合在代理内的访问控制平台服务中，由代理向 Swarm 服务提供授权这一公共功能。因此，如果一个应用服务希望利用访问控制，唯一的要求是它必须实现 aPEP，而 aPEP 非常简单，可使该服务受到本地代理的保护。

2) 访问控制策略

ABAC系统中的访问规则表示为一组策略。一个策略由任意复杂的规则集组成，这些规则使用主体、对象和环境属性来定义。它允许创建非常灵活的策略，但代价是复杂性增加。例如，XACML标准[27]由于其复杂性，不适合用于物联网目的。

本工作采用oneM2M提出的策略格式来表示ABAC策略。每个策略包含一个名称、一个唯一ID以及两个规则集，分别称为权限（privileges）和自权限（selfPrivileges）。权限集定义了控制对Swarm服务访问的规则，而自权限集定义了控制对策略本身访问的规则。自权限集用于定义管理员权限。权限集中的每条规则最多包含四个字段：
- originators：包含一个主体属性列表。此列表中的每一项可以是单个标识符（例如 Swarm 服务的身份），也可以是组标识符。组标识符可以使用保留字“all” 或通配符进行 glob风格匹配。
- targets：由一系列客体组成。该字段适用与发起者属性相同的规则。
- operations：由“发起者”中定义属性的主体对“目标”中定义属性的客体可执行的操作列表组成。
- contexts：这是一个可选字段，用于指定访问请求必须遵守的各种上下文限制，才能被允许。例如，在代码清单1中定义了一个time上下文，这意味着该策略仅在上午6点至晚上10点之间允许访问。

selfPrivileges条目与privileges具有相同的结构，只是缺少target字段，因为selfPrivileges始终引用其定义所在的策略。选择JSON作为策略序列化格式，因其比 XML更轻量级，同时保持了表达能力。

{
  "权限": [
    {
      "发起者": ["192.168.1.8/air-conditioner"],
      "目标": ["*smart-window"],
      "操作": ["read", "update"],
      "上下文": [{"time": ["** * 6-22 **"]}]
    }
  ],
  "自权限": [
    {
      "发起者": ["alice"],
      "操作": ["all"]
    }
  ]
}

清单1：访问控制策略的简单示例。

3) 访问控制实施

参考图3，当温度控制服务（服务消费者）向智能窗户服务（服务提供者）发送请求时，该请求首先被策略执行点拦截。策略执行点知道如何与代理的 AccessControl服务进行通信，因此它将使用RESTful协议与策略决策点通信，由策略决策点验证并响应该请求是否被允许。在发往策略决策点的请求中，策略执行点应将以下内容作为参数传递，服务消费者（originator）、服务提供者（target）以及所请求的 operation的标识符。

一旦PDP接收到这些参数，它将从策略存储库中检索访问控制策略，并使用PIP收集有关访问请求的上下文信息。然后，PDP将结合请求参数、策略和环境信息进行决策，结果为“允许”或“拒绝”。策略处理算法采用 XACML[27]中定义的“允许优先”组合算法。根据该算法，只要任何一条访问控制规则的处理结果为“允许”，即可授予对资源的访问权限，并立即停止策略评估。

当策略执行点（PEP）收到策略决策点（PDP）的响应后，它将允许请求被服务处理，或终止该请求，并向服务消费者返回一个表明请求为未授权的响应。最后，由于所有Swarm服务都被建模为表述性状态转移（REST）资源，因此服务消费者与服务提供者之间以及策略执行点（PEP）与策略决策点（PDP）之间的请求/响应都被映射为常规的HTTP/CoAP命令以及成功和错误的返回码。

4) 异构设备

尽管理想情况下，Swarm中的每个设备都将运行自己的代理，但某些资源严重受限的设备可能无法运行功能完整的代理。在这种情况下，我们提供了一个“最小Broker”，它提供了一组精简的平台服务。访问控制系统的一个简化版本被安装在最小Broker中。该版本不提供图形界面。可选地，最小 Broker中的PDP可以调用另一个（受信任的）Broker中的 PDP。

某些设备甚至可能不运行最小Broker，而仅运行一个应用服务。鉴于提议的架构提供了访问控制即服务，这一场景也被涵盖，只需该应用服务实现一个PEP，并远程调用其可信任的Broker上的访问控制服务即可。这种方法无法利用自包含特性，但在实践中仍然具有实用性。

5) 策略管理

策略存储库由人类用户写的策略组成。为了提供管理该存储库的接口，我们创建了策略管理点 （PAP），负责创建、读取、更新和删除（CRUD）访问控制策略。PAP作为代理平台服务实现，并分为图形界面（PAP图形用户界面）和后端服务（PAP服务）。PAP服务通过RESTful API提供对策略存储库功能的访问。

PAP图形用户界面获取并向用户显示已注册的应用服务，这些服务在策略创建过程中充当主体和客体。随后，所有更改均由PAP服务提交并更新。

PAP使用户能够管理在单个设备中运行的Swarm服务的权限。然而，由于Swarm预期的大规模特性，针对每个设备的手动策略管理策略可能并不可行。即使在不那么极端的情况下，例如用户拥有十台设备，手动配置每一台设备也会带来可用性问题。因此，为了使策略管理更加用户友好，PAP提供策略分发功能，允许使用单一图形界面来管理与不同设备中的服务相关的访问控制策略。PAP利用代理提供的发现服务以及远程PAP服务提供的RESTful API。发现服务用于查找远程服务，而RESTful API则作为PAP到 PAP之间通信的接口。

例如，在图4所示的场景中，空调具有服务A、C和 T，智能窗户具有服务T和W。当用户打开由空调提供的 PAP图形用户界面时，他将能够为所有服务A、C、T和 W创建策略。之所以可行，是因为PAP服务使用发现服务（图中未显示）来将附近的设备服务填充到图形用户界面中。当用户进行策略更新时，PAP服务将执行以下操作：（1）接收策略更新；（2）本地存储相关策略（即与A、C和T相关的策略）；（3）使用策略分发机制将涉及T和W的策略转发给智能窗户的代理。

PAP操作包含三个阶段：初始化、策略操作和策略提交。在深入分析每个阶段之前，先对相关术语进行描述。考虑一组 d设备，每台设备恰好有一个代理，并提供一组 sd服务。因此， B={1, 2,…, d}表示 d代理的集合，Sd={1, 2,…, sd}表示每台设备的sd服务集合；所有设备上的全部服务集合为 S={Sd1, Sd2,…, Sdd}。访问控制策略集用 ACP表示。用户 u将访问由代理 bl | bl ∈ B（即本地代理）提供的PAP图形用户界面。其余的代理集合 Br= B\ bl由用户间接管理的代理组成（即远程代理）。

在第一阶段，用户 u将访问PAP图形用户界面，并提供其凭据。系统会显示一个界面，其中包含该用户有权编辑的 ACP。此外，用户还可以创建新策略，其主体和客体将是服务集合 S中的属性。为了使集合 ACP和 S在图形用户界面中可用，图形用户界面需要通过向PAP服务发出请求来获取这些集合。此请求将由PAP处理。代理服务 bl，在一个名为get_s_and_acps的函数中。此函数接收关于用户 u的信息作为输入，并返回集合 S和 ACP。它首先使用Swarm代理发现服务来查找 Br，即一组远程代理。然后尝试在 bl与 Br中的所有代理之间建立会话，以确保在该会话期间，只有 bl能够向 Br中的代理推送新策略。如果会话建立成功，则通过连接所有已发现服务的集合，将 Br中每个代理注册的服务与本地注册的服务聚合，从而构建集合 S。类似地，通过连接 Br中每个代理的所有策略集合与本地存储的策略集合，构建 ACP集合。最后，对 ACP集合进行过滤，仅返回用户 u有权限编辑的策略。

在第二阶段，将根据检索到的策略和服务构建图形用户界面，即 ACP和 S。用户 u将通过更改策略进行交互，例如创建一组新的ACP′ 。这可以用函数 GUI.manipulate(S, ACP) = ACP′来描述。

在第三阶段， ACP′被提交给PAP服务：将调用函数store_updated_acps。该函数将遍历 Br，并将任何其客体与每个代理中注册的服务相匹配的策略转发到 Br。策略转发包括向远程代理的PAP服务发送POST请求。最后，它会将与本地注册服务相关的策略存储在本地策略存储库中。

IV. 实现与评估

本节描述了一个原型实现，并对所提出的解决方案进行了定性和定量评估。

A. 原型

我们创建了一个概念验证，并将其集成到当前的代理实现[30]中。该代理具有使用HTTP的RESTful API，可以轻松适配其他应用协议，例如CoAP。

a) PDP - 策略决策点 ：如第三节所述，策略决策点负责实际执行访问控制决策。策略决策点的输入包括：一个访问请求、一个策略列表以及与该访问请求相关的环境属性列表。策略决策点的输出是一个访问决策，其值可以是“真”，表示访问请求被“允许”；或“假”，表示被“拒绝”。

b) PIP - 策略信息点 ：负责收集访问请求的上下文属性。在当前实现中，它将获取当前日期和时间。

c) 策略执行点 - PEP ：如图3所示，策略执行点位于服务提供者内部，而不是像ABAC架构中的其他“点”那样位于代理内部。PEP通过HTTP与代理进行通信。

d) 策略管理点 - PAP ：实现策略管理的逻辑。如前所述，它分为两部分：PAP图形用户界面和PAP服务。PAPGUI由用户用于编辑ACP的网页组成（见图5）。

当用户保存新策略时，PAP图形用户界面将通过 PAP服务RESTful API与代理进行通信。图6显示了PAP图形用户界面的截图。左侧的字段是策略发起者，而右侧的字段是策略目标。中间的按钮使用户能够指定允许的操作。实验性图形界面不支持添加上下文属性。

输入框中的值代表Swarm服务。请注意，可以在发起者和目标框中看到各种IP地址，从而可以通过单一用户界面管理分布在不同设备上的多种服务的策略。当用户保存策略时，系统将使用函数store_updated_acps将其选择性地推送到相应的设备。

B. 评估

评估重点在于评估所提出方案在物联网环境中的可行性，特别是考虑Swarm架构的情况。评估分为两部分：第一部分包括对一组访问控制质量指标[26]的评估；第二部分则包含一种定量性能评估的方法论。

1) 访问控制定性指标

美国国家标准与技术研究院（NIST）推荐了一套用于评估访问控制系统的十四项质量指标[26]。我们评估了我们的解决方案是否满足这些指标。未来工作可从中受益，因为使用标准化指标集在比较解决方案时可能有所帮助。

• 将用户权限分配和取消分配到系统所需的步骤 ：在我们的实现中，用户必须打开策略管理器界面并编辑策略。尽管用户必须手动将每个服务添加到策略的特定规则中，但使用单一界面即可管理多台设备的策略，从而避免了要求用户为每台设备分别打开一个管理页面等步骤。

• 将对象权限分配和取消分配到系统所需的步骤 ：与上述相同，只是涉及客体，而不是用户。

• 访问控制系统对最小权限概念的支持程度 ：通过将主体可能拥有的权限集合限制在其合法目的所需的最小范围内来实现。提出系统不支持任何用于最小权限管理的特定工具，而是依赖于策略定义。

• 对职责分离的支持 ：此指标指的是系统要求多个具有不同权限的主体共同完成某项任务的能力。由于 Swarm是一个高度异构的环境，所提出的访问控制系统不提供职责分离功能。

• 创建访问控制策略所需的关联数量 ：每条策略权限规则至少需要3个用户输入：发起者、操作和目标。

• 访问控制系统对实现和演进访问控制策略的适应程度 ：访问控制策略的演进必然意味着需要更改处理这些策略的软件。扩展系统以支持更多属性不应困难。

• 访问控制策略中对用户和资源进行管理的横向范围（跨平台和应用） ：在Swarm中，每个设备恰好运行一个代理b，以及数量可变的服务ns。存储在b中的策略的横向范围等于服务ns。

• 控制的纵向范围（在应用程序、数据库管理系统和操作系统之间） ：针对Swarm的整个访问控制逻辑仅考虑 RESTful Web服务。没有映射到其他软件层。

• 安全支持 ：未涵盖。

• The degree of freedoms for AC management ：该指标指的是用户在编辑策略时，从不同视角看到的系统情况。当前系统仅提供单一视图来管理策略，导致自由度非常有限。

• 访问控制系统可以解决或防止的策略冲突 ：由于系统使用“允许优先”算法来评估针对策略的访问请求，因此这些冲突始终能够得到解决。

• 现有系统中的配置灵活性 ：微内核、应用或客户端/服务器：我们的解决方案在设计上采用客户端/服务器模式：位于应用服务提供商内部的策略执行点作为客户端，而位于平台服务中的策略决策点则作为服务器。这种配置既安全又灵活[26]。例如，如果程序员有一个没有访问控制功能的服务，并希望添加该功能，则只需将策略执行点模块添加到该服务中（灵活性），并处理身份与认证模块（本文未涉及）。

• 策略封装在策略组合、合成和约束方面的能力 ：不适用。

• 访问控制执行性能 ：指在发出访问请求时执行的操作数量。对于预期拥有大量用户的系统（如Swarm）而言，这一点非常重要，可以通过计算决策过程的计算复杂度来衡量。

大量的计算负载发生在策略决策点（PDP）中，当其接收一个请求、一组策略和若干属性，并计算出决策时。检索策略的复杂度以及调用策略信息点（PIP）的时间复杂度为输入规模 n（系统中存储的策略数量）的线性时间：O(n)。遍历权限字段中的规则，该字段具有三层嵌套结构，其开销为 O(n³)。因此，在最坏情况下，请求授权的整体复杂度为 O(n)+O(m³)，可均摊为 O(m³)。

2) 性能评估

性能评估的目标是收集有关普通现成物联网设备能够处理的策略大小的信息。该评估通过测量访问请求对运行在配备700 MHz单核处理器和512MB SDRAM的单板计算机（SBC）上的策略决策点（PDP）的响应时间来进行。该开发板运行使用Nerves框架创建的轻量级Linux发行版，其中运行用Elixir编程语言编写的Swarm Broker。

为了测量系统的性能，通过改变存储在代理中的策略的权限字段中规则的数量（nr）以及每条规则中属性的数量（na），测量了访问请求到达策略决策点的响应时间。测试了 nr和 na的多种组合。对于每种组合（nr, na），一个自动化脚本会创建 nr条随机规则，每条规则包含 na个随机属性。这些规则被分组为任意数量的策略；由于策略仅是规则的分组方式，策略的数量不会影响计算时间。所使用的属性包括主体、对象、操作和时间窗口（一种上下文属性）。

为了预测访问响应，手动创建了两个结果已知的固定请求。其中一个请求应导致拒绝访问，而另一个请求应获得允许访问。为了产生“拒绝”响应，在规则集的属性中引入了一个前缀；而请求则使用不同的前缀生成，从而阻止匹配。通过将一个手动创建的已知策略插入到随机生成的策略集中，获得了允许访问的结果。

测试通过执行这两个请求并各自重复10次，测量策略决策点（PDP）的响应时间。图6展示了测试方法论。由于对策略决策点（PDP）的访问请求是HTTP请求，预期返回码为401（未授权），表示应拒绝访问的请求，以及 200（正常），表示应授予访问的请求。任何与此不同的返回码均表明系统出现故障，解释为系统无法处理特定请求，通常是由于请求过载所致。

测试结果如图7所示。纵轴表示平均HTTP请求响应时间，横轴表示 nr和 na的不同组合。每组柱状图将 na的给定值与6个不同的 nr值集合相关联。

该图表显示，当 na和 nr的值增加时，响应时间也随之增加。当这些变量设置为一百或更小时，决策机制在不到一秒的时间内作出响应。这种开销最小，对于大多数 Swarm交互而言可以忽略不计。

从200个属性开始，响应时间的增加大致呈线性增长，并开始对整体服务的通信产生一定影响。当属性数量为 2000、规则数量为200时，响应时间最大为5.38。进一步增加 nr和 na时，许多请求会因超时或其他错误而失败；因此我们认为这是当前系统正常运行的极限。

C. 讨论

提出系统采用基于属性的访问控制，并涵盖了表I中列出的所有方面。它填补了物联网访问控制解决方案中的主要空白，即以去中心化方式实现策略分发与管理，同时具备可扩展性和轻量级特性（如性能评估所示）。

关于对提出系统的定性评估，策略分发机制的优势通过“分配能力所需的步骤”这一指标得到了证实。然而，这些步骤还可以通过使用更丰富的策略模型（例如 [18],[19]）以及一些自动生成策略的方法进一步减少，这些内容留待未来工作完成。此外，选择面向服务的架构对访问控制的实际方面产生了积极影响，因为它仅要求服务实现一个HTTP客户端或任何基于REST的协议（如 CoAP），即可拥有一个可运行的策略执行点。但最小权限和职责分离尚未涵盖，将留待采用增强型策略模型的未来工作来实现。由于相关研究中没有一项应用了定性评估，因此无法进行比较。另一方面，我们在工作中使用的 NIST指标可以为未来工作提供一个起点，以便将其解决方案与我们的进行比较。

评估还表明，策略决策算法是三次方的，普通设备最多可支持两百条规则和数千个属性。一项使用基于JSON断言的相关研究表明，在大多数情况下，加密和完整性验证将占用大部分处理时间[20]。然而，作者并未提及所匹配规则的大小。我们假设，当规则和属性数量较少时，加密操作的影响较大；但随着规则和属性数量的增加，匹配允许请求所需的时间将变得更长。加密和认证不在本文的讨论范围内，但安全保护方法[31]将在未来工作中进行研究和评估。

最后，为了更清楚地理解规则和属性数量的意义，有必要估算一个“Swarm集群”（即高度互联的Swarm服务子集）的规模，以及其服务之间逻辑连接的程度，例如满足200条规则和2000个属性所需的连接程度。为此，需借助图论的一些前提进行计算。

首先，假设所有规则中的主体和客体数量大致相同；这使得估算得以简化，并可视为一个无向图。图中的每个顶点代表一个Swarm服务（目标/发起者），每条边代表两个服务之间的逻辑连接（意味着存在一条包含主体和客体的规则）。

因此，考虑一个Swarm集群，例如包含10,000个服务（顶点数量 V= 10, 000），其中平均有20%的服务相互通信（图密度 d= 0.2）。利用图论方程1,可以证明，平均度等于1,999.8。这表明，在拥有10,000个服务且其中20%在逻辑上相互连接的Swarm集群中，该提出方案最多可使用200个属性并保持功能正常。

通过改变 V和 d，这些结论可能会大不相同。一种可能性是将Swarm与社交网络进行比较，特别是考虑到它预期将成为一个有机的网络。例如，尽管一个流行的社交网络在2017年3月已有约20亿活跃用户，但每个用户的平均好友数量仅为 3402。这意味着图密度非常低，仅为 0.000034%。因此，如果Swarm中的连接关系与此社交网络类似，则提出方案可支持包含60亿项服务的Swarm。由于预计物联网将拥有200亿台设备，该系统仍存在局限性，但将在未来工作中加以解决。

V. 结论

本工作描述了一种面向消费电子设备的访问控制系统，该系统应用于受Swarm启发的物联网环境中。此前，该领域的先前研究具有可扩展性和轻量级特点，但很少有研究关注去中心化的策略分发与管理。本文提出的贡献包括一个允许在设备之间轻松进行策略创建和策略分发的系统，且无需依赖中央授权服务器。该系统的性能通过现成的中端硬件进行了评估，结果表明其可根据服务间交互密度从数千台设备扩展至数十亿台设备。由于目前尚无针对消费类设备解决相同问题的研究，因此未进行直接的性能对比，而是提供了该系统对Swarm适用性的分析。未来的工作将继续寻找相关研究，并解决两个主要问题：如何在不使策略过于复杂的前提下提高属性粒度；以及如何创建一种安全且可扩展的机制来实现服务与属性认证。