セキュリティの制限

プラグイン

Elasticsearchのプラグインインフラストラクチャは、拡張可能な内容に関して非常に柔軟です。これにより、Elasticsearchはさまざまな（しばしばカスタムの）追加機能に対応できますが、セキュリティに関しては、この高い拡張性にはコストが伴います。私たちはサードパーティプラグインのコード（オープンソースかどうかにかかわらず）を制御できないため、Elastic Stackのセキュリティ機能に準拠していることを保証できません。このため、セキュリティ機能が有効なクラスターでは、サードパーティプラグインは公式にサポートされていません。

ワイルドカードの動作の変更

セキュリティ機能が有効なElasticsearchクラスターは、現在のユーザーが権限を持つデータストリーム、インデックス、およびエイリアスに_allやその他のワイルドカードを適用します。クラスター内のすべてのデータストリーム、インデックス、およびエイリアスには適用されません。

マルチドキュメントAPI

マルチゲットおよびマルチタームベクターAPIは、ユーザーが権限を持たない存在しないインデックスにアクセスしようとするとIndexNotFoundExceptionをスローします。これにより、データストリームまたはインデックスが存在しないという情報が漏洩しますが、ユーザーはそれらのデータストリームやインデックスについて何も知る権限がありません。

フィルタ付きインデックスエイリアス

フィルタを含むエイリアスは、エイリアスの制限で説明されている制限のため、個々のドキュメントへのアクセスを制限する安全な方法ではありません。Elastic Stackのセキュリティ機能は、ドキュメントレベルのセキュリティ機能を通じて、ドキュメントへのアクセスを制限する安全な方法を提供します。

フィールドおよびドキュメントレベルのセキュリティの制限

ユーザーの役割がデータストリームまたはインデックスに対してドキュメントまたはフィールドレベルのセキュリティを有効にする場合：

  • ユーザーは書き込み操作を実行できません：
    • 更新APIはサポートされていません。
    • バルクリクエストに含まれる更新リクエストはサポートされていません。
  • ユーザーは、次のAPIからのアクションを含む、実質的に内容を別の名前でアクセス可能にする操作を実行できません：
  • 次のいずれかが真である場合、検索リクエストのリクエストキャッシュは無効になります：
    • ドキュメントレベルのセキュリティを定義する役割クエリがテンプレート化されている場合、保存されたスクリプトを使用しています。
    • 対象インデックスがローカルインデックスとリモートインデックスの混合である場合。

ユーザーの役割がデータストリームまたはインデックスに対してドキュメントレベルのセキュリティを有効にする場合：

  • ドキュメントレベルのセキュリティは、関連性スコアリングで使用されるグローバルインデックス統計に影響を与えません。これは、スコアが役割クエリを考慮せずに計算されることを意味します。役割クエリに一致しないドキュメントは決して返されません。
  • has_childおよびhas_parentクエリは、役割定義のクエリパラメータとしてサポートされていません。has_childおよびhas_parentクエリは、ドキュメントレベルのセキュリティが有効な検索APIで使用できます。
  • 日付数学式は、日付フィールドの範囲クエリでnowを含むことはできません。
  • リモート呼び出しを行ってクエリデータを取得するクエリはサポートされていません。以下のクエリが含まれます：
    • termsクエリ（用語ルックアップ付き）
    • geo_shapeクエリ（インデックスされた形状付き）
    • percolateクエリ
  • サジェスターが指定され、ドキュメントレベルのセキュリティが有効な場合、指定されたサジェスターは無視されます。
  • ドキュメントレベルのセキュリティが有効な場合、検索リクエストをプロファイルすることはできません。
  • 用語列挙APIは、ドキュメントレベルのセキュリティが有効な場合、用語を返しません。

ドキュメントレベルのセキュリティは、ユーザーが制限されたドキュメントを表示するのを防ぎますが、インデックス全体に関する集約情報を返す検索リクエストを書くことは依然として可能です。インデックス内の特定のドキュメントへのアクセスが制限されているユーザーは、アクセスできないドキュメントにのみ存在するフィールド名や用語について学ぶことができ、特定の用語を含むアクセスできないドキュメントの数をカウントすることができます。

エイリアスを使用する際にインデックスおよびフィールド名が漏洩する可能性

エイリアスに対して特定のElasticsearch APIを呼び出すと、ユーザーがアクセスを許可されていないインデックスに関する情報が漏洩する可能性があります。たとえば、_mapping APIを使用してエイリアスのマッピングを取得すると、レスポンスにはエイリアスが適用される各インデックスのインデックス名とマッピングが含まれます。

この制限が解決されるまで、機密または敏感な情報を含むインデックスおよびフィールド名を避けてください。

LDAPレルム

LDAPレルムは、現在、ネストされたLDAPグループの発見をサポートしていません。たとえば、ユーザーがgroup_1のメンバーで、group_1がgroup_2のメンバーである場合、group_1のみが発見されます。ただし、Active Directoryレルムは、推移的グループメンバーシップをサポートしています。

ユーザーおよびAPIキーのリソース共有チェック

非同期検索およびスクロールリクエストの結果は、初期リクエストを送信した同じユーザーまたはAPIキーによって後で取得できます。検証プロセスは、ユーザー名、認証レルムタイプ、および（ファイルまたはネイティブ以外のレルムの場合）レルム名を比較することを含みます。リクエストを送信するためにAPIキーを使用した場合、そのキーのみが結果を取得できます。このロジックにはいくつかの制限もあります：

  • 2つの異なるレルムが異なるノードで同じ名前を持つことがあります。これはレルムを構成する推奨方法ではないため、リソース共有チェックはこの不整合を検出しようとしません。
  • レルムは名前を変更できます。これにより、非同期検索またはスクロールを送信した後にレルムの名前を変更し、結果を取得しようとすると、リソース共有チェックに不整合が生じる可能性があります。したがって、レルム名の変更は注意して行う必要があります。リソース共有チェックだけでなく、他の問題を引き起こす可能性があります。
  • ユーザー名は、特定の外部認証プロバイダーによってバックアップされたレルムに対して動的に計算されます。たとえば、ユーザー名はLDAPレルムのDNの一部から導出されることがあります。理論的には、外部システムの2つの異なるユーザーが同じユーザー名にマッピングされる可能性があります。この状況を最初から避けることをお勧めします。したがって、リソース共有チェックはこの潜在的な不一致を考慮していません。