今日のデジタル環境において、Web アプリケーションに依存して顧客にサービスを提供し、収益を生み出す企業にとって、Web セキュリティは最も重要です。
Web アプリケーション ファイアウォール (WAF) は、Web アプリケーションを悪意のある攻撃から保護するための主要なセキュリティ ソリューションとして長い間使用されてきました。しかし、今日の進化する脅威の状況では、より包括的なアプローチが必要です。 WAF は、敵対的な HTTP リクエストの検査とフィルタリングには優れていますが、より高度な標的型攻撃に対しては効果的ではない可能性があります。完全な Web セキュリティを確保するには、WAF の機能を補完する追加の対策が必要です。
この記事では、WAF だけでなく、DDoS 保護、API セキュリティ、ボット管理など、堅牢な Web セキュリティの 4 つの柱について説明します。それぞれの長所と短所を検討し、堅牢な戦略に 4 つすべてが含まれる理由を示します。
この記事の概念を説明するために、以下を使用する組織に焦点を当てます。
重要な理由:前述したように、WAF は Web セキュリティの重要なコンポーネントであり、HTTP/HTTPS トラフィックを検査およびフィルタリングして、悪意のあるリクエストを特定してブロックするように設計されています。 WAF は、SQL インジェクションやクロスサイト スクリプティング (XSS) などの一般的な Web アプリケーション攻撃から保護する上で重要な役割を果たします。
AWS での利用可能性: Amazon はネイティブ WAF サービス (AWS WAF) を提供しています。これにより、組織はアプリケーション層のセキュリティのためのカスタム ルールとポリシーを作成できます。多くのサードパーティ WAF を使用して、AWS ワークロードの受信リクエストをフィルタリングすることもできます。これらのいくつかは、AWS 環境内でネイティブに実行することもできます。
十分ではない理由: AWS WAF は Web アプリケーションのセキュリティのための強固な基盤を提供しますが、一定の制限があります。まず、既知の攻撃パターンに主に焦点を当てているため、ゼロデイ攻撃や新たな脅威に対しては効果的ではない可能性があります。第 2 に、WAF は敵対的なリクエストに基づいて脅威を特定するように設計されていますが、多くの種類の攻撃は無害に見えるリクエストに基づいています。第三に、多くの WAF と同様に、AWS WAF ではユーザーが独自のセキュリティ ポリシーとルールセットを作成して維持する必要がありますが、これは困難な場合があります。
制限への対処:組織は、(以下で説明する他の柱に加えて) 追加のセキュリティ対策で AWS WAF を強化することを検討する必要があります。一部のサードパーティ製 WAF には、リアルタイムの脅威データとプロアクティブな防御メカニズムを提供できる脅威インテリジェンス フィードが統合されています。これにより、組織は新たな脅威の先を行き、進化する攻撃ベクトルに対する防御を強化できます。
さらに、高度な動作分析と機械学習アルゴリズムを実装すると、異常を検出し、新しい攻撃パターンを特定することで WAF 機能を強化できます。これらのテクノロジーを活用することで、組織は WAF の精度と有効性を向上させ、Web アプリケーション全体のセキュリティを強化できます。
最後に、一部のサードパーティ WAF は、フルマネージド Web アプリケーション ファイアウォール ソリューションとして利用できます。これにより、クライアント組織はベンダーが代わりにセキュリティ ポリシーを作成して維持する責任 (これには多大な時間と専門知識が必要です) から解放されます。
重要な理由: __分散型サービス拒否 (DDoS) 攻撃は、サーバーに負荷をかけ、サービスの可用性を中断する可能性があり、Web アプリケーションに重大な脅威をもたらします。 DDoS 恐喝はハッカーの間で人気のある戦術であり、通常、被害者が大量のトラフィックと収益を受け取る時間帯に (攻撃者にとって) 特に効果的です。
AWS での可用性: AWS は、AWS Shield を通じて組み込みの DDoS 保護を提供し、最も一般的かつ大規模なボリューム攻撃を防御します。
十分ではない理由: AWS Shield Standard は無料ですが、DDoS に対する完全な保護を提供しません (たとえば、レイヤー 7 攻撃に対する保護はありません)。ほとんどの組織は代わりに AWS Shield Advanced を購入する必要がありますが、高価になる可能性があります (月額 3,000 ドルの基本料金とデータ料金、および 1 年間の契約)。それでも、API の保護には問題があり、AWS Route 53 でホストされるゾーンを除き、AWS Shield はハイブリッド/マルチクラウド展開のリソースを保護しません。
最後に、AWS Shield は、直接的なボリューム攻撃を軽減することを目的としています。これは、攻撃者が消費するリソースを最小限に抑えながら、被害者に最大の経済的損害を与えることを目的としたヨーヨー DDoS 攻撃など、より高度な戦術を防御するようには設計されていません。
制限への対処: 組織は、高度な検出アルゴリズムとトラフィック分析を活用した DDoS 軽減ソリューションで AWS Shield を強化または置き換えることを検討できます。これらのソリューションはリアルタイムの監視と軽減を提供し、進化する DDoS 脅威を事前に特定して無力化できるようにします。多くの場合、低コストの構造 (特に、包括的なプラットフォームの一部として DDoS 保護を含むオールインワン ソリューション) があり、ほとんどがハイブリッドおよびマルチクラウド アーキテクチャをサポートしています。
また、上で説明したように、フルマネージド ソリューションは、人間が組織化したヨーヨー、リソース枯渇 (サーバーレスに対して使用できる戦術)、その他の戦略などの高度な攻撃を阻止するのに役立ちます。インシデントが発生したときに監視し、対応します。
重要な理由: API は、クラウド コンピューティングの人気、マイクロサービス アーキテクチャの普及、モバイル アプリケーションの数の増加など、さまざまな理由から、シームレスな統合とデータ交換にとって重要なコンポーネントとなっています。 API トラフィックが増加するにつれて、敵対的なアクティビティから API を保護することが非常に重要になってきました。
AWS での利用可能性: AWS は、AWS Identity and Access Management (IAM) や Amazon API Gateway などのサービスを提供します。 IAM を使用すると、組織は AWS リソースへのアクセスを管理できるようになり、API Gateway は認証、認可、トラフィック管理機能を提供します。
十分ではない理由: API を保護するために、AWS ユーザーは AWS WAF を API Gateway とともに使用することが期待されています。これは、AWS WAF の制限が API セキュリティにも適用されることを意味します。実際、このコンテキストで使用する場合には、実際にはさらに多くの制限があります。たとえば、特定の状況では、AWS WAF はブラウザーチャレンジと CAPTCHA を使用して受信リクエストを検証しますが、これらを API トラフィックに適用することはできません。
制限への対処: AWS ユーザーは、AWS のネイティブ セキュリティ機能を他のツールで強化できます。一部のサードパーティ セキュリティ ソリューションには、Web アプリケーション トラフィックと同等の効果で API トラフィックを保護するための広範な機能が含まれており、敵対的なリクエストをフィルタリングするだけでなく、きめ細かいアクセス制御や包括的なトラフィックの可視性とログ記録などの関連機能も備えています。一部の企業はさらに進んで、特定の状況で追加の保護の機会を活用します。たとえば、モバイル アプリケーション トラフィックに追加の強化を追加する SDK を提供します。
重要な理由: Web 上でのボットの蔓延は、組織にとって大きな課題となっています。一部のボットは正当な目的を果たしますが、他のボットはアカウント乗っ取り、コンテンツ スクレイピング、資格情報のスタッフィングなどの悪意のある活動のために導入されます。平均して、総 Web トラフィックの約 38% が敵対的なボットで構成されています。
WAF などの従来の Web セキュリティ テクノロジは、ほとんどの形式の自動トラフィックが正規のユーザーを装っているため、敵対的なボットを検出するように設計されていません。通常、個々のリクエストは無害であるように見えます (したがって、フィルタリングは回避されます)。彼らの悪意のある目的は、彼らの集団行動でのみ現れます。たとえば、在庫拒否ボットは、ショッピング活動を行う正規の顧客のように見えます。ただし、これらの「顧客」は実際には何も購入しません。代わりに、正規の顧客が在庫を利用できないようにするアクション (ショッピング カートに商品を入れる、旅行予約の最初の手順を完了するなど、トランザクションは決して完了しない) を実行します。
AWS での利用可能性: Amazon は、AWS WAF の管理されたルールセットである AWS WAF Bot Control を提供します。
不十分な理由: AWS WAF のアドオンとして、Bot Control には上記と同じ制限が含まれています。ただし、Web アプリケーションや API から敵対的なボットを排除しようとすると、これらの問題はさらに大きくなります。あらゆる形式の Web 攻撃の中で、最も複雑で高度な攻撃がボットによって行われることが多いためです。たとえば、AWS のレート制限機能の精度が低いため、クレデンシャル スタッフィングやその他の形式の ATO (アカウント乗っ取り) 攻撃を実行するボットを完全にブロックすることが困難になります。トラフィックの可視性が不完全または遅れていると、顧客が Web プロパティでのボット アクティビティを完全に理解したり、誤検知および誤検知アラームを減らすためにセキュリティ ポリシーを微調整したりすることが妨げられる可能性があります。複雑なセキュリティ ポリシーを作成して維持する必要があるため、エラーが発生する可能性が高くなります。等々。
次に、Bot Control を使用すると、追加の使用料金が発生します。 AWS WAF、AWS Shield Advanced、AWS API Gateway などのコストと組み合わせると、顧客は非常に高額な月額料金に直面する可能性があります。
最後に、AWS Bot Control の基本 (「共通」) 層は、ボット トラフィック (主にリクエストのユーザー エージェント、および IP アドレスがブラックリストに登録されているかどうか) を識別するための単純な方法に依存しています。脅威アクターは、これらの基準に基づく検出を簡単に回避できます。より効果的にボットを検出するには、顧客組織は最上位 (「ターゲット ボット」) 層を購入する必要がありますが、これにはさらに費用がかかります (ただし、最新世代の回避ボットを特定するのは依然として困難な場合があります)。
制限への対処: 一般に、敵対的なボットの軽減は、堅牢なセキュリティ体制を維持する上で最も困難な側面となる可能性があります。したがって、この記事で説明する 4 つの柱の中で、AWS のネイティブ ツールに固有の制限を克服することが最も重要な柱となります。
多くのサードパーティ Web セキュリティ ソリューションには、アマゾン ウェブ サービスのボット管理機能を超えるボット管理機能が含まれています。これは驚くべきことではありません。 AWS はクラウド リソースへのアクセスを販売するビジネスを行っており、単にそれらのリソースの使用を促進するためにセキュリティ ツールを提供しています。逆に、Web セキュリティ ベンダーは、堅牢で効果的なセキュリティ ソリューションを作成することに取り組んでいます。
ボット管理の観点から WAAP (Web アプリケーションおよび API 保護) ソリューションを評価する際の主な考慮事項は、すでに上で説明したものです。最高の
さらに、多くの組織は、社内スタッフにこの役割を実行させるのではなく、セキュリティ専門家のチームによってサイバーセキュリティ防御を構成および維持できるようにするための完全な管理オプションを必要とします。
Web アプリケーション ファイアウォールは Web セキュリティの重要なコンポーネントですが、今日の脅威の状況では、WAF だけに依存するだけではもはや十分ではありません。 Web セキュリティの 4 つの柱 (WAF、DDoS プロテクション、API セキュリティ、ボット管理) を採用することで、AWS ユーザーは幅広い脅威に対して堅牢な多層防御を確立できます。
\AWS はいくつかの組み込みセキュリティ ツールを提供していますが、その制限を理解し、特定の脅威に合わせた外部セキュリティ対策でそれらを補完することが重要です。この包括的なアプローチを採用することで、組織は AWS ウェブアプリケーションと API を効果的に保護し、最新の脅威環境におけるリスクを軽減できます。