AWS WAFに含まれるルールはそのpriorityによって適用順序が変わる。
この適用順序というものは重要で、例えば
- IaaS系のIPのブロックルール
- 社内の関係システムからのアクセスの許可ルール
という2つのルールがあった場合、前者が先に適用されてしまうと社内の関係システムからのアクセスが許可されなくなってしまう。
幸い、このルールのpriority変更はACL作成後も変更できるが、ある程度priorityの付け方に方針が定まっていると付けやすい。
そこで、ここではpriorityレンジ帯の基本設計をメモしておく。
注意点
この設計方針はあくまで原則
この記事での設計は基本的に許可(allow)と拒否(block)をpriorityレンジ帯ごとにまとめて書くことにしているが、この方針に完璧に沿おうとすると書けないルールがある。
例えば、社内からのアクセスのうち、特定のURIパスに対しては拒否したい、と言った許可と拒否が複雑に織り込まれているケースなどがそれに当たる。
そのため、以下はあくまで基本の方針として個別の事情に合わせて運用すること。
(自分向けのメモ) 上記の例外が頻発する箇所は、設計原則を更新するべき箇所の可能性が高い。適時アップデートを検討すること。
この設計メモは今後もアップデートされる可能性が高い
この設計方針は基本的に経験則に基づいたベストプラクティスであり、かつ、僕自身その経験が豊富とは言えない。
そのため、今後の経験でこのメモはアップデートされる可能性が高い。
priorityレンジ帯
0 ~ 999 システム横断で共通の許可
原則許可するアクセス。
主に社内IP・VPNのIPなど。
ここに配置する意図
BotアクセスやHosting Providerブロックなどより先に書かないとそちらに引っかかって拒否されてしまうため。
また、共通性が高いものをシステム固有のものより先に書くことで比較や視認をしやすくしている。
1000 ~ 1999 システム固有の許可
システム固有の理由で許可したいアクセス。
APIをコールする元のIPの許可など。
ここに配置する意図
BotアクセスやHosting Providerブロックなどより先に書かないとそちらに引っかかって拒否されてしまうため。
また、システム固有のものを共通性が高いものより後に書くことで比較や視認をしやすくしている。
2000 ~ 2999 システム横断で共通の拒否 (マネージドルールグループ)
原則拒否するアクセスでマネージドルールグループのもの。
主にIP 評価ルールグループやベースラインルールグループ、ユースケース固有のルールグループなど。
ただしBot Controlは除く。
ここに配置する意図
共通性が高いものをシステム固有のものより先に書くことで比較や視認をしやすくしている。
3000 ~ 3999 システム横断で共通の拒否 (非マネージドルールグループ)
原則拒否するアクセスでマネージドルールグループでないもの。
基本的には少ないが、マネージドルールグループやBot Controlでも拒否しきれないBotアクセスなど。
ここに配置する意図
共通性が高いものをシステム固有のものより先に書くことで比較や視認をしやすくしている。
4000 ~ 4999 システム固有の拒否
システム固有の理由で拒否したいアクセス。
特定のパスへのアクセスを社内に限定してそれ以外のIPからのアクセスを拒否したり、AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループなど特定のユースケースのマネージドルールグループなど。
ここに配置する意図
システム固有のものを共通性が高いものより後に書くことで比較や視認をしやすくしている。
5000 ~ 5999 Bot Controlの許可・拒否
AWS WAF Bot Control ルールグループと、それに伴う許可・拒否。
ここに配置する意図
Bot Controlは処理対象のリクエストによって課金が発生するため、なるべくここに到達するリクエストを減らしたい。また、わかりやすい許可・拒否を先に行うことでBot Controlの統計からノイズを減らしている。
Discussion