Elasticsearchの“認証”と“認可”を徹底解説

著者
Gabriel Moskovicz

筆者はElasticで4年と少し働いています。そのうち3年半はサポートとコンサルティングチームに、この半年はセールスチームに所属しています。所属する部署を問わず、私がユーザーから最もよく受ける質問は“Elasticsearchを安全に保つ”ことについてです。具体的には、「Elasticsearchがサポートする認証のタイプは何か？」とか、「どうやって設定すればよいか？」とか、「ユーザーに非表示として設定したデータが、本当に非表示であるかどうか、どう確認すればよいか？」といった質問です。本ブログ記事ではこのような質問に回答すると同時に、セキュリティの設定に際してよくある問題を解決するためのガイダンスも提供してまいります。

まずは歴史の話です。以前からElasticsearchをお使いの方は、かつてElasticがX-PackというパッケージのShieldと呼ばれるプラグインでセキュリティ機能を提供していたことをご存じかもしれません。現在、セキュリティ機能（とX-Packのその他の機能）はElastic Stackに移行されており、最も一般的に使われる機能はデフォルトの配布パッケージで無料で提供されています。セキュリティと言っても通信暗号化（TLS/SSL）や認証（ネイティブ、LDAP、SSOほか）、認可（RBAC、ABACなど）、IPフィルタリング、監査ログなどさまざまな機能が存在しますが、本ブログ記事ではこのうち、“認証”と“認可”に絞って取り上げます。

Elasticsearchの認証

簡単に言うと、あるユーザーやAPIがElasticsearchにアクセスするには、認証が必要です。

Elasticsearchは多数のセキュリティメソッドをネイティブにサポートしています。一例として、次のようなメソッドがあります。

ここに挙がっているような認証を使わない場合、独自の統合を作成することもできますが、Elasticは既存の統合の使用を推奨しています。これらは検証済みであり、確実に適切なサポートを提供できるよう、Elasticが継続的な開発を行っているためです。

Elasticsearch内で最も基本のコンポーネントはユーザーの判別と、認証を行う“レルム”です。上に挙げた認証メソッドのいずれも、レルムと見なすことができます。これを動作させるため、Elasticsearchはレルムチェーンと連携しています。レルムチェーンとは、設定済みの（1からNの）レルムを、優先度の昇順でならべた優先順位リストです。あるユーザーがElasticsearchにアクセスを試みるとき、そのリクエストは、認証が成功するまで、あるいは試行するレルムが尽きるまで、リストを順次通過してゆきます。

原則としてこのプロセスは、リストの先頭に設定されたレルムを試行し、失敗したら次を試行するという手順を、レルム項目の1つで成功するか、もれなくリスト全体を実行し終えるまで継続するというものです。Elasticsearchへのアクセスの最初のステップは、認証と呼ばれます。

ユーザーを認証した後、Elasticsearchはユーザーに1つ以上のロールを割り当てようとします。ロールは、認証を行う間、ユーザープロパティの一部に基づいて静的に、あるいは動的にユーザーに割り当てることができます。ロールの割り当てに使用するユーザープロパティはユーザーを認証したレルムのタイプによって異なり、外部システムにあるグループメンバーシップを使うこともあれば、Elasticsearchのユーザー名の接尾辞を使うことなどもあります。その他に、Elasticsearchは機能として実行させる仕様も搭載しています。他のユーザーの代わりにユーザーがリクエストを送信し、再認証は必要となりません。

認証のフェーズが完了したら、次のステップは認可です。ワークフローの全体は、下の図で確認することができます。

Elasticsearchのレルムチェーン

Elasticsearchの認可

認証に成功したユーザーは、2番目のセキュリティチェックポイントとなる認可のステップへ移行します。認可とは、そのユーザーがあるリクエストを実行する権限を付与されているか判断するプロセスです。認可のプロセスは、ユーザーを事前定義および/またはユーザー定義のロールにマッピングすることで実施されます。デフォルトでElasticsearchに表示されるロールもありますが、ユースケースに応じて、特定のロールを作成することもできます。

ロールは次の要素で構成されます：

  • アクセスできるユーザーのリスト
  • クラスター権限
  • グローバル権限
  • インデックス権限
  • アプリケーション権限

Elasticsearchの認可のフェーズでは、次のメソッドから1つを使用します。

  • role_mapping API：各ロールのマッピングをAPIドリブンに、一元的に管理できることから、Elasticが推奨するメソッドです。Elastic CloudのElasticsearch Serviceでは、これがロールマッピングを設定する唯一の方法となっています。
  • ロールマッピングファイル（role_mapping.yml）：configurationフォルダー内の各ノードにあります。

role_mapping APIは、ロールを管理する適切な権限を持ったユーザーにより呼び出される必要があります。一例として、Elasticユーザーに与えられるsuperuserロールがこれに該当しますが、ロール管理のために特定のロールを作成することも可能です。

レルムとロールは、定義上まったく異なっています。レルムとレルムチェーンは認証を受けるために使うものであり、認証フェーズが終わったら、以降はロールを使ってユーザーにマップします。認証フェーズでは、レルムチェーンのレルムの1つを使ってユーザーを認証するだけですが、2つ目のフェーズでは、ユーザーを1つないし多数のロールにマップすることができます。これは、“ロールベースのアクセス制御”としても知られています。

認証と認可の問題のトラブルシューティング手順

認証と認可の基本について理解したところで次は、問題が起きた場合のトラブルシューティングをいくつかご紹介します。

401 Unauthorized

どのレルムを使っても認証されない場合、ステータスコード401 Unauthorizedが返されます。設定したレルムのリストに対してユーザーの資格情報を試す最も簡単な方法は、cURLを、調査可能なフラグ（例：-v）と共に使用するやり方です。たとえば、次のようなレスポンスが返ってきます。 

curl https://xxxxxx:9200 -u test:test -v 
> User-Agent: curl/7.54.0 
> Accept: */* 
> 
< HTTP/1.1 401 Unauthorized 
< Content-Type: application/json; charset=UTF-8 
< Date:Tue, 10 Sep 2019 15:59:33 GMT 
< Www-Authenticate:Bearer realm="security" 
< Www-Authenticate:ApiKey 
< Www-Authenticate:Basic realm="security" charset="UTF-8" 
< Content-Length:455 
< Connection: keep-alive 
< 
* Connection #0 to host 06618318cff64c829af1cd5a2beb91a5.us-east-1.aws.found.io left intact 
{"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}}],"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}},"status":401}%

このエラーメッセージは、問題の根本原因の把握に役立てることができます。たとえばSAMLのような一部のレルムは、ElasticsearchとIDプロバイダーの間で通信を行うために、Kibana、またはその他のカスタムWebアプリを必要とします。

エラーロギングの実施

レルム、レルムチェーン、ロール、ロールマッピングの設定を完了した後でまだ問題がある場合は、簡単に追加のロギングを設定できます。追加のロギングが、先ほどご説明した認証と認可のプロセスに関する詳しい情報を提供します。

クラスター設定API内にあるロギング設定を使用すると、任意のレルムにあらゆるレベルのロギングを定義できます。

LDAPレルムの例で実際にやってみましょう。ユーザー認証または認可でエラーが生じる場合、以下のロギングレベルを設定して、より詳しい情報を取得することができます。 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap":"DEBUG",
     "logger.org.elasticsearch.xpack.security.authz":"DEBUG" 
   } 
}

この設定で、LDAPパッケージのロギングレベルをデフォルトから“DEBUG”に引き上げることができます。また、トレースロギングも有効化することで、サーバーに対して行われたすべてのLDAPコールとその応答など、より広範な情報を取得できます。特定のレルムを有効化するパッケージ名は、ElasticのGitHubレポジトリで探すことができます。一例として、LDAPレルムのコードはこちらです。コードの1行目を使用して、ロギングレベルを設定するパッケージを表示できます。 

package org.elasticsearch.xpack.security.authc.ldap;

有効化するとすぐに、たくさんのログ行が現れます。以下はその例です： 

[2019-09-12T08:41:20,628][DEBUG][o.e.x.s.a.l.LdapRealm   ] [xxxxxxx] user not found in cache, proceeding with normal authentication
[2019-09-12T08:41:21,180][TRACE][o.e.x.s.a.l.s.LdapUtils ] LDAP Search SearchRequest(baseDN='dc=xxx,dc=xxxx,dc=domain,dc=com', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(cn=vchatzig)', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=2, entriesReturned=1, referencesReturned=0) ([SearchResultEntry(dn='cn=xxxxxxx,ou=xxxxx,dc=intc,dc=xxxx,dc=domain,dc=com', messageID=2, attributes={}, controls={})])

この例では、LDAPレルムが（有効期限切れの可能性がある）キャッシュからユーザーを取得しようとしており、次に、ユーザーが提供した特定の設定を使用して、サーバーに対してLDAP Searchリクエストを行っていたことがわかります。これは、取得できる多数のログ行の一例です。

注：ロギングの有効化は、診断には非常に有益ですが、パフォーマンスには有益ではありません。動作確認が終了したら、次のコードを使用して、ロギングレベルの設定をデフォルトに戻すことをおすすめしています。 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap": null,
     "logger.org.elasticsearch.xpack.security.authz": null 
   } 
}

一部のパッケージはバージョンによって異なる可能性があります。特定のリリース向けのGitHubクラスリンクに加え、お使いの特定のElasticsearchバージョンのドキュメントリンクでダブルチェックすることをElasticは推奨しています。

SAMLのよくある問題

SAMLレルムはIDプロバイダー（OktaやAuth0など）とWebアプリケーション（デフォルトではKibana）を要求し、Elasticsearchと共にサービスプロバイダーとして振る舞います。SAMLのよくある問題に、次のようなものがあります。

  • IDプロバイダー（IdP）のconfigで、Assertion Consumer Service URLの設定が誤っている：通常、IDプロバイダーで設定すべきエンドポイントはhttps://kibana.xxxx.com/api/security/v1/samlです。
  • IDプロバイダーのメタデータにインターネット経由でアクセスできない：オンプレミスでもElastic Cloudでも、Elasticsearchのconfigのidp.metadata.path値に、Elasticsearch/Kibanaを実行するネットワーク経由でアクセスできるようにしておく必要があります。これを実施しない場合は、メタデータにアクセスできるホストからメタデータをダウンロードするか、IDプロバイダー管理者に頼んでメタデータをElasticsearchのローカルファイルに追加し、それを参照する必要があります。表示されるエラーは、次のメッセージに似た内容となります： 
    Caused by: net.shibboleth.utilities.java.support.resolver.ResolverException: net.shibboleth.utilities.java.support.resolver.ResolverException:Non-ok status code 404 returned from remote metadata source https://xxxx.xxxx/xxx/yyyyyyyy/sso/saml/metadata
  • ユーザーは認証されるが、Kibanaを開けない：Elasticは、このユーザーへのロールマッピングで、少なくとも1つのロールにKibanaへのアクセスが含まれていることをダブルチェックすることを推奨しています。

IDプロバイダーの設定は、Elasticsearch/Kibanaの設定と同じくらい重要です。誤字や、configの設定に期待値とは不一致の内容が含まれていないか、常に確認する必要があります。IDプロバイダーにはそれぞれ独自の設定があります。Elasticは、各々に固有の必要な設定について、ドキュメントを参照されることをおすすめしています。

SAMLに関するその他のよくある問題とトラブルシューティングの手順については、各リリースのたびに更新されるトラブルシューティングドキュメントをご覧ください。

まとめ

Elasticsearchの認証は、背景にあるコンセプトさえ理解すれば、とても簡単に設定することができます。何がどう動作しているか、動作していないか、その理由は何かを理解することが困難な場合もないわけではありません。本記事では、より詳しく調べるためのオプションを多数ご紹介しました。この他にも、ブログ記事「Elasticsearch Securityを使いはじめる」や、Elasticのセキュリティ向けドキュメントにあるトラブルシューティングガイドをご活用いただくことができます。Elasticセキュリティのシニアプロダクトマネージャーが立ち上げのエクスペリエンスについて詳しく説明している動画も併せてご覧ください。

各サブスクリプションに含まれる機能について詳しくは、サブスクリプションページでご確認いただくことをおすすめいたします。個別の質問については、サポート担当者にお問い合わせいただくか、ディスカッションフォーラムをご活用ください。

セキュリティをお楽しみいただければ幸いです。