elasticsearch-security-troubleshooting

Elasticsearch のセキュリティに関するトラブルシューティング

Elasticsearch でよくあるセキュリティ上の問題を診断し、解決します。このスキルでは、認証の失敗、認可エラー、TLS の問題、API キーの問題、ロールマッピングの不一致、Kibana へのログイン失敗、ライセンスの有効期限切れによるロックアウトに対応する、体系的なトリアージワークフローを提供します。

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

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

デプロイに関する注意： 診断用 API の利用可否は、セルフマネージド、ECH、Serverless によって異なります。詳細は デプロイの互換性を参照してください。

対応するタスク

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

前提条件

項目	説明
Elasticsearch URL	クラスターのエンドポイント（例：https://localhost:9200 またはクラウドデプロイの 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 証明書がないか、誤った 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 と（_authenticate から取得した）groups を各マッピングの 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 は "Request must contain a kbn-xsrf header" を含む 400 Bad Request を返します。

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 によって完全に管理されています。

例

ユーザーがログのクエリで 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 の復旧手順に従ってください。 ファイルベースまたはネイティブユーザーでログインし、更新したライセンスをアップロードするか、basic に戻します。

ガイドライン

必ず _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	サーバーレス
_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 コンソールを使用してください。

サーバーレスに関する注意事項：

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