メインコンテンツへスキップ
テナントアクセス制御リスト (ACL) を使用すると、設定可能なルールで Auth0 サービスへのトラフィックを管理できます。これにより、サービス拒否 (DoS) 攻撃などの潜在的な脅威からテナントを保護し、レート制限の消費を抑えながら、正当なユーザーのみがアプリケーションにアクセスできるようにします。

仕組み

テナントまたはがリクエストを受信すると、テナント ACLがそのリクエストを処理し、設定したルールに基づいて応答方法を決定します。 たとえば、テナントでModel Context Protocols (MCP) を導入している場合は、dcr スコープを使用することで、不正なアプリケーション登録や、紛らわしいアプリケーション名を使ったフィッシングの試みといったリスクを回避できます。詳しくは、リファレンスを参照してください。

Rules

Rules は、テナント ACL 機能の基本構成要素です。Rule は、次の要素で構成されます。
  • シグナル: シグナルとは、IP アドレス、地理的位置情報、ユーザーエージェントなど、受信リクエストによって提供される識別情報です。
  • 条件: 条件は、演算子 (match など) と値のセット (IP アドレスのリストなど) を組み合わせたものです。
  • アクション: アクションは、条件が満たされた場合にRule が実行する動作を示すもので、許可、ブロック、リダイレクトなどがあります。
  • スコープ: スコープは、Authentication API、Management API、またはテナント全体など、そのRule が適用されるエンドポイントの範囲を示します。
  • 優先度: 優先度は、他のRule との関係において、そのRule が実行される順序を定義します。

優先度の重要性

従うべき厳格な実行ロジックがあるため、Rule の優先度を正しく設定することが重要です。
  • 評価順序: テナント ACL は Rule を優先度の数値が小さい順に評価し、小さい数値の Rule から先に実行します。たとえば、優先度 1 の Rule は優先度 2 の Rule より先に実行され、優先度 3 の Rule は優先度 4 の Rule より先に実行されます。
  • 一致時の終了: Rule の条件が満たされると、テナント ACL はその Rule のアクションを直ちに実行し、後続の Rule やリストは評価しません。​
  • モニタリングモードの例外: Rule の条件が満たされても、その Rule がモニタリングモードの場合、テナント ACL はアクションを実行せず、次の Rule に進みます。
優先度を慎重に設定することで、ニーズに応じたきめ細かなアクセス制御ポリシーを作成できます。

監視モード

Rule が監視モードの場合、Tenant ACL はそのRule を通常どおり評価してテナントログイベントを発行しますが、Rule のアクションは実行せず、後続のルールやリストの評価も終了しません。 監視モードは、現在の Tenant ACL 設定に影響を与えることなく、Tenant ACL Rule が受信トラフィックにどのような影響を及ぼすかをテストするための最適な方法です。 Rule の監視モードは、action オブジェクトを更新することで切り替えられます。詳しくは、ルールの設定を参照してください。

ログ

各テナント ACL Rule について、その Rule がトラフィックにどのような影響を与えているかの詳細を含むログイベント (acls_summary) が 10 分ごとに生成されます。
acls_summary
object

制約と制限事項

  • Enterprise プランをご利用のお客様は、テナント ACL を 1 つ作成できます。
  • Attack Protection アドオンを含む Enterprise プランをご利用のお客様は、テナント ACL を最大 10 個作成できます。
  • 各テナント ACL には、ソース識別子ごとに最大 20 件のエントリを含めることができます (IPv4、CIDR など) 。
  • セルフマネージドのカスタムドメインを使用している場合、ユーザーエージェント 識別子はサポートされません。
  • auth0-fowarded-for ヘッダーはサポートされません。

詳細情報