Auth0 の Tenant ACL を設定してみる ─ ログイン画面が表示される前のリクエストを止める
こんにちは。
ゲームソリューション部/業務効率化ソリューション部の西川です。
今回はAuth0のTenant ACLを検証用テナントで設定し、自分のIPアドレスからのリクエストをログイン画面が表示される前に止めるところまで試してみました。
はじめに
背景
分散した多数のIPからログイン画面や/authorizeへのアクセスが続くと、IPを1つずつ拒否する運用では追いつきません。前段にCDNやWAFを置いていても、そこを通り抜けるリクエストは残ります。
Auth0の標準の防御であるBot DetectionとSuspicious IP Throttlingは、認証情報の検証が発生するタイミングで働きます。画面が表示される前のリクエストには当たりません。この段階で止められるのがTenant ACLです。
Tenant ACLとは
Tenant ACLは、テナントへのリクエストをIPアドレス、国、ASN、ユーザーエージェントなどの条件で評価し、一致したリクエストにブロック・許可・ログ・リダイレクトのいずれかを実行する機能です。
試した環境
- Auth0の検証用テナント（デモ環境）
- 管理画面は日本語表示、2026年11月時点
- ブラウザから管理画面のみ操作（Management APIは呼んでいません）
- 画像に写るIPアドレスは、自分のIPアドレスをドキュメント用の
203.0.113.10に置き換えて掲載しています
作れるTenant ACLの数はプランで変わります。Enterpriseプランで1つ、EnterpriseプランにAttack Protectionアドオンを足すと最大10です。後述するCurated Blocklistsを使えるのはAttack Protectionの契約がある場合です（Tenant Access Control List、Use Curated Blocklists）。
やってみた
アクセス制御の画面を開く
左メニューの「セキュリティ」を開くと「アクセス制御」があります。プランによってはこの項目自体が出ないので、まずここを確認します。
開くと「カスタムリスト」の一覧です。列は優先度、名前、アクション、ステータス、最終更新日の5つで、ルール1本が1行にあたります。
ルールを作成する
右上の「作成」を押すと、入力欄は名前とアクションとスコープの3つだけです。条件はここでは指定しません。
アクションは「ブロック」「許可」「ログ」「リダイレクト」の4つ、スコープは「テナント」「認証」「管理」「動的クライアント登録」の4つから選べます。
既定値はアクションが「ブロック」、スコープが「テナント」です。スコープのテナントは管理APIも含むため、そのまま作ってブロックの条件を当てると、管理画面やデプロイ用のAPIまで止まる組み合わせになります。ログイン画面への対策として作るなら、スコープは「認証」です。
今回はアクションを「ブロック」のまま、スコープを「認証」にして作成しました。
条件を追加する
作成すると、ルールの編集画面に移ります。条件は「タイプ」「ソース識別子」「値」の3つを選んで追加します。タイプは一致と不一致、ソース識別子は次の12種類です。括弧内はAPIのキー名です。
| 管理画面の表示 | APIのキー |
|---|---|
| ASN | asns |
| 地理的国コード | geo_country_codes |
| 地理的行政区画コード | geo_subdivision_codes |
| IPv4 CIDR | ipv4_cidrs |
| IPv6 CIDR | ipv6_cidrs |
| IPv4 CIDRへの接続 | connecting_ipv4_cidrs |
| IPv6 CIDRへの接続 | connecting_ipv6_cidrs |
| JA3フィンガープリント | ja3_fingerprints |
| JA4フィンガープリント | ja4_fingerprints |
| ユーザーエージェント | user_agents |
| ホスト名 | hostnames |
| キュレーション済みブロックリスト | auth0_managed |
「キュレーション済みブロックリスト」を選ぶと、値の欄が自由入力からプルダウンに変わり、Auth0が維持している5本のリストから選ぶ形になります。
| 管理画面の表示 | APIの値 |
|---|---|
| 低レピュテーションIP | auth0.low_reputation |
| プロキシ | auth0.proxy |
| Tor出口ノード | auth0.tor |
| VPN | auth0.vpn |
| iCloud Private Relay | auth0.icloud_relay_proxy |
このうちVPNとiCloud Private Relayの2本には、一般の利用者が日常的に通る経路が入ります。社用VPNからサインインする社員や、iCloud Private Relayを有効にしている利用者がいれば、ブロックに当てた時点でその人たちのサインインが落ちます。
なお、Attack Protectionの契約がないテナントでも、この選択肢はプルダウンに出て、条件の行まで追加できます。保存しようとした時点でエラーになるので、先にプランを確認しておくと手戻りがありません。
今回は止まったことを自分で確認できるように、ソース識別子に「IPv4 CIDR」を選び、自分のIPアドレスを/32で追加して保存しました。
コード表示で中身を確認する
編集画面には「表」と「コード」の2つのタブがあります。コードに切り替えると、今の設定を作るためのcurlがそのまま出ます。
curl --request POST \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <jwt with create:network_acls>' \
--url 'https://<テナント名>.auth0.com/api/v2/network-acls' \
--data '{
"description": "自分のIPをブロック",
"active": false,
"rule": {
"action": {
"block": true
},
"scope": "authentication",
"match": {
"ipv4_cidrs": [
"203.0.113.10/32"
]
}
}
}'
画面で組んでからコードを写せば、TerraformやCIに載せるときの形がそのまま手に入ります。既存のルールを開いた場合は、同じタブにPATCH /api/v2/network-acls/{id}の形で出ます。
なお、このボディにpriorityは入りません。画面には優先度が表示されていますが、リクエストの本文とは別に扱われています。
ルールを有効にする
保存しただけでは、ステータスは「無効」のままです。コードタブにも"active": falseと出ており、このままではリクエストは評価されません。
「リストの設定」を開き、リストのステータスを「アクティブ」にして「適用」を押します。
ステータスが「有効」に変わりました。
ログイン画面へのリクエストが止まるか確かめる
ルールを作る前に、ホーム画面の「ログインボックス」にある「試してみる」からログイン画面を開くと、通常どおり表示されていました。
ルールを有効にしたあとに開き直すと、ログイン画面の代わりに「Access denied.」のページが返りました。ページには、ブロックされたIPアドレスとRequest IDが表示されます。
有効にした直後に開いたときは、まだログイン画面が表示されました。有効にしてから2〜3分ほどあとに開き直したところでブロックされたので、設定が反映されるまでに少し時間がかかるようです。
スコープを「認証」にしているので、同じIPアドレスからでも管理画面の操作は続けられました。
分かったこと
優先度は数値の小さいものから
「リストの設定」では、ステータスのほかに名前、アクション、優先度、スコープも変更できます。優先度の説明に「数値の小さいものから先に評価されます。」と書かれており、Rule Evaluationの記述と一致します。
最初に一致したルールのアクションが実行されて、そこで評価が終わります。許可とブロックのどちらが優先されるという決まりはないので、オフィスのIPを通す許可のルールは、ブロックのルールより小さい優先度にしておく必要があります。
前段のWAFとどちらで止めるか
同じことは前段のCDNやWAFでもできます。
利用者に近い側で止めるほうが、Auth0に届くリクエスト自体が減り、レートリミットの消費も抑えられます。前段で止めるのを主にして、Tenant ACLはそこを通り抜けたぶんに当てる。この置き方が素直です。
ただし、JA3/JA4を条件にした拒否は、どちらの層に置いても攻撃側が値を変えれば当たらなくなります。指定した値を追い続ける運用より、Auth0やCDN側が更新するリストに寄せるほうが、手間の面では現実的です。
さいごに
Auth0のTenant ACLを検証用テナントで試してみました。管理画面で条件を組むと、同じ設定を作るcurlがコードタブに出るので、TerraformやCIに載せるときの形も確認しやすいです。
今回のポイントをまとめると次の通りです。
- 自分のIPアドレスをブロックするルールを有効にすると、ログイン画面の代わりに「Access denied.」のページが返り、ログイン画面が表示される前に止まった
- 作成直後のルールは無効なので、「リストの設定」でアクティブにする必要がある
- 有効にしてからブロックされるまで、2〜3分ほどかかった
- 作れるルール数とCurated Blocklistsを使えるかどうかはプランで変わる
- 評価は優先度の数値が小さいルールから行われ、最初に一致したルールで終わる
導入するときは、先にプランでCurated Blocklistsとルール数の上限を確認しておくと、条件を組んだあとに作り直さずに済みます。いきなりブロックにせず、アクションをログにしたルールで一致件数を何日か確認し、正規の利用者が当たっていないと判断できてからブロックに変えると、サインインを落とさずに済みます。
本記事がAuth0のTenant ACLを検討中の方のご参考になっていれば幸いです。
