こんにちは！インフラやセキュリティの世界へようこそ。
初めてAWSのセキュリティ設定やファイアウォール（WAF）に向き合うとき、画面に並ぶたくさんの専門用語に圧倒されてしまいますよね。「何から手をつければいいんだろう…」と不安になるかもしれませんが、安心してください。一歩ずつ、身近な例えから紐解いていきましょう！
今回は、クラウドの守りの要である「AWS WAF（Web Application Firewall）」を取り上げます。特に、AWSが用意してくれた強力な盾である「マネージドルールセット」の選び方と、自分たちのビジネスを守るための「カスタムルールの優先順位設計」について、現場のプロの視点も交えながら優しく解説していきますね。
—
1. Webのセキュリティって、家で例えるとどういうこと？
まずは、私たちが普段作っているWebサイトやアプリを「一軒家」に例えて考えてみましょう。
- ネットワーク・OS層のファイアウォール（Security GroupやNACL）:
家の周りの「頑丈な塀」や「施錠された門」のようなものです。不審者が敷地に入ってくるのを防ぎますが、玄関のドアの鍵まではカバーしていません。
- AWS WAF（Web Application Firewall）:
これは、家で言うところの「玄関に立っている優秀なスマート執事（または警備員）」です。
泥棒（サイバー攻撃者）は、ただ力任せにドアを蹴破るだけではありません。時には、宅配業者を装って巧妙な嘘をついたり（SQLインジェクション）、郵便受けから変な手紙を滑り込ませたり（クロスサイトスクリプティング）して家に侵入しようとします。
AWS WAFという執事は、お客様が持ってきた荷物や話す言葉の端々をチェックし、「おっと、その手紙は危ない内容が書かれているので中に入れてはいけませんね！」と、玄関先でピシャリと追い返してくれる頼もしい存在なんです。
—
2. AWSマネージドルールセットの選び方：プロの既製品をうまく使おう
AWS WAFには、世界中のセキュリティのプロが作った「攻撃パターンの見本帳」があらかじめ用意されています。これが「マネージドルール（Managed Rules）」です。
すべてを自前でゼロから作ろうとすると、毎日新しい攻撃の手口が生まれる現代では、到底追いつきません。ですから、基本的にはAWSや信頼できるセキュリティベンダー（Palo Alto NetworksやF5など）が提供してくれている既製品をうまく組み合わせるのが、現場のベストプラクティスです。
初心者がまず選ぶべき基本のマネージドルール
代表的なものをいくつか挙げてみましょう。これらはOWASP Top 10（Webアプリが狙われやすい代表的な弱点10選）にしっかり対応しています。
1. Core rule set (CRS):
SQLインジェクション（データベースを不正に覗き見・改ざんする攻撃）や、クロスサイトスクリプティング（悪意あるスクリプトを実行させる攻撃）など、あらゆる基本的な攻撃を防ぐ、いわば「総合防犯セット」です。まず最初にこれを入れておきます。
2. Known bad inputs:
過去に世間を騒がせた有名な攻撃コードや、明らかに怪しいゴミデータがリクエストに含まれていないかをチェックしてくれます。
3. SQL database:
データベースを直接狙い撃ちするような、特に狡猾なSQLインジェクションを集中的にブロックします。
ここで注意してほしいのは、「何でもかんでも全部のルールをONにすればいいというわけではない」ということです。厳しくしすぎると、正当なお客様が入力した「ちょっと変わった文字（例：特殊な記号や外国語など）」まで「怪しい！」と誤検知してブロックしてしまうことがあります（これを「False Positive（偽陽性）」と呼びます）。
まずは「Countモード（ブロックせずにログだけ記録するモード）」でしばらく動かしてみて、正規のユーザーの邪魔をしていないか確認してから「Blockモード」に切り替えるのが、実務でよく使われる安全な手順です。
—
3. カスタムルールの優先順位（Priority）設計：執事に仕事を頼む順番の秘密
マネージドルールという「一般的な防犯マニュアル」だけでは、自分たちの会社特有のビジネスやルールは守れません。例えば、「うちの会社の管理画面には、特定の社内ネットワークからしかアクセスさせたくない！」というときは、自分でルールを作る必要があります。これが「カスタムルール」です。
ここで非常に重要になるのが、「ルールの評価順序（Priority）」の設計です。
執事に「指示を出す順番」の重要性
AWS WAFは、上から順番にルールをチェックしていきます。そして、「どれか一つのルールにヒットした（＝ブロックまたは許可された）瞬間、その後のチェックは打ち切られる」というルールがあります。
家で例えるなら、優秀な執事に次のようなメモを渡している状態です。
- Priority 1: 「我が社の社員（特定のIPアドレス）からの荷物は、中身を見ずに無条件で通しなさい！」
- Priority 2: 「海外からの怪しいアクセスは、問答無用で追い返しなさい！」
- Priority 3: 「AWSのマネージドルール（CRS）で一般的な攻撃をチェックしなさい！」
もし、この順番を間違えて「Priority 1」と「Priority 2」を逆にしてしまったらどうなるでしょうか？せっかくの社員からのアクセスなのに、海外からのアクセス判定やマネージドルールの網に引っかかって、先に追い返されてしまうかもしれませんよね。
実務での優先順位設計の黄金ルール
インフラ現場で設計するときは、基本的に次のような順番で「Priorityの数値が小さい（＝優先度が高い）順」に並べるのが鉄則です。
1. ホワイトリスト（例外的な許可）: 社内IPや特定の信頼できるパートナー企業のIPなど、絶対にブロックしてはいけないものを最優先で通す。
2. ブラックリスト（即座の拒否）: 過去に何度も攻撃を仕掛けてきた、明らかな悪意あるIPアドレスや国単位の制限などを弾く。
3. アプリケーション固有のカスタムルール: 「特定のログインパスに、1秒間に何回もアクセスが来たらブロックする（ブルートフォース攻撃対策）」など、自分たちのアプリ特有のロジックをチェックする。
4. AWSマネージドルール（CRSなど）: 一般的なWeb脆弱性への対策。
—
4. 実設定のイメージ（Terraformのコード例）
では、実際にインフラのコード（Infrastructure as Code）を書くとき、どのように設定されるのかを見てみましょう。ここでは、代表的なツールであるTerraformを使った設定イメージをご紹介します。
# AWS WAFのWebACL（ルールグループ全体の入れ物）の定義
resource "aws_wafv2_web_acl" "example" {
name = "my-secure-web-acl"
scope = "REGIONAL" # CloudFrontなら "CLOUDFRONT" に変更します
description = "初心者にも安心なセキュリティ設定のサンプル"
default_action {
allow {} # デフォルトは「通す（許可する）」。怪しいものだけをWAFで弾きます。
}
# --- ルール1: 【最優先】社内IPからのアクセスは無条件で許可するカスタムルール ---
rule {
name = "AllowTrustedOfficeIPs"
priority = 10 # 数字が小さいほど優先されます！
action {
allow {}
}
statement {
ip_set_reference_statement {
arn = aws_wafv2_ip_set.trusted_office.arn
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "AllowTrustedOfficeIPsMetric"
sampled_requests_enabled = true
}
}
# --- ルール2: 一般的な脆弱性を防ぐAWSマネージドルール ---
rule {
name = "AWS-AWSManagedRulesCommonRuleSet"
priority = 20 # 社内IPの次、2番目にチェックされます
override_action {
none {} # マネージドルール自体のデフォルト動作（基本はブロック）に従います
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesCommonRuleSet"
vendor_name = "AWS"
# 例：特定のルールで誤検知が多い場合、そのルールだけ除外する設定も可能です
excluded_rule {
name = "SizeRestrictions_BODY" # 例としてボディのサイズ制限ルールを除外する場合
}
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "AWSManagedRulesCommonRuleSetMetric"
sampled_requests_enabled = true
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "MyWebACLMetric"
sampled_requests_enabled = true
}
}
# 許可する社内IPアドレスのリスト（IP Set）
resource "aws_wafv2_ip_set" "trusted_office" {
name = "trusted-office-ips"
scope = "REGIONAL"
ip_address_version = "IPV4"
addresses = ["203.0.113.50/32"] # ここにオフィスのグローバルIPなどを書きます
}この設定を見ていただくとわかる通り、priority というパラメータで「どちらを先に評価するか」が明確にコントロールされています。
—
5. まとめ：焦らず、ログを見ながらチューニングを楽しもう
AWS WAFの導入は、一度設定して終わりではありません。むしろ、運用が始まってからの「ログの確認」と「チューニング」が一番の醍醐味です。
- 最初はマネージドルールを
Countモードにして、正当なお客様のアクセスを誤って遮断していないかCloudWatchのログやメトリクスで確認する。 - 自分たちのビジネスルール（社内IPや特例など）は、
priorityを若く（小さく）して一番最初に評価させる。 - 不安なときは小さな変更から少しずつ適用していく。
セキュリティの対策は、まるで丹精込めてお庭の手入れをするようなものです。一歩ずつ、仕組みを理解しながら強固なシステムを作っていきましょう。あなたのインフラストラクチャが、安全で快適な場所になることを応援しています！
コメント