📚 课程目录第3章设备身份与安全接入基础

3. 设备身份与安全接入基础

在 AWS IoT Core 中，设备身份不是靠用户名口令建立的，而是靠一套基于公钥基础设施（PKI）的证书体系。理解这套体系，是设备能安全接入、稳定上线的前提。本节从最基础的密钥对讲起，逐步串起 CSR、证书签发、AWS IoT 证书模式，最后落到可执行的安全实践。

一、密钥对：设备身份的根

每个接入 AWS IoT Core 的设备，都需要持有一对非对称密钥：私钥和公钥。私钥由设备自己生成并严格保密，公钥则可以公开。这对密钥的关系是：用私钥签名的数据，只有对应公钥能验证；用公钥加密的数据，只有对应私钥能解密。

在设备端，密钥通常由 OpenSSL 或硬件安全模块（如 ATECC608A、TPM）生成。以 OpenSSL 为例，生成一个 2048 位 RSA 私钥的命令是：

openssl genrsa -out device.key 2048

生成后，私钥文件 device.key 必须留在设备本地，绝不能上传到云端或写入代码仓库。公钥可以从私钥中导出：

openssl rsa -in device.key -pubout -out device.pub

私钥一旦泄露，攻击者就能冒充该设备接入 AWS IoT Core，因此私钥的保护等级直接决定了设备身份的安全边界。

二、证书签名请求（CSR）：把公钥交给 CA

设备有了密钥对之后，不能直接拿公钥去连接 AWS IoT Core，而是需要一张由受信任的证书颁发机构（CA）签发的 X.509 证书。设备通过生成证书签名请求（CSR）来申请这张证书。

CSR 的核心内容是：设备的公钥 + 设备主体信息（如 Common Name、Organization 等）。设备用私钥对 CSR 签名，证明自己确实持有对应的私钥。生成 CSR 的命令如下：

openssl req -new -key device.key -out device.csr \
  -subj "/CN=thermostat-001/O=SmartHome/C=CN"

这里 CN=thermostat-001 是设备标识，建议与 AWS IoT 中的 Thing Name 保持一致，便于后续管理。CSR 生成后，设备把 device.csr 提交给 CA。CA 验证请求后，用 CA 自己的私钥对 CSR 中的公钥和主体信息签名，生成 X.509 证书返回给设备。

在 AWS IoT Core 中，有两种常见的证书签发路径：一是使用 AWS IoT 自带的 CA（即 AWS IoT 证书模式），二是使用企业自建的 CA 或第三方 CA，再通过注册 CA 证书的方式接入。前者适合快速起步，后者适合已有 PKI 体系的企业。

三、AWS IoT 证书模式：一键签发与激活

AWS IoT Core 提供了一套内置的证书管理能力。在控制台或 CLI 中创建证书时，AWS IoT 会直接生成密钥对和证书，并返回三个关键文件：设备证书、私钥、以及可选的根 CA 证书。例如使用 CLI：

aws iot create-keys-and-certificate \
  --set-as-active \
  --certificate-pem-outfile device.crt \
  --public-key-outfile device.pub \
  --private-key-outfile device.key

执行后，device.crt 是设备证书，device.key 是私钥，device.pub 是公钥。注意：私钥只在创建时返回一次，必须立即保存到设备安全存储中，之后无法再次下载。

证书创建后默认处于 PENDING_ACTIVATION 状态，需要显式激活才能用于连接。激活命令为：

aws iot update-certificate \
  --certificate-id <certificateId> \
  --new-status ACTIVE

激活后，还需要把证书附加到 Thing 和策略上，设备才能真正发布/订阅消息。整个链路可以概括为：密钥对 → CSR/证书签发 → 证书激活 → 附加策略 → 设备连接。

四、证书附加与策略绑定

证书激活后，还需要完成两步绑定。第一步，把证书附加到 Thing 上，建立“设备—证书”的对应关系：

aws iot attach-thing-principal \
  --thing-name thermostat-001 \
  --principal arn:aws:iot:cn-north-1:123456789012:cert/<certificateId>

第二步，把策略附加到证书上，定义该设备能做什么：

aws iot attach-policy \
  --policy-name ThermostatPolicy \
  --target arn:aws:iot:cn-north-1:123456789012:cert/<certificateId>

策略示例（仅允许发布温度数据、订阅控制指令）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Publish",
      "Resource": "arn:aws:iot:cn-north-1:123456789012:topic/devices/thermostat-001/telemetry"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Subscribe",
      "Resource": "arn:aws:iot:cn-north-1:123456789012:topicfilter/devices/thermostat-001/commands"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Receive",
      "Resource": "arn:aws:iot:cn-north-1:123456789012:topic/devices/thermostat-001/commands"
    }
  ]
}

注意：iot:Subscribe 作用于 topicfilter，iot:Receive 作用于实际 topic，两者需要同时授权，设备才能收到消息。

五、安全最佳实践

证书体系搭起来之后，真正决定安全水平的是日常实践。以下几条是工程中最容易踩坑、也最值得优先落实的：

私钥不出设备：私钥应在设备端生成，或通过安全通道注入后立即写入 HSM/TPM/安全元件。禁止把私钥放在文件系统明文、代码仓库或云端可下载位置。
一设备一证书：不要多台设备共用同一张证书。共用证书会导致无法单独吊销、无法追溯来源，一台设备被攻破会波及全部。
最小权限策略：策略按设备粒度编写，只开放必要的 Topic 和操作。避免使用 iot:* 或 Resource: "*"。
证书轮换与吊销：为证书设置合理的有效期（如 1 年），建立到期前自动轮换机制。设备退役或私钥疑似泄露时，立即吊销证书并更新策略。
启用日志与监控：开启 AWS IoT 日志，将连接、发布、订阅事件写入 CloudWatch，对异常连接频率、异常 Topic 访问设置告警。
传输层安全：设备连接必须使用 TLS 1.2 及以上，并校验服务器证书，防止中间人攻击。

在测试阶段，可以用 aws iot describe-certificate 查看证书状态、有效期和关联的 Thing；用 aws iot list-principal-things 反查某张证书绑定了哪些设备，便于排查“证书已激活但设备连不上”的问题。

把上述链路串起来看：设备生成密钥对 → 通过 CSR 或 AWS IoT 内置 CA 获得 X.509 证书 → 激活证书 → 附加 Thing 与策略 → 使用 MQTT over TLS 连接。每一步都有明确的输入、输出和状态判断依据，任何一步缺失或配置错误，都会导致设备无法接入或权限不足。掌握这条链路，后续的批量注册、动态注册和证书轮换才有稳定的基础。