跳转至主要内容
版本: 5.0

安全

安全模型​

Apache RocketMQ 项目本身提供了 ACL 和 TLS 等安全功能，但最终的安全效果仍取决于运维人员对网络、主机、账户和数据的全面保护。

重要提示（安全部署基线）：RocketMQ 的身份验证/授权能力依赖于 ACL 配置。如果未启用/配置 ACL，RocketMQ 将不会在协议层强制执行客户端身份验证。任何能够访问 RocketMQ 端口的实体都可以发起消息发送/接收或管理操作。运维人员必须：要么启用并正确配置 ACL（身份验证+授权），要么将 RocketMQ 组件和端口严格限制在可信网络（内网/VPC/私有网络）内，而不是将其暴露给不受信任的网络。

1. 身份验证与授权 (ACL)​

  • ACL 1.0 自 RocketMQ 4.4.0 版本起开始支持
  • 更安全的 ACL 2.0 于 5.3.0 版本引入
  • ACL 1.0 已于 5.3.3 版本移除
  • 建议所有使用 Apache RocketMQ ACL 的用户迁移至 ACL 2.0

ACL 用于 RocketMQ 请求的身份验证和授权控制。对于生产环境，建议：

  • 除非 RocketMQ 被严格隔离在可信网络内，否则请启用 ACL（身份验证/授权），并为应用程序配置最小权限账户
  • 避免在业务应用程序中使用管理员账户；实施分级访问密钥、定期轮换并审计变更记录

2. 控制台与可观测性暴露​

RocketMQ Dashboard 和一些可观测性组件（如 RocketMQ Prometheus Exporter）默认不开启强身份验证；任何能访问 HTTP 端口的人都可以读取集群元数据。强烈建议：

  • 将 Dashboard 监听地址绑定到内网或受信任的 VPC
  • 在网关/Ingress/反向代理上配置 ACL / IP 白名单
  • 如果必须进行公网运维，请务必增加 VPN、HTTP Basic/OAuth 认证或 WAF

否则，可能会出现信息泄露风险；此类风险由部署方负责，而非 RocketMQ 漏洞。

3. 传输加密与数据加密​

  • 客户端与服务端之间可以通过 TLS 加密进行通信；如果涉及敏感数据，请启用此功能
  • 消息体由业务定义；RocketMQ 不会解析或持久化解密后的内容
  • 如果消息中包含敏感信息，请在业务侧进行字段级或整体加密，以避免存储明文

4. 序列化与反序列化风险​

  • RocketMQ 仅传输字节数组，不会执行对象反序列化
  • 如果消费者需要反序列化，应选择安全的格式（如 JSON-Binding、Protobuf 等）并验证不受信任的数据

5. SDK 与版本管理​

  • 始终使用最新的官方稳定版客户端，以获取最新的漏洞修复和改进

6. 日志管理​

  • 妥善保管 RocketMQ 相关日志（包括 Broker、NameServer、Proxy、Client 等），以避免敏感信息泄露

安全策略​

Apache RocketMQ 是 Apache 软件基金会 (ASF) 的项目，遵循 ASF 的漏洞处理流程。

漏洞报告​

如需报告您发现的新漏洞，请遵循 ASF 漏洞报告流程：https://apache.org/security/#reporting-a-vulnerability

为了帮助我们评估和解决问题，请包含受影响的组件/版本、复现步骤、影响分析以及可能的漏洞证明 (PoC)。

在修复方案发布之前，请勿通过公共 Issue、邮件列表或社交媒体披露可利用的漏洞细节。

常见问题：关于“未启用 ACL 时无需认证/可访问”​

RocketMQ 的身份验证和授权能力由 ACL 提供；是否启用取决于部署和配置。当未启用或未配置 ACL 时，请求可能会在未经身份验证的情况下被处理。这属于部署/配置的选择。运维人员应根据自身威胁模型启用 ACL，并通过网络隔离等手段确保安全。