固定IPだけ信じるな！AWS WAFのマネージドルールと組み合わせる防御設計
はじめに
AWS WAFでIP制限（Allow/Deny）を設定しているだけで「十分に守れている」と思っていませんか？
実際には、固定IP制限だけでは防げない攻撃が多く存在します。本記事では、AWS WAFのマネージドルール（Anonymous IP / Reputation IP）を活用した多層防御設計について、実例を交えて解説します。
対象読者：
- AWS WAFの導入を検討中、または運用中のインフラ・セキュリティ担当者
- 静的なIP制限に限界を感じている方
AWS WAFのルール構成と種類
AWS WAFでは、大きく分けて以下の2種類のルールを設定できます。
- カスタムルール：自分で条件を定義する（IP制限や文字列パターンなど）
- マネージドルール：AWSやサードパーティが提供するルールセット（サブスクリプション形式）
今回取り上げるのは以下の3種類のルールです：
| 種類 | 概要 |
|---|---|
| IP制限（Allow/Deny） | 特定IPからのアクセスのみ許可 or 拒否 |
| Anonymous IP list | VPN / プロキシ / Tor など匿名化サービスのIPを遮断 |
| Amazon IP reputation list | 過去に悪質な挙動を示したIP（スキャナー・ボットなど）を遮断 |
3つの防御レイヤーを理解する
レイヤー1：静的IP制限（Allow/Deny）
- 明示的に社内ネットワークなど「信頼できるIP」だけを許可
- アクセス元が固定のアプリや社内向けUIなどに有効
{
"IPSet": {
"Addresses": ["203.0.113.0/24"]
},
"Action": "ALLOW"
}
レイヤー2：Anonymous IP list
- TorやVPNなどを経由した匿名性の高いIPアドレスを自動で検出・遮断します。
- 主に以下のようなケースに有効です：
- ボットによるスクレイピング
- 匿名プロキシを使った偽装アクセス
- 地理的な回避手段を用いた不正利用
✅ 特徴：匿名化サービスの利用を自動識別するため、固定IPでの制御が難しいトラフィックに強い。
💡 Torとは？
Tor（The Onion Router）は、通信を多層の暗号化経路で中継することでユーザーのIPアドレスやアクセス元を匿名化するネットワークです。
例えば、攻撃者がTorを経由してアクセスすると、実際のIPアドレスが隠されてしまい、通常のIP制限では検知できません。
AWS WAFの「Anonymous IP list」は、このような匿名化技術（Tor、VPN、プロキシ等）を利用したアクセス元IPを自動で検出・遮断します。
レイヤー3：Amazon IP reputation list
- AWSがグローバルに収集した「悪質なIPアドレスのレピュテーションデータ」に基づき、攻撃元を遮断します。
- 主に以下のような攻撃に対応します：
- ボットによる自動攻撃
- DDoS攻撃
- スキャニングツールによる調査アクセス
多層防御におけるルール順と設計のポイント
AWS WAFではルールの評価順序が非常に重要です。
誤った順序でルールを適用すると、正当なアクセスが遮断されたり、逆に攻撃を通してしまう可能性があります。
✅ 推奨ルール順序の例
- Allow list（信頼済みIP）
- Anonymous IP list
- Reputation IP list
- その他のカスタム検知（例：SQLインジェクション、XSSなど）
- Default Action: Block
⚠️ 設計上の注意点
- Allowルールを上位に配置して、誤検知による遮断を防ぐ
- マネージドルールは初期は「Countモード」で導入し、安全性をログで確認
- ルールが多すぎるとパフォーマンスと料金に影響（特にCloudFront連携時）
ルール評価順序の図解（多層防御フロー）
以下は、WAFでアクセスを評価する際のルール順序のイメージです：
💡 Countモードを活用しながら CloudWatch Logs で効果を確認 → 問題なければ Block に切り替えるのが安全です。
よくある勘違いと落とし穴
| ❌ 誤解 | ✅ 実際には… |
|---|---|
| Anonymous IP listで完全に匿名アクセスを防げる | 一部のVPNや企業プロキシは対象外になる可能性あり |
| Reputation listを使えばすべての攻撃は防げる | Zero-day攻撃や新種のBotは検知されないことも |
| IP制限だけで十分 | クラウド環境やBotネットなどの動的なIPには非対応 |
AWS WAFルール構成の実装例（Terraform）
# Terraform (例) - CloudFrontと連携するWAF Web ACL
resource "aws_wafv2_web_acl" "example" {
name = "multi-layer-waf"
scope = "CLOUDFRONT"
default_action {
allow {}
}
rule {
name = "AllowTrustedIP"
priority = 1
action {
allow {}
}
statement {
ip_set_reference_statement {
arn = aws_wafv2_ip_set.trusted_ips.arn
}
}
visibility_config {
sampled_requests_enabled = true
cloudwatch_metrics_enabled = true
metric_name = "AllowTrustedIP"
}
}
rule {
name = "BlockAnonymousIP"
priority = 10
override_action {
count {} # 検証段階では count モードを推奨
}
statement {
managed_rule_group_statement {
name = "AnonymousIPList"
vendor_name = "AWS"
}
}
visibility_config {
sampled_requests_enabled = true
cloudwatch_metrics_enabled = true
metric_name = "BlockAnonymousIP"
}
}
rule {
name = "BlockBadReputationIP"
priority = 20
override_action {
count {}
}
statement {
managed_rule_group_statement {
name = "AmazonIpReputationList"
vendor_name = "AWS"
}
}
visibility_config {
sampled_requests_enabled = true
cloudwatch_metrics_enabled = true
metric_name = "BlockBadReputationIP"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
sampled_requests_enabled = true
metric_name = "multi-layer-waf"
}
}
まとめ
- IP制限は静的に信頼済みIPを管理するための手段
- Anonymous IP list / Reputation list は動的に変化する攻撃元の遮断に有効
- この2種類を組み合わせることで、ゼロトラスト的な多層防御を構築できる
- WAFルールの評価順序とCountモードでの検証導入が成功のカギ
参考リンク
おわりに
この記事では、AWS WAFを使った多層的なIP制御の設計パターンについて解説しました。
静的なIP制限に頼るだけでなく、AWSが提供するマネージドルールを活用することで、より柔軟かつ堅牢なセキュリティ対策が可能です。
WAFの構成見直しや初期導入時の参考になれば幸いです。
👍 記事が役に立ったら「いいね」やコメントをお願いします！