【入門編】 DDoS攻撃に対するクラウドネイティブな緩和策とAuto Scalingの連携 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。新人ITエンジニアの皆さん、あるいは「アプリを作るのは好きだけど、セキュリティって聞くとなんだか難しそう……」と身構えてしまう開発者の皆さん、日々の開発お疲れ様です！

セキュリティの現場に長く身を置いていると、「どうやったらサービスを安全に守れるか」という相談をたくさん受けます。その中でも、初心者の方が一番パニックになりやすいのが「DDoS（ディードス）攻撃」です。

今回は、この厄介なDDoS攻撃から私たちのサーバーを守るための「クラウドネイティブな防犯術」について、難しい専門用語をできるだけ噛み砕いて、一緒に一歩ずつ学んでいきましょう！

—

1. 家の鍵で例える「DDoS攻撃」と「オートスケーリング」の仕組み

まずは、セキュリティの基本をイメージしやすくするために、私たちの「お家」に例えて考えてみましょう。

泥棒の新しい手口？ DDoS攻撃ってなに？

通常の「ハッキング」が、器用にピッキングして家の鍵を開け、こっそり侵入する「空き巣」だとすれば、DDoS攻撃は「何千人ものサクラを雇い、一斉にあなたの家の玄関のチャイムを同時に鳴らし続ける嫌がらせ」です。

泥棒は盗みを働くわけではありません。ただひたすら「ピンポーン、ピンポーン！」とやり続けます。
あなたはどうなりますか？ 玄関の対応に追われて、家族との会話もできなければ、宅配便を受け取ることも、仕事に行くこともできなくなってしまいますよね。

これがDDoS攻撃の正体です。世界中から大量の偽装されたアクセス（トラフィック）を送りつけ、サーバーという「玄関」をパンクさせ、本当のお客様が使えなくしてしまう嫌がらせなのです。

オートスケーリング ＝ 「ピンチの時に分身する玄関」

では、この嫌がらせに対して、私たちはどう立ち向かえばいいでしょうか？
昔の頑固なエンジニアなら「もっと分厚い鉄のドア（超高性能な1台のサーバー）に買い替えろ！」と言ったかもしれません。しかし、何万、何億という攻撃の前には、どんなに巨大な鉄のドアもいつかは壊れます。

そこで登場するのが、今回の主役である「クラウドネイティブなAuto Scaling（自動スケーリング）」です。

これは例えるなら、「チャイムが鳴り響いて混雑してきたら、魔法のように全く同じ作りの玄関とスタッフがパッと自動で増殖し、何人来てもスムーズに対応してくれるスーパーコンビニ」のような仕組みです。
攻撃者がいくら大量のアクセスを送っても、クラウドが自動的にサーバーを何倍にも増やして受け止めてくれるため、サービスがダウンせずに耐え抜くことができるのです。

—

2. クラウドの盾でL3/L4・L7のいやがらせを防ぐ

DDoS攻撃には、大きく分けて「ネットワークの道路を物理的に渋滞させる攻撃（L3/L4）」と、「お店のレジの前で変な質問を延々とし続ける攻撃（L7）」の2種類があります。

これらを自前のサーバーだけで防ごうとすると、ネットワークの回線がすぐに太刀打ちできなくなってしまいます。そこで、AWSやAzure、GCPといったクラウドベンダーが提供する「門番（DDoS保護サービス）」を一番手前に置くのが現代の鉄則です。

門番がやってくれること

  • L3/L4攻撃の防御: クラウドの広大なネットワークインフラを使い、悪意ある大量のゴミデータを玄関に入る手前で綺麗にろ過して捨ててくれます。
  • L7攻撃の防御（WAFの連携）: アプリケーションの言葉を理解する「WAF（Web Application Firewall）」という門番が、「このアクセスは怪しい動きをしているな」と見抜いて、一歩も中に入れないようにブロックします。

—

3. 実践！Auto Scalingとクラウド防御を連携させる設定

それでは、実際にクラウド（今回はAWSをイメージした構成）でどのように設定を行うのか、現場で使える具体的なイメージを見ていきましょう。

今回は、負荷が高まったら自動でサーバーを増やす「Auto Scaling Group（ASG）」の手前に、悪意あるアクセスをいなすロードバランサー（ALB）を配置する構成を考えます。

サーバーが自動増殖する仕組み（AWS CloudFormation / 設定イメージ）

以下の設定は、CPUの使用率が高くなったら自動的にサーバーを増やす設定のイメージです。

# サーバーの負荷（CPU使用率）が70%を超えたら、自動的にインスタンスを増やす設定
Resources:
  CPUUtilizationAlarmHigh:
    Type: "AWS::CloudWatch::Alarm"
    Properties:
      AlarmDescription: "CPU使用率が70%を超えたらオートスケーリングを発動します"
      MetricName: "CPUUtilization"
      Namespace: "AWS/EC2"
      Statistic: "Average"
      Period: 60
      EvaluationPeriods: 2
      Threshold: 70.0 # 70%の閾値
      ComparisonOperator: "GreaterThanOrEqualToThreshold"
      AlarmActions:
        - !Ref WebServerScaleOutPolicy # 後述のスケーリングポリシーを呼び出す

  WebServerScaleOutPolicy:
    Type: "AWS::AutoScaling::ScalingPolicy"
    Properties:
      AdjustmentType: "ChangeInCapacity"
      AutoScalingGroupName: !Ref MyWebAutoScalingGroup
      ScalingAdjustment: 2 # 負荷が高まったら、一気に「2台」サーバーを増やす！
      Cooldown: 300

このように、「ピンチを察知したら、自動で仲間を呼んで負担を分散する」という仕組みをコードベースで構築しておくことが、クラウドネイティブな防御の第一歩となります。

—

4. アプリケーション側（L7）で仕掛ける防衛策

クラウドの門番に頼るだけでなく、私たち開発者が書くアプリケーション側（PHPやNode.js、Pythonなど）でも、ちょっとした工夫をしておくとDDoSやブルートフォース攻撃（総当たり攻撃）に強くなります。

例えば、ログイン画面やお問い合わせフォームなどで、同じIPアドレスから短時間に何回もリクエストが送られてきた場合、それを弾く簡易的なレートリミット（回数制限）のコードを挟むことが有効です。

以下は、PHPで簡単なリクエスト制限（概念実習用コード）を行う例です。

<?php
// セッションを使った簡易的なレートリミッティング（回数制限）の例
session_start();

$client_ip = $_SERVER['REMOTE_ADDR'];
$current_time = time();
$time_window = 60; // 60秒間（1分間）
$max_requests = 10; // 最大10回まで

// セッションにアクセス履歴がない場合は初期化
if (!isset($_SESSION['request_history'])) {
    $_SESSION['request_history'] = [];
}

// 過去60秒以内のリクエストだけをフィルタリング
$_SESSION['request_history'] = array_filter($_SESSION['request_history'], function($timestamp) use ($current_time, $time_window) {
    return ($timestamp > ($current_time - $time_window));
});

// 制限回数を超えているかチェック
if (count($_SESSION['request_history']) >= $max_requests) {
    // 429 Too Many Requests ステータスを返してブロック
    header('HTTP/1.1 429 Too Many Requests');
    echo "アクセスが多すぎます。しばらく時間をおいてから再度アクセスしてください。";
    exit;
}

// 今回のアクセス時刻を記録
$_SESSION['request_history'][] = $current_time;

// 通常の処理をここに続ける
// echo "ようこそ、安全なページへ！";
?>

このように、アプリ側でも「あまりに短時間で何度もドアを叩く人には、少しお静かにしてもらう（429エラーを返す）」というルールを作っておくことで、L7攻撃のダメージを大幅に軽減できます。

—

5. まとめ：一歩ずつ、確実な防犯対策を

今回は、DDoS攻撃のメカニズムから、クラウドの盾、そしてAuto Scalingによる「分身の術」のような自動スケーリングの仕組み、さらにアプリ側の対策までを紐解いてみました。

セキュリティ対策というと、「完璧にやらなければいけない」とプレッシャーに感じてしまうかもしれませんが、そんなことはありません。

  • 家の外側（ネットワーク・L3/L4）は、クラウドベンダーの強力な門番に任せる。
  • 家の中の混雑（負荷）は、Auto Scalingに自動で受け止めてもらう。
  • 玄関のルール（アプリ・L7）は、コードでちょっとしたお行儀の良さをチェックする。

このように、役割を分担して「一歩ずつ、重層的な防衛」を作っていくことが何よりも大切です。
皆さんも、ご自身のプロジェクトの構成を見直すとき、「もしここに大量のチャイムが鳴ったらどうなるかな？」と優しく想像しながら、安全なインフラストラクチャを育てていってくださいね。応援しています！

スポンサーリンク

コメント

タイトルとURLをコピーしました