【実務・中級編】 GCP Cloud ArmorによるDDoS攻撃とWAF保護 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

現場で血を流しながら学んできたエンジニア諸君、ようこそ。

教科書通りの「暗号化しましょう」「WAFを入れましょう」という助言は、もう卒業しよう。今日は、戦場におけるエッジ防御の最前線、GCP Cloud Armorの実践的なチューニングと、なぜその設定が必要なのか、という「攻撃者の思考」に焦点を当てる。

暗号からWAFへ：防御のレイヤーを理解する

まず、技術的な前提を確認しておこう。TLS（RSAやECC）による通信の暗号化は、あくまで「盗聴」と「改ざん」を防ぐためのものだ。しかし、暗号化された通信の中身は、WAFが適切に復号して検査しなければ、単なる「暗号化された攻撃コード」をサーバーへ直送するトンネルに過ぎない。

攻撃者は、HTTPSの裏側に潜む「アプリケーションの論理的脆弱性」を突いてくる。ここでCloud Armorの出番だ。

Cloud Armorで「防御の穴」を塞ぐ：実務的なWAF設定

Cloud Armorの真価は、マネージド保護ルール（OWASP Top 10対応）を「適用しただけ」で満足しないことにある。攻撃者は常にシグネチャを回避（Evasion）しようと試みるからだ。

1. SQLi / XSS対策の本質

多くのエンジニアが陥る罠は、過剰なルール適用による「正規ユーザーの遮断（False Positive）」を恐れ、緩い設定にすることだ。我々は「厳格なフィルタリング」と「ログ分析による除外設定」を同時に回す必要がある。

以下のTerraform設定は、Cloud Armorのセキュリティポリシーを定義する際の実践的なテンプレートだ。

# Google Cloud Armor セキュリティポリシーの定義例
resource "google_compute_security_policy" "main_policy" {
  name = "prod-web-policy"

  # デフォルトは拒否（ホワイトリスト的な考え方を持つこと）
  default_rule {
    action   = "deny(403)"
    priority = "2147483647"
  }

  # OWASP Top 10 のシグネチャを適用
  rule {
    action   = "deny(403)"
    priority = "1000"
    match {
      expr {
        expression = "evaluatePreconfiguredExpr('sqli-stable')"
      }
    }
    description = "SQLインジェクション防御"
  }

  rule {
    action   = "deny(403)"
    priority = "1010"
    match {
      expr {
        expression = "evaluatePreconfiguredExpr('xss-stable')"
      }
    }
    description = "クロスサイトスクリプティング防御"
  }
}

攻撃者の視点：なぜ防御をすり抜けるのか？

例えば、' OR 1=1 -- のような古典的なSQLiを投げる攻撃者はもう稀だ。今の攻撃者は、URLエンコードを二重にしたり、半角スペースの代わりに制御文字を使ったりして、WAFの正規表現を「無効化」しようとする。

これに対抗するには、WAFだけでなくアプリケーション側での「防御的コーディング」が必須だ。

2. アプリ側での防御：PDOによるプレースホルダ

WAFは「壁」だが、アプリケーションは「盾」だ。二重の防御がなければ、突破された瞬間にゲームセットとなる。

PHPでデータベースに接続する際は、必ずプリペアドステートメントを使用すること。以下は、脆弱性を一切排除した安全なコードの書き方だ。

<?php
// 安全なデータベース接続とクエリ実行
try {
    $pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=utf8mb4', 'user', 'pass');
    
    // プリペアドステートメントの使用（これこそがSQLi対策の要）
    $stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
    
    // 値をバインドする（直接クエリに埋め込まない）
    $email = $_POST['email']; 
    $stmt->execute(['email' => $email]);
    
    $user = $stmt->fetch();
} catch (PDOException $e) {
    // エラー詳細を画面に出さない（攻撃者にヒントを与えない）
    error_log($e->getMessage());
    die("システムエラーが発生しました。");
}
?>

運用上のTIPS：WAFを「育てろ」

Cloud Armorの設定を適用した直後は、必ず「プレビューモード（Preview Mode）」で動かしてほしい。

1. プレビューモードで運用: action = "deny" ではなく preview = true に設定する。
2. ログの監視: Cloud Loggingで jsonPayload.enforcedSecurityPolicy.name を追跡し、正当なユーザーがブロックされていないかを確認する。
3. 継続的改善: ブロックされた通信が「攻撃」なのか「誤検知」なのかを判別し、必要であれば eval 系のルールを除外するのではなく、ルール自体をチューニングするか、アプリケーションの入力を修正する。

最後に：セキュリティは「完璧」ではなく「継続」だ

暗号理論の知識も、Cloud Armorの設定も、すべては「敵を知り、己を知る」ためのツールに過ぎない。サイバー攻撃者は常に進化する。だが、我々が「多層防御」という原則を崩さず、泥臭いログ分析とコードレビューを怠らなければ、彼らにとってこのシステムは「割に合わないターゲット」になる。

今日から、サーバーログの末尾を見る回数を少しだけ増やしてくれ。それが、インシデントを未然に防ぐための、最も手っ取り早い「ハッカーへの対抗策」だ。

健闘を祈る。