📚 课程目录第3章 IoT云IAM核心概念

3. IoT云IAM核心概念

IoT云平台与普通互联网应用最大的差异在于：账号体系里不仅有“人”，还有海量“设备”。设备需要上报数据、订阅指令、访问影子、写入时序库；应用需要读取设备数据、下发控制命令；运维人员需要批量管理固件升级。如果把这些访问关系都简化成“账号+密码”，很快就会失控。IAM（Identity and Access Management，身份与访问管理）要解决的，正是“谁，在什么条件下，能对哪个对象，做什么操作”这一组问题。理解 IoT 云 IAM，关键是先分清六个核心概念：主体、资源、策略、角色、信任策略、权限边界。

主体：不只是用户，更是设备身份

主体（Principal）是发起访问请求的一方。在 IoT 场景中，主体至少有三类。第一类是云账号用户，例如运维工程师、数据分析师，他们通过控制台或 API 登录。第二类是设备身份，通常以“产品 + 设备名”唯一标识，例如 ProductKey=PK1001, DeviceName=sensor-001，设备用设备证书或密钥完成认证。第三类是云服务或应用身份，例如规则引擎、函数计算、数据转发服务，它们以服务角色或应用凭证访问资源。

主体最重要的属性是“可被唯一识别”和“可被认证”。设备主体往往还带有标签，例如 region=华东1、model=A1、stage=prod，这些标签后续会成为策略里的判断条件。需要特别注意的是：设备身份一旦泄露，攻击者就能伪装成合法设备上报伪造数据或订阅他人指令，因此设备主体必须做到“一机一密、一机一证”，不能多台设备共用同一套凭证。

资源：被访问的对象及其层级

资源（Resource）是主体想要操作的对象。IoT 云里的资源通常具有明显的层级结构：实例 → 产品 → 设备 → 设备影子 / 物模型属性 / 时序数据 / 指令 Topic。例如一条设备影子资源可以写成 acs:iot:*:1234567890:/products/PK1001/devices/sensor-001/shadow，一条消息 Topic 资源可以写成 acs:iot:*:1234567890:/products/PK1001/devices/sensor-001/user/update。

资源层级决定了权限可以“粗放”也可以“精细”。如果只授权到产品级，那么该产品下所有设备都受影响；如果授权到单设备级，就能实现设备隔离。实际治理中，常见做法是：给运维角色授予产品级只读权限，给设备主体只授予自身设备级读写权限，给数据分析应用授予时序数据只读权限。资源写错一个层级，权限范围就会放大或缩小一个数量级。

策略：把“允许/拒绝”写成可计算规则

策略（Policy）是描述权限的规则集合，通常由 Effect、Action、Resource、Condition 四部分组成。Effect 取 Allow 或 Deny；Action 是操作，例如 iot:UpdateDeviceShadow、iot:Publish、iot:Subscribe；Resource 指定对象；Condition 是附加条件，例如来源 IP、时间、标签、TLS 版本。

下面是一段设备侧策略示例，含义是：只允许 sensor-001 这台设备向自己的上报 Topic 发布消息，并且只允许在指定产品下操作：

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["iot:Publish"],
      "Resource": [
        "acs:iot:*:1234567890:/products/PK1001/devices/sensor-001/user/update"
      ],
      "Condition": {
        "StringEquals": { "iot:ProductKey": "PK1001" }
      }
    }
  ]
}

策略的评估逻辑通常是“默认拒绝 + 显式允许 + 显式拒绝优先”。也就是说，没有匹配到 Allow 就是拒绝；一旦某条 Deny 命中，即使其他策略 Allow 也会被拒绝。因此 Deny 常被用来做“黑名单兜底”，例如禁止某台已下线设备继续发布数据。

角色：让主体临时获得权限，而不是长期持有密钥

角色（Role）是一组权限的载体，本身不是账号，而是“可被扮演的身份”。在 IoT 场景中，角色最常见的用法是：设备或应用不直接持有长期密钥，而是通过 STS（Security Token Service）申请临时凭证。例如，设备端通过设备证书向 IoT 平台换取临时 Token，再拿 Token 去访问时序数据库；函数计算通过服务角色读取设备影子。这样即使临时凭证泄露，也会在有效期后失效，风险窗口被大幅压缩。

角色与策略的关系是：策略定义“能做什么”，角色定义“谁可以扮演它、扮演后拿到哪些策略”。一个角色可以绑定多条策略，一条策略也可以被多个角色引用。治理时建议按“职责”建角色，例如 DeviceReporterRole、AppReadOnlyRole、FirmwareOperatorRole，而不是按人建角色。

信任策略：决定“谁有资格扮演这个角色”

信任策略（Trust Policy）是角色的“准入规则”，它回答的是：哪些主体可以扮演这个角色。信任策略与权限策略不同：权限策略管“扮演后能做什么”，信任策略管“能不能扮演”。例如，一个给设备使用的角色，其信任策略应限定为 IoT 设备身份服务，而不是允许任意云账号扮演：

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "iot.aliyuncs.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

如果信任策略写得过宽，例如允许 "Principal": "*"，就等于把角色开放给所有主体，攻击者一旦拿到任意合法身份，就可能扮演该角色获取更高权限。因此信任策略是 IoT IAM 中最容易被忽视、却最危险的一环。

权限边界：给“最大权限”加一道天花板

权限边界（Permissions Boundary）是一种“上限控制”。它不直接授予权限，而是规定某个主体或角色最多只能拥有哪些权限。即使角色绑定了管理员策略，只要权限边界里没有对应 Action，实际生效权限仍会被截断。在 IoT 场景中，权限边界常用于：限制代运维角色不能删除产品、不能修改设备证书；限制第三方应用不能访问生产环境设备数据。

可以用一个简单关系理解：实际权限 = 身份策略允许 ∩ 权限边界允许 − 显式拒绝。身份策略决定“想给什么”，权限边界决定“最多能给什么”，显式拒绝决定“绝对不能给什么”。三者叠加，才是最终生效的权限集合。

六个概念如何协同工作

把六个概念串起来，一次典型的设备数据上报访问大致经历以下判断：设备以自身身份完成认证，成为主体；平台根据信任策略判断该设备是否有资格扮演 DeviceReporterRole；角色绑定的策略给出允许的 Action 与 Resource 集合；权限边界再截断一次上限；若没有显式 Deny 命中，则允许向自己的上报 Topic 发布消息。任何一环写错，都会导致“该通的通不了”或“不该通的通了”。

在 IoT 权限治理中，建议优先检查三件事：第一，设备主体是否做到一机一证，避免共用凭证；第二，信任策略是否限定到具体服务或具体账号，避免 *；第三，资源路径是否精确到设备级，避免产品级通配。把这三件事做扎实，再叠加角色与权限边界，IAM 才能真正成为 IoT 云上可审计、可收敛、可演进的权限底座。