Elasticsearch 監査ログ

クラスター設定 API を使用して Elasticsearch のセキュリティ監査ログを有効化および設定します。監査ログは、認証試行、アクセス許可と拒否、ロール変更、API キー操作などのセキュリティイベントを記録します。これはコンプライアンスとインシデント調査に不可欠です。

Kibana 監査ログ (保存オブジェクトへのアクセス、ログイン/ログアウト、スペース操作) については、kibana-audit を参照してください。認証と API キー管理については、elasticsearch-authn を参照してください。ロールとユーザー管理については、elasticsearch-authz を参照してください。セキュリティエラーの診断については、elasticsearch-security-troubleshooting を参照してください。

詳細な API エンドポイントとイベントタイプについては、references/api-reference.md を参照してください。

デプロイメント注記: 監査ログの設定はデプロイメントタイプによって異なります。詳細については デプロイメント互換性 を参照してください。

実施すべきタスク

• クラスター上のセキュリティ監査ログを有効化または無効化
• 記録するセキュリティイベント (認証、アクセス、設定変更) の選択
• 監査ログノイズを削減するフィルターポリシーの作成
• 失敗した認証試行について監査ログをクエリ
• 不正なアクセスまたは権限昇格インシデントの調査
• コンプライアンス対応の監査設定
• 監査データからブルートフォースログインパターンの検出
• 監査出力をインデックスに設定してプログラムによるクエリを実現

前提条件

項目	説明
Elasticsearch URL	クラスターエンドポイント (例: https://localhost:9200 またはクラウドデプロイメント URL)
認証	有効な認証情報 (elasticsearch-authn スキルを参照)
クラスター権限	クラスター設定を更新するための manage クラスター権限
ライセンス	監査ログには gold、platinum、enterprise、またはトライアルライセンスが必要

不足している値についてはユーザーに入力を促してください。

監査ログの有効化

再起動なしで監査ログを動的に有効化します:

curl -X PUT "${ELASTICSEARCH_URL}/_cluster/settings" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "xpack.security.audit.enabled": true
    }
  }'

無効化するには、xpack.security.audit.enabled を false に設定します。現在の状態を確認:

curl "${ELASTICSEARCH_URL}/_cluster/settings?include_defaults=true&flat_settings=true" \
  <auth_flags> | jq '.defaults | with_entries(select(.key | startswith("xpack.security.audit")))'

監査出力

監査イベントは 2 つの出力に書き込むことができます。両者は同時にアクティブにできます。

出力	設定値	説明
logfile	logfile	<ES_HOME>/logs/<cluster>_audit.json に書き込まれます。デフォルト。
index	index	.security-audit-* インデックスに書き込まれます。API 経由でクエリ可能。

API 経由で出力を設定

curl -X PUT "${ELASTICSEARCH_URL}/_cluster/settings" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "xpack.security.audit.enabled": true,
      "xpack.security.audit.outputs": ["index", "logfile"]
    }
  }'

index 出力は監査イベントのプログラムによるクエリに必要です。logfile 出力は Filebeat 経由で外部 SIEM ツールにシップする場合に便利です。

注記: 自社管理クラスターでは、xpack.security.audit.outputs は古いバージョン (8.x 以前) で elasticsearch.yml の静的設定が必要になる場合があります。8.x 以降では、クラスター設定 API を推奨します。

記録するイベントの選択

含めるまたは除外するイベントタイプを制御します。デフォルトでは、監査が有効な場合、すべてのイベントが記録されます。

特定のイベントのみを含める

curl -X PUT "${ELASTICSEARCH_URL}/_cluster/settings" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "xpack.security.audit.logfile.events.include": [
        "authentication_failed",
        "access_denied",
        "access_granted",
        "anonymous_access_denied",
        "tampered_request",
        "run_as_denied",
        "connection_denied"
      ]
    }
  }'

ノイズの多いイベントを除外

curl -X PUT "${ELASTICSEARCH_URL}/_cluster/settings" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "xpack.security.audit.logfile.events.exclude": [
        "access_granted"
      ]
    }
  }'

access_granted を除外すると、ビジーなクラスターのログボリュームが大幅に削減されます。失敗のみが重要な場合に使用してください。

イベントタイプ参照

イベント	発火条件
authentication_failed	認証情報が拒否された
authentication_success	ユーザーが正常に認証された
access_granted	認可されたアクションが実行された
access_denied	十分な権限がないためアクションが拒否された
anonymous_access_denied	認証されていないリクエストが拒否された
tampered_request	リクエストが改ざんされていることが検出された
connection_granted	ノードがクラスターに参加した (トランスポート層)
connection_denied	ノード接続が拒否された
run_as_granted	run-as 偽装が認可された
run_as_denied	run-as 偽装が拒否された
security_config_change	セキュリティ設定が変更された (ロール、ユーザー、API キーなど)

完全なイベントタイプリストとフィールド詳細については、references/api-reference.md を参照してください。

フィルターポリシー

フィルターポリシーを使用すると、イベントタイプをグローバルに無効化することなく、ユーザー、レルム、ロール、またはインデックスごとに特定の監査イベントを抑止できます。複数のポリシーがアクティブにできます。イベントは、いずれのポリシーでもフィルターされていない場合のみ ログに記録されます。

システムおよび内部ユーザーを無視

curl -X PUT "${ELASTICSEARCH_URL}/_cluster/settings" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "xpack.security.audit.logfile.events.ignore_filters": {
        "system_users": {
          "users": ["_xpack_security", "_xpack", "elastic/fleet-server"],
          "realms": ["_service_account"]
        }
      }
    }
  }'

特定のインデックスのヘルスチェックトラフィックを無視

curl -X PUT "${ELASTICSEARCH_URL}/_cluster/settings" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "xpack.security.audit.logfile.events.ignore_filters": {
        "health_checks": {
          "users": ["monitoring-user"],
          "indices": [".monitoring-*"]
        }
      }
    }
  }'

フィルターポリシーフィールド

フィールド	型	説明
users	array[string]	除外するユーザー名 (ワイルドカード対応)
realms	array[string]	除外するレルム名
roles	array[string]	除外するロール名
indices	array[string]	除外するインデックス名またはパターン (* 対応)
actions	array[string]	除外するアクション名 (例: indices:data/read/*)

イベントは、1 つのポリシー内で指定されたすべてのフィールドに一致する場合、フィルターされます。

フィルターポリシーを削除

ポリシーを null に設定:

curl -X PUT "${ELASTICSEARCH_URL}/_cluster/settings" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "xpack.security.audit.logfile.events.ignore_filters.health_checks": null
    }
  }'

監査イベントのクエリ

index 出力が有効な場合、監査イベントは .security-audit-* インデックスに保存され、クエリできます。

失敗した認証試行を検索

curl -X POST "${ELASTICSEARCH_URL}/.security-audit-*/_search" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "filter": [
          { "term": { "event.action": "authentication_failed" } },
          { "range": { "@timestamp": { "gte": "now-24h" } } }
        ]
      }
    },
    "sort": [{ "@timestamp": { "order": "desc" } }],
    "size": 50
  }'

特定のインデックスでのアクセス拒否イベントを検索

curl -X POST "${ELASTICSEARCH_URL}/.security-audit-*/_search" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "filter": [
          { "term": { "event.action": "access_denied" } },
          { "term": { "indices": "logs-*" } },
          { "range": { "@timestamp": { "gte": "now-7d" } } }
        ]
      }
    },
    "sort": [{ "@timestamp": { "order": "desc" } }],
    "size": 20
  }'

セキュリティ設定の変更を検索

curl -X POST "${ELASTICSEARCH_URL}/.security-audit-*/_search" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "filter": [
          { "term": { "event.action": "security_config_change" } },
          { "range": { "@timestamp": { "gte": "now-7d" } } }
        ]
      }
    },
    "sort": [{ "@timestamp": { "order": "desc" } }],
    "size": 50
  }'

これはロール作成/削除、ユーザーの変更、API キー操作、ロールマッピング更新をキャプチャします。

イベント数をタイプ別に集計してブルートフォースパターンを検出

terms 集計を event.action (size: 0 のもの) で使用して、時間枠でイベント数をタイプ別に集計します。ブルートフォース試行を検出するには、authentication_failed イベントを source.ip で min_doc_count: 5 とともに集計します。完全な集計クエリ例については、references/api-reference.md を参照してください。

Kibana 監査ログとの相関

Kibana には、Elasticsearch が認識しないアプリケーション層イベント (保存オブジェクト CRUD、Kibana ログイン、スペース操作) をカバーする独自の監査ログがあります。ユーザーが Kibana でアクションを実行すると、Kibana はユーザーの代わりに Elasticsearch に要求を出します。両方のシステムは同じ trace.id を記録します (これは X-Opaque-Id ヘッダー経由で渡されます)。これが主な相関キーとして機能します。

前提条件: Kibana 監査は kibana.yml で個別に有効化される必要があります。セットアップ手順、イベントタイプ、Kibana 固有のフィルターポリシーについては、kibana-audit スキルを参照してください。

Kibana アクションによってトリガーされた ES 監査イベントを検索

Kibana 監査イベントから trace.id が指定されている場合、ES 監査インデックスを検索して、基底の Elasticsearch 操作を確認:

curl -X POST "${ELASTICSEARCH_URL}/.security-audit-*/_search" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "filter": [
          { "term": { "trace.id": "'"${TRACE_ID}"'" } },
          { "range": { "@timestamp": { "gte": "now-24h" } } }
        ]
      }
    },
    "sort": [{ "@timestamp": { "order": "asc" } }]
  }'

ユーザーと時間枠で相関

trace.id が利用できない場合 (直接 API 呼び出しなど)、ユーザー + 時間枠相関にフォールバック:

curl -X POST "${ELASTICSEARCH_URL}/.security-audit-*/_search" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "filter": [
          { "term": { "user.name": "'"${USERNAME}"'" } },
          { "range": { "@timestamp": { "gte": "now-5m" } } }
        ]
      }
    },
    "sort": [{ "@timestamp": { "order": "asc" } }]
  }'

副次的な相関フィールド: user.name、source.ip、@timestamp。

統合クエリ

Kibana 監査ログを Filebeat 経由で Elasticsearch にシップ (kibana-audit については Filebeat 設定を参照) すると、.security-audit-* (ES) と kibana-audit-* (Kibana) の両方のインデックスを 1 つのマルチインデックスクエリで一緒に検索でき、trace.id でフィルター可能です。

例

コンプライアンス用に監査ログを有効化

リクエスト: "監査ログを有効化し、失敗したアクセスおよび認証イベントをすべて記録してください。"

curl -X PUT "${ELASTICSEARCH_URL}/_cluster/settings" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "xpack.security.audit.enabled": true,
      "xpack.security.audit.logfile.events.include": [
        "authentication_failed",
        "access_denied",
        "anonymous_access_denied",
        "run_as_denied",
        "connection_denied",
        "tampered_request",
        "security_config_change"
      ]
    }
  }'

これはすべての拒否およびセキュリティ変更イベントをキャプチャし、高ボリュームの成功イベントを除外します。

疑わしい不正アクセス試行の調査

リクエスト: "誰かが secrets-* インデックスにアクセスしようとしたかもしれません。監査ログを確認してください。"

curl -X POST "${ELASTICSEARCH_URL}/.security-audit-*/_search" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "filter": [
          { "terms": { "event.action": ["access_denied", "authentication_failed"] } },
          { "wildcard": { "indices": "secrets-*" } },
          { "range": { "@timestamp": { "gte": "now-48h" } } }
        ]
      }
    },
    "sort": [{ "@timestamp": { "order": "desc" } }],
    "size": 100
  }'

結果の user.name、source.ip、event.action を確認して、アクターとパターンを特定します。

ビジーなクラスターの監査ノイズを削減

リクエスト: "監査ログが大きすぎます。監視トラフィックと成功したリードをフィルターで除外してください。"

イベントタイプから access_granted を除外し、次に監視ユーザーとインデックスのフィルターポリシーを追加します。完全な構文については フィルターポリシー を参照してください。

ガイドライン

プログラムによるアクセスには index 出力を推奨

index 出力を有効化して、監査イベントをクエリ可能にします。logfile 出力は Filebeat 経由で外部 SIEM ツールにシップするのに適していますが、Elasticsearch API 経由でクエリできません。

制限的に開始して、その後拡大

失敗イベント (authentication_failed、access_denied、security_config_change) のみで開始します。成功イベントは必要な場合のみ追加してください。ボリュームが大きくなります。

イベント無効化の代わりにフィルターポリシーを使用

イベントタイプ全体を除外するのではなく、フィルターポリシーで特定のユーザーまたはインデックスを抑止します。

監査インデックスサイズを監視

ILM ポリシーを設定して古い .security-audit-* インデックスをロールオーバーおよび削除します。典型的な保持期間は 30～90 日です。

Kibana 監査を有効化して完全にカバー

アプリケーション層イベント (保存オブジェクトアクセス、Kibana ログイン、スペース操作) については、Kibana 監査ログも有効化します。セットアップについては kibana-audit スキルを参照してください。相関には trace.id を使用してください。Kibana 監査ログとの相関 上記を参照。

スーパーユーザー認証情報を避ける

manage 権限を持つ専用の管理ユーザーまたは API キーを使用します。elastic は緊急復旧にのみ予約します。

デプロイメント互換性

機能	自社管理	ECH	Serverless
クラスター設定経由の ES 監査	はい	はい	利用不可
ES logfile 出力	はい	クラウド UI 経由	利用不可
ES index 出力	はい	はい	利用不可
クラスター設定経由のフィルターポリシー	はい	はい	利用不可
.security-audit-* をクエリ	はい	はい	利用不可

ECH 注記: ES 監査はクラスター設定 API 経由で設定されます。Logfile 出力はクラウドコンソールデプロイメントログを通じてアクセスできます。Index 出力は自社管理と同じように機能します。

Serverless 注記:

• Serverless では監査ログはユーザー設定不可です。セキュリティイベントはプラットフォームの一部として Elastic によって管理されます。
• ユーザーが Serverless での監査について質問する場合は、Elastic Cloud コンソールまたはアカウントチームにご連絡ください。