📚 课程目录第3章身份与访问管理（IAM）

3. 身份与访问管理（IAM）：零信任身份基石

零信任的核心逻辑，说白了就是一句话：不再信任网络位置，只信任身份。在边缘网关这个场景下，这句话的分量尤其重。你想想看，一个部署在工厂车间、路边机柜或者无人值守站点的网关，它的物理安全几乎为零——谁都能摸到设备，插个U盘、接个串口，甚至直接把网线拔了怼到自己电脑上。

那靠什么守住防线？靠身份。我个人的习惯是，在做边缘网关安全设计时，第一件事就是把「身份」这个概念从「人」扩展到「设备」和「服务」。人有人证，设备有设备证，服务有服务证。三证齐全，才能放行。

3.1 零信任身份基石：从「你是谁」到「你凭什么」

传统IAM解决的是「你是谁」——用户名密码对不对？零信任IAM要解决的是「你凭什么」——你当前的设备可信吗？你的访问上下文安全吗？你的行为模式正常吗？

我在一个智慧能源项目中遇到过这样的情况：运维人员用合法账号登录了边缘网关，但登录地点突然从国内跳到了海外，时间在凌晨3点，而且登录后立刻尝试修改防火墙规则。传统IAM会放行，因为密码是对的。但零信任IAM会立刻阻断，因为「上下文」不对。

边缘网关的IAM架构，我建议至少包含三层：

层级	核心能力	边缘侧实现要点
身份层	用户、设备、服务的统一身份注册与生命周期管理	本地身份库 + 云端同步，离线可认证
认证层	多因素认证、证书认证、生物特征认证	轻量级认证栈，支持硬件安全模块（HSM）
授权层	基于属性的访问控制（ABAC）、动态策略评估	策略本地缓存，断网不降级

核心原则：边缘网关的IAM必须支持「离线认证」能力。网络断了，认证不能断。本地身份库和策略缓存是底线。

3.2 多因素认证（MFA）在边缘设备上的实现

MFA在云端已经很成熟了——短信验证码、TOTP、推送通知。但到了边缘设备上，事情就没那么简单了。边缘网关通常没有手机信号，没有互联网连接，甚至没有显示屏。你怎么让用户输入第二个因素？

我踩过这个坑。早期一个项目里，我们直接在边缘网关上部署了标准的TOTP方案，结果现场运维人员反馈：网关没有键盘，只有几个物理按键，输入6位数字验证码要按半天，用户体验极差。后来我们改成了「硬件令牌 + 本地PIN码」的方案，才算解决问题。

边缘设备上MFA的常见组合方式：

第一因素：用户名 + 密码（或PIN码）
第二因素（按场景选择）：
- 硬件令牌（FIDO2/U2F）：USB插入即认证，适合有USB接口的网关
- TOTP离线码：预生成一批一次性备用码，打印出来贴在设备内部
- 本地生物特征：指纹模块（成本较高，适合高安全场景）
- 近场验证：运维手机通过蓝牙/NFC与网关交互，手机端完成MFA

实战建议：如果边缘网关资源受限（比如只有几百KB的Flash），不要跑完整的TOTP算法。可以预置一个「挑战-响应」表，网关每次随机选一个序号，运维人员从备用码表中找到对应值输入。简单、可靠、零计算开销。

代码示例：边缘网关上的轻量级挑战-响应认证实现片段

// 预置挑战-响应表（出厂时写入，每个设备唯一）
const challengeTable = [
  { id: 0, challenge: "A3F9", response: "7C2E" },
  { id: 1, challenge: "B1D4", response: "9A8F" },
  // ... 共20-50条
];

// 认证流程
function authenticate(challengeId, userResponse) {
  // 1. 查找挑战记录
  const record = challengeTable.find(c => c.id === challengeId);
  if (!record) return false;

  // 2. 验证响应
  if (record.response !== userResponse.toUpperCase()) return false;

  // 3. 使用后立即失效（防止重放）
  record.used = true;
  return true;
}

3.3 基于证书的设备身份认证

设备身份认证，是边缘网关零信任里最容易被忽视、但又最关键的一环。人可以用密码+MFA，但设备怎么证明「我是我」？

答案是：证书。每个边缘网关在出厂时，内置一个唯一的设备证书，私钥存储在硬件的安全元件（Secure Element）或TPM芯片中。这个证书就是设备的「身份证」，任何设备间的通信、设备到平台的连接，都基于这个证书做双向TLS认证。

我曾经处理过一个事故：某客户现场，攻击者把一台伪造的边缘网关接入了网络，试图冒充合法设备上报假数据。幸好我们的设备认证机制做了「证书吊销列表（CRL）实时同步」，那台伪造设备的证书序列号早在CRL里了，连接直接被拒绝。事后复盘，如果当时只用IP或MAC地址做设备识别，后果不堪设想。

设备证书的生命周期管理，我建议按这个流程走：

证书签发：设备出厂时，由工厂CA签发设备证书，写入安全芯片
证书分发：设备首次上电联网后，向管理平台注册，平台记录证书指纹
证书验证：每次通信前，双向TLS握手，验证对方证书链和有效期
证书更新：证书到期前，设备自动向CA发起续期请求（需用旧证书签名）
证书吊销：设备报废或失窃后，管理员在平台吊销证书，CRL同步到所有网关

注意：边缘网关的证书私钥必须硬件保护。如果私钥以文件形式存储在Flash里，攻击者物理拆机后可以直接读取。至少要用TPM芯片，预算允许的话上独立SE（安全元件）。

下面这张图展示了边缘网关设备身份认证的核心流程：

嗯，这里要注意一个细节：边缘网关的证书续期机制。很多设备部署后三五年没人管，证书过期了，设备直接断连。我建议的做法是：证书有效期设短一些（比如90天），但允许设备在证书到期前30天自动发起续期。续期请求用旧证书签名，平台验证通过后签发新证书。这样即使设备长期离线，也有一个月的缓冲窗口。

避坑指南：我曾经遇到过设备证书续期时，因为网关和平台的时间不同步，导致签名验证失败。解决方案是在证书续期请求中带上设备当前时间戳，平台用这个时间戳做验证窗口（±5分钟），而不是依赖TLS时间。这样即使NTP服务不可用，续期也能正常完成。

最后总结一下身份与访问管理在边缘网关上的三个核心动作：

统一身份模型：把人、设备、服务都纳入同一个身份域，用证书和MFA双重锁定
离线优先设计：所有认证和授权逻辑在本地可独立运行，不依赖云端
硬件根信任：私钥和敏感数据必须由安全芯片保护，软件层面的安全是脆弱的

这三件事做好了，边缘网关的身份防线才算真正立起来。下一层，我们要聊的是「动态访问控制」——身份认证通过之后，怎么精细控制每个设备能做什么、不能做什么。