無料の暗号化とユーザー認証で、Elasticsearchクラスターを安全に保つ
Elasticsearchの複数のセキュリティ機能はElastic Stack 6.8および7.1よりデフォルト配布で無料化され、すべてのユーザーに広くお使いいただけるようになりました。Elastic Stackを安全に保つ方法に関するドキュメントや、ガイド類すべてに更新が必要になりましたが、それでもワクワクするニュースであることに変わりありません。スタックの安全を1台のプロキシサーバーに頼る日々にお別れです！
筆者はセキュリティ関連の古いブログ記事のうち、主要なものを読み返しました。本記事を通じて、各種手順をアップデートしたり、一般的な誤解を解いたり、新しいアイデアを紹介したり、そしてElastic Stackが史上最高にセキュアになっていることなどをお伝えしたいと思います。
Elastic Stackはここ数年で大きく変化しました。ここに具体的なリンクは貼りませんが、古いブログ記事の内容はそのまま使えないものもありますので、ご注意くださるようお願いいたします。（古いブログ記事の、セキュリティに関するアドバイスにはご注意ください。ここ最近、大きな変化がありました。） Elasticチームは、古い記事のリンクが本記事のページにジャンプするよう作業を行っていく予定です。別のサイトでキャッシュされたバージョンから本ページアクセスされてた方は、リンク元に本ページのリンクを転送していただけますと幸いです。
TLS暗号化
現在、TLS暗号化はデフォルト配布で使える無料のElasticsearch、およびKibanaのセキュリティ機能の一部に組み込まれています。TLSの目的は、ネットワーク通信を暗号化することです。ユーザーのクラスターでノード同士が行う通信と、クライアントとクラスター間の通信、ユーザーとKibanaの接続を暗号化しています。
またTLS証明書は、クラスターにノードを加える際の承認方法にも使われます。TLSが設定されていない場合、誰でもクラスターにノードを追加することが可能になります。攻撃者に悪用される恐れもありますが、それ以上に、誤ってクラスターにノードを追加するケースは少なくありません。TLSがあれば、適切な証明書がなければクラスターにノードを追加できないことから、誤操作の問題を防ぐことができます。
6.8および7.1の以前のバージョンでElastic StackにTLSを入れるにはベーシックライセンスが必要で、かつ一種のプロキシに依存することになっていたため、セットアップ手順も大変でした。ノードとクライアント間にプロキシを設定する手順を無視しても、TLSの設定自体がかなり難度の高いものです。これまでは、そこにプロキシの設定が加わることで、非常にハードルの高いものとなっていました。しかし現在ではElastic Stackが直接TLSをサポートしており、その仕様を活用することができます。
TLSの設定方法に関するドキュメントはかなり充実しています。過去にTLSの作業を行ったことがある人なら、証明書の設定が決して簡単ではないことはご存知でしょう。そこでElasticは、クラスターレベルの証明書と認証局を生成する内蔵ツールを用意し、手順の簡易化を図っています。 Elastic StackのすべてのコンポーネントにTLSを設定する最適な手順については今後のブログ記事でも詳しくお伝えしますので、ぜひ併せてご覧ください。今すぐ設定をはじめたい場合、簡単な手順は2つあります。ブログ記事「Elasticsearchセキュリティを使いはじめる」の手順や、オフィシャルのKubernetes Operatorを活用することができます。
認証
バージョン6.8および7.1より、すべてのユーザーがネイティブ認証をお使いいただけるようになりました。認証の目的は、Elastic Stackにクライアントを識別してもらうことです。この認証はしばしば、システムにログインする際に使うユーザー名とパスワードとして知られています。一般に、大量のデータを扱うクラスターを誰でもアクセスできる状態にしておくというのは、良い考えではありません。クラスターが、パスワードを使わず誰でもアクセスできる状態で直接インターネットに接続されている場合は特に危険です。
かつては、クライアントクラスター間で基本的な認証を有効化し、Nginxサーバーを使うことが推奨されていました。この設定を正しく実行しようとする場合、手順の難度が驚くほど高くなる可能性がありました。すべてのノードは外部リクエストに対してサービスを提供する可能性があるため、ノードにファイアウォールを設定し忘れると、誰でも認証なしにクラスターに接続できてしまうことになります。
ネイティブレルム、およびファイルレルムを使用する認証が無料になりました。ファイルレルムは、各ノードでユーザー情報をファイルに格納します。すべてのノード間で、これらのファイルの同期を保つ必要があります。ネイティブレルムのエクスペリエンスはよりスムーズです。ユーザーデータはノードがアクセス権限をもつクラスターのインデックスに格納されます。ユーザーがREST API経由でユーザー名とパスワードを追加すると、そのアカウントがログイン可能になります。詳しくは、ブログ記事「Elasticsearchセキュリティを使いはじめる」をご覧ください。
LDAP、Active Directory、SAMLなどの複雑な認証を必要とする場合、高度な認証や有償機能を簡単に利用できるElasticのクラウドサービス（SaaS）がおすすめです。オンプレミスでのソリューションをご希望の場合は、お問い合わせください。Elasticが提供するさまざまな認証オプションについては、認証に関するドキュメントをご覧ください。
認可
認可と認証はたいていの場合、切り離せない関係です。Elastic Stackも例外ではありません。Elasticはクラスターとインデックス、さらにドキュメントとフィールドにまで認可ルールを定義できる柔軟な仕組みを提供しています。独自の認可プラグインを開発するための認可エンジンも用意されています。
長い間、このトピックに関するアドバイスはきわめて荒っぽいものでした。かつて、Nginxのようなプロキシに複雑なフィルタリングルールを設定し、フィルター済みエイリアスを活用して認可に近い形でアーカイブする、という手順に代えるものとして、複数の方法が提案されていました。現在Elasticは、そうした方法を認可に使わないよう強く呼びかけています。そうした方法はそもそもセキュリティ機能ではないことから、期待通りに動作しなかったり、驚くほど保守管理に耐えないものだったりします。そのようなソリューションが期待通りに動作しない理由として、Elasticsearch APIの数が時間とともに顕著に増加してしまうということがあります。インデックスと、そこに含まれるデータにアクセスしたり、クエリを行う方法は多数存在します。したがって、すべてのリクエストを確実にブロックしたり、制限することは不可能です。2つ目の理由は、1つ目にも関連していますが、保護すべきエンドポイントの数が非常に多く、また常に新たなエンドポイントも増えていくからです。そのフィルターを最新の状態に保とうとすれば、膨大な量の作業になっていまいます。
幸いにも、そんな悩みは過去のものになりました。6.8および7.1より、多数の認可機能が提供されています。本記事では紹介しきれないほど多数の機能がありますが、従来からあるすべての機能は、Elastic Stackセキュリティのドキュメントで詳しく説明されています。今後のブログ記事では、Elasticの許可モデルを使って開発できるソリューション例を紹介していく予定です。
認証の高度なオプションのように、認可にも個々のドキュメントとフィールドに適用できる高度な機能が存在します。ユーザーは独自の認可プラグイン、および認証プラグインを開発できるだけでなく、クラスター上のセキュリティイベントをログにすることも可能です。この機能はクラウドサービスでご利用いただけます。オンプレミスで使えるオプションについてはお気軽にお問い合わせください。
スタックをVPNおよび/またはファイアウォールで保護する
Elastic StackをファイアウォールやVPNで保護するように、というアドバイスはこれまで多く発信されていました。背景にあったのは、TLSと認証が設定されていない場合、プロキシのみでクラスターを保護することが困難だという事実です。あらゆる人からのアクセスをブロックする方が、変動する条件を適切に設定するより簡単だ、という発想から提供されていたアドバイスです。
現在、すでにTLSと認証を有効化しているが、さらにファイアウォールやVPNも設定する、というのは素晴らしいアイデアです。セキュリティは複数のレイヤーで実施するとき、最も効果的です。VPNやファイアウォールを唯一のレイヤーとしてではなく、重ねて使うところがポイントです。
禁止されるスクリプト
Elasticではかなり以前に、Elasticsearchで禁止されるスクリプトについてのブログ記事を公開しました。現在はPainlessスクリプト言語が作成されたことで、悪意のあるスクリプトによってクラスターをダウンさせることはかなり難しくなりました。しかし今でもダウンさせることは不可能ではありません。Elasticの現在のスタンスを説明するスクリプティングのセキュリティに関するドキュメントには、スクリプトに関するベストプラクティスが公開されています。Elasticが提唱するのは、常に使用環境を見直していただき、そこで最も有意義な手段を講じることです。セキュリティは複数のレイヤーで実施するのが最も効果的であり、単体で絶対的なオプションというものはありません。
分離
セキュリティ上の理由からクラスターとノードを分離させる手法についても、これまで多く言及されてきました。具体的には、コンテナーやファイアウォール、IPフィルタリングにいたるまでさまざまな手法があります。
このアドバイスは現在も有効であり、できる限り分離することはセキュリティの観点で役立ちます。ここ数年の取り組みで、分離の作業は以前よりずっと簡単になりました。Docker Hubが提供するオフィシャルのコンテナーを使用できます。Elasticsearch Serviceを利用して、面倒な部分はサービスに頼ることができます。さらに先日リリースされたばかりのKubernetes Operatorを使うことも可能です。
インデックスをバックアップする（特に、変更の多い.kibanaのバックアップが重要）
データのバックアップが重要であることは以前とまったく変わりません。セキュリティの大枠は変わりませんが、手法に関しては新しいものがいくつか登場しています。
新しい手法のうち最もメリットが大きい機能が、特定のダッシュボードを編集できるユーザーを制限するKibanaのspacesです。この機能も、6.8および7.1より無料化されました。かつては、Kibanaにアクセスさえできれば、あらゆるオブジェクトを変更できることがありました。誰かがダッシュボードの挙動をおかしくしてしまったり、誤って削除することも十分あり得たわけです。そのため、「.kibanaインデックスを定期的にバックアップし、誤操作が生じてもすばやく復旧させられるように備えておくこと」が推奨されていました。ダッシュボードをゼロから作り直すより、インデックスを復旧させるほうがはるかに早いためです。現在でも.kibanaインデックスのバックアップは重要です。しかし、spacesと認可の機能が登場したことで、以前ほど復旧が必要となる機会はなくなりました。
この他にセキュリティに大きく貢献するのが、スナップショット撮影/インデックス作成/データ編集の各操作権限を持つユーザーを制御できる機能の登場です。セキュリティが不十分な場合、読み込み権限しかないユーザーであるにもかかわらず、データに壊滅的な変更を及ぼすこともあり得ます。セキュリティを有効化することが、重要なデータへの誤操作を防ぐ対策となります。
おわりに
本ブログ記事の目的は、Elastic Stackのデプロイを安全に保つためのアドバイスとして以前発信された内容を確認し、アップデートすることでした。セキュリティの世界に、変化のない瞬間は存在しません。この記事でお伝えしたアドバイスも、いつか「古くて、誤っている」情報になります。Elastic Stackのセキュリティは、選択肢が多いために難しく感じられることがあります。（仕様です。バグではありません。） ぜひディスカッションフォーラムへ質問していただいたり、Elasticのブログ記事やドキュメントをご活用ください。
Elastic Stackのセキュリティをクリックだけで簡単に保ちたい、と考える方におすすめのオプションもいくつかあります。Elasticsearch Serviceなら、デフォルトですべてのクラスターにTLSが設定されており、また認証と認可、およびエンタープライズセキュリティ機能が有効化されています。クラウドを使う予定がない場合、データセンターなどのオンプレミス環境でElasticsearch Serviceの機能を数多く使えるElastic Cloud Enterprise（ECE）がおすすめです。また、Kubernetes Operatorでは、TLSや認証設定など、難度の高い作業がデフォルトで完了した状態となっています。さらに独自のスタックを実行しているエンタープライズユーザーは、さまざまな問題の解決を手伝うサポートチームを活用することができます。
今後新たに提供されるサービスについては改めてお知らせいたします。楽しみにお待ちください。引き続きさまざまなノウハウをお伝えするほか、新しいセキュリティ機能のリリースも予定されています。さらにセキュアになったElastic Stackを、ぜひお楽しみください。