GraphQL APIセキュリティとは、GraphQL APIを不正アクセス、悪意のあるリクエスト、データの露出、サービス拒否攻撃、および不正利用から保護するために使用されるプラクティスとテクノロジーの総称です。
オープンソースのクエリ言語である GraphQL は、クライアント（コンピュータ、電話、ブラウザ、ソフトウェアプログラム）に、リクエストするデータに関してかなりの柔軟性を与えます。固定されたレスポンスを返す事前定義済みのエンドポイントに依存するのではなく、クライアントは必要なフィールドと関連データを指定するクエリを構築できます。
その柔軟性により、APIは開発者にとってより効率的になる可能性がありますが、同時に特有のセキュリティ上の考慮事項も生じます。保護が不十分なGraphQL APIでは、攻撃者が計算コストの高いクエリを構築したり、APIスキーマの機密性の高い部分を発見したり、アクセス権のないデータにアクセスしたり、大量の悪意あるリクエストを自動化したりする可能性があります。
したがって、効果的な GraphQL セキュリティには、認証、認可、クエリ コントロール、入力検証、レート制限、アプリケーション セキュリティ、監視、および安全な API 設計を組み合わせる必要があります。
GraphQL API セキュリティは、どのようなツールとプラクティスで構成されていますか？
GraphQL API セキュリティは、GraphQL API を通じて公開されるデータ、オペレーション、インフラストラクチャを保護します。GraphQL API は通常、利用可能なデータの型と、クライアントが実行できるオペレーションを記述するスキーマを公開します。クライアントは、必要な情報やアクションを記述するクエリまたはミューテーションを送信します。
GraphQL API を保護するには、次のような対策やツールが関係します：
認証
認可
入力検証
クエリの深さと複雑さのコントロール
スキーマおよびイントロスペクションの管理。
インジェクション保護
エラー処理
ログとモニタリング
目標は、GraphQL の柔軟性を制限することなく、正当なクライアントに必要な機能を提供することです。
GraphQL API セキュリティはどのように機能しますか？
GraphQL リクエストは通常、「/graphql」のような単一の HTTP エンドポイントに到達します。リクエストには、クライアントがサーバーに実行させたいオペレーションを記述するクエリが含まれます。正当なクライアントは、プロダクトとその提供状況に関する情報を要求する場合があります。
GraphQLサーバーはクエリを解析し、スキーマに照らして検証し、必要なリゾルバーを呼び出し、適切なデータを取得して、レスポンスを返します。
そのプロセスのいくつかの段階でセキュリティコントロールを適用できます。
認証はクライアントを識別します。
認証は、誰または何がリクエストを行っているかを判断します。GraphQL API は、アプリケーションのアーキテクチャに応じて、セッションCookie、API キー、OAuth、または JSON Web Tokens（JWTs）などのメカニズムを使用できます。
認可によってクライアントが実行できることが決まります
認証だけでは十分ではありません。クライアントを識別した後、アプリケーションは、そのIDが特定のオブジェクト、フィールド、またはオペレーションへのアクセスを許可されているかどうかを判断する必要があります。
認可は、GraphQL リゾルバーのみに依存したりスキーマの一部を隠したりするのではなく、ビジネス・ロジック・レイヤーで適用する必要があります。
クエリコントロールは高コストなオペレーションを制限します
GraphQLクエリはネストできます。適切なコントロールがない場合、クライアントは、大量の CPU、メモリ、データベース処理、またはダウンストリーム サービスの呼び出しを必要とするクエリを送信する可能性があります。
アプリケーションは、クエリの深さ、幅、複雑さ、またはコストを分析し、許容可能な制限を超えるリクエストを拒否できます。
レート制限はリクエスト消費を制御します
レート制限は、クライアントがオペレーションを実行する頻度をコントロールできます。GraphQL では、同じ/graphqlエンドポイントに対する2つのリクエストでも計算コストが大きく異なる可能性があるため、組織には HTTP リクエストを単純に数えるだけではなく、より高度なコントロールが必要になる場合があります。
アプリケーション・セキュリティのコントロールは悪意のあるトラフィックを検査します。
Web アプリケーションファイアウォール（WAF）またはWeb アプリケーションおよびAPI 保護 プラットフォームは、インジェクションのような攻撃やその他の悪意のあるペイロードについてリクエストを検査し、それらが GraphQL アプリケーションに到達する前に検出できます。
モニタリングによって異常な動作が検出されます。
ログとセキュリティテレメトリにより、予期しないクエリパターン、繰り返される認可の失敗、異常に高コストなリクエスト、悪意のあるボット、またはトラフィックスパイクが明らかになることがあります。これらのコントロールを組み合わせることで、GraphQL APIの周囲に多層防御を提供します。
GraphQL API セキュリティが必要な理由
GraphQLによってAPIが本質的に安全でなくなるわけではありません。ただし、GraphQLを強力にしている機能の一部は、従来のREST APIとは異なるセキュリティ上の考慮事項も生み出します。
以下は、GraphQLの性質によって生じるリスクと、GraphQL APIセキュリティが非常に重要である理由です。
クライアントはクエリを大幅にコントロールできます。
REST API では、サーバーは一般に、あらかじめ決められたデータ構造を返すエンドポイントを定義します。代わりに、GraphQL では、クライアントが必要とするフィールドとリレーションシップを指定できます。適切な制限がないと、悪意のあるクライアントがその柔軟性を利用して、高コストまたは濫用的なクエリを構築できる可能性があります。
単一のエンドポイントで多くのオペレーションを公開できます。
従来のAPI セキュリティでは、セキュリティポリシーの重要な一部として URL パスがよく使用されます。GraphQL では通常、多くの異なるクエリやミューテーションが同じエンドポイントを介してルーティングされます。そのため、セキュリティ・システムは、/graphqlへのすべてのリクエストが同じオペレーションまたはリスクを表していると想定することはできません。
クエリは計算コストが高くなる可能性があります
GraphQLでは、ネストされた関係を使用できます。深くネストされたクエリや非常に広範なクエリは、多数のリゾルバー呼び出し、データベースオペレーション、またはダウンストリームリクエストを引き起こす可能性があります。攻撃者は、アプリケーションのリソースを消費するために、この動作を意図的に悪用することがあります。
認可はきめ細かく設定できるようになります
ユーザーは、ある GraphQL オブジェクトにはアクセスできても別のオブジェクトにはアクセスできない場合や、オブジェクトの一部のフィールドにはアクセスできても他のフィールドにはアクセスできない場合があります。したがって、関連するすべてのデータアクセス・オペレーションには適切な認可が必要です。
スキーマ情報は攻撃者の助けになる可能性があります。
GraphQL はイントロスペクションをサポートしており、これによりクライアントはスキーマに関する情報をクエリできます。これは開発ツールにとって非常に有用です。ただし、本番環境では、スキーマ情報が利用可能なオペレーションを攻撃者が把握するのに役立つ可能性があるため、無制限のイントロスペクションが必要かどうかを組織が慎重に判断する必要があります。
API は自動化された不正利用を引き寄せます
攻撃者はボットを使用して、偵察、クレデンシャル攻撃、高コストなオペレーションへのクエリ、データのスクレイピング、または大規模な悪用の試行を実行できます。したがって、GraphQL セキュリティでは、脆弱性と正当な機能の悪用の両方に対処する必要があります。
GraphQL API の一般的なセキュリティリスクは何ですか？
認可の欠陥
APIはユーザーを正しく認証しても、そのユーザーが特定のオブジェクトまたはフィールドへのアクセスを許可されるべきかどうかの検証に失敗する場合があります。たとえば、クエリ内のオブジェクト識別子を変更することで、ある顧客が別の顧客の個人情報を取得できてはなりません。
過剰なクエリの深さ
攻撃者は、ますます大量の処理を必要とする深くネストされたクエリを構築できます。深さの制限により、リクエストがアプリケーションの妥当なネスト要件を超えないようにできます。
クエリの複雑さとリソース枯渇
深さだけが問題ではありません - 比較的浅いクエリでも、数千のオブジェクトを要求したり、高コストのリゾルバーを呼び出したりする可能性があります。クエリのコストまたは複雑さの分析により、リクエストの実行に必要なリソースを見積もることで、より正確な保護を提供できます。
バッチ処理の悪用
GraphQL の実装では、複数のオペレーションをまとめて送信できる場合があります。バッチ処理によって正当なアプリケーションの効率が向上する可能性がある一方で、攻撃者はこれを利用して、単純なリクエストベースのレート制限を回避したり、より少ない HTTP リクエスト内で大量のオペレーションを実行したりしようとする可能性があります。
インジェクション攻撃
GraphQLリゾルバーは、多くの場合、データベースやその他のバックエンド・システムとやり取りします。ユーザー入力がダウンストリームで安全でない方法で処理される場合、GraphQL アプリケーションは依然として SQL インジェクション、コマンドインジェクション、その他のインジェクション攻撃に対して脆弱である可能性があります。
情報漏洩
詳細なエラーによって、スタックトレース、内部実装の詳細、または攻撃者にとって有用なその他の情報が露出する可能性があります。スキーマ・イントロスペクションも、有効になっている場合は、利用可能な型やオペレーションに関する情報を開示する可能性があります。
サービス拒否攻撃
高コストなクエリ、過剰なエイリアス、バッチ処理、繰り返しのリクエスト、またはその他のリソース集約型のオペレーションを使用して、アプリケーションのパフォーマンスや可用性を低下させることができます。
自動スクレイピングと不正使用
技術的に有効なGraphQLクエリであっても、大規模に自動実行される場合は悪用的となる可能性があります。Bot Managementとレート制限は、脆弱性に重点を置いたAPIセキュリティを補完する重要な要素となる場合があります。
GraphQL API セキュリティのベストプラクティスとは何ですか？
GraphQLセキュリティは、アプリケーション自体から始め、ランタイムセキュリティコントロールで強化する必要があります。
1. 強力な認証を必須にします。
非公開のオペレーションは、適切な認証メカニズムで保護してください。確かな理由もなくカスタム認証スキームを構築するのではなく、確立されたID標準と安全なセッションまたはトークン処理を使用してください。
2. 関連するすべてのレイヤーで認可を適用する
認証済みユーザーが、スキーマによって公開されているすべてのオブジェクトにアクセスできると想定しないでください。認可はアプリケーションのビジネスルールに結び付け、データにアクセスまたは変更する際に一貫して適用する必要があります。
3. クエリの深さを制限する
クエリをどの程度深くネストできるかについて、妥当な制限を設定してください。適切な最大値は、アプリケーションの正当な要件によって異なります。
4. クエリ・コスト分析を実装する
想定されるリソース消費量に基づいてフィールドまたはオペレーションにコストを割り当て、計算されたコストが許容可能なしきい値を超えるリクエストを拒否します。これにより、深さの制限だけの場合よりも、より有意義な保護を提供できます。
5. レート制限を適用する
アプリケーションのリスクと通常の従量課金プランのパターンに応じて、クライアントをレート制限します。可能であれば、すべての HTTP リクエストを同等に扱うのではなく、実際の GraphQL オペレーションまたはリソースコストを考慮してください。
6. コントロールのバッチ処理とエイリアス
クライアントが一度にリクエストできるオペレーション、エイリアス、またはフィールドの数に適切な制限を設定してください。これにより、従来のレート制限を回避したり、想定外に高コストなワークロードを作成したりする機会を減らすことができます。
7. すべての入力を検証する
GraphQL の引数は信頼できない入力として扱ってください。スキーマ検証、パラメータ化されたデータベースクエリ、安全な API、コンテキストに応じた出力処理を使用してください。
8. イントロスペクションについて意図的に決定します
イントロスペクションは開発やツールにとって有用ですが、本番環境でのアクセスは組織の要件に一致している必要があります。イントロスペクションを無効化または制限しても認可の代わりにはなりませんが、不必要な情報露出を減らすことはできます。
9. 過剰なエラー詳細を避ける
スタックトレース、データベース情報、内部サービスの詳細、またはその他の機密性の高い実装情報を公開することなく、正当なクライアントに有用なエラーを返します。
10. タイムアウトを使用する
クエリがサーバーリソースを無期限に消費できるようにしてはなりません。適切な実行、データベース、およびダウンストリーム・サービスのタイムアウトにより、予期せず高コストなオペレーションの影響を抑えることができます。
11. WAF で GraphQL エンドポイントを保護する
WAF は、悪意のあるアプリケーションリクエストに対する追加のセキュリティレイヤーを提供できます。安全な GraphQL 設計の代わりにはなりませんが、脆弱なアプリケーションコンポーネントに攻撃が到達するのを防ぐのに役立ちます。
12. GraphQL トラフィックを監視する
リクエスト率、エラー、認証の失敗、オペレーションパターン、クエリの複雑さ、バックエンドレイテンシ、リソース消費を追跡します。効果的なオブザーバビリティにより、ユーザーに重大な影響が及ぶ前に、攻撃やパフォーマンスの問題を特定しやすくなります。
GraphQL APIセキュリティを必要とするのは誰ですか？
GraphQL API を公開している組織は、適切なセキュリティ・コントロールを実装する必要がありますが、機密データ、大量のトラフィック、または価値の高いビジネス・オペレーションを扱う API では、その必要性が特に重要になります。
SaaSプロバイダー
GraphQL を使用すると、フロントエンド・アプリケーションは複雑な顧客データやアプリケーション・データを効率的に取得できます。マルチテナント環境では、データが顧客間の境界を越えないようにするために、強力な認可が不可欠です。
eコマース企業
GraphQL API は、プロダクトカタログ、顧客アカウント、カート、在庫、チェックアウト機能、その他の高価値のオペレーションを公開する可能性があります。これらの API は、スクレイピング、認証情報攻撃、不正行為、可用性攻撃を引き付ける可能性があります。
ファイナンスサービス
金融情報または個人情報を扱う API には、強力な認証、認可、監視、不正使用の防止が必要です。
メディア/出版企業
GraphQLは大規模なコンテンツライブラリへの柔軟なアクセスを提供できますが、不正なスクレイピングやリソースを大量に消費するクエリの標的になる可能性もあります。
モバイルおよびアプリケーション開発者
異なるクライアントが異なるデータのサブセットを必要とする場合、GraphQL は有用です。モバイルアプリケーションは依然として公開到達可能な API と通信するため、攻撃者は公式アプリケーションを使用するのではなく、API と直接やり取りできる可能性があります。
マイクロサービスを使用する企業
GraphQL は、複数のバックエンドサービスにまたがる統合 API レイヤーを提供できます。そのため、1つの GraphQL インターフェースが多数の内部システムに分散したデータや機能へのアクセスを提供する可能性があるため、セキュリティは特に重要になります。
FastlyはどのようにGraphQL APIの保護に役立ちますか？
Fastly は、GraphQL アプリケーション内で実装されるコントロールを補完できる複数のセキュリティ機能を提供します。
Fastly Next-Gen WAF
Fastly Next-Gen WAF は、悪意のあるリクエストから Web アプリケーションと API を保護します。従来の正規表現マッチングのみに依存するのではなく、FastlyのSmartParse検出技術を使用してリクエスト・パラメータを分析し、悪意のあるアプリケーションの動作を特定します。
これにより、GraphQL API を標的とするインジェクションやその他のアプリケーションレイヤー攻撃に対する追加の保護レイヤーを提供できます。
Fastly API セキュリティ機能
Fastly の Web アプリケーションおよび API 保護 機能は、従来の Web アプリケーションとあわせて API を保護するうえで、組織に役立ちます。セキュリティをエッジに配置することで、悪意のあるリクエストが GraphQL アプリケーション、データベース、またはバックエンド・サービスのリソースを消費する前に検査できます。
これは、1つのリクエストが下流で大量の処理を引き起こす可能性がある GraphQL アーキテクチャで特に役立ちます。
Fastly Bot Management
GraphQLリクエストは、被害を引き起こすために脆弱性を悪用する必要はありません。攻撃者は、自動化されたクライアントを使用してデータをスクレイピングしたり、スキーマやオペレーションを調査したり、アカウント攻撃を試みたり、高コストなクエリを繰り返し呼び出したりできます。
Fastly Bot Management は、自動化されたトラフィックの特定と管理を支援し、組織が不要なボットに適切なコントロールを適用しながら、正当なユーザーと承認された自動化のアクセスを維持できるようにします。
レート制限
Fastly のレート制限機能は、保護されたアプリケーションに到達する前に過剰なトラフィックを制御するのに役立ちます。GraphQL 環境では、エッジのレート制限は、クエリコスト分析などのアプリケーションレベルのコントロールを補完できます。エッジでは過剰なリクエストアクティビティを制限できる一方で、GraphQL サーバーでは各オペレーションの実際のコストと認可要件に基づいて、より詳細なポリシーを適用できます。
Fastly DDoS Protection
GraphQL エンドポイントは、特に攻撃者がバックエンドのリソースを不均衡に消費するクエリを特定した場合に、アプリケーションレイヤー DDoS 攻撃の標的になる可能性があります。DDoS Protection は、エッジで悪意のあるトラフィックを検出して軽減し、アプリケーション・インフラストラクチャに到達する攻撃トラフィックの量を削減するのに役立ちます。
エッジデリバリーとキャッシュ
GraphQLのレスポンスを安全にキャッシュ可能な場合、Fastlyの配信機能により、GraphQLインフラストラクチャへの繰り返しのリクエストを削減できます。GraphQLのキャッシュには慎重な設計が必要です。これは、レスポンスがクエリ、変数、認証、およびユーザー固有のデータに依存する可能性があるためです。組織は、キャッシュキーとポリシーがそれらの違いを正確に表している場合にのみ、レスポンスをキャッシュする必要があります。
適切に実装すると、エッジ・キャッシュによってバックエンドへのリクエストを削減し、API パフォーマンスを向上させることができます。
リアルタイムの可視性
Fastly は、チームが不審な API アクティビティを調査するのに役立つリアルタイムロギング とセキュリティ可視性を提供します。GraphQL デプロイでは、これにより、GraphQL サービスに到達する前のトラフィックをセキュリティチームとオペレーションチームが可視性できるため、アプリケーションレベルのオブザーバビリティを補完できます。
Fastly は GraphQL セキュリティ戦略にどのように適合しますか？
Fastlyは、適切に保護されたGraphQLアプリケーションの周囲に追加されるセキュリティレイヤーと考えるのが最適であり、GraphQL実装内のセキュリティに代わるものではありません。
アプリケーションは、次のものを含むコントロールについて引き続き責任を負う必要があります：
認証
オブジェクト・レベルおよびフィールド・レベルの認可
クエリの深さの制限
クエリの複雑さまたはコスト分析
安全なリゾルバーの実装
入力検証
安全なエラー処理
適切なイントロスペクションポリシー
Fastlyは、Next-Gen WAF、API protection、Bot Management、レート制限、DDoS Protection、エッジデリバリー、リアルタイムの可視性によって、これらのコントロールを補完できます。
これらのレイヤーを組み合わせることで、組織は悪意のあるリクエストがGraphQLインフラストラクチャに到達する前にブロックし、自動化された不正使用をコントロールし、トラフィック急増の影響を軽減し、APIをアプリケーション攻撃から保護し、不要なバックエンドリソース消費を抑えることができます。
GraphQL APIセキュリティの中心原則は、クライアントにアプリケーションリソースやデータに対する無制限のコントロールを与えることなく、GraphQLの柔軟性を維持することです。安全なGraphQL設計をエッジベースのアプリケーションおよびAPI保護と組み合わせることで、組織はそのバランスを実現しやすくなります。