8.1 物联网安全概述
8.1.1 物联网安全威胁全景图
物联网设备的安全短板，不只属于设备所有者，还会反噬整个公网。从弱口令扫描到协议栈漏洞，再到 AI 模型的新型攻击，攻击者往往只需找到一个薄弱环节就能撬动整条链。理解威胁，是设计防御的起点。这一节从攻击面出发，分层梳理物联网系统面临的安全威胁。
从攻击面看威胁分布
物联网系统从终端设备到云端应用，大致分为感知层、网络层、平台层和应用层。每一层都有其特定的攻击向量。
感知层（设备与传感） 面临的威胁最直接。攻击者可以物理接触设备，通过调试接口（JTAG/SWD）读取固件，或直接撬开外壳替换存储芯片。对于没有防拆机制的设备，物理访问等于完全控制。主流攻击手段是弱口令扫描——它不依赖高端技术，靠的是设备出厂配置的“不设防”：默认管理员账户、无密码过期、不限制尝试次数。2016 年暴发的 Mirai 僵尸网络正是靠扫描这类默认口令感染了约 60 万台摄像头和路由器，并驱使这些设备对 DNS 服务商发起 DDoS，造成大范围互联网服务中断（如何从网络架构上遏制这类蠕虫式扩散，8.3.3 还会回到这个案例）。安全启动机制正是为了应对这类威胁——从 Bootloader 逐级校验固件签名，签名不对就拒绝运行，把恶意固件挡在启动之前。
网络层（通信链路） 把设备数据送到平台，中间可能经过 Wi-Fi、ZigBee、LoRaWAN 或蜂窝网络。每一跳都给了攻击者窃听、篡改或重放的机会。未加密的通信链路尤其脆弱，攻击者可以在网关附近部署嗅探器，直接把传感器数据和设备指令抄走。这正是 DTLS 被选为 CoAP 安全基座的原因——面对 UDP 的不确定性，DTLS 通过记录层对数据报逐个做完整性校验，防止了报文拼接重放的常见手法。但工程上，完整 TLS 握手的非对称运算和证书链对小设备仍是负担，因此出现了 TLS-PSK（预共享密钥，Pre-Shared Key，PSK）、会话复用、更轻的椭圆曲线算法等折中方案。
平台层（云端/边缘） 的风险更像传统的 Web 安全：弱认证、越权访问、API 未经限流。差异在于，IoT 平台背后连着物理设备——一个越权请求不只是“看到不该看的数据”，而是“关掉不该关的阀门”。多租户场景下更要把隔离做严：有读设备权限的用户，不代表能读别家租户的设备数据。授权模型通常采用 RBAC，把主体、角色、资源绑起来，并坚持最小权限与 fail-closed 原则——查不到权限就拒绝，绝不默认放行。
应用层（用户界面与业务逻辑） 的威胁包括 Web 后台的 XSS、移动端的不安全存储，以及 AI 模型引入的新攻击向量。随着大语言模型被接入运营流程——比如通过 Tool-Calling 让模型读写设备位号、执行命令——Prompt 注入和越狱攻击也成了新的现实问题。威胁在于：当模型能够通过 Tool-Calling 向 MQTT Broker 发送 stop 指令时，一次 Prompt 注入的后果就不再是“吐出不该说的词”，而是物理世界的停摆。此处仅对 AI 安全威胁进行分类，具体的 Prompt 注入过滤、输出校验、Tool-Use 权限沙箱等防护措施，将在本章 8.5 节展开。
威胁分类图
这张图清晰地表达了物联网安全的“多层面”特征：攻击者通常不会只在一个点上操作。典型攻击路径是从设备侧弱口令切入，控制设备发起网络层 DDoS；协议栈漏洞则利用实现缺陷，影响从前端到后端的整条链路。
威胁演进趋势
传统上，工控与物联网安全的核心威胁是物理攻击和网络渗透。但几个明显的趋势正在改变这一格局。
协议漏洞成为高发区。 轻量级协议本身设计简洁，但实现中往往省略安全检查。例如，CoAP 实现若未校验消息 ID 的单调递增性，攻击者可能通过重放旧 ACK 报文干扰连接状态；MQTT 的遗嘱消息特性若未加约束，可能被中间人利用篡改。这类攻击不依赖加密破解，只靠协议逻辑缺陷。
供应链成为薄弱环节。 设备制造商将固件、SDK、协议栈从第三方引入时，可能连带携带已知漏洞。此类漏洞影响范围广泛，而厂商从漏洞公布到收到事件通知、再到推送升级包，响应周期通常严重滞后。测试环节也往往不够严格——端口扫描和渗透测试工具可以检测 Telnet、FTP、Finger、TFTP 等关键服务是否暴露，但很多设备的出厂测试并不包含这些检查。
AI 引入的新攻击面不可忽视。 模型注入、数据投毒、Prompt 越狱，这些攻击利用的是模型推理过程中的脆弱性，而非外围防护的缺失。当模型通过 Tool-Calling 访问平台资源时，它代表的是某个用户账号进行操作。这就意味着，模型能看到、能动的，绝不能超过这个账号本身的权限——跨租户的数据，对 AI 也必须是看不见的。这项约束在多租户系统里是硬约束，不是可选项。
从威胁到防御的逻辑起点
前面所有威胁有一个共同特征：它们依靠的是“默认不安全”的设计假设——设备没有唯一信任根、通信链路没有内置加密、平台不校验调用方的租户归属、AI 模型不对输入做约束。这正是安全设计要逐一修正的假设。
防御不是消灭所有威胁——工程上做不到、资源上不划算。防御是让攻击者在跨过每一层时都付出足够高的代价，让他停下脚步。从这个角度看，图8-1 也是“纵深防御”的平面投影：每一层都意味着一次拦截的机会。
8.1.2 安全原则与防护策略
物联网安全的起点不是选什么加密算法，而是建立一套贯穿系统全生命周期的设计原则。这些原则回答的是更底层的问题：防什么、防到什么程度、失守之后怎么办。缺乏原则约束的“安全”往往是散点补丁——今天封一个端口，明天修一个固件，后天升级一个协议，却没有统一的防御基线。
纵深防御：多层布防，不押注单点
纵深防御（Defense in Depth）的核心假设很简单：任何一层都可能迟早失守。防火墙可以被绕过，加密算法可能被爆破，固件签名可能被绕过——所以要在不同层面重复布防，让攻击者即便突破第一道防线也进不了第二道。
典型的物联网纵深防御覆盖从物理安全到应用安全的多个层面：
- 物理安全：防拆开关、安全元件（Secure Element, SE）、可信执行环境（Trusted Execution Environment, TEE）、锁定的调试接口。设备如果防不住物理接触，其上所有软件层防护都不可靠。
- 设备固件安全：安全启动（Secure Boot）、强制OTA签名校验，挡住“刷入恶意固件”这条路径。
- 通信安全：TLS/DTLS加密隧道、双向证书认证、防重放机制。即使攻击者能接入网络，也无法窃听或冒充。
- 身份与访问控制：JWT令牌、OAuth 2.0、RBAC权限模型。只有持有合法凭证的主体才能获取相应资源。
- 平台安全：多租户隔离、审计日志、速率限制。单个租户的漏洞不会扩散到全局。
- 数据安全：存储加密、字段级脱敏。数据库泄露之后，数据本身仍有加密保护。
- 应用与AI安全：大模型接入带来的新攻击面，如模型注入攻击、提示词劫持等。此处的威胁分类仅作为安全基线的一部分，具体防护措施在本书后续章节展开。
层与层之间相互补充，但不相互依赖——这种安排称为补偿控制（compensating control）。例如，设备侧缺乏SE/TEE硬件信任根时，可以用更强的通信认证（如PSK与证书绑定的混合方案）来补偿；网络层加密力度不够时，可以在平台侧增加重放检测和异常流量告警。补偿控制是纵深防御在资源受限场景下最实际的工程权衡。
最小权限与默认安全
最小权限原则（Principle of Least Privilege）要求每个主体只拥有完成任务所必需的最少权限——不多给一台设备、一个用户、一条进程。RBAC模型把主体、角色和资源显式绑定，并坚持 fail-closed：查不到权限就拒绝，绝不默认放行。这条约束同样适用于设备：传感器只需发送上行遥测数据，就不应开放下行命令通道；边缘网关需读写多个位号，但不该有管理控制台的访问权限。
默认安全（Secure by Default）则要求系统在出厂状态的配置就是安全的：不安全的服务（Telnet、FTP）默认关闭，非必要端口不予开放，弱密码强制修改。典型事件反复暴露的正是“出厂即带Telnet、默认管理员账户且无任何密码策略”这类配置。行业共识是：默认全拒绝，按需放行。只有经过显式配置规则之后，才允许设备接入和权限分配，而不是先全部开放、等审计再打补丁。
安全开发生命周期：把安全左移
安全不是某个阶段“加上去”的。把安全机制嵌入软件开发的每一个环节，这条路称为安全开发生命周期（Secure Development Lifecycle, SDL）。
- 需求阶段：做威胁建模。画出系统的数据流图（DFD），标记每个交互点可能存在的威胁，用STRIDE模型（仿冒、篡改、抵赖、信息泄露、拒绝服务、权限提升）分类，然后决定各层应采取何种防护策略。
- 设计阶段：做架构安全评审。有无单点故障？加密是否端到端？认证是否是双向的？有没有防回滚机制？
- 开发阶段：遵循安全编码规范，使用安全函数库，不在源码中硬编码密钥或凭据。
- 测试阶段：自动化静态代码分析（SAST）和动态安全测试（DAST）；手动执行渗透测试，对照物联网安全排查清单逐一验证。
- 部署与运维阶段：持续跟踪漏洞公告，及时推送安全更新；保留审计日志，定期复盘安全事件。
安全成本因发现时机而大不相同。威胁建模阶段发现并修复一个架构缺陷，可能只需要修改几页设计文档；等设备出厂成千上万台之后才发现固件中存在命令注入漏洞，单次OTA升级的成本与时间投入相比前期修复差距显著。SDL做得好，不只是为了“通过合规审查”，更是从工程经济学角度看最明智的投资。
持续监控与响应
隔离和加密能挡住多数通用攻击，但零日漏洞或高级持续性威胁仍然可能穿透层层防御。安全策略的最后一环是持续监控与威胁响应。
物联网环境下，监控不是“收到告警就打给运维”。推荐用三层降噪机制，把原始告警收敛为可处置的事件：
- 去抖动：单个越界或单次失败指令不做告警，连续一段时间内同类异常发生预定次数以上才触发——过滤掉一次网络抖动或瞬时干扰。
- 状态机：把告警划分为“触发→确认→恢复→关闭”四个状态，配合活跃连接保活与遗嘱消息机制，避免设备因网络波动反复触发误报。
- 分级与聚合：按紧急程度分级，紧急事件（如数据泄露、设备沦陷）要求尽快响应；严重事件（如批量认证失败、证书过期）要求在较短时间内处理；常规事件（如单设备断连、端口扫描）归入日报。同类型、同时间段、同区域的告警聚合成一条事件记录，而不是一条报文弹一次窗口。
响应策略应优先自动化：探测到恶意IP扫描特定端口时，自动在防火墙上加黑名单；发现设备固件签名校验失败，自动将该设备隔离、切断对外通信，同时推送通知给运维人员。这和纵深防御中的“阻断”能力遥相呼应——发现异常，先按预设策略阻断，事后审计补流程。
核心原则速查
表8-1 物联网安全核心原则速查
| 原则/策略 | 核心思想 | 工程落地举例 | 典型适用场景 |
|---|---|---|---|
| 纵深防御 | 多层布防，不依赖单点 | 物理加密 → TLS → 身份认证 → 应用安全 | 高价值设备、关键基础设施、远程运维 |
| 最小权限 | 只给必需权限，fail-closed | RBAC模型、传感器仅上行、不开放下行 | 多租户平台、权限复杂的工厂产线 |
| 默认安全 | 不安全的功能出厂即关闭 | 禁用Telnet/FTP、缺省密码首次必须修改 | 消费级IoT设备、新人入驻平台 |
| 安全开发生命周期 | 安全左移，全流程嵌入 | 威胁建模、SAST/DAST、OTA签名验证 | 新产品设计、合规认证场景 |
| 持续监控与响应 | 实时检测 → 降噪 → 阻断 → 审计 | 去抖动告警、状态机分级、自动IP黑名单 | 日百万级消息的IoT平台、无人值守数据中心 |
表8-1每项原则都有它的适用边界。极少出现“所有原则在所有设备上都做到极致”的情况——约束来自成本、算力、功耗和投产周期。工程师可以该表为基础，在项目初期做一次设计评审：系统布置了多少层防御？设备权限是否收得够紧？出厂默认配置是否安全？监控响应延迟是否符合业务容忍度？回答这些问题之后再进入具体技术实现，比边做边调要有效得多。
上述原则与行业公认的安全指南（如NIST IoT安全框架、IEC 62443系列）在制定安全基线时的方向一致，都将纵深防御、最小权限和默认安全列为起点。不同行业的规范条文可能有差异，但底层逻辑相通：安全不是单一产品的特性，而是需要贯穿系统全生命周期的一整套策略安排，任何一个环节的缺失都会成为整个系统的短板。
8.1.3 安全法规与合规要求概述
前两节从威胁和原则切入，勾勒了物联网安全的设计边界。但安全方案落地时，还有一层外部约束——法规。它未必告诉你用哪种加密算法或认证协议，但会划出“必须保护什么”和“保护到什么程度”的底线。对工程团队来说，理解法规要求不只是法务部门的事——它直接影响系统架构、数据流向和产品上市周期。一个在设计阶段没考虑数据最小化原则的系统，上线后可能被迫重构数据存储模块，这种代价通常远超预埋合规设计的成本。
GDPR：以“个人数据”为中心
欧盟《通用数据保护条例》（General Data Protection Regulation, GDPR）是当前数据隐私领域最具影响力的法规体系之一。它不专门针对物联网，但物联网系统恰恰是个人数据的“生产大户”：智能家居收集生活习惯、可穿戴设备采集生理指标、车联网记录位置轨迹。只要设备处理的数据能直接或间接识别到个人——人脸图像、MAC地址、设备唯一标识——就落入GDPR的管辖范围。
GDPR对工程架构有几条直接影响。数据最小化原则要求系统只采集服务于明确目的的最小数据量。一个智能灯泡厂商如果同时采集WiFi信号强度和环境噪声，用户就有理由质疑：这些数据与“开灯”有关吗？用户同意与知情权要求数据采集前获得明确授权，且用户有权随时撤回。这意味着平台必须内建同意管理模块，并能向用户清晰展示“谁在什么时候、为什么、收集了什么数据”。数据泄露通知义务要求在规定时限内通知监管机构，这反过来要求系统具备实时审计和告警能力——不知道数据何时出了边界，就无法计算通知时限从哪算起。
GDPR最有冲击力的条款之一是被遗忘权（Right to Erasure）：用户要求删除其个人数据时，系统必须彻底清除所有副本，包括备份中的碎片。这对物联网的分布式数据存储是一个真实的工程挑战——数据可能同时落在端侧缓存、边缘节点、云数据库和数据仓库中，删除需要跨层协调。设计不当的系统可能根本无法执行完整的删除操作，最终成为合规缺陷。多个项目的经验表明，团队在设计阶段常把这个需求推迟到“后续优化”，结果等测评时才发现备份中的残留数据根本删不干净。
等保2.0：物联网安全的国家标准
在中国，网络安全等级保护制度2.0（等保2.0）扩展到了物联网场景。它的核心思想是将系统按受侵害后的危害程度分为五级，每一级有对应的安全要求和测评标准。涉及物联网的部分，主要依据GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》中的物联网安全扩展要求。等保2.0对物联网有几个重点覆盖面：感知层设备安全要求设备具备身份标识、防篡改和固件校验能力；网络通信安全要求传输加密和接入认证，星型拓扑中汇聚节点（网关）必须防止被用于横向攻击；数据安全关注采集、传输、存储各环节的机密性和完整性，以及个人信息保护措施的落实情况。
对于在国内运营物联网平台的企业，等保2.0是合规审查的强制门槛。工程团队需要在系统设计阶段就对照各安全等级的要求，而非在测评前临时“补课”——后者的改造成本通常是指数级上升。值得注意的是，等保2.0对物联网的定级在实际测评中常遇到边界问题：比如一个设备同时连接云端和本地管理平台，其安全等级应当依照哪个系统定级？这些判断需要架构师在早期就与测评机构对齐。
行业特定法规：医疗与工业
不同行业有各自的监管框架。医疗物联网系统若由 HIPAA 受监管实体或其业务伙伴处理电子受保护健康信息，需要落实行政、物理和技术保障，包括访问控制、审计、完整性、身份认证和传输安全。现行 HIPAA Security Rule 中的加密属于“可寻址”实施规范：组织必须基于风险判断其是否合理适当；不采用时要记录理由并实施等效措施，不能简单写成所有静态与传输数据都被法律无条件强制加密。工业控制系统则常以 IEC 62443 系列标准建立安全生命周期、区域与通道、访问控制以及组件安全要求。跨行业平台应在适用主体、数据类型和司法辖区明确后，再把合规要求映射到租户与系统控制。
欧盟新规：CRA、《数据法案》与 NIS2
欧盟近年的三部立法对物联网的约束正在从数据处理延伸到产品本身，面向欧盟市场交付的团队需要单独跟踪。《网络弹性法案》（Cyber Resilience Act, CRA）已于 2024 年 12 月生效，与 GDPR 不同，它直接管产品：IoT 网关、边缘盒子、平台软件都落在“带数字元素的产品”范围内。时间线分两步——2026 年 9 月 11 日起，被积极利用的漏洞与严重事件必须按规定上报；2027 年 12 月 11 日起全面义务生效，制造商须在声明的安全支持期内持续提供安全更新，并随产品维护 SBOM。这与本章 8.2.4 的设备生命周期治理和 SBOM 实践是同一件事的法规面。《数据法案》（Data Act）自 2025 年 9 月 12 日起适用，赋予联网产品的用户访问并共享其使用所产生数据的权利——智能家居与车联网平台需要为此提供数据导出与共享接口。此外，网络与信息安全指令 NIS2 的成员国转置截止于 2024 年 10 月，把更多数字基础设施运营者纳入风险管理事件报告义务。
合规检查清单：从法规到工程动作
法规条款纷繁，落到工程上需要一张检查清单来逐项验证。下表综合了GDPR、等保2.0和行业法规的通用要求，为架构师和开发者在系统设计阶段的合规自查提供起点——它不替代专业的法律评估，但能帮团队把抽象条款映射成可执行的工程检查项。
表8-2 合规检查清单
| 安全域 | 检查项 | 对应法规 |
|---|---|---|
| 设备安全 | 设备具备唯一身份标识，支持固件签名校验与安全启动 | 等保2.0、IEC 62443 |
| 通信安全 | 传输通道采用加密协议，完成双向认证，具备防重放机制 | 等保2.0、HIPAA |
| 数据安全 | 明确个人数据采集范围，设计实时删除机制（被遗忘权） | GDPR、等保2.0 |
| 身份与访问控制 | 默认拒绝策略，基于角色的细粒度权限管理，支持审计日志 | 等保2.0、IEC 62443 |
| 运营与审计 | 具备实时数据泄露检测与告警能力，满足法规规定的通知时限 | GDPR、等保2.0 |
这份清单不是一个完整体检工具，但它揭示了工程团队在系统设计阶段必须回答的一组问题：系统存储了哪些个人数据？能否在必要时彻底删除？敏感数据在传输和存储中是否加密？谁有权访问什么数据——这个权限是默认放行还是默认拒绝？等到产品上线才回答这些问题，代价远高于设计阶段就把它们写进架构文档。
法规合规不是加分项，而是市场准入的前提条件。更重要的是，好的安全性设计往往天然接近合规要求——加密、审计、最小权限这些工程要素，在法规框架里都能找到对应条款。下一节从设备身份开始，逐层落实这些工程实践。
8.1.4 NIST AI RMF：把 Agent 风险纳入治理闭环
传统安全控制常从漏洞、身份和网络边界出发，但 Agent 风险还取决于使用场景、工具权限、自主度和物理后果。同一个模型用于生成周报与用于提交设备命令，风险等级完全不同。NIST AI Risk Management Framework（AI RMF 1.0）用 GOVERN、MAP、MEASURE、MANAGE 四个函数组织 AI 风险管理；其中 GOVERN 贯穿其他函数，适合把零散控制连接成持续治理闭环（NIST AI RMF）。AI RMF 是自愿性风险管理框架，不应写成强制法规或产品认证。
GOVERN：先明确谁能决定系统放权
治理层建立责任、政策和证据要求。组织应维护 AI 资产清单，记录模型、Prompt、RAG 索引、Tool、权限策略、评测集和供应商版本；为每个场景指定业务责任人、安全责任人、发布审批人和事件处置人；定义只读、建议、受约束执行和禁止自动化等自主度等级。
禁止场景应在开发前写清，例如：LLM 不直接进入 PLC/SIS 实时安全回路，不自行批准不可逆动作，不在缺少租户身份时调用业务 Tool。模型或供应商变化也应进入变更管理，不能把相同模型 ID 视为行为永远不变。
MAP：把抽象模型放回真实物理场景
MAP 的目标是理解系统处境、相关方、影响与风险来源。AIoT 场景至少要映射：
- 输入数据来自用户、RAG、设备还是第三方系统；
- Agent 能看到哪些租户、设备和历史数据；
- Tool 是查询、业务变更、设备控制还是不可逆操作；
- 动作是否可撤回，失败会造成数据错误、停机还是人身风险；
- 哪些步骤需要人工或外部策略审批；
- 受影响的人、设备、产线和组织有哪些；
- 系统在断网、模型超时、数据陈旧和回执缺失时如何降级。
风险不能只按模型能力打分。一个精度一般但只读的问答助手，可能比一个回答更准确却拥有通用 HTTP/SQL 工具的 Agent 更安全。
MEASURE：把“可信”变成可检查证据
MEASURE 应引用第 7 章的 RAG Eval 和 Agent Eval，并加入安全红队、偏差、鲁棒性、隐私和可解释性检查。高风险 Agent 至少测量：跨租户越权、无审批写入、参数越界、间接 Prompt Injection、工具超时、拒答准确率、人工接管、重复副作用和停止指令生效率。
每项指标都应关联评测集、版本、阈值和原始 trace。没有完成测量的能力不能用“安全可控”概括；应明确写成未验证、试验性或禁止进入生产。
MANAGE：根据证据接受、降低或拒绝风险
管理层依据测量结果决定风险接受、缓解、转移或禁止。常见措施包括：影子流量、灰度租户、只读 Tool 先行、高风险外部审批、预算和步数限制、降级到 Copilot、停用特定 Tool、回退模型/Prompt/索引，以及触发 kill switch。
事件发生后，应保存输入、检索证据、Tool 目录、参数摘要、权限决策、Action、回执、最终状态和版本 manifest，用于复盘和复评。修复一次 Prompt 不能替代治理；同类风险应回写威胁模型和回归集。
表8-3 Agent 风险控制与证据对应示例
| 风险 | 控制 | 指标 | 证据 | 责任人 |
|---|---|---|---|---|
| 跨租户数据读取 | 四元授权与检索过滤 | 越权率=0 | 策略日志与攻击集 | 平台安全负责人 |
| 高风险写操作 | 外部审批与 Action 确认 | 无审批执行率=0 | Action、回执与 trace | 业务责任人 |
| 过期知识 | 版本过滤与时间有效性 | 过期文档误命中率 | RAG Eval 结果 | 知识负责人 |
| 模型/Tool 变更 | 版本 manifest 与回归门 | 回归通过率 | 发布记录 | AI 发布负责人 |
| 循环与成本失控 | 步数/时间/金额预算 | 超预算率 | trace 与成本账单 | 运行负责人 |
四个函数不是线性的一次性流程。场景变化要重新 MAP，版本更新要重新 MEASURE，事故和评测结果会推动 MANAGE，治理策略再由 GOVERN 更新。这套框架的价值不在于宣称“采用了某个模型”，而在于把风险、控制、指标、证据和责任人之间的对应关系沉淀为可审计的文档与流程——出了事，能够回答“谁在什么证据下做了什么决定”。