本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

中的安全最佳实践 AWS IoT Core

本节包含有关安全最佳实践的信息 AWS IoT Core。有关工业物联网解决方案的安全规则的信息，请参阅工业物联网解决方案的十大安全黄金规则。

保护 MQTT 连接 AWS IoT

AWS IoT Core是一种托管云服务，使联网的设备可以轻松安全地与云应用程序和其他设备进行交互。 AWS IoT Core 支持 HTTP 和 MQTT，这是一种专为容忍间歇性连接而设计的轻量级通信协议。 WebSocket 如果您 AWS IoT 使用 MQTT 进行连接，则您的每个连接都必须与一个称为客户端 ID 的标识符相关联。MQTT 客户端 ID 唯一地标识 MQTT 连接。如果使用已为另一个连接申请的客户端 ID 建立新连接，则 AWS IoT 消息代理会删除旧连接以允许新连接。每个 AWS 账户 客户端 ID 必须是唯一的 AWS 区域。这意味着，您无需强制要求客户端 ID 在您之外 AWS 账户 或您的区域之间保持全球唯一性。 AWS 账户

在设备实例集上删除 MQTT 连接的影响和严重程度取决于许多因素。这些方法包括：

为避免客户端 ID 冲突及其潜在的负面影响，请确保每个设备或移动应用程序都有 AWS IoT 或 IAM 政策，限制哪些客户端 ID 可用于与 AWS IoT 消息代理的 MQTT 连接。例如，您可以使用 IAM 策略防止设备无意中通过使用已在使用的客户端 ID 关闭其它设备的连接。有关更多信息，请参阅 Authorization。

队列中的所有设备都必须具有仅授权预期操作的权限的证书，包括（但不限于） AWS IoT MQTT 操作，例如发布消息或订阅具有特定范围和上下文的主题。具体的权限策略可能因您的使用案例而异。确定最能满足您的业务和安全要求的权限策略。

要简化权限策略的创建和管理，您可以使用 AWS IoT Core 策略变量 和 IAM 策略变量。策略变量可以放在策略中，并且在评估策略时，变量将由来自设备请求的值替换。使用策略变量，您可以创建单个策略以授予对多个设备的权限。您可以根据您的 AWS IoT 账户配置、身份验证机制和连接 AWS IoT 消息代理时使用的网络协议，为您的用例确定相关的策略变量。但是，要编写最佳权限策略，应考虑使用案例和威胁模型的具体情况。

例如，如果您在注册 AWS IoT 表中注册了设备，则可以使用策略中的 AWS IoT 事物策略变量根据事物名称、事物类型和事物属性值等事物属性授予或拒绝权限。事物名称是从事物连接到时发送的 MQTT 连接消息中的客户端 ID 获取的。 AWS IoT当事物使用 TLS 双向身份验证 AWS IoT 通过 MQTT 连接或使用经过身份验证的 Amazon Cognito 身份通过 WebSocket 协议通过 MQTT 连接时，事物策略变量将被替换。您可以使用 AttachThingPrincipal API 将证书和经过身份验证的 Amazon Cognito 身份附加到事物上。iot:Connection.Thing.ThingName是强制执行客户端 ID 限制的有用事物策略变量。以下示例 AWS IoT 策略要求将注册事物的名称用作与 AWS IoT 消息代理的 MQTT 连接的客户端 ID：

如果要识别持续的客户端 ID 冲突，则可以启用和使用CloudWatch 日志 AWS IoT。对于 AWS IoT 消息代理因客户端 ID 冲突而断开的每个 MQTT 连接，都会生成与以下内容类似的日志记录：

{
    "timestamp": "2019-04-28 22:05:30.105",
    "logLevel": "ERROR",
    "traceId": "02a04a93-0b3a-b608-a27c-1ae8ebdb032a",
    "accountId": "123456789012",
    "status": "Failure",
    "eventType": "Disconnect",
    "protocol": "MQTT",
    "clientId": "clientId01",
    "principalId": "1670fcf6de55adc1930169142405c4a2493d9eb5487127cd0091ca0193a3d3f6",
    "sourceIp": "203.0.113.1",
    "sourcePort": 21335,
    "reason": "DUPLICATE_CLIENT_ID",
    "details": "A new connection was established with the same client ID"
}

您可以使用CloudWatch 日志筛选器，例如{$.reason= "DUPLICATE_CLIENT_ID" }搜索客户端 ID 冲突的实例，或设置CloudWatch 指标筛选器和相应 CloudWatch 警报以进行持续监控和报告。

您可以使用 D AWS IoT evice Defender 来识别过于宽松的策略 AWS IoT 和 IAM 政策。 AWS IoT Device Defender 还提供审计检查，通知您队列中的多台设备是否使用相同的客户端 ID 连接到 AWS IoT 消息代理。

您可以使用 D AWS IoT evice Advisor 来验证您的设备是否可以可靠地连接到安全最佳实践 AWS IoT Core 并遵循安全最佳实践。

另请参阅

使设备的时钟保持同步

在设备上留出准确的时间很重要。 X.509 证书有到期日期和时间。设备上的时钟用于验证服务器证书是否仍有效。如果您正在构建商用物联网设备，请记住，您的产品可能会在出售之前存储很长时间。 Real-time 在这段时间内，时钟会漂移，电池可能会放电，因此在出厂时设置时间是不够的。

对于大多数系统，这意味着设备的软件必须包含网络时间协议（NTP）客户端。设备应等待，直到它与 NTP 服务器同步，然后再尝试连接到 AWS IoT Core。如果无法做到这一点，系统将为用户提供一种设置设备时间的方法，以便后续连接成功。

设备与 NTP 服务器同步后，便能打开与 AWS IoT Core的连接。允许的时钟偏移量取决于您尝试通过此连接执行的操作。

验证服务器证书

设备要与之交互的第一件事 AWS IoT 是打开安全连接。将设备连接到时 AWS IoT，请确保您正在与之通话， AWS IoT 而不是冒充 AWS IoT其他服务器。每 AWS IoT 台服务器都预置了为该iot.amazonaws.com域颁发的证书。该证书 AWS IoT 由可信的证书颁发机构颁发，该机构验证了我们的身份和域名所有权。

设备连接时要 AWS IoT Core 做的第一件事就是向设备发送服务器证书。设备可以验证它们是否希望连接到 iot.amazonaws.com，并验证位于该连接一端的服务器是否拥有来自该域的受信任颁发机构的证书。

TLS 证书采用X.509 格式，包含各种信息，例如组织的名称、位置、域名和有效期。有效期被指定为一对时间值（分别名为 notBefore 和 notAfter）。诸如 AWS IoT Core 服务器证书的有效期有限（例如，一年），并在旧证书到期之前开始提供新证书。

每个设备使用一个身份

每个客户端使用一个身份。设备通常使用 X.509 客户端证书。Web 和移动应用程序使用 Amazon Cognito Identity。这使您能够对设备应用细化权限。

例如，您有一个由手机设备构成的应用程序，这些设备接收来自两个不同的智能家居对象（灯泡和恒温器）的状态更新。灯泡发送电池电量的状态，恒温器发送报告温度的消息。

AWS IoT 分别对设备进行身份验证并单独处理每个连接。您可以使用授权策略应用精细访问控制。您可以为恒温器定义一个策略，该策略允许恒温器发布到主题空间的策略。您可以为灯泡定义一个单独策略，该策略允许灯泡发布到不同的主题空间。最后，您可以为移动应用程序定义一个策略，该策略只允许它连接到和订阅恒温器和灯泡的主题以接收来自这些设备的消息。

应用最小权限原则，并尽可能缩小每个设备的权限范围。所有设备或用户都应在其中 AWS IoT 制定政策 AWS IoT ，仅允许其连接已知客户端 ID，以及发布和订阅一组已确定的固定主题。

用一秒钟 AWS 区域 作为备份

考虑在一秒钟内存储一份数据副本 AWS 区域 作为备份。请注意，名为 “灾难恢复” 的 AWSAWS IoT解决方案不再可用。虽然关联GitHub库仍然可以访问，但已于 2023 年 7 月将其 AWS 弃用，不再为其提供维护或支持。要实施您自己的解决方案或探索其他支持选项，请访问联系 AWS。如果有与您的账户关联 AWS 的技术客户经理，请联系他们寻求帮助。

使用即时预调配

手动创建和配置每台设备可能很耗时。 AWS IoT 提供了一种定义模板的方法，用于在设备首次连接时对其进行配置 AWS IoT。有关更多信息，请参阅 Just-in-time 资源调配。

要运行的权限 AWS IoT 设备顾问测试

以下策略模板显示了运行 AWS IoT 设备顾问测试用例所需的最低权限和 IAM 实体。您需要your-device-role-arn替换为您在前提条件下创建的设备角色亚马逊资源名称 (ARN)。

Cross-service 设备顾问的副手防范措施令人困惑

混淆代理问题是一个安全性问题，即不具有某操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在中 AWS，跨服务模仿可能会导致副手混乱的问题。 Cross-service 当一项服务（呼叫服务）调用另一项服务（被叫服务）时，可能会发生模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作，否则该服务不应有访问权限。为防止这种情况，请 AWS 提供工具来帮助您保护所有服务的数据，这些服务主体有权访问您账户中的资源。

我们建议在资源策略中使用 aws:SourceArn 和 aws:SourceAccount 全局条件上下文键，以限制 Device Advisor 为其它服务提供的资源访问权限。如果使用两个全局条件上下文键，在同一策略语句中使用时，aws:SourceAccount 值和 aws:SourceArn 值中的账户必须使用相同的账户 ID。

aws:SourceArn 的值必须是套件定义资源的 ARN。套件定义资源是指您使用 Device Advisor 创建的测试套件。

防范混淆代理问题最有效的方法是使用 aws:SourceArn 全局条件上下文键和资源的完整 ARN。如果不知道资源的完整 ARN，或者正在指定多个资源，请针对 ARN 未知部分使用带有通配符（*）的 aws:SourceArn 全局上下文条件键。例如，arn:aws:iotdeviceadvisor:*:account-id:suitedefinition/*

以下示例演示如何使用 Device Advisor 中的 aws:SourceArn 和 aws:SourceAccount 全局条件上下文键来防范混淆代理问题。