運用担当者が Auth0 サービスのステータスを監視する方法を把握し、Auth0 のステータス更新を受け取れるように設定していることを確認してください。
Auth0 の status dashboard と Auth0 の uptime dashboard では、Auth0 サービスの現在および過去のステータスを人が読みやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの最初の手順として、運用担当者はステータスダッシュボードを確認し、現在障害が発生していないかを確認する必要があります。パブリッククラウドのステータスページでは障害通知の購読機能も提供されており、Social Providers など、依存しているサードパーティの 外部サービス のステータスも確認することを推奨します。この情報をすぐ参照できるようにしておくと、問題のトラブルシューティング時に考えられる原因をすばやく切り分けるのに役立ち、開発者だけでなくヘルプデスク担当者にとっても、トラブルシューティングチェックリストの最上位に置くべき項目になります。
ベストプラクティス Auth0 および依存サービス (Social Providers など) のステータス確認方法に関する情報は、開発者とヘルプデスク担当者の両方にとって、トラブルシューティングチェックリストの最上位に置くべきです。また、ステータス更新の通知を受け取れるよう、Auth0 のステータスページで購読を設定することを推奨します。 パブリッククラウドサービスで障害が発生した場合、Auth0 は Root Cause Analysis (RCA) を実施し、その結果を Auth0 のステータスページに公開します。Auth0 は障害発生後に、根本原因の特定、寄与要因の分析、再発防止策の検討を含む徹底的な調査を行います。そのため、RCA 文書が公開されるまでに数週間かかる場合があります。
サインアップ、メールアドレスの確認、アカウント復旧などで顧客に送信される、本番運用に必要な量のメールに対応できるよう、独自のメールプロバイダーが正しく設定されていることを再確認してください。
Auth0 は、サインアップ時のウェルカムメール、メールアドレスの確認、パスワード漏えい検知、パスワードリセットなどのイベントで、ユーザーにメール を送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール送信処理を高度にカスタマイズすることも可能です。Auth0 には、基本的なテスト向けに容量が制限されたテスト用メールプロバイダーが用意されていますが、本番環境で利用するには独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまで、メールテンプレートのカスタマイズは機能しません。
ベストプラクティス デフォルトの Auth0 メールプロバイダーは、本番環境に必要な量のメール送信やメールテンプレートのカスタマイズをサポートしていません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定してください。 Auth0 で実行されるカスタムコード (Action、Rule、Hook、カスタムデータベーススクリプトなど) からネットワーク内のサービスを呼び出す場合、または Auth0 でオンプレミスの SMTP プロバイダーを設定する場合は、Auth0 からのインバウンドトラフィック を許可するようにファイアウォールを設定する必要があることがあります。ファイアウォールで許可する IP アドレスはリージョンごとに異なり、Auth0 Dashboard
ホスティング環境でこれが自動的に処理されない場合は、NTP (Network Time Protocol) に障害が発生した際に自動的に再起動するスクリプトと、NTP が稼働していない場合に担当者へ通知するアラートを用意する必要があります。認証トランザクションは正確なシステム時刻に依存します。これは、送信側と受信側のシステム間で時刻にずれがあると、セキュリティトークン
AD/LDAP Connector を使用している場合は、環境内のロードバランサーの設定を確認し、非アクティブな長時間接続を切断するようになっていないか確認してください。切断する場合は、Auth0 AD/LDAP 接続の設定 を変更し、LDAP_HEARTBEAT_SECONDS 設定を使用して定期的にハートビートメッセージを送信することで、接続を維持できます。
アプリケーションがサーバー側の状態を保持しており、ユーザーを特定のサーバーに振り分けるためにスティッキーセッションを前提としたロードバランシングに依存している場合は、すべてのロードバランサー設定が正しいことをあらためて確認すると効果的です。プール内の 1 台のロードバランサーでも設定に不整合があると、トラブルシューティングが難しい断続的なエラーの原因になることがあります。ロードバランサーの設定を簡単に確認しておくだけで、こうした問題を未然に防げます。
ログデータを収集できるよう設定されていること、ログがデータ保持ポリシーの対象に含まれていること、さらにログデータの保持期間の制限を適用する仕組みがあることを確認してください。また、トラブルシューティングやフォレンジックに備えて、開発、サポート、セキュリティの各チームがログデータへのアクセス方法を把握していることも確認してください。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、利用傾向やエラーなどのパターンを特定しやすくなります。
Auth0 は、イベントのログ記録に関する幅広い機能に加え、イベントの異常を特定するためのログスキャン機能も提供しています (詳しくはログのドキュメント を参照してください) 。Auth0 ログの標準的な保持期間はサブスクリプションレベルによって決まり、最短で 2 日、最長でも 30 日です。Auth0 がサポートする外部ログサービスとの統合を活用すれば、この期間を超えてログを保持できるほか、組織全体のログを集約することもできます。
ベストプラクティス ログストリーミングソリューションのいずれかを利用して、ログデータを外部のログ分析サービスに送信してください。これにより、データをより長期間保持できるようになり、ログデータに対する高度な分析も可能になります。 ご利用のサブスクリプションレベルにおけるログデータの保持期間 を確認し、ログデータを外部のログ分析サービスに送信するためのログデータエクスポート拡張機能を実装してください。Auth0 Marketplace では、ログストリーミングソリューション のいずれかを利用できます。
開発チームは、トラブルシューティングや、QA テストでは見つけにくい断続的なエラーの検出にログファイルを活用できます。セキュリティチームも、フォレンジックデータが必要になった場合に備えて、ログデータを必要とする可能性があります。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、利用傾向や 攻撃対策
Auth0 は、レート制限を超過した場合 に報告されるエラーごとに固有のエラーコードを提供しています。ユーザーに大きな影響が及ぶ前に、レート制限に達するアクティビティへ先回りして対処できるよう、ログを自動的にスキャンしてレート制限エラーを確認することをお勧めします。Auth0 は他の種類のエラーに対するエラーコードも公開しているため、認証エラー に加えて、Auth0 の Management API Management API Explorer の各呼び出しの下に表示されます) 。
ベストプラクティス Rule 内からユーザープロファイル情報を取得するために Management API を呼び出すことは、レート制限エラーの一般的な原因です。これは、そのような API 呼び出しがログインのたびに実行されるだけでなく、定期的なセッションチェックでも実行されるためです。 Auth0 サービスだけでなく、アプリケーション全体を通じた認証についても、必ずプロアクティブな監視を設定してください。
サポートチームや運用チームがサービス障害に先回りして対応するために必要な情報を迅速に受け取れるよう、Auth0 実装の監視 の仕組みを整備する必要があります。Auth0 には、監視インフラストラクチャに組み込める監視用エンドポイントが用意されています。これらのエンドポイントは、監視サービスで利用しやすい応答を返すよう設計されています。ただし、提供されるのは Auth0 に関するデータのみである点に注意してください。ユーザーがログインできることを確認するうえで不可欠な完全なエンドツーエンド監視を行うには、合成トランザクション監視 を設定することを推奨します。これにより監視の粒度が向上し、Auth0 以外に起因する障害やパフォーマンスの低下も検出できるため、よりプロアクティブに対応できるようになります。
重要なお知らせや変更を把握できるよう、チームで Auth0 からの以下のすべての連絡チャネルを確認するようにしてください。
Auth0 からの通知にはいくつかの種類があり、テナントやプロジェクトに影響する可能性のある重要な情報が含まれているため、見逃さないよう注意してください。
事前対応が必要なセキュリティ通知やその他の運用に関するお知らせは、Auth0 からAuth0 Dashboard 管理者に送信されます。こうしたメッセージを受け取る必要がある担当者がAuth0 Dashboard 管理者になっていることを確認してください。
Auth0 は随時、テナントに関連する重要なお知らせを送信することがあります。これらのサービスに関するお知らせは Auth0 Dashboard に表示され、内容の重大度に応じて、登録済みの Auth0 Dashboard 管理者にメールでも送信されます。定期的に Dashboard にログインし、上部のベルアイコンを確認して重要な通知がないか確認することを習慣にしてください。また、Auth0 からのメールには、重要な変更や必要な対応に関する情報が含まれている場合があるため、速やかに確認してください。
Auth0 では定期的にさまざまなセキュリティ関連のテストを実施しており、問題が見つかった場合は、セキュリティ上の変更が必要なお客様を特定し、事前に通知します。ただし、Auth0 製品は拡張性が高いため、影響を受けるすべてのお客様を Auth0 が特定できるとは限りません。そのため、Auth0 のセキュリティ情報 を定期的に確認してください。また、組織のセキュリティ連絡先が Support Center に登録されていることを確認してください。
ベストプラクティス Auth0 のセキュリティ情報 ページを定期的に確認し、該当するセキュリティ情報の影響を受ける場合は、推奨される対応を実施することをお勧めします。 Auth0 は、サービスへの変更に関する情報を Auth0 の変更ログ で提供しています。変更を把握するため、Auth0 の変更ログを定期的に確認することを習慣にしてください。問題を調査するサポートチームにとっては、最近の変更が関係している可能性がないか確認するうえで、特にそれが互換性を損なう変更である場合、変更ログの確認が役立つことがあります。開発チームにとっても、有用な新機能を把握するために変更ログを確認することは重要です。
また、チーム側で対応が必要になる可能性のある今後の非推奨化に関する情報を確認するために、Auth0 の移行ページ も定期的に確認してください。
必須ではありませんが、バージョン管理と併せて自動デプロイを設定することをお勧めします。自動化によって dev、test、本番環境への変更のデプロイやロールバックを行えるようにしておくと、リリース後に問題が発生した場合にも、より効率よく対応できます。
変更管理と QA のベストプラクティスを採用することに加えて、運用がうまくいっているお客様は、自動デプロイ プロセスの一部として Auth0 の構成資産の管理も統合しています。SDLC support の Architecture セクションで説明しているように、開発、テスト、本番の各環境には、それぞれ個別の Auth0 テナントを設定し、各環境で同じテナント構成にする必要があります。デプロイを自動化することで、環境間でテナント構成の整合性を維持しやすくなり、バグやその他の問題の削減につながります。
ベストプラクティス デプロイ自動化の構成方法にかかわらず、デプロイ前に Rules、カスタム DB スクリプト、Hooks の単体テストを実施し、デプロイ後にはテナントに対する統合テストもいくつか実行することをお勧めします。詳しくは、Quality Assurance のガイダンスを参照してください。 Auth0 では、必要に応じて組み合わせて利用できる、次のデプロイ自動化アプローチをサポートしています。
Deploy CLI Tool と Source Control Extensions は、どちらも破壊的変更を引き起こす可能性がある点に注意してください。自動デプロイの合間に Dashboard で直接行った手動変更は失われるおそれがあります。そのため、いずれかを使用する場合は、すべて の変更を、そのツールが参照するソース管理サブシステムからデプロイし、手動では行わないでください。
環境によっては、環境固有の構成も必要になる場合があります。たとえば、アプリケーションの クライアントID クライアントシークレット
Auth0 では、カスタムの拡張機能 内から利用できる変数を設定できます。これらは、Auth0 テナントの環境変数と考えることができます。開発環境、テスト環境、本番環境の間でコードを移動するたびに変わる参照をハードコードする代わりに、テナントで設定した変数名をカスタム拡張コードから参照できます。これにより、実行時にテナント固有の値が設定される変数をコードから参照できるため、同じカスタムコードを変更せずに異なるテナント間で利用しやすくなります。
ベストプラクティス テナント固有の値に加え、カスタムコード内に公開すべきではない機密のシークレットを保持するためにも、変数を使用することを推奨します。カスタムコードを GitHub/GitLab/Bitbucket/VSTS にデプロイしている場合、テナント固有の変数を使用することで、リポジトリ経由で機密値が露出するのを防げます。 プロジェクトに必要なバックアップ/復元機能に対応できるよう、計画と実施手段を用意しておく必要があります。これには、データについては Auth0 Management API を使用し、Auth0 の設定については自動デプロイのセクションで説明している Automated Deployment 機能を使用できます。
Auth0 の Data Tenant Restore policy および Data Transfer policy に記載されているとおり、Auth0 は削除されたテナントを復元せず、テナント間でデータを移行することもありません。Auth0 は、お客様が必要に応じてデータのバックアップ、復元、移行を柔軟に行えるよう、Auth0 Management API を提供しています。お客様はバックアップを目的として Auth0 からデータを取得するスクリプトを作成でき、同様に Automated Deployment 機能と組み合わせて Auth0 設定のあらゆる要素を復元するためのスクリプトも作成できます。
問題が発生した際に Auth0 のサポート提供に影響する可能性があるため、アプリケーションスタックを構成するすべての技術要素と、ユーザーが使用するブラウザーが、いずれも最新の現行バージョンであることを再確認してください。
証明書は、ID 管理のデプロイ環境で使用されることがあります。証明書の有効期限切れに不意を突かれないようにするには、環境内の証明書一覧とその有効期限日、有効期限が近づいた際の通知方法、および証明書のロールオーバー手順を把握しておく必要があります。
SAML IdP Web Service Federation ローンチ前の必須要件ではありませんが、システム障害や、重要な担当者が所在する地域を襲う自然災害など、さまざまな災害が発生した場合でも事業継続性を確保できるよう、災害復旧計画をあらかじめ整備しておくと有用です。
絶対的な必須要件ではありませんが、推奨事項として、Auth0 に関連するすべてのプロセスを文書化しておくことも挙げられます。これには、次のようなものが含まれます。
構成変更の管理
新しい変更のデプロイ、使用している自動デプロイの仕組み、問題が見つかった場合に以前のバージョンへ戻す方法
証明書のロールオーバープロセス (該当する場合)
新しいIDプロバイダーの追加または削除 (該当する場合)
Auth0 内、または Auth0 が取り込むディレクトリ内でのユーザープロファイル構造の変更
アプリケーションまたは API の追加または削除
ログの収集とエクスポート
実装しているバックアップ／復元プロセス
ユーザー管理 (パスワード忘れ、電話の紛失)
インシデント発生後の根本原因分析
推奨する戦略の詳細を確認できるよう、ダウンロードして参照できる PDF 形式の計画ガイドを提供しています。
B2B IAM プロジェクト計画ガイド 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム