最近新闻报道了一个配置错乱的 Elasticsearch 服务器，带着 60 亿条数据（包括银行和个人身份信息），裸奔在公网上了，谁都能匿名访问。
这是典型的 “没上锁，还把家门钥匙插在外边” 的事故。
核心问题不是 ES 软件本身有漏洞，而是网络和安全配置问题导致。
以下是针对 ES 用户，无论版本新旧，你必须立即检查和执行的几个技术动作。
1. 立刻堵死对外端口（网络隔离）
服务器别裸奔在公网上。这事儿没得商量。
检查 network.host
。
你的 elasticsearch.yml
里，network.host
绝对不能是 0.0.0.0
或者直接留空。
只要是生产环境，立马改成内网 IP（比如 10.x.x.x
或 192.168.x.x
），或者直接写 localhost
(127.0.0.1
)。
配置防火墙。
用好云平台的安全组（阿里云、腾讯云等）或者服务器的 iptables
/firewalld
。
9200 和 9300 端口只对特定、受信任的内网应用服务器开放，其他 IP 一律拒绝访问。
自查：
找个公网 IP 的机器，跑个 curl http://你的公网IP:9200
。
如果能拿到集群信息，你的数据就在裸奔。赶紧断网。
2. 强制开启认证和授权
没密码的 ES 集群就是个公共厕所。——话糙理不糙。
ES 8.X / 9.X（新版本）：
安全功能默认是开的，这是好事。但你得确保启动时生成的 elastic
用户强密码你存好了，而且改过默认密码。不要图省事偷懒关掉安全。
ES 7.X：
安全是免费内置的（X-Pack Security Basic）。你需要在 elasticsearch.yml
里明确写上 xpack.security.enabled: true
。然后跑那个 elasticsearch-setup-passwords
工具，把内置用户的密码全都设置好。
权限管理（RBAC）：
给每个应用和用户分配最小权限。别都用 elastic
超级用户去操作。
应用 A 只需要读 logstash-*
索引？那就只给它 reader
角色和对应索引的读权限。
3. 所有通信都加密（TLS/SSL）
即使在内网，传输也必须加密。
节点间通信（9300）：
哪怕是集群内部的节点交流，也应该走 TLS 加密。防止内网有人在嗅探流量。
客户端通信（9200）：
必须用 HTTPS。如果你还在用 HTTP 访问 ES 或 Kibana，就是在裸传数据和密码。赶紧配置证书，切换到 HTTPS。
新版本 ES 默认启动时就会帮你生成证书。
4. 旧版本用户建议（5.X, 6.X）
如果你还在用 5.X、6.X 这种老掉牙的版本，你面对的安全风险是极高的。
立马升级：
6.X 已经停止维护，5.X 更是博物馆文物。它们的安全机制太弱，甚至没有。马上制定计划，升级到 7.17 或 8.X。
这是唯一的长期解决方案。
临时救命措施：
在升级完成前，必须做到最严格的网络隔离。
把 ES 节点藏在最深的内网里，只有通过跳板机或 VPN 才能访问。
5. 运维审计和监控
光配置好还不够，你得知道谁在动你的数据。
（付费版本才有）开审计日志：
启用 X-Pack 的审计日志功能。它会记录所有对集群的请求，包括谁、在什么时候、干了什么操作。这是事后追溯和发现异常行为的唯一凭证。
异常监控：
监控你的 ES 访问日志和指标。如果发现有大量来自不该出现的 IP 的请求，或者有不正常的索引操作（比如删除、大规模导出），立马拉响警报。
总结：
互联网上没有“默认安全”。别指望默认配置能保护你的数据。
我们开发人员和运维人员要对集群的安全配置负全部责任。
