【ITニュース解説】Fraudulent Resource Consumption Attacks and a Gatekeeper Solution

クラウドサービスを狙った新たな脅威、不正なリソース消費攻撃（FRC攻撃）とその対策について解説する。FRC攻撃は、クラウドサービスを悪用し、サービスの利用料金やリソースを不正に搾取することを目的とした巧妙なサイバー攻撃である。システムエンジニアを目指す上では、このような新しい脅威とその対策技術について理解しておくことが非常に重要となる。

FRC攻撃は、クラウドサービス提供者にとって深刻な問題を引き起こす。Amazon Web Services (AWS) や Microsoft Azure のような多くのクラウドサービスは、利用した分だけ料金を支払う「従量課金モデル」を採用している。このモデルを悪用するのがFRC攻撃の本質だ。攻撃者は、まず、利用者のクラウドアカウントに不正にアクセスする。このアクセスは、通常、認証情報の漏洩や脆弱性を突くことによって行われる。一度アカウントを乗っ取ると、攻撃者はそのアカウントを使って、自動化された大量のリソース要求（ボットネットと呼ばれる乗っ取られたコンピューター群からの要求）をクラウドサービスに送りつける。これにより、ネットワーク帯域幅、ストレージ、計算処理能力といったクラウドのリソースが、攻撃者の私的な利益や悪意のある目的に利用されてしまう。

FRC攻撃による被害は多岐にわたる。まず、乗っ取られたアカウントの持ち主は、身に覚えのない高額な利用料金を請求される可能性がある。クラウドサービス提供者側も、不正なリソース消費によってインフラに過剰な負荷がかかり、サービス品質の低下やシステム停止につながることがある。帯域幅やストレージが枯渇すれば、正当な利用者の業務が著しく阻害され、企業活動に深刻な影響が出る。サーバーが停止すれば、企業の財務的損失だけでなく、顧客との契約不履行による法的問題に発展する可能性もある。さらに、FRC攻撃は、データ窃盗やネットワーク侵入といった、より悪質なセキュリティ脅威から注意をそらすための「目くらまし」として利用されるケースも少なくない。このような背景から、FRC攻撃はクラウド利用者とサービス提供者の双方にとって、迅速かつ効果的な対策が求められる喫緊の課題となっている。

この問題に対する有効な解決策として、「ゲートキーパー」と呼ばれる仕組みが提案されている。ゲートキーパーは、クラウドサービスへのあらゆるリクエストを監視し、フィルタリングする役割を果たす。これは、従来の認証に加え、もう一段階の認証プロセスを追加するようなイメージだ。ゲートキーパーは、個々のクラウドリクエストの送信元や、そのリクエストの優先度を検証する。もしリクエストが正当な送信元から来ていない、あるいはその正当性が確認できない場合、ゲートキーパーはそのリクエストの優先度を最低限に設定し、実行を厳しく制限する。これにより、不正なリクエストが大量のリソースを消費するのを防ぎ、FRC攻撃によるコスト発生を抑制することができる。基本的に、ゲートキーパーは、正常で認証されたトラフィックは効率的に通過させる一方で、疑わしいクラウドリクエストは厳しく取り締まる。このメカニズムが適切に機能すれば、FRC攻撃の脅威を効果的に排除できると期待されている。

ゲートキーパーの有効性を検証するため、ある実験的なアプローチが採用された。この実験では、通常のユーザーリクエストと、FRC攻撃をシミュレーションした不正なリクエストの両方を、ゲートキーパーの有無で比較する形でクラウドサービスのエンドポイントに送信した。具体的には、ゲートキーパーがない場合とある場合で、それぞれ10回の試行を行った。各試行では、まず毎分200リクエストの「通常トラフィック」を10分間送り、次に毎分300リクエストの「上昇トラフィック」（FRC攻撃を模倣）を5分間送り、最後に再び毎分200リクエストの「通常トラフィック」を10分間送って、クラウドサービス上のLambda関数を呼び出すという流れだ。これらのリクエストは、Amazon Web Services (AWS) 環境で行われ、その結果はCloudWatch AnalyticsというAWSの監視ツールを使ってグラフ化された。ゲートキーパーの有無にかかわらず、グラフには中央の5分間、つまり「上昇トラフィック」が送られた期間に明らかなリクエスト数のピークが確認された。ゲートキーパーの有効性は、このピーク期間における毎分の平均リクエスト数 (RPM) の削減率で評価された。実験は、ゲートキーパーがピーク時の平均RPMを70%以上削減できた場合に成功とみなされた。

このゲートキーパーの概念実証（PoC）は、Pythonアプリケーションとして開発された。このアプリケーションは、クライアント側とサーバー側に分かれている。クライアント側は、あらかじめ設定された数のユーザーに代わって、関数名、ユーザー優先度、リージョン、パスなどの情報を含むペイロードをサーバーに送信する役割を担う。サーバー側は、クライアントから送られてきたリクエストを受信し、それらに含まれる関数の優先度に基づいて処理を実行する。もしユーザーの優先度が低いと判断された場合、そのリクエストは実行が制限され、完了するまでにより長い時間がかかるように設計されている。この仕組みによって、ゲートキーパーはFRC攻撃によるリクエスト数のピークを効果的に低減できる。実験では、Pythonのアルゴリズムを使って、通常のトラフィックとFRC攻撃トラフィックの両方をAWSのLambda関数エンドポイントに送信した。CloudWatch Analyticsは、関数呼び出し数を毎分のリクエスト数として正確に追跡し、その結果を線グラフとして出力するために使用された。

ゲートキーパーの性能を評価し分析するために、いくつかの重要な指標が考慮された。一つ目は「毎分のリクエスト数 (RPM)」で、これはサーバーに送信されるリクエストの頻度を測るものだ。二つ目は「応答時間」で、リクエストを送信してからサーバーから応答が返ってくるまでの時間を指す。三つ目は「成功率」で、これは成功した応答の数を全リクエスト数で割った割合を示す。反対に「エラー率」は、失敗したリクエストの数を示す指標となる。さらに、「レート制限ヒット数」は、リクエストがサーバーによって定められた処理上限（レート制限）に達し、制限された回数を示す。そして「リトライ回数」は、レート制限によってリクエストが失敗した後、再試行された回数を表す。また、「レイテンシ」は、リクエストの送信から応答の受信までの時間遅延を示す。最後に「システム負荷」は、リクエストを処理しているサーバーのCPU使用率、メモリ使用量、ネットワーク使用量といったリソースの消費状況を包括的に示す指標となる。これらの指標を総合的に分析することで、ゲートキーパーがFRC攻撃に対してどれほど効果的であり、かつシステムの性能にどのような影響を与えるかを詳細に評価することが可能になる。