AWS IoT中确立设备所有权、防范未授权数据访问的最佳方案

核心逻辑 #

通过动态权限策略+身份属性绑定的方式，直接用AWS IoT原生的策略引擎做访问控制，无需额外开发校验逻辑，就能实现用户只能访问自有设备的主题，核心是将Cognito用户身份和设备序列号做唯一关联，两类身份的IoT访问权限都通过关联属性动态生成，避免硬编码通配规则导致的越权。

实现步骤 #

1. 完成Cognito用户与设备序列号的绑定 #

• 在Cognito用户池新增自定义属性custom:owned_thermostat_sn，用于存储用户绑定的温控设备序列号
• 在用户绑定设备的业务流程中增加后端校验逻辑：用户在App提交设备序列号和设备侧生成的临时校验码，校验通过后，后端Lambda同时完成两个操作：
  • 更新当前用户的Cognito自定义属性custom:owned_thermostat_sn的值为设备序列号（如123）
  • 给对应设备的IoT物模型新增自定义属性sn，值为设备序列号，同时给设备X509证书新增标签owner_id，值为当前用户的Cognito身份ID，方便后续审计

2. 配置Cognito身份对应的IoT访问策略 #

不要给Cognito身份分配通配的IoT主题权限，使用AWS IoT支持的策略变量动态生成允许访问的主题范围，策略示例如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iot:Subscribe",
        "iot:Receive"
      ],
      "Resource": "arn:aws:iot:<你的区域>:<你的账号ID>:topicfilter/thermostat/${cognito-identity.amazonaws.com:custom:owned_thermostat_sn}/temperature/*"
    }
  ]
}

注：${cognito-identity.amazonaws.com:custom:owned_thermostat_sn}会被AWS IoT策略引擎自动替换为当前请求用户的Cognito自定义属性值，用户Jill的属性值是自己的设备序列号，即使主动请求订阅/thermostat/123/temperature/*，也会因为资源不匹配被直接拒绝。

3. 配置设备X509证书对应的IoT访问策略 #

设备的发布权限同样做动态限制，避免设备被篡改后发布到其他序列号的主题，策略示例如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Publish",
      "Resource": "arn:aws:iot:<你的区域>:<你的账号ID>:topic/thermostat/${iot:Connection.Thing.Attributes[sn]}/temperature/*"
    }
  ]
}

注：${iot:Connection.Thing.Attributes[sn]}会自动替换为当前连接设备的物模型sn属性值，设备只能上报自身序列号对应路径的主题。

加固建议 #

• 设备物模型的sn属性设置为不可变更，避免设备被篡改后修改属性值越权
• 单个用户绑定多台设备的场景，可以将用户的设备列表存在DynamoDB，结合AWS IoT规则引擎的Lambda前置校验做细粒度权限控制
• 不要给任何身份分配iot:*、topicfilter:*这类通配权限，最小化权限范围

内容的提问来源于stack exchange，提问作者Eitan