3、ThingsBoard 安全架构概览：通信端口、默认安全配置与传输层风险分析

理解 ThingsBoard 的安全架构是进行有效加固的前提。本章将深入剖析平台的通信端口矩阵、开箱即用的默认安全配置，并系统性地分析传输层面临的主要安全风险，为后续 HTTPS 与证书配置打下坚实基础。

3.1 核心通信端口与协议矩阵

ThingsBoard 作为物联网平台，需要同时处理设备数据、用户界面访问以及集群内部通信。下表列出了默认安装下的关键端口及其用途：

3.2 默认安全配置基线

ThingsBoard 在安装后提供了一套基础安全配置，但远未达到生产环境要求。以下是默认配置的关键项分析：

• 系统管理员账户： 默认用户名 sysadmin@thingsboard.org，密码 sysadmin。首次登录后必须立即修改。
• 租户管理员账户： 默认用户名 tenant@thingsboard.org，密码 tenant。同样需要强制修改。
• JWT 令牌： 默认使用 thingsboardDefaultSigningKey 作为签名密钥。该密钥在 GitHub 仓库中公开，攻击者可伪造任意令牌。
• SSL/TLS： 默认未启用。所有 HTTP、MQTT、CoAP 端口均以明文运行。
• 数据库： 默认使用 PostgreSQL 或 Cassandra，监听 localhost:5432 或 localhost:9042，仅允许本地连接。
• 日志级别： 默认日志级别为 INFO，可能记录敏感信息（如设备令牌）。

3.3 传输层安全风险分析

传输层是攻击者最容易介入的环节。以下从三个维度分析 ThingsBoard 面临的传输层风险：

3.3.1 中间人攻击（MITM）

当设备或浏览器与 ThingsBoard 之间使用明文协议（HTTP、MQTT、CoAP）时，攻击者可在网络路径上部署嗅探工具，截获：

• 设备凭据： 访问令牌（Access Token）、X.509 证书、MQTT 用户名/密码。
• 遥测数据： 传感器读数、GPS 坐标、业务敏感数据。
• 控制指令： 对设备的 RPC 调用，如开关阀门、修改参数。

3.3.2 端口扫描与服务指纹识别

攻击者通过扫描开放端口（如 8080、1883）即可确认 ThingsBoard 的存在。随后可利用已知漏洞（如旧版 Log4j 漏洞）或默认配置弱点发起针对性攻击。

3.3.3 会话劫持与重放攻击

在未启用 HTTPS 的情况下，用户的 JWT 令牌通过明文传输。攻击者捕获令牌后可直接冒充用户执行管理操作。此外，未加密的 MQTT 消息可被重放，导致设备执行重复指令。

3.4 安全架构纵深防御原则

针对上述风险，ThingsBoard 的安全架构应遵循纵深防御原则，在多个层面建立防护：

1. 传输层加密： 所有外部通信链路强制使用 TLS/SSL（HTTPS、MQTTS、CoAPS），这是本章的核心目标。
2. 网络层隔离： 将 ThingsBoard 部署在私有网络或 VPC 中，通过反向代理（Nginx、HAProxy）暴露必要端口，屏蔽内部组件端口（如 Kafka、Zookeeper）。
3. 身份与访问管理： 使用强密码策略、多因素认证（MFA）以及基于角色的访问控制（RBAC）。
4. 密钥与证书管理： 定期轮换 JWT 签名密钥、设备访问令牌以及 TLS 证书。
5. 审计与监控： 启用详细审计日志，监控异常连接尝试和证书过期事件。