ユーザーエクスペリエンスは何よりも重要です。消費者や顧客に利用されなければ、アプリやWebサイトを提供する意味はありません。特に、レイテンシ、ダウンタイム、エラーに対するユーザーの許容度が低下する中、良好で一貫したユーザーエクスペリエンスを確保することが重要です。
ユーザーがアプリやWebサイトで不快な体験をすると、そのユーザーを顧客として永久に失う可能性があります。Salesforceの調査では、消費者の61%が、たった1度の不快な体験をきっかけに競合他社へ乗り換えたと回答しています。不快な体験が繰り返されれば、顧客離れは避けられません。オンラインに多くの選択肢がある中で、ブランドロイヤルティだけで顧客をつなぎ止めるには限界があります。
消費者の不満を招く主な原因の1つがダウンタイムであり、サービス拒否(DoS)攻撃は、ダウンタイムが長期化する大きな要因です。アプリケーション設計の変化に伴って新たな脅威ベクトルが出現し、攻撃者は20年以上にわたって使われてきたDoS攻撃を、最新のアーキテクチャを悪用できるよう変化させてきました。2020年1月から2021年3月にかけて、アプリケーション層(レイヤー7)に対するDoS攻撃が急増し、DDoSインシデント全体の16%を占めました。実際、F5 Security Incident Response Teamに寄せられる支援要請の半数は、アプリケーション層に対するDoS攻撃に関するものです。
一元化されたセキュリティ対策は、ネットワーク層(レイヤー4)における大規模なDoS攻撃に有効な場合があります。一方、アプリケーション層のDoS攻撃は標的がより限定されるため、分散化が進み、APIやマイクロサービスで構成され、クラウドなどの柔軟性の高いインフラストラクチャ上で稼働する最新のアプリケーションを保護するには、専用の防御策が必要です。
従来型の保護からの脱却
DoS攻撃の発信元が分散している場合(つまり、DDoS攻撃の場合)でも、ネットワーク層に対する基本的なボリューム型攻撃は、通常、単一のデバイスまたはサービスを標的とします。従来の保護ツールも同様に、モノリシックかつ一元化されています。こうしたツールは、現在もアプリケーションセキュリティにおいて一定の役割を果たしていますが、それだけでは十分ではありません。現在、クラウドベースのDDoS防御サービスは業界標準となっています。しかし、アプリケーションはもはやモノリシックな単一サービスではなく、保護が必要な多数の統合ポイントを持つという実情には、依然として対応できていません。
デジタルトランスフォーメーションと、それに伴うAPI、マイクロサービス、クラウドベースの統合への大規模なアーキテクチャ移行が進む以前は、基本的なWebアプリケーションファイアウォール(WAF)で、脆弱性を悪用する攻撃やDoS攻撃の大部分を緩和できました。たとえば、クライアント側で大量のトラフィックとして現れるボリューム型攻撃では、トラフィックが一元化されているため、基本的なWAFや従来のDoS対策ツールが有効です。クラウドスクラビングサービスでトラフィックがイングレス回線に流入する前に攻撃を緩和することも、アプリケーションスタックの前段に保護機能を配置することもできます。基本的なWAFは現在も、主にレート制限、拒否リスト、ボットシグネチャを通じて従来型の攻撃から保護しますが、脅威の状況はすでにその範囲を超えて変化しています。
つまり、状況は一変しており、基本的なWAFや従来型のDoS対策は、最新のアプリケーションアーキテクチャには有効ではありません。
最新のDoS攻撃はレイヤー7で発生しており、暗号化されたチャネルに潜み、アプリケーションロジックを標的とするため、検知がはるかに困難です。そのため、DoS攻撃を示す2つの最大の指標であるクライアントの挙動とサーバーの負荷を測定するには、保護レイヤーを追加する必要があります。
この問題への対応を支援するため、F5は先ごろ、NGINX App Protect Denial of Serviceモジュールをリリースしました。すでにWAFと従来型のDoS対策を導入している場合、DoSモジュールが必要なのか疑問に思われるかもしれません。しかし、実際には必要です。その理由を以下で説明します。
モダンアーキテクチャにはモダンな保護が必要
暗号化が広く普及する一方、従来のDoS対策は大規模な復号を想定して設計されていません。モノリシックアプリケーションの時代には、暗号化がそれほど普及しておらず、クライアント側だけを確認すれば攻撃の大半を検知できたため、DoS対策を一元化することには合理性がありました。現在では、ほぼすべてのトラフィックが暗号化されています。そのため、受信トラフィックのみに着目するステートレスなDoS対策は、ほとんど効果がありません。特に、標的を絞った1件のリクエストだけでアプリケーションに負荷をかける攻撃には効果が限定的です。
現在、アプリケーションはマイクロサービスなどの分散アーキテクチャ向けに設計、最適化されています。また、ユーザープライバシーの重視(およびそれに伴う法制化)と暗号技術の進歩により、エンドツーエンド暗号化が一般的になりつつあります。最新のアーキテクチャはAPIに大きく依存しており、API間の通信(「East-Westトラフィック」とも呼ばれます)は、一元化されたセキュリティ制御を経由しない場合もあります。
効果的なアプリケーションレベルのDoS対策には、クライアント側の異常やサーバー側の負荷を検知する機能を含め、エンドツーエンドの可視性とコンテキストが必要です。高度なレイヤー7 DoS攻撃は正規のトラフィックを装うことが多いため、レート制限、拒否リスト、シグネチャ、プロトコル準拠といった基本的な緩和策だけでは、もはや十分ではありません。
高度なLayer 7攻撃は一見すると正規のトラフィックに見えるため、基本的なWAFでは、検知に必要な振る舞い分析を行えません。NGINX App Protect DoSは、クライアント側の異常とサーバー側の負荷の両方を監視するように設計されており、すでに多忙を極めるセキュリティチームの対応を必要とせずに、攻撃を動的に特定して緩和し、緩和の有効性を測定できます。
基本的なWAF防御と従来のDDoS緩和策だけに依存していると、Layer 7攻撃を適切に可視化し、その背景を把握することができません。その結果、遅延やダウンタイム、収益機会の喪失、ブランドイメージの低下など、甚大な影響が生じる可能性があります。振る舞い分析を使用すれば、クライアントの異常とサービスの健全性を継続的に分析し、ゼロデイDoS攻撃を検知できます。サイトの振る舞いを詳細に調べることで、次のような点を確認できます。ベースラインのトラフィックパターンと比べて異常はないか。ブラウザから送信されたように見えるリクエストに、通常ブラウザに含まれるはずの情報が欠けていないか。CPU使用率の上昇を引き起こす複雑なデータベースクエリがリクエストに含まれていないか。
通常時のパフォーマンスと動作を把握することで、NGINX App Protect DoSは、従来の防御を回避してアプリケーションに負荷をかけるレイヤー7攻撃に重点的に対処できます。

複数のモジュールで攻撃を緩和
DoS攻撃がもたらす結果は変わっていません。パフォーマンスの低下、ユーザーの不満、収益機会の喪失です。しかし、DoS攻撃の手法は大きく異なる場合があります。ハッカーは暗号化やセキュリティツールを利用し、脅威を正規のトラフィックに偽装します。
ユーザーにはアーキテクチャの違いを見分けられなくても、サイトのパフォーマンスが良いか悪いかはわかります。大量の攻撃トラフィックによって遅延が発生すると、ユーザーエクスペリエンスが低下します。あまりに遅ければ、辛抱強いユーザーでさえ(そう多くはいません!)取引を中断し、別のサイトへ移ってしまいます。標的を絞った1件のリクエストだけでも、遅延やサーバーへの負荷が発生する可能性があるため、アプリケーションに特化したDoS対策が不可欠です。
Webアプリケーションセキュリティソリューションは、OWASP Automated Threats to Web Applicationsで概説されているような新たな攻撃に対応するため、進化を続けています。しかし、必要なのは、アプリケーションランタイムにネイティブに統合される保護です。動的で、適応性に優れた保護が求められます。他のDoSソリューションが、SYNフラッドなどのネットワークDDoS攻撃向けに設計されている場合がある一方、NGINX App Protect DoSソリューションは、アプリケーションリソースに負荷をかけるレイヤー7攻撃に特化しています。WAFとレイヤー7 DoSソリューションを組み合わせることで、脆弱性の悪用とビジネスロジックの不正利用の両方からアプリケーションを保護し、侵害だけでなく、遅延、性能低下、ダウンタイムも防止できます。
現在、商取引の大半はオンラインで行われ、人々も多くの時間をオンラインで過ごしています。そのため、オンラインを安心して利用できる安全な環境にする必要があります。NGINX App Protect WAFとNGINX App Protect DoSの各モジュールを組み合わせることで、環境、アプリケーション、ビジネスに適した堅牢な保護を実現できます。
NGINX App Protectをぜひお試しください。今すぐ30日間の無料トライアルを開始するか、ユースケースについてお問い合わせください。
著者について
関連するブログ記事
チュートリアル:NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。
AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。
JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。
F5 NGINXaaS for Azureのご紹介:Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト&シフトできるため、クラウド導入とモダンアプリの展開を加速できます。

SELinuxでNGINXおよびNGINX Plusを使用する
Red Hat Enterprise Linux(RHEL)および関連ディストリビューションでSecurity-Enhanced Linux(SELinux)を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。
NGINX PlusによるAWS Auto Scalingグループの負荷分散
新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります