F5 NGINX App ProtectとF5 NGINX Plusでセキュリティを自動化し、侵害コストを削減

自動化と人工知能 (AI) によるセキュリティ体制の改善に費やすお金が、最終的にははるかに大きな金額の節約につながると知ると、驚かれるかもしれません。 IBMセキュリティー・チームは、 「2021年データ漏えいのコストに関するレポート」の中で、セキュリティー自動化とAIを導入していない組織では、セキュリティー侵害によるコストが自動化とAIを完全に導入している組織よりも平均で80%も高く、671万ドル対290万ドルで、その差は381万ドルにも上ると明らかにしました。 セキュリティの自動化と AI を優先することで、組織は侵害をより迅速に特定して封じ込めることができ、コストと時間の両方を節約できます。

ただし、CI/CD パイプラインにセキュリティを統合する場合は、ツールに過負荷をかけないようにすることが重要です。 トラフィックを検査する回数が少ないほど、発生する遅延が少なくなります。 ビジネス上の必然的な帰結は、技術的な複雑さが俊敏性の敵であるということです。

F5 NGINX では、シームレスな統合と、ソフトウェア開発ライフサイクル中にチームが「セキュリティをシフトレフト」できるようにする機能を備えた独自のセキュリティ プラットフォームを提供しています。 組織が「コードとしてのセキュリティ」を CI/CD パイプラインに統合すると、セキュリティの自動化と AI が有効になり、IBM が説明したように大幅なコスト削減につながります。 アプリケーションと API 開発の各段階にセキュリティが組み込まれているため、構成ファイルとセキュリティ ポリシー ファイルはコードとして使用され、SecOps チームは、アプリの構築時に DevOps が使用する宣言型セキュリティ ポリシーを作成して維持できます。 これらの同じポリシーを新しいアプリに繰り返し適用できるため、CI/CD パイプラインへのセキュリティが自動化されます。

では、トラフィック処理の 3 つのフェーズを詳しく見ていきましょう。F5 NGINX App Protect と F5 NGINX Plus は、セキュリティ保護の自動化に役立ちます。

• フェーズ1 – F5 NGINX App Protect DoSはサービス拒否（DoS）攻撃を検出し防御します
• フェーズ2 – F5 NGINX App Protect WAFはOWASPトップ10攻撃と悪意のあるボットから保護します
• フェーズ3 – F5 NGINX Plusは、ネイティブ機能とサードパーティのシングルサインオン（SSO）ソリューションとの統合を使用して、アプリとAPIクライアントを認証し、承認要件を適用します。

この 3 部構成のセキュリティ ソリューションは、特にパブリック クラウド環境において、次の 2 つの方法でコストを節約します。

1. NGINX App Protect DoS が DoS 攻撃からのトラフィックをフィルタリングし、NGINX App Protect WAF がOWASP Top 10などの複数の攻撃ベクトルを排除するため、正当なトラフィックだけがアプリに到達します。
2. NGINX Plus の非常に効率的なイベント駆動型設計により、CPU 消費量を抑えながら 1 秒あたり膨大な数のリクエストを処理できます。 非常に効率的なプラットフォームで正当なアプリケーション トラフィックのみを処理すると、必要なコンピューティング リソースが大幅に削減され、時間とコストが節約され、ツールに負担をかけずに複数の攻撃ベクトルに対する保護が確保されます。

現在、データセンターで実行されているアプリケーションを保護するためにF5 BIG-IP Advanced WAF を使用している場合は、NGINX App Protect Dos と WAF を使用して、Kubernetes の Ingress コントローラーとして NGINX Plus を簡単に追加し、最新のアプリケーションを拡張および保護し、クラウドで Kubernetes アプリケーションをオーケストレーションする包括的なソリューションとして使用できます。 F5 のセキュリティ アズ コードアプローチを使用すると、宣言型 API またはファイル内の宣言型 JSON 形式の定義を介してインフラストラクチャとセキュリティ ポリシー制御をコードとして定義でき、BIG-IP XML ファイルを JSON ファイルに変換することもできます。 ポリシー (SecOps が所有および管理する標準的な企業セキュリティ制御) は、コード リポジトリに保存することができ、そこから取得して、他のコードと同様に開発パイプラインに統合できます。 このアプローチにより、DevOps と SecOps は運用上のギャップを埋め、コストを削減し、セキュリティを強化しながら、より早くアプリを市場に投入できるようになります。

F5 は、WAF ポリシーの構築とベースライン設定を開発プロセスに組み込んでいます。これは、アプリケーション開発パイプラインにおける「セキュリティのシフトレフト」とアプリケーション展開の自動化の重要な部分です。

BIG‑IP と NGINX の可視性ツールは相互に補完し、SecOps が自動化プロセスを DevOps ライフサイクルの早い段階に組み込むことを可能にします。 BIG‑IP を使用すると、チームは XML ファイルを NGINX で使用される JSON ファイルに変換して、一貫したセキュリティ ポリシーを維持できます。 NGINX を使用すると、チームは既存のアプリを微調整できると同時に、最新のアプリ セキュリティ自動化を導入して、将来の侵害や潜在的な攻撃のコストを相殺できます。

フェーズ1: NGINX App Protect DoS は DoS 攻撃から防御します

安全なトラフィック管理の取り組みの最初の目的は、サービス拒否 (DoS)攻撃を排除することです。 こうした虐待を最初から阻止することが、必要な第一防衛線です。

攻撃者が従来のボリューム型攻撃から、レイヤー 7 での攻撃に HTTP および HTTPS リクエストや API 呼び出しを使用する攻撃に切り替えていることは、以前にも指摘しました。 なぜ？ 彼らは最も抵抗の少ない道を歩んでいる。 インフラストラクチャ エンジニアは、レイヤー 3 およびレイヤー 4 の攻撃に対する効果的な防御を構築するために何年も費やしており、攻撃をブロックしやすくし、攻撃が成功する可能性を低くしています。 レイヤー 7 攻撃はこれらの従来の防御を回避することができます。

すべての DoS 攻撃がボリューム型であるわけではありません。 Slow POSTや Slowloris などの「低速で低速な」方法でサーバー リソースを消費するように設計された攻撃は、正当なトラフィック内に簡単に隠れることができます。 gRPCのようなオープンソースの HTTP/2 リモート プロシージャ コール フレームワークは、最新のアプリに必要な速度と柔軟性を提供しますが、そのオープンな性質により、独自のプロトコルよりも DoS 攻撃に対して脆弱になる可能性があります。

従来の DoS 保護とは異なり、 NGINX App Protect DoS は、自動化されたユーザーおよびサイトの動作分析、プロアクティブなヘルス チェック、ノータッチ構成を活用して、今日の攻撃を検出します。 これは、HTTP GETフラッド、HTTP POSTフラッド、Slowloris、Slow read、Slow POSTなどの一般的な攻撃を阻止する低遅延ソリューションです。

これらの攻撃に対抗するには、SecOps チームと DevOps チームが「セキュリティ アズ コード」の自動化を CI/CD ワークフローに統合する必要があります。これはシフトレフトの考え方の一部です。 NGINX App Protect DoS によりこれが可能になります。 DoS 脅威に対する高度な保護機能により、最新の分散型アプリと API を保護します。また、軽量ソフトウェア パッケージ、継続的な脅威緩和フィードバック ループ、RESTful API を介した使い慣れた DevOps ツールとの統合によってこのモデルを容易にし、SecOps と DevOps の優先順位が衝突することもある状況を調整します。

NGINX App Protect DoS には、 IBM セキュリティ レポートで大幅なコスト削減の鍵として強調されている機械学習 (ML) テクノロジーが統合されています。 クライアントの動作とアプリケーションの健全性を分析して通常のトラフィック パターンをモデル化し、独自のアルゴリズムを使用して最も正確な保護を提供する動的な統計モデルを作成し、動的なシグネチャを展開して攻撃を自動的に軽減します。 また、緩和効果を継続的に測定し、変化する行動や健康状態に適応します。 これらの機能により、NGINX App Protect DoS は、各攻撃リクエストが完全に合法的に見える DoS 攻撃をブロックでき、1 人の攻撃者が生成するトラフィックが、平均的な正当なユーザーよりも少なくなる可能性もあります。

フェーズ2: NGINX App Protect WAFはOWASPトップ10から保護します

DoS 保護により悪意のあるトラフィックがインフラストラクチャに侵入するのを確実に阻止できますが、攻撃は依然として侵入する可能性があります。 そのため、防御を成功させるための次の段階では、正当なトラフィックを装った悪意のあるユーザーからのトラフィックに焦点を当てた Web アプリケーション ファイアウォール (WAF) が必要になります。

軽量で高性能なNGINX App Protect WAF は、応答を検査し、HTTP プロトコルのコンプライアンスを強制し、回避手法を検出し、Data Guard を使用してクレジットカード番号やその他の機密個人情報をマスクし、許可されていないメタ文字やファイル タイプ、不正な形式の JSON や XML、機密パラメータをチェックする包括的なセキュリティ保護を提供します。 また、更新されたOWASP Top 10からも保護します。

アクセス制御の不備
暗号化の失敗
注射
安全でない設計
セキュリティの誤った設定
脆弱で古いコンポーネント
識別と認証の失敗
ソフトウェアとデータの整合性の障害
セキュリティログと監視の失敗
サーバーサイドリクエストフォージェリ

A03:2021 インジェクションなどのOWASP Top 10 の脆弱性に対するサイバー攻撃が依然として人気があるのは驚くことではありません。 2021年7月、オープンソースの電子商取引サイトWooCommerceは、多くのプラグインがSQLインジェクションに対して脆弱であり、その時点で複数の攻撃が発生していることを発表しました。 企業や顧客が主にオンラインで業務を行っていることから、攻撃者が Web ベースのアプリに重点を置くのは当然のことです。Web ベースのアプリは複雑で、マイクロサービスで構成され、多くの API が相互に通信する分散環境にまたがり、悪用に対して脆弱なエンドポイントの数が増加します。

現代の攻撃も急速に変化し、適応します。 ここで AI が登場し、IBM がその重要性に注目した理由がここにあります。 NGINX App Protect DoS と同様に、NGINX App Protect WAF の豊富な ML システムにより、Platform Ops、DevOps、SecOps の各チームが攻撃の傾向とデータを簡単に共有できるようになります。 新しい機能の 1 つであるAdaptive Violation Rating機能は、アプリケーションの動作がいつ変化したかを検出することで、ML をさらに活用します。 この ML 機能により、NGINX App Protect WAF は各アプリケーションの予測動作を継続的に評価します。 この学習に基づいて、通常はブロックされるクライアント要求を有効にし、アプリの違反評価スコアを下げて誤検知を大幅に削減し、管理コストを抑えながらユーザー エクスペリエンスを向上させることができます。

NGINX App Protect WAF はボット保護も提供します。 現在、インターネット トラフィックの約 50% はボットから発生しています。 NGINX App Protect WAF は、既知の悪意のあるトラフィックを事前に排除することで、ボット署名データベースを使用してボット トラフィックを迅速にブロックできます。

CI/CD パイプラインの早い段階で WAF をセキュリティ レイヤーとして導入すると、セキュリティ リスクを軽減できます。 NGINX App Protect WAF は CI/CD に対応しているため、アプリケーション開発プロセスの早い段階でセキュリティをコードとして組み込み、自動化することができます。 早期のセキュリティ認識とチーム間の適切な連携により、配信リスクなどのボトルネックも排除されます。 多段階の DoS および WAF 保護により、多くの検査ポイントが作成され、セキュリティ チームはアプリの使用状況を可視化し、アプリ チームはアプリがどのように保守されているかを把握できるようになります。

フェーズ3: NGINX PlusはアプリとAPIクライアントを認証および承認します

NGINX App Protect Dos と NGINX App Protect WAF が悪意のあるトラフィックを排除した後でも、クライアントが正当であり、要求しているリソースにアクセスする権限があることを確認する必要があります。 ここでNGINX Plusが登場し、認証と承認を処理して、リクエストを適切なサーバーにルーティングします。 NGINX Plus を API ゲートウェイとして導入することで、複数の API に対して一貫した 1 つのエントリ ポイントを提供でき、スタックを簡素化できます。

認証と承認はシングル サインオン (SSO) によって自動化できるため、DevOps チームは必要な俊敏性を維持できます。 NGINX Plus は、 OAuth 2.0プロトコル上の ID レイヤーであるOpenID Connect (OIDC) をサポートしています。 NGINX ドキュメントでは、 OIDC を使用して、NGINX Plus によってプロキシされるアプリケーションに対して SSO を有効にする方法について説明しています。

API はオープンな性質を持っているため、脆弱なターゲットとなります。 ガートナー リサーチは年次レポートで、2022 年には API が最も一般的な攻撃ベクトルとなり、エンタープライズ Web アプリで数え切れないほどのデータ侵害が発生すると予測しました。 2022 年に入り、組織全体で API 攻撃対象領域が拡大し続けるのを見ると、この予測は真実であることがわかります。

API 認証インシデント: 2020 アプリケーション保護レポート F5 Labs の調査では、API インシデントの一般的な原因として次の 3 つが挙げられています。

1. APIエンドポイントでの認証なし
2. 壊れた API 認証
3. 壊れた API 認証

APIエンドポイントでの認証なし

API トラフィックの認証を実装すると、ID を正常に証明したクライアントは、信頼できる ID プロバイダーからトークンを受け取ります。 その後、クライアントは各 HTTP リクエストでアクセス トークンを提示します。 リクエストがアプリケーションに渡される前に、NGINX Plus はトークンを検証し、トークンにエンコードされた ID やその他のデータ (グループ メンバーシップなど) を抽出することで、クライアントの認証と承認を確実に行います。 トークンが検証され、クライアントがリソースにアクセスする権限を持っていると仮定すると、要求はアプリケーション サーバーに渡されます。 この検証を実行する方法はいくつかありますが、OpenID Connect (OAuth 2.0 プロトコル上に構築) は、API リクエストのサードパーティ認証を有効にする一般的な方法です。

ただし、市場に出回っている多くの API は認証層で保護されていません。 2021年、インタラクティブフィットネスプラットフォーム「ペロトン」のAPIに漏洩があることが明らかになった。セキュリティ研究者は、ペロトンのAPIに認証されていないリクエストを送信して、認証なしで簡単にユーザーデータを取得できることを発見した。 Peloton は重大な侵害が発生する前にコードを修正しましたが、この事故は、セキュリティに対するモノリシックなアプローチが API 構造の固有の多様性と、その結果生じる防御の俊敏性の必要性を考慮していないことを浮き彫りにしています。

壊れた API 認証

API はコンピューター同士を接続するために設計されているため、多くの DevOps チームは人間が API エンドポイントと通信しないと想定しています。 F5 Labs のレポートにある例の 1 つは、複数の API リクエストを連鎖させて、モバイル アプリで数十万ドル相当のクレジットを「獲得」した研究者に関するものです。このアプリは、不正使用を防ぐように設計されたトークンを継続的に生成していましたが、トークンに有効期限が設定されていなかったため、トークンは繰り返し使用できました。

API 認証トークンを適切に検証しないと、攻撃者が API の脆弱性を悪用する可能性があります。 この種の脆弱性が研究者ではなく悪意のある人物によって発見された場合、ビジネス全体が危険にさらされる可能性があります。

壊れた API 認証

API 認証が失敗すると、当然ながら API 認可が壊れてしまいます。 F5 Labs のレポートでは、オペレーティング システムのバグによって API への悪意のある HTTP リクエストが許可され、悪意のある人物が認証トークンに簡単にアクセスできるというインシデントについても説明されています。 攻撃者がこの認証トークンを取得すると、管理者権限を取得しました。

NGINX は、API を保護し、API クライアントを認証するためのいくつかのアプローチを提供します。 詳細については、 IP アドレスベースのアクセス制御リスト(ACL)、デジタル証明書認証、およびHTTP 基本認証のドキュメントを参照してください。 さらに、NGINX Plus は、API 認証用の JSON Web Token (JWT) の検証をネイティブにサポートします。 詳細については、弊社のブログの「JWT と NGINX Plus を使用した API クライアントの認証」をご覧ください。

今すぐ始めましょう

セキュリティを自動化すると、全員の責任になります。 セキュリティの自動化を優先することで、組織はより信頼性の高いアプリを構築し、リスクを軽減し、運用コストを削減し、リリース速度を加速できます。 つまり、マイクロサービス、アプリ、API は、今日の競争に追いつくのに十分なスケーラビリティと速度を備えた俊敏なセキュリティを実現できます。

この 3 段階のセキュリティ構造は、DoS 攻撃からのトラフィックを検査する WAF の動作を妨げたり、悪意のある行為者の認証と承認を試みて貴重なリソースを無駄にしたりすることがないため、最適なフローを実現します。 簡単に識別できる攻撃を早期に排除することで、時間とコストを節約し、アプリのパフォーマンスを向上できます。

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