Kafka 安全指南：SASL、SSL 与 ACL

Apache Kafka 的默认安装配置以开箱即用和高性能为首要目标，安全机制在初始状态下是关闭的。这意味着任何人只要能访问 Kafka 的监听端口，就可以创建 Topic、发送消息、消费任意数据。在早期阶段的测试环境或内网隔离场景中，这种设计可以接受；但在生产环境中，数据涉及商业机密、用户隐私或金融交易时，无防护的 Kafka 集群等同于将核心数据资产暴露给所有内部人员甚至外部攻击者。

Kafka 的安全体系围绕三个核心维度构建：认证（Authentication），确认"你是谁"；加密（Encryption），确保"传输不会被窃听"；授权（Authorization），决定"你能做什么"。这三个维度分别对应 SASL 认证协议、SSL/TLS 传输层加密和 ACL 访问控制列表。本文将系统性地拆解 Kafka 安全加固的完整路径，从安全架构设计到各种 SASL 机制的对比选择，从 SSL 证书链的配置实战到 ACL 规则矩阵的管理，再结合数据脱敏策略，为生产级 Kafka 集群构建纵深防御体系。

1. Kafka 安全架构：认证、加密与授权的三维模型

Kafka 的安全模型可以抽象为 AEA（Authentication, Encryption, Authorization）三层防御。

认证层位于最前端，解决通信双方的身份确认问题。当客户端（Producer 或 Consumer）连接到 Broker 时，Broker 要求客户端提供凭据，通过预设的安全协议验证其合法性。Kafka 支持的认证机制完全由 SASL（Simple Authentication and Security Layer）框架承载，支持的机制包括 SCRAM、GSSAPI（Kerberos）、PLAIN、OAUTHBEARER 和委托令牌。

加密层解决数据在传输过程中的保密性和完整性问题。即使没有认证，启用 SSL/TLS 也能将 Broker 与客户端之间的通信从明文转换为密文传输，防止中间人窃听和数据篡改。Kafka 的 SSL 支持包括单向认证（仅服务端验证）和双向认证（mTLS，客户端与服务端互相验证）。

授权层位于最内层，负责在身份确认之后控制主体（Principal）对资源（Topic、Group、Cluster）的操作权限。Kafka 的授权机制通过可插拔的 Authorizer 实现，核心实现是 AclAuthorizer，基于 ACL（Access Control List）规则进行权限判定。

三层安全机制并非必须同时启用。例如，在内网环境中可以仅使用 SASL/SCRAM 认证 + ACL 授权，不开启 SSL；在跨数据中心场景中，可能同时启用 SASL/GSSAPI + SSL + ACL 的全栈方案。选择什么组合取决于安全需求与性能开销之间的权衡。

Kafka 安全机制的一个关键设计是所有安全相关的配置都通过 server.properties 或客户端 Properties 对象完成，无需修改源码。Broker 端的核心配置包括 listeners、security.inter.broker.protocol、sasl.enabled.mechanisms、ssl.* 系列参数以及 authorizer.class.name。理解这些参数的作用范围与优先级，是安全加固的第一步。

2. SASL 认证：从 SCRAM 到 OAuth2 的机制全景

SASL 是一个独立于应用协议的认证框架，它将身份验证逻辑与底层传输协议解耦。在 Kafka 中，SASL 运行于应用层之上，可以与 PLAINTEXT 或 SSL 传输层组合使用。

2.1 SASL/SCRAM：生产环境的首选方案

SCRAM（Salted Challenge Response Authentication Mechanism）是目前 Kafka 生产环境中最常用的认证方式，具体实现有 SCRAM-SHA-256 和 SCRAM-SHA-512 两种。相比于 PLAIN，SCRAM 不会在网络上明文传输密码，而是采用挑战-响应机制，服务端存储的是由用户名、密码和盐值迭代计算出的哈希值，即使数据库泄露，原始密码也无法直接还原。

SCRAM 的认证流程分为四个阶段：客户端发送初始请求（包含用户名和随机 nonce）；服务端返回挑战（包含服务端 nonce、盐和迭代次数）；客户端用密码、盐、迭代次数计算出证明，与客户端证明一起返回；服务端验证两个证明是否匹配。整个过程中密码本身不会传输。

Broker 启用 SCRAM 的配置如下：

# server.properties
listeners=SASL_SSL://:9093
security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
sasl.enabled.mechanisms=SCRAM-SHA-256,SCRAM-SHA-512
listener.name.sasl_ssl.scram-sha-512.sasl.jaas.config=\
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="admin" \
  password="admin-secret";
authorizer.class.name=kafka.security.authorizer.AclAuthorizer

用户密码不是在 server.properties 中静态配置，而是通过 Kafka 提供的 kafka-configs.sh 工具动态管理：

# 创建 SCRAM 用户（指定 8192 次迭代和随机盐值）
kafka-configs.sh --zookeeper localhost:2181 \
  --alter --add-config 'SCRAM-SHA-512=[iterations=8192,password=user-secret]' \
  --entity-type users --entity-name alice

# 查看用户的 SCRAM 凭据
kafka-configs.sh --zookeeper localhost:2181 \
  --describe --entity-type users --entity-name alice

# 删除用户凭据
kafka-configs.sh --zookeeper localhost:2181 \
  --alter --delete-config 'SCRAM-SHA-512' \
  --entity-type users --entity-name alice

将凭据存储在 ZooKeeper 中是 Kafka 的传统做法。Kafka 2.8+ 引入了 KRaft 模式，此时凭据存储于内部的 Raft 元数据日志中，kafka-configs.sh 需使用 --bootstrap-server 替代 --zookeeper。SCRAM 的优势在于不依赖外部系统（如 Kerberos 的 KDC 或 OAuth 的认证服务器），部署简单且兼容性好，适合大多数中小型企业的 Kafka 集群。但也存在弱点：ZooKeeper/KRaft 中存储的凭据需要单独保护，如果攻击者获得 ZooKeeper 的访问权限，所有用户的密码哈希将暴露。

2.2 SASL/GSSAPI（Kerberos）：企业级强认证

GSSAPI（Generic Security Services Application Program Interface）在 Kafka 中的实际实现就是 Kerberos 认证。Kerberos 是 MIT 开发的网络认证协议，基于对称密钥和票据（Ticket）机制，广泛应用于企业级 Windows Active Directory 和 Hadoop 生态。当 Kafka 与其他大数据组件（如 Spark、Flink、Hive）部署在同一 Hadoop 集群中时，使用 GSSAPI 可以实现统一的身份管理。

Kerberos 认证需要预先配置 KDC（Key Distribution Center）服务器。在 Broker 端，每个节点都需要一个服务主体（Service Principal），格式为 kafka/broker1.example.com@EXAMPLE.COM。

Broker 的 JAAS（Java Authentication and Authorization Service）配置：

# server.properties
listeners=SASL_SSL://:9093
security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=GSSAPI
sasl.enabled.mechanisms=GSSAPI
listener.name.sasl_ssl.gssapi.sasl.jaas.config=\
  com.sun.security.auth.module.Krb5LoginModule required \
  useKeyTab=true \
  storeKey=true \
  keyTab="/etc/security/keytabs/kafka.service.keytab" \
  principal="kafka/broker1.example.com@EXAMPLE.COM";

客户端同样需要 JAAS 配置和 kinit 获取的 TGT（Ticket Granting Ticket）：

# 用户获取 Kerberos 票据
kinit -kt /path/to/user.keytab alice@EXAMPLE.COM

# 验证票据是否有效
klist

GSSAPI 的优势在于与企业现有身份系统（AD、LDAP）的深度集成，单点登录体验好，且 Kerberos 的票据机制避免了密码在网络上的传输。劣势也同样明显：运维复杂度高，需要维护独立的 KDC 服务器和 Keytab 文件；跨域认证场景配置繁琐；Java 客户端之外的其他语言客户端对 Kerberos 的支持参差不齐。因此，GSSAPI 主要出现在已有 Kerberos 基础设施的企业环境中，而不适合从零构建的 Kafka 集群。

2.3 SASL/PLAIN：简单但需谨慎使用

PLAIN 是最简单的 SASL 机制，直接在认证交换中传输用户名和密码。从安全性角度看，PLAIN 与 HTTPS 中表单提交密码没有本质区别——如果底层不使用 SSL，密码将以明文在网络上传输。因此，使用 SASL/PLAIN 时必须绑定 SSL 或 TLS 传输层。

Broker 配置需要在 JAAS 中静态定义用户名密码列表：

# server.properties
listener.name.sasl_ssl.plain.sasl.jaas.config=\
  org.apache.kafka.common.security.plain.PlainLoginModule required \
  username="admin" \
  password="admin-secret" \
  user_alice="alice-secret" \
  user_bob="bob-secret";

PLAIN 的 JAAS 配置将用户凭据直接嵌入 JVM 的启动参数中，任何拥有 Broker 节点文件读取权限的人都可以查看这些密码。虽然有 Vault 等外部秘密管理工具可以通过环境变量注入来部分解决这个问题，但本质上静态配置的密码管理始终是一个痛点。因此，PLAIN 仅适用于快速原型验证或高度受控的测试环境，不建议用于生产。

2.4 SASL/OAUTHBEARER：现代云原生认证

OAuth 2.0 已成为云原生应用和微服务架构的事实标准认证协议。Kafka 从 2.0 版本开始支持 SASL/OAUTHBEARER，允许客户端使用 OAuth 2.0 的 Access Token 进行身份认证。这为 Kafka 与现有的 OAuth 2.0 / OIDC 身份提供商（如 Keycloak、Auth0、Okta、Azure AD）集成提供了可能。

在默认实现中，Kafka Broker 验证 JWT Token 的签名，但不会主动调用授权服务器的 Introspection Endpoint 进行令牌验证。这意味着默认方案仅能验证令牌是否由可信机构签发以及是否过期，而无法实时撤销令牌。要实现完整的 OAuth 2.0 验证（包括令牌吊销检查），需要自定义 AuthenticateCallbackHandler。

Broker 端配置：

sasl.enabled.mechanisms=OAUTHBEARER
listener.name.sasl_ssl.oauthbearer.sasl.jaas.config=\
  org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;
listener.name.sasl_ssl.oauthbearer.sasl.server.callback.handler.class=\
  com.example.kafka.OAuthBearerValidatorCallbackHandler

客户端使用 Bearer Token 进行认证：

security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.jaas.config=\
  org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  unsecuredLoginStringClaim_sub="alice";

在生产环境中，通常会结合一个客户端回调处理器，在运行时从 OAuth 服务器获取和刷新 Access Token。SASL/OAUTHBEARER 的最大价值在于与云原生 IAM 基础设施的整合，但配置和运维的复杂度高于 SCRAM，适合已经深度采用 OAuth 2.0 的微服务架构。

2.5 委托令牌：减少 Kerberos 票据暴露

委托令牌（Delegation Token）是 Kafka 特有的轻量级凭据，旨在解决 Kerberos 场景中的一个实际问题：长时间运行的任务（如 Flink 作业、Kafka Connect Connector）持有 Kerberos TGT 的风险较高。委托令牌允许这些任务使用一个轻量级的、有 TTL 的令牌代替实际的 Kerberos 凭据来访问 Kafka。

委托令牌由 Kafka 自身签发，使用 HMAC 签名进行验证，不依赖外部系统。创建令牌需要客户端已拥有有效的 SASL 认证（如 GSSAPI 或 SCRAM）。

# 创建委托令牌（有效期 7 天）
kafka-delegation-tokens.sh --bootstrap-server broker1:9093 \
  --create --max-life-time-period 604800 \
  --command-config client.properties

# 查看令牌列表（管理员）
kafka-delegation-tokens.sh --bootstrap-server broker1:9093 \
  --describe --command-config admin.properties

委托令牌适合大批量分布式作业的统一凭据管理，但并非独立的安全方案，只是降低长周期凭据暴露风险的一种手段。

3. SSL/TLS 加密：Broker 间与 Broker-Client 通信加密

SSL/TLS（Secure Sockets Layer / Transport Layer Security）为 Kafka 通信提供三个核心保障：加密（Encryption），数据不以明文传输；完整性（Integrity），数据在传输中不会被篡改；认证（Authentication），客户端可以验证 Broker 的身份（双向认证时 Broker 也可以验证客户端身份）。

3.1 SSL 证书体系

Kafka 使用 Java 的 keytool 和 OpenSSL 来管理 X.509 证书和密钥库。要理解 SSL 配置，需要先明确三个核心概念：

• 密钥库（KeyStore）：存储服务端自身的私钥和证书链。对于 Kafka Broker，KeyStore 包含 Broker 的私钥和由 CA 签发的证书。
• 信任库（TrustStore）：存储受信任的 CA 证书。客户端使用 TrustStore 来验证服务端发来的证书是否由可信 CA 签发。
• 证书链：从服务端证书到根 CA 的完整链条。Broker 的证书必须包含完整的中级 CA 链，否则某些严格的客户端可能会拒绝连接。

在自签名证书（Self-Signed）的生产环境中，每个 Broker 的证书应由同一个内部 CA 签发，这样客户端只需在 TrustStore 中导入这个 CA 的根证书即可信任所有 Broker。如果使用 Let’s Encrypt 或企业购买的商业证书，TrustStore 中需要导入对应的中间 CA 和根 CA。

3.2 为 Kafka Broker 生成与配置 SSL 证书

创建 CA 和 Broker 证书的完整流程：

# 1. 创建 CA 私钥
openssl genrsa -out ca-key 4096

# 2. 创建自签名 CA 证书
openssl req -new -x509 -key ca-key -sha256 -days 3650 -out ca.crt \
  -subj "/C=CN/ST=Shanghai/O=MyOrg/CN=Kafka-CA"

# 3. 为 Broker 生成密钥和 CSR（证书签名请求）
keytool -keystore kafka.server.keystore.jks -alias broker1 -validity 365 \
  -genkey -keyalg RSA -storepass serverpass -keypass serverpass \
  -dname "CN=broker1.example.com, OU=Platform, O=MyOrg, L=Shanghai, ST=Shanghai, C=CN"

# 4. 从 keystore 导出 CSR
keytool -keystore kafka.server.keystore.jks -alias broker1 \
  -certreq -file broker1.csr -storepass serverpass -keypass serverpass

# 5. 使用 CA 签发 Broker 证书
cat > v3-ext.cnf << EOF
basicConstraints=CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:broker1.example.com, DNS:localhost, IP:127.0.0.1
EOF

openssl x509 -req -CA ca.crt -CAkey ca-key -in broker1.csr -out broker1.crt \
  -days 365 -sha256 -CAcreateserial -extfile v3-ext.cnf

# 6. 将 CA 证书和 Broker 证书导入 keystore（必须按顺序：先 CA，后证书）
keytool -keystore kafka.server.keystore.jks -alias CARoot -import -file ca.crt \
  -storepass serverpass -noprompt

keytool -keystore kafka.server.keystore.jks -alias broker1 -import -file broker1.crt \
  -storepass serverpass -keypass serverpass -noprompt

# 7. 创建客户端 truststore
keytool -keystore kafka.client.truststore.jks -alias CARoot -import -file ca.crt \
  -storepass clientpass -noprompt

Broker 端的 server.properties 配置：

listeners=SASL_SSL://:9093
security.inter.broker.protocol=SASL_SSL

# SSL KeyStore
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=serverpass
ssl.key.password=serverpass

# SSL TrustStore（Broker 互相认证时使用）
ssl.truststore.location=/var/ssl/private/kafka.server.truststore.jks
ssl.truststore.password=serverpass

# 启用客户端证书认证（双向 mTLS）
ssl.client.auth=required

# TLS 版本和算法套件
ssl.protocol=TLS
ssl.enabled.protocols=TLSv1.2,TLSv1.3
ssl.endpoint.identification.algorithm=HTTPS

ssl.endpoint.identification.algorithm=HTTPS 是关键配置。启用后，客户端会根据证书中的 CN 或 Subject Alternative Name（SAN）来验证 Broker 的主机名，防止中间人攻击者使用伪造证书进行 Man-in-the-Middle 攻击。在生产环境中，这个配置必须设置为 HTTPS。

ssl.client.auth 控制客户端认证级别：

• none：不验证客户端证书（单向 SSL）
• requested：请求客户端证书但不强制
• required：强制要求客户端提供有效证书（双向 mTLS）

双向认证将客户端身份验证下沉到 TLS 层，结合 SASL 认证可以实现真正的双因素认证，适合最高安全级别场景。

3.3 性能影响与优化

SSL/TLS 加密对 Kafka 的性能影响主要来自三个方面：CPU 开销（加解密运算）、网络延迟（TLS 握手）和 JVM 堆内存（SSL 缓冲区）。在大多数现代硬件上，启用了 AES-NI 指令集的 CPU 处理 TLS 加解密的额外开销在 5%-15% 之间。对于延迟敏感型业务，可以通过以下方式优化：

# 增大 SSL 网络缓冲区，减少加解密调用次数
ssl.secure.random.implementation=SHA1PRNG

# 启用 TLS 1.3，减少握手往返
ssl.enabled.protocols=TLSv1.3

# Broker 内部通信复用连接
socket.request.max.bytes=104857600

对于跨数据中心的数据复制（MirrorMaker 2），Broker 间的 SSL 连接数量可能成为瓶颈。此时需要权衡是否对 Inter-Broker 通信使用不同的安全协议配置。

4. ACL 权限控制：基于用户、资源与操作的精细授权

认证回答了"你是谁"的问题，而 ACL（Access Control List）回答"你能做什么"。Kafka 的授权系统由 Authorizer 接口实现，默认实现 AclAuthorizer 将 ACL 规则持久化到 ZooKeeper（或 KRaft 元数据日志）中。

4.1 核心概念：Principal、Resource 与 Operation

ACL 规则是一个五元组：Principal, Host, Operation, PermissionType, Resource。

• Principal（主体）：格式为 User:username，由认证模块提供。SASL/SCRAM 认证的用户 alice 对应的 Principal 是 User:alice。
• Host（主机）：规则适用的客户端 IP 或通配符 *。可以限制特定用户只能从特定 IP 段访问 Kafka。
• Operation（操作）：具体的操作类型，包括 Read、Write、Create、Delete、Alter、Describe、DescribeConfigs、AlterConfigs、ClusterAction、IdempotentWrite、All。
• PermissionType（权限类型）：Allow 或 Deny。Deny 具有更高优先级。
• Resource（资源）：ACL 施加的目标，分为四类：Topic、Group、Cluster、TransactionalId。

4.2 ACL 操作实战

Kafka 提供 kafka-acls.sh 工具管理 ACL 规则。以下是生产环境中最常见的 ACL 操作场景。

为某个用户授予特定 Topic 的生产和消费权限：

# 允许 alice 对订单 Topic 进行生产和消费
kafka-acls.sh --bootstrap-server broker1:9093 \
  --add --allow-principal User:alice \
  --operation Read --operation Write \
  --topic orders \
  --command-config admin.properties

# 允许 alice 加入消费者组 order-group
kafka-acls.sh --bootstrap-server broker1:9093 \
  --add --allow-principal User:alice \
  --operation Read \
  --group order-group \
  --command-config admin.properties

为管理员授予集群级权限：

# 允许 admin 用户创建 Topic、修改配置、查看集群信息
kafka-acls.sh --bootstrap-server broker1:9093 \
  --add --allow-principal User:admin \
  --operation Create --operation Alter --operation Delete --operation Describe \
  --topic '*' \
  --command-config admin.properties

# 允许 admin 进行集群管理操作
kafka-acls.sh --bootstrap-server broker1:9093 \
  --add --allow-principal User:admin \
  --operation ClusterAction \
  --cluster \
  --command-config admin.properties

列出和删除 ACL 规则：

# 列出所有 ACL 规则
kafka-acls.sh --bootstrap-server broker1:9093 \
  --list --command-config admin.properties

# 查看特定主体的权限
kafka-acls.sh --bootstrap-server broker1:9093 \
  --list --principal User:alice --command-config admin.properties

# 删除 alice 对 orders Topic 的写权限
kafka-acls.sh --bootstrap-server broker1:9093 \
  --remove --allow-principal User:alice \
  --operation Write --topic orders \
  --command-config admin.properties

4.3 权限矩阵设计建议

在为团队设计 Kafka ACL 策略时，建议遵循最小权限原则（Principle of Least Privilege）。以下是一个典型的多团队场景权限矩阵：

对于幂等性生产者（Idempotent Producer），还需要额外的集群级权限：

kafka-acls.sh --bootstrap-server broker1:9093 \
  --add --allow-principal User:order-service \
  --operation IdempotentWrite \
  --cluster \
  --command-config admin.properties

对于使用事务性消息的 Producer，需要分配 TransactionalId 的权限：

kafka-acls.sh --bootstrap-server broker1:9093 \
  --add --allow-principal User:order-service \
  --operation Write --operation Describe \
  --transactional-id order-tx-* \
  --command-config admin.properties

4.4 超级用户与 Deny 规则

在 ACL 体系中，超级用户（Super User）可以绕过所有权限检查。在 server.properties 中配置：

super.users=User:admin;User:cluster-operator

同时，allow.everyone.if.no.acl.found 控制当资源没有任何 ACL 规则时的默认行为：

# 安全模式下设 false：无 ACL = 无权限
allow.everyone.if.no.acl.found=false

# 过渡期可设 true：无 ACL = 允许任何人
allow.everyone.if.no.acl.found=true

Deny 规则在某些场景下非常有用。例如，禁止特定用户访问敏感数据主题：

kafka-acls.sh --bootstrap-server broker1:9093 \
  --add --deny-principal User:intern \
  --operation Read --operation Write \
  --topic pci-sensitive-data \
  --command-config admin.properties

ACL 的匹配逻辑是：先检查所有匹配的 Deny 规则，如果存在则拒绝；再检查 Allow 规则，如果存在则允许；如果没有任何规则匹配且 allow.everyone.if.no.acl.found=false，则拒绝。

5. 安全配置的完整实战

以下是一个三节点生产集群的完整安全配置示例，采用 SASL/SCRAM + SSL + ACL 的组合方案。

5.1 Broker 配置

# server.properties
broker.id=1
listeners=SASL_SSL://:9093
advertised.listeners=SASL_SSL://broker1.example.com:9093

# 内部通信协议
security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
sasl.enabled.mechanisms=SCRAM-SHA-256,SCRAM-SHA-512

# Inter-broker JAAS
listener.name.sasl_ssl.scram-sha-512.sasl.jaas.config=\
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="admin" \
  password="admin-secret";

# SSL 配置
ssl.keystore.location=/etc/kafka/ssl/kafka.server.keystore.jks
ssl.keystore.password=${file:/etc/kafka/ssl/keystore-passwd:keystorePassword}
ssl.key.password=${file:/etc/kafka/ssl/keystore-passwd:keyPassword}
ssl.truststore.location=/etc/kafka/ssl/kafka.server.truststore.jks
ssl.truststore.password=${file:/etc/kafka/ssl/truststore-passwd:truststorePassword}
ssl.client.auth=required
ssl.protocol=TLS
ssl.enabled.protocols=TLSv1.3
ssl.endpoint.identification.algorithm=HTTPS

# ACL 授权
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=User:admin;User:kafka
allow.everyone.if.no.acl.found=false

# ZooKeeper/KRaft 安全配置（ZooKeeper 模式下）
zookeeper.set.acl=true
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty

注意配置中使用了 ${file:...} 语法从外部文件中读取密码，避免将密码明文写入配置文件。Kafka 支持通过 org.apache.kafka.common.config.ConfigProvider 接口将密码存储在外部秘密管理器中（如 HashiCorp Vault、AWS Secrets Manager）。

5.2 客户端配置

Producer 安全配置：

# producer.properties
bootstrap.servers=broker1.example.com:9093,broker2.example.com:9093,broker3.example.com:9093
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=\
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="alice" \
  password="alice-secret";

# SSL
ssl.truststore.location=/path/to/client.truststore.jks
ssl.truststore.password=clientpass
ssl.endpoint.identification.algorithm=HTTPS

# 生产级优化
acks=all
retries=3
enable.idempotence=true

Consumer 安全配置：

# consumer.properties
bootstrap.servers=broker1.example.com:9093
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=\
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="bob" \
  password="bob-secret";
ssl.truststore.location=/path/to/client.truststore.jks
ssl.truststore.password=clientpass
ssl.endpoint.identification.algorithm=HTTPS

group.id=billing-service
auto.offset.reset=earliest
enable.auto.commit=false

5.3 部署 checklist

将 Kafka 从非安全模式切换到全安全模式时，按以下顺序操作可以降低风险：

1. 备份当前数据：在进行任何安全配置变更前，完整备份 ZooKeeper 数据和 Kafka log.dirs。

2. 分步启用：不要同时启用 SASL、SSL 和 ACL。推荐顺序为：先启用 SSL（监听新的安全端口，保留原有 PLAINTEXT 端口），然后添加 SCRAM 用户，测试客户端连接正常后，再启用 ACL，最后关闭 PLAINTEXT 端口。

3. 逐步建立 ACL 规则：在 allow.everyone.if.no.acl.found=true 的过渡模式下添加所有必要的 ACL 规则，通过 kafka-acls.sh --list 确认规则正确后，再切换到 false。

4. 验证所有客户端：确保所有 Producer、Consumer、Connect、Streams、ksqlDB、MirrorMaker 的客户端都已配置安全参数并运行正常。最容易遗漏的是监控采集端（如 JMX Exporter）和管理工具。

5. 关闭 PLAINTEXT：在所有流量都切换到 SASL_SSL 后，从 listeners 中移除 PLAINTEXT 监听器，重启 Broker 完成安全加固。

6. 数据脱敏与敏感数据保护

认证、加密和 ACL 构成了 Kafka 的网络和访问层安全，但它们无法防止合法消费者访问到包含敏感信息的原始消息内容。数据脱敏（Data Masking）是在应用层保护消费者隐私的最后防线。

6.1 字段级脱敏策略

对于日志、事件流中的敏感字段（如手机号、身份证号、银行卡号、邮箱），应在进入 Kafka 前进行脱敏处理。常见的策略包括：

• 掩码（Masking）：138****1234、身份证号只保留后四位
• 哈希（Hashing）：用 SHA-256 等不可逆算法处理，保留用于关联分析但不暴露原始值
• Tokenization：将敏感值替换为无意义的占位符，真实值存储在安全的 Token Vault 中
• 加密（Field-Level Encryption）：消息中的敏感字段用 AES 等算法单独加密，只有持有密钥的消费者才能解密

在 Kafka 生态中，字段级加密最成熟的方案是结合 Confluent 的 Schema Registry 和 Field-Level Encryption 扩展，或自行在 Producer 端实现加解密拦截器（ProducerInterceptor）。

6.2 使用 Record Header 标记敏感等级

Kafka 消息支持 Headers，可以在不修改消息体的情况下携带元数据。利用这一特性，可以建立数据分类标签体系：

# Producer 发送带敏感标记的消息
kafka-console-producer.sh --bootstrap-server broker1:9093 \
  --topic events \
  --property parse.headers=true \
  --producer.config producer.properties
# 发送：sensitivity:PII\tpayload:{"user_id": "12345", "phone": "encrypted:xxx"}

消费者端可以根据 sensitivity Header 的值决定是否允许解密或是否需要额外的审计日志。

6.3 Topic 隔离与数据生命周期

对于不同安全等级的数据，最可靠的保护方式是物理隔离：

• 基础事件（Public）：普通 ACL 控制的通用 Topic，如页面浏览事件
• 业务数据（Internal）：仅生产服务内部消费的 Topic，如订单状态变更
• 个人隐私数据（Confidential）：单独的 Topic，启用更严格的 ACL、字段级加密和审计日志
• 合规敏感数据（Restricted）：独立集群或独立命名空间，配合数据保留策略和访问日志

数据保留策略（Retention Policy）也是安全的一部分：缩短敏感数据的保留时长，降低泄露窗口。Kafka 的 Topic 级配置 retention.ms 和 retention.bytes 可以精确控制数据生命周期：

# 为个人隐私数据设置 3 天保留期
kafka-configs.sh --bootstrap-server broker1:9093 \
  --entity-type topics --entity-name pii-events \
  --alter --add-config retention.ms=259200000,retention.bytes=1073741824 \
  --command-config admin.properties

7. 总结

Kafka 的安全加固是一个系统工程，需要在认证、加密、授权和应用层保护之间取得平衡。

对于大多数生产环境，SASL/SCRAM-SHA-512 + SSL/TLS + ACL 的组合是最佳平衡点：SCRAM 提供了不需要外部依赖的安全认证，SSL 确保了传输加密和身份验证，ACL 实现了基于用户和资源的细粒度访问控制。这三者的组合足以满足绝大多数中大型企业的合规要求。

对于已经拥有 Kerberos/CDH/AD 基础设施的企业，选择 SASL/GSSAPI + SSL + ACL 可以实现统一身份管理。对于云原生和云中立架构，SASL/OAUTHBEARER 提供了与现代 IAM 基础设施集成的能力。

无论选择哪种认证方式，以下几点是所有 Kafka 安全方案的通用最佳实践：

• 始终启用 ssl.endpoint.identification.algorithm=HTTPS，防止中间人攻击
• 密码和密钥不要明文写入配置文件，使用外部配置提供器或环境变量注入
• 启用 ZooKeeper/KRaft 的 ACL 保护，防止凭据存储层被绕过
• 遵循最小权限原则设计 ACL 矩阵，超级用户列表应严格受限
• 敏感数据在入库前脱敏，不同敏感等级使用 Topic 物理隔离
• 安全变更采用分阶段渐进式部署，避免一次性切断所有客户端

Kafka 的安全配置虽然复杂，但它提供了企业级消息系统所需的所有安全工具。将这些工具正确组合并落地执行，你的 Kafka 集群将不再只是高性能的数据管道，而是一个受控、可信、可审计的企业级数据交换中枢。