Web アプリケーションで多層制御セキュリティ戦略を構築する

サイバー攻撃は増加傾向にあり、政府は国民と組織の両方に対してセキュリティ対策の見直しと強化を呼びかけています。そのため、現在多くのお客様が最適な Web アプリケーション保護を実施するために、実行可能な対策を検討しています。すべての攻撃を阻止できるソリューションは存在しませんが、多層防御戦略で使用されている多くのベストプラクティスによって、攻撃の影響を制限することができます。

このブログ投稿では、様々なレベルでアプリケーションを保護するステップを紹介します。それは、攻撃できる対象の限定方法を理解することから始まります。

攻撃対象領域とベンダーが提供するソリューションを把握する

まず、Web アプリケーションを使用してクライアントが情報を送受信する際に、一般的なリクエストで行われる複数のステップについて考えるとよいでしょう。例えば、自宅が攻撃されるとすると、多くの人は玄関を考えますが、窓、私道、水道管、道路の電柱なども考慮する必要があるのです。同じように、アプリケーションによる対象ユーザーへのサービス提供を妨げる可能性のあれば、あらゆるコンポーネントがターゲットになり得ます。

Web リクエストのこうしたコンポーネントを順次見てゆくと、まずドメイン名と IP アドレスに解決するための DNS フェーズがあります。次に、この IP に接続し、HTTP リクエストが送信されます。通常、この IP は CDN やロードバランサーなどのリバースプロキシに結び付けられています。最後に、リバースプロキシがコンテンツの元のバージョンを保存しているオリジンネットワークに対してリクエストを行います。これらを保護しなければなりません。

データリンク、接続、セッションを確立した後、完全な形式のリクエストを返すためには、これら3つの段階すべてを通じて、完全な OSI (Open Systems Interconnect) モデルまたは TCP/IP モデルの接続が実行されなければなりません。まとめると、次のように考えることができます。

セキュリティの観点から、今挙げたポイントすべてが、攻撃対象となり得る重要な機能です。各所で保護を行い、利用しているベンダーが皆さんに代わってどのような保護を行っているかを把握することが、可用性の維持に欠かせません。

アプリケーションを攻撃から保護する方法としては、分散 DNS、グローバルに分散した CDN によるコンテンツのキャッシュ、迂回を困難にする様々な識別子を使用した速度制限によるレートの制限、ブロックモードの強固な WAF の使用などが挙げられます。Fastly はこうした保護を漏斗のようなものだと考えており、以下のような多層防御のインフラセキュリティ戦略に沿って、複数のレイヤーにわたって保護を行っています。この投稿の続きでは、各セグメントと保護の詳細を説明します。

すべてのレイヤーで保護する

インフラレイヤーの保護

現在、最新のインターネットアプリケーションのほとんどでは、企業はネットワークを直接運用するのではなく、先に説明した3つの Web リクエストフェーズをすべてクラウドプロバイダーにアウトソースしています。しかし、DNS は攻撃対象となることが多く、Web リクエストの最初のフェーズでもあります。そのため、可能であれば複数の DNS プロバイダーを利用し、可用性を最大限に確保することをおすすめします。また、Fastly はお客様に CDN などのリバースプロキシをできる限り多くのトラフィックの前に置き、オリジンのネットワークがこれらのプロキシなど特定の IP からのトラフィックだけを受信するようにして、直接の攻撃を回避することを推奨しています。最後に、オリジン自体はクラウドプロバイダーまたは複数のプロバイダー内に置き、その手前で CDN によるロードバランシングを行うこともできます。これにより、自社チームではなくベンダーがオリジンネットワーク保護の第一の責任を負うこととなります。

こうした対策を講じれば、ベンダーの対応範囲が広がり、個々の Web サイトやアプリケーションの運営者が UDP 増幅や TCP SYN フラッドなどの低レイヤーの攻撃を直接軽減する必要がなくなります。例えば、Fastly にはデータ転送量が多い大型グローバルネットワークや対策能力だけでなく、Fastly のインフラを常に監視するネットワークグループがあります。そのため、お客様に代わってこうした攻撃に即座に対応できます。

独自のネットワークを運用しているお客様は、多くの場合、ISP などの機能を活用し、BGP から IP を迂回させ、悪意のあるトラフィックを排除して、オリジンネットワークに配信しています。Fastly のサービスを利用すると、膨大な量のトラフィックが生じた場合でも、これらのアクセス制御を適用できます。

アプリケーションレイヤーの保護

コアインフラが保護されれば、運用者が「インプロトコル」、つまり OSI モデルのレイヤー 7 をベースとする攻撃に注力できます。これは、アプリケーションに対する実際のユーザーリクエストを模倣する攻撃です。

アプリケーションの攻撃には、2 種類の形態があります。1つ目は、継続的なインフラ攻撃の一種で、一般的な顧客のリクエストに非常に近いリクエストを用いたトラフィックによるフラッド攻撃です。この場合、トラフィックの量が問題となります。攻撃の目的は、アプリケーションに圧倒的な負荷をかけ、正当なリクエストの処理を停止させることや (つまりサービス拒否) 、データ、金銭、在庫を引き出すことです。

第2の攻撃の形態は、対象を絞ったリクエストです。最終的な目的はアプリケーションシステムをコントロールすることにあるので、リクエスト自体に悪意があります。SQL インジェクション (SQLi)、コマンド実行 (CMDEXE)、クロスサイトスクリプティング (XSS)、管理ページへのアクセス試行のほか、Log4j の脆弱性を悪用しようとするリクエストはすべて、この攻撃の典型例です。

欠落部分に注意する

インターネットベースのデバイスや大規模なボットネットが普及したことにより、プロトコル攻撃の中でもシステムに対するフラッド攻撃の実行は、これまで以上に容易となりました。また、このような攻撃の成熟度も進化しています。ここからは、この攻撃の進化とアプリケーションを保護する方法を説明します。

キャッシュから提供する

最も単純な攻撃の例は、誰かが同じリソースに対して何十億回ものリクエストを行い、提供側のシステムを消耗させようとすることです。この場合、キャッシュから提供するアセットをできる限り多くするだけで、こうした形態の攻撃の影響を軽減できます。リクエスト共有やシールドといった、高いキャッシュヒット率を実現し、オリジンに送信されるトラフィック量を低減する受動的な解決策は、リクエストが実際のユーザーではなくボットから行われている場合に、特に大きなメリットがあります。さらに、リクエストクエリパラメーターの順序付けやサニタイズのように、能動的にキャッシュカバレッジを増加させることにより、キャッシュの余力をできる限り大きくすることができます。多くの場合、インプロトコルアプリケーション攻撃を回避する方法の中でも、コンピューティング負荷が最小でコスト効率が最も高いのは、キャッシュからトラフィックを提供することです。

高レート、高リスク

攻撃の次なる進化は、単純に URL をランダムなハッシュに変えたり、リクエストの他の値を変えたりして、キャッシュできないようにすることです。つまり、大量のトラフィックが高い割合でオリジンに送り返されることとなります。Fastly では、このような攻撃を「キャッシュバスティング HTTP フラッド」と総称しています。

エッジレート制限は、クライアント識別子に基づいてトラフィックの全体的なレートを確認します。攻撃者は IP、ユーザーエージェント、ネットワークなどを変えることができますが、複数のポリシーを併用することで、サイトでの一般的なトラフィックプロファイルに基づき全体的なトラフィック速度の制限を設定できます。こうしたポリシーによる防護策では、例えば IP ごとに最大100 RPS、ユーザー ID ごとに最大100 RPS、ネットワーク (ASN など) ごとに最大500 RPS を許可します。目標は攻撃を完全に排除することではなく、下流のシステムが処理できる程度にトラフィックの流れを低く抑えることです。

トラフィック量を抑えた攻撃

すべての攻撃者が強引な攻撃を仕掛けるわけではありません。ときには、バックエンドのシステムに打撃を加えることを目的に、目立たないようにトラフィックを低量に保ったまま、低速で何かを攻撃します。記録を一括変更できる API や、複数のシステムへのクエリが可能な認証リクエストを見つけたら、攻撃者はそのアプリケーションを利用して、自らの影響力を増幅させます。同様に、脆弱なシステムを探る攻撃者は、検知を完全に回避できるようにトラフィック量を抑えたいと考えています。

より正確なコントロールを実現する場合は、アプリケーションレート制限を使用すると、低トラフィック量の攻撃に対して極めて高い精度を発揮します。例えば、API URL のリストに対して IP が 1 分間で 5 回までしかリクエストできないよう制限するルールを簡単に設定できます。また、外国や TOR ノードなど、特定のソースからのレートのみを制限したり、既知の優良リクエストソースのリストを除外したりするなど、ロジックを複雑にすることもできます。法律で特に定められていない限り、特定の国からのリクエストすべてをブロックすることは、通常、適切な行為とは言えません。むしろ、リスクの高い地域 (現在業務を行なっていない地域など) からのリクエストの数や許容する種類をより厳格に管理する方が望ましい場合がほとんどです。

細かな点に留意する

多様な種類のフラッドトラフィックを排除しても最後まで残るのが、リクエスト数は非常が少なくても悪影響を及ぼす、悪意のあるリクエストです。こうした種類の攻撃の多くは OWASP による上位の攻撃リストで定義されており、悪意のある Web リクエストの略記として使用できます。さらに、共通脆弱性識別子 (CVE) を悪用してアプリケーションの欠陥を利用する、個別の攻撃も存在します。これまでは、重大な脆弱性へのパッチ適用や管理に加え、脆弱性そのものに関わる受信トラフィックを停止することが、 Web アプリケーションファイアウォール (WAF) の役割でした。

従来型の WAF では、WAF ルールがブロックモードであることを確認し、できる限り多くのアセットをカバーして最大限の保護を行うことが推奨されていました。しかし、次世代 WAF ソリューションでは、強化された言語処理機能を活用して、より的確に悪意のあるリクエストを識別し、誤検出を防ぐことができます。また、Fastly の次世代 WAF はしきい値を活用し、リクエストを拒否する前に、攻撃の分類と攻撃速度の両方を確認します。これにより、従業員が CMS にコードを送信し、それがたまたま「攻撃」シグナルを引っかかるといった「主観的に悪意のない」リクエストをブロックしてしまう可能性を低くすることができます。こうした機能の組み合わせにより、より多くのアセットに WAF を適用できるとともに、本番環境で正確なブロックを実現できます。先に述べたように、レート制限機能は従来型の WAF の一般的な役割を超えて、トラフィックの境界を変更するものです。

全体的なセキュリティ戦略

WAF や CDN の活用など、この投稿で説明したすべてのトピックは、包括的な多層防御セキュリティ戦略に含めておくべきものであることを指摘しておきたいと思います。中央認証システムを通じてロールベースのアクセス制御 (RBAC) と多要素認証 (MFA) を行えば、ユーザーのセキュリティを適切に確保し、セキュリティシステムへの不正アクセスを低減できます。また、WAF を使用すれば、脆弱性管理におけるベストプラクティスに従うことや、アプリケーションに加えられた変更を能動的にスキャニングすることが不要になるわけではありません。

しかし、公共インターネットを通過するトラフィックの大部分は HTTP (S) ベースです。この投稿で説明したメソッドは、現代の Web アプリケーションに対するサイバーセキュリティの一般的な課題のいくつかを反映しています。信頼できるパートナーと協力し、攻撃される前に、アプリケーションを保護できるシステムを構築しましょう。Fastly のテクノロジーチームとサポートチームが、お客様によるこれらのテクノロジーの実装と、可能な限り保護された状態の維持をサポートします。使用を開始する場合、またはご質問がある場合は、お問い合わせください。