适用于AWS物联网的访问控制模型

1 引言

安全性是物联网（IoT）的基本要求，尤其是随着部署规模的不断扩大。连接设备的数量正在呈指数级增长。根据高德纳（Gartner）的数据，到2020[5]将有超过200亿台连接设备。这带来了一个极具吸引力且全新的攻击面。访问控制是物联网安全解决方案中的关键组成部分。因此，已提出多种面向物联网的访问控制模型。瓦达等人[25]对此进行了最新的综述。与此同时，主流云服务提供商，如亚马逊网络服务（AWS）[1],微软Azure[7],和谷歌云平台（GCP）[6],在其现有的云服务和资源基础上进行了扩展以启动物联网服务。Azure和GCP在云中使用某种定制形式的基于角色的访问控制（RBAC）[15,27]，并采用预定义的角色和组来满足其访问控制需求。GCP将RBAC用于其物联网解决方案的授权[9]。亚马逊云服务对其云和物联网服务使用基于策略的访问控制机制[1,2]。与Azure云不同，微软Azure物联网已采用基于策略的访问控制来指定物联网授权[4]。然而，针对实际应用的支持云的物联网平台的正式访问控制模型仍然缺乏。

本文中，我们研究并探讨了亚马逊云服务（AWS）及其物联网（IoT）服务，由此提出了一种称为AWS‐IoTAC的正式访问控制模型。该模型抽象自现有的分散式AWS物联网文档，并结合我们对该服务的实践，以验证我们对物联网功能的理解。AWS‐IoTAC基于张等人[29],为通用AWS访问控制所提出的AWS访问控制（AWSAC）模型构建而成。

物联网服务需要超越云中基本访问控制的新概念。在开发物联网的访问控制模型时，将模型置于明确定义的物联网架构背景下进行构思是十分有益的。阿尔谢赫里和桑杜提出了面向云计算的物联网分层访问控制（ACO）架构[12]。我们将模型中的不同实体与ACO架构的四个层级相对应，以强调本模型与专为访问控制设计的云支持物联网架构的相关性。我们还在AWS物联网平台中演示并配置了一个智能家居用例，展示了本模型在解决AWS物联网授权问题方面的适用性。

在不久的将来，随着数十亿连接设备的出现，物联网采用灵活的访问控制模型（例如基于属性的访问控制（ABAC）[18,19],）来满足物联网服务动态访问控制需求将不可避免。在ABAC中，通过使用用户和资源的属性（以名称‐值对表示的属性）来确定用户对资源的访问权限。AWS物联网支持针对物联网设备的部分ABAC属性形式，然而这些属性在访问控制策略中的使用是有限的。因此，我们提出了对我们的（AWS‐IoTAC）模型进行ABAC增强，以在其内纳入完整的ABAC形式。

我们的贡献摘要如下。
- 我们为AWS物联网开发了一个正式的访问控制模型，称之为AWS‐IoTAC。
- 我们展示了一个智能家居物联网用例，清楚地说明了我们的模型如何解决支持云的物联网平台中的授权问题。
- 我们提出了针对AWS‐IoTAC的ABAC增强方案，以包含更灵活和更细粒度的访问策略。

本文的其余部分组织如下。第2节讨论相关工作，包括AWSAC模型。AWS‐IoTAC模型在第3节中提出并定义。第4节演示了一个利用AWS‐IoTAC模型的智能家居用例。第5节提出了对AWS‐IoTAC的一些扩展。最后，我们在第6节中总结全文，并探讨可能的未来研究方向。

2 相关工作和背景

2.1 相关工作

正如瓦达等人最近综述的那样，物联网访问控制模型已有大量研究。[25]许多这些模型基于基于能力的访问控制（CAPBAC）[17],基于角色的访问控制（RBAC）[15,27],而少数采用基于属性的访问控制（ABAC）[18,19]。在[16],中提出了一种基于集中式策略决策点（PDP）的集中式CAPBAC模型。而文献[17]中则提出了一种面向物联网的完全去中心化CAPBAC模型。然而，完全集中化或完全去中心化的方法可能并不适用于动态物联网架构中的访问控制需求。

马赫勒等人[23]提出了一种用于物联网认证与访问控制的身份建立和基于能力的访问控制方案。除了CAPBAC之外，物联网中还使用了RBAC模型[22]，其中设备的访问权限由其角色决定。类似地，张和田[28]提出了一种面向物联网的扩展型基于角色的访问控制模型，其中根据从系统和用户环境中收集的上下文信息来授予访问权限。这些面向物联网的RBAC模型仍然存在RBAC的局限性，例如角色爆炸[26]问题。孙等人[20]提出了一种基于RBAC和ABAC的混合访问控制模型（ARBHAC），以应对物联网中大量动态用户的问题。该方法利用属性进行用户‐角色分配，然后由用户的角色决定对资源或设备的访问权限。这种方法类似于动态角色[11,21],，即根据用户的属性动态地为用户分配角色。然而，ARBHAC未能充分利用更通用的ABAC模型中存在的用户、设备、环境和应用程序属性。

我们的模型与上述现有模型有显著不同，尤其是其本质是为由最大的云服务提供商亚马逊云服务（AWS）管理的真实世界支持云的物联网平台而开发的访问控制模型[1]。我们工作的另一个显著特点是识别用户属性以及物联网设备（请求访问其他设备的设备，以及被请求访问的设备）属性在物联网访问控制中的适用性。我们坚信，ABAC模型是应对快速发展的物联网领域访问控制需求的最佳方法。

2.2 AWS访问控制模型 (AWSAC)

张等人开发了一种用于亚马逊云服务云服务的访问控制模型。[29]。我们在此简要描述AWS访问控制（AWSAC）模型及其形式化定义，这为下一节介绍的AWS‐IoTAC模型奠定了基础。图1展示了单个AWS账户内的AWSAC模型，其形式化定义见表1。AWSAC包含七个组件：账户（A）、用户（U）、组（G）、角色（R）、服务（S）、对象类型（OT）和操作（OP）。账户是亚马逊云服务中的基本资源容器，允许客户拥有特定的云资源，且作为资源使用和计费的基本单位。用户代表能够通过亚马逊云服务认证并被授权通过账户访问云资源的个人。拥有账户的用户可以在该账户内创建其他用户，并为其分配对资源的特定权限，因此该用户即为管理员。组是一组用户组。用户组关系指定了用户到组的分配。“角色”在亚马逊云服务中，与标准的基于角色的访问控制角色不同，用于在不同的AWS账户中的用户和资源之间建立信任关系。用户可以通过扮演角色操作被分配角色，分配给这些角色的权限允许这些用户访问相应的云资源。用户与角色的映射通过虚拟用户角色关系指定。为了区分亚马逊云服务中的“角色”与基于角色的访问控制角色，在图1中使用了引号。为简便起见，在本文其余部分中，除非另有说明，我们所提到的角色均指“角色”。服务指AWS云服务。对象类型表示特定云服务中某类对象的具体类型，例如虚拟机。操作表示基于附加到对象类型或其所属服务的访问控制策略所允许执行的操作。

亚马逊云服务采用基于策略的访问控制机制。一个亚马逊云服务策略是一个JSON文件，其中包含在云中的服务和资源上定义的权限。它由三个主要部分（或标签）效果、操作和资源组成，并可选地包含条件。策略可以附加到用户、组、角色或特定的云资源上。虚拟权限分配是指通过将策略附加到这些实体上来虚拟地为用户、角色和组分配权限的过程。当策略附加到资源时，需要在策略中指定特定的主体（账户、用户或角色）。单个策略中可以定义多个权限，且多个策略可以附加到一个实体上。

3 亚马逊云服务物联网中的访问控制

3.1 AWS物联网访问控制（AWS‐IoTAC）模型

AWS IoT是由领先的云服务提供商亚马逊云服务（Amazon Web Services，AWS）管理的物联网平台。它允许在AWS云中的连接物联网设备与应用程序之间进行安全通信[2]。针对AWS IoT（一种支持云的物联网平台）的访问控制模型涉及物联网空间中的不同实体，并应定义这些实体如何被授权以安全地相互交互。我们将参与AWS IoT服务中访问控制和授权的实体纳入AWSAC模型，从而构建AWS‐IoTAC模型。AWS‐IoTAC模型基于对AWS IoT大量文档的细致研究以及对该服务开展的实践实验，以验证我们的理解。

AWS‐IoTAC模型如图2所示，及其不同的组件。由于它是在AWSAC模型之上开发的，因此它包含AWSAC的所有组件和关系，以及一组额外的组件和与AWS IoT服务相关的关系。附加或修改的组件和关系在表2中进行了形式化定义，并在下文进行非正式讨论。AWS‐IoTAC模型中有六个新增组件。

AWS物联网服务（AIS）是亚马逊云服务中的新物联网服务。它拥有不同的实体，用于支持物联网设备及其在云中的底层授权。我们在模型中将AIS表示为一个独立的实体，以强调其重要性，并清晰展示与其相关的其他组件和关系。AIS的矩形框表示其在亚马逊云服务中的单例存在。证书集（Certs, C）是一组由受信任实体——证书颁发机构（CA）签发的X.509证书[10],。AIS可以为物联网客户端生成X.509证书，也可以允许使用由客户端创建的证书，前提是这些证书由在AWS IoT服务中注册的CA签名。基于MQTT的客户端（物联网设备、应用程序）使用Certs向AIS进行身份验证。MQTT是一种OASIS标准，是一种适用于资源受限设备的轻量级机器对机器（M2M）发布/订阅消息协议。[8]设备（Devices, D）代表一组连接的物联网设备，例如传感器、灯泡。这些设备可以独立于AIS存在，因此我们在模型中用不同颜色表示它们。在与AWS物联网服务进行身份验证并建立安全通信通道之前，必须将有效的X.509证书及其私钥以及根AWS CA证书复制到设备上。设备与证书之间的关联通过证书绑定关系实现。在AWS物联网平台中，一个证书可以关联多个设备/设备实体（thing）。同样，多个证书也可以复制到一个物联网设备上。然而，在我们的模型中，我们假设证书绑定是设备与证书之间的一对一关联，以便更好地进行授权管理，并且该关联本质上是可变的，可在证书过期或吊销时由管理员更改。在AWS物联网中，访问控制策略附加到证书上，并在与这些证书关联的物理物联网设备上实施。

物联网对象（IO）表示在云中的虚拟物联网对象。虚拟对象是真实物理设备或虚拟空间中的独立逻辑实体（应用程序）的数字对应物[24]。在AWS IoT中，设备和设备影子代表物联网对象，它们是云中真实物理物联网设备的虚拟对应物。对于每个物联网设备，我们假设至少有一个设备及其设备影子在云中被实例化，提供一组预定义的MQTT主题/通道（与此设备相关联），以允许与其他物联网设备和应用程序进行交互，即使该设备处于离线状态。设备影子维护相关联的物联网设备的身份和最后已知状态。物联网操作（IOP）是一组为物联网服务定义的操作性操作，不包括管理操作，例如创建设备、证书等。基本的物联网操作集可以根据物联网设备和应用程序与AWS IoT服务通信所使用的通信协议进行分类。对于MQTT客户端，有四种基本的物联网操作：iot:Publish允许设备向MQTT主题发布消息，iot:Subscribe允许设备订阅所需的MQTT主题，iot:Connect允许MQTT客户端连接到AWS IoT服务，以及iot:接收允许设备接收来自已订阅主题的消息。类似地，对于HTTP客户端，iot:获取事物影子可用于获取设备影子的当前状态，iot:更新事物影子可用于发送消息以更新或更改设备影子的状态，而iot:删除事物影子则用于删除设备影子。每当设备或应用程序向云中的虚拟设备发送消息时，如果该设备影子尚不存在，则会自动创建一个新的设备影子。

规则(Ru)是简单的SQL语句，根据规则中定义的条件触发预定义的操作。一条规则从设备/thing接收数据，并触发一个或多个操作。这些操作将数据从一个物联网设备路由到其他物联网设备，或路由到其他AWS服务。每条规则必须关联一个IAM（身份和访问管理）角色，该角色授予其访问物联网对象和触发操作所涉及的AWS服务的权限。关系触发操作表示规则与规则触发操作的物联网对象及AWS服务之间的多对多映射。AWS中的访问控制策略已修改为包含物联网操作和资源，因此被称为IoT策略。AWS物联网同时利用IoT策略和IAM策略，向物联网设备、IAM用户以及物联网应用程序分配特定权限。因此，虚拟权限分配(VPA)已更新以包含IoT策略，并且这些策略被附加到X.509证书上。附加到证书上的策略将在使用该证书连接并认证到AWS IoT服务的设备上强制执行。一个策略可以附加到多个证书，或者多个策略可以附加到一个证书。

我们模型中的所有组件和关系均在单个AWS账户的范围内定义。跨账户授权不在本文讨论范围之内。我们模型中的组件和关系基于AWS IoT服务的当前功能。尽管AWS IoT服务关联着许多其他组件和关系，但我们的模型从访问控制的角度涵盖了其中最重要的部分。

3.2 ACO物联网映射

在此，我们展示了AWS‐IoTAC模型与阿尔谢赫里和桑杜提出的面向访问控制的（ACO）物联网架构的相关性[12]。我们的模型中不同实体与ACO架构的对应关系如图3所示。不同的实体映射到ACO物联网架构的不同层。物理设备或设备位于对象层，而虚拟物联网设备或资源映射到虚拟对象层。所有亚马逊云服务云服务和资源位于云服务层，与云和物联网设备交互的用户和应用程序则位于应用层。授权策略在云中定义，这些策略对试图访问云和虚拟物联网资源的物理设备及用户所使用的应用程序实施访问控制决策。AWS‐IoTAC总体上与面向访问控制的分层架构（ACO）兼容。

4 用例

在本节中，我们展示了一个智能家居用例，其中恒温器和两个灯泡通过AWS IoT服务根据传感器输入进行控制。这里我们重点关注物联网设备通过云进行的交互。（更复杂的示例将涉及不同用户和应用程序与物联网设备的交互。）我们演示了如何基于AWS‐IoTAC模型配置不同组件之间的访问控制和授权。

4.1 用例设置和配置

图4展示了该用例中涉及的不同连接设备、虚拟物/对象以及亚马逊云服务云和AWS IoT服务。我们首先创建了一个亚马逊云服务账户，以在AWS IoT服务中设置该用例。通过使用AWS IoT管理控制台，我们为每个物理设备创建了一个虚拟对象（设备）——两个传感器，一个恒温器和两个灯泡。一个设备可以具有一个设备类型，用于存储相似设备的配置，以及表示单个物联网设备属性的设备属性（键值对）。例如，传感器1具有一个传感器设备类型，并具有两个属性SType（传感器类型）和归属（归属关系）。这些属性的值在创建设备时设定。我们还通过AWS IoT控制台中的“一键证书创建”功能为每个物联网设备/设备生成了X.509证书。然后，我们定义了适当的授权策略并将其附加到这些证书上。在附加策略后，将相应的证书附加到虚拟设备，并连同该证书的私钥和AWS根CA证书一起复制到对应的物理设备上。CA证书用于指定服务器的身份，即本例中的AWS IoT服务器。设备证书在设备认证过程中使用，并根据所附加的策略确定其授权权限。我们使用亚马逊云服务提供的AWSSDKs（Node.js）[3]模拟了灯和恒温器设备，并使用MQTT.fx工具将传感器模拟为MQTT客户端[8]。所有这些设备都使用MQTT协议并通过TLS安全机制与AWS IoT服务进行通信。

根据我们的用例场景，我们利用了AWS物联网平台中的规则引擎来定义规则并触发期望操作。这些操作包括调用Lambda函数以及通过亚马逊简单通知服务（SNS）发送短信向用户发送通知。对于每条规则，都会关联一个IAM“角色”，以授权该规则访问所需的AWS和AWS IoT服务及资源。

4.2 使用场景

在此，我们讨论用例的两个场景及其相关的授权方面。

A. 场景1：
此场景涉及一个温度传感器和一个恒温器，如图5(a)所示。一个温度传感器传感器2（以实线椭圆表示）检测温度，并将数据发送到其设备影子，Sensor2（以虚线椭圆表示）位于AWS物联网平台中。根据传感器2的数据，一条规则（规则1）触发一个Lambda函数，通过向其设备影子发布更新消息来改变恒温器的状态（如虚线椭圆所示）。如果环境温度高于78华氏度，则该规则会调用一个Lambda函数，向恒温器的设备影子发布消息，以打开恒温器并将其温度设置为72华氏度。物理恒温器（以实线椭圆表示）已订阅其影子主题，因此能够接收到更新消息，并将其状态与设备影子同步。针对此场景，我们为传感器2和恒温器定义了一个简单的授权策略，如图5（b）所示。该策略允许实体在亚马逊云服务云中的任何资源上执行任何物联网操作（例如，发布、订阅）。该策略附加到X.509证书上，并复制到相应的物理物联网设备（传感器2和恒温器）中。在此示例中，物理设备对AWS物联网中的所有资源具有完全的物联网访问权限。

B. 场景2：
图6中展示了一个具有细粒度授权策略的更全面的场景。一个光传感器传感器1监测环境光照水平，并在光照水平较低时打开户外灯灯1和灯2。当灯打开时，家庭的用户（所有者或住户）会收到关于灯状态变化的短信通知。

针对此场景，我们为传感器1定义了一个更严格的策略，在该策略的条件部分中使用了设备属性。该策略如图6（b）所示，包含两条策略语句——第一条授权客户端仅当其客户端ID为传感器1时才能连接到AWS物联网；第二条允许对所有资源执行物联网发布、订阅和接收操作，但前提是请求访问的客户端具有值为Home1的设备属性归属。该策略在访问控制决策中使用了设备属性。如图4所示，设备属性表示物联网设备/设备的特征。

目前，AWS IoT策略仅支持请求访问AWS IoT服务中资源的客户端（设备/事物）的设备属性。一个有用的场景是利用执行物联网操作的目标资源的属性。例如，用户希望传感器1只能向具有以下属性的灯发布数据：位置=室外。目前，AWS‐IoTAC模型无法在IoT策略中包含目标设备/事物的属性。然而，该场景可以通过规则和Lambda函数实现，如下所示。

Lambda函数的代码片段如图7所示。在此，我们搜索具有特定属性键和值的设备，即位置=室外，并获取此类设备的列表，即本用例中的灯1和灯2。一旦获得该列表，就会向这些设备的影子更新主题发布一条用于打开灯的JSON格式消息，如图所示。物理灯泡接收到更新消息后改变其状态。一旦设备状态发生变化，将通过AWS SNS服务向规则中指定的用户发送短信通知，如规则2和规则3中所定义。

5 建议的增强功能

在典型的ABAC模型中，访问控制策略会利用请求访问的用户（执行者）属性以及被访问的资源（目标对象）属性，以确定对对象的允许访问。ABAC中的属性是名称‐值对，用于表示实体（如用户和对象）的特征。通常还会考虑环境或系统属性。在AWS物联网中，设备可以拥有一组属性。这些属性在云中的虚拟设备上定义，并与其关联的物理设备同步。

设备属性的一个示例如图8所示。(b)中所示，设备还可以通过证书附加或关联获得属性。在创建X.509证书时会设置和定义许多属性，当证书附加到设备时，该证书的属性可用于AWS IoT策略中，以为这些设备分配权限。然而，证书属性并不能反映其所附加设备的任何直接属性，因此不同于典型的基于属性的访问控制属性。

因此，AWS物联网（AWS‐IoTAC）的访问控制模型可归类为一种受限形式的ABAC模型，主要原因如下。在AWS‐IoTAC模型中，只能利用那些请求在云中对物联网资源（其他物联网设备或应用程序）执行操作的物联网设备/设备的属性。仅当设备/设备使用MQTT协议连接并与AWS IoT服务通信时，才在策略中应用设备属性。在AWS IoT中，目前一个设备最多只能拥有五十个属性，其中仅有三个属性可直接搜索。

基于上述讨论以及对AWS IoT服务的探索，我们提出了一些针对AWS‐IoTAC模型的改进措施，以在该模型中引入更完整的基于属性的访问控制形式。

1. 包含目标资源属性的基于属性的访问控制
   如我们在用例场景2中所讨论的，AWS‐IoTAC模型应能够纳入执行物联网操作的设备/设备的属性，以及被操作的设备/设备的属性，且不受所使用连接和通信协议的影响。目标资源属性主要用于隔离特定物联网对象的身份。例如，一个物联网设备需要向具有某些特定属性值的其他设备发布消息。该发布设备无需知晓其需要发布的具体主题，而可以发布到满足某些特定条件的多个主题。

2. 包含用户和组属性的基于属性的访问控制
   更完整的基于属性的访问控制形式需要包含用户及其用户组的属性，如图8(c)所示。在现实世界的物联网系统中，有多个用户在使用和控制物联网设备。因此，需要包含用户在云支持的物联网平台中，访问控制决策中的设备关系有助于实现细粒度授权。

3. 利用策略机进行策略管理
   AWS提供了一种基于策略的访问控制，该控制依赖于附加到用户、组、“角色”和证书等实体上的策略文件。对于所有这些实体，都定义了大量策略。随着数十亿设备及其用户的增长，这些策略将急剧扩展，并很快变得难以管理。在不久的将来，AWS可能遇到的一个问题是策略爆炸问题。在以管理员身份设置我们的用例时，我们意识到需要一种基于客户的策略管理工具。策略机（PM）[13,14],是由美国国家标准与技术研究院（NIST）开发的一种访问控制规范与执行工具，可以在该场景中加以利用。然而，还需要对我们的模型与PM之间的关系进行更详细的分析，以证明其适用性。

6 结论

我们提出了一种针对AWS物联网的正式访问控制模型。AWS是最大的云计算平台之一，提供了众多服务和产品以及详尽的文档。将物联网平台的所有方面和功能纳入我们的模型是一项挑战。我们主要关注真实支持云的物联网平台中的访问控制和授权。我们相信，我们的模型可作为开发支持云的物联网通用访问控制模型的初步蓝图，并可逐步增强以纳入新的物联网访问控制功能。我们还根据用例设置和配置过程中的经验，提出了一些对AWS‐IoTAC模型的改进建议。基于属性的访问控制似乎是一种有前景的物联网服务访问控制模型。在未来的工作中，我们将探索将基于属性的访问控制增强功能集成到我们的模型中的方法，包括客户端（例如设备、用户、应用程序）属性和目标资源（例如设备、应用程序）属性。我们还计划研究其他真实世界支持云的物联网平台中的访问控制和授权。