最近、私は Webアプリケーションファイアウォール と、インジェクション、XSS、CSRFなどの最も頻繁な攻撃から保護するという事実について読んでいます。
ただし、goodアプリケーションはこれらのエクスプロイトに対してすでに耐性があるはずなので、なぜ企業は試すためにこれらの高価なデバイスを購入することを好むのですか?保護(WAF 完全ではない いずれか)最初にセキュリティの欠陥を修正する代わりに、セキュリティの欠陥を持つアプリ?
詳細な回答をありがとう、そんな初心者の質問がそれほど注目されるとは思いもしませんでした。
セキュリティを展開するときは、複数のレイヤーを適用することをお勧めします。寝室のドアに鍵がかかっているからといって、家の玄関に鍵をかけないという意味ではありません。複数のアプリケーションの前にWAFルールの一般的なセットを適用することもできます。
WAFはIDS/IPSのより大きなスイートの一部である可能性があります。また、WAFがインラインであり、アプリケーションがブロック、ロギング、dbクエリなどのリソースを浪費しないようにする場合、アプリケーションのパフォーマンスにも役立ちます。
また、アプリケーションのセキュリティについて妥当な保証を得るリソースとスキルが組織にあると想定します。サードパーティのアプリケーションであるか、サードパーティのモジュールがある場合、これらのコンポーネントは簡単にアップグレードできないか、クローズドソースであるか、プログラムを変更するライセンスに反する可能性があります。
多くの組織は、古くなった開発者によって作成されたレガシーアプリケーションに悩まされています。WAFは、その組織がそれらのアプリケーションに対する攻撃から身を守るための手段です。
WAFは修正の展開もはるかに高速です。複雑なアプリケーションの更新には数週間から数か月かかる場合があり、WAFの保護は数時間で更新されることがよくあります。
それはコスト対利益でもあり、一部のWAFはアプリケーションの保護に非常に優れているので、なぜ1年間で段階的に廃止されるレガシーアプリケーションの書き換えに数百万ドルを費やすのでしょうか。
いいえ、完全に安全なアプリケーションはほとんどありません。 WAFは、実際にアプリケーションに到達する前に攻撃を軽減する方法です。さらに、悪意のあるユーザーを簡単に特定し、自動的にブロックすることができます。
WAFはアプリケーションを修正するためのものではなく、攻撃を防止し、場合によっては軽減するために用意されています。アプリケーションが安全であるが、アプリケーションが記述されている言語ではない場合は、修正がリリースされるまで攻撃を防ぐための対策を講じることができます。
組織は、従来のWebアプリケーションが提供しない(または一般に提供するようにコーディングされていない)WAFが提供できる機能を確認する必要があります。
たとえば、WAFには通常、ある種の「応答」メカニズムが組み込まれています。攻撃が発生した場合、アプリケーションを保護するために自動的に応答できます。これには、ブルートフォース保護、DOS(ある程度)、および特定のIPアドレスからの要求の禁止が含まれます。これを行うようにアプリケーションをコーディングすることもできますが、WAFが境界にあります。そこで悪意のあるトラフィックを停止し、さらにネットワーク内で停止するのが最善です。さらに、ネットワークベースのWAFは複数のWebサイトを保護できるため、必要な開発時間を短縮できます。
主な利点の1つは、攻撃/ロギングの検出に関連しています。 WAFが攻撃を検出している場合、その情報をSIEMソリューションに渡すことができます。 WAFには、作成したバックエンドだけでなく、さまざまなバックエンドに対する攻撃を検出するためのシグネチャがあります。その後、セキュリティスタッフはその情報を使用して、最善の行動方針を決定できます。たぶん彼らはそれを、起こっている他の攻撃と関連づけているのかもしれません。
もう1つの重要な機能は、WAFを使用してWebサーバーだけでなくWebアプリケーションも保護できることです。たとえば、WAFは、IIS自体に対するバッファオーバーフロー攻撃を阻止するように構成できます。Webアプリケーションはこれを実行できません。
最後に、WAFを使用して「仮想パッチ」を実行できます。たとえば、特定のリクエストが送信された場合、Webアプリケーションにセキュリティホールがあることがわかったとします。もちろん、コードを変更することもできます。ただし、これには時間がかかる場合があります(変更管理、開発者に何かを記述させる、テストなど...)。開発チームからのパッチを待つ間、その攻撃経路からWebサイトを「保護」するための署名が作成される可能性があります。
追加すべきことの1つは、@ Lucas Kauffmansの回答に沿ったものです。セキュリティはすべてレイヤーに関するものです。 Webアプリケーションが「完全に」安全であることを確実に知ることはできません。その前に別のレイヤーを追加しても問題ありません。
WAFは、「必要/不要」の議論のどちらかの側に多くのセキュリティ関係者が登場して以来、話題になっています。それはすべて、特定の状況に必要な機能にかかっていると思います。
いいえ。実際には、WAFを実装すると攻撃対象が増える WAFに対する攻撃に対してインフラストラクチャが脆弱になる。
WAFの導入は、WAFが保護できる脆弱性がアプリケーションにある可能性があるため、実用的な方法ですが、ここでは、誰も何も完全に確信しておらず、管理者が正しいと思うことを行う分野にいます。
私の意見では、本当に正しいことは、サイトに必要なセキュリティ対策とプロセスを実装することです。 アプリケーションコードと開発プロセスをこのように制御できる場合、WAFは必要ありません。ただし、この状況は常に可能とは限りません。
WAFは、すべてをWebレベルで実行できるようにするという無責任への反応です。つまり、以前はさまざまなポートでサービスが実行されていました。すぐにファイアウォールを作成して、特定のサービスを無差別に調べようとする者が無差別に開かないようにする必要がありました。したがって、サービスはフィルタリングされており、許可されるのは、たとえばポート80を経由することだけです。では、人々は何を始めますか?ポート80を介してサービスを利用できるようにします。これで、ポート80を介してサービスを使用できるようになりました。以前は、特定のポートを介して通常のファイアウォールでフィルタリングされていました。
歴史は繰り返されているようです。人々は安全でないサービスを作成し、セキュリティ志向の人々はセキュリティ制限を設定し、それが使いやすさを犠牲にしています。したがって、人々はさまざまな方法で物事を開き、開こうとします(この場合、「80ですべてを入れましょう」 ”);これにより、セキュリティ志向の人々はトピックを再訪せざるを得なくなり、この場合、ファイアウォールもWebに適合させる必要があります。これは、セキュリティとユーザビリティの間の絶え間ないトレードオフの戦いです。
したがって、今日WAFを使用する必要があるかどうかを確認することは、15年前にファイアウォールを使用する必要があるかどうかを確認することと同じです。
常に、WaF'aは、新しい脆弱性が発見されたときに更新できる追加のセキュリティレイヤーを追加します。アプリケーションは今日は安全ですが、明日は壊れる可能性があります
ファイアウォールが必要ないよりも100%安全であれば、理論的にはそれが必要です。実際には、そのアプリが100%確実であるとは限りませんではない脆弱です。アプリに必要な権限のみを与える必要があります。あなたが検索アプリを持っているように、特定のテーブルのみを検索することができます。攻撃を止めることはできませんが、攻撃を制限します。
ライフサイクルと展開時間に関するメモ
上記のように、アプリケーションのライフサイクルは、修正にかかる時間に大きく影響します。
企業や他の組織のWebアプリケーションには、さまざまな形やサイズがあります。
また、Webアプリケーションは組織内で異なる用途を持つ場合があります。
したがって、これらすべての変数を使用すると、次の作業に長い時間/多くの労力が必要になります。
したがって、Web Appファイアウォールを使用すると、これらのレイヤーをすべて切り抜け、多大な費用/時間/労力をかけずに修正をすばやく実装できます。