アプリケーションのAPIを通じてElasticsearch Search APIを直接公開しても安全ですか？

Question

私はJava/Spring Boot APIを使ってAngularJSアプリケーションを開発しています。これは、Spring Data Elasticsearchを使用して、Elasticsearchの検索APIにアクセスして検索します。

Page<Address> page = addressSearchRepository.search(simpleQueryStringQuery(query), pageable); 

変数queryがユーザーの検索文字列である：ここでは一例です。 pageableは、ページ番号、ページサイズ、およびソートを指定するオブジェクトです。 QueryBuildersを使用して、他のElasticsearchクエリを作成し、それらを異なるAPIエンドポイントとして公開することができます。

もう1つの方法は、QueryBuilders.wrapperQueryを使用し、JavaScriptから直接Elasticsearchクエリを送信することです。ここでjsonQueryがフルElasticsearchクエリを含む文字列である例である：

Page<Address> page = addressSearchRepository.search(wrapperQuery(jsonQuery), pageable); 

これは、認証されたユーザーのみがアクセスできる安全なエンドポイントになります。これは、ElasticsearchインデックスのSearch APIを直接公開するのと同じようです。索引内のデータがユーザーを表示するのに安全であると仮定すると、これはセキュリティ上のリスクになりますか？私の研究では

これまでのところ、私はクエリを使用してElasticsearchをクラッシュすることが可能であることがわかってきましたが、それは新しいバージョンで問題の大きなではありません。https://www.elastic.co/blog/found-crash-elasticsearch#arbitrary-large-size-parameter

はたぶん、ページサイズを制限しますか、ページサイズが非常に大きいときにスキャンとスクロールAPIを使用すると、これを軽減できます。

私は、スクリプトフィールドは絶対に避けてくださいが、デフォルトでは無効になっていることを知っています（v1.4.3以降）。

Answer 1

あなたはそれを行う方法が分かっていれば、まだElasticsearchをクラッシュさせることができます。たとえば、深いネストされた集約を10個作成する場合、非常にうまく行って休憩を取ることができます。多くの時間がかかるか、非常に高価になるか、メモリを大量に使用するか、JVMでガベージコレクションを行う（基本的にJVMで実行される他のすべてのスレッドをフリーズさせる）、少量のメモリを回収する。この方法でクラスタが応答しなくなる可能性があります。

集計を取って10個の深いネストされた集計を作成すると、クラスタを破壊することはありませんが、特定のSLA用に構築された通常の状況では、特定の量のデータ重い集約（例えば、terms on analyzed文字列フィールド）は、ノードに対して非常に高度に計算されます。

ノードのメモリが不足することはありませんが、ノードはほとんど応答しません。

弾性のチームはimplement other circuit breakersとadd default limits to certain types of queries and aggregations（巨大なタスク）にしようとしています。しかし、ユーザーがESをクラッシュさせないようにすることが目的であれば、すべてのクエリに完全にアクセスできますが、クラッシュさせる方法があると思います。私は、個人的には、ESを公開せず、ユーザーが作成したクエリを使用して、自分が望むものを何でも実行できるようにします。

あなたwrapperが設定されている方法に応じて、私は私のユーザーにクエリ/集計の特定の種類を許可するだろうし、それらのために私は（これらのクエリ制限を受け入れる/aggsに適用可能な）いくつかの制限を課すと思います。