2. 物联网架构与攻击面
物联网安全面试中，只要面试官问出“你怎么理解物联网的攻击面”，本质上是在考察一件事：你能否把一套跨物理与数字的复杂系统，拆成可讨论、可定位、可验证的安全边界。四层架构——感知层、网络层、平台层、应用层——是最通用的拆解方式。但仅仅背出“感知层有节点劫持、网络层有中间人攻击”并不够，面试官更想听到的是：每一层的关键资产是什么、攻击者从哪个入口进入、进入后能造成什么后果、防御的抓手在哪里。下面按层展开，并在每层中穿插面试表述的要点与常见追问。
感知层：物理世界的入口，也是信任链的起点
感知层由传感器、执行器、RFID标签、摄像头、PLC/RTU等现场设备组成，它们直接与物理世界交互。这一层最核心的安全矛盾是：设备通常资源受限（算力、存储、电量有限），却往往部署在攻击者物理可达的位置。关键风险可以归为四类。
第一类是物理暴露与侧信道。例如，攻击者通过UART、JTAG、SWD等调试接口直接读取固件或提取密钥。面试中如果被问到“拿到一个智能门锁你怎么分析”，可以这样表述：先识别主控芯片型号，检查调试接口是否被熔断或禁用；若未禁用，尝试通过调试口读取Flash，提取固件后用binwalk分析文件系统，寻找硬编码密钥或调试后门。防御抓手是：量产阶段熔断调试接口、启用安全启动、对固件加密。
第二类是弱口令与默认凭证。Mirai僵尸网络的核心利用方式就是Telnet/SSH默认账号密码。面试表述可以具体到：设备出厂默认admin/admin或root/root，且无强制修改机制；攻击者扫描23/22端口后批量尝试。防御上应强制首次配置修改密码，或采用一机一密。
第三类是固件与供应链风险。固件更新若未做签名校验，攻击者可通过中间人替换固件包。面试中可提到：检查OTA更新是否使用HTTPS且校验数字签名，若仅靠MD5校验则存在被篡改风险。
第四类是协议与无线接口风险。BLE、Zigbee、LoRa等无线协议若配对机制薄弱，可被窃听或重放。例如BLE的Just Works配对无中间人保护，攻击者可在配对阶段截获密钥。
面试表述建议：不要只列风险，而是用“资产—入口—后果—控制”四要素串起来。例如：“感知层的核心资产是设备身份密钥和固件；入口包括调试口、无线配对和默认凭证；后果可能是设备被控或数据伪造；控制手段是安全启动、一机一密和固件签名。”
网络层：传输管道，也是横向移动的通道
网络层负责把感知层数据汇聚到平台，涉及协议包括MQTT、CoAP、HTTP、Modbus TCP、OPC UA等，以及蜂窝、Wi-Fi、LoRa等接入方式。这一层的安全风险集中在协议设计缺陷和网络暴露面。
以MQTT为例，这是物联网最常用的发布/订阅协议。面试中常被问“MQTT安全吗”。可以这样回答：MQTT本身支持TLS，但很多部署为了性能或兼容性使用明文1883端口；更关键的是主题（Topic）权限控制。如果Broker未做ACL，任何客户端都能订阅#通配符，从而窃取所有设备数据。实际配置中，应在Broker端为每个设备分配独立Client ID和用户名，并限制其只能发布/订阅自己的主题，例如device/001/telemetry，禁止订阅device/+/telemetry。
另一个典型是Modbus TCP。它设计之初无认证无加密，攻击者只要网络可达就能读写寄存器。面试中可提到：在工控场景中，若Modbus TCP直接暴露在办公网，攻击者可通过功能码0x05写单个线圈强制设备启停。防御上应做网络分段，用工业防火墙限制源IP和功能码。
网络层还有一个高频考点是中间人攻击。以ARP欺骗为例，攻击者在同一广播域伪造网关MAC，使设备流量经过攻击者。面试表述可以具体到：设备与平台之间若使用自签名证书且未做证书固定（Certificate Pinning），攻击者可用伪造证书解密TLS。防御抓手是启用双向TLS认证（mTLS）并固定平台证书指纹。
面试中若被追问“你怎么排查网络层异常”，可以给出可操作路径：在交换机上配置端口镜像，用Wireshark抓包，过滤mqtt或modbus，观察是否存在异常订阅、高频重连或非预期功能码。判断依据是：正常设备心跳间隔稳定，若出现秒级重连或大量CONNECT失败，可能正在被暴力破解。
平台层：数据汇聚与设备管理，权限与隔离是核心
平台层通常包括IoT Hub、设备管理、规则引擎、数据库和API网关。这一层的关键资产是设备身份、数据流和规则配置。风险集中在身份认证、越权访问和多租户隔离。
设备接入平台时，常见方式是使用设备证书或密钥。若平台仅用静态Token且无过期机制，Token泄露即可冒充设备。面试中可提到：应采用短期凭证加刷新机制，或使用X.509证书做双向认证。例如AWS IoT Core要求设备用证书连接，并绑定IoT Policy限制其可发布/订阅的主题。
越权访问是平台层最容易被忽视的风险。假设规则引擎允许用户编写SQL-like语句处理数据，若未做租户隔离，A租户的规则可能读取B租户的数据。面试表述可以具体到：检查规则引擎的查询是否强制带租户ID过滤，API网关是否在每次请求中校验JWT中的tenant_id与资源归属一致。
另一个高频问题是API安全。平台对外提供REST API供应用调用，若未做速率限制和输入校验，可能被撞库或注入。面试中可提到：对/devices/{id}/commands这类接口，应校验调用者是否有该设备的操作权限，并对命令内容做白名单校验，防止攻击者通过命令注入控制设备。
面试表述建议：平台层回答要突出“身份—权限—隔离”三个词。例如：“平台层的核心是确认每个请求的身份，并确保该身份只能访问其被授权的资源；防御手段包括mTLS、短期Token、租户级数据隔离和API速率限制。”
应用层：用户与业务的界面，也是社会工程与逻辑漏洞的温床
应用层包括Web控制台、移动App、小程序和第三方集成。这一层直接面向用户，风险更偏向传统Web安全与业务逻辑。
常见风险包括：越权查看他人设备（水平越权）、未授权控制设备（功能级越权）、敏感信息泄露（如API返回设备密钥）、不安全的直接对象引用。面试中若被问到“你怎么测试一个物联网App”，可以这样表述：先抓包分析API，尝试修改请求中的deviceId或userId，观察是否返回他人数据；再检查App本地存储是否明文保存Token或密钥；最后测试固件升级接口是否校验签名。
一个具体示例：某智能摄像头App的API为GET /api/v1/devices/{deviceId}/stream。若仅校验用户登录态而不校验设备归属，攻击者遍历deviceId即可观看他人摄像头。防御上应在服务端校验deviceId与当前用户绑定关系，而非仅依赖前端隐藏。
应用层还常涉及第三方集成风险。例如通过OAuth授权第三方访问设备，若Scope过大或Token泄露，第三方可长期控制设备。面试中可提到：应遵循最小权限原则，限制Scope为device:read而非device:*，并支持用户随时撤销授权。
面试表述的通用框架与追问应对
当面试官让你“谈谈物联网攻击面”时，可以用一个通用框架组织回答：先按四层拆解，每层说清“关键资产—攻击入口—典型后果—防御抓手”，最后补一句“跨层风险”。跨层风险是加分项，例如：感知层设备被控后，攻击者可能利用平台层信任关系横向移动到其他设备；或者应用层越权获取的Token可用于平台层API调用。
常见追问包括：“如果只能选一个最重要的防御措施，你选什么？”可以回答：“设备身份与最小权限。因为物联网攻击面太广，但多数严重事件都源于身份伪造或权限过大。把设备身份做扎实，把每层权限收窄，能显著降低横向移动的成功率。”
另一个追问是：“你怎么验证防御有效？”可以给出可操作判断：在测试环境尝试用默认口令登录设备，应失败；尝试订阅非授权MQTT主题，应被拒绝；尝试用A用户Token访问B用户设备，应返回403。这些验证点可以直接作为面试中的具体回答，体现你不仅知道风险，还知道怎么确认控制措施生效。
最后提醒一点：面试中不要只堆砌术语。每提到一个风险，尽量跟一句“实际中怎么发现或怎么防”。例如提到固件未签名，就补一句“可以用binwalk解包后检查是否存在签名校验逻辑，或用firmware-mod-kit尝试重打包并刷入，若设备接受则说明无签名校验”。这种“风险+验证方法”的表述方式，比单纯罗列风险更有说服力。