運用担当者が Auth0 サービスのステータスを監視する方法を理解し、Auth0 のステータス更新を受け取れるように設定しておく必要があります。
Auth0 の status dashboard と uptime dashboard では、Auth0 サービスの現在および過去のステータスを人が見てわかりやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの最初の手順として、まず status dashboard を確認し、現在障害が発生していないかを運用担当者が確認する必要があります。パブリッククラウドのステータスページでは、障害通知を購読することもできます。また、Social Providers など、依存しているサードパーティの 外部サービス のステータスも確認することを推奨します。この情報をすぐ参照できるようにしておくことで、問題発生時のトラブルシューティングで考えられる原因をすばやく切り分けるのに役立ちます。そのため、開発者とヘルプデスク担当者の双方にとって、これはトラブルシューティングチェックリストの最優先項目に含めるべきです。
ベストプラクティス Auth0 および依存サービス (Social Providers など) のステータスを確認する方法に関する情報は、開発者とヘルプデスク担当者の両方のトラブルシューティングチェックリストの最優先項目に含めるべきです。また、ステータス更新の通知を受け取れるよう、Auth0 のステータスページで購読設定を行うことを推奨します。 パブリッククラウドサービスで障害が発生した場合、Auth0 は根本原因分析 (RCA) を実施し、その結果を Auth0 のステータスページで公開します。Auth0 では、障害発生後に根本原因の特定に加え、寄与した要因や再発防止策を含む徹底的な調査を行うため、RCA ドキュメントの公開までに数週間かかることがあります。
サインアップ、メールアドレスの検証、アカウント復旧などで顧客に送信される可能性がある、本番環境で想定されるメール送信量に対応できるよう、独自のメールプロバイダーが正しく設定されていることを必ず再確認してください。
Auth0 は、サインアップ時のウェルカムメール、メールアドレスの検証、パスワード漏えい、パスワードリセットなどのイベントで、ユーザーにメール を送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理を高度にカスタマイズすることも可能です。Auth0 は基本的なテスト用に容量が限定されたテスト用メールプロバイダーを提供していますが、本番環境で使用するには独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまで、メールテンプレートのカスタマイズは機能しません。
ベストプラクティス Auth0 のデフォルトのメールプロバイダーは、本番環境で必要な量のメール送信や、メールテンプレートのカスタマイズに対応していません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定してください。 Auth0 で実行されるカスタムコード (Action、Rule、Hook、または Custom DB scripts など) からお使いのネットワーク内のサービスを呼び出す場合、または Auth0 でオンプレミスの SMTP プロバイダーを設定する場合は、Auth0 からの受信トラフィック を許可するようファイアウォールの設定が必要になることがあります。ファイアウォールで許可する IP アドレスはリージョンごとに異なり、Auth0 Dashboard
これがホスティング環境によって自動的に処理されない場合は、NTP (Network Time Protocol) で障害が発生した際に自動的に再起動するスクリプトと、NTP が稼働していない場合に担当者へ通知するアラートを用意する必要があります。認証トランザクションは正確なシステム時刻に依存します。これは、送信側と受信側のシステム間で時刻のずれがあると、セキュリティ トークン
LoadBalancer のタイムアウト設定を確認する AD/LDAP Connector を使用している場合は、環境内のロードバランサー設定を確認し、アイドル状態の長時間接続が切断されるかどうかを確認してください。切断される場合は、Auth0 AD/LDAP 接続の設定 を変更し、LDAP_HEARTBEAT_SECONDS 設定を使用して定期的にハートビートメッセージを送信することで、接続を維持できます。
アプリケーションがサーバー側の状態を保持しており、ユーザーを特定のサーバーに振り分けるためにスティッキーセッションを伴うロードバランシングに依存している場合は、すべてのロードバランサー設定が正しいことをあらためて確認すると効果的です。プール内のロードバランサーのうち 1 台でも設定の同期が取れていないと、断続的で原因の切り分けが難しいエラーが発生することがあります。ロードバランサー設定をひととおり確認しておけば、そのような問題を未然に防ぐことができます。
ログデータを収集できるよう設定されていること、ログがデータ保持ポリシーの対象に含まれていること、さらにログデータの保持期間の上限を適用する仕組みがあることを確認してください。また、開発、サポート、セキュリティの各チームが、トラブルシューティングやフォレンジックのためにログデータへアクセスする方法を把握していることも重要です。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、利用傾向やエラーなどのパターンを特定しやすくなります。
Auth0 は、イベントのログ記録に関して豊富な機能を提供しており、さらにイベントの異常を特定するためのログスキャン機能も備えています (詳細はログのドキュメント を参照してください) 。Auth0 ログの標準保持期間はサブスクリプションレベルによって異なり、最短で 2 日間、最長でも 30 日間です。Auth0 Support を通じて外部ロギングサービスと統合すれば、この期間を超えてログを保持できるようになるほか、組織全体のログを集約することも可能です。
ベストプラクティス ログデータを外部のログ分析サービスに送信するために、ログストリーミングソリューションのいずれかを活用してください。これにより、データをより長期間保持できるようになり、ログデータに対して高度な分析を実行できます。 ご利用のサブスクリプションレベルに応じたログデータの保持期間 を確認し、ログデータを外部のログ分析サービスに送信するログデータエクスポートサービスを実装してください。Auth0 Marketplace では、ログストリーミングソリューション のいずれかを利用できます。
開発チームは、QA テストでは見つけにくい断続的なエラーのトラブルシューティングや検出のためにログファイルを利用できます。セキュリティチームは、フォレンジックデータが必要になった場合に備えてログデータを必要とする可能性があります。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、利用傾向や アタックプロテクション
Auth0 は、レート制限を超過した ときに報告されるエラーに対して、一意のエラーコードを提供しています。レート制限エラーを確認できるようにログの自動スキャンを設定し、レート制限に達するアクティビティがユーザーに大きな影響を及ぼす前に、先回りして対処することをおすすめします。Auth0 は他の種類のエラーに対するエラーコードも公開しているため、認証エラー に加えて、Auth0 Management API Management API Explorer の各呼び出しの下に表示されます) 。
ベストプラクティス Rule 内から Management API を呼び出してユーザープロフィール情報を取得することは、レート制限エラーの一般的な原因です。こうした API 呼び出しは、ログインのたびだけでなく、定期的なセッションチェック時にも実行される可能性があるためです。 Auth0 サービスのプロアクティブな監視に加え、アプリケーション全体を通した認証のエンドツーエンド監視も必ず実施してください。
サポートチームや運用チームがサービス停止に先回りして対応するために必要な情報をタイムリーに受け取れるよう、Auth0 実装の監視 の仕組みを整備する必要があります。Auth0 には、監視基盤に組み込める監視エンドポイントが用意されています。これらのエンドポイントは、監視サービスで利用しやすいレスポンスを返すよう設計されています。ただし、これらで取得できるのは Auth0 に関するデータのみである点に注意してください。ユーザーがログインできることを確認するうえで不可欠な完全なエンドツーエンド監視には、シンセティックトランザクション監視を設定することを推奨します。これにより監視の粒度が高まり、Auth0 に起因しない障害やパフォーマンス低下も検出できるため、より先回りした対応が可能になります。
重要なお知らせや変更を把握できるよう、チームで Auth0 からの以下のすべての連絡チャネルを確認するようにしてください。
Auth0 からの通知には複数の種類があり、テナントやプロジェクトに影響する可能性のある重要な情報が含まれているため、注意して確認する必要があります。
事前のセキュリティ通知やその他の運用上のお知らせは、Auth0 から Dashboard 管理者に送信されます。こうしたメッセージを受け取る必要がある担当者が Dashboard 管理者になっていることを確認してください。
Auth0 は随時、テナントに関連する重要なお知らせを送ることがあります。こうしたサービスに関するお知らせは Auth0 Dashboard に表示され、内容の重要度に応じて、登録済みの Auth0 Dashboard 管理者にはメールでも送信されます。定期的に Dashboard にログインし、上部のベルアイコンを確認して重要なお知らせが届いていないか確認することを習慣にしてください。また、Auth0 からのメールには、重要な変更や必要な対応に関する情報が含まれている場合があるため、速やかに確認してください。
Auth0 では定期的にさまざまなセキュリティ関連のテストを実施しており、問題が見つかった場合は、セキュリティ上の変更が必要な顧客を積極的に特定して通知します。ただし、Auth0 製品は拡張性が高いため、影響を受けるすべての顧客を Auth0 が特定できるとは限りません。そのため、Auth0 のセキュリティ情報 を定期的に確認してください。また、組織のセキュリティ連絡先が Support Center に登録されていることを確認してください。
ベストプラクティス ベストプラクティスとして、Auth0 のセキュリティ情報 ページを定期的に確認し、セキュリティ情報の影響を受ける場合は推奨される対応を実施してください。 Auth0 は、サービスの変更に関する情報を Auth0 の変更履歴 で提供しています。変更内容を把握するため、Auth0 の変更履歴を定期的に確認するようにしてください。問題を調査しているサポートチームは、最近の変更が関連している可能性があるかどうかを判断するために、変更履歴を確認すると役立つ場合があります。特に、それが破壊的変更である場合は重要です。開発チームもまた、有用な可能性のある新機能を把握するために、変更履歴を確認するとよいでしょう。
また、今後予定されている非推奨化によりチームで対応が必要になる可能性があるため、定期的にAuth0 migrations page も確認してください。
必須ではありませんが、デプロイの自動化を設定しておくことを強くお勧めします。dev、test、本番環境への変更のデプロイや変更のロールバックを自動化しておけば、リリース後に変更が必要になった場合でも、より効率的に対応できます。
変更管理と QA のベストプラクティスを取り入れることに加え、導入に成功しているお客様は、自動デプロイプロセスの一部として Auth0 の構成管理も統合しています。SDLC サポート の Architecture セクションで説明しているとおり、開発、テスト、本番の各環境ごとに個別の Auth0 テナントを設定し、各環境のテナント構成がほぼ同一になるようにする必要があります。デプロイを自動化することで、各環境のテナントを同じ構成に保ちやすくなり、環境間の構成不一致に起因するバグの発生も抑えられます。
ベストプラクティス デプロイ自動化の方法にかかわらず、デプロイ前に Rules、Custom DB scripts、Hooks のユニットテストを実施し、デプロイ後にはテナントに対して統合テストも実行することをお勧めします。詳細については、Quality Assurance のガイダンスを参照してください。 Auth0 では、デプロイ自動化の方法としていくつかの選択肢をサポートしており、必要に応じて組み合わせて使用することもできます。
Auth0 Deploy CLI tooling では、既存の Continuous Integration/Continuous Deployment (CI/CD) pipeline との統合に役立つ、使いやすいスクリプトが提供されています。CI/CD pipeline と直接統合できない場合や、何らかの理由で CI/CD pipeline を使用していない場合は、Auth0 の Source Control Extensions を使用することで、設定が簡単でメンテナンス負荷も非常に低い、基本的な自動化プロセスを実現できます。
Deploy CLI Tool と source control extensions は、どちらも破壊的変更を引き起こす可能性があることに注意してください。自動デプロイの合間に Dashboard で直接行った手動の変更は失われる可能性があります。そのため、どちらかを使用する場合は、すべて の変更を tooling が参照する source control サブシステムからデプロイし、手動では行わないようにしてください。
各環境では、環境固有の構成も必要になる場合があります。たとえば、アプリケーションの クライアント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 WS-Fed ローンチ前の必須条件ではありませんが、システム障害や、重要な担当者が所在する地域を襲う自然災害など、さまざまな災害が発生した場合でも事業継続性を確保できるよう、災害復旧計画を整備しておくことは有用です。
絶対要件ではありませんが、推奨事項として、Auth0 に関連するすべてのプロセスが文書化されていることも確認してください。これには、次のようなものが含まれます。
設定の変更管理
新しい変更のデプロイ、使用している自動デプロイの仕組み、および問題が見つかった場合に以前のバージョンへ戻す方法
証明書のロールオーバープロセス (ある場合)
新しい IDプロバイダー の追加または削除 (該当する場合)
Auth0 または Auth0 が参照元とするディレクトリ内のユーザープロフィール構造の変更
アプリケーションまたは API の追加または削除
ログの取得とエクスポート
実装しているバックアップ/復元プロセス
ユーザー管理 (パスワード忘れ、電話紛失時の対応)
インシデント発生後の根本原因分析
推奨戦略の詳細を確認できるよう、ダウンロードして参照できる PDF 形式の計画ガイドを提供しています。
B2C IAM プロジェクト計画ガイド 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム