Elasticsearch：实战指南——从零构建基于TLS/SSL与PKI的零信任安全架构

张

张建站

2026/5/11 23:24:28

10分钟阅读

Elasticsearch：实战指南——从零构建基于TLS/SSL与PKI的零信任安全架构

1. 为什么Elasticsearch需要零信任安全架构最近几年数据泄露事件频发很多企业开始重新审视内部系统的安全设计。我去年参与过一个金融客户的Elasticsearch安全加固项目他们原本以为内网环境很安全结果因为某个开发人员误操作导致客户数据泄露。这件事让我深刻认识到在现代安全威胁环境下内网不再等于安全。零信任架构的核心思想很简单从不信任始终验证。具体到Elasticsearch场景意味着不再依赖网络边界防护比如认为内网流量就是安全的每次请求都需要验证身份和权限所有通信必须加密采用最小权限原则传统方案通常只做这几件事配置基础认证用户名/密码开启简单的HTTPS依赖网络ACL控制访问但现实中的风险往往来自密码泄露比如代码中硬编码的凭证内部人员滥用权限中间人攻击尤其是跨机房通信时配置错误导致未授权访问实测下来结合TLS/SSL和PKI的方案能有效解决这些问题。比如我们给某电商平台实施的方案在改用客户端证书认证后原先频繁出现的异常登录尝试直接归零。2. 准备工作搭建PKI基础设施2.1 选择适合的CA方案PKI公钥基础设施是整个体系的核心我推荐两种方案自建CA适合中小规模# 安装openssl以CentOS为例 yum install openssl -y # 创建根CA私钥 openssl genrsa -aes256 -out ca.key 4096 # 生成根CA证书 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt商用CA适合合规要求高的场景DigiCertGlobalSignLets Encrypt免费但有效期短曾经有个制造企业客户为了省钱用了自签名证书结果在ISO27001审计时被开了不符合项。如果预算允许建议至少对生产环境使用商业CA。2.2 设计证书层级结构好的PKI设计应该像洋葱一样分层根CA ├── 中间CAElasticsearch专用 ├── 节点证书 ├── 客户端证书 └── 管理员证书这样做的好处是根CA可以离线保存降低泄露风险不同类型证书可以设置不同有效期某个中间CA被吊销不会影响其他业务我曾经见过最夸张的情况是某公司所有服务共用同一个证书结果一个边缘服务被入侵导致全线沦陷。3. Elasticsearch集群的TLS配置实战3.1 生成节点证书每个Elasticsearch节点都需要独立证书# 生成私钥 openssl genrsa -out elasticsearch_node.key 2048 # 创建CSR注意subjectAltName设置 openssl req -new -key elasticsearch_node.key -out elasticsearch_node.csr -subj /CNnode1.example.com -addext subjectAltNameDNS:node1.example.com,DNS:node1,DNS:localhost,IP:192.168.1.100 # 用中间CA签发证书 openssl x509 -req -in elasticsearch_node.csr -CA intermediate.crt -CAkey intermediate.key -CAcreateserial -out elasticsearch_node.crt -days 365 -sha256关键点说明必须包含所有可能的DNS名称和IP地址生产环境建议有效期不超过1年私钥必须设置严格权限chmod 4003.2 配置elasticsearch.yml这是最容易踩坑的部分分享我的经验配置xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.key: /path/to/elasticsearch_node.key xpack.security.transport.ssl.certificate: /path/to/elasticsearch_node.crt xpack.security.transport.ssl.certificate_authorities: [/path/to/intermediate.crt] xpack.security.http.ssl.enabled: true xpack.security.http.ssl.key: /path/to/elasticsearch_node.key xpack.security.http.ssl.certificate: /path/to/elasticsearch_node.crt xpack.security.http.ssl.client_authentication: required xpack.security.authc.token.enabled: false # 禁用密码认证特别注意verification_mode建议用certificate而非full避免主机名校验问题禁用密码认证是零信任的关键一步不同Elasticsearch版本参数可能有差异4. 客户端证书认证实现细节4.1 签发客户端证书和节点证书的主要区别在于扩展用途openssl x509 -req -in client.csr -CA intermediate.crt -CAkey intermediate.key -CAcreateserial -out client.crt -days 90 -sha256 -extfile (echo extendedKeyUsageclientAuth)建议做法为不同部门创建不同中间CA设置更短的有效期如90天在证书中嵌入OU字段标识部门4.2 配置Kibana使用证书认证修改kibana.ymlelasticsearch.ssl.certificateAuthorities: [/path/to/intermediate.crt] elasticsearch.ssl.certificate: /path/to/kibana_client.crt elasticsearch.ssl.key: /path/to/kibana_client.key elasticsearch.username: null # 禁用用户名密码4.3 使用curl测试API访问带证书访问的示例curl --cert ./client.crt --key ./client.key --cacert ./intermediate.crt https://elasticsearch.example.com:9200/_cluster/health调试技巧增加-v参数查看详细握手过程用openssl s_client检查证书链检查Elasticsearch的audit log5. 高级安全加固方案5.1 证书自动轮换方案手动管理证书迟早会出问题推荐两种自动化方案方案一使用cert-managerKubernetes环境apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: elasticsearch-cert spec: secretName: elasticsearch-tls duration: 2160h # 90天 renewBefore: 720h # 到期前30天续期 issuerRef: name: es-ca-issuer kind: ClusterIssuer usages: - server auth - client auth dnsNames: - elasticsearch.example.com方案二使用HashiCorp Vaultvault write pki/issue/elasticsearch \ common_namenode1.example.com \ ttl720h \ formatpem5.2 基于属性的访问控制(ABAC)在证书中嵌入部门信息然后在Elasticsearch中配置角色映射{ role_mappings: { ops_team: { rules: { any: [ { field: { dn: OUDevOps,DCexample,DCcom } } ] }, roles: [superuser] } } }5.3 安全监控与告警建议监控这些关键指标证书过期时间用Elasticsearch自己的监控就行异常证书使用行为如非工作时间访问证书吊销列表(CRL)更新状态配置示例PUT _watcher/watch/cert_expiry { trigger: { schedule: { interval: 1d } }, input: { search: { request: { indices: [.monitoring-es-*], body: { query: { range: { nodes.ssl.cert.expiry: { lte: now30d } } } } } } } }6. 常见问题排查指南问题1证书验证失败检查证书链是否完整openssl verify -CAfile确认时间是否同步NTP问题很常见检查subjectAltName是否包含所有可能的主机名问题2性能下降明显测试TLS性能影响建议用基准测试工具考虑启用TLS会话恢复调整密码套件避免使用RSA2048以上问题3客户端无法连接检查防火墙规则包括selinux/apparmor确认客户端证书的extendedKeyUsage包含clientAuth查看Elasticsearch的SSL日志日志级别调到DEBUG问题4证书吊销问题配置OCSP响应器定期生成CRL并配置到Elasticsearch考虑使用短有效期证书替代吊销机制7. 实际案例某金融机构实施过程去年我们为一家银行实施了这套方案他们的特殊需求包括必须使用硬件安全模块(HSM)存储CA密钥证书有效期不得超过30天所有访问行为需要双重审计实施过程中的关键点使用Thales HSM保护根CA搭建自动化的证书签发流水线在Elasticsearch前部署双向TLS代理集成现有的SIEM系统最终效果安全事件响应时间从4小时缩短到15分钟内部审计通过率从70%提升到100%运维效率反而提高了不再需要处理密码重置这个案例给我的启示是安全性和便利性不是对立的好的设计可以兼得。现在这个客户已经把这套模式推广到了其他数据库系统。