【実務・中級編】 エッジセキュリティ：CDN（CloudFront等）による攻撃の分散と遮断 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

おい、新人。ちょっとこっちのモニターを貸せ。
今、お前が組んでいる次期システムのインフラ構成図を見ているんだが……これじゃあ、バックエンドのオリジンサーバーが丸裸で世界中の荒波に突っ込んでいくようなものだぞ。

「いや、AWSのCloudFront挟んでるから大丈夫です」って？
甘い。甘すぎる。CDNをただの「速くするためのキャッシュサーバー」だと思って導入しているなら、今すぐその認識を改めろ。インフラの最前線であるエッジ（CDN）で敵を叩き潰せないシステムは、実戦では使い物にならない紙の鎧だ。

今日は、俺が数々の修羅場で見てきた泥臭いインシデントの現実を踏まえ、CloudFrontをはじめとするCDNを活用したエッジセキュリティの極意を叩き込む。
ジオブロッキングの裏をかく攻撃者の手口、IPレピュテーションの限界、そして最も厄介な「キャッシュ汚染（Cache Poisoning）」をどう封じ込めるか。現場でそのまま使える設定とコードを交えて徹底的に解説する。耳の穴をかっぽじってよく聞けよ。

—

1. なぜ「オリジン直通」を完全に断たなければならないのか

現場で最も多い致命傷は、CDNを導入しているにもかかわらず、オリジンサーバー（EC2やGCEなど）のセキュリティグループが世界中（0.0.0.0/0）からのアクセスを許可している状態だ。

攻撃者は、DNSの過去のレコードや、サブドメインの総当たり、あるいは情報漏洩した設定ファイルからオリジンサーバーの本当のIPアドレス（グローバルIP）を暴き出す。そして、CloudFrontを綺麗にバイパスして、直接オリジンをDDoS攻撃やSQLインジェクションで叩き潰す。

防御の鉄則：オリジン・シールドとアクセス制限

CloudFrontからオリジンへの通信には、必ず AWS-Kestrel のようなマネージド・プレフィックスリスト（またはカスタムヘッダー）を用いた厳格な制限をかけろ。オリジンサーバー（Nginxを想定）は、CloudFrontのエッジからの通信以外は一切受け付けないように設定する。

以下のNginx設定を見てみろ。CloudFront経由のアクセスであるかを検証し、直接叩いてくる輩は問答無用で 403 Forbidden に叩き落とす設定だ。

# /etc/nginx/conf.d/secure_origin.conf

# CloudFrontからのリクエストであることを証明するカスタムヘッダーを検証
map $http_x_origin_verify $is_from_cloudfront {
    "1a2b3c4d-Secure-Secret-Token-XYZ" 1;
    default 0;
}

server {
    listen 80;
    server_name api.example.com;

    # CloudFront経由ではない直アクセスを遮断
    if ($is_from_cloudfront = 0) {
        return 403;
    }

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

CloudFront側（マネジメントコンソールやTerraform）では、オリジンリクエストのカスタムヘッダーに X-Origin-Verify を仕込み、上の秘密のトークンを乗せて送るわけだ。これだけで、オリジン直撃型のアタックの9割は無力化できる。

—

2. 地理的制限（Geo-blocking）とIPレピュテーションの限界を知る

「うちのサービスは日本国内向けだから、海外からのアクセスは全部Geo-blockingで弾きます」
……よく聞くセリフだが、これだけではセキュリティ対策としては片手落ちだ。

攻撃者は、AWSやAzureなどのクラウド基盤、あるいは踏み台にした国内の住宅用プロキシ（住宅用IPプロキシ）を踏み台にして、いとも簡単に日本国内のIPアドレスになりすましてアタックしてくる。単なる「国コード（GeoIP）」でのブロックなど、プロやボットネットの前では紙の上の防壁にすぎない。

ここで頼りになるのが、AWS WAFが提供するIPレピュテーションリスト（Managed IP Reputation Lists）や、悪意あるボットを自動検知するマネージド・ルールグループだ。

CloudFront + AWS WAFでの実践的ブロック設定

AWS WAFでは、既知のボットネットや悪意あるスキャナーのIPリストをリアルタイムで更新し、エッジでドロップさせることができる。これをTerraformやCloudFormationでインフラストラクチャとしてコード化しておくのがプロのやり方だ。

# AWS WAFv2 WebACLのサンプル設定（Terraform）
resource "aws_wafv2_web_acl" "edge_shield" {
  name        "edge-security-shield"
  description "CloudFront edge protection against malicious bots and IPs"
  scope       "CLOUDFRONT"

  default_action {
    allow {}
  }

  # AWSのマネージドIPレピュテーションルール（既知の悪意あるIPをブロック）
  rule {
    name     "AWS-AWSManagedRulesAmazonIpReputationList"
    priority = 1

    override_action {
      none {}
    }

    statement {
      managed_rule_group_statement {
        name        "AWSManagedRulesAmazonIpReputationList"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "AWSManagedRulesAmazonIpReputationListMetric"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "EdgeSecurityShieldMetric"
    sampled_requests_enabled   = true
  }
}

エッジ（CloudFront）でこれらを弾くことで、オリジンサーバーのCPUやメモリを無駄なリクエスト処理で枯渇させずに済む。これがエッジセキュリティの真骨頂だ。

—

3. 最も恐ろしい脅威：キャッシュ汚染（Cache Poisoning）を防ぐ

お前たちが一番ハマりやすい、そして最も見落とされがちなのが「キャッシュ汚染（Web Cache Poisoning）」だ。

攻撃者は、アプリケーションが適切にハンドリングしていないHTTPヘッダー（例: X-Forwarded-Host やカスタムヘッダーなど）をリクエストに混ぜて送り込む。もしオリジンサーバーがそのヘッダーの値をそのままレスポンス（例えば、パスワードリセットのURLや動的JavaScript内）に反射してしまい、かつCloudFrontがそのヘッダーを「キャッシュのキー（Cache Key）」として認識していなかったらどうなるか？

攻撃者が細工した「悪意あるレスポンス」がCloudFrontにキャッシュされ、その後にアクセスしてきた無実の一般ユーザー全員に、その悪意あるコンテンツ（フィッシング誘導スクリプトなど）が配られてしまうのだ。これがキャッシュ汚染の悪夢だ。

対策：キャッシュキーの厳密な制御とVaryヘッダー

CloudFrontでは、キャッシュのキーに含める要素（HTTPヘッダー、クエリ文字列、クッキー）を明示的に指定する必要がある。不要なヘッダーはオリジンに転送しないか、キャッシュキーから完全に排除しろ。

さらに、PHPなどのアプリケーション側でも、動的に変化する内容やヘッダー依存のレスポンスを返す場合は、適切な Vary ヘッダーを出力するか、そもそもキャッシュさせないヘッダーを厳格に付与する必要がある。

以下は、PHPでの安全なヘッダー制御の実装例だ。

<?php
// security_headers.php
// 動的な処理やユーザー固有のセッションが含まれるページの実装例

// キャッシュ汚染を防ぐため、特定のプロキシヘッダーに基づくレスポンスの動的生成を排除し、
// プライベートキャッシュまたはキャッシュ無効化を明示する
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
header("Pragma: no-cache");

// アプリケーションが意図しないホストヘッダーの反射を防ぐため、
// ホスト名を厳格にハードコードまたはバリデーションする
$allowed_host = 'example.com';
$current_host = $_SERVER['HTTP_HOST'] ?? '';

if ($current_host !== $allowed_host) {
    // ホストヘッダーインジェクションの検知
    http_response_code(400);
    exit("Bad Request: Invalid Host Header");
}

// セキュリティヘッダーの基本装備
header("X-Content-Type-Options: nosniff");
header("X-Frame-Options: DENY");
header("X-XSS-Protection: 0"); // 現代のブラウザでは無効化しCSPを推奨
header("Content-Security-Policy: default-src 'self'; script-src 'self'");

echo json_encode([
    "status" => "success",
    "message" => "Secure response generated."
]);

CloudFrontの設定においても、オリジンリクエストポリシーやキャッシュポリシーで X-Forwarded-Host などの危ういヘッダーがキャッシュキーに意図せず混入しないよう、ポリシーをホワイトリスト方式で厳しく設計しろ。

—

4. 現場のシーフからの総括

セキュリティは「点」ではなく「面」で守るものだ。
アプリケーションのコードだけを綺麗に書いても、エッジであるCDNの設定がガバガバであれば、一瞬でシステム全体が乗っ取られる。逆に、WAFやCloudFrontでしっかりとスクリーニングを行い、オリジンへの無駄な負荷や不正なリクエストをシャットアウトできれば、バックエンドのエンジニアは本来のビジネスロジックの開発に集中できる。

いいか、明日からのスプリントでは、自分たちが構築しているCloudFrontのキャッシュポリシーとAWS WAFのルール、そしてオリジン側のアクセス制限がこの基準を満たしているか、必ずコードレビューの項目に入れろよ。

わかったら、さっそく作業に戻れ。何か不審なログを見つけたら、自分で抱え込まずにすぐに俺のところへ持ってこい。以上だ。

スポンサーリンク

コメント

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