Elasticsearch Audit Logging 解説:セキュリティ監視とコンプライアンスのための第一歩

Tech Blog header with a futuristic circuit background and cityscape, showing the bold title 'Elasticsearch Audit Logging 解説' and a Japanese subtitle; vertical 'Tech Blog' label on the right. BLOG

はじめに

システムのセキュリティを確保する上で、「誰が、いつ、何をしたか」を正確に記録する 監査ログ(Audit Logs) は欠かせません。 特に機密性の高いデータを扱う Elasticsearch クラスターにおいて、 監査ログは不正アクセスの検知やコンプライアンス要件(SOC2、PCI-DSSなど)の達成に不可欠な機能です。

本記事では、Elasticsearch の Audit Logging の仕組み、主要なイベントタイプ、そして運用上のベストプラクティスについて詳しく解説します。 検証環境今回の解説にあたり、以下の環境で動作を確認しています。

  • Elasticsearch バージョン: 9.4.0
  • デプロイ形態: Self-Managed (Docker コンテナ)
  • ライセンス: Enterprise (Trial)
    • ※ 監査ログ機能は Enterprise ライセンスでのみ提供されます。
  • ログ出力先: JSON ファイル

検証用リソース

今回の検証で使用した docker-compose.yml や設定ファイル一式は、以下の GitHub リポジトリで公開しています。

elastic-blogs/2026-05-audit-logging at main · SIOS-Technology-Inc/elastic-blogs
A sample code for blogs about Elastic. Contribute to SIOS-Technology-Inc/elastic-blogs development by creating an accoun...

1. Audit Logging とは何か?

Elasticsearch の監査機能(Audit Logging)は、クラスター内で発生するセキュリティ関連のイベントを記録する機能です。 これには、認証の成功・失敗、インデックスへのアクセス、セキュリティ設定の変更などが含まれます。

この機能は Elasticsearch の「Security」スタックの一部として提供されており、設定を有効にすることで利用可能になります。

2. 監査ログを有効にする方法

監査ログはデフォルトでは 無効 です。 有効化するには elasticsearch.yml に設定を追加し、ノードを再起動する必要があります。

elasticsearch.yml の設定例

# 監査ログを有効化
xpack.security.audit.enabled: true

# 検証用:実行されたクエリ本文(request.body)も記録する
xpack.security.audit.logfile.events.emit_request_body: true

# 全てのイベントタイプを対象にする(運用時は絞り込みを推奨)
xpack.security.audit.logfile.events.include: _all

※GitHub のサンプルでは、docker-compose.yml ファイルで上記を定義しています。

[!CAUTION]

emit_request_body を true にすると、クエリに含まれる機密情報(個人情報など)がそのままログに出力される可能性があります。 本番環境での利用には十分注意してください。

Docker 環境でのログ出力設定

今回は Docker コンテナを利用しており、ログ出力を適切に制御するために $ES_HOME/config/log4j2.properties を編集し、 /usr/share/elasticsearch/logs/<クラスター名>_audit.json に出力されるよう構成しています。

3. 主要な監査イベントの種類

記録されるイベントの中でも、特に運用監視で重要なものを紹介します。

イベント名内容監視のポイント
access_granted操作が許可された正常なアクセス。特権操作の追跡に利用。
access_denied操作が拒否された権限不足の確認。短時間の多発は攻撃の予兆。
authentication_failed認証に失敗した不正なログイン試行、またはアプリの設定ミス。
authentication_success認証に成功した特権ユーザー(elastic 等)のログイン監視に。
security_config_changeセキュリティ設定変更ロールやユーザー定義の変更。内部不正防止に重要。

4. ログ構造の理解(JSON 形式)

監査ログは構造化された JSON 形式で出力されるため、SIEM や Kibana での解析が容易です。

  • timestamp: イベント発生時刻
  • event.action: イベントの種類(access_granted など)
  • user.name: 操作を行ったユーザー名
  • origin.address: リクエスト送信元の IP アドレスとポート
  • action: 実行された内部アクション(indices:data/read/search など)
  • url.path: リクエスト先のパス
  • request.body: 実行されたクエリ内容(設定時のみ出力)

5. 実際の Audit Log サンプル

ここでは、具体的な操作とそれに対応するログの出力を確認します。

※今回の検証環境では、/usr/share/elasticsearch/logs/<クラスター名>_audit.json ファイルに出力されます。

5.1. 認証失敗(存在しないユーザー / パスワード間違い)

ユーザー名やパスワードを間違えた場合、event.action: “authentication_failed” が記録されます。

実行コマンド:

curl -X GET -u dummy:password --cacert ./certs/ca/ca.crt https://localhost:9200/

出力ログ(抜粋):

{
  "type":"audit",
  "timestamp":"2026-04-30T01:22:22,842+0000",
  "event.action":"authentication_failed",
  "user.name":"dummy",
  "origin.address":"192.168.143.2:35134",
  "url.path":"/",
  "request.method":"GET"
}

補足:

ログ上はユーザー名間違いとパスワード間違いを区別できませんが、user.name を確認することで、既存ユーザーへの攻撃か未知のユーザーによるものかを判断できます。

5.2. 権限のないインデックスへのアクセス

認証には成功しているものの、操作権限がない場合は access_denied となります。

実行コマンド:

# guest1 ユーザー(閲覧権限なし)で検索を実行
curl -X GET -u guest1:password --cacert ./certs/ca/ca.crt "https://localhost:9200/kibana_sample_data_logs/_search?pretty"

出力ログ(抜粋):

{
  "type":"audit",
  "event.action":"access_denied",
  "user.name":"guest1",
  "action":"indices:data/read/search",
  "indices":["kibana_sample_data_logs"]
}

5.3. 検索の実行とクエリ内容の記録

emit_request_body を有効にしている場合、どのようなクエリが投げられたかも記録されます。

実行コマンド:

curl -X POST -u elastic:password --cacert ./certs/ca/ca.crt "https://localhost:9200/kibana_sample_data_logs/_search?pretty" \
-d '{"query":{"match":{"geo.dest":"CN"}}}'

出力ログ(抜粋):

{
  "event.action":"authentication_success",
  "user.name":"elastic",
  "url.path":"/kibana_sample_data_logs/_search",
  "request.body":"{\"query\":{\"match\":{\"geo.dest\":\"CN\"}}}"
}

6. 実践的な運用 Tips

監査ログは非常に詳細ですが、デフォルトのままではログサイズが膨大になり、ディスクやパフォーマンスに影響を及ぼします。

ノイズのフィルタリング

特定の監視用ユーザーや、信頼できる内部通信をログから除外することで、重要なイベントに集中できます。

設定例:

# 特定のイベントを除外
xpack.security.audit.logfile.events.exclude: ["anonymous_access_denied"]

# 特定のユーザーを監視対象から除外するフィルタ例
xpack.security.audit.logfile.events.ignore_filters:
  filter_monitor:
    users: ["monitor_user"]

7. まとめ

Elasticsearch の Audit Logging は、クラスターの透明性を高め、インシデントへの対応力を向上させる強力な武器です。

  • 1. まずは検証環境で有効化し、出力されるログの量と内容を確認する。
  • 2. 必要なイベントに絞り込むことで、ストレージの消費とパフォーマンスへの影響を最小限にする。
  • 3. Kibana や SIEM で可視化し、異常なアクセスパターンを即座に検知できる体制を整える。

セキュリティの第一歩として、ぜひ設定を試してみてください。

参考資料