ユースケース
- 1台のサーバーで管理画面アプリケーションと外部公開用APIサーバーの両機能が備わっている場合など（apiに制限はかけたくないが、管理画面にかけたいというシチュエーション）
どーやるの
◾️ 流れ
- ipのホワイトリストを作成（aws_wafv2_ip_set）
- Web ACLを作成（aws_wafv2_web_acl）
-
aws_wafv2_web_aclのリソースの定義において、「特定のipは許可する」、「特定のドメインへのアクセスをブロックする」という定義をrulesブロックにて、
priorityの重み順に実装する。これによりpriorityの若い数値で、「特定のipは許可する」という実装になっているため、この数値よりも高い数値のpriorityとして、特定ドメインのblockという定義を行なっているので、前述したruleの方が優先される。
WebACLで複数のルールを定義する場合、AWS WAFは
rules、の値に基づいて順番に各リクエストを評価しますpriority。AWS WAFは、優先度の低いルールを最初に処理します。
◾️ Terraformに書き起こすと
例）waf.tf
ipのホワイトリスト
resource "aws_wafv2_ip_set" "example" {
name = "example"
description = "Example IP set"
scope = "REGIONAL"
ip_address_version = "IPV4"
addresses = ["1.2.3.4/32", "5.6.7.8/32"]
tags = {
Tag1 = "Value1"
Tag2 = "Value2"
}
}
WebACLのterraform定義 & 実装
※細かいブロック定義は割愛してます
resource "aws_wafv2_web_acl" "example" {
...
// ip許可の定義
rule {
name = "rule-1"
priority = 1
// statementの結果と一致した場合のアクション（この場合許可）
action {
allow {}
}
// 処理するステートメント （この場合ipとの一致を検証）
statement {
ip_set_reference_statement {
aws_wafv2_ip_set.example
}
}
...
// 特定ドメインblockの定義
rule {
...
// statementの結果と一致した場合のアクション（この場合拒否）
action {
block {}
}
// 処理するステートメント （この場合対象のドメインへのアクセスかどうかをチェック）
statement {
byte_match_statement {
field_to_match {
single_header {
name = "host"
}
}
positional_constraint = "EXACTLY"
search_string = "対象ドメイン名（admin.example等）"
text_transformation {
priority = 0
type = "LOWERCASE"
}
}
}
...
}
}
補足
- コンソールからであれば以下の記事で解説されてました。
https://dev.classmethod.jp/articles/waf-virtualhost-iprestrict/