亚马逊AWS官方博客

AWS IoT 物联网系列 | 第五篇:物联网场景中灵活实施对设备的控制管理

AWS IoT 物联网系列博客

当前物联网环境中,设备类型多种多样,连接方式不一而足。为了帮助读者更好的理解并运用 AWS IoT 相关服务,我们提供了一个完整的 IoT 起步指南,包含设备的注册及上线、设备管理、用户身份及权限管理以及成本控制,通过这一系列的起步指南,也可以快速了解到 AWS IoT 服务如何与 Amazon Alexa 语音助手进行集成。AWS IoT 物联网系列共8篇,本篇是该系列的第一篇,其他篇链接请在本文结尾处查看。

 


背景介绍

随着 IoT 设备的普及,如何安全、灵活地管理对设备的控制权限变得更加复杂。在以往简单的应用场景中,控制端 APP 仅仅需要使用 AWS IoT 平台对一个设备进行控制。但随着家庭拥有的物联网设备愈加丰富,控制端 APP 需要同时控制多个设备。另外,某些终端设备还需要提供给多人控制,例如家具式的智能排插能够支持被所有的家人打开或者关闭,因此就出现一个控制端 APP 能够控制多个设备端,或者多个用户能够相互控制多个设备的权限管理问题。

对这两种场景,本文分别介绍如何结合 AWS STS 服务,以临时安全凭证的方式在多设备和多用户的场景下精细化地向控制端 APP 分发和管理控制权限。

方案使用场景

场景一:单个控制端 APP 管理多个设备

当用户需要使用单一控制端管理多台设备时,通过控制端 APP,用户能够实时查看所有设备的状态信息。而且,当用户通过控制端 APP添加/删除设备后,控制端 APP 能够及时获取最新的控制权限。

在 IoT 场景下,考虑到设备与服务端的交互的高可用性,以及对时间和资源调度的不可预知性,利用 API GatewayLambda 组合的无服务器架构方式可以更好的满足实际使用需求。这是因为 API Gateway 和 Lambda 按照请求数量和持续时间进行计费,无需管理服务器,并获得持续扩展的能力。

另外,IoT 场景下大部分的管理关系属于键值存储,因此推荐使用 Dynamodb(一个托管的分布式NoSQL数据库)作为保存管理关系的数据库。

因此,我们可以利用下图的架构来实现这一需求:

  1. 控制端 APP 通过调用部署在 API Gateway 的更新管理权限 API 接口,修改保存在数据库中的管理关系。
  2. 当控制端 APP 需要控制 IoT 设备时,控制端 APP 调用部署在 API Gateway 的获取临时凭证的API接口。
  3. 在 Dynamodb 数据库中查询当前控制端 APP 所拥有或能够控制的设备集。
  4. 获取设备集后,通过调用 STS 服务的 AssumeRole API 申请临时凭证。在调用 AssumeRole API 时,根据设备集构造 AssumeRole API 的 Policy 参数,从而进一步收紧临时凭证的权限,使控制端 APP 只能控制有限的设备集。
  5. 当控制端 APP 获取临时凭证后,就能够用 MQTT over Websocket,通过对 IoT Core 发布和订阅的方式对 IoT 设备进行控制。
  6. 由于 STS 签发的临时凭证具有有效期,为了防止临时凭证过期影响控制端 APP 对 IoT API 的调用,在控制端 APP 开发时需要维护临时凭证的刷新机制。另外,由于临时凭证的权限是在其签发时决定的,因此对设备进行新增、修改、删除等变更操作后,应主动刷新临时凭证,以获取最新的权限。

场景二:多个控制端 APP 交互管理多个设备

现有的 IoT 设备包含更多交互特性。设备的购买者/拥有者始终保持对设备的完全控制,但可以把设备的全部/部分控制权限分享给其他人,或对权限进行撤回。

多个控制端交互管理多个设备跟单个控制端的架构原理是类似的。不同在于,一个控制端的场景下控制端能够通过自身定义的逻辑主动刷新临时凭证,但在多个控制端的场景下,则需要构建一套控制端之间的消息通讯机制,通知另一个控制端进行刷新。我们可以利用下图的架构来实现这一需求:

当控制端 APP 获取临时凭证后,其通过 MQTT over Websocket 订阅自己的消息通知主题 topic,例如控制端1订阅主题 /phone/111,而控制端2订阅主题  /phone/222。当控制端1通过访问更新管理权限的 API 接口把设备的控制权限分享给控制端2,数据库更新后,主动向受影响的控制端2所订阅的主题 /phone/222发送消息。通过这种方式,受影响的控制端就能够获取到权限变更的通知从而主动刷新自己的临时凭证。

需要注意的是,为了达到实时通知的效果,控制端 APP 需要跟 AWS IoT 平台建立长连接。连接时间是 AWS IoT 的其中一个收费维度,因此该方案可能会增加额外成本,具体如下:

  1. 如果控制端 APP 也需要实时获取设备端的状态信息,通过共用长连接,该消息通知机制不会增加控制端 APP 的连接成本,只增加对一个 Topic 的订阅。
  2. 如果控制端不需要获取设备端的实时状态,仅仅为了实现实时的消息通知机制而建立长连接,那就可能需要考虑在控制端 APP 建立长连接带来的额外成本增加。按照 AWS 官网的定价,以美国东部 (弗吉尼亚北部) 为例,一个控制端一年(365*24*60分钟)全天候建立一个长连接所需成本约为0.042 USD。

总结

在物联网多人权限管理的场景中,我们使用 STS 服务分发临时凭证,以满足权限的细粒度控制;用 DynamoDB 保存管理关系,满足权限修改的灵活性。而且 DynamoDB 和 STS 都是可扩展的托管服务,能满足物联网设备高并发的请求。可以看到,AWS 服务是模块化的,客户可以根据自己的需要像搭积木一样量身定制适合的架构,以满足创新的业务场景和想象空间。

 

本篇作者