ステータス
運用担当者が Auth0 のサービスステータスを監視する方法を把握し、Auth0 のステータス更新通知を受け取る手段を設定していることを確認してください。 Auth0 の ステータスダッシュボード と Auth0 の 稼働状況ダッシュボード では、Auth0 サービスの現在および過去のステータスを、人が見てわかりやすい形式で確認できます。監視アラートが発生した場合は、トラブルシューティングの最初の手順として、運用担当者はステータスダッシュボードを確認し、現在障害が発生していないかを確認する必要があります。パブリッククラウドのステータスページでは障害通知を受け取るための登録もできるため、Social Providers など、依存しているサードパーティの 外部サービス のステータスも併せて確認することをお勧めします。こうした情報をすぐに参照できるようにしておくと、問題のトラブルシューティング時に考えられる原因をすばやく切り分けるのに役立ちます。これは、開発者だけでなくヘルプデスク担当者にとっても、トラブルシューティングのチェックリストの最上位に置くべき項目です。ベストプラクティス
Auth0 および依存サービス (Social Providers など) のステータスを確認する方法に関する情報は、開発者とヘルプデスク担当者の両方にとって、トラブルシューティングのチェックリストの最上位に置くべきです。また、ステータス更新の通知を受け取れるよう、Auth0 のステータスページから登録しておくことをお勧めします。メールプロバイダーの設定
サインアップ、メールアドレスのバリデーション、アカウント復旧などで顧客に送信される可能性がある本番環境向けのメール配信量に対応できるよう、独自のメールプロバイダーが設定されていることを必ず再確認してください。 Auth0 は、サインアップ時のウェルカムメール、メールアドレスのバリデーション、漏えいしたパスワード、パスワードリセットなどのイベントに応じて、ユーザーにメールを送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理自体をさらに高度にカスタマイズすることも可能です。Auth0 には、基本的なテスト用として容量が限られたテストメールプロバイダーが用意されていますが、本番利用には独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまで、メールテンプレートのカスタマイズは機能しません。ベストプラクティス
Auth0 のデフォルトのメールプロバイダーは、本番環境レベルのメール送信量やメールテンプレートのカスタマイズには対応していません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定してください。インフラストラクチャ
ファイアウォール
Auth0 で実行されるカスタムコード (Action、Rule、Hook、またはカスタムデータベーススクリプトなど) からお使いのネットワーク内のサービスを呼び出す場合や、Auth0 でオンプレミスの SMTP プロバイダーを設定する場合は、Auth0 からの受信トラフィックを許可するようにファイアウォールを設定する必要が生じることがあります。ファイアウォールで許可する IP アドレスはリージョンごとに異なり、 のルール、Hooks、カスタムデータベーススクリプト、およびメールプロバイダーの設定画面に一覧表示されています。NTP
ホスティング環境でこれが自動的に処理されない場合は、NTP (Network Time Protocol) に障害が発生した際に自動的に再起動するスクリプトと、NTPが停止している場合に担当者へ通知するアラートを用意する必要があります。認証トランザクションは、正確なシステム時刻に依存しています。送信側と受信側のシステム間で時刻のずれがあると、が受信時に期限切れと判定されることがあるためです。LoadBalancer のタイムアウトを確認する
AD/LDAP Connector を使用している場合は、環境内のロードバランサーの設定を確認し、非アクティブな長時間接続を切断するようになっていないか確認してください。切断する設定になっている場合は、Auth0 AD/LDAP 接続の設定を変更してLDAP_HEARTBEAT_SECONDS 設定を使用し、定期的にハートビートメッセージを送信することで、接続を維持できます。
LoadBalancer の設定
アプリケーションがサーバー側で状態を保持しており、ユーザーを特定のサーバーに振り分けるためにスティッキー負荷分散に依存している場合は、すべてのロードバランサーの設定が正しいことをあらためて確認しておくとよいでしょう。プール内のロードバランサーのうち1台でも設定の同期が取れていないと、原因の特定が難しい断続的なエラーが発生することがあります。ロードバランサーの設定をひととおり確認しておけば、こうした問題を未然に防げます。ログ
ログデータを取得できるよう設定されていること、ログがデータ保持ポリシーの対象になっていること、さらにログデータの保持上限を適用する仕組みがあることを確認してください。また、開発チーム、サポートチーム、セキュリティチームが、トラブルシューティングやフォレンジックの目的でログデータにアクセスする方法を把握していることも確認してください。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、利用傾向やエラーなどのパターンを特定しやすくなります。 Auth0 には、イベントのログ記録や、イベントの異常を特定するためのログのスキャンに関する幅広い機能があります (詳しくはログのドキュメントを参照してください) 。Auth0 ログの標準的な保持期間はサブスクリプションレベルによって決まり、最短で 2 日、最長でも 30 日です。外部のログサービスとの連携に Auth0 Support を活用すれば、この期間を超えてログを保持できるほか、organization 全体でログを集約することも可能になります。ベストプラクティス
ログデータを外部のログ分析サービスに送信するには、ログストリーミングソリューションのいずれかを活用してください。これにより、データをより長期間保持できるようになり、ログデータに対する高度な分析も可能になります。レート制限とその他のエラー
Auth0 では、レート制限を超過した際に報告されるエラーごとに固有のエラーコードを提供しています。レート制限エラーを確認できるようにログの自動スキャンを設定し、ユーザーに大きな影響が出る前に、レート制限に達するアクティビティへ先回りして対処することをおすすめします。Auth0 はこのほかの種類のエラーについてもエラーコードを公開しており、認証エラーに加えて、Auth0 の呼び出しによるエラーについてもログをスキャンすると役立ちます (Management API のエラーコードは、Management API Explorer で各呼び出しの下に表示されます) 。ベストプラクティス
Rule 内からユーザープロファイル情報を取得するために Management API を呼び出すことは、レート制限エラーのよくある原因です。これは、そのような API 呼び出しがログインのたびに実行される可能性があるうえ、定期的なセッションチェック時にも実行されるためです。監視
アプリケーション全体を通した認証のエンドツーエンド監視に加えて、Auth0 サービスのプロアクティブな監視も必ず設定してください。 サポートチームや運用チームがサービス停止に先回りして対応するために必要な情報を適時受け取れるよう、Auth0 実装の監視の仕組みを整備する必要があります。Auth0 では、監視インフラストラクチャに組み込める監視用エンドポイントを提供しています。これらのエンドポイントは、監視サービスで利用しやすい応答を返すよう設計されています。ただし、提供されるのは Auth0 に関するデータのみである点に注意してください。ユーザーがログインできるかどうかを確認するために不可欠な、完全なエンドツーエンド監視を行うには、シンセティックトランザクション監視を設定することを推奨します。これにより、よりきめ細かな監視が可能になり、Auth0 に起因しない停止やパフォーマンス低下も検出できるため、より迅速かつ先回りした対応が可能になります。ベストプラクティス
認証のエンドツーエンド監視を行いやすくするために、シンセティックなログイントランザクションを送信できるようにしておく必要があります。これは、権限を持たないテストユーザーと組み合わせて、リソース所有者パスワードグラントを使用するシンプルなアプリケーションで実現できます。また、Auth0 のレート制限ポリシーも忘れないでください。Auth0 の通知
重要なお知らせや変更を把握できるよう、Auth0 からの以下のすべての連絡チャネルをチームで確認するようにしてください。 Auth0 からは複数の種類の通知が送られてきます。これらには、テナントやプロジェクトに影響する可能性のある重要な情報が含まれているため、見落とさないよう注意が必要です。Auth0 は、事前対応が必要なセキュリティ通知やその他の運用に関するお知らせを Auth0 Dashboard 管理者に送信します。こうしたメッセージを受け取る必要がある担当者が Auth0 Dashboard 管理者になっていることを確認してください。
Auth0 Dashboard の通知
Auth0 は、お客様のテナントに関する重要なお知らせを随時送信することがあります。こうしたサービスに関するお知らせは Auth0 Dashboard に送信され、重要度に応じて、登録済みの Auth0 Dashboard 管理者へメールでも送信されます。定期的に Auth0 Dashboard にログインし、画面上部のベルアイコンに重要なお知らせが届いていないか確認する習慣をつけてください。また、必要な変更や対応に関する重要な情報が含まれている可能性があるため、Auth0 からのメールも速やかに確認してください。変更ログ
Auth0 では、サービスの変更に関する情報を Auth0 の変更ログで提供しています。変更を把握できるよう、Auth0 の変更ログを定期的に確認する習慣をつけてください。問題を調査しているサポートチームにとっては、最近の変更が関係している可能性がないかを確認するうえで、変更ログが役立つ場合があります。特に、互換性のない変更が含まれている場合は重要です。開発チームも、導入すると有益な新機能を見つけるために変更ログを確認するとよいでしょう。 また、チームでの対応が必要になる可能性のある今後の非推奨化に関する情報を確認するため、Auth0 の移行ページも定期的に確認してください。自動デプロイ、バージョン管理
必須ではありませんが、バージョン管理とあわせて自動デプロイを導入することをお勧めします。自動化によって dev、test、production 環境への変更のデプロイや切り戻しを行えるようにしておくと、ローンチ後に問題が発生した場合でも、より効率的に対応できます。 変更管理や QA のベストプラクティスを採り入れることに加え、導入に成功しているお客様は、自動デプロイのプロセスの一環として Auth0 の構成要素の管理も組み込んでいます。SDLC のサポート の Architecture セクションで説明しているように、開発、テスト、本番環境ごとに個別の Auth0 テナントを構成しつつ、各環境で同じテナント設定になるようにする必要があります。デプロイの自動化を利用することで、環境間でテナント設定の一貫性を保ちやすくなり、バグやその他の問題の軽減につながります。ベストプラクティス
デプロイ自動化の構成方法にかかわらず、デプロイ前にルール、Custom DB スクリプト、フックのユニットテストを行い、デプロイ後にはテナントに対して連携テストもいくつか実施することをお勧めします。詳細については、Quality Assurance のガイダンスを参照してください。- Auth0 Deploy CLI tooling は、既存の Continuous Integration/Continuous Deployment (CI/CD) パイプラインと連携できる、使いやすいスクリプトを提供します。
- Auth0 の Source Control Extensions は、CI/CD パイプラインがない場合や、CI/CD パイプラインと直接連携できない場合に、設定しやすく保守の手間も非常に少ない基本的な自動化プロセスを提供します。
- 開発ワークフローで Terraform を利用している場合は、Auth0 Terraform Provider を使って Auth0 テナント設定を管理できます。
- Tenant Specific Variables を使用する
- Auth0 Deploy CLI tool を使用している場合は keyword replacement を使用する
テナント固有の変数
Auth0 では、カスタム拡張内から利用できる変数を設定できます。これは、Auth0 テナント用の環境変数と考えることができます。開発、テスト、Production 環境の間でコードを移動するたびに変わる参照をハードコードする代わりに、テナントで設定した変数名をカスタム拡張コードから参照できます。これにより、実行時にテナント固有の値が設定される変数をコードから参照できるため、同じカスタムコードを変更せずに異なるテナントでも使いやすくなります。- Actions で変数を使用する場合は、エディターで secrets を設定する方法について Write Your First Action を参照してください
- ルール で変数を使用する場合は、値を設定する方法を参照してください
- Hooks で変数を使用する場合は、エディターで secrets を設定する方法を参照してください
- Custom DB Scripts で変数を使用する場合は、設定パラメータを参照してください
ベストプラクティス
テナント固有の値や、カスタムコード内で公開すべきでない機密性の高い secrets を保持するために、変数を使用することを推奨します。カスタムコードを GitHub/GitLab/Bitbucket/VSTS で管理している場合、テナント固有の変数を使用することで、リポジトリ経由で機密値が漏洩するのを防げます。バックアップ / 復元
プロジェクトに必要なバックアップ / 復元機能に対応できるよう、あらかじめ計画と仕組みを整えておく必要があります。これは、データについては Auth0 Management API を使用し、Auth0 の設定については automated deployment セクションで説明している Automated Deployment 機能を使用することで実現できます。 Auth0 の Data Tenant Restore policy および Data Transfer policy にあるとおり、Auth0 は削除されたテナントを復元せず、テナント間でデータを移動することもありません。Auth0 は、お客様が必要に応じてデータのバックアップ、復元、移動を柔軟に行えるよう、Auth0 Management API を提供しています。お客様は、バックアップを目的として Auth0 からデータを取得するスクリプトを作成でき、同様に Automated Deployment 機能と組み合わせて、Auth0 の設定のあらゆる要素を復元するためのスクリプトを作成することもできます。バージョンを最新の状態に保つ
問題が発生した場合にAuth0のサポート提供へ影響する可能性があるため、アプリケーションスタックで使用しているすべてのテクノロジーと、ユーザーが使用するブラウザーが、いずれも最新のバージョンであることを必ず再確認してください。- Auth0 Dashboard の設定で、サポート対象の最新バージョンの node.js を使用していることを確認してください。
- Auth0 Support Matrixに基づき、Auth0 がサポートしているバージョンの SDK/ライブラリを使用していることを確認してください。
証明書ロールオーバー計画
証明書は、アイデンティティのデプロイで使用される場合があります。証明書の有効期限切れに不意を突かれないようにするには、環境内で使用している証明書の一覧とその有効期限日、有効期限が近づいた際の通知方法、そして証明書のロールオーバー手順を把握しておく必要があります。SAML 接続
接続では、 から証明書を取得し、Auth0 Dashboard でその IdP の SAML 接続にアップロードします。これらの証明書のいずれかの有効期限が近づくと、Auth0 は期限切れが近いことを知らせる警告メールを Auth0 Dashboard 管理者に送信します。新しい証明書を取得し、接続の設定画面からアップロードできます。WS-Fed 接続
(WS-Fed) 接続では、ADFS URL を指定して設定している場合、変更内容は毎日の更新時に反映されます。Auth0 Dashboard の接続設定ページを開いて Save を実行すると、手動で更新をトリガーできます。リモート IdP で証明書が変更された場合、Auth0 はこれらの方法、または同じ接続設定画面で新しいメタデータファイルをアップロードすることで更新できます。災害復旧／事業継続計画が整備されている
ローンチ前の必須条件ではありませんが、システム障害や、重要な担当者がいる地域で発生する自然災害など、さまざまな災害が起きた場合にも事業継続を確保できるよう、災害復旧計画を整備しておくことは有効です。文書化されているプロセス
絶対的な必須要件ではありませんが、推奨事項として、Auth0 に関連するすべてのプロセスが文書化されていることを確認することも挙げられます。これには、次のようなものが含まれます。- 構成の変更管理
- 新しい変更のデプロイ、使用している自動デプロイの仕組み、問題が見つかった場合に以前のバージョンに戻す方法
- 証明書のロールオーバープロセス (ある場合)
- 新しい IDプロバイダー の追加または削除 (該当する場合)
- Auth0 内、または Auth0 が参照元とするディレクトリ内でのユーザープロファイル構造の変更
- アプリケーション または API の追加または削除
- ログの取得とエクスポート
- 実装済みのバックアップ/復元プロセス
- ユーザー管理 (パスワードを忘れた場合、電話を紛失した場合)
- インシデント発生後の根本原因分析