Trail)次のバージョンでは?※この記事は次のブログを翻訳したものになります。Elasticsearch向けの私たちのセキュリティプラグインの最初のリリースです。一般的に望まれているものから始まり、具体的な考えと実行できる計画へと変遷し、それが、いま現実となりました。私たちは継続的にカスタマーやユーザーからのリクエストを受け取り、統合されたソリューションになるようにしてきました。カスタマーとユーザが必要とするセキュリティとはどんなものかを理解するために多くの時間を費やしました。その結果がShieldです。Shieldは、ElasticsearchクラスタをセキュアにするElasticsearchの有償プラグインです。私たちは、ShieldをDev、Gold、Platinumサブスクリプションの一部として、追加料金なしで提供します。最初のリリースでは、基本的な機能と基盤にフォーカスしています。Elasticsearch自身に対しても、セキュリティに対して準備してきました。拡張性の側面だけでなく、Elasticsearchにあるデータフローについても再考してきました。Elasticsearchクラスタをセキュアにする場合に、具体的な価値を即座に届けるだけでなく、素早く拡張できるようにも開発しました。1.0は次の5つにフォーカスしています。サービスのライフタイムのある時点で、サブジェクト(例えばユーザー)を現在実行中のサブプロセスなどに結びつけることです。この関係性を持つためには、サブプロセスを実行する前にユーザの身元を確認するように命じます。ユーザの身元の確認のプロセスをAuthenticationと呼び、ElasticsearchのすべてのAPIコールでそれが実行されます。認証の手法は多くの異なるものがあります。Token)を、それぞれのタイプで提供するようにユーザに要求します。tokenをユーザ/パスワードペアとしています。tokenもサポートできることを意味します。)ユーザの資格を受け取ることだけでは不十分で、次に、それらをチェックする必要があります。Shieldでは、これはレルムの責務です。レルムは認証プロバイダ/サービスとしてみることができます。tokenが適切な資格を持っていない/単に知らないユーザであるということで、拒否されたかです。Shieldの認証メカニズムでは、複数のレルムを設定でき、さらに、あるレルムの戻り値を扱う他のレルム、というようなchainとすることもできます。1.0は3つのレルムをサポートします。Elasticsearchによって管理されるファイルベースのレルムです。これは、ファイルにユーザを定義することができます。このレルムは外部への依存はなく、Shieldをインストールすれば、デフォルトで使用できます。このレルムは配置が簡単で、マルチテナントなElasticsearchクラスタに対して使用できます。マルチテナントなElasticsearchクラスタとは、クラスタを複数のアプリでシェアすることをテナントと言います。すべてのユーザがパスワードを忘れてしまうような"emergency"な代替レルムも対応可能です。外部のLDAPサーバでユーザを認証するレルムです。このレルムは組織のLDAPサーバで管理/保存されているユーザをすでに持っている組織を対象としています。Directoryに対する設定になります。レルムはelasticsearch.yml設定ファイルで、次のように設定可能です。ldaps://url/to/ldap2/server上記のようにrealmsが一つのチェインとして参照されます。レルムごとに、設定された順序で、それらは参照されます。Shieldには、esusersファイルに保存されたユーザを管理するためのコマンドラインツールもあります。認可(authorization)認可(Authorization)は保護されたリソースにアクセスするユーザを許可するか拒否するかということです。モダンなシステムは、ユーザのパーミッションのために、ロールベースのアクセスコントロール(RBAC)モデルを利用します。このモデルでは、各ユーザはロールの集合に関連していて、それぞれのロールには、パーミッションの集合が定義されています。これは、洗練された設定で、パーミッションを機能的なグループで共有させることができます。次のようなロールを定義したとします。)財務部門のAnnは従業員と財務のロールを持っており、会社のディレクトリと財務データにアクセスでできます。認可プロセスはユーザがリクエストに関連したユーザが必要で、このプロセスのために、認証フェーズの後に直接実行されます。Shieldは2つのタイプのリソースを定義します。クラスタとインデックスです。これらは、すべてのAPIコールで保護されます。それらに関連したパーミッションとロールも定義できます。一度定義をすると、ロールはユーザもしくはLDAP/ADのグループに関係します。ロールはroles.yml設定ファイルで定義されます。設定のサンプルは次のようになります。write上記のサンプルで、次の5つのロールを定義しています。管理者のロールで、すべてのクラスターレベルの操作とすべてのインデックスに対してすべてのインデックスレベルの操作を実行可能です。システム/クラスタのモニタリングのためのロール。compnay_directoryにあるすべてのデータへの読み取りアクセスを与えられたロール。(特にcompany。expensesとpurchasesの両方に読み書きができるロール上記のサンプルで定義されているallとreadとwriteとして名前がつけられた権限です。これらは、予約語で、Elasticsearchのローレベルのアクションを複数含んだ権限です。updateの操作を含んでいます。多くのケースで、これらのハイレベルの名前が付けられた権限で十分ですが、特定のロールに特定のアクションを明示的に指定することもできます。indices:data/write/updateここまで説明した認可のレルムは、各ユーザに関連するロールを識別するためのものです。内部のesuserレルムでは、提供されるesuserコマンドラインツールを使ってロールはユーザに割り当てたり変更したりもできます。Directoryでは、LDAP/ADグループにShieldのロールを割り当てることができます。クライアントからElasticsearchクラスタへ、もしくはクラスタのノード間では暗号化されていないデータを送るためまだ危険があります。第三者が登頂したり、オンザフライでデータを書き換えたりといった可能性やクラスタを壊すことができます。1.0はElasticsearchのすべての通信チャネルをセキュアにすることができます。クラスタ内のノード間のチャネルやクライアントに公開されているチャネルです。これは、SSL/TLS通信を導入して実現します。Shieldで使えるSSLはElasticsearchのtransportサービスをSSL/TLSで通信できるものに置き換えます。APIを提供するもの)のそれぞれに設定可能です。ShieldのSSL/TLSは、スタンダードなJavaのものとkeystoreとtruststoreを基本にしたものが利用可能です。SSL/TLSを設定すると、各ノードのキーストアに証明書をインポートする必要があります。CAがサインした証明書を使うことも、CAが信頼したものとして許可許諾されたものを使うことが可能です。storeが必要です。新しいノードをクラスタに追加するときに、すべての必要な少なくとも一つの信頼されたCAから発行されてサインされたものが必要になります。クラスタで個別のノードがすべてのkeystore/truststoreを更新する必要性なしに。??通信チャネルを安全にする方法やSSL/TLS設定をどのように行うかはShieldのドキュメントをご覧ください。transportに設定することができます。これは、shield.transport.client.authにtrueを設定することで可能です。設定した場合、ノード間でSSLハンドシェイクが行われ、接続されたノードが接続に来たノードのクライアント認証を要求しチェックします。チェックに失敗した場合は、SSLシェイクハンドが失敗し接続が拒否されます。SSLクライアント認証transportレベルでノード認証が必要なようなら、次のような疑問がわくでしょう。Transportクライアントはクラスタの他のノードと同じチャネルを使うため、コネクションを確立するときに、ノードが他のノードと異なるかどうかを見極めることはできません。この時、もっとも単純な解決は、Transportクライアントも同様に許可を与えることです。それは、認証を解決するときに、他の問題(潜在的な悪意)を引き起こします。Transportクライアントが他のクラスタのノードを偽装しようとすることです。これは望んでいません。幸いなことに、良い解決方法があります。トランスポートプロファイルです。1.4で導入されたトランスポートプロファイルは、トランスポートレイヤー(異なるホスト/ポートにバインドされる)のために複数のネットワークチャネルを設定することができます。Shieldはこのサポートを、プロファイルごとに異なるSSL設定をできるように拡張します。ノードのタイプとクライアントプロファイルタイプの間に明確な違いを設定することも可能です。これを用いると、2つのプロファイルを設定できるようになります。ひとつは、クライアントのためのもので、もうひとつはクラスタのノードのためのものです。これにより、クライアントのための認証の問題が必要なくなり、Shieldはクライアントプロファイルをもった限定されたクライアントからのリクエストを保証します。IPフィルタリングこれは、厳密には、認証カテゴリではありませんが関係しています。Shieldはそれ自身がIPフィルタリングのメカニズムを持っています。これは、許可/不許可のIPのリストを設定することができます。これらのフィルタリングのルールは複数のレベルで設定可能です。transportチャネル、transportプロファイルレベル、そして、HTTPチャネルです。次の設定は、それらの設定のサンプルです。]このように、IPv4とIPv6、CIDR、ホスト名、ワイルドカードが利用できます。デプロイの全体から除去できることにも注意してください(詳細はドキュメントのIPフィルタリングをご覧ください)。Trail)セキュアなシステムの必須機能の一つで、監査硝石により、Elasticsearchに発生した重要なイベントをトラッキングすることが可能です。不審な/悪意のある可能性のあるイベントを追跡するときの診断ツールにもなります。1.0.0で、監査証跡は監査/アクセスlogを一般的なElasticsearchのログとは個別に保存します。それらは、構造化されているため、読んだりパースするのが容易で、イベントのタイプも分類されています。情報のレベルを設定することができ、各イベントをlogレベルの設定で書き出すことができます。以下が、イベントのリストです。ノードもしくはtransportクライアントがIPフィルタリングルールの制限により却下された時のログShieldの監査証跡についてより詳しく知りたい方は、ドキュメントをごらんください。次のバージョンでは?ここまで紹介したように、これはまだ始まりにすぎません。Shieldに追加される多くの機能があり、しっかりとした基盤を構築したところです。Shieldの次のバージョンでは、以下の機能の追加にフォーカスするでしょう。(これらだけに限ったわけではありません。Directoryサポートレルムタイプの追加(kerberos、anonymous、certificatesなどなど)セッションベースの認証ShieldはElasticsearch社の2番目の(Marvelに続く)商用プロダクトです。ダウンロードして開発環境で評価してください。インストールは他のプラグインと同様の方法です(インストール方法についての詳細はこちら)。一度インストールすると、30日の試用ライセンスが始まります。protected]まで連絡してください。私たちのすべてのプロダクトについてフィードバックをお待ちしています。サイトからご連絡ください。