企业级 Elastic Stack 安全实践：为什么以及如何配置加密 ES 集群及全组件对接

企业级 Elastic Stack 安全实践：为什么以及如何配置加密 ES 集群及全组件对接

---

一、 为什么 Elasticsearch 需要配置加密集群？

在默认情况下，Elasticsearch 未开启任何安全机制，节点间通信和客户端访问均采用明文传输。在企业级生产环境中，不配置加密将面临以下重大安全隐患：

1. 数据明文传输泄露（Sniffing）：
   业务日志中经常包含敏感信息（如用户手机号、身份证、交易密码、API 密钥等）。若未开启 HTTP 加密，网络监听者（如内网恶意攻击者或被渗透的相邻节点）可以通过简单的抓包工具（如 Wireshark）直接获取明文日志和登录凭证。
2. 非法节点恶意加入（Rogue Nodes）：
   在未开启 Transport 传输层加密的情况下，集群对加入的节点不进行身份校验。任何知道您集群名称（cluster.name）且内网互通的服务器，都可以启动一个 ES 进程加入您的集群，从而自动同步并窃取所有索引数据，甚至执行破坏性的删除操作。
3. 行业合规与法规约束：
   国家网络安全等级保护（等保）、GDPR、PCI-DSS 等安全合规标准均明确要求：涉及敏感数据在网络传输时必须进行加密保护。未配置加密的集群通常无法通过合规审计。
4. 缺乏精细化的权限控制（RBAC）：
   不开启安全插件意味着所有人均拥有 superuser 权限，无法实现“开发人员只读、运维人员可写、审计人员只看审计日志”的最小权限原则。

---

二、 第一阶段：如何配置 ES 加密集群？

为了保障全组件（尤其是不具备 JVM 环境的 Go 语言组件 Filebeat）的兼容性，我们采用 PEM 格式证书 来配置集群。

1. 生成自签 CA 证书与节点证书

在其中一台 ES 节点上，进入安装根目录执行：

# 生成 PEM 格式的全局 CA 证书
./bin/elasticsearch-certutil ca --pem

# 解压 CA 压缩包
unzip elastic-stack-ca.zip

# 基于生成的 CA 为节点签发证书
./bin/elasticsearch-certutil cert --ca-cert ca/ca.crt --ca-key ca/ca.key --pem --name elastic-nodes

# 解压节点证书压缩包
unzip elastic-certificates.zip

2. 分发证书并配置权限

将生成的 ca/ca.crt、elastic-nodes/elastic-nodes.crt 和 elastic-nodes/elastic-nodes.key 拷贝至所有 ES 节点的 /etc/elasticsearch/certs/ 目录下，并设置安全权限：

chmod 600 /etc/elasticsearch/certs/*
chown -R elasticsearch:elasticsearch /etc/elasticsearch/certs/

3. 配置 elasticsearch.yml

修改所有节点的配置文件，启用安全认证并指向证书路径：

# ======================== Security Settings ========================
# 1. 开启安全认证
xpack.security.enabled: true

# 2. 开启 Transport 层加密（节点间通信，9300 端口）
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.key: certs/elastic-nodes.key
xpack.security.transport.ssl.certificate: certs/elastic-nodes.crt
xpack.security.transport.ssl.certificate_authorities: [ "certs/ca.crt" ]

# 3. 开启 HTTP 层加密（客户端/API通信，9200 端口）
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.verification_mode: certificate
xpack.security.http.ssl.key: certs/elastic-nodes.key
xpack.security.http.ssl.certificate: certs/elastic-nodes.crt
xpack.security.http.ssl.certificate_authorities: [ "certs/ca.crt" ]

配置完成后，启动所有 ES 节点。

4. 初始化内置账户密码

ES 启动成功后，执行以下命令，为系统账户及管理员初始化密码（建议使用交互式 -i 自定义密码）：

# 1. 修改管理员 elastic 的密码
./bin/elasticsearch-reset-password -u elastic -i

# 2. 修改 Kibana 系统同步账号 kibana_system 的密码
./bin/elasticsearch-reset-password -u kibana_system -i

请记录好以上设置的密码。

---

三、 第二阶段：全组件对接加密集群配置

因为 Elasticsearch 开启了 HTTP TLS 加密，所有的客户端组件（Kibana、Logstash、Filebeat）在通过 HTTPS 协议访问 ES 时，必须显式信任签发 ES 证书的 CA（即 ca.crt），否则会触发“自签名证书不被信任”的安全报错。

请将第一步中生成的 ca.crt 证书拷贝至 Kibana、Logstash、Filebeat 所在的服务器中。

---

1. Kibana 对接加密集群配置

Kibana 作为前端展示层，必须使用专属的 kibana_system 系统账号与 ES 进行通信。

• 证书放置路径：/etc/kibana/certs/ca.crt
• 配置文件 /etc/kibana/kibana.yml：

# 使用 https 连接 ES 集群
elasticsearch.hosts: ["https://192.168.1.10:9200", "https://192.168.1.11:9200"]

# 配置专门的系统连接账户与密码（切勿配置为 elastic）
elasticsearch.username: "kibana_system"
elasticsearch.password: "您的kibana_system密码"

# 导入 CA 证书，使 Kibana 信任 ES
elasticsearch.ssl.certificateAuthorities: [ "/etc/kibana/certs/ca.crt" ]

# 由于使用的是自签证书，设为 certificate 以忽略主机名/IP不匹配的报错，但保留证书完整性校验
elasticsearch.ssl.verificationMode: certificate

---

2. Logstash 对接加密集群配置

Logstash 作为集中式清洗中心，向 ES 写入数据时需要具备写索引的权限。

• 证书放置路径：/etc/logstash/certs/ca.crt
• 管道配置文件 /etc/logstash/conf.d/prod.conf 中的 Output 部分：

output {
  elasticsearch {
    # 1. 采用 https 协议
    hosts => ["https://192.168.1.10:9200", "https://192.168.1.11:9200"]
    
    # 2. 配置账号与密码（生产环境建议在 ES 中创建定制的 logstash_writer 角色与用户）
    user => "elastic"
    password => "您的elastic密码"
    
    # 3. 开启 SSL/TLS 安全通信
    ssl => true
    ssl_certificate_verification => true
    
    # 4. 指定 CA 证书路径，建立信任关系
    cacert => "/etc/logstash/certs/ca.crt"
    
    index => "app-log-%{+YYYY.MM.dd}"
  }
}

---

3. Filebeat 对接加密集群配置

Filebeat 部署在业务主机边缘，直接通过 HTTPS 协议向加密集群写入数据。

• 证书放置路径：/etc/filebeat/certs/ca.crt
• 配置文件 /etc/filebeat/filebeat.yml：

# ================================= Outputs ====================================
output.elasticsearch:
  # 1. 采用 https 协议
  hosts: ["https://192.168.1.10:9200", "https://192.168.1.11:9200"]
  
  # 2. 配置账号与密码（生产环境建议在 ES 中创建定制的 filebeat_writer 角色与用户）
  username: "elastic"
  password: "您的elastic密码"
  
  # 3. 配置 SSL 通信
  ssl.enabled: true
  
  # 4. 忽略自签证书域名/IP不匹配问题，但保留证书可信度校验
  ssl.verification_mode: "certificate"
  
  # 5. 指定信任的 CA 证书路径
  ssl.certificate_authorities: ["/etc/filebeat/certs/ca.crt"]

注意：Filebeat 配置完成后，请务必将其配置文件的权限设置为 600，否则服务将因权限过于宽松而拒绝启动：
chown root:root /etc/filebeat/filebeat.yml && chmod 600 /etc/filebeat/filebeat.yml

---

四、 生产环境安全最佳实践建议

1. 遵循最小权限原则（RBAC）：
   本文在 Logstash 和 Filebeat 的配置中使用了超级管理员 elastic 账号进行演示。在实际生产环境中，强烈建议在 Kibana 控制台的「Stack Management -> Users / Roles」中为 Filebeat 和 Logstash 创建专用的写入用户（赋予 write、create_index 等最小必要权限），防止高权限账号泄露导致整个集群失控。
2. 证书定期轮转（Rotation）：
   自签证书在创建时通常有 3 年或 5 年的有效期。建议企业建立证书到期提醒机制，并在过期前通过无缝替换机制（通常支持热更新或滚动重启）更换新证书。
3. 内网网络隔离：
   虽然开启了 TLS 加密，但依然建议配合物理网络隔离、安全组（Security Groups）或防火墙（Firewalld），仅允许可信的内网段或指定中继服务器（如堡垒机）访问 ES 的 9200 和 9300 端口。

---

五、 结语

通过配置 双层传输加密（Transport + HTTP） 并对 Filebeat、Logstash、Kibana 进行联动配置，我们构建起了一套坚固的 Elastic Stack 安全防线。这不仅消除了敏感数据在内网明文传输的安全隐患，也有效防止了外部非法节点的恶意侵入。