運用準備（B2C）

運用スタッフがAuth0サービスのステータスを監視する方法を知っており、Auth0ステータスの更新を購読する手段をセットアップしていることを確認する必要があります。

Auth0のステータスダッシュボートと稼働時間ダッシュボートには、Auth0サービスの過去と現在のステータスが人間に読める形式で表示されます。追跡アラートが発生したら、トラブルシューティングの第1段階として、運用スタッフは必ずステータスダッシュボートで現在の停止状態を確認してください。パブリッククラウドのステータスページにも、機能停止の通知を受け取るように登録する手段があります。また、ソーシャルプロバイダーなど、依存関係にあるサードパーティーの外部サービスでもステータスを確認するようにしてください。この情報はトラブルシューティングで可能性のある原因を除外するのに役立つため、開発者やヘルプデスク担当者はトラブルシューティングのチェックリストで必ず最優先の確認事項にしてください。

パブリッククラウドサービスが停止すると、Auth0は根本原因分析（RCA）を行い、その結果をAuth0のステータスページで公開します。Auth0は停止後に、根本原因の特定、寄与要因、再発防止方法などを含めた徹底的な調査を行うため、RCAドキュメントの公開には数週間かかることがあります。

サインアップ、メールの検証、アカウントの回復などのために顧客に送信される可能性のある実運用における大量のメールをサポートするように、独自のメールプロバイダーをセットアップしていることを再確認する必要があります。

サインアップの歓迎、メール検証、パスワード漏洩、パスワードリセットのイベントなどについて、Auth0はユーザーにメールを送信します。イベントタイプのそれぞれにメールテンプレートをカスタマイズすることができます。また、メールの扱いを細やかにカスタマイズすることもできます。Auth0はテストメールプロバイダーを提供していますが、基本的なテスト用に機能が制限されているため、運用での使用には独自のメールプロバイダーをセットアップしなければなりません。メールテンプレートのカスタマイズは、独自のプロバイダーを確立するまで動作しません。

Auth0で実行するカスタムコード（アクション、ルール、フック、カスタムDBスクリプト）がネットワーク内のサービスを呼び出す場合、または、Auth0でオンプレミスSMTPプロバイダーを構成した場合は、Auth0からのインバウンドトラフィックを許可するようにファイアウォールを構成しなければならないことがあります。ファイアウォールを通過できるIPアドレスは各リージョンに特有で、ルール、フック、カスタムデータベーススクリプト、Auth0 Dashboardのメールプロバイダー構成画面にリストがあります。

これがホスティング環境によって自動的に処理されない場合は、NTP（ネットワークタイムプロトコル）が失敗した場合に自動的に再起動するスクリプトと、NTPが実行されていない場合に通知するアラートを用意する必要があります。認証トランザクションは正確なシステム時刻に依存します。これは、送信システムと受信システムの間に時刻の不一致がある場合、セキュリティトークンが受信時に期限切れと評価される可能性があるためです。

AD/LDAPコネクタを使用する場合は、環境内のロードバランサー設定を確認して、非アクティブで長時間実行されている接続が終了するかどうかを確認する必要があります。終了する場合は、Auth0 AD/LDAP接続設定を変更して、LDAP_HEARTBEAT_SECONDS設定を使用して定期的にハートビートメッセージを送信し、接続を開いたままにすることができます。

アプリケーションがサーバー状態を維持し、ユーザーを特定のサーバーにルーティングするためにスティッキーロードバランシングに依存する場合は、すべてのロードバランサー構成が正しいことを再確認することを勧めします。プール内の1つのロードバランサーが同期していないと、トラブルシューティングが困難な断続的なエラーが発生する可能性があります。ロードバランサーの設定をすばやくチェックすることで、そのような問題を未然に防ぐことができます。

ログデータをキャプチャする機能がセットアップされていること、ログがデータ保持ポリシーの対象となっていること、およびログデータの保持制限を適用するメカニズムがあることを確認する必要があります。また、開発、サポート、およびセキュリティチームが、トラブルシューティングとフォレンジックの目的でログデータにアクセスする方法を知っていることを確認する必要があります。包括的な分析を提供するサービスにログファイルをエクスポートすると、使用傾向やエラーなどのパターンを特定するのに役立ちます。

Auth0には、イベントのログを記録したり、異常なイベントの特定にログを調べたりするための豊富な機能が備わっています（詳細についてはログのドキュメントを参照してください）。Auth0ログの標準的な保持制限はサブスクリプションのレベルによって決定され、最も短い期間は2日、最も長い期間は30日です。Auth0は外部のログサービスとの統合に対応しているため、外部でログを保持する他にも、組織全体でログを集積することができます。

ログデータを外部のログ分析サービスに転送するには、サブスクリプションのレベルでログデータの保持期間を確認し、ログデータのエクスポートサービスを実装してください。Auth0 Marketplaceで提供しているログストリーミングソリューションの1つを使用することができます。

開発チームは、トラブルシューティングやQAテストでは見つけにくい断続的なエラーを検出するためにログファイルを使用できます。セキュリティチームは、フォレンジックデータが必要になるときのために、ログデータを取得しておきたいかもしれません。総合的な分析を行うサービスにログファイルをエクスポートすると、利用の傾向や攻撃防御のトリガーなどのパターンを理解するのに役立てることができます。

Auth0はレート制限の超過で報告されるエラーに一意のエラーコードを提供します。ログの自動スキャンをセットアップしてレート制限エラーを確認し、ユーザーに影響が及ぶ前に、レート制限を超えそうなアクティビティに予見的に対処することが賢明です。Auth0は他のエラータイプのエラーコードも公開しており、認証エラーやAuth0 Management API呼び出し（Management APIのエラーコードはManagement API Explorerで呼び出しの下部に表示されます）について、ログを調べるのに役立ちます。

Auth0サービスのプロアクティブな監視と、アプリケーションを介したエンドツーエンド認証をセットアップしてください。

Auth0実装の監視メカニズムを設置して、サポートチームや運用チームが適時な情報を受け取り、サービスの停止に予見的に対処できるようにします。Auth0は監視エンドポイントを提供し、監視インフラストラクチャに組み込めるようにしています。これらのエンドポイントは、監視サービスの使用に適した応答を返すように設計されています。提供するのがAuth0についてのデータのみであることに注意してください。完全なエンドツーエンド監視は、ユーザーがログインできることを確認するには不可欠ですが、合成トランザクションをセットアップすることをお勧めします。監視がより細やかになり、Auth0に無関係な停止や性能の劣化が検知できるため、さらに予見的に対処することができます。

重要なアナウンスや変更点を常に把握するため、以下のAuth0からの通信チャネルをすべて監視していることを確認する必要があります。

Auth0からの注意を払うべき通知にはいくつかの異なる種類があり、テナントやプロジェクトに影響を与えかねない重要な情報が含まれています。

Auth0は時々、テナントに関する重要な告知を送信します。サービスについてのこれらの告知はAuth0 Dashboardに送信され、告知内容の重要度によっては、登録済のAuth0 Dashboard管理者にメールで通達されます。Dashboardには定期的にログインし、画面上部のベルアイコンで重要なお知らせが届いていないかを確認してください。また、Auth0からのメールには対処が必要な変更についての重要情報が含まれていることがある、必ず適時に確認してください。

Auth0は定期的にセキュリティ関連のテストを行います。問題を発見すると、事前対処として特定し、セキュリティ関連の変更が必要な顧客に通知します。ただし、Auth0製品には拡張性があり、影響を受ける顧客をすべて特定することが不可能かもしれないため、Auth0のセキュリティ速報は定期的に確認してください。組織のセキュリティ連絡先がサポートセンターに記載されていることを確認する必要があります。

Auth0はサービスに対する変更の情報をAuth0の変更履歴に記載します。Auth0の変更履歴は定期的に確認し、変更内容を理解するようにしてください。サポートチームが問題を調査するときには変更履歴を確認し、最近の変更の中でも特に互換性のない変更への関連性を判断するのに役立つかもしれません。開発チームにとっても、有益な新機能を見つけるには変更履歴が便利です。

さらに、定期的に Auth0 migrationsページをチェックし、今後予定されている非推奨の変更に関するニュースを確認する必要があります。

必須ではありませんが、導入の自動化をセットアップすることを強くお勧めします。開発、テスト、および運用環境に変更を導入して元に戻す機能を自動化しておくと、起動後に変更を加える必要がある場合に、より効率的に対応できます。

変更管理とQAのベストプラクティスを採用するだけでなく、成功する顧客はAuth0の資産管理を自動化された導入プロセスの一部として統合します。SDLCサポートのアーキテクチャセクションで説明されているように、開発・テスト・運用環境用に個別のAuth0テナントを構成し、各環境でのテナントの構成がほぼ同じであるようにします。導入を自動化すれば、各環境のテナントが確実に同じ構成になるため、環境間での構成の不一致に起因するバグがほとんど生じなくなります。

Auto0では、2つの方法で導入を自動化することができ、必要であれば両方を組み合わせることもできます。

• Auth0 Deploy CLIツーリングでは、使いやすいスクリプトを利用して既存の継続的統合/継続的導入（CI/CD）パイプラインと簡単に統合できます。

• 直接統合できない場合や、CI/CDパイプラインがない場合は、Auth0のSource Control Extensions（ソースコントロール拡張機能）を使用することで、簡単に設定できる基本的な自動化プロセスを提供し、非常にわずかなメンテナンスで済ませることができます。

それぞれの環境で異なる構成が必要なこと（たとえば、アプリケーションクライアントIDやクライアントシークレットがAuth0テナントごとに異なる、など）もあるため、ハードコード化した値ではなく、異なる値を動的に参照できる何らかの方法が必要になります。Auth0は、環境によって異なる構成情報を扱う方法として、以下の2つをサポートしています。

• テナント固有の値

• Auth0 Deploy CLIツールを使用している場合、キーワード置換を使用する

Auth0を使用すると、カスタム拡張性内から使用できる変数を構成できます。これらは、Auth0テナントの環境変数とみなすことができます。ハードコード化された参照は、開発・テスト・運用環境間で移動すると変わってしまうため、代わりに、テナントで構成され、カスタムの拡張コードによって参照される変数名を使用することができます。コードが変数を参照すれば、実行時にテナント固有の値が書き込まれるため、同じカスタムコードを異なるテナントで問題なく使用できます。

• アクションでの変数の使用については、Write Your First Action（最初のアクションを書く）をご覧いただき、エディターでのシーレットの設定方法を参照してください。

• ルールでの変数の使用については、値の設定方法

• フックでの変数の使用については、エディターでシークレットの設定方法を参照してください

• カスタムDBスクリプトでの変数の使用については、設定パラメーター

プロジェクトに必要なバックアップ/復元機能をサポートするための計画とメカニズムを用意しておく必要があります。これは、データ用のAuth0 Management APIと、Auth0構成の自動デプロイメントに関するセクションで説明されている自動デプロイメント機能を使用して行うことができます。

Auth0 ［Data Tenant Restore policy（データテナントリストアポリシー）］と［Data Transfer policy（データ転送ポリシー）］に記載されているように、Auth0 は削除されたテナントのリストアやテナント間のデータ移動は行いません。Auth0は、Auth0 Management APIを提供し、必要に応じてデータのバックアップ、復元、移動を行う柔軟な機能を提供します。バックアップ目的でAuth0からデータを取得するスクリプトを作成したり、Auth0構成のあらゆる側面を復元するために自動導入機能で使用するスクリプトを作成したりすることができます。

アプリケーションスタック内のすべてのテクノロジーと、ユーザーが使用するブラウザーのバージョンが最新のバージョンであることを再確認する必要があります。これは、問題が発生した場合にAuth0がサポートを提供する能力に影響します。

• ［Auth0 dashboard settings（Auth0ダッシュボードの設定）］で、サポートされている最新バージョンのnode.jsを使用していることを確認します。

• ［Auth0 Support Matrix（Auth0サポートマトリックス）］に従って、Auth0でサポートされているSDK/ライブラリのバージョンを使用していることを確認します。

証明書はID導入で使用できます。証明書の有効期限切れが突然発生しないようにするには、環境内の証明書のリストと有効期限、有効期限が近づいたときに通知する方法、証明書のロールオーバープロセスの動作方法を用意しておく必要があります。

SAML接続の場合は、IdPから証明書を取得し、Auth0 DashboardのIdPのSAML接続にアップロードします。これらの証明書のいずれかの有効期限が切れそうになると、Auth0はダッシュボード管理者に有効期限が近づいていることを警告するメールを送信します。新しい証明書を取得し、接続構成画面を使用してアップロードできます。

WS-Fed接続の場合、ADFSURLを指定して構成すると、すべての変更が毎日の更新で取得されます。Auth0 Dashboardの接続設定ページにアクセスし、［Save（保存）］を実行することで、手動で更新をトリガーできます。リモートIdPで証明書が変更された場合、Auth0はそれらのメカニズムによって、または同じ接続設定画面で新しいメタデータファイルをアップロードすることによって更新することができます。

開始前の絶対要件ではありませんが、システムの停止や、重要なスタッフが配置されている地域を襲う自然災害など、さまざまな種類の災害に直面した場合にビジネス継続性を確保するために、Disaster Recovery計画を実施しておくことは有用です。

絶対的な要件ではありませんが、推奨されるもう1つの項目は、Auth0 に関連するすべてのプロセスが文書化されていることを確認することです。これには、次のものが含まれます。

• 構成の変更管理

• 新しい変更の導入と使用される自動導入メカニズム、問題が見つかった場合に以前のバージョンに戻す方法

• 証明書ロールオーバープロセス（存在する場合）

• 新しいIDプロバイダーの追加または削除（該当する場合）

• Auth0内またはAuth0が取得するディレクトリ内のユーザープロファイル構造の変更

• アプリケーションまたはAPIの追加または削除

• ログの取得とエクスポート

• 実装したバックアップ/復元プロセス

• ユーザー管理（パスワード忘れ、電話の紛失）

• インシデント発生後の根本原因分析

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。