驚くほど多くのアプリケーションが、何の保護も受けずにクラウドに存在しています。 Web アプリ ファイアウォールはありません。 アイデンティティやアクセス制御はありません。 何もない。 彼らはただそこにいて、攻撃を受けやすいのです。
これは企業にとっては悪夢であり、攻撃者にとっては夢の実現です。
また、ターゲットとなるアプリケーションへの注目が高まっていることを考えると、これは賢明ではありません。 豊富なデータソースへのパスを見つけるためであろうと、アプリを他の不正な目的の配布ポイントとして利用するためであろうと、アプリケーション攻撃は増加しています。
実際、上位の侵害を調査すると、30% が Web アプリケーションへの攻撃に関連していることがわかります。 脆弱性を悪用するハッキングが 62% を占めました。 そして驚くべきことに、77% は個人ではなくボットネットによって実行されました。
つまり、単なる統計データに過ぎないように、アプリをボットや脆弱性から保護する必要があるということです。
ここで言うアプリとは、すべてのアプリのことです。 セキュリティに関しては、クラウド内のアプリであっても、すべてのアプリが重要なアプリです。 おそらく、ネットワーク ファイアウォールによって提供される基本的な保護さえもなしにアプリが展開される可能性があるクラウドでは、さらにその傾向が強まるでしょう。
しかし、特にセキュリティ ソリューションの複雑さが、クラウド内のアプリケーションの保護を妨げる場合があることを無視することはできません (無視すべきではありません)。 2018 年のアプリケーション配信の現状に関する調査では、回答者の 3 分の 1 強 (34%) が「セキュリティ ソリューションの複雑性の増大」が今後 1 年間の最大のセキュリティ課題であると回答しました。
セキュリティは難しい場合があります。 しかし、特にクラウドではそうである必要はありません。
ご存知ない方のために説明すると、AWS は、ユーザーがアプリをデプロイできるだけでなく、ベンダーが機能を追加できる非常に優れたプラットフォームを提供しています。 セキュリティ分野では、ネイティブWeb アプリケーション ファイアウォールがサードパーティの管理ルールを提供して機能を拡張します。 つまり、Web アプリケーション ファイアウォールの詳細をすべて学習しなくても、主要な侵害の背後にある脅威から保護できるということです。 始めたばかりの場合は、AWS WAF マネージドルールは、Web アプリのセキュリティを初めて理解し、今日のアプリケーション (およびビジネス) を悩ませている最も一般的な脅威から保護するのに適しています。
AWS WAF マネージドルールとは、AWS WAF の機能を拡張し、あらゆるアプリを保護するウェブアプリのセキュリティルールです。マネージドルールはセキュリティの専門家が管理し、更新するため、常に最新の状態に保たれ、最新の脅威から防御されていると確信できます。 これは、あらゆるアプリ向けのクラウド上のサービスとしてのセキュリティです。
最も一般的な 3 つの脅威 (ボット、既知の脆弱性、ハッキング) からアプリを保護するには、今すぐ導入を検討する必要がある 3 つの異なるルールがあります。 ただし、一度に選択できるマネージド ルールは 1 つだけなので、慎重に検討してください。
OWASP Top Ten は、開発者、DevOps、セキュリティ専門家の間でよく知られています。 あなたは彼らの名前の多くを知っています: SQLi、XSS、コマンド インジェクション、No-SQLi インジェクション、パス トラバーサル、予測可能なリソース。 これらは、悪用されると組織に頭痛の種(そして時には望ましくない見出し)をもたらす、最も一般的な脆弱性のトップ 10 です。 そして、特に興味深い消費者データや企業データを含むデータ ソースと通信するアプリで見つかる場合、それらはしばしばそうなります。
最適な方法は、開発者がこれらの問題を発見したときにコード内で対処することです。 現実的に、それが起こるには(起こるとしても)数か月かかることはわかっています。 そのため、これらの一般的な脆弱性に対処できる Web アプリケーション ファイアウォールは、悪用に対する即時の保護を提供するため、非常に価値があります。 恒久的な解決策としてであれ、一時的な対策としてであれ、OWASP Top Ten を含むルール セットを採用することは理にかなっています。
既知の CVE に対する保護の重要性は、いくら強調してもし過ぎることはありません。
2015 年に Kenna Security は、2 億 5,000 万の脆弱性と 10 億件を超える侵害イベントを抱える 50,000 の組織を対象に実施した調査について報告し、脆弱性の修復に関して非常に興味深い点が 2 つあることを発見しました。
言い換えれば、ほとんどの組織では、修復する機会を得る前に CVE が悪用される可能性があります。 注意を払っていなかったとしても、非常に注目を集めた侵害の多くが CVE に起因することが判明しています。 つまり、超超超超有名人です。 CVE のあるプラットフォームとライブラリをいくつか考えてみましょう。 Apache、Apache Struts、Bash、Elasticsearch、IIS、JBoss、JSP、Java、Joomla、MySQL、Node.js、PHP、PHPMyAdmin、Perl、Ruby On Rails、WordPress。 これは、最近のインターネット上のほとんどのアプリをカバーします。
したがって、CVE が公開されたらすぐに、CVE の悪用に対してアプリケーションを事実上パッチできるルールを採用する必要があります。 ソース(通常はプラットフォームまたはサードパーティのライブラリ)でパッチを適用する必要がありますが、その間、アプリは侵害から保護されます。
この修復ギャップとセキュリティ専門知識の不足こそが、クラウドでの管理ルールが非常に優れたアイデアである理由です。 専門家がそれらを保守し、最新の状態に維持して、アプリをエクスプロイトから保護できるようにします。必要なのはそれらを展開することだけです。
最近のアプリ訪問者の半分以上はボットです。 また、サイトをクロールしてインデックスを作成し、検索エンジンで利用できるようにする、優れたスパイダータイプのボットでもありません。 私たちが話しているのは、脆弱性を探したり、コミュニティにスパムを送り込んだり、サイトをスクレイピングしたり、ボットネットベースの DDOS 攻撃に参加したりする、怪しげなディセプティコンのようなボットのことです。
ボットに対する防御は簡単ではありません。 CAPTCHA はボットを識別してブロックする新しい方法を常に試みていますが、季節性インフルエンザのように、これらの厄介な生き物は適応し続け、防御を回避し続けます。
それでも、悪意のあるボットは検出可能な動作を示し、望ましくないものとして識別されます。 Bot Defense ルールは、悪意のある動作やアクティビティを監視し、アプリケーションとのやり取りをブロックすることができます。 過去 2 四半期にわたってボット防御サービスを利用する組織の割合が増加しており、現状を考えると、この傾向は今後も続くと予想されます。
クラウド内のアプリにボット保護ルールを導入すると、CVE の悪用を未然に防ぐ空中防御を提供できます。
一部のアプリでは、これら 3 つの脅威すべてに対する保護が必要になることに注意することが重要です。 さらに、ボット、CVE、OWASP Top Ten 以外のものに対する保護も必要になります。 一部のアプリでは、データのスクラビングや漏洩防止、さらにアプリ固有の防御が必要になります。 スキーマ検証は、特に不明なソースからデータを受け入れる場合の良い例です。 L7 (アプリケーション層) DDoS もその 1 つです。 TCP または HTTP ベースの脆弱性から保護する場合、プロトコルの強制も非常に重要です。 複数のルールや追加の保護が必要な場合は、フル機能のAdvanced WAF を検討してください。 また、アプリの機能や顧客が増えるにつれて、アプリの保護を強化することにも注意を払う必要があります。
いずれにせよ、マネージド ルールはクラウドでのアプリ保護を開始するための優れた方法です。 これらは、ユーザー自身がセキュリティの専門家になる必要がなく、Web アプリのセキュリティの強固な基盤を提供します。
AWS と F5 に参加して、F5 WAF がデータの保護、コンプライアンス規制の遵守、クラウド ワークロードの継続的な保護の確立にどのように役立つかを学んでください。
ウェビナーに参加して以下を学んでください:
ウェビナーの日時:
2018 年 4 月 25 日水曜日 | 午前 10:00 PT