4、身份认证与授权：设备接入认证协议（TLS/mTLS）、访问控制策略、动态权限管理

设备拿到身份凭证之后，下一步就是「怎么用」的问题。说白了，设备连上网络，你得先确认它是不是它自己，这叫认证；确认完了，还得管它能干什么、不能干什么，这叫授权。这两个环节要是没做好，设备身份管理就是空中楼阁。

我这些年看过太多项目，证书配得漂漂亮亮，结果授权策略一塌糊涂，设备上来就能互相乱访问。嗯，今天咱们就把这块彻底捋清楚。

4.1 设备接入认证协议：TLS 与 mTLS

设备接入认证，目前工业界最成熟的做法就是 TLS 和它的变种 mTLS。你可能会问，为什么不用简单的用户名密码？我举个例子你就明白了——你家里那台智能灯泡，你让它每次连接都输一次密码？不现实。设备认证需要的是无交互、自动化、高安全的机制。

4.1.1 TLS：单向认证就够了？

标准的 TLS 握手，其实只做了一件事：客户端验证服务器的身份。服务器出示证书，客户端校验证书链。这在 Web 场景下完全够用——你访问银行网站，银行需要证明自己是银行，但银行不需要验证你是谁（那是登录环节的事）。

但在 IoT 场景里，情况不一样。服务器也需要知道「对面那个设备是不是我授权的设备」。这时候，单向 TLS 就不够了。

4.1.2 mTLS：双向认证才是 IoT 的标配

mTLS（Mutual TLS）就是在标准 TLS 握手的基础上，增加了一步：客户端（设备）也必须出示自己的证书，由服务器验证。这样一来，双方都确认了对方的身份。

我在一个智能门锁项目里遇到过这种情况：设备端用了 mTLS，但有个批次的门锁证书签发时漏了扩展密钥用法（Extended Key Usage），结果服务器验证证书时直接拒绝连接。排查了整整两天才发现是证书模板配错了。所以啊，证书的每一个字段都不是摆设。

mTLS 的握手流程大致如下：

1. 客户端发起 ClientHello
2. 服务器回复 ServerHello + 服务器证书 + 请求客户端证书
3. 客户端验证服务器证书，然后发送自己的证书
4. 服务器验证客户端证书
5. 双方协商会话密钥，建立加密通道

4.1.3 证书验证的坑

光有证书还不够，验证逻辑必须做全。我列几个常见的踩坑点：

• 证书链验证不完整：有些实现只验证叶子证书，不验证中间 CA。攻击者可以伪造中间 CA 签发证书。
• 吊销检查缺失：证书被吊销了，但设备端没做 OCSP 或 CRL 检查，照样能连进来。
• 主机名验证跳过：证书里的 CN 或 SAN 和实际域名不匹配，但代码里没检查。

4.2 访问控制策略：设备能做什么？

认证通过之后，设备就获得了「入场券」。但入场之后它能访问哪些资源、执行哪些操作，这就是访问控制策略的事了。

4.2.1 基于角色的访问控制（RBAC）

RBAC 是最常见的模型。你把设备分成几个角色，比如「传感器」「执行器」「网关」「管理员设备」，然后给每个角色分配权限。

角色	可读资源	可写资源	可执行操作
传感器	无	/data/sensor/*	上报数据
执行器	/config/actuator/*	/status/actuator/*	执行指令、上报状态
网关	/config/gateway/*	/data/forward/*	转发数据、管理子设备
管理员设备	所有	所有	所有操作

RBAC 的好处是简单、直观。但缺点也很明显——角色一旦多了，权限矩阵会变得非常复杂。我见过一个项目定义了 50 多个角色，最后没人搞得清楚每个角色到底能干什么。

4.2.2 基于属性的访问控制（ABAC）

ABAC 更灵活。它不依赖固定的角色，而是根据属性来做决策。属性可以是设备类型、地理位置、时间、固件版本、安全等级等等。

举个例子：

策略：允许传感器设备在 08:00-18:00 之间写入 /data/temperature，前提是固件版本 >= 2.1.0

这种策略用 RBAC 就很难表达，但 ABAC 可以轻松实现。我个人习惯在设备数量超过 10 万或者权限维度超过 3 个的场景下，优先考虑 ABAC。

4.2.3 策略执行点（PEP）与策略决策点（PDP）

不管用哪种模型，架构上都要把「策略执行」和「策略决策」分开。这是我在实际项目中反复强调的一点。

• PEP（Policy Enforcement Point）：部署在设备接入网关或 API 网关上，拦截请求，向 PDP 询问「这个请求允许吗？」
• PDP（Policy Decision Point）：集中式的策略决策服务，根据策略引擎计算并返回 Allow/Deny。

这样做的好处是：策略变更时只需要更新 PDP，不需要动每个网关节点。

4.3 动态权限管理：权限不是一成不变的

设备在运行过程中，它的「可信度」是会变化的。一台设备刚出厂时是可信的，但如果它运行了半年没升级固件，或者被检测到异常行为，它的权限就应该被动态调整。

4.3.1 基于信任评分的动态授权

我参与过一个工业物联网平台，给每个设备维护一个信任评分。评分维度包括：

• 固件是否最新
• 证书是否即将过期
• 最近 24 小时是否有异常流量
• 是否在预期地理位置

信任评分高的设备，可以访问敏感数据；评分低的设备，只能访问基础资源。评分可以实时计算，也可以定时更新。

4.3.2 会话级权限与令牌刷新

设备认证通过后，通常会拿到一个访问令牌（Access Token）。这个令牌的有效期不能太长。我建议：

• 常规设备：令牌有效期 1-2 小时
• 高安全设备：令牌有效期 15-30 分钟
• 低功耗设备：可以使用长有效期令牌，但必须配合设备端安全存储

令牌过期后，设备需要用刷新令牌（Refresh Token）去换取新的访问令牌。刷新令牌本身也可以被撤销——一旦设备被标记为失陷，刷新令牌立即失效，设备就无法再获取新的访问令牌了。

4.3.3 权限的即时撤销

动态权限管理最难的一点是即时撤销。你发现某台设备被入侵了，怎么让它的权限立刻失效？

这里有几种做法：

1. 令牌黑名单：在 PDP 或 API 网关上维护一个黑名单，每次请求都检查令牌是否在黑名单中。缺点是增加延迟。
2. 短生命周期令牌：令牌有效期很短（比如 5 分钟），即使被窃取，影响范围也有限。缺点是设备需要频繁刷新令牌。
3. 事件驱动撤销：当设备被标记为失陷时，平台主动推送撤销事件到所有 PEP，让它们立即终止该设备的会话。

我个人比较推荐短生命周期令牌 + 事件驱动撤销的组合。前者控制风险窗口，后者提供紧急情况下的即时响应能力。

4.4 本章知识体系总览

下面这张图把认证、授权、动态权限管理的关系串起来了。你可以把它当作本章的「地图」——每次回顾时，先看这张图，再想细节。

从这张图可以看得很清楚：认证是入口，授权是规则，动态管理是持续运营。三者缺一不可。