Elasticsearch 集群的每一次认证、授权、索引变更和配置修改，理论上都可以被记录为审计事件。问题在于默认配置下这些事件不会进入任何持久化输出，即使开启了安全功能也可能因为事件范围设置过大或过小，最终导致取证时缺少关键链路。审计日志的价值不在于实时阻断，而在于事后还原操作主体、时间点和资源对象，因此配置时必须同时考虑日志完整性、防篡改能力和性能影响。
一、审计日志的定位与启用前提
Elasticsearch 审计日志属于安全功能的组成部分，它记录的是围绕认证、授权和系统安全配置发生的事件。与慢日志关注查询耗时、GC 日志关注内存回收不同，审计日志回答的是谁在什么时候通过什么方式访问了什么资源，以及这次访问是否被允许。对于需要满足等保、GDPR、HIPAA 或内部安全规范的集群来说，审计日志通常不是可选项，而是合规基线的一部分。
启用审计日志需要有效的白金或企业级许可证，基础免费版本不包含完整的审计输出能力。配置入口集中在 xpack.security.audit 命名空间下，最核心的开关是 xpack.security.audit.enabled。该参数可以在 elasticsearch.yml 中静态设置，也可以通过集群动态设置临时开启，但动态设置只能调整一部分参数，静态参数建议写入节点配置文件，避免节点重启后配置丢失。
默认情况下审计功能虽然可以接收安全事件，但并不会将这些事件写入任何输出目标。必须显式配置 xpack.security.audit.outputs，可选值为 logfile 和 index。前者把审计事件写入节点的专用审计日志文件，后者把事件作为文档写入 Elasticsearch 索引。两个输出可以同时启用，也可以只保留一个。下面的配置片段演示了最基础的启用方式：
# elasticsearch.yml xpack.security.audit.enabled: true xpack.security.audit.outputs: [ logfile ] xpack.security.audit.logfile.events.include: - authentication_failed - access_denied - connection_denied - security_config_change
这段配置只记录认证失败、访问拒绝、连接拒绝和安全配置变更四类事件。之所以没有开启全部事件，是因为审计日志的写入量会随着事件范围扩大而迅速增长，尤其是记录每一次成功查询或成功认证的场景，很容易在繁忙集群中制造明显的 I/O 压力。启用前先明确最低合规要求，比盲目开启全部事件更加稳妥。
二、事件类型选择与过滤策略
审计事件类型的完整列表覆盖了认证成功、认证失败、访问授予、访问拒绝、连接拒绝、系统访问授予、安全配置变更以及请求体篡改等。对于大多数安全审计场景，认证失败和访问拒绝是必须保留的基础事件，它们能直接反映暴力破解尝试和越权访问行为。安全配置变更同样值得记录，例如角色、用户、API Key 的创建与删除，这些操作通常只应由少数管理员执行，一旦出现异常变更需要立即发现。
事件范围通过 xpack.security.audit.logfile.events.include 和 xpack.security.audit.logfile.events.exclude 控制。include 列表定义哪些事件需要写入，exclude 列表则从已包含的事件中再排除指定类型。如果只配置 exclude 而不配置 include，不同的 Elasticsearch 版本可能会有不同的默认行为，因此建议显式声明 include，避免依赖默认值。下面的示例展示了更完整的事件选择以及用户和请求过滤：
xpack.security.audit.logfile.events.include: - authentication_success - authentication_failed - access_granted - access_denied - system_access_granted - security_config_change xpack.security.audit.logfile.events.ignore_users: - elastic_agent - monitoring_user xpack.security.audit.logfile.events.ignore_requests: - "*_bulk" - "GET /_cluster/health"
ignore_users 用来排除内部服务账号产生的重复事件。例如监控组件、日志采集 Agent 或自动化巡检脚本通常会在短时间内产生大量访问，把这些账号写入忽略列表可以显著减少日志噪音，同时不影响对真实用户行为的审计。需要特别注意的是，忽略规则也意味着这些账号的操作不会被记录，因此不要将可能被攻击者利用的通用账号加入忽略列表。
ignore_requests 适合过滤已知高频且风险较低的请求路径，比如集群健康检查或某些批量写入操作。过滤时最好使用足够具体的模式，避免大范围匹配导致审计盲区。对于涉及敏感索引的查询和写入操作，即使频率较高也不应轻易排除，否则一旦发生数据泄露，将无法从审计日志中还原访问路径。
另一个与数据敏感度相关的参数是 emit_request_body。开启后审计日志会记录请求体内容，这在调试认证和授权问题时非常有用，但请求体可能包含个人隐私、业务数据或凭据信息。生产环境如果开启该选项，必须配合日志脱敏和严格的访问控制，否则审计日志本身可能变成新的泄露点。
三、输出方式、轮转与保留策略
输出到 logfile 是最常见的做法。审计日志会写入 Elasticsearch 日志目录下的独立文件，默认文件名为 elasticsearch_access.log，滚动策略由 Log4j 配置控制。这种方式实现简单、对集群内部存储没有额外压力，但日志文件分散在各个节点上，跨节点检索时效率较低。对于小规模集群或已有集中式日志平台的团队，文件输出配合 Filebeat 或 Logstash 采集是较成熟的方案。
输出到 index 则把审计事件直接写入 Elasticsearch 索引，默认使用 .ds-audit-* 数据流。这样可以直接用 Elasticsearch 的查询和聚合能力分析审计数据，但审计索引会占用集群的计算和存储资源。如果被审计的集群本身就是核心生产集群，建议把审计索引写到独立的审计集群，或者至少使用独立数据节点和独立磁盘，防止审计写入与业务查询争抢 I/O。
不管使用哪种输出，都需要为审计日志定义保留周期。合规要求通常规定日志至少保留 90 天、180 天或更长时间。文件输出可以依赖外部日志归档系统，索引输出则适合用 ILM 策略自动滚动和删除。以下示例创建了一个简单的 ILM 策略，用于每天或每 50GB 滚动一次，并在 90 天后删除：
PUT _ilm/policy/audit-log-policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_age": "1d",
"max_size": "50gb"
}
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}
如果选择将审计日志输出到独立集群，还需要保证传输链路安全，避免日志在节点之间被截获或篡改。审计日志一旦被攻击者删除或修改，整个安全审计链路就会失去可信度。因此独立存储、最小权限访问和定期归档是审计日志管理的基本要求。
四、性能优化与安全告警联动
审计日志必然带来额外开销，但可以通过异步写入、批量提交和合理过滤把影响控制在可接受范围。输出到索引时，xpack.security.audit.index.bulk_size 控制批量提交的文档数，xpack.security.audit.index.flush_interval 控制刷新间隔。适当增大批量大小可以降低写入频率，但会延迟审计日志的可检索时间。对于取证场景，延迟几秒通常可以接受；对于实时告警场景，则需要兼顾及时性。
在性能敏感的环境中，可以先开启认证失败和访问拒绝这两类低频率但高价值的事件，观察审计日志写入速率和集群资源变化，再逐步增加事件类型。如果直接开启访问授予事件，查询密集型业务可能让审计日志量达到每秒数万条，甚至超过业务数据本身的写入量，这种情况下过滤策略比扩大硬件资源更有效。
审计日志的最终价值需要通过分析才能体现。可以使用 Watcher 或外部 SIEM 对审计索引进行持续监控，例如统计 15 分钟内认证失败次数，超过阈值时触发告警。以下查询演示了如何按用户聚合认证失败事件：
GET .ds-audit-log-*/_search
{
"size": 0,
"query": {
"bool": {
"filter": [
{ "term": { "event.type": "authentication_failed" } },
{ "range": { "@timestamp": { "gte": "now-15m" } } }
]
}
},
"aggs": {
"failed_by_user": {
"terms": {
"field": "user.name",
"size": 20
}
}
}
}
当某个用户短时间内出现大量认证失败时，可能意味着口令爆破攻击；当某个普通角色突然出现安全配置变更记录时，可能意味着权限被非法提升。把这些规则固化到告警系统中，审计日志就从被动记录变成了主动防护的一部分。最终目标是让每一次敏感操作都有完整、可信、可检索的日志留痕，同时不让日志采集成为集群不可承受的负担。
Elasticsearch_审计日志安全审计audit_logging修改时间：2026-08-16 02:47:38