GraphQLのセキュリティ
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
GraphQL APIの特定のセキュリティ上の問題に対処する必要があります:GraphQLサーバーの実行に非常にコストのかかるクエリを作成し、サービス拒否攻撃を引き起こす可能性があります。この問題は、次の2つの方法で軽減できます。
-
クエリの複雑さの分析を使用して、大量のデータを要求するクエリを拒否します。
-
クエリの深さ分析を使用して、深くネストされたクエリを拒否します。
これらの軽減策は、任意のクエリが実行されるすべてのパブリックAPIに適しています。制御するクエリのみをサポートするAPIの場合、ホワイトリストに登録すると問題が完全に軽減されます。
複雑度のデフォルト設定は、/App_Config/Sitecore/Services.GraphQL/Sitecore.Services.GraphQL.configで指定されています。
キャッシングとホワイトリスト
キャッシングとホワイトリスト
GraphQL APIは、Sitecoreキャッシュ インスタンスを使用して、事前に解析および検証された受信クエリを格納します。検証が完了すると、クエリを再度検証する必要はなくなり、キャッシュから取得されます。デフォルトのキャッシュ・サイズは10 MBで、各エンドポイントのサイズを設定できます。
デフォルトのキャッシングメカニズムでは、Apolloが開発したAutomatic Persisted Queries (APQ) プロトコルのサポートも有効になります。APQクライアントは、実行したいクエリのハッシュを送信します。クエリがキャッシュされている場合は、完全なクエリ内容を送信する代わりに、そのハッシュを使用して実行されます。クエリがキャッシュにない場合は、特定のエラー応答が送信され、クライアントはクエリ テキストを使用して要求を再発行します。これにより、サーバーは後で再利用するために要求をキャッシュできます。この手法により、最小限の労力で入力帯域幅を大幅に削減できます。
キャッシュメカニズムでは、クエリホワイトリストを使用することもできます。ホワイトリストは、APIのサービス拒否攻撃に対する保護を提供するだけでなく、クエリ全体を送信する必要はなく、クエリへのポインタ/ハッシュのみを送信する必要があるため、帯域幅の使用量を削減できます (APQとまったく同じです)。GraphQL APIは、権限のあるキャッシュの概念をサポートしており、許可されるクエリはキャッシュ内のクエリのみです。 WhitelistingGraphQLQueryCacheクラスは、次の機能を備えたデフォルトのホワイトリスト実装を提供します。
-
許可されたクエリをファイルとしてディスク上のフォルダーに格納します (ソース管理のコミットを簡単に確認できます)。
-
.graphqlファイルを使用してアプリにクエリを保存し、ファイルごとに1つのGQL操作を保存する場合は、これらのファイルをホワイトリストにコピーできます。
-
受信したクエリをホワイトリスト ファイルに追加する学習モードをサポートします。これは、ビルド時にアプリケーション内のすべてのクエリを実行するエンドツーエンドのテストがある場合に適しています。学習モードは本番環境では無効になっています。
-
保存されたクエリにAPQ互換のハッシュを使用するため、APQクライアントは自動部分なしですべてのAPQ機能に接続して取得できます (実行されたクエリはホワイトリストに含まれている必要があります)。
-
ホワイトリストが変更されると、ホワイトリストが再読み込みされます。
キャッシュ設定は、エンドポイントの設定ファイルに登録されます。カスタムキャッシュの実装は、IGraphQLQueryCacheFactory.次の例は、ホワイトリスト キャッシュを登録する方法を示しています。
認可
認可
GraphQL認証は、ビジネスロジック/スキーマレベルで実行します。各リゾルバー関数は、特定のグラフ・ノードに対して必要に応じて許可を確認する必要があります。
API全体でカスタム承認が必要な場合は、<security> セクションでIAuthorizationFilterベースのクラスを登録して、各API要求を承認できます。