NGINX App Protect WAF で API ゲートウェイを保護する

モノリスがマイクロサービスに移行するにつれて、アプリケーションはかつてないほど速く開発されます。 競争力を維持するにはスピードが不可欠であり、API はこうした急速な近代化の取り組みの最前線に立っています。 しかし、アプリケーションの最新化のための API の普及は、アプリのセキュリティに大きな影響を与えます。 API は脆弱な攻撃対象であり、アプリケーション ロジックや機密データが他のアプリや第三者に公開されます。 API の使用が増えるにつれて、API ゲートウェイの必要性も高まります。

F5 の2021 年アプリケーション戦略の現状レポートによると、組織はさまざまな方法で近代化を進めており、API はこれらの近代化の取り組みの中でトップを占めています。

• 58%が最新のユーザーインターフェースを実現するためにAPIレイヤーを追加している
• 51% が最新のアプリケーション コンポーネント (Kubernetes など) を追加しています。
• 47% がリファクタリング（アプリケーションコード自体の変更）を行っています
• 40%がモダナイズせずにパブリッククラウドに移行（リフト＆シフト）している

組織が成長するにつれて、API ゲートウェイを導入することで API リスクを軽減できます。 F5 の更新された2022 年のアプリケーション戦略の現状レポートでは、API ゲートウェイはエッジ上またはその近くで最高のパフォーマンスを発揮することがわかります。 ここで、API ゲートウェイは、攻撃がネットワーク全体に影響する前に攻撃を阻止し、複数の API に対して均一で一貫した保護を提供します。 API ゲートウェイはアプリの内部構造をカプセル化し、クライアントと API 間の通信を効率化します。クライアントは特定のサービスを呼び出すのではなく、API ゲートウェイに接続するだけです。 これにより、クライアントに特定の API が提供され、クライアントと API 間のラウンドトリップの回数が削減され、クライアント コードが簡素化されます。

F5 NGINX のお客様は、分散環境全体に API ゲートウェイを正常に導入しています。 しかし、API ゲートウェイが安全でない場合、悪意のある人物が侵入する可能性があります。 NGINX には、絶えず変化する環境において API ゲートウェイの背後にあるアプリのセキュリティを確保するための強力なセキュリティ ツールがあります。

API が増えると攻撃対象領域も増える

API は新しいものではありません。 Web ベースの API は 1990 年代にまで遡り、小規模な分散ネットワーク間の通信として、今日のインターネット以前にも API のバージョンが存在していました。 私たちが今目にしているのは、API を使用した最新のアーキテクチャであり、これがゲームを変えたのです。

API は近代化を加速させる上で重要な役割を果たしますが、同時にその悪用も容易になっています。 マイクロサービス アーキテクチャでは、単一の API に数百のエンドポイントを持たせることができ、単一のアプリケーションは API を使用して相互に接続する多数のマイクロサービスで構成できます。 これは、セキュリティ保護すべきエントリ ポイントが 1 つだけだった過去のモノリシック アプリとは異なります。 各マイクロサービスが複数の API エンドポイント セットを公開するため、潜在的な攻撃対象領域は 10 倍に増加します。

F5 の 2022 年のレポートでは、ほとんどの組織が 200 ～ 1,000 個のアプリを保有しており、77% が複数のクラウドでアプリケーションを実行していることも明らかになりました。 分散環境全体のポートフォリオに追加されるアプリや API が増えるほど、攻撃対象となる領域が拡大します。

OWASP API セキュリティ トップ 10 の脆弱性

特性上、API はオープンであり、機密データを公開する可能性があります。 Open Web Application Security Project (OWASP) は、OWASP API セキュリティ トップ 10 プロジェクトで最も蔓延している脆弱性を強調しています。

今日のビジネスでは、開発サイクルが加速するにつれて、俊敏性とスピードが求められます。 この脆弱な API 主導の環境におけるセキュリティ ソリューションは、適応性が高く、軽量で、API の自動展開プロセスの一部として組み込まれる必要があります。

F5 NGINX PlusでAPIセキュリティを始めましょう

注目度の高い API 攻撃は定期的にニュースの見出しを飾ります。 2019年、ライドシェア会社UberのAPIに重大なバグが発見されました。脆弱なAPIエンドポイントにより、悪意のある人物が乗客の認証トークンを含む貴重なデータを盗むことが可能でした。 幸いなことに、このバグは被害が発生する前に発見されました。 2021年、LinkedInはそれほど幸運ではありませんでした。APIの脆弱性により、ハッカーが7億人を超えるLinkedInユーザーのデータを侵害し、それがダークウェブで販売されました。

F5 NGINX Plus をAPI ゲートウェイとして導入することで、API ルーティングと配信を処理する際に、高いパフォーマンスでこの高速 API 環境を実現できます。 独立系技術調査分析会社 GigaOm は、 NGINX を他の API ゲートウェイ ソリューションと比較しました。 ベンチマーク結果によると、NGINX は 30 ミリ秒未満のレイテンシで 1 秒あたり 30,000 件のリクエストを配信でき、これはハイパースケーラーの API ゲートウェイよりも 1000 倍低いレイテンシです。

NGINX Plus は、OWASP API の脆弱性に対する保護をすぐに使用できるだけでなく、不正な Cookie、JSON、XML のチェックや、許可されたファイル タイプと応答ステータス コードの検証などの追加のセキュリティ保護も提供します。 HTTP RFC への準拠を保証し、攻撃を隠すために使用される回避手法を検出します。

NGINX Plus は、API リクエストを迅速にルーティングし、API クライアントを認証および承認して API を保護し、トラフィックのレート制限を行って API ベースのサービスを過負荷から保護します。 これらのツールは、OWASP API セキュリティ トップ 10 の脆弱性からも API を保護します。

• 認証および承認メカニズム– 適切なアクセス権限を持つクライアントのみが API を使用できるようにします。 そのようなメカニズムの 1 つは、JSON Web Token (JWT) のクレームです。 これにより、OWASP API セキュリティ トップ 10 の複数の脆弱性が解決されます。 オブジェクト レベルの認証の破損(API1)、ユーザー認証の破損(API2)、関数レベルの認証の破損(API5)、ログ記録と監視の不十分さ(API10)。
• レート制限ポリシー– 定義された期間内に API ゲートウェイが各 API クライアントから受け入れるリクエストの数に制限を設定することで、API が過負荷になるのを防ぎ、DDoS 攻撃を軽減します。 NGINX Plus を使用すると、レート制限をソースごとに設定できるため (たとえば、JWT クレームの値に基づいて)、有効なユーザーに影響が及ぶことはありません。 これは、リソース不足とレート制限 (API4) の脆弱性に対処するのに役立ちます。

F5 NGINX App Protect WAF で API を強化

F5 NGINX App Protect WAFを使用して API ゲートウェイを保護すると、追加の API セキュリティが提供され、インジェクション(API8) などの OWASP 攻撃が軽減されます。 OWASP API 保護に最低限の機能しか提供しない他の API ゲートウェイおよび管理プロバイダーとは異なり、NGINX App Protect WAF は、リモート コード実行 (RCE)、クロスサイト スクリプティング (XSS)、その他の攻撃ベクトルなどの脆弱性に対する追加の保護を提供します。 NGINX App Protect WAF は、不十分なログ記録と監視(API10) に必要な攻撃の可視性も提供します。 記録された攻撃の詳細は、追加の分析のために、セキュリティ情報およびイベント管理 (SIEM) システムまたはその他の顧客データ レイクに送信できます。

NGINX Plus を API ゲートウェイおよびロードバランサーとして使用している場合（インターネットに公開する必要がある API のルーティングや、外部の開発者やパートナー向け）、保護のために NGINX App Protect WAF を導入するのに最適な場所です。 API トラフィックのホップが 1 つ少なくなるため、複雑さが最小限に抑えられ、レイテンシも最小で保護を追加できます。

特定の業界における機密データ（個人識別情報 [PII]）の取り扱いに関する PCI コンプライアンス要件では、オープンなパブリック ネットワーク全体でペイロードをエンドツーエンドで暗号化する必要があります。 ロードバランサーまたは CDN の背後にある API ゲートウェイに NGINX App Protect WAF を配置すると、ペイロードは API ゲートウェイで復号化されるまで完全に暗号化されたままになります。 したがって、機密データの処理要件を満たしながら、API を保護することができます。

F5 NGINX App Protect WAF による多層防御

ロード バランサーがあり、そのロード バランサー上に F5 Advanced WAF などの WAF が配置されている場合があります。 その背後には、API ゲートウェイがデプロイされています。 では、ロードバランサーにすでに WAF がある場合、なぜ API ゲートウェイに WAF が必要なのでしょうか?

エッジのロードバランサーと WAF の組み合わせから環境内の API ゲートウェイと WAF の組み合わせに移行することの主な利点の 1 つは、セキュリティをより厳格かつきめ細かく制御できることです。 セキュリティの責任を API チームに引き渡すことで、ポリシーをより API 固有のものにすることができます。

この 2 層アプローチにより、最速の API 開発およびリリース サイクルでも API が保護された状態を維持できるようになります。

OpenAPI スキーマ検証によるポジティブ セキュリティの追加

保護を API 固有にする必要がある重要な領域は、Swagger のOpenAPI 仕様の検証です。 OpenAPI スキーマは各 API に固有であり、API バージョンごとに変更されます。 API の OpenAPI スキーマに基づく保護では、IT チームが管理する集中型 WAF のセキュリティ制御を更新するのを待つことはできません。他の API やアプリへの予期しない影響を回避するには、承認と慎重なテストが必要です。

NGINX App Protect WAF は OpenAPI スキーマを検証し、リクエストが API がサポートするもの (メソッド、エンドポイント、パラメーターなど) に準拠していることを確認できます。 このため、ロードバランサーの集中型 WAF の背後にある API ゲートウェイで NGINX App Protect WAF が確実なセキュリティを提供するのが理想的です。

API の導入に遅れを取らない「コードとしてのセキュリティ」

CI/CD パイプラインはセキュリティではなく速度のために構築されています。 API も過去のアプリよりも頻繁に公開されています。 これが、API 主導の分野でシフトレフトの動きが見られる理由です。 シフトレフト、つまりアプリ開発ライフサイクルの早い段階でセキュリティ制御を適用することにより、DevOps は、セキュリティがコードとして扱われるDevSecOps文化へと移行します。

WAF を API ゲートウェイ、ロード バランサー、またはその両方に配置する場合でも、API バージョンの変更に対応するには、WAF 構成を自動的に展開する必要があります。 組織がシフトレフトの文化を採用し、「コードとしてのセキュリティ」を CI/CD パイプラインに統合すると、後から追加するのではなく、アプリケーションと API 開発の各段階にセキュリティを組み込むことができます。

セキュリティ ポリシーと構成をコードとして使用することには多くの利点があります。

• コードはソース コード リポジトリから簡単に取得できます。
• SecOps チームは、宣言型セキュリティ ポリシーを作成して維持し、ビジネスを保護するために必要な制御が確実に実施されるようにすることができます。
• 宣言型ポリシーは、新しいアプリや API に繰り返しコーディングできます。
• セキュリティは CI/CD パイプラインに自動化されます。

API スキーマを自動化する場合、API を更新するたびに、そのファイル内の構成とコードも更新する必要があります。 ここでも、自動化が鍵となります。 シフトレフトまたは「セキュリティ第一」の理念が完全に採用されると、開発者はリポジトリからそのコードを簡単に取得できるため、俊敏性が維持され、速度が向上し、市場投入までの時間が短縮されます。

API の高性能な保護

API を保護するために WAF をどこに配置しても、高パフォーマンスと低レイテンシは、API が顧客に迅速に応答してより豊かなユーザー エクスペリエンスを実現するための要件です。 NGINX App Protect WAF の軽量アーキテクチャは、クラウドでのコンピューティング需要が非常に低い状態で、高いパフォーマンスと低レイテンシを実現します。

GigaOm は、高性能アプリケーション セキュリティ テスト レポートで、NGINX App Protect WAF、AWS WAF、Azure WAF、ModSecurity Open Source WAF のパフォーマンス テストの結果を報告しています。 GigaOm は、NGINX App Protect WAF のレイテンシが NGINX 上の ModSecurity OSS WAF より 4.7 倍低く、高パフォーマンスを必要とするアプリケーションの場合 AWS WAF より 128 倍低いことを発見しました。

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

結論

NGINX では、NGINX Plus と NGINX App Protect WAF による強力な API セキュリティを提供しています。 NGINX の軽量なスケーラビリティと F5 の Advanced WAF エンジンの堅牢性により、最新のアプリが安全であることを確信して API 主導の世界に参入できます。

NGINX のコアバリューに忠実な NGINX App Protect WAF は、プラットフォームに依存せず、一般的な DevOps ツールチェーンとシームレスに統合して摩擦を排除し、安全な導入を加速する、最新のアプリケーション ソフトウェア セキュリティ ソリューションです。 宣言型構成機能を使用すると、CI/CD パイプラインおよびソフトウェア開発ライフサイクル (SDLC) 全体の一部としてセキュリティを自動化できます。 これはリリース速度の向上に役立つだけでなく、DevOps チームと SecOps チーム間のギャップを埋め、DevSecOps への文化的転換を可能にしながら、組織が信頼性が高く保護された API を構築するのにも役立ちます。

NGINX App Protect WAF を実際に試してみませんか? 今すぐ30 日間の無料トライアルを開始するか、使用事例についてご相談ください。