本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
中的安全最佳实践 Amazon IoT Core
本节包含有关安全最佳实践的信息Amazon IoT Core。有关工业物联网解决方案的安全规则的信息,请参阅工业物联网解决方案的十大安全黄金规则
保护中的 MQTT 连接 Amazon IoT
Amazon IoT Core
在设备实例集上删除 MQTT 连接的影响和严重程度取决于许多因素。这些方法包括:
-
您的用例(例如,您的设备发送到的数据Amazon IoT、数据量以及发送数据的频率)。
-
您的 MQTT 客户端配置(例如,自动重新连接设置、关联的退避计时以及使用 MQTT 持久会话)。
-
设备资源限制。
-
断开连接的根本原因、其主动性和持久性。
为避免客户端 ID 冲突及其潜在的负面影响,请确保每台设备或移动应用程序都有Amazon IoT或 IAM 策略,该策略限制哪个客户端 IDs 可用于与Amazon IoT消息代理的 MQTT 连接。例如,您可以使用 IAM 策略防止设备无意中通过使用已在使用的客户端 ID 关闭其它设备的连接。有关更多信息,请参阅 Authorization。
您的队列中的所有设备都必须具有仅授权预期操作的权限的证书,这些权限包括(但不限于)Amazon IoTMQTT 操作,例如发布消息或订阅具有特定范围和上下文的主题。具体的权限策略可能因您的使用案例而异。确定最能满足您的业务和安全要求的权限策略。
要简化权限策略的创建和管理,您可以使用 Amazon IoT Core策略变量 和 IAM 策略变量。策略变量可以放在策略中,并且在评估策略时,变量将由来自设备请求的值替换。使用策略变量,您可以创建单个策略以授予对多个设备的权限。您可以根据您的Amazon IoT账户配置、身份验证机制和连接到Amazon IoT消息代理时使用的网络协议来确定与您的用例相关的策略变量。但是,要编写最佳权限策略,应考虑使用案例和威胁模型
例如,如果您在注册Amazon IoT表中注册了设备,则可以在策略中Amazon IoT使用事物策略变量,根据事物名称、事物类型和事物属性值等事物属性来授予或拒绝权限。事物名称是从事物连接到时发送的 MQTT 连接消息中的客户端 ID 中获取的Amazon IoT。当事物使用 TLS 相互身份验证通过 MQTT 连接或使用Amazon IoT经过身份验证的 Amazon Cognito 身份通过 WebSocket 协议连接 MQTT 时,事物策略变量将被替换。您可以使用 AttachThingPrincipalAPI 将证书和经过身份验证的 Amazon Cognito 身份附加到事物。 iot:Connection.Thing.ThingName是强制执行客户端 ID 限制的有用策略变量。以下示例Amazon IoT策略要求将已注册事物的名称用作与Amazon IoT消息代理的 MQTT 连接的客户端 ID:
-
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:Connect", "Resource": [ "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}" ] } ] }
如果要识别持续存在的客户端 ID 冲突,可以启用和使用CloudWatch 日志Amazon IoT。对于Amazon 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 警报以进行持续监控和报告。
您可以使用 Dev Amazon IoTice Defender
您可以使用 Amazon IoT Device Advisor 来验证您的设备能否可靠地连接Amazon IoT Core并遵循安全最佳实践。
另请参阅
使设备的时钟保持同步
请务必确保您的设备上有准确的时间。X.509 证书具有到期日期和时间。设备上的时钟用于验证服务器证书是否仍有效。如果您要构建商用物联网设备,请记住,您的产品在出售前可能会存放较长时间。在此期间,实时时钟可能会出现偏移误差,并且电池可能会放电,因此在工厂设置时间是不够的。
对于大多数系统,这意味着设备的软件必须包含网络时间协议(NTP)客户端。设备应等待,直到它与 NTP 服务器同步,然后再尝试连接到 Amazon IoT Core。如果无法做到这一点,系统将为用户提供一种设置设备时间的方法,以便后续连接成功。
设备与 NTP 服务器同步后,便能打开与 Amazon IoT Core 的连接。允许的时钟偏移量取决于您尝试通过此连接执行的操作。
验证服务器证书
设备与之交互的第一件事Amazon IoT就是打开安全连接。将设备连接到时Amazon IoT,请确保您正在与服务器通话Amazon IoT,而不是其他服务器在模仿Amazon IoT。每Amazon IoT台服务器都配置了为该iot.amazonaws.com域颁发的证书。该证书Amazon IoT由可信的证书颁发机构颁发,该机构验证了我们的身份和域名所有权。
设备连接时要Amazon IoT Core做的第一件事就是向设备发送服务器证书。设备可以验证它们是否希望连接到 iot.amazonaws.com,并验证位于该连接一端的服务器是否拥有来自该域的受信任颁发机构的证书。
TLS 证书采用 X.509 格式,并包含各种信息,例如组织的名称、位置、域名和有效期。有效期被指定为一对时间值(分别名为 notBefore 和 notAfter)。Amazon IoT Core诸如服务器证书的有效期有限(例如,一年),并在旧证书到期之前开始提供新证书。
每个设备使用一个身份
每个客户端使用一个身份。设备通常使用 X.509 客户端证书。Web 和移动应用程序使用 Amazon Cognito Identity。这使您能够对设备应用细化权限。
例如,您有一个由手机设备构成的应用程序,这些设备接收来自两个不同的智能家居对象(灯泡和恒温器)的状态更新。灯泡发送电池电量的状态,恒温器发送报告温度的消息。
Amazon IoT对设备进行单独身份验证并单独处理每个连接。您可以使用授权策略应用精细访问控制。您可以为恒温器定义一个策略,该策略允许恒温器发布到主题空间的策略。您可以为灯泡定义一个单独策略,该策略允许灯泡发布到不同的主题空间。最后,您可以为移动应用程序定义一个策略,该策略只允许它连接到和订阅恒温器和灯泡的主题以接收来自这些设备的消息。
应用最小权限原则,并尽可能缩小每个设备的权限范围。所有设备或用户都应Amazon IoT制定政策Amazon IoT,仅允许其使用已知的客户端 ID 进行连接,以及发布和订阅已确定和固定的主题集。
用一秒钟Amazon Web Services 区域作为备份
考虑在一秒钟内存储一份数据副本Amazon Web Services 区域作为备份。请注意,名为 “灾难恢复” 的Amazon
使用即时预调配
手动创建和配置每台设备可能很耗时。 Amazon IoT提供了一种定义模板的方法,以便在设备首次连接时对其进行配置Amazon IoT。有关更多信息,请参阅 Just-in-time 资源调配。
运行Amazon IoT设备顾问测试的权限
以下策略模板显示了运行Amazon IoT设备顾问测试用例所需的最低权限和 IAM 实体。您需要your-device-role-arn替换为在先决条件下创建的设备角色 Amazon 资源名称 (ARN)。
-
{ "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iot:us-east-1:123456789012:thinggroup/your-thing-group", "Condition": { "StringEquals": { "iam:PassedToService": "iotdeviceadvisor.amazonaws.com" } } }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "execute-api:Invoke*", "iam:ListRoles", "iot:Connect", "iot:CreateJob", "iot:DeleteJob", "iot:DescribeCertificate", "iot:DescribeEndpoint", "iotjobsdata:DescribeJobExecution", "iot:DescribeJob", "iot:DescribeThing", "iotjobsdata:GetPendingJobExecutions", "iot:GetPolicy", "iot:ListAttachedPolicies", "iot:ListCertificates", "iot:ListPrincipalPolicies", "iot:ListThingPrincipals", "iot:ListThings", "iot:Publish", "iotjobsdata:StartNextPendingJobExecution", "iotjobsdata:UpdateJobExecution", "iot:UpdateThingShadow", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:PutRetentionPolicy" ], "Resource": "*" }, { "Sid": "VisualEditor2", "Effect": "Allow", "Action": "iotdeviceadvisor:*", "Resource": "*" } ] }
针对 Device Advisor 防范跨服务混淆代理
混淆代理问题是一个安全性问题,即不具有某操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在中Amazon,跨服务模仿可能会导致混乱的副手问题。一个服务(呼叫服务)调用另一项服务(所谓的服务)时,可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作,否则该服务不应有访问权限。为了防止这种情况,我们Amazon提供了一些工具,帮助您保护所有服务的数据,这些服务委托人已被授予访问您账户中资源的权限。
我们建议在资源策略中使用 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 全局条件上下文键来防范混淆代理问题。
-
{ "Version":"2012-10-17", "Statement": { "Sid": "ConfusedDeputyPreventionExamplePolicy", "Effect": "Allow", "Principal": { "Service": "iotdeviceadvisor.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:iotdeviceadvisor:us-east-1:123456789012:suitedefinition/ygp6rxa3tzvn" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } } }