こんにちは！クラウドの海を航海するエンジニアの皆さん、そしてこれからインフラの世界に飛び込もうとしている皆台。今日もパケットの行き先を追いかけていますか？
「ロードバランサーを立てたから、これでアクセスが分散されて一安心！」……そう思っていた時期が私にもありました。しかし、インターネットという広大な公道に面した入り口（エンドポイント）を公開するということは、世界中の「招かれざる客」からも丸見えになるということです。
今回は、AWSのロードバランサーの中でも特に「知的な振る舞い」が得意なALB（Application Load Balancer）と、その強力な相棒であるAWS WAFについて解説します。
「WAFって何だか難しそう……」「パケットの中身を見るってどういうこと？」そんな不安を抱えている方も大丈夫です。今回は、私たちの身近な「郵便配達」や「ホテルの受付」に例えながら、その仕組みを丁寧に紐解いていきましょう！
—
1. ALBは「手紙の中身を読める」受付嬢
AWSには、NLB（Network Load Balancer）やGLB（Gateway Load Balancer）など、いくつかのロードバランサーが存在します。その中でなぜ「ALB」がセキュリティの要になるのでしょうか。
それは、ALBが「HTTP/HTTPS（L7）」という言葉を理解できるからです。
例えるなら、NLBは「封筒の宛先（IPアドレス）だけを見て、機械的に仕分けする高速な郵便局員」です。中身が何であれ、とにかく速く届けます。
一方でALBは、「手紙の内容（URL、ヘッダー、クエリ、本文）までしっかり読み込み、宛先を決めるホテルのコンシェルジュ」のような存在です。
この「中身が読める」という特性があるからこそ、その隣に「検閲官」であるAWS WAFを立たせることができるのです。
—
2. AWS WAFという「凄腕の検閲官」
ALBのフロントエンドでAWS WAFを有効化すると、すべてのリクエスト（お手紙）は、ALBが後ろのサーバー（ターゲットグループ）に渡す前に、必ずWAFのチェックを受けることになります。
このチェックプロセスを、3つの主要な防衛策で見ていきましょう。
① SQLインジェクション防御：手紙に「爆弾の設計図」がないか？
SQLインジェクションは、入力フォームなどにデータベースを操作する不正なコマンド（OR 1=1 など）を紛れ込ませる攻撃です。
WAFは、リクエストの中身をスキャンして、「おや、この文章にはデータベースを壊すような怪しい命令文が含まれているぞ」と気づき、その場で手紙を破棄（ブロック）してくれます。
② XSS（クロスサイトスクリプティング）防御：他のお客さんを騙そうとしていないか？
XSSは、サイトを訪れた他のユーザーのブラウザで勝手にプログラムを動かそうとする攻撃です。
WAFは、リクエストの中に script タグのような、Webサイトの見た目や挙動を勝手に変えてしまうコードが隠れていないかを厳重にチェックします。
③ レートリミッティング：短時間に1万通の手紙を送りつけていないか？
これが現場で最も重宝する機能の一つです。「同じ人（IPアドレス）から5分間に1000回以上のアクセスがあったら、しばらくの間その人を門前払いする」といったルールが作れます。
これは、サーバーがパンクするのを防ぐだけでなく、悪意のある大量アクセス（DDoS攻撃の初期段階など）からサイトを守る強力な盾になります。
—
3. 実践！AWS WAFをALBに紐付ける設定イメージ
では、実際にどのように設定するのか、IaC（Infrastructure as Code）のデファクトスタンダードである Terraform のコードを例に見てみましょう。
「コードなんてまだ早いよ！」という方も、コメント部分を追うだけで「何をしようとしているのか」が分かるはずです。
# 1. まずは「Web ACL」という防衛ルールのルールブックを作ります
resource "aws_wafv2_web_acl" "my_web_acl" {
name = "my-security-gate"
description = "ALBを守るための最強の門番"
scope = "REGIONAL" # ALBに適用する場合はREGIONAL、CloudFrontならCLOUDFRONT
default_action {
allow {} # 基本的には「通す」設定にして、特定の条件だけブロックします
}
# ルールその1：SQLインジェクションを防ぐ
rule {
name = "PreventSQLi"
priority = 1 # 優先順位。数字が小さいほど先にチェックされます
override_action {
none {} # ブロックを有効にする
}
statement {
sqli_match_statement {
field_to_match {
all_query_arguments {} # URLの?以降（クエリ）を全部チェック
}
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "PreventSQLiMetric"
sampled_requests_enabled = true
}
}
# ルールその2：レートリミッティング（5分間に500回以上のアクセスを制限）
rule {
name = "RateLimitRule"
priority = 2
action {
block {} # 制限を超えたらブロック！
}
statement {
rate_based_statement {
limit = 500
aggregate_key_type = "IP" # IPアドレスごとに集計します
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "RateLimitMetric"
sampled_requests_enabled = true
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "OverallWAFMetric"
sampled_requests_enabled = true
}
}
# 2. 最後に、作ったルールブックをALB（Arnで指定）に貼り付けます！
resource "aws_wafv2_web_acl_association" "example" {
resource_arn = aws_lb.my_alb.arn # あなたのALBのID
web_acl_arn = aws_wafv2_web_acl.my_web_acl.arn
}—
4. 現場の知恵：いきなり「ブロック」してはいけない
ここで、SRE（サイト信頼性エンジニア）としての泥臭いアドバイスを一つ。
WAFを導入する際、いきなり全ての攻撃を Block（遮断）に設定するのは非常に危険です。なぜなら、「正常なユーザーの操作を、誤って攻撃と判定してしまう（誤検知）」ことがよくあるからです。
例えば、ユーザーが一生懸命書いたブログ記事の本文に、たまたまSQLのようなキーワードが含まれていて、投稿ボタンを押した瞬間に「お前は攻撃者だ！」と追い出されてしまったら悲しいですよね。
そこで、最初は Count モード（カウントモード）を使いましょう。
これは「もしこのルールを適用していたらブロックしていたけど、今回は見逃して記録だけしておくね」という、いわば「シミュレーションモード」です。
数日間ログを眺めて、誤検知がないことを確認してから、満を持して Block へ切り替える。これが、プロが現場で実践する安全な導入ステップです。
—
まとめ：一歩ずつ理解していきましょう！
「AWS WAFとALBの連携」と聞くと難しく感じますが、その本質は「大切なWebサイトという家を守るために、門（ALB）に優秀な検閲官（WAF）を立たせ、手紙の内容を一つずつ丁寧にチェックしてもらう」という、とてもシンプルなセキュリティの考え方に基づいています。
1. ALB はアプリケーションの中身（L7）がわかる。
2. WAF はその中身を見て、SQLi、XSS、大量アクセスなどを検閲する。
3. まずは Countモード でテストして、安全を確認してから運用する。
この3点さえ押さえておけば、あなたの構築するシステムはぐっと堅牢になります。パケットの一つ一つに込められたユーザーの思いを安全にサーバーに届けるために、ぜひこの「最強のコンビ」を活用してみてくださいね。
これからも、一歩ずつ一緒にインフラの深淵を楽しんでいきましょう！
コメント