在当下网络安全事件频发的背景下，安全防护的构建成为日常开发与运维工作中的重中之重。ZooKeeper 存储着系统敏感实例信息与配置数据，但传统的使用方式并未为 ZooKeeper 配备强制身份验证机制，从而使得其内部数据面临暴露在网络空间中的风险。稍有不慎，任何具备网络访问能力的实体都能读取甚至篡改 ZooKeeper 中的数据，具有较大安全隐患。
某企业自建 ZooKeeper 客户就曾在使用 ZooKeeper 时忽略了对内部敏感数据设置适当的访问控制列表（ACL）和使用身份认证能力，同时没有禁用那些具备潜在安全风险的“四字命令”，ZooKeeper 数据完全暴露于网络中，任何能够访问此网络的人员都能够连接并操作 Zookeeper 中的数据，在这种使用场景中由于存在巨大的安全隐患，被安全团队要求限期整改。
自行改造升级 ZooKeeper
安全能力，复杂程度高，风险大
ZooKeeper 本身具备身份认证和细粒度的访问控制列表（ACL）能力。即便在默认配置下，它也能够支持多种身份认证模式，包括 Digest、IP 和 World 等。开发者可以在初始化连接时提供认证信息，并针对特定的 Znode 设置相应的 ACL，这样一来就能有效地限制客户端访问 Znode 的权限范围。然而，这套机制虽然强大，但是实际使用起来比较复杂。针对每个 Znode 单独配置 ACL 意味着随着 Znode 数量的增加，尤其是在业务逻辑较为复杂时，管理工作将变得异常繁重并且容易出错。
ZooKeeper 还提供了对 SASL（简单认证和安全层）身份认证模式的支持，该模式通过简单的服务器和客户端配置就能实现基于用户名和密码的认证机制。SASL 是一种支持身份验证过程和数据安全传输的协议，在 Java 中已经有一套基于该协议的接口实现，借助这些接口实现，ZooKeeper 实现了 SASL 认证功能，并且该功能可通过配置文件动态读取与应用，使得开发者可以无缝集成 SASL 认证机制，无需修改现有代码即可提升 ZooKeeper 的安全性。
采用 SASL 认证模式时，客户端与服务端通过相关配置实现安全连接：仅允许持有有效认证信息的客户端与ZooKeeper 服务器建立连接并执行数据操作。这有效增强了数据的安全性，避免了将 ZooKeeper 中的数据暴露于整个网络。
但是，实际部署 SASL 认证机制需手动完成服务端的配置工作，其配置规则较为复杂，容易在设置过程中出现错误导致节点异常。此外，SASL 认证所需的身份信息配置也需持续手动维护，增加了运维工作的难度和复杂性。
使用 MSE 标准化流程，
简单快速加固集群安全能力
MSE 通过标准化流程集成了 SASL 配置管理能力，屏蔽底层集群和客户端配置的复杂度，使得用户只需要通过白屏化配置和客户端配置引入即可接入 SASL 身份认证能力。
MSE 集成 SASL 管理能力，方便用户快捷接入，提升集群安全能力
为了让用户更加便捷地利用 SASL 身份认证功能，MSE 简化了复杂的服务端配置步骤，将其抽象成简单的白屏操作。用户只需在 MSE 控制台几步操作，即可轻松启动服务端的 SASL 认证功能。同时 MSE 控制台会自动生成客户端配置，以及引导用户简单配置参数即可让应用接入 SASL 能力，无需深入繁琐的技术细节即可提升ZooKeeper 的安全能力。
通过在 MSE 控制台一键配置 SASL 用户信息，屏蔽 ZooKeeper 本身的复杂配置
通过参数配置，一键开启集群强制校验 SASL 身份信息以及禁用敏感信息四字命令
在开启了服务端和客户端强制 SASL 身份认证能力之后，未配置用户信息或者用户信息错误的客户端将无法再连接到 ZooKeeper Server。同时 MSE 提供用户管理，密码轮转等能力，在必要时刻能够快速轮转，和用户禁用。
通过以上配置，集群将会开启强制认证客户端 SASL 身份认证，无法通过身份认证的客户端将无法对服务端发起请求，从而有效降低了 Zookeeper 集群内部数据泄漏的风险，并且降低了手动运维的风险和复杂度。
使用 Dubbo 支持通过此种方式配置 SASL 身份认证能力，在 Dubbo 的使用场景中，需要确保使用的 ZooKeeper 依赖版本在 3.4.x 及以上版本才支持，配置过程和一般使用 ZooKeeper 客户端的方式相同。
SpringCloud 使用的 spring-cloud-starter-zookeeper-discovery 依赖默认全部版本都支持，配置过程和一般使用 ZooKeeper 客户端的方式相同。
kafka 所有版本依赖的 Zookeeper 客户端都支持使用 sasl 身份认证，配置过程和一般使用 ZooKeeper 客户端的方式相同。
