Elasticsearch セキュリティトラブルシューティング

Elasticsearch の一般的なセキュリティ問題を診断・解決します。このスキルは、認証失敗、認可エラー、TLS 問題、API キーの問題、ロールマッピング不一致、Kibana ログイン失敗、ライセンス期限切れロックアウトに対する構造化されたトリアージワークフローを提供します。

認証方法と API キー管理については、elasticsearch-authn スキルを参照してください。ロール、ユーザー、ロールマッピングについては、elasticsearch-authz スキルを参照してください。ライセンス管理については、elasticsearch-license スキルを参照してください。

診断 API エンドポイントについては、references/api-reference.md を参照してください。

デプロイメント注: 診断 API の可用性はセルフマネージド、ECH、Serverless によって異なります。詳細は Deployment Compatibility を参照してください。

ジョブ

• HTTP 401 認証失敗を診断する
• HTTP 403 アクセス拒否エラーを診断する
• TLS/SSL ハンドシェイクまたは証明書エラーをトラブルシューティングする
• 期限切れまたは無効な API キーを調査する
• 予期されたロールを付与していないロールマッピングをデバッグする
• Kibana ログイン失敗、リダイレクトループ、CORS エラーを修正する
• ライセンス期限切れロックアウトから復旧する
• ユーザーが特定のインデックスにアクセスできない理由を判定する

前提条件

項目	説明
Elasticsearch URL	クラスタエンドポイント (例: https://localhost:9200 または Cloud デプロイメント URL)
認証	クラスタに到達するための有効な認証情報 (最小限でも構いません)
クラスタ権限	読み取り専用診断の場合は monitor、修正の場合は manage_security

不足している値について、ユーザーに入力を促します。ユーザーがまったく認証できない場合は、 TLS と証明書エラーまたはライセンス期限切れからの復旧から始めてください。

診断ワークフロー

症状を正しいセクションにルーティングします:

症状	セクション
HTTP 401、authentication_exception	認証失敗
HTTP 403、security_exception、アクセス拒否	認可失敗
SSL/TLS ハンドシェイクエラー、証明書拒否	TLS と証明書エラー
API キー拒否、期限切れ、または無効	API キーの問題
ロールマッピングが予期されたロールを付与していない	ロールマッピング問題
Kibana ログインが機能しない、リダイレクトループ、CORS エラー	Kibana 認証の問題
すべてのユーザーがロックアウト、有料機能が無効化	ライセンス期限切れからの復旧

各セクションは情報収集 - 診断 - 解決パターンに従います。

診断ツールキット

セキュリティ調査の開始時に、これらの API を使用します:

curl <auth_flags> "${ELASTICSEARCH_URL}/_security/_authenticate"

ID、レルム、ロールを確認します。401 で失敗する場合、問題は認証です。

curl <auth_flags> "${ELASTICSEARCH_URL}/_xpack"

セキュリティが有効かどうかを確認します (features.security.enabled)。セキュリティが無効な場合、すべてのセキュリティ API はエラーを返します。

curl -X POST "${ELASTICSEARCH_URL}/_security/user/_has_privileges" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "index": [
      { "names": ["'"${INDEX_PATTERN}"'"], "privileges": ["read"] }
    ]
  }'

認証されたユーザーが特定の権限を保有しているかをテストします。manage_security を必要としません。

curl <auth_flags> "${ELASTICSEARCH_URL}/_license"

ライセンスタイプとステータスを確認します。期限切れの有料ライセンスは有料レルムと機能を無効化します。

認証失敗 (401)

401 レスポンスは、Elasticsearch が呼び出し元の ID を検証できなかったことを意味します。

情報収集

curl -v <auth_flags> "${ELASTICSEARCH_URL}/_security/_authenticate" 2>&1

-v フラグはヘッダーとレスポンスボディを表示します。次を探します:

• WWW-Authenticate ヘッダー — クラスタが受け入れる認証スキームを示します。
• レスポンスボディの authentication_exception — reason フィールドは失敗の内容を説明しています。

診断

症状	考えられる原因
unable to authenticate user	ユーザー名またはパスワードが間違っている
unable to authenticate with provided credentials	認証情報がチェーン内のどのレルムとも一致しない
user is not enabled	ネイティブユーザーアカウントが無効化されている
token is expired	API キーまたはベアラートークンが期限切れ
WWW-Authenticate ヘッダーなし	セキュリティが無効な可能性があります。GET /_xpack を確認してください

ユーザーが外部レルム (LDAP、AD、SAML、OIDC) を使用して認証する場合、レルムチェーン順序が重要です。Elasticsearch は設定順序でレルムを試行し、最初のマッチで停止します。高優先度のレルムが意図されたレルムに到達する前に認証情報を拒否した場合、認証は失敗します。

解決

原因	アクション
認証情報が間違っている	ユーザー名/パスワードまたは API キー値を確認してください。elasticsearch-authn を参照してください。
ユーザーが無効化されている	PUT /_security/user/{name}/_enable を実行してください。elasticsearch-authz を参照してください。
API キーが期限切れ	新しい API キーを作成してください。API キーの問題を参照してください。
レルムチェーン順序	elasticsearch.yml のレルム順序を確認してください (セルフマネージドのみ)。
セキュリティが無効化されている	elasticsearch.yml で xpack.security.enabled: true を有効にして再起動してください。
期限切れ後の有料レルム	ライセンスが期限切れです — ライセンス期限切れからの復旧を参照してください。

認可失敗 (403)

403 レスポンスは、ユーザーは認証されていますが、必要な権限を持っていないことを意味します。

情報収集

操作に必要な特定の権限をテストします:

curl -X POST "${ELASTICSEARCH_URL}/_security/user/_has_privileges" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "index": [
      { "names": ["logs-*"], "privileges": ["read", "view_index_metadata"] }
    ],
    "cluster": ["monitor"]
  }'

レスポンスには has_all_requested ブール値と、リソースごとの詳細が含まれます。

ユーザーの有効なロールも確認してください:

curl <auth_flags> "${ELASTICSEARCH_URL}/_security/_authenticate"

roles 配列と authentication_realm を確認して、ユーザーが期待通りかどうかを確認してください。

診断

症状	考えられる原因
インデックスに対して has_all_requested: false	ロールが必要なインデックス権限を持っていない
クラスタに対して has_all_requested: false	ロールが必要なクラスタ権限を持っていない
ユーザーが予期より少ないロールを持っている	ロール配列が (マージではなく) 置換された
API キーが以前許可されていた操作で 403 を返す	API キー権限はスナップショット — 作成後のロール変更は
(操作)	既存キーには伝播されない

解決

原因	アクション
インデックス権限がない	ロールに権限を追加するか、新しいロールを作成してください。elasticsearch-authz を参照してください。
クラスタ権限がない	クラスタ権限を追加してください。elasticsearch-authz を参照してください。
ロール更新時に置換された	最初に現在のロールをフェッチしてから、完全な配列で更新してください。elasticsearch-authz を参照してください。
古い API キー権限	更新された role_descriptors で新しい API キーを作成してください。elasticsearch-authn を参照してください。

TLS と証明書エラー

TLS エラーは、クライアントがまったく接続を確立することを防ぎます。

情報収集

curl -v --cacert "${CA_CERT}" "https://${ELASTICSEARCH_HOST}:9200/" 2>&1 | head -30

次を探します:

• SSL certificate problem: unable to get local issuer certificate — CA が信頼されていない。
• SSL certificate problem: certificate has expired — 証明書が有効期限を過ぎている。
• SSL: no alternative certificate subject name matches target host name — ホスト名不一致。

より詳しい検査 (セルフマネージドのみ):

openssl s_client -connect "${ELASTICSEARCH_HOST}:9200" -showcerts </dev/null 2>&1

完全な証明書チェーン、有効期限、およびサブジェクト代替名が表示されます。

診断

エラーメッセージ	考えられる原因
unable to get local issuer certificate	CA 証明書がないまたは間違っている
certificate has expired	サーバーまたは CA 証明書が有効期限を過ぎている
no alternative certificate subject name matches	証明書 SAN がホスト名を含まない
self-signed certificate	自己署名証明書が信頼ストアにない
SSLHandshakeException (Java クライアント)	トラストストアに CA がないまたはパスワードが間違っている

解決

原因	アクション
間違った CA 証明書	--cacert で正しい CA を渡すか、システム信頼ストアに追加してください。
期限切れ証明書	elasticsearch-certutil を使用して証明書を再生成してください (セルフマネージド)。
ホスト名不一致	正しい SAN エントリで証明書を再生成してください。
自己署名証明書	CA 証明書をすべてのクライアントに配布するか、公開信頼 CA を使用してください。
クイックワークアラウンド	curl -k / --insecure を使用して検証をスキップしてください。本番環境向けではありません。

ECH では、TLS は Elastic によって管理されます — 証明書エラーは通常、クライアントが正しい Cloud エンドポイント URL を使用していないことを示しています。Serverless では、TLS は完全に管理され、透過的です。

API キーの問題

情報収集

キーのメタデータを取得します:

curl "${ELASTICSEARCH_URL}/_security/api_key?name=${KEY_NAME}" <auth_flags>

レスポンスから expiration、invalidated、role_descriptors を確認してください。

診断

症状	考えられる原因
キーを使用する際に 401 が返される	キーが期限切れまたは無効化されている
許可されるべき操作で 403 が返される	キーが不十分な role_descriptors で作成された
派生キーがアクセス権を持たない	API キーが別の API キーを作成した — 派生キーには権限がない
キーはいくつかのインデックスで動作するが他では動作しない	role_descriptors スコープが狭すぎる

解決

原因	アクション
キーが期限切れ	適切な expiration で新しいキーを作成してください。elasticsearch-authn を参照してください。
キーが無効化されている	新しいキーを作成してください。無効化されたキーは復旧できません。
スコープが間違っている	正しい role_descriptors で新しいキーを作成してください。elasticsearch-authn を参照してください。
派生キー問題	ユーザー認証情報を使用して POST /_security/api_key/grant を使用してください。elasticsearch-authn を参照してください。

ロールマッピング問題

ロールマッピングは、外部レルムのユーザーにロールを付与します。サイレントに失敗した場合、ユーザーは認証されますが、ロールを取得できません。

情報収集

curl <auth_flags> "${ELASTICSEARCH_URL}/_security/_authenticate"

username、authentication_realm.name、roles 配列を記録してください。

curl <auth_flags> "${ELASTICSEARCH_URL}/_security/role_mapping"

すべてのマッピングをリストし、rules と enabled フィールドを確認してください。

診断

症状	考えられる原因
ユーザーに空の roles 配列がある	マッピングがユーザーの属性と一致しない
ユーザーが間違ったロールを取得する	別のマッピングが最初にマッチしたか、ルールが広すぎる
マッピングが存在するが適用されない	enabled が false である
Mustache テンプレートが間違ったロール名を生成する	テンプレート構文エラーまたは予期しない属性値

ユーザーの authentication_realm.name と groups (_authenticate から) を各マッピングの rules と比較して、不一致を見つけてください。

解決

原因	アクション
マッチするルールがない	マッピングルールを更新してユーザーのレルムと属性に一致させてください。
マッピングが無効化されている	マッピングで "enabled": true を設定してください。
テンプレートエラー	既知の属性値で Mustache テンプレートをテストしてください。elasticsearch-authz を参照してください。
ルールが広すぎる	all / except 条件を追加して、マッチを絞ってください。elasticsearch-authz を参照してください。

Kibana 認証の問題

不足している kbn-xsrf ヘッダー

すべての Kibana API ミューテーションリクエストは kbn-xsrf ヘッダーが必要です:

curl -X PUT "${KIBANA_URL}/api/security/role/my-role" \
  <auth_flags> \
  -H "kbn-xsrf: true" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

なければ、Kibana は 400 Bad Request と "Request must contain a kbn-xsrf header" を返します。

SAML/OIDC リダイレクトループ

一般的な原因:

• elasticsearch.yml の xpack.security.authc.realms.saml.*.sp.acs または idp.metadata.path が間違っている。
• IdP と Elasticsearch ノード間のクロックスキュー (SAML アサーションには有効期間がある)。
• Kibana の server.publicBaseUrl が SAML ACS URL と一致していない。

SAML レルム設定を確認してください:

curl <auth_flags> "${ELASTICSEARCH_URL}/_security/_authenticate"

これが非 SAML レルム経由で有効なユーザーを返す場合、SAML レルム自体に到達していません。レルムチェーン順序を確認してください。

Kibana が Elasticsearch に到達できない

Kibana ログに Unable to retrieve version information from Elasticsearch nodes が出力されます。kibana.yml の elasticsearch.hosts 設定が到達可能なエンドポイントを指しており、認証情報 (elasticsearch.username / elasticsearch.password または elasticsearch.serviceAccountToken) が有効かを確認してください。

ライセンス期限切れからの復旧

有料ライセンスが期限切れの場合、クラスタはセキュリティ閉鎖状態になります: 有料レルム (SAML、LDAP、AD、PKI) が停止し、それらを通じて認証するユーザーはロックアウトされます。ネイティブレルムとファイルレルムは機能したままです。

クイックトリアージ

curl <auth_flags> "${ELASTICSEARCH_URL}/_license"

license.status が "expired" の場合、復旧を進めてください。

復旧ステップ

elasticsearch-license スキルの詳細な復旧ワークフローに従ってください。重要な最初のステップはデプロイメントタイプに依存します:

デプロイメント	最初のステップ
セルフマネージド	ファイルベースのユーザー (elasticsearch-users CLI) またはネイティブユーザーでログインしてください。
ECH	Elastic サポートに連絡するか、Cloud コンソール経由で更新してください。
Serverless	適用なし — ライセンスは Elastic によって完全に管理されています。

例

ユーザーが logs をクエリするとき 403 を取得

症状: "logs-* を検索するときに 403 を取得します。"

1. ID を確認してください:

curl -u "joe:${PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

レスポンスに "roles": ["viewer"] が表示されます。

1. 権限をテストしてください:

curl -X POST "${ELASTICSEARCH_URL}/_security/user/_has_privileges" \
  -u "joe:${PASSWORD}" \
  -H "Content-Type: application/json" \
  -d '{"index": [{"names": ["logs-*"], "privileges": ["read"]}]}'

レスポンス: "has_all_requested": false — viewer ロールに logs-* に対する read が含まれていません。

1. 修正: logs-reader ロールを作成して Joe に割り当ててください。elasticsearch-authz を参照してください。

API キーが動作しなくなった

症状: "昨日から API キーが 401 を返します。"

1. キーを確認してください:

curl -u "admin:${PASSWORD}" "${ELASTICSEARCH_URL}/_security/api_key?name=my-key"

レスポンスに "expiration": 1709251200000 が表示されます — キーが期限切れです。

1. 修正: 適切な expiration で新しい API キーを作成してください。elasticsearch-authn を参照してください。

SAML ログインがエラーにリダイレクト

症状: "Kibana で SSO ボタンをクリックするとエラーページにリダイレクトされます。"

1. 非 SAML 方法で認証して SAML レルムに到達可能か確認してください:

curl -u "elastic:${PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

1. IdP メタデータ URL が Elasticsearch ノードからアクセス可能か確認してください (セルフマネージド):

curl -s "${IDP_METADATA_URL}" | head -5

1. クロックスキューを確認してください — SAML アサーションは時間に機敏です。すべてのノードで NTP が設定されていることを確認してください。
2. kibana.yml の server.publicBaseUrl が IdP で設定された SAML ACS URL と一致することを確認してください。

ライセンス期限切れ後、ユーザーがロックアウト

症状: "誰も Kibana にログインできません。SAML を使用しています。"

1. ライセンスを確認してください:

curl -u "admin:${PASSWORD}" "${ELASTICSEARCH_URL}/_license"

レスポンスに "status": "expired"、"type": "platinum" が表示されます。

1. 有料ライセンスが期限切れのため SAML レルムが無効化されています。elasticsearch-license の復旧ステップに従ってください: ファイルベースまたはネイティブユーザーでログインして、更新されたライセンスをアップロードするか基本に戻してください。

ガイドライン

常に _authenticate で開始

最初の診断ステップとして GET /_security/_authenticate を実行してください。単一の呼び出しでユーザーの ID、レルム、ロール、認証タイプが明らかになります。ほとんどの問題はこのレスポンスだけで明らかになります。

ライセンスを早期に確認

レルムまたは権限の問題を調査する前に、GET /_license でライセンスが有効か確認してください。期限切れの有料ライセンスはレルムと機能を無効化し、設定ミスを模倣する症状を生成します。

手動検査の前に _has_privileges を使用

ロール定義を読んで有効なアクセスを心の中で計算する代わりに、POST /_security/user/_has_privileges を使用して特定の権限を直接テストしてください。これは高速でロール構成、DLS、FLS を考慮します。

スーパーユーザー認証情報を使用しない

組み込みの elastic スーパーユーザーを日常的なトラブルシューティングに使用しないでください。manage_security 権限を持つ専用管理者ユーザーまたは API キーを作成してください。elastic ユーザーは初期設定と緊急復旧のみに予約してください。

本番環境で TLS をバイパスしない

curl -k または --insecure を使用して証明書検証をスキップし、実際の TLS 問題を隠します。初期診断にのみ使用してから、根本的な証明書問題を修正してください。

デプロイメント互換性

診断ツールと API の可用性はデプロイメントタイプ間で異なります。

ツール / API	セルフマネージド	ECH	Serverless
_security/_authenticate	あり	あり	あり
_security/user/_has_privileges	あり	あり	あり
_xpack	あり	あり	限定的
_license	あり	あり (読み取り)	なし
_security/api_key (GET)	あり	あり	あり
_security/role_mapping	あり	あり	あり
elasticsearch-users CLI	あり	なし	なし
ノード上の openssl s_client	あり	なし	なし
Elasticsearch ログ	あり	Cloud UI 経由	Cloud UI 経由

ECH メモ:

• ノードレベルのアクセスがないため、elasticsearch-users CLI と直接的なログ/証明書検査は利用できません。
• TLS は Elastic によって管理されます — 証明書エラーは通常、不正なエンドポイント URL を示します。
• Cloud コンソールを使用してログ検査とデプロイメント設定を行ってください。

Serverless メモ:

• ライセンス API は公開されていません。ライセンス関連のロックアウトは発生しません。
• ネイティブユーザーは存在しません — 認証の問題は組織レベルで処理されます。
• TLS は完全に管理され、透過的です。