ルールセキュリティのベストプラクティス

Auth0のルールセキュリティに関するベストプラクティスについて説明します。

RulesとHooksのサポート終了（EOL）日は2026年11月18日 であり、2023年10月16 日の時点で作成された新しいテナントは使用できなくなります。Hooksが有効な既存のテナントは、サポート終了までHooksを利用できます。

今後はActionsに移行して、Auth0の機能を拡張することを強くお勧めします。Actionsを使用すると、豊富な情報やインラインドキュメント、パブリックnpmパッケージにアクセスして、外部統合を使って全体的な拡張エクスペリエンスを強化することができます。Actionsの詳細については、「Auth0 Actionsの仕組みを理解する」をお読みください。

当社では、移行の参考資料として、RulesからActionsへの移行とHooksからActionsへの移行に関するガイドを提供しています。また、専用の「Actionsへの移行」ページでは、機能の比較やActionsのデモ、その他のリソースを掲載して、円滑な移行をサポートしています。

RulesとHooksの廃止の詳細については、当社のブログ記事「RulesとHooksの提供終了について」をお読みください。

HTTPSを常に使用する

外部サービスへの呼び出しを行ったり、ルール実装の一部としてリダイレクトを実行したりする場合は、HTTPでなく、HTTPSを必ず使用します。

セキュリティ上重要な値をルール設定に保存する

資格情報やAPIキーなどセキュリティ上重要な情報はルール設定に保存します。ルール設定では、情報は難読化や暗号化され、configurationオブジェクトを介して利用することができます。これらの値をリテラルの値としてルールコードに保存しないでください。たとえば、以下のようなコードは書き込まないでください。

const myApiKey = 'abc123';

代わりに、configurationオブジェクトを介してアクセスできるよう、（シークレット）情報を保存することを推奨します。

const myApiKey = configuration.myApiKey;

contextオブジェクト全体を外部サービスに送信しない

外部サービスに情報を送信するルールでは、contextオブジェクト全体を送信しないようにしてください。このオブジェクトにはトークンやその他の機微データが含まれているためです。外部サービスに情報を送信するルールでは、contextオブジェクトから機微度が低い属性のサブセットのみを必要な時間に必要な場所に送ります。

同様に、auth0オブジェクトの側面をルール外に渡すことは避けます。

メールが確認済みかどうかチェックする

ユーザーのメールアドレスがルールで確認済みであるかどうかチェックすることができます。

function (user, context, callback) {
      // Access should only be granted to verified users.
      if (!user.email || !user.email_verified) {
    return callback(new UnauthorizedError('Access denied.'));
      }
    	  .
    	  .
    }

ただし、ユーザーが属する会社に応じて異なるコードを実行したい場合は、メールドメインでなく、認証を行ったIDプロバイダーにユーザーをリンクすることができるデータを使用する必要があります（接続またはAzureのtenant idなどIDプロバイダー固有のフィールドなど）。

文字列の完全一致を確認する

メールドメインなど特定の文字列に基づいてアクセス制御を決定するルールでは、サブ文字列の一致でなく文字列の完全一致を確認します。サブ文字列のみを確認する場合、ルールが意図したように機能しないことがあります。以下に例を示します。

if( _.findIndex(connection.options.domain_aliases, function(d){ return user.email.indexOf(d) >= 0;

上のコードは、次のようなメールが与えられている場合、trueを返します。

• [e-mail]
• “[e-mail]”@not-domain.com（引用符を含む）

上のメールは好ましくない例です。代わりに、次のようなコードを使って完全一致を実行してください。

const emailSplit = user.email.split('@'); const userEmailDomain = emailSplit[emailSplit.length - 1].toLowerCase();

詳細については、GitHub「ユーザーのメールドメインが構成されたドメインのルールテンプレートに一致するかどうか確認する 」を参照するか、［Auth0 Dashboard］>［Auth Pipeline（Authパイプライン）］>［Rules（ルール）］の順に移動し、［Create（作成）］ を選択します。

多要素認証のコンテキストに基づいたバイパス

多要素認証（MFA）には、不正アクセスから身を守るための追加のセキュリティが導入されています。ユーザーエクスペリエンスの観点から、これには通常、ユーザーが別の認証要素（他の資格情報を提示したり、何らかの形態のアクセス要求を認可したりする）を提出することが必要となります。

それでも、状況によっては、多要素認証が必要であると判断されたユーザーがMFAをバイパスしたほうが望ましいケースもあります。たとえば、ユーザーが現在のブラウザーコンテキストで認証の一部としてプライマリとセカンダリの両方の要素をすでに提出している場合は、MFAをバイパスしてもよいでしょう。このようにコンテキストに基づいて確認することで、ユーザーエクスペリエンスの向上に役立ちます。しかし、適切に行わないと、セキュリティ上の重大な抜け道が生じ、MFAがスキップされたことで、この後セキュリティ侵害が発生する可能性があります。このため、コンテキストに基づいてMFAをバイパスするかどうかを判断する上で、以下のガイドラインを守られることを推奨します。

推奨されるベストプラクティスとして、用意されているMFAを使用するときにコンテキストに基づいてバイパスを検討する場合、使用するべきオプションはallowRememberBrowserまたはcontext.authenticationのみです。allowRememberBrowserをtrueに設定すると、MFAが定期的にしか求められないように、ボックスにチェックマークを入れることができます、その一方で、context.authenticationを安全かつ正確に使用し、MFAが現在のブラウザーコンテキストで最後にいつ実行されたのかを特定することができます。用意されている指定されたルール（Require MFA once per session）でcontext.authenticationのサンプルユースをいくつか閲覧することができます。

• Do not perform MFA bypass ：サイレント認証に関連する条件ロジックに基づく（context.request.query.prompt === 'none'など）
• Do not perform MFA bypass ：何らかの形態のデバイスフィンガープリンティングを使った条件ロジックに基づく（ここでは、user.app_metadata.lastLoginDeviceFingerPrint === deviceFingerPrint）
• Do not perform MFA bypass ：地理的場所を使った条件ロジックに基づく（ここでは、user.app_metadata.last_location === context.request.geoip.country_code）

カスタムMFAプロバイダー使用時のコンテキストに基づいた確認

すでに説明したのと同じように、ユーザーをカスタム多要素認証プロバイダーにリダイレクトするルールに対して、上記の項目で示したガイダンスに従うことを推奨します。たとえば、カスタムプロバイダーの場合、サイレント認証中はMFAを効果的にバイパスする安全な方法はありません。これは、リダイレクト（カスタムMFAで必須）はサイレント認証時に必ず失敗するからです。

もっと詳しく

• ルールの構造に関するベストプラクティス
• ルール環境のベストプラクティス
• ルールの実行に関するベストプラクティス
• ルールのテストに関するベストプラクティス
• セキュリティ保護