本文将说明两大云服务 Amazon Web Services (AWS) 和 Microsoft Azure 所使用的连接要求，并且介绍开发人员可以如何使用来自众多供应商的开发套件及相关软件，来快速连接这些服务。
 

物联网门户在云服务中所扮演的角色
 

当一台物联网设备连接到某个资源，如云服务或远程主机，其自身以及因扩展整个物联网网络而可能受到伪装成合法服务或服务器的威胁。相反地，云服务本身也面临着来自黑客的类似攻击威胁，黑客会模仿物联网设备事务以试图对云防御机制进行渗透。为了帮助确保保护物联网设备和云资源，云服务需要采用特定的安全协议对登录进行双向身份验证并对后续操作加以授权，以确定是否允许使用服务。此类协议通常包含在一系列服务内，以在物联网设备和云资源之间提供安全门户。
 

类似于其他可用的物联网云服务平台，AWS 和 Azure 分别提供特定入口门户，以供物联网设备用来与每家提供商的全套云资源进行交互。这些云资源包括虚拟机 (VM) 和软件即服务 (SaaS) 产品等。Azure IoT Hub 和 AWS IoT 使用功能类似的机制和能力组合，能够为各自相应的企业云产品提供此类门户。
 

在最低程度上，这些及其他物联网门户会使用特定的身份验证协议来建立安全连接。这些协议可通过每家提供商的软件开发套件 (SDK) 实现。对于 AWS，物联网设备使用双向身份验证来连接设备网关。而设备网关会使用设备注册表中保存的信息来连接物联网设备和其他物联网支持服务。该寄存器可存储唯一设备标识码、安全凭证，以及管理对 AWS 服务进行访问所需的其他元数据(图 1)。在 Azure 中，身份注册表具有类似的功能。

图1 和其他云提供商一样，AWS会为开发人员提供一系列专用服务，用以在物联网设备和企业云服务之间提升事务的安全性和有效性。(图片来源： Amazon Web Services)

AWS IoT 和 Azure IoT 都提供有相关服务，能在与每台物理物联网设备有关的虚拟设备中维护状态信息。在 AWS IoT 中，设备影子将为 AWS IoT 提供此功能;而设备孪生则为 Azure IoT 提供类似功能。
 

这种安全门户概念可延伸到物联网边缘服务，例如 AWS Greengrass 或 Azure IoT Edge 等。这些边缘服务产品可将部分云服务和功能下放至本地网络，并且在大规模部署中，边缘系统会放置在靠近物联网设备和系统的位置。开发人员可以使用 Azure IoT Edge 等服务来实现应用业务逻辑，或提供所需的其他功能来缩短延迟，或向本地操作人员提供服务，如工业自动化等(图 2)。

图2 为了支持边缘计算，云服务提供商会提供Microsoft Azure Edge等专用服务，使部分Azure IoT云服务更靠近与物联网应用有关的物理设备。(图片来源：Microsoft Azure)

应对物联网门户连接性要求
 

不管是通过边缘系统进行连接，还是直接连接至提供商的物联网服务，物联网设备通常需要满足一系列要求，才能连接提供商的物联网门户并使用提供商的云服务。虽然细节有差异，但物联网设备至少要提供某些项目，如私钥、X.509 证书或其他安全令牌。在设备-云连接序列的身份验证阶段，这些密钥、证书或令牌会为物联网门户提供关于物联网设备身份的认证或证明。此外，物联网云服务通常需要一套策略规范，用于定义物联网设备和云服务之间交互所需的访问权限。
 

和其他企业计算要求一样，需要使用由主要物联网云服务(如 AWS IoT 和 Azure IoT)指定的特定格式和程序，来提供用于身份验证的认证信息以及用于访问管理的策略信息。这些服务不仅在最低程度上支持基于证书的身份验证，它们还支持使用其他形式的认证。例如，开发人员可以在 AWS IoT 中使用以 JSON Web Token (JWT) 为基础的基于令牌的身份验证方法，或在 Azure IoT 中使用共享访问签名 (SAS) 令牌。
 

如前文所述，这些服务使用注册表来保存每台物联网设备的元数据。除安全和其他信息以外，此类注册表还会保存访问权限策略，而这些策略需要进行定义以连接物联网设备。虽然针对不同的云服务有不同的指定方式，但这些策略定义对不同通信通道和实体的访问权限进行了描述。例如，一项简单的 AWS IoT 访问权限策略可能会使用 JSON 格式来指明：AWS IoT 设备注册表中带有特殊“物件”名称的物联网设备只能在具有相同的相关物件名称的通道中进行连接与发布消息(清单 1)。

清单 1：开发人员使用 JSON 格式来描述物联网设备的 AWS IoT 访问权限策略。(代码来源：AWS)

云就绪开发套件
 

虽然云提供商提供关于此类格式和程序的详细规格，但提供商的支持论坛上经常充斥着开发人员遇到的非常小但关键的细节问题，这些问题使其无法顺利完成身份验证和访问管理。更糟糕的是，从安全角度来看，无意识的滥用认证或不完整的访问策略定义还有可能导致物联网设备、网络和应用受到攻击。随着现成即用的开发板和配套软件包的推出，开发人员能够在这些连接程序中快速导航，并使用供应商提供的示例快速连接到物联网云。例如，Espressif Systems 的 ESP32-Azure IoT 套件或 Seeed Technology 的 AZ3166 IoT 开发套件都包含经过 Azure 认证的开发板，且专门为轻松连接 Microsoft 云而设计。
 

Microsoft 提供完整的分步演示，包括受支持开发套件的身份验证和访问凭证等。以 AZ3166 开发板为例，开发人员只要按下板上的按钮，即可启动与本地 Wi-Fi 网络的连接。一旦连接，他们可以使用适用于 Microsoft Visual Studio Code 的 Azure IoT Tools 扩展包中的 Azure IoT Device Workbench，来进行开发、调试，以及与 Azure IoT Hub 进行交互。通过使用此工具集及其代码样例包，开发人员可以在 Azure IoT Hub 中为物联网设备创建对象，并使用提供的文件来配置包含凭证和其他元数据的关联身份注册表，用以将物联网板连接至 Azure IoT Hub(图 3)。

图3 Microsoft Azure IoT Device Workbench 中提供的代码样例和凭证可以帮助开发人员完成配置，以便将 Seeed Technology 的 AZ3166 IoT 开发套件连接至 Azure IoT Hub。(图片来源：Microsoft Azure)

Azure IoT Device Workbench 提供额外的支持软件和元数据，让开发人员可以快速加载 AZ3166 板和代码样例，并开始将开发板的温度和湿度传感器的测量数据传输到 Azure IoT Hub。
 

在物联网云中为物理物联网设备创建表示形式以及配置关联的注册表，所涉及的必要步骤只是将设备连接到物联网云。不过，要充分利用云服务的优点，Azure IoT Hub 还需要一项访问权限策略。为了对来自 AZ3166 传感器的设备到云的消息进行监控，开发人员只需使用 Azure 共享访问策略屏幕，来选择专门为快速启用必要访问权限而设计的预构建策略(图 4)。

图4 开发人员可以使用预构建的策略轻松授权使用 Azure 云服务以及来自 eed Technology 的 AZ3166 IoT 开发套件的传感器数据。(图片来源：Microsoft Azure)

在使用 AWS IoT 时，开发人员可以转用开发套件，如 Microchip Technology 的 AT88CKECC-AWS-XSTK-B 零接触配置套件及配套软件，来对云连接进行快速评估。此版本是早期 Microchip 零接触配置套件的更新版，预先加载了身份验证凭证。使用该套件提供的其他脚本，开发人员可以快速将开发板连接到 AWS IoT，而无需处理私钥和证书问题(请参阅“采用零接触方法安全锁定物联网设备”)。
 

其他开发套件包括 Renesas 的 RTK5RX65N0S01000BE RX65N 云套件和 Infineon Technologies 的 KITXMC48IOTAWSWIFITOBO1 AWS IoT 套件，扩展了对 AWS IoT 连接的支持，并且支持快速开发基于 Amazon FreeRTOS 的应用。AWS 提供了详细的指导说明，有助于注册开发板，创建身份验证凭证，以及加载所提供的 JSON 策略以连接至 AWS IoT 和使用 AWS 服务。
 

简化大规模物联网部署的配置
 

开发套件(如前文所述的套件)可作为快速开发物联网应用的原型，以及探索物联网云服务连接要求的有效平台。但在实际应用中，开发人员通常需要转用更高级的方法，而这些方法专为简化现实应用中的物联网设备配置而设计。Azure IoT 和 AWS IoT 都支持各种方法，以允许对大规模部署中的个别设备或大量物联网设备进行更自动化的配置。
 

以 AWS IoT 为例，开发人员可以使用自举方式进行证书配置。亦即，智能产品在交付时会提供自举证书，其中包含关联的最低访问权限以供请求和访问新证书(图 5)。

图5 AWS IoT 在物联网设备中支持字举证书配置方法。(图片来源：Digi-Key Electronics，原始资料来源于 Amazon Web Services)

使用自举证书时，设备可以连接到云(见图 5 中的“1”)，请求 (“2”) 新证书，接收 (“3”) 由 AWS 无服务器 Lambda 函数生成的证书 URL，以及从 AWS Simple Storage Services (S3) 存储桶检索 (“4”) 该证书。而使用该新证书，设备则可以重新登录到 AWS IoT (“5”)，以便继续正常操作。
 

AWS 还提供其他云服务，以支持使用执行资源(如 AWS Lambda 函数)对身份验证令牌进行动态配置。例如，某汽车应用可能依赖一系列临时连接，在这些连接中，使用令牌更实用而且更安全。在适用于物联网身份验证和授权的 AWS 模块批准令牌请求以后，AWS Security Token Service (STS) 会生成一个令牌以传输到汽车系统。使用该令牌，这些系统可以访问需要由 AWS Identity and Access Management (IAM) 服务验证的 AWS 服务(图 6)。

图6 主要云服务提供商提供其他形式的身份验证认证，例如，由 AWS Security Token Service(STS)动态生成安全令牌的这种流程。(图片来源：Amazon Web Services)

AWS 为访问权限的动态分配提供类似功能。此时，其他 AWS Lambda 函数会分配一组与有效令牌关联的策略(图 7)。

图7 开发人员可以使用云服务来实现访问权限的动态分配，它尤其适用于具有临时连接或短期操作的应用。(图片来源：Amazon Web Services)

其他物联网云服务允许开发人员更有效地处理大规模部署中的配置。例如，AWS IoT 提供车队配置功能，包括支持前文所述自举方法的更大规模部署。Azure IoT 的设备配置服务提供组注册功能，支持对拥有相同 X.509 证书或 SAS 令牌的大量物联网设备进行配置。
 

安全责任共担
 

IoT 云提供商提供若干有效方法，以提升物联网应用的端对端安全。尽管如此，IoT 开发人员不能预期这些方法可以承担其特定物联网应用的全部安全要求重任。实际上，云服务提供商会使用具体的模型(如 AWS 的责任共担模型)来仔细地概述其在物联网应用安全领域内的具体角色和责任(图 8)。

图8 和其他主要云提供商一样，AWS也对自身与云用户共担的责任进行了说明，以便在一方面保护云基础设施，另一方面保护客户的应用。(图片来源：Amazon Web Services)
 

AWS 和 Microsoft Azure 都提供责任共担文档，说明与解释在保护资源、数据和应用过程中提供商的自身角色，以及客户所扮演的角色。在其说明文档中，Microsoft 还概述了安全责任共担和合规性要求之间的部分关系。最后，云提供商还负有保护云安全的责任，而客户则要对在云中使用的应用、数据和资源负责。
 

总结

IoT 应用依赖以基于硬件的机制为基础所建立起来的安全层，来实现加密和安全密钥存储。和任何联网产品一样，当物联网设备连接云服务时，安全威胁可能存在于任何形式的交互过程当中。为了保护自身及其客户，IoT 云提供商针对身份验证和访问权限管理制定了具体的要求。虽然提供商会提供关于此类要求及相关规格的详细说明文档，但开发人员还是有可能发现他们为实现安全连接所做的努力有时候会使资源暴露在风险当中，甚至适得其反地使其不可访问。使用开发板和相关软件，开发人员可以快速连接云服务，并快速设计物联网应用原型，同时保证端对端安全

免责声明：本文转载自互联网，转载此文目的在于传递更多信息，版权归原作者所有。文章所用文字、图片、视频等如涉及作品版权问题，请联系小编。