📚 课程目录第2章 Elastic安全基础

2. Elastic安全基础

在 Elasticsearch 中谈“安全”，不能只把它理解成“加个用户名密码”。Elastic 的安全体系是分层设计的：从整个集群的准入控制，到单个节点的身份与角色，再到节点之间通信的加密，最后到客户端访问 HTTP 接口时的认证与授权。这四层各司其职，又彼此依赖。理解它们的分工和配置入口，是后续做证书、角色、API Key、审计等实操的前提。

本节先建立一张“分层地图”，再逐层说明每层保护什么、由谁负责、配置写在哪里。

集群安全：总开关与全局策略

集群安全是 Elastic 安全体系的“总开关”。在 7.x 之后，安全功能默认随发行版提供，但需要显式启用。最核心的配置项是 xpack.security.enabled，它位于 elasticsearch.yml 中。一旦设为 true，集群就会要求所有入站请求经过认证，并启用角色授权、审计日志等能力。

集群安全还负责定义全局的认证域（realm），例如 native、ldap、saml、pki 等。这些域决定了“用户从哪里来、如何被验证”。例如，使用内置用户库时，native 域是默认启用的；如果企业已有 LDAP，则可以在集群级别挂载 ldap 域，让所有节点共享同一套认证源。

集群安全是“策略层”，它不直接加密流量，而是决定“谁可以进来、以什么身份进来”。传输层和 HTTP 层的 TLS 是“通道层”，负责把数据加密后再传输。两者配合，才能既保证身份可信，又保证内容不被窃听。

节点安全：身份、角色与证书

节点安全关注的是“每个节点是谁”。在集群中，每个节点都需要一个唯一标识，通常由 node.name 指定。更重要的是 node.roles，它决定该节点承担哪些职责，例如 master、data、ingest、ml 等。角色划分本身就是一种安全边界：把 master 节点与 data 节点分离，可以避免数据节点被攻破后直接影响集群元数据。

节点安全的另一个关键点是证书。在启用 TLS 的集群中，每个节点都需要一份由同一 CA 签发的证书。这份证书在传输层握手时用于证明“我是合法节点”。配置入口包括：

node.name: node-1
node.roles: [ master, data, ingest ]

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.verification_mode: certificate

这里 verification_mode 建议使用 certificate 或 full。certificate 只验证证书是否由可信 CA 签发；full 还会校验主机名，安全性更高，但要求证书 SAN 中包含节点主机名或 IP。生产环境推荐 full。

传输层安全：节点间通信的加密与验证

传输层安全保护的是节点之间 9300 端口的内部通信。Elasticsearch 集群内部有大量敏感数据流动：集群状态、分片分配、索引数据复制、心跳检测等。如果这些流量不加密，攻击者一旦进入内网，就可以窃听甚至篡改集群元数据。

传输层 TLS 的配置入口集中在 xpack.security.transport.ssl.* 下。关键参数包括：

enabled：是否启用传输层 TLS，生产环境必须为 true。
keystore.path：节点自己的密钥库，包含私钥和证书。
truststore.path：信任库，包含签发节点证书的 CA 证书。
verification_mode：验证模式，full 最严格。
client_authentication：是否要求对端提供证书，通常设为 required。

一个常见的教学示例是：用 elasticsearch-certutil 生成一个 CA，再为每个节点签发证书，最后把 CA 证书导入 truststore。这样，任何没有合法证书的节点都无法加入集群，从而防止“伪造节点”攻击。

传输层 TLS 一旦启用，所有节点必须使用同一 CA 签发的证书，且 verification_mode 要一致。如果某个节点证书过期或 SAN 不匹配，该节点将无法加入集群，表现为连接被拒绝或握手失败。排查时应优先检查证书有效期和 SAN 字段。

HTTP 层安全：客户端访问的加密与认证

HTTP 层安全保护的是客户端到 9200 端口的 REST 访问。这是最常被外部接触的入口，也是安全配置的重点。HTTP 层 TLS 的配置入口是 xpack.security.http.ssl.*，参数结构与传输层类似：

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: certs/http.p12
xpack.security.http.ssl.truststore.path: certs/http.p12
xpack.security.http.ssl.client_authentication: optional

与传输层不同的是，HTTP 层的 client_authentication 通常设为 optional 或 none，因为大多数客户端使用用户名密码或 API Key 认证，而不是客户端证书。如果企业要求双向 TLS（mTLS），则可以设为 required，此时客户端也必须提供证书。

HTTP 层安全还与认证域紧密配合。当客户端发起请求时，Elasticsearch 会依次尝试各个认证域：先看是否携带客户端证书（pki 域），再看是否携带 Bearer Token（token 域），最后看用户名密码（native 或 ldap 域）。一旦某个域认证成功，就会生成一个认证对象，后续的授权决策都基于这个对象。

四层协同：一个请求的完整安全路径

把四层串起来看，一个外部请求进入 Elasticsearch 的典型路径是：

客户端通过 HTTPS 访问 9200 端口，HTTP 层 TLS 负责加密通道。
HTTP 层根据请求携带的凭证，调用集群安全定义的认证域进行身份验证。
认证成功后，集群安全根据角色映射和权限策略进行授权判断。
如果请求需要转发到其他节点，传输层 TLS 负责加密节点间通信。
目标节点通过传输层证书验证请求来源的合法性，再执行具体操作。

这五步中，任何一步失败都会导致请求被拒绝。例如，HTTP 层证书过期会导致客户端无法建立连接；传输层证书不匹配会导致节点无法加入集群；认证域配置错误会导致用户无法登录。因此，排查安全问题时，建议按“HTTP 层 → 集群安全 → 传输层 → 节点安全”的顺序逐层检查。

配置入口速查：集群安全在 elasticsearch.yml 的 xpack.security.enabled；节点安全在 node.name、node.roles 和 xpack.security.transport.ssl.*；传输层在 xpack.security.transport.ssl.*；HTTP 层在 xpack.security.http.ssl.*。所有证书相关路径都相对于 Elasticsearch 的配置目录或绝对路径。

理解这四层的分工与配置入口后，后续做证书签发、角色定义、API Key 管理、审计日志分析时，就能清楚知道每一步操作影响的是哪一层，以及出问题时应该先看哪个配置文件、哪个日志、哪个端口。这是 Elastic 安全体系从“知道有安全功能”走向“能独立配置和排障”的关键一步。