1. Kafka 安全概述：为什么需要安全配置

说实话，我刚接触 Kafka 那会儿，也觉得安全配置是个「锦上添花」的事。那时候团队小，Kafka 集群跑在内网，大家觉得「没人会来搞我们」。直到有一次，一个实习生误操作，直接把生产环境的 topic 给删了……嗯，从那以后，我再也不敢轻视安全配置了。

你想想看，Kafka 现在可是数据平台的核心枢纽。业务日志、用户行为、交易流水，全都从它这儿过。如果这个枢纽出了问题，那可不是小事。

1.1 为什么需要安全配置

我总结了几点，都是我在项目中真实踩过的坑：

• 数据泄露风险：Kafka 默认不加密，数据在网络上是明文传输的。我在金融项目里见过，有人用 tcpdump 就能抓到 topic 里的敏感数据。
• 未授权访问：默认配置下，谁都能连上你的 Kafka 集群。我曾经接手过一个集群，发现居然有 3 个不认识的客户端在往里面写数据。
• 数据篡改：没有认证和校验，中间人可以随意篡改消息内容。这在金融交易场景下，后果不堪设想。
• 权限失控：谁该读、谁该写、谁能管理，这些如果不控制好，内部人员误操作或者恶意行为，你都防不住。

1.2 Kafka 安全模型总览

Kafka 的安全模型，说白了就是四道防线。我习惯把它们叫做「四层防护」：

这四层不是孤立的，它们是层层递进的关系。我画了张图，帮你理清它们之间的关系：

我个人习惯把这四层比作「门锁系统」：传输加密是门板材质，身份认证是门锁，授权控制是钥匙权限，审计日志是监控摄像头。少一层，都不安全。

1.3 常见安全威胁分析

光知道怎么防护还不够，你得先知道敌人长什么样。我整理了几种最常见的威胁：

1.3.1 中间人攻击（MITM）

说白了，就是有人在网络链路上偷听甚至篡改你的数据。Kafka 默认的明文传输，对这种攻击毫无抵抗力。我曾经在客户现场做过测试，用 Wireshark 抓包，直接就能看到 topic 里的 JSON 数据。

1.3.2 未授权访问

Kafka 默认监听 0.0.0.0:9092，谁都能连。我记得有个项目，开发环境跟生产环境网络没隔离，结果开发同学的生产客户端连错了地址，把测试数据写到了生产 topic 里。还好发现得早，不然就出大事了。

1.3.3 内部威胁

这个往往被忽视。你想想看，能接触到 Kafka 集群的，大多是运维和开发人员。如果没有权限控制，一个「手滑」就能删掉关键 topic。我经历过一次，凌晨两点被电话叫醒，说数据写不进去了。查了半天，发现是有人误删了 consumer group。

1.3.4 拒绝服务攻击（DoS）

Kafka 的默认配置对连接数、请求频率没有严格限制。如果有人恶意建立大量连接，或者发送超大消息，很容易把 Broker 打挂。我在压测时就遇到过，一个客户端发了 100MB 的单条消息，直接把 Broker 的堆内存撑爆了。

1.3.5 数据泄露与合规风险

这个不用我多说。金融、医疗、电商，只要涉及用户隐私数据，GDPR、等保 2.0 这些合规要求就像悬在头上的剑。没有加密和审计，合规检查根本过不了。