elasticsearch-audit

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 または Cloud デプロイの URL）
認証	有効な認証情報（elasticsearch-authn スキルを参照）
クラスタ権限	クラスタ設定を更新するための manage クラスタ権限
ライセンス	監査ログには gold、platinum、enterprise、または trial ライセンスが必要です

不足している値があれば、ユーザーに確認してください。

監査ログを有効にする

再起動せずに監査ログを動的に有効にします。

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 ツールに転送する場合に便利です。

注： セルフマネージドクラスタでは、古いバージョン（8.x より前）で xpack.security.audit.outputs に 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/*）

単一のポリシー内で指定されたフィールドすべてに一致するイベントが除外されます。

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

ポリシーを 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 キーの操作、ロールマッピングの更新が記録されます。

イベントタイプごとの件数を集計し、ブルートフォース攻撃のパターンを検出する

時間範囲内のイベントをタイプごとに集計するには、event.action に対して terms 集計（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。

統合クエリ

Filebeat を介して Kibana 監査ログを Elasticsearch に送信し（Filebeat の設定については kibana-audit を参照）、 .security-audit-*（ES）と kibana-audit-*（Kibana）のインデックスを、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 出力を有効にします。logfile 出力は Filebeat を介して外部 SIEM ツールに送信するのに適していますが、Elasticsearch API からクエリすることはできません。

制限を厳しくして始め、必要に応じて範囲を広げる

まず失敗イベントのみ（authentication_failed、access_denied、security_config_change）から始めます。成功イベントは件数が多くなるため、必要な場合にのみ追加します。

イベントを無効にするのではなく、フィルターポリシーを使用する

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

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

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

Kibana 監査を有効にして全体を網羅する

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

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

manage 権限を持つ専用の管理ユーザーまたは API キーを使用します。elastic は緊急時の復旧のみに使用してください。

デプロイの互換性

機能	セルフマネージド	ECH	Serverless
クラスター設定による ES 監査	はい	はい	利用不可
ES の logfile 出力	はい	Cloud UI 経由	利用不可
ES の index 出力	はい	はい	利用不可
クラスター設定によるフィルターポリシー	はい	はい	利用不可
.security-audit-* のクエリ	はい	はい	利用不可

ECH に関する注意： ES 監査はクラスター設定 API で設定します。logfile 出力は Cloud コンソールのデプロイログから確認できます。index 出力はセルフマネージドの場合と同様に機能します。

Serverless に関する注意：

• Serverless では監査ログをユーザーが設定することはできません。セキュリティイベントはプラットフォームの一部として Elastic が管理します。
• Serverless での監査についてユーザーから質問があった場合は、Elastic Cloud コンソールまたは担当のアカウントチームを案内してください。