安全
5.1 简介 Introduction
Introduction
本章的内容仅供参考,不属于非规范化约定范畴。然而,强烈推荐使用TLS的服务端应该
使用TCP端口8883(IANA服务名:secure-mqtt)。
解决方案提供者需要考虑很多风险。例如:
设备可能是易被盗用的
客户端和服务端的静态数据可能是可访问的
协议行为可能有副作用(如"时间攻击")
拒绝服务(Dos)攻击
通信可能会被拦截、修改、重定向或者泄露
虚假控制报文注入
MQTT解决方案通常部署在恶劣的通信环境中。在这种情况下,协议实现通常需要提供这些机制:
用户和设备的身份认证
服务端资源的访问授权
MQTT控制报文和内嵌应用数据的完整性校验
MQTT控制报文和内嵌应用数据的隐私控制
作为传输协议,MQTT仅关注消息传输,而实施者有义务提供适当的安全功能。通常会使用TLS [RFC5246]。除了技术上的安全问题外,还有地理(例如美国欧盟安全港原则 [USEUSAFEHARB]),行业标准(例如第三方支付行业数据安全标准 [PCIDSS]),监管方面(例如萨班斯-奥克斯利法案 [SARBANES])等问题。
5.2 MQTT解决方案:安全和认证 MQTT solutions: security and certification
MQTT solutions: security and certification
协议实现可能想要符合特定的行业安全标准,如NIST网络安全框架 [NISTCSF] ,PCI-DSS [PCIDSS] ,FIPS-140-2 [FIPS1402] 和 NSA组件B [NSAB] 。
在MQTT补充出版物-MQTT和NIST改进关键基础设施网络安全框架 [MQTT NIST]) 中可以找到在NIST网络安全框架 [NISTCSF] 中使用MQTT的指导。使用行业认证、独立验证和认证的技术有助于满足合规要求。
5.3 轻量级的加密与受限设备 Lightweight cryptography and constrained devices
Lightweight cryptography and constrained devices
高级加密标准 [AES]和数据加密标准 [DES]被大家广泛采用 。
ISO 29192 [ISO29192]是特别推荐在受限的"低端"设别上实施的密码标准。
5.4 实施注意事项 Implementation notes
Implementation notes
实现和使用MQTT时需要考虑许多安全问题。以下部分并不应该被视为一个"检查清单"。
协议实现可以只实现下面的一部分或全部功能:
5.4.1 服务端对客户端进行身份验证 Authentication of Clients by the Server
Authentication of Clients by the Server
CONNECT
报文包含用户名和密码字段。协议实现可以决定如何使用这些字段的内容。实现者可以提供自己的身份验证机制,或者使用外部的认证系统如LDAP [RFC4511] 或OAuth [RFC6749] ,还可以利用操作系统的认证机制。
协议实现可以明文传递认证数据,混淆那些数据,或者不要求任何认证数据,但应该意识到这会增加中间人攻击和重放攻击的风险。5.4.5节介绍了确保数据私密的方法。
在客户端和服务端之间使用虚拟专用网(VPN)可以确保数据只被授权的客户端收到。
使用TLS [RFC5246] 时,服务端可以使用客户端发送的SSL证书验证客户端的身份。
实现可以允许客户端通过应用消息给服务端发送凭证用于身份验证。
5.4.2 服务端对客户端授权 Authorization of Clients by the Server
Authorization of Clients by the Server
基于客户端提供的信息如用户名、客户端标识符、客户端的主机名/IP地址,或者身份认证的结果,服务端可以限制客户端对服务端资源的访问。
5.4.3 客户端对服务端认证 Authentication of the Server by the Client
Authentication of the Server by the Client
MQTT协议不是双向信任的,它不提供客户端验证服务端身份的机制。
但是使用TLS [RFC5246] 时,客户端可以使用服务端发送的SSL证书验证服务端的身份。为来自单个IP地址的多主机提供MQTT服务的协议实现应该考虑RFC6066 [RFC6066]的第3节中定义的TLS服务器名称指示扩展Server Name Indication extension
。它允许客户端告诉服务端它要连接的服务端主机名。
实现可以允许服务端通过应用消息给客户端发送凭证用于身份验证。
在客户端和服务端之间使用虚拟专用网(VPN)可以确保客户端连接的是预期的服务器。
5.4.4 控制报文和应用消息的完整性 Integrity of Application Messages and Control Packets
Integrity of Application Messages and Control Packets
应用可以在应用消息中单独包含哈希值。这样可以确保网络传输中和静态的PUBLISH
控制报文的完整性。
TLS [RFC5246] 提供了对网络传输的数据做完整性校验的哈希算法。
在客户端和服务端之间使用虚拟专用网(VPN)连接可以在VPN覆盖的网络段提供数据完整性检查。
5.4.5 应用消息和控制报文的保密性 Privacy of Application Messages and Control Packets
Privacy of Application Messages and Control Packets
TLS [RFC5246] 可以对网络传输数据加密。如果有效的TLS密码组合包含的加密算法为NULL,那么它不会加密数据。要确保客户端和服务端的保密,应避免使用这些密码组合。
应用可以单独加密应用消息的内容。这可以保证应用消息传输途中和静态数据的保密性。但不能给应用消息的其它属性如主题名加密。
客户端和服务端实现可以加密存储静态数据,例如可以将应用消息作为会话的一部分存储。
使用VPN连接客户端和服务端可以在VPN覆盖的网络段实现数据的加密。
.5.4.6 消息传输的不可否认性 Non-repudiation of message transmission
Non-repudiation of message transmission
应用设计者可能需要考虑适当的策略,以实现端到端的不可否认性。
5.4.7 检测客户端和服务端的盗用 Detecting compromise of Clients and Servers
Detecting compromise of Clients and Servers
使用TLS [RFC5246] 的客户端和服务端实现应该确保,初始化TLS [RFC5246] 连接时提供的SSL证书是与客户端连接的主机名或者是将连接到的服务器是相关联的。
使用TLS [RFC5246] 的客户端和服务端实现,可以选择提供检查证书吊销列表 (CRLs [RFC5280]) 和在线证书状态协议 (OSCP) [RFC6960] 的功能,防止使用被吊销的证书。
物理上的布局可以将防篡改硬件与应用消息的特殊数据的传输相结合。例如,一个仪表可能会内置一个GPS以确保没有在未授权的地区使用。IEEE安全设备认证 [IEEE 802.1AR] 就是用于实现使用加密绑定标识符来认证设备身份的机制的标准。
5.4.8 检测异常行为 Detecting abnormal behaviors
Detecting abnormal behaviors
服务端实现可以监视客户端的行为,检测潜在的安全风险。例如:
重复的连接请求
重复的身份验证请求
连接的异常终止
主题扫描(请求发送或订阅大量主题)
发送无法送达的消息(没有订阅者的主题)
客户端连接但是不发送数据
服务端可以断开违反安全规则的客户端的连接。
检测不受欢迎行为的服务端可以基于如IP地址或客户端不标识符来实现动态黑名单。
服务部署可以使用网络界别控制(如果可用)实现基于IP地址或其它信息的速率限制或黑名单。
5.4.9 其它的安全注意事项 Other security considerations
Other security considerations
如果客户端或服务端的SSL证书丢失,或者认为可能被盗,则英爱撤销这些证书。(利用 CRLs [RFC5280] 和 OSCP [RFC6960])
客户端或服务端验证凭证时,如果发现用户名和密码丢失或被盗用,应该吊销或者重新发放。
在使用长连接时:
客户端和服务端使用TLS [RFC5246] 时应该允许重新协商会话以确认新的加密参数(替换会话密钥,更换密码组合,更换身份认证凭证)。
服务端可以断开客户端连接,并要求他们使用新的凭证重新验证身份。
受限网络上的受限设备和客户端可以使用TLS会话恢复 [RFC5077] 降低TLS会话重连 [RFC5246] 的成本。
连接到服务端的客户端与连接到同一服务端的其他客户端之间有一个信任传递关系,它们都有权发布相同主题的数据。
5.4.10 使用SOCKS Use of SOCKS
Use of SOCKS
客户端实现应该意识到某些环境要求使用SOCKSv5 [RFC1928] 代理创建出站的网络连接。某些MQTT实现可以利用安全隧道(如SSH)替代SOCKS代理。协议实现决定支持SOCKS时,它们应该同时支持匿名的和用户名密码验证的SOCKS代理。对于后一种情况,协议实现应该意识到SOCKS可能使用明文认证,因此应该避免使用相同的凭证连接MQTT服务器。
5.4.11 安全配置 Security profiles
Security profiles
实现者和方案设计者可能希望将安全考虑当作配置集合应用到MQTT协议中。下面介绍的是一个分层的安全等级的例子。
5.4.11.1 开放的通信配置 Clear communication profile
Clear communication profile
当使用开放通信配置时,MQTT协议通过开放网络运行,没有其他安全通信机制。
5.4.11.2 安全的网络通信配置 Secured network communication profile
Secured network communication profile
当使用安全网络通信配置时,MQTT协议运行在有安全控制的物理或虚拟网络上,(如VPN或物理安全网络)。
5.4.11.3 安全的传输配置 Secured transport profile
Secured transport profile
使用安全的传输配置时,MQTT协议运行在使用TLS [RFC5246] 的物理或虚拟网络上,它提供了身份认证,完整性和隐私保护。
使用内置的用户名和密码字段的TLS [RFC5246] 客户端身份认证可被用于(或者代替)MQTT客户端认证。
5.4.11.4 行业特定的安全配置 Industry specific security profiles
Industry specific security profiles
可以预料的是,MQTT会被设计成特定行业的应用配置文件,每一种定义一个威胁模型和用于解决这些威胁的特定安全机制。特殊的安全机制推荐从现存的方案中挑选,其中包括:
[NISTCSF] NIST网络安全框架 [NIST7628] NISTIR 7628智能电网网络安全指南 [FIPS1402] (FIPS PUB 140-2) 加密模块的安全要求 [PCIDSS] PCI-DSS支付卡行业数据安全标准 [NSAB] NSA组件B密码学
Last updated