Elasticsearch × Kibana 安全配置实战：从零构建可落地的生产级防护体系
你有没有遇到过这样的场景？
一个刚上线的日志系统，Elasticsearch 直接暴露在内网甚至公网，没有密码、没有加密。开发同事随手用 curl 就能查到所有业务日志，运维人员担心哪天被扫描出端口，数据就被拖走了。
这不是危言耸听。 我曾亲眼见过某公司因未启用 TLS 和 RBAC，导致核心用户行为日志被内部非授权人员批量导出，最终触发合规审计风险 。而这一切，本可以通过一套标准的安全配置避免。
今天，我就带你一步步搭建一个真正“能上生产”的 Elasticsearch + Kibana 安全架构——不讲虚的，只写你能直接抄作业的完整方案。
一、先搞清楚：我们到底在防什么？
别急着改配置文件。在动手之前，我们必须明确目标： 我们的安全防线要挡住哪些威胁？
窃听（Eavesdropping） 数据在节点之间传输是明文？抓个包就能看到敏感内容。→ 需要 TLS 加密
伪装与中间人攻击（MITM） 攻击者伪造一个假 ES 节点加入集群？→ 必须启用 双向证书验证（mTLS）
越权访问（Unauthorized Access） 某个开发只能看自己的服务日志，却能看到支付系统的全部记录？→ 必须实现 RBAC 角色隔离
Kibana 成为跳板 Kibana 配了超级账号，一旦服务器失陷，整个集群就完了 → 要遵循 最小权限原则
出了事没法追责 谁删了索引？谁导出了数据？没人知道 → 必须开启 审计日志
明白了这些，你就不会觉得“加个密码就够了”。真正的安全，是一整套机制的协同工作。
二、第一步：给通信穿上“防弹衣”——启用 TLS/SSL 全链路加密
为什么不能跳过这一步？
Elasticsearch 默认通信是明文的。无论是节点间同步数据（9300 端口），还是你通过浏览器访问 Kibana 查日志（9200 端口），只要在同一网络段，任何人都可以用 Wireshark 抓出来。
解决办法只有一个：全面启用 TLS。
怎么做最省事？用官方工具一键生成证书
Elastic 提供了 elasticsearch-certutil 工具，无需懂 OpenSSL 复杂命令，三步搞定：
# 1. 生成私有 CA（证书颁发机构）
bin/elasticsearch-certutil ca \\
–name my-es-ca \\
–ip \”192.168.10.11,192.168.10.12,192.168.10.13\” \\
–dns \”es-node-1,es-node-2,es-node-3,localhost\” \\
–out config/certs/my-ca.p12
这条命令会创建一个名为 my-es-ca.p12 的 PKCS#12 格式 CA 文件，它将用于签发后续所有节点证书。
🛠️ 小贴士：如果
