インストールされた elasticsearch は非常に悪用されやすいという事実にもかかわらず、これに関する情報が深刻に不足しているようです。
これを使用する上での私の主な懸念は、専門家ではないため、潜在的な脆弱性が何であるか、またそれをどのように解決するかが全く分からないことです。
安全な環境内で次の操作を実行できるように、elasticsearch をロックダウンする方法を教えていただけますか。
ユーザーごとに複数のインデックス。これを事前に作成できると仮定すると、ユーザーは他のユーザーのインデックスに対して操作を実行できないはずです。ただし、許可されている場合はクエリを実行できます。(各ユーザーの URL に何らかの形式の秘密キーが含まれている可能性があります。)
ユーザーは自由にインデックスにオブジェクトを追加したり削除したりできますが、インデックスを削除することはできません。
何か問題が発生した場合にサービスに過負荷がかからないように、ユーザーのメモリ サイズに何らかの制限を設けます。
このうちのいくつかはアプリケーション レベルで実行する必要があると推測しており、これを代わりに書いてもらうことは期待できませんが、デフォルトの構成は非常にオープンであるため、これにカスタム API レイヤーを提供したとしても、誰かが簡単にそれをバイパスしてサーバーと直接通信することができます。
答え1
私の意見では、あなたが要求する方法で ES を保護する唯一の方法は、別のアプリケーション レイヤーの背後にロックし、そのレイヤーで https/ssl トランスポート、認証、および承認制御を処理させることです。
ES 側では、jetty ES セキュリティ プラグインが開発されましたが、成功したかどうかはわかりません。ES を初めてデプロイしたときに、プラグインがリリースされようとしていたので、見てみましょう。
答え2
おそらく、このすべての「ビジネス ロジック」を備えた中間 HTTP プロキシを作成し、ローカルホストからの ElasticSearch アクセスのみを許可する必要があるでしょう。この方法では、ES への直接アクセスがブロックされ、必要なポリシーを決定して適用できます (やった! ;)
「これにカスタム API レイヤーを提供したとしても、誰かが簡単にそれをバイパスできます」: ES がローカルホストからの接続のみを受け入れる場合、それはできません。
メモリ使用量の制限は不可能だと思いますが、プロキシ レイヤー内でクエリを事前に承認することは可能でしょうか?
答え3
ES の前で実行されている Nginx を使用して同様のことを行いました。URL 内のキーワードに基づいて Nginx で「認証」を設定することが可能です。このドキュメントで定義されているユースケースを参照してください。http://www.elasticsearch.org/blog/playing-http-tricks-nginx/
答え4
elasticsearch を openvpn トンネルにバインドしました:
/etc/elasticsearch/elasticsearch.yml 内:
network.host: 172.16.xxx.xxx
ここで、172.16.xxx.xxx は openvpn によって割り当てられた IP アドレスです。