第五章 – 安全
本章的内容仅供参考，是非规范化的。然而，强烈推荐提供TLS的服务端实现应该使用TCP端口8883（IANA服务名：secure-mqtt）。
解决方案提供者需要考虑很多风险。例如：
- 设备可能会被盗用
- 客户端和服务端的静态数据可能是可访问的（可能会被修改）
- 协议行为可能有副作用（如计时器攻击）
- 拒绝服务攻击
- 通信可能会被拦截、修改、重定向或者泄露
- 虚假控制报文注入
MQTT方案通常部署在不安全的通信环境中。在这种情况下，协议实现通常需要提供这些机制：
- 用户和设备身份认证
- 服务端资源访问授权
- MQTT控制报文和内嵌应用数据的完整性校验
- MQTT控制报文和内嵌应用数据的隐私控制
作为传输层协议，MQTT仅关注消息传输，提供合适的安全功能是实现者的责任。使用TLS [RFC5246] 是比较普遍的选择。除了技术上的安全问题外，还有地理因素（例如美国欧盟安全港原则 [USEUSAFEHARB]），行业标准（例如第三方支付行业数据安全标准 [PCIDSS]），监管方面的考虑（例如萨班斯-奥克斯利法案 [SARBANES]）等问题。
MQTT solutions: security and certification
协议实现可能想要符合特定的工业安全标准，如NIST网络安全框架 [NISTCSF] ，第三方支付行业数据安全标准 [PCIDSS] ，美国联邦信息处理标准 [FIPS1402] 和 NSA 加密组合B [NSAB] 。
在MQTT的补充出版物 （MQTT and the NIST Framework for Improving Critical Infrastructure Cybersecurity [MQTT NIST]） 中可以找到在NIST网络安全框架 [NISTCSF] 中使用MQTT的指导。使用行业证明、独立审计和认证技术有助于满足合规要求。
Lightweight cryptography and constrained devices
实现和使用MQTT时需要考虑许多安全问题。下面的部分不应该被当作是一个 核对清单 。
协议实现可以实现下面的一部分或全部：
实现可以明文传递认证数据，混淆那些数据，或者不要求任何认证数据，但应该意识到这会增加中间人攻击和重放攻击的风险。5.4.5节介绍了确保数据私密的方法。
在客户端和服务端之间使用虚拟专用网（VPN）可以确保数据只被授权的客户端收到。
实现可以允许客户端通过应用消息给服务端发送凭证用于身份验证。
基于客户端提供的信息如用户名、客户端标识符（ClientId）、客户端的主机名或IP地址，或者身份认证的结果，服务端可以限制对某些服务端资源的访问。
MQTT协议不是双向信任的，它没有提供客户端验证服务端身份的机制。
实现可以允许服务端通过应用消息给客户端发送凭证用于身份验证。
在客户端和服务端之间使用虚拟专用网（VPN）可以确保客户端连接的是预期的服务器。
应用可以在应用消息中单独包含哈希值。这样做可以为PUBLISH控制报文的网络传输和静态数据提供内容的完整性检查。
在客户端和服务端之间使用虚拟专用网（VPN）连接可以在VPN覆盖的网络段提供数据完整性检查。
应用可以单独加密应用消息的内容。这可以提供应用消息传输途中和静态数据的私密性。但不能给应用消息的其它属性如主题名加密。
客户端和服务端实现可以加密存储静态数据，例如可以将应用消息作为会话的一部分存储。
在客户端和服务端之间使用虚拟专用网（VPN）连接可以在VPN覆盖的网络段保证数据的私密性。
应用设计者可能需要考虑适当的策略，以实现端到端的不 可抵赖性（non-repudiation）。
物理部署可以将防篡改硬件与应用消息的特殊数据传输结合。例如，一个仪表可能会内置一个GPS以确保没有在未授权的地区使用。IEEE安全设备认证 [IEEE 802.1AR] 就是用于实现这个机制的一个标准，它使用加密绑定标识符验证设备身份。
服务端实现可以监视客户端的行为，检测潜在的安全风险。例如：
- 重复的连接请求
- 重复的身份验证请求
- 连接的异常终止
- 主题扫描（请求发送或订阅大量主题）
- 发送无法送达的消息（没有订阅者的主题）
- 客户端连接但是不发送数据
发现违反安全规则的行为，服务端实现可以断开客户端连接。
服务端实现检测不受欢迎的行为，可以基于IP地址或客户端标识符实现一个动态黑名单列表。
服务部署可以使用网络层次控制（如果可用）实现基于IP地址或其它信息的速率限制或黑名单。
客户端或服务端验证凭证时，如果发现用户名和密码丢失或被盗用，应该吊销或者重新发放。
在使用长连接时：
- 服务端可以断开客户端连接，并要求他们使用新的凭证重新验证身份。
连接到服务端的客户端与其它连接到服务端的客户端 之间有一个信任传递关系，它们都有权在同一个主题上发布消息。
客户端实现应该意识到某些环境要求使用SOCKSv5 [RFC1928] 代理创建出站的网络连接。某些MQTT实现可以利用安全隧道（如SSH）通过SOCKS代理。一个实现决定支持SOCKS时，它们应该同时支持匿名的和用户名密码验证的SOCKS代理。对于后一种情况，实现应该意识到SOCKS可能使用明文认证，因此应该避免使用相同的凭证连接MQTT服务器。
实现者和方案设计者可能希望将安全当作配置文件集合应用到MQTT协议中。下面描述的是一个分层的安全等级结构。
使用开放通信配置时，MQTT协议运行在一个没有内置额外安全通信机制的开放网络上。
使用安全网络通信配置时，MQTT协议运行在有安全控制的物理或虚拟网络上，如VPN或物理安全网络。
可以预料的是，MQTT被设计为支持很多工业标准的应用配置，每一种定义一个威胁模型和用于定位威胁的特殊安全机制。特殊的安全机制推荐从下面的方案中选择：
[NISTCSF] NIST网络安全框架 [NIST7628] NISTIR 7628智能电网网络安全指南 [FIPS1402] (FIPS PUB 140-2) 加密模块的安全要求 [PCIDSS] PCI-DSS第三方支付行业数据安全标准 [NSAB] NSA加密组合B
最近更新 3yr ago