长久以来日志收集系统和消息系统一直在企业的生产与发展中扮演者重要的角色，但随着客户需求逐渐增多、产品功能逐渐增强，传统的消息系统和日志系统已经无法满足企业自身的内部需求，于是一系列分布式日志系统开始逐渐取代传统的日志系统，其中Kafka便是一个很典型的产品。

本期美创安全实验室将给大家解析分布式日志系统Kafka的安全机制。

01、Kafka简介

Kafka最初是由LinkedIn公司开发，LinkedIn于2010年贡献给了Apache基金会，随后于2012年成为Apache的主要项目之一。Apache Kafka采用Scala和Java进行编写，是一个基于zookeeper协调的、快速的、可扩展的、高吞吐的、分区的、可容错的分布式日志系统（发布-订阅消息系统）。常见可以用于web日志、访问日志、消息服务等等，适合在大规模消息处理场景中使用。

Kafka主要设计目标如下：

① 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
② 高吞吐率，即使在低性能的商用机器上也能做到单机支持每秒100K条消息的传输。
③ 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
④ 同时支持离线数据处理和实时数据处理。
⑤ 支持在线水平扩展。

在企业中Kafka作为一个分布式的发布-订阅消息系统，无论是在离线模式还是实时模式都必须能够支持海量数据的数据传递。而Kafka的做法就是将消息持久化到磁盘中，并对消息创建了备份以保证数据的安全，在保持较高的处理速度的同时，又能保证数据处理的低延迟和数据的零丢失。

① 解耦：在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

② 扩展性：因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。

③ 灵活性：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

④ 可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

⑤ 缓冲机制：在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行——写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。

⑥ 异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

02、消息系统模式简介

一个消息系统负责将数据从一个应用传递到另外一个应用，应用只需关注于数据，无需关注数据在两个或多个应用间是如何传递的。分布式消息传递基于可靠的消息队列，在客户端应用和消息系统之间异步传递消息。有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。

① 点对点消息系统模式
在点对点消息系统模式中，消息被持久化到同一个队列当中。此时，可以有一个或多个消费者（Consumer）来消费队列中的数据。但是需要注意的是，一条消息只能被消费一次，也就是说当一个消费者消费了队列中的某条数据后，该条数据将从消息队列中删除。所以在该模式下，当有多个消费者同时消费数据时，虽然能保证数据处理的顺序，但是由于是一一对应的关系且消息被消费后会被删除，会导致处理速度缓慢且无法溯源，存在安全隐患。这种架构的示意图如下：

Kafka在0.9.0.0版本中添加了很多功能和安全机制，这些功能既可以单独运作也可以同时运作，从而提高Kafka集群的安全性。目前主要使用的安全机制有：

① 使用SSL或者SASL验证来自客户端（生产者和消费者）或者其他broker和工具到broker的链接身份。

② 验证broker到zookeeper的链接的身份。

③ 使用SSL加密数据的方式传输数据在broker和客户端之间，broker和broker之间以及其他工具之间。

④ 对客户端读写操作的授权。

⑤ 授权是可以被扩展并且支持外部服务的验证授权的整合。

从上面的措施可以看出，Kafka的安全机制主要关注三部分内容：加密、授权和身份验证。其中加密部分指的是数据或者消息在传递的过程中（broker->客户端，broker->broker，broker->其他）需要使用SSL或者TLS进行加密，确保数据/消息的可用性、完整性、保密性；身份验证指的是在整个数据交互的过程中，需要时刻对发布者、消费者、broker或其他工具进行身份验证，使用的方法大多是依赖公私钥对以及证书；而授权解决的是用户有什么权限的问题，需要注意的是授权的前提条件是用户已经完成了身份验证这一步骤，所以这两个功能通常是一起出现的。

基本上，Apache Kafka扮演者内部中间层的角色，也因此我们的后端系统才能够通过Kafka主题彼此共享实时数据传送。当我们的数据包在被路由转发到Kafka集群或者从broker转发到broker时，使用SSL加密或者TLS加密数据或消息，就可以解决中间人（MITM）攻击的问题。如果我们的数据是PLAINTEXT，那么攻击者在路由器中的任何一个位置都可以读取数据/消息的内容。

消息或者数据经过SSL/TLS加密后通过网络进行安全传输，启用加密功能并仔细设置SSL证书。只有第一台和最后一台机器具有使用SSL/TLS来解密正在发送的数据包的能力。然而，这种加密是有代价的，这意味着为了加密和解密数据包，CPU现在可以用于Kafka客户端和KafkaBrokers，而且仅在加密进行中时，数据仍然在代理磁盘上处于未加密状态。

06、Kafka之SSL/SASL身份验证

当我们在做Kafka安全模块分析时，我们首先要关注以下几个点：① 密码如果在服务端保存，必须要用密文保存；② 每次新增用户时最好不要重启Broker；③客户端密码需要密文传输；明确了以上三个前提后，为Kafka集群中的每台机器生成密钥和证书是部署一个或多个具有SSL支持的broker的第一步。利用SASL进行身份验证则是第二步。一般来说SASL认证机制主要有三种方式可以实现：

① 基于Kerberos的GSSAPI

SASL-GSSAPI是一种提供身份验证非常安全的方法，但使用它的前提是企业中有Kerberos基础，因为他是在Kerberos票证机制的基础上运作的。Kerberos最常见的实现是Microsoft Active Directory。由于它允许公司从他们的Kerberos服务器中直接管理安全性，因此可以说SASL-GSSAPI是大型企业的绝佳选择。

② SASL-PLAINTEXT

SASL-PLAINTEXT是一个经典的用户名和密码组合，且用户密码是以明文形式保存在服务端的JAAS配置文件中的，每次更改都需要触发滚动重启且客户端使用PLAIN时，密码是明文传输的。所以说该模式的安全性较低，很不推荐使用。

③ SASL-SCRAM

SASL-SCRAM是一个较为理想的解决方案，与PLAINTEXT不同，SCRAM将用户密码保存在zookeeper上，并且可以通过脚本动态增减用户，当客户端使用SCRAM模式进行认证时，密码会经过SHA-256哈希加密后传输到服务器，因此即使不重新启动代理也可以扩展其安全性，所以可以看出SCRAM是一个较为安全的认证办法，其大致工作流程如下图所示：

07、Kafa之ACL授权

当Kafka客户端通过身份验证后，Kafka需要决定这些客户端能够做什么和不能够做什么，这就需要对用户进行授权操作。通常都是通过ACL（访问控制列表）控制。

ACL机制可以帮助使用者规避很多风险，举个列子：当存在一个只能从主机的子集或者客户端写入的Topic时，我们希望阻止普通用户为这些主题编写任何内容，向监管机构证明只有某些应用程序或用户才能访问这些数据，从而防止任何数据损坏或反序列化错误。这时我们可以使用kafka-acls命令来添加一条ACL：

kafka-acl --topic test --producer --authorizer-properties

zookeeper.connect=localhost:2181 --add --allow-principalUser:alice

为名叫test的Topic主题添加ACL，允许用户alice具有操作权限可以描述主机和从主机写入。但需要注意的是，仅使用默认的SimpleAclAuthorizer在Zookeeper中存储ACL。另外，确保只有Kafka代理可以写入Zookeeper（zookeeper.set.acl = true）。否则，任何用户都可以进入并编辑ACL，从而破坏其安全性。