AWS IoT通用策略与Cognito用户策略的区别

Question

我想知道有没有人对AWS IoT中的策略处理有最佳实践的想法，例如，我们可能会有两种不同的情况：

情况1： 调用一个lambda函数（将身份ID作为参数），动态创建一个策略并将其附加到身份ID上。策略将包含硬编码的物品名称，例如：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "arn:aws:iot:us-west-2:XXXX:client/hardcodedClient1"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iot:Publish",
        "iot:Subscribe",
        "iot:Receive"
      ],
      "Resource": [
        "arn:aws:iot:us-west-2:XXXX:topic/$aws/things/THINGNAME1/*",
        "arn:aws:iot:us-west-2:XXXX:topicfilter/$aws/things/THINGNAME1/*"
      ]
    }
  ]
}

方案2：通过使用策略变量，如${iot:ClientId}，${iot:ThingName}，我们可以将一个单一的策略附加到所有的cognito-identity用户上。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "arn:aws:iot:us-west-2:XXXX:client/${iot:ClientId}"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iot:Publish",
        "iot:Subscribe",
        "iot:Receive"
      ],
      "Resource": [
        "arn:aws:iot:us-west-2:XXXX:topic/$aws/things/${iot:Connection.Thing.ThingName}/*",
        "arn:aws:iot:us-west-2:XXXX:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/*"
      ]
    }
  ]
}

因此，问题是：哪种方法是最佳实践，同时又保证Cognito用户只能与自己的设备交互？

- jamesjara

---

你可能自己回答了一些问题吗？ - Daniel Birowsky Popeski

Answer 1

情况二更好。您还可以使用Cognito联合池实现身份验证机制，并使用适当的IAM策略在IoT策略中使用${cognito-identity.amazonaws.com:sub}变量进行适当的权限设置（只需记住将此策略附加到您的Cognito identityId）。

如果您的客户端从浏览器连接，则最好不要使用iot：ClientId，因为clientId必须是唯一的，因此用户将无法打开多个浏览器选项卡。

- Maciej Dzikowicki

Answer 2

使用策略变量的情况2是推荐的方法。

它减少了需要处理的策略数量，并使其有意义且可重复使用。从好的方面来看，通过不使用lambda和每次创建策略来节省一些额外的时间和金钱！

就安全而言，与策略中的策略变量无关，最终与策略允许或拒绝的操作有关，因为策略变量会根据尝试执行操作的人动态解析，然后与硬编码的策略相同。

- gitesh.tyagi

---

但是 #case2 会允许任何用户连接到 IoT 注册表中的任何内容，对吗？ - jamesjara

是的，您可以通过使用布尔条件来控制允许主体仅作为其所附加的那些事物进行操作。您可以使用attach-thing-principal API将主体和事物连接起来。 - gitesh.tyagi