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

Thelen Blumシニアプロダクトマーケティングマネージャー、NGINX App Protect | F5

Daphne Won

モノリスからマイクロサービスへの移行に伴い、アプリケーション開発はかつてないほど高速化しています。競争力を維持するにはスピードが不可欠であり、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はモダナイゼーションの加速に不可欠な役割を果たす一方で、悪用されやすくもなっています。マイクロサービスアーキテクチャでは、1つのAPIに数百ものエンドポイントが存在する場合があり、1つのアプリケーションが、APIを介して相互接続する多数のマイクロサービスで構成されることもあります。これは、保護すべきエントリポイントが1つしかなかった従来のモノリシックアプリとは異なります。各マイクロサービスが複数のAPIエンドポイント群を公開することで、潜在的な攻撃対象領域は10倍に拡大しています。

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

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

APIはその性質上オープンであり、機密データが露出する可能性があります。Open Web Application Security Project（OWASP）は、最も広く見られる脆弱性を「OWASP API Security Top 10プロジェクト」で取り上げています：

API1. オブジェクトレベルの認可の不備
API2. ユーザー認証の不備
API3. 過剰なデータ露出
API4. リソース不足とレート制限の不備
API5. 機能レベルの認可の不備
API6. 一括割り当て
API7. セキュリティ設定の不備
API8. インジェクション
API9. 不適切な資産管理
API10. ログ記録と監視の不足

開発サイクルが加速する中、今日の企業には俊敏性とスピードが求められています。脆弱性を抱えるAPI主導の環境では、セキュリティソリューションに適応性と軽量性が必要であり、APIの自動デプロイプロセスに組み込む必要があります。

F5 NGINX PlusでAPIセキュリティを始める

大規模なAPI攻撃は、たびたび大きく報道されています。2019年には、ライドシェア企業のUberのAPIに重大なバグが発見されました。脆弱なAPIエンドポイントにより、攻撃者が乗客の認証トークンを含む重要なデータを窃取できる状態でした。幸いにも、このバグは被害が発生する前に発見されました。2021年のLinkedInは、そうはいきませんでした。APIの脆弱性が原因で、ハッカーが7億人を超えるLinkedInユーザーのデータを侵害し、その後、ダークウェブで売りに出されました。

By F5 NGINX PlusをAPIゲートウェイとして導入することで、急速に変化するAPI環境において、APIのルーティングと配信を高いパフォーマンスで処理できます。独立系テクノロジー調査・分析会社のGigaOmは、NGINXと他のAPIゲートウェイソリューションのベンチマーク比較を実施しました。その結果、NGINXは30 ms未満のレイテンシで1秒あたり30,000件のリクエストを処理でき、ハイパースケーラーのAPIゲートウェイと比べてレイテンシが1,000分の1であることが示されました。

NGINX Plusは、OWASP APIの脆弱性に対する保護機能を標準で提供します。さらに、不正な形式のCookie、JSON、XMLのチェックに加え、許可されたファイル形式とレスポンスステータスコードの検証も行います。HTTP RFCへの準拠を確保し、攻撃を隠蔽するために使用される回避手法を検出します。

NGINX Plusは、APIリクエストを迅速にルーティングすると同時に、APIクライアントの認証と認可によってAPIを保護し、トラフィックのレート制限によってAPIベースのサービスを過負荷から保護します。これらのツールは、OWASP API Security Top Tenの脆弱性からもAPIを保護します。

• 認証および認可メカニズム – 適切なアクセス権限を持つクライアントのみがAPIを利用できるようにします。そのようなメカニズムの1つが、クレーム（JSON Web Token（JWT）内の情報）です。これにより、OWASP API Security Top 10に挙げられている複数の脆弱性に対処できます。具体的には、オブジェクトレベルの認可の不備（API1）、ユーザー認証の不備（API2）、機能レベルの認可の不備（API5）、および不十分なロギングとモニタリング（API10）です。
• レート制限ポリシー – 一定期間内にAPIゲートウェイが各APIクライアントから受け付けるリクエスト数に上限を設定することで、APIへの過剰な負荷を防ぎ、DDoS攻撃を緩和します。NGINX Plusでは、レート制限を送信元ごとに設定できるため（たとえば、JWTクレームの値に基づいて設定）、正規ユーザーへの影響を回避できます。これは、リソース不足とレート制限の欠如 （API4）の脆弱性への対処に役立ちます。

F5 NGINX App Protect WAFでAPIを強化

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

インターネットに公開する必要があるAPIや、外部の開発者およびパートナー向けのAPIをルーティングするために、NGINX Plusを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固有の保護が必要となる重要な領域の1つが、Swaggerの「OpenAPI Specification」の検証です。OpenAPIスキーマはAPIごとに固有であり、APIのバージョンごとに変わります。APIのOpenAPIスキーマに基づく保護では、ITチームが管理する一元化されたWAFのセキュリティ制御を更新するまで待つことはできません。この更新には承認が必要であり、他のAPIやアプリに予期しない影響が及ばないよう、慎重なテストも求められます。

NGINX App Protect WAFはOpenAPIスキーマを検証し、リクエストがAPIでサポートされている内容（メソッド、エンドポイント、パラメーターなど）に準拠していることを確認できます。そのため、ロードバランサー上の一元管理されたWAFの背後にあるAPIゲートウェイで、NGINX App Protect WAFによるポジティブセキュリティを実現する構成が最適です。

APIデプロイに対応する「Security as Code」

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分の1、AWS WAFと比べて128分の1でした。

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日間の無料トライアルを開始するか、ユースケースについてご相談ください。

著者について

Thelen Blumシニアプロダクトマーケティングマネージャー、NGINX App Protect | F5

Thelen Blumのその他のブログ記事

Daphne Won

Daphne Wonのその他のブログ記事