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

自動化と人工知能（AI）によるセキュリティ態勢の強化に投じた費用が、結果としてそれを大きく上回るコスト削減につながると聞けば、驚かれるかもしれません。IBM Securityチームは、2021年データ侵害のコストに関する調査レポートの中で、セキュリティの自動化とAIを導入していない組織では、全面的に導入している組織と比べて、セキュリティ侵害に伴うコストが平均で実に80%も高いことを明らかにしています。前者が671万ドル、後者が290万ドルで、その差は381万ドルです。セキュリティの自動化とAIを優先することで、組織は侵害をより迅速に特定して封じ込め、コストと時間の両方を削減できます。

セキュリティの自動化とAIを導入していない組織では、データ侵害によるコストが数百万ドルも増加
（出典：Cost of a Data Breach 2021 Report）

ただし、CI/CDパイプラインにセキュリティを組み込む際は、ツールに過剰な負荷をかけないことが重要です。トラフィックを検査する回数を減らすほど、発生するレイテンシーも低減します。ビジネスの観点では、技術的な複雑さがアジリティを損なう要因になるということです。

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

詳しく掘り下げて、F5 NGINX App ProtectとF5 NGINX Plusがセキュリティ保護の自動化を支援するトラフィック処理の3つのフェーズを見ていきましょう。

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

不正なトラフィックをブロックし、セキュリティを自動化することで、時間とコストを削減しながらアプリケーショントラフィックを効率的に管理する3段階のセキュリティソリューション

この3つの要素で構成されるセキュリティソリューションは、特にパブリッククラウド環境において、次の2つの方法でコスト削減に貢献します。

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

現在、データセンターで稼働するアプリのセキュリティ確保にF5 BIG-IP Advanced WAFを使用している場合、NGINX PlusをKubernetesのIngressコントローラーとして追加し、NGINX App Protect DoSおよびWAFと組み合わせることで、最新のアプリケーションの拡張とセキュリティ確保、クラウド上のKubernetesアプリのオーケストレーションに対応する包括的なソリューションを容易に構築できます。F5のSecurity as Codeアプローチでは、宣言型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）攻撃を排除することです。こうした不正行為を初期段階で阻止することが、必要不可欠な最初の防御線となります。

以前にも指摘したように、攻撃者は従来のボリューム型攻撃から次第に移行し、HTTPおよびHTTPSリクエストやAPI呼び出しを利用してレイヤー7を攻撃するようになっています。なぜでしょうか。最も抵抗の少ない経路を選んでいるためです。インフラストラクチャエンジニアは長年にわたり、レイヤー3およびレイヤー4の攻撃に対する効果的な防御策を構築してきました。そのため、これらの攻撃はブロックしやすく、成功する可能性も低くなっています。一方、レイヤー7攻撃は、こうした従来の防御策を回避できる場合があります。

すべてのDoS攻撃がボリューム型とは限りません。Slow POSTやSlowlorisのような「Low and Slow」手法でサーバーリソースを消費するよう設計された攻撃は、正規のトラフィックに容易に紛れ込む可能性があります。また、gRPCのようなオープンソースのHTTP/2リモートプロシージャコールフレームワークは、最新のアプリに必要な速度と柔軟性を提供する一方、そのオープンな性質により、プロプライエタリプロトコルよりもDoS攻撃に対して脆弱になる可能性があります。

従来のDoS対策とは異なり、NGINX App Protect DoSは、ユーザーとサイトの挙動の自動分析、プロアクティブなヘルスチェック、設定不要の構成を活用して、今日の攻撃を検知します。また、HTTP 一般的な攻撃を阻止する低レイテンシのソリューションです。対象となる攻撃には、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 Securityレポートが大幅なコスト削減の鍵として挙げている機械学習（ML）テクノロジーが統合されています。クライアントの挙動とアプリケーションの健全性を分析して通常のトラフィックパターンをモデル化し、独自のアルゴリズムを使用して極めて精度の高い保護を実現する動的な統計モデルを作成するとともに、動的シグネチャを導入して攻撃を自動的に緩和します。また、緩和の有効性を継続的に測定し、挙動や健全性の変化に適応します。これらの機能により、個々の攻撃リクエストが完全に正当なものに見え、単一の攻撃者が生成するトラフィック量が正規ユーザーの平均を下回る場合でも、NGINX App Protect DoSはDoS攻撃をブロックできます。

セキュリティソリューションのフェーズ1とフェーズ2：NGINX App Protect DoSとWAFによる効率的なトラフィック処理を活用したアプリケーションセキュリティ

フェーズ2：NGINX App Protect WAFでOWASP Top 10に対する保護を実現

DoS対策によって悪意のあるトラフィックがインフラストラクチャに侵入するのを阻止できても、攻撃がすり抜ける可能性は残ります。そのため、次の防御フェーズではWebアプリケーションファイアウォール（WAF）が必要です。WAFは、正規のトラフィックを装った悪意のある攻撃者からのトラフィックに重点的に対処します。

軽量かつ高性能なNGINX App Protect WAFは、レスポンスの検査、HTTPプロトコルへの準拠の適用、回避手法の検出、Data Guardによるクレジットカード番号などの機密性の高い個人情報のマスキングに加え、許可されていないメタ文字やファイル形式、不正な形式のJSONおよびXML、機密性の高いパラメーターのチェックを行い、包括的なセキュリティ保護を提供します。また、更新されたOWASP Top 10に対する保護も提供します。

アクセス制御の不備
暗号化の失敗
インジェクション
安全が確認されない設計
セキュリティの設定ミス
脆弱で古くなったコンポーネント
識別と認証の失敗
ソフトウェアとデータの整合性の不具合
セキュリティログとモニタリングの失敗
サーバーサイドリクエストフォージェリ

「A03:2021 インジェクション」など、OWASP Top 10の脆弱性を狙うサイバー攻撃が依然として多いのは、驚くことではありません。2021年7月、オープンソースのeコマースサイトであるWooCommerceは、多くのプラグインに脆弱性があると発表しました。その脆弱性はSQLインジェクションに関するもので、当時、複数の攻撃が発生していました。企業と顧客の活動が主にオンラインで行われるなか、攻撃者がWebベースのアプリに狙いを定めるのは当然といえます。こうしたアプリは複雑であることが多く、マイクロサービスで構成され、多数のAPIが相互に通信する分散環境にまたがるため、悪用される可能性のあるエンドポイントが増加します。

最新の攻撃も急速に変化し、適応します。ここでAIが力を発揮します。IBMがAIの重要性を指摘したのもこのためです。NGINX App Protect DoSと同様に、NGINX App Protect WAFの高度なMLシステムにより、Platform Ops、DevOps、SecOpsの各チームは攻撃の傾向やデータを容易に共有できます。新機能の「Adaptive Violation Rating」では、アプリケーションの動作の変化を検出することで、MLをさらに活用します。このML機能により、NGINX App Protect WAFは各アプリケーションの予測動作を継続的に評価します。この学習に基づき、本来ならブロックされるクライアントリクエストを許可できるため、アプリケーションの違反評価スコアが下がり、誤検知が大幅に減少します。その結果、管理コストを抑えながら、ユーザーエクスペリエンスを向上できます。

NGINX App Protect WAFは、ボット対策機能も提供します。現在、インターネットトラフィックの約50%はボットによるものです。既知の悪意あるトラフィックを事前に排除することで、NGINX App Protect WAFはBot Signatureデータベースを使用してボットトラフィックを迅速にブロックできます。

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に一貫した単一のエントリーポイントを提供し、スタックをさらに簡素化できます。

シングルサインオン（SSO）を使用して認証と認可を自動化することもできるため、DevOpsチームは必要なアジリティを維持できます。NGINX Plusは、OpenID Connect（OIDC）をサポートしています。これは、OAuth 2.0プロトコル上に構築されたアイデンティティレイヤーです。NGINXのドキュメントでは、OIDCを使用して、NGINX PlusでプロキシされるアプリケーションのSSOを有効にする方法を説明しています。

セキュリティソリューション フェーズ3：NGINX PlusとOAuth 2.0/OIDC IdP準拠のSSOサンプルを使用した認証と認可

APIはその特性上オープンであるため、攻撃を受けやすい標的です。年次レポートで、Gartner Researchは予測しました2022年にはAPIが最も一般的な攻撃ベクトルとなり、企業のWebアプリで無数のデータ侵害を引き起こすと。その予測どおり、2022年を迎え、組織全体でAPIの攻撃対象領域が拡大し続けています。

F5 Labsの「API認証インシデント：2020年アプリケーション保護レポート」では、APIインシデントが発生する一般的な理由として、次の3つを挙げています。

1. APIエンドポイントで認証が行われていない
2. 不適切なAPI認証
3. 不適切なAPI認可

APIエンドポイントで認証が行われない

APIトラフィックの認証を実装すると、本人確認に成功したクライアントは、信頼できるアイデンティティプロバイダーからトークンを受け取ります。クライアントは、HTTPリクエストのたびにアクセストークンを提示します。NGINX Plusは、リクエストをアプリケーションに渡す前に、トークンを検証し、トークンにエンコードされたIDやその他のデータ（グループメンバーシップなど）を抽出することで、クライアントの認証と認可を行います。トークンが検証され、クライアントにリソースへのアクセスが許可されている場合、リクエストはアプリケーションサーバーに渡されます。この検証を行う方法はいくつかありますが、OAuth 2.0プロトコルを基盤とするOpenID Connectは、APIリクエストのサードパーティ認証を可能にする一般的な方法です。

しかし、市場にある多くのAPIは、認証レイヤーで保護されていません。2021年、インタラクティブフィットネスプラットフォームのPelotonのAPIに情報漏えいにつながる不備があることが明らかになりました。あるセキュリティ研究者は、PelotonのAPIに認証なしでリクエストを送信し、ユーザーデータを容易に取得できることを発見しました。Pelotonは大規模な侵害が発生する前にコードを修正しましたが、この問題は、画一的なセキュリティアプローチではAPI構造が本質的に多様であることを考慮できず、その防御には機敏な対応が必要であることを浮き彫りにしています。

API認証の不備

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

API認証トークンを適切に検証しないと、攻撃者にAPIの脆弱性を悪用される可能性があります。この種の脆弱性を研究者ではなく悪意のある人物が発見した場合、事業全体が侵害されるおそれがあります。

API認可の不備

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

NGINXは、APIの保護とAPIクライアントの認証に複数の方法を提供しています。詳細については、IPアドレスベースのアクセス制御リスト（ACL）、デジタル証明書認証、およびHTTP Basic認証のドキュメントをご覧ください。また、NGINX Plusは、API認証用のJSON Web Token（JWT）の検証をネイティブにサポートしています。詳しくは、ブログ記事「JWTとNGINX PlusによるAPIクライアントの認証」をご覧ください。

今すぐ始める

セキュリティを自動化することで、誰もがその責任を担うようになります。セキュリティ自動化を優先することで、組織はより信頼性の高いアプリを構築し、リスクと運用コストを削減するとともに、リリースを迅速化できます。これにより、マイクロサービス、アプリ、APIに、拡張性に優れ、今日の競争に対応できる俊敏で高速なセキュリティを実現できます。

この3段階のセキュリティ構造は、最適な処理フローも実現します。DoS攻撃によるトラフィックの検査でWAFに過剰な負荷をかけたり、悪意のある攻撃者の認証や認可を試みて貴重なリソースを浪費したりすることを避けられるためです。容易に特定できる攻撃を早期に排除することで、時間とコストを節約し、アプリのパフォーマンスを向上できます。

NGINX PlusとNGINX App Protectを実際にお試しになりませんか？今すぐ30日間の無料トライアルを開始するか、ユースケースについてご相談ください。

---