1. 课程导入与安全全景

Elastic Stack 从最初的全文检索工具，已经演化为承载日志、指标、链路追踪、安全事件与企业搜索的统一数据平台。一旦它承载了业务日志、用户行为、审计记录甚至个人信息，它就不再只是“一个搜索引擎”，而是一个需要被严肃对待的数据存储与访问系统。本课程讨论的核心问题只有一个：在 Elastic 中，谁，在什么条件下，能对哪些数据，做哪些操作，以及这些行为如何被记录和验证。

这句话拆开来看，包含四个必须同时成立的要素：身份（谁）、授权条件（在什么条件下）、数据范围（哪些数据）和操作类型（读、写、管理、删除）。Elastic 的安全体系正是围绕这四个要素构建的：认证解决“你是谁”，授权解决“你能做什么”，加密解决“传输和存储中是否被窃取”，审计解决“你做过什么”。四者缺一不可，任何一环缺失都会让整体防护失效。

核心目标：从“能访问”到“最小必要访问”

很多团队在初期只关心“集群能不能连上”，于是把安全目标简化为“加个密码”。但真正的安全目标应当是最小权限原则：每个用户、每个服务账号、每个应用，只应拥有完成其职责所必需的最小数据范围和最小操作集合。例如，一个只负责查询近 7 天应用日志的运维看板账号，不应该拥有删除索引的权限，也不应该能读取财务索引。这个目标听起来简单，落地时却需要身份体系、角色设计、索引级权限、字段级权限和文档级权限共同配合。

与之配套的第二个目标是可追溯性。安全事件发生后，必须能回答“谁在什么时间从哪个 IP 访问了哪些索引、执行了什么操作、结果如何”。Elastic 的审计日志和 API 调用记录正是为此服务。没有可追溯性，安全控制就只是“防君子不防小人”的摆设。

威胁模型：先想清楚敌人在哪里

在设计任何访问控制之前，先要明确威胁来源。Elastic 场景下常见的威胁可以归纳为几类：外部未授权访问（集群端口暴露、弱口令、未启用 TLS 导致凭据被嗅探）、内部越权（普通用户通过通配符索引模式读取到敏感索引）、凭据泄露（应用账号密钥硬编码在代码仓库中）、横向移动（一个低权限账号被攻陷后用于探测集群结构）、数据外泄（通过批量查询或快照导出敏感数据）以及配置漂移（临时开放的权限未及时回收）。

这些威胁并不都需要同等强度的防御。合理的做法是先识别高价值数据（如含个人身份信息的索引、审计索引、密钥索引），再针对这些数据设计更严格的访问路径。威胁模型的价值在于：它决定了你把有限的精力放在哪里，而不是平均用力。

整体架构：四层控制如何协同

上图展示了 Elastic 安全体系的四层控制链。请求进入集群时，首先经过认证层确认身份；身份确认后，授权层根据角色和权限规则判断该身份能否对目标索引执行目标操作；数据在传输和落盘过程中由加密层保护；所有关键操作由审计层记录。四层是串联关系：认证失败则后续全部终止，授权拒绝则请求被拦截，加密缺失则凭据可能在中途泄露，审计缺失则事后无法追责。

需要特别注意的是，Elastic 的授权模型是基于角色的。用户不直接绑定权限，而是绑定角色，角色再绑定权限。这种间接层带来了灵活性：同一个角色可以分配给多个用户，权限调整只需改角色。Elastic 内置了若干角色（如 superuser、kibana_admin、viewer），也支持自定义角色。自定义角色可以精确到索引模式、字段和文档查询条件。

一个具体的权限示例

假设有一个名为 app-logs-* 的索引模式，存放应用日志，其中包含 message、level、user_id、ip 等字段。运维看板账号只需要读取近 7 天数据，且不应看到 user_id 字段。可以这样设计角色：

PUT _security/role/app_log_viewer
{
  "indices": [
    {
      "names": ["app-logs-*"],
      "privileges": ["read", "view_index_metadata"],
      "field_security": {
        "grant": ["message", "level", "ip", "@timestamp"],
        "except": ["user_id"]
      },
      "query": {
        "range": {
          "@timestamp": { "gte": "now-7d/d" }
        }
      }
    }
  ]
}

这个角色做了三件事：限定索引范围（app-logs-*）、限定字段（排除 user_id）、限定文档范围（仅近 7 天）。把该角色分配给看板账号后，即使该账号尝试查询 user_id 或更早的数据，Elastic 也会在授权层直接过滤或拒绝。这就是“最小必要访问”的具体落地方式。

学习路径与常见误区

本课程后续将沿着“认证 → 授权 → 加密 → 审计 → 生产加固”的顺序展开。建议的学习路径是：先理解认证机制和内置用户体系，再掌握角色与权限模型，然后深入索引级、文档级和字段级控制，接着配置 TLS 与密钥库，最后学习审计日志的读取与安全排障。

初学者常见的误区有三个：一是认为“启用了 X-Pack Security 就安全了”，实际上默认配置往往过于宽松；二是把 superuser 账号用于日常应用连接，导致权限过大且难以审计；三是只关注外部攻击，忽视内部越权和凭据管理。本课程会在后续章节中逐一纠正这些认知，并给出可执行的配置与验证方法。

安全不是一次性配置，而是一个持续的过程：权限需要定期复核，凭据需要轮换，审计日志需要有人看，配置变更需要被记录。理解这一点，比记住任何单条命令都重要。