F5 NGINX App Protect WAF で GraphQL と gRPC 双方向ストリーミング API を保護

COVID-19 パンデミック以降、デジタル経済は拡大を続けており、組織の 90% が最新のアプリ アーキテクチャを拡大しています。 F5 の2023 年アプリケーション戦略の現状レポートでは、調査対象となった世界中の 1,000 人の IT 意思決定者のうち 40% 以上が、自社のアプリ ポートフォリオを「最新」であると評価しています。 この割合はここ数年着実に増加しており、2025年までに50%を超えると予測されています。 しかし、最新のアプリやマイクロサービスの使用の増加に伴い、API と API エンドポイントも急増し、脆弱性の可能性と攻撃対象領域が飛躍的に増加しています。

F5 CTO オフィスのレポート「Continuous API Sprawl」によると、2021 年には世界中に約 2 億個の API があり、2030 年までにその数は 20 億個に近づくと予想されています。  この急速な API の増加によって生じる複雑さをさらに増大させているのが、ハイブリッド環境とマルチクラウド環境にわたる分散アプリケーションを管理するという課題です。 2023 年のアプリケーション戦略の現状レポートの回答者は、マルチクラウド環境にアプリを展開する際の最大の課題として、複数のツールと API を管理する複雑さを挙げました。 一貫したセキュリティ ポリシーの適用とアプリのパフォーマンスの最適化は、僅差で 2 位にランクされました。

API セキュリティが収益に重要な理由

API は最新のアプリケーションの構成要素であるだけでなく、デジタル ビジネスの中核を成しています。F5 2023 レポートで調査された組織の 58% が、収益の少なくとも半分をデジタル サービスから得ていると回答しています。 API はユーザーとアプリ、アプリ間の通信を可能にし、顧客のプライベートデータや企業内部の情報へのアクセスを提供することから、攻撃者にとって格好のターゲットとなります。 2022 年に最も好まれた攻撃ベクトルは API でした。

API の保護は、全体的なアプリケーション セキュリティ戦略において最も重要です。 攻撃は、消費者のプライバシーの侵害（それ自体は悪いことですが）をはるかに超えて、公共の安全を害し、知的財産の損失につながるほどの深刻な結果をもたらす可能性があります。 2022 年に発生した各タイプの API 攻撃の例をいくつか示します。

• 消費者のプライバシー– Twitter は数年にわたる API 攻撃を経験しました。 2022年12月、ハッカーがTwitterユーザー2億人のプロフィールデータとメールアドレスを盗んだ。 その4か月前に、CloudSEKの研究者らは、有効なTwitter APIキーとシークレットを漏洩するモバイルアプリケーション3,207件を発見した。 そしてその1か月前には、ハッカーがAPIの脆弱性を悪用し、 540万人のユーザーのデータを押収して販売していた。
• 公共の安全– 研究者チームは、トヨタ、メルセデス、BMWを含む約 20 社の大手自動車メーカーにわたって重大な API セキュリティの脆弱性を発見しました。 今日では多くの車がスマートデバイスのように機能しており、ハッカーは車のVINや所有者の個人情報を盗む以上のことが可能です。 車の位置を追跡し、リモート管理システムを制御して、車のロックを解除して始動したり、車を完全に無効にしたりすることができます。
• 知的財産– 世界中で 100 万人以上の開発者がコードを出荷するために使用する CI/CD プラットフォームであるCircleCIの標的となった従業員が、マルウェア攻撃の被害者となりました。 この従業員は本番アクセス トークンを生成する権限を持っていたため、ハッカーは顧客の API キーとシークレットを盗むことができました。 この侵害は3週間近く気づかれずにいた。 CircleCI は、顧客の秘密が盗まれ、サードパーティ システムへの不正アクセスに使用されたかどうかを判断できなかったため、プロジェクトと個人の API トークンをローテーションするように顧客にアドバイスすることしかできませんでした。

これらの API 攻撃は警告の教訓となります。 API にセキュリティ上の脆弱性があり、保護されていないまま放置されると、その影響は金銭的なコストをはるかに超えるものになる可能性があります。 API セキュリティの重要性は強調しすぎることはありません。

F5 NGINX が API のセキュリティ保護にどのように役立つか

NGINX API 接続スタックソリューションは、マルチクラウド環境全体で API ゲートウェイと API を管理するのに役立ちます。 NGINX App Protect WAFとともにNGINX Plus を API ゲートウェイとして導入することで、F5 2023 State of Application Strategy レポートで特定された上位 3 つの API 課題 (マルチクラウド環境全体での API の複雑さの管理、セキュリティ ポリシーの確保、アプリ パフォーマンスの最適化) に対処する一般的な API エクスプロイトの防止と軽減に役立ちます。また、前のセクションで説明した種類の API 攻撃にも対処できます。 NGINX Plus は、API ゲートウェイとして使用するなど、さまざまな方法で使用できます。API ゲートウェイでは、API リクエストを迅速にルーティングしたり、API クライアントを認証および承認して API を保護したり、トラフィックをレート制限して API ベースのサービスを過負荷から保護したりできます。

NGINX Plus は、 OWASP API セキュリティ トップ 10 の脆弱性だけでなく、その他の脆弱性に対してもすぐに使用できる保護を提供します。 また、不正な形式の Cookie、JSON、XML をチェックし、許可されたファイルの種類と応答ステータス コードを検証し、攻撃を隠すために使用される回避手法を検出します。 NGINX Plus API ゲートウェイは、REST、GraphQL、gRPC などの HTTP または HTTP/2 API プロトコルの保護を保証します。

NGINX App Protect WAF は、OWASP API セキュリティ トップ 10 およびOWASP (アプリケーション) トップ 10に対する基本的な保護を超えた、7,500 を超える高度なシグネチャ、ボット シグネチャ、脅威キャンペーンからの保護を備えた、軽量で高性能なアプリおよび API セキュリティを提供します。 これにより、シフトレフト戦略が可能になり、API セキュリティの自動化が容易になり、セキュリティ アズ コードが CI/CD パイプラインに統合されます。 AWS、Azure、Cloudflare WAF に対するテストでは、NGINX App Protect WAF は、より優れたパフォーマンスと低いレイテンシを維持しながら、強力なアプリおよび API セキュリティを実現することが確認されました。 詳細については、 GigaOm レポートをご覧ください。  

NGINX App Protect WAF は NGINX Plus API ゲートウェイに組み込まれているため、API トラフィックのホップが 1 つ少なくなります。 レイヤー間のホップが少なくなると、レイテンシ、複雑さ、障害ポイントが減少します。 これは、WAF と統合されない一般的な API 管理ソリューションとはまったく対照的です (WAF を個別に展開する必要があり、セットアップ後は API トラフィックが WAF と API ゲートウェイを個別に通過する必要があります)。 NGINX の緊密な統合により、セキュリティを損なうことなく高いパフォーマンスを実現します。

GraphQL と gRPC が人気上昇中

アプリおよび API 開発者は、柔軟性、速度、使いやすさ、展開のしやすさを向上させる新しい方法を常に模索しています。 Postman の2022 年 API 状況レポートによると、REST は現在でも最も人気のある API プロトコル (89%) ですが、GraphQL (28%) と gRPC (11%) の人気も高まり続けています。 最終的に、API プロトコルの選択は、アプリケーションの目的とビジネスに最適なソリューションに大きく依存します。 各プロトコルにはそれぞれ独自の利点があります。

GraphQL API を使用する理由

GraphQL API を使用する主な利点は次のとおりです。

• 適応性- クライアントがデータの要求、タイプ、および形式を決定します。
• 効率性- オーバーフェッチは発生せず、リクエストは作成されたスキーマに対して実行され、返されるデータはまさにリクエストされたもの（そしてそのみ）です。 リクエストとレスポンスのデータのフォーマットは同一であるため、GraphQL API は高速で予測可能であり、スケーリングが容易です。
• 柔軟性- 12 を超える言語とプラットフォームをサポートします。

GitHub はGraphQL のよく知られたユーザーの 1 つです。 同社は、スケーラビリティと柔軟性の理由から、2016 年に GraphQL に切り替えました。

gRPC API を使用する理由

gRPC API を使用する主な利点は次のとおりです。

• パフォーマンス- 軽量でコンパクトなデータ形式により、リソースの要求が最小限に抑えられ、メッセージのエンコードとデコードが高速化されます。
• 効率的– protobufsデータ形式は、構造化されたデータをシリアル化することで通信を効率化します。
• 信頼性 – HTTP/2とTLS/SSLが必須で、デフォルトでセキュリティが向上します。

処理能力のほとんどはクライアント側で発揮され、管理と計算はリソースをホストするリモート サーバーにオフロードされます。gRPC は、マイクロサービス間のトラフィックや、リクエスター (IoT デバイスなど) が限られたリソースを節約する必要があるデータ収集など、一定量のデータや処理が日常的に必要なユース ケースに適しています。

Netflix は、gRPC API のよく知られたユーザーの一例です。

NGINX App Protect WAF で GraphQL API を保護する

NGINX App Protect WAF は、REST および gRPC API に加えてGraphQL API もサポートするようになりました。 攻撃シグネチャを適用し、悪意のあるエクスプロイトを排除し、攻撃から防御することで、GraphQL API を保護します。 GraphQL トラフィックはネイティブに解析されるため、NGINX App Protect WAF は GraphQL 構文とプロファイルに基づいて違反を検出し、攻撃シグネチャを適用できます。 イントロスペクション クエリを可視化することで、NGINX App Protect WAF はクエリをブロックできるだけでなく、応答で検出されたパターンもブロックできます。 この方法は、攻撃を検出し、ペイロードの適切なセグメントでシグネチャを実行するのに役立ち、これにより誤検知を減らすのに役立ちます。
 
このデモでは、NGINX App Protect WAF が GraphQL API を攻撃からどのように防御できるかを学びます。

NGINX App Protect WAF を使用した GraphQL API セキュリティの利点:

• セキュリティパラメータを定義する– アプリセキュリティポリシーの一部として、GraphQLテンプレートとコンテンツプロファイルのパラメータの合計長と値を組織のポリシーに従って設定します。
• 誤検知を減らす– GraphQL リクエストでの攻撃をより適切に検出するためのきめ細かな制御により、攻撃防止の精度を向上させます。
• 悪意のある攻撃を軽減– 1 つの HTTP リクエストでバッチ処理されるクエリの最大数を定義して、悪意のある攻撃や攻撃のリスクを軽減します。
• DoS攻撃を排除– コンテンツプロファイルの最大構造深度を設定して、再帰クエリによるDoS攻撃を阻止します。
• APIリスクの露出を制限する– イントロスペクションクエリに制約を適用して、ハッカーがAPI構造を理解して侵入するのを防ぎます。

NGINX App Protect WAF を使用した安全な gRPC 双方向ストリーミング API

NGINX App Protect WAF は、単項メッセージ タイプに加えてgRPC 双方向ストリーミングをサポートするようになり、メッセージ ストリーム (クライアント、サーバー、またはその両方) を使用する gRPC ベースの API を保護できるようになりました。 これにより、通信タイプに関係なく、gRPC API に完全なセキュリティが提供されます。

NGINX App Protect WAF は、スキーマの適用、サイズ制限の設定、不明なファイルのブロック、リソース枯渇型の DoS 攻撃の防止によって gRPC API を保護します。 インターフェイス定義言語 (IDL) ファイルを NGINX App Protect WAF にインポートして、gRPC メッセージの構造とスキーマを適用し、適切な場所で攻撃をスキャンできるようになります。 これにより、gRPC を介してアプリケーションを悪用する試みを正確に検出できるようになり、コンテキストなしで間違った場所でセキュリティをスキャンしたときに発生する可能性のある誤検知を回避できます。

このデモでは、NGINX App Protect WAF が gRPC 双方向 API を攻撃から防御する方法を学びます。

NGINX App Protect WAF による gRPC API セキュリティの利点:

• 包括的な gRPC 保護– 単方向から双方向ストリーミングまで、通信タイプに関係なく完全なセキュリティを実現
• 誤検知の削減– gRPC メッセージ構造とスキーマの適用により精度が向上し、gRPC リクエストにおける攻撃の検出が向上します。
• 悪意のあるエクスプロイトをブロック– gRPC メッセージの各フィールドに正しいタイプと期待されるコンテンツが含まれていることを強制し、不明なフィールドをブロックする機能を備えています。
• DoS攻撃を排除– リソース枯渇型のDoS攻撃を防ぐためのメッセージサイズの制限

SecOps チームと API 開発チームの両方が API セキュリティを管理および自動化できます

Postman の2022 年 API の現状レポートでは、調査対象となった 37,000 人の開発者と API プロフェッショナルのうち 20% が、組織内で少なくとも月に 1 回は API インシデントが発生し、その結果、データの損失、サービスの損失、不正使用、不適切なアクセスが発生していると述べています。 対照的に、回答者の 52% は年間 1 回未満しか API 攻撃を受けておらず、API セキュリティのシフトレフト戦略の一環としてセキュリティを早期に組み込むことの重要性が強調されています。 API はアプリケーションよりも頻繁に公開されるため、シフトレフト戦略が API セキュリティに適用されるケースが増えています。 組織がシフトレフトの文化を採用し、セキュリティ アズ コード (Security as Code)を CI/CD パイプラインに統合すると、API 開発の各段階にセキュリティが組み込まれ、開発者の俊敏性を維持し、展開速度を加速できます。

保護を API 固有にする必要がある重要な領域は、gRPC IDL ファイルや GraphQL クエリなどの API スキーマの検証です。 スキーマは各 API に固有であり、API バージョンごとに変更されます。 API スキーマを自動化する場合、API を更新するたびに、そのファイル内の構成とコードも更新する必要があります。 WAF 構成は、API バージョンの変更に対応するために自動的に展開できます。 NGINX App Protect WAF はスキーマを検証し、リクエストが API のサポート内容 (メソッド、エンドポイント、パラメーターなど) に準拠していることを確認できます。 NGINX App Protect WAF は、SecOps チームが作成できる宣言型ポリシーを使用して一貫したアプリ セキュリティを実現し、API 開発チームは API セキュリティを管理および展開して、よりきめ細かな制御と俊敏性を実現します。 ハイブリッドおよびマルチクラウド環境全体で API セキュリティを大規模に自動化したい場合は、NGINX App Protect WAF が役立ちます。

まとめ

最新のアプリ ポートフォリオは拡大し続けており、マイクロサービスの使用により API がさらに増加しています。 API セキュリティは、特にハイブリッド環境やマルチクラウド環境で運用している組織にとって複雑かつ困難です。 API セキュリティが不足すると、金銭的なコストを超えた壊滅的なロングテール効果が生じる可能性があります。 NGINX App Protect WAF は、REST、GraphQL、gRPC API の保護を含む包括的な API セキュリティを提供し、SecOps チームと API チームがシフトレフトして、API ライフサイクル全体と分散環境全体でセキュリティを自動化するのに役立ちます。

今すぐ 30 日間の無料トライアルで NGINX App Protect WAF をお試しください。

追加リソース

ブログ: NGINX App Protect WAF で API ゲートウェイを保護する
電子書籍: 最新のアプリと API のセキュリティ
電子書籍: O'Reilly の API アーキテクチャをマスターする
データシート： NGINX アプリ保護 WAF