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