運用担当者が Auth0 サービスのステータスを監視する方法を把握し、Auth0 のステータス更新を購読する手段を設定していることを確認してください。
Auth0 のステータスダッシュボード と Auth0 の稼働状況ダッシュボード では、Auth0 サービスの現在および過去のステータスをわかりやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの最初の手順として、運用担当者はまずステータスダッシュボードを確認し、現在障害が発生していないかを確認する必要があります。パブリッククラウドのステータスページでは、障害通知を購読する機能も提供されています。また、ソーシャルプロバイダーなど、依存しているサードパーティの外部サービス のステータスも確認することをお勧めします。この情報をすぐ確認できるようにしておくことで、問題のトラブルシューティング時に考えられる原因をすばやく切り分けることができ、開発者とヘルプデスク担当者の両方にとって、トラブルシューティング用チェックリストの最優先項目にすべきです。
ベストプラクティス Auth0 および依存サービス (ソーシャルプロバイダーなど) のステータス確認方法に関する情報は、開発者とヘルプデスク担当者の両方に向けたトラブルシューティング用チェックリストの最優先項目にすべきです。また、ステータス更新の通知を受け取れるよう、Auth0 のステータスページで購読設定を行うことをお勧めします。 パブリッククラウドサービスで障害が発生した場合、Auth0 は根本原因分析 (RCA) を実施し、その結果を Auth0 のステータスページで公開します。Auth0 は障害発生後、根本原因の特定に加え、影響した要因の分析や再発防止策の検討を含む徹底的な調査を行うため、RCA 文書の公開までに数週間かかることがあります。
新規登録、メールのバリデーション、アカウントの復旧などで顧客に送信される可能性のある本番環境レベルのメールに対応できるよう、独自のメールプロバイダーが正しく設定されていることをあらためて確認してください。
Auth0 は、新規登録時のウェルカムメール、メールのバリデーション、漏えいしたパスワード、パスワードリセットなどのイベントに応じて、ユーザーにメール を送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理自体を高度にカスタマイズすることも可能です。Auth0 には基本的なテスト用として、送信容量が制限されたテスト用メールプロバイダーが用意されていますが、本番環境で利用するには独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまでは、メールテンプレートのカスタマイズは機能しません。
Best Practice Auth0 のデフォルトのメールプロバイダーは、本番環境レベルのメール送信やメールテンプレートのカスタマイズには対応していません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定してください。 Auth0 で実行されるカスタムコード (Action、Rule、Hook、または Custom DB スクリプトなど) からお使いのネットワーク内のサービスを呼び出す場合や、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 Support を活用すれば、この期間を超えてログを保持できるようになるほか、organization 全体にまたがるログの集約も可能になります。
ベストプラクティス ログデータを外部のログ分析サービスに送信するために、ログストリーミングソリューションのいずれかを活用してください。これにより、データをより長期間保持できるようになり、ログデータに対する高度な分析も可能になります。 ご利用のサブスクリプションレベルに応じたログデータの保持期間 を確認し、ログデータを外部のログ分析サービスに送信するためのエクスポートサービスを導入してください。Auth0 Marketplace では、当社のログストリーミングソリューション のいずれかを利用できます。
開発チームは、QA テストでは見つけにくい断続的なエラーのトラブルシューティングや検出にログファイルを活用できます。セキュリティチームも、フォレンジックデータが必要になった場合に備えて、ログデータを必要とする可能性が高いでしょう。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、使用傾向や 攻撃対策
Auth0 では、レート制限を超えた 際に報告されるエラーに対して、固有のエラーコードを提供しています。ユーザーに深刻な影響が出る前に、レート制限に達するアクティビティへ先回りして対応できるよう、レート制限エラーを検出するためにログを自動的にスキャンする設定をしておく必要があります。Auth0 は、ほかの種類のエラーについてもエラーコードを公開しています。そのため、認証エラー だけでなく、Auth0 の Management API Management API Explorer の各呼び出しの下に表示されます) 。
ベストプラクティス Rule 内から Management API を呼び出してユーザープロファイル情報を取得することは、レート制限エラーの一般的な原因です。こうした API 呼び出しは、ログインのたびに実行される可能性があるうえ、定期的なセッションチェック時にも実行されるためです。 Auth0 サービスのプロアクティブな監視に加え、アプリケーションを通じた認証のエンドツーエンド監視も必ず設定してください。
サポートチームや運用チームがサービス停止に先回りして対処するために必要な情報をタイムリーに受け取れるよう、Auth0 実装の監視 の仕組みを整備する必要があります。Auth0 では、監視インフラストラクチャに組み込める監視エンドポイントを提供しています。これらのエンドポイントは、監視サービスで利用しやすい応答を返すよう設計されています。ただし、取得できるのは Auth0 に関するデータのみである点に注意してください。ユーザーがログインできるかどうかを確認するうえで不可欠な完全なエンドツーエンド監視には、合成トランザクション監視を設定することをおすすめします。これにより監視の粒度が高まり、Auth0 に起因しない障害やパフォーマンス低下も検出できるようになるため、より先回りした対応が可能になります。
ベストプラクティス 認証のエンドツーエンド監視を実現するために、合成ログイントランザクションを送信できるようにしておくべきです。これは、権限を持たないテストユーザーと組み合わせて リソース所有者パスワードグラント を使用するシンプルなアプリケーションで実現できます。また、Auth0 のレート制限ポリシー も忘れずに考慮してください。 重要なお知らせや変更を把握できるよう、Auth0 からの以下すべての連絡チャネルをチームで確認するようにしてください。
Auth0 からの通知にはいくつかの種類があり、テナントやプロジェクトに影響する可能性のある重要な情報が含まれているため、注意して確認する必要があります。
セキュリティに関する事前通知やその他の運用上のお知らせは、Auth0 からAuth0 Dashboard 管理者に送信されます。こうしたメッセージを受け取る必要がある担当者が、Auth0 Dashboard 管理者になっていることを確認してください。
Auth0 は、お使いのテナントに関する重要なお知らせを随時送信することがあります。こうしたサービスに関するお知らせは Auth0 Dashboard に送信され、内容の重要度に応じて、登録済みの Auth0 Dashboard 管理者にメールでも送信されます。定期的に Auth0 Dashboard にログインし、上部のベルアイコンを確認して重要なお知らせが届いていないか確認するようにしてください。あわせて、Auth0 からのメールにも速やかに目を通してください。変更に関する重要な情報や、必要な対応が記載されている場合があります。
Auth0 では、サービスの変更に関する情報を Auth0 の変更ログ で公開しています。変更を把握するために、Auth0 の変更ログを定期的に確認する習慣をつけましょう。問題を調査しているサポートチームにとっては、特にそれが互換性のない変更である場合、最近の変更が関係している可能性がないかを判断するうえで、変更ログの確認が役立つことがあります。開発チームもまた、役立つ可能性のある新機能を見つけるために、変更ログを確認するとよいでしょう。
また、チーム側で対応が必要になる可能性のある今後の非推奨化に関する情報を得るため、Auth0 の移行ページ も定期的に確認してください。
必須ではありませんが、デプロイの自動化を導入しておくことを強くお勧めします。dev、test、本番環境への変更のデプロイや切り戻しを自動化しておけば、ローンチ後に変更が必要になった場合でも、より迅速かつ効率的に対応できます。
変更管理と 品質保証 のベストプラクティスを取り入れることに加え、導入に成功しているお客様は、Auth0 の構成管理も自動デプロイプロセスの一部として組み込んでいます。SDLC のサポート にある Architecture セクションで説明しているように、開発、テスト、本番用にそれぞれ別の Auth0 テナントを用意し、各環境のテナント構成をほぼ同一にしておくことが重要です。デプロイを自動化することでこれを実現しやすくなり、各環境のテナントを同じ構成に保てるため、環境間の構成の不一致によって不具合が発生する可能性を低くできます。
ベストプラクティス デプロイの自動化をどのように構成する場合でも、デプロイ前にルール、Custom DB スクリプト、フックをユニットテストし、デプロイ後にはテナントに対していくつかの統合テストも実行することをお勧めします。詳しくは、品質保証 のガイダンスを参照してください。 Auth0 では、デプロイ自動化の方法としていくつかの選択肢をサポートしており、必要に応じてそれらを組み合わせて使用することもできます。
Auth0 Deploy CLI tooling では、既存の Continuous Integration/Continuous Deployment (CI/CD) パイプラインとの連携に役立つ、使いやすいスクリプトが提供されています。CI/CD パイプラインと直接連携できない場合、または何らかの理由で CI/CD パイプラインがない場合は、Auth0 の Source Control Extensions を使うことで、セットアップが容易で保守の手間も非常に少ない基本的な自動化プロセスを実現できます。
Deploy CLI Tool と source control extensions は、どちらも破壊的な変更を引き起こす可能性がある点に注意してください。自動デプロイの合間にダッシュボードで直接行った手動変更は失われるおそれがあります。そのため、いずれかを使用する場合は、すべての 変更をそのツールが参照するソース管理サブシステムからデプロイし、手動では変更しないようにする必要があります。
また、各環境では環境固有の構成が必要になる場合があります。たとえば、アプリケーションの Client ID Client Secrets
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 からデータを取得するスクリプトを作成でき、同様に、Auth0 の設定のあらゆる要素を復元するために Automated Deployment 機能で使用するスクリプトも作成できます。
問題が発生した際に Auth0 からサポートを受けられるかどうかに影響するため、アプリケーションスタックを構成するすべての技術要素と、ユーザーが利用しているブラウザのバージョンが、いずれも最新の状態であることをあらためて確認してください。
証明書は ID デプロイで使用されることがあります。証明書の有効期限切れに不意を突かれないようにするには、環境内で使用している証明書の一覧に加え、それぞれの有効期限、期限が近づいた際の通知方法、そして証明書のロールオーバー手順をどのように実施するかを把握しておく必要があります。
SAML IdP WS-Fed ローンチ前の絶対条件ではありませんが、システム障害や、重要な担当者がいる地域を襲う自然災害をはじめとするさまざまな災害が発生した場合でも事業継続性を確保できるよう、災害復旧計画を整備しておくことは有用です。
絶対的な必須要件ではありませんが、推奨事項として、Auth0 に関連するすべてのプロセスを文書化しておくことも挙げられます。これには、次のようなものが含まれます。
設定変更の変更管理
新しい変更のデプロイ、使用している自動デプロイの仕組み、問題が見つかった場合に以前のバージョンに戻す方法
証明書のロールオーバープロセス (ある場合)
新しい IDプロバイダー の追加または削除 (該当する場合)
Auth0 内、または Auth0 が情報を取り込むディレクトリ内でのユーザープロファイル構造の変更
アプリケーション または API の追加または削除
ログの取得とエクスポート
実装済みのバックアップ／復元プロセス
ユーザー管理 (パスワード忘れ、携帯電話の紛失)
インシデント発生後の根本原因分析
推奨戦略の詳細を確認できるよう、ダウンロードして参照できる PDF 形式の計画ガイドを提供しています。
B2C IAM プロジェクト計画ガイド 
認証
ユーザー管理
カスタマイズ
プラットフォーム