引言
RocketMQ 作为一款流行的分布式消息中间件，被广泛应用于各种大型分布式系统和微服务中，承担着异步通信、系统解耦、削峰填谷和消息通知等重要的角色。随着技术的 演进和业务规模的扩大，安全相关的挑战日益突出，消息系统的访问控制也变得尤为重 要。然而，RocketMQ 现有的 ACL 1.0 版本已经无法满足未来的发展。
因此，我们推出了 RocketMQ ACL 2.0 升级版，进一步提升 RocketMQ 数据的安全性。本文将介绍 RocketMQ ACL 2.0 的新特性、工作原理，以及相关的配置和实践。
升级的背景
ACL 1.0 痛点问题
RocketMQ ACL 1.0 的认证和授权流程如图所示，在使用过程中，存在着以下痛点问题：
- 绕过访问控制的 IP 白名单：在标准安全实践中，IP 白名单通常用于限制客户端只能从特定 IP 或 IP 段访问资源。然而，ACL 1.0 中，IP 白名单被异常用于绕过鉴权验证的手段， 偏离了标准实践中的安全意图。这种设计上的偏差可能造成潜在的安全隐患，特别是在公网场景中，多个客户端共享同一个 IP 的情况下，会导致未授权的 IP 地址绕过正常的访问控制检查对集群中的数据进行访问。
- 缺乏管控 API 精细化控制：RocketMQ 提供了 130 多个管控 API，支持了集群配置，Topic、Group 的元数据管理，以及消息查询、位点重置等操作。这些操作涉及到敏感数据的处理，以及影响系统的稳定性。因此，根据用户不同角色或职责， 精确定义可访问的 API 和数据范围变得至关重要。然而，ACL 1.0 仅对其中 9 个API 进行了支持，包括 Topic、Group 元数据，以及 Broker 配置，剩下的 API 有可能被攻击者利用，对系统进行攻击，窃取敏感的数据。此外，要实施对这么多的 管控 API 进行访问控制，现有的设计会导致大量的编码工作，并且在新增 API 时也增加了遗漏的风险。
- 缺少集群组件间访问控制：在 RocketMQ 架构中，涵盖了 NameServer、Broker 主从节点、Proxy 等多个关键组件。目前，这些组件之间的互相访问缺失了关键的的权限验证机制。因此，一但旦在集群外自行搭建 Broker 从节点或 Proxy 组件， 便可以绕过现有的安全机制，访问并获取集群内的敏感数据，这无疑给系统的数据 安全和集群的稳定性造成巨大的威胁。
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级（2）https://developer.aliyun.com/article/1554226
