> ## Documentation Index > Fetch the complete documentation index at: https://auth0.com/llms.txt > Use this file to discover all available pages before exploring further. # 運用準備（B2B） > B2B IAM実装の開始前に行うべき運用チェック。 ## ステータス 運用スタッフはAuth0の監視方法を理解して、Auth0ステータスを更新するために登録手段の手配を整えている必要があります。 Auth0の[ステータスダッシュボート](https://status.auth0.com/)と[稼働時間ダッシュボート](http://uptime.auth0.com/)には、Auth0サービスの過去と現在のステータスが人間に読める形式で表示されます。追跡アラートが発生したら、トラブルシューティングの第1段階として、運用スタッフは必ずステータスダッシュボートで現在の停止状態を確認してください。パブリッククラウドのステータスページにも、機能停止の通知を受け取るように登録する手段があります。また、ソーシャルプロバイダーなど、依存関係にあるサードパーティーの[外部サービス](/docs/ja-jp/deploy-monitor/monitor/check-external-services-status)でもステータスを確認するようにしてください。この情報はトラブルシューティングで可能性のある原因を除外するのに役立つため、開発者やヘルプデスク担当者はトラブルシューティングのチェックリストで必ず最優先の確認事項にしてください。 ### ベストプラクティス Auth0および依存するサービス（ソーシャルプロバイダーなど）の状態を確認する方法に関する情報は、開発者とヘルプデスクスタッフにとって、トラブルシューティングチェックリストのトップに来るべきです。Auth0のステータスページで利用登録し、ステータスの更新通知を受け取るようにセットアップすることをお勧めします。 パブリッククラウドサービスが停止すると、Auth0は根本原因分析（RCA）を行い、その結果をAuth0のステータスページで公開します。Auth0は停止後に、根本原因の特定、寄与要因、再発防止方法などを含めた徹底的な調査を行うため、RCAドキュメントの公開には数週間かかることがあります。 ## メールプロバイダーのセットアップ サインアップ、メール検証、アカウント復元などのために、実運用では大量のメールがお客様に送信される可能性があります。そのような状況に対応できるよう、独自のメールプロバイダーをセットアップしていることを再確認してください。 サインアップの歓迎、メール検証、パスワード漏洩、パスワードリセットのイベントなどについて、Auth0はユーザーに[メール](/docs/ja-jp/customize/email)を送信します。イベントタイプのそれぞれにメールテンプレートをカスタマイズすることができます。また、メールの扱いを細やかにカスタマイズすることもできます。Auth0はテストメールプロバイダーを提供していますが、基本的なテスト用に機能が制限されているため、運用での使用には独自のメールプロバイダーをセットアップしなければなりません。メールテンプレートのカスタマイズは、独自のプロバイダーを確立するまで動作しません。 ### ベストプラクティス デフォルトのAuth0メールプロバイダーは、大量のメールの送信やメールテンプレートのカスタマイズに対応していません。運用環境にデプロイする前に独自のメールプロバイダーを設定するようにしましょう。 ## インフラストラクチャ ### ファイアウォール Auth0で実行するカスタムコード（アクション、ルール、フック、カスタムデータベーススクリプト）がネットワーク内のサービスを呼び出す場合、または、Auth0でオンプレミスSMTPプロバイダーを構成した場合は、[Auth0からのインバウンドトラフィック](/docs/ja-jp/secure/security-guidance/data-security/allowlist)を許可するようにファイアウォールを構成しなければならないことがあります。ファイヤーウォールを通過できるIPアドレスは各リージョンに特有で、ルール、フック、カスタムデータベーススクリプト、Auth0 Dashboardのメールプロバイダー構成画面にリストがあります。 ## NTP これがホスト環境で自動的に処理されない場合には、失敗時に NTP (ネットワークタイムプロトコル) を自動的に再起動するスクリプトと、NTPが動作していない場合に通知するアラートを用意する必要があります。認証トランザクションには正確なシステム時間が必要です。送信システムと受信システムの間に時間の相違がある場合、セキュリティトークンの受信時に失効と判定される可能性があるためです。 ## ロードバランサーのタイムアウト確認 AD/LDAPコネクターを使用する場合は、環境内のロードバランサー設定をチェックして、非アクティブな長時間接続を終了するようになっていないかを確認する必要があります。終了している場合には、`LDAP_HEARTBEAT_SECONDS`設定を使用して定期的にハートビートメッセージを送信するように[Auth0 AD/LDAP接続設定](/docs/ja-jp/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/ad-ldap-connector-to-auth0)を変更して、接続を開いたままにすることができます。 ## ロードバランサーの構成 アプリケーションが、ユーザーを特定のサーバーにルーティングするためにスティッキーロードバランシングを使用してサーバーの状態を維持している場合には、すべてのロードバランサーの構成が正しいことを再確認すると効果的です。予備のロードバランサーの中に構成の一致しないものが1つでもあると、断続的なエラーが発生してトラブルシューティングが難しくなる場合があります。ロードバランサーの構成を簡単に確認すれば、初めからこのような問題を避けられます。 ## ログ ログデータをキャプチャする機能が設定されていること、ログにデータ保持ポリシーが適用されていること、ログデータの保持制限を徹底する仕組みがあることを確認してください。また、開発、サポート、セキュリティの各チームが、トラブルシューティングやフォレンジックのためにログデータにアクセスする方法を理解していることも確認してください。総合的な分析を行うサービスにログファイルをエクスポートすると、利用の傾向やエラーなどのパターンを特定するのに役立てることができます。 Auth0には、イベントのログを記録したり、異常なイベントの特定にログを調べたりするための豊富な機能が備わっています（詳細については[ログのドキュメント](/docs/ja-jp/deploy-monitor/logs)を参照してください）。Auth0ログの標準的な保持制限はサブスクリプションのレベルによって決定され、最も短い期間は2日、最も長い期間は30日です。Auth0は外部のログサービスとの統合に対応しているため、外部でログを保持する他にも、組織全体でログを集積することができます。 ### ベストプラクティス ログデータを外部のログ分析サービスに送信するには、ログストリーミングソリューションをぜひご活用ください。データの長期保存とログデータに対する高度な分析を可能にします。 ログデータを外部のログ分析サービスに転送するには、サブスクリプションのレベルでログデータの[保持期間](/docs/ja-jp/deploy-monitor/logs/log-data-retention)を確認し、ログデータのエクスポート拡張機能を実装してください。Auth0 Marketplaceで提供している[ログストリーミングソリューション](https://marketplace.auth0.com/features/log-streaming)の1つを使用することができます。 開発チームは、トラブルシューティングやQAテストでは見つけにくい断続的なエラーを検出するためにログファイルを使用できます。セキュリティチームは、フォレンジックデータが必要になるときのために、ログデータを取得しておきたいかもしれません。総合的な分析を行うサービスにログファイルをエクスポートすると、利用の傾向や攻撃防御のトリガーなどのパターンを理解するのに役立てることができます。 ### レート制限とその他のエラー Auth0は[レート制限の超過](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)で報告されるエラーに一意のエラーコードを提供します。ログの自動スキャンを設定してレート制限エラーを確認し、ユーザーに影響が及ぶ前に、レート制限を超えそうなアクティビティに予見的に対処することが賢明です。Auth0は他のエラータイプのエラーコードも公開しており、[認証エラー](/docs/ja-jp/libraries/common-auth0-library-authentication-errors)やAuth0 Management API呼び出し（Management APIのエラーコードは[Management API Explorer](/docs/ja-jp/api/management/v2)で呼び出しの下部に表示されます）について、ログを調べるのに役立ちます。 ### ベストプラクティス ルール内からユーザープロファイル情報を取得するためにManagement APIを呼び出すことは、レート制限の発生の一般的な原因になります。なぜなら、そのようなAPIはすべてのログインと定期的なセッションチェックを呼び出すからです。 ## 監視 Auth0サービスの予見的な監視と、アプリケーションを介したエンドツーエンドの認証を必ず設定してください。 [Auth0実装の監視](/docs/ja-jp/deploy-monitor/monitor)メカニズムを設置して、サポートチームや運用チームが適時な情報を受け取り、サービスの停止に予見的に対処できるようにします。Auth0は監視エンドポイントを提供し、監視インフラストラクチャに組み込めるようにしています。これらのエンドポイントは、監視サービスの使用に適した応答を返すように設計されています。提供するのがAuth0についてのデータのみであることに注意してください。完全なエンドツーエンド監視は、ユーザーがログインできることを確認するには不可欠ですが、[合成トランザクション](https://auth0.com/docs/deploy-monitor/monitor/monitor-applications)をセットアップすることをお勧めします。監視がより細やかになり、Auth0に無関係な停止や性能の劣化が検知できるため、さらに予見的に対処することができます。 ### ベストプラクティス 代理ログイントランザクションを送信できる機能をセットアップすることで、認証のエンドツーエンドのモニタリングが容易になります。これは[リソース所有者パスワード付与](/docs/ja-jp/api-auth/tutorials/password-grant)と権限のないテストユーザーを組み合わせて使用する簡単なアプリケーションで行うことができます。[Auth0レート制限ポリシー](/docs/ja-jp/policies/rate-limits)についてもご確認ください。 ## Auth0の通知 重要な告知や変更を常に把握できるように、チームは次にあげるAuth0のコミュニケーションチャネルをすべて注視するようにしてください。 Auth0からの注意を払うべき通知にはいくつかの異なる種類があり、テナントやプロジェクトに影響を与えかねない重要な情報が含まれています。 Auth0によって、予見的なセキュリティ通知など、操作に関する告知がダッシュボード管理者に送信されます。これらのメッセージを受け取るべき人がダッシュボード管理者になっていることを確認してください。 ### Dashboardの通知 Auth0は時々、テナントに関する重要な告知を送信します。サービスについてのこれらの告知はAuth0 Dashboardに送信され、告知内容の重要度によっては、登録済のAuth0 Dashboard管理者にメールで通達されます。Dashboardには定期的にログインし、画面上部のベルアイコンで重要なお知らせが届いていないかを確認してください。また、Auth0からのメールには対処が必要な変更についての重要情報が含まれていることがある、必ず適時に確認してください。 ### Auth0のセキュリティ情報 Auth0は定期的にセキュリティ関連のテストを行います。問題を発見すると、事前対処として特定し、セキュリティ関連の変更が必要な顧客に通知します。ただし、Auth0製品には拡張性があり、影響を受ける顧客をすべて特定することが不可能かもしれないため、Auth0の[セキュリティ速報](/docs/ja-jp/secure)は定期的に確認してください。組織のセキュリティ連絡先がサポートセンターに登録されていることを確認してください。 ### ベストプラクティス 定期的にAuth0 [「セキュリティ情報」](/docs/ja-jp/security/bulletins)ページを確認し、セキュリティ情報の影響を受けている場合には、推奨される対策を講じることがベストプラクティスです。 ### 変更履歴 Auth0はサービスに対する変更の情報をAuth0の[変更履歴](https://auth0.com/changelog)に記載します。Auth0の変更履歴は定期的に確認し、変更内容を理解するようにしてください。サポートチームが問題を調査するときには変更履歴を確認し、最近の変更の中でも特に互換性のない変更への関連性を判断するのに役立つかもしれません。開発チームにとっても、有益な新機能を見つけるには変更履歴が便利です。 さらに、今後の廃止については、チームによる変更対応が必要な可能性もあるため、[Auth0の移行ページ](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations)でニュースを定期的に確認してください。 ## デプロイメントとバージョン管理の自動化 必須ではありませんが、バージョン管理による自動デプロイメントの設定をお勧めします。開発、テスト、運用の各環境に変更をデプロイする際や復元する際に自動化を使用することで、リリース後の問題への対応を効率化できます。 成功するお客様は、変更管理と[QA](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/quality-assurance)のベストプラクティスを採用するだけでなく、デプロイメントを自動化するプロセスの一環としてAuth0付随の管理も統合しています。[SDLCサポート](/docs/ja-jp/architecture-scenarios/b2c/architecture#sdlc-support)のアーキテクチャセクションで説明されているように、開発・テスト・運用環境用に個別のAuth0テナントを構成し、各環境でのテナントの構成を同じにしてください。デプロイメントの自動化を活用すれば、環境間でテナント構成が一致していることが保証されるため、バグやその他の問題を削減できます。 ### ベストプラクティス デプロイメントの自動化を構成しても、デプロイメント前にルール、カスタムDBスクリプト、フックをユニットテストし、デプロイメント後のテナントに対していくつかの統合テストも実行することをお勧めします。詳細は、[「品質保証」](/docs/ja-jp/architecture-scenarios/b2c/quality-assurance)のガイダンスをご覧ください。 Auth0は、以下のデプロイメント自動化方法に対応しており、必要に応じて組み合わせて使用​​できます。 * [Auth0 Deploy CLIツーリング](/docs/ja-jp/deploy-monitor/deploy-cli-tool)では、使いやすいスクリプトを利用して既存の継続的統合/継続的デプロイメント（CI/CD）パイプラインと簡単に統合できます。 * CI/CDパイプラインがない場合、またはCI/CDパイプラインと直接統合できない場合、Auth0 [Source Control Extensions](/docs/ja-jp/customize/extensions)（ソースコントロール拡張機能）を使用することで、簡単に設定できる基本的な自動化プロセスを提供し、非常にわずかなメンテナンスで済ませることができます。 * 開発ワークフローで[Terraform](https://www.terraform.io/)を利用している場合は、[Auth0 Terraform Provider](/docs/ja-jp/deploy-monitor/auth0-terraform-provider)を使用してAuth0テナント構成を管理できます。 Deploy CLIツールとソース制御拡張機能は、どちらも破壊的な変更を引き起こす恐れがあります。自動デプロイメントの合間にダッシュボードで手動で行った変更が失われる可能性があるためです。そのため、いずれかを使用する場合は、**すべて** の変更を、ツールを介して参照元のソース制御サブシステムから導入するようにします。 それぞれの環境で異なる構成が必要なこと（たとえば、アプリケーションクライアントIDやクライアントシークレットがテナントごとに異なる、など）もあるため、ハードコード化した値ではなく、異なる値を動的に参照できる何らかの方法が必要になります。Auth0は、環境によって異なる構成情報を扱う方法として、以下の2つをサポートしています。 * [テナント固有の値](#tenant-specific-variables)を使用する * Auth0 Deploy CLIツールを使用している場合、[キーワード置換](/docs/ja-jp/deploy-monitor/deploy-cli-tool/configure-the-deploy-cli)を使用する ## テナント固有の値 Auth0を使用すると、カスタム[拡張性](/docs/ja-jp/customize/extensions)内から使用できる変数を構成できます。これらは、Auth0テナントの環境変数とみなすことができます。ハードコード化された参照は、開発・テスト・運用環境間で移動すると変わってしまうため、代わりに、テナントで構成され、カスタムの拡張コードによって参照される変数名を使用することができます。コードが変数を参照すれば、実行時にテナント固有の値が書き込まれるため、同じカスタムコードを異なるテナントで問題なく使用できます。 * アクションでの変数の使用については、「[初めてアクションを作成する](/docs/ja-jp/customize/actions/write-your-first-action)」を読んで、エディターでのシーレットの構成方法を参照してください。 * ルールでの変数の使用については、[値の設定](/docs/ja-jp/customize/rules/configuration)方法を参照してください * フックでの変数の使用については、エディターで[シークレット](/docs/ja-jp/customize/hooks/hook-secrets)の設定方法を参照してください * カスタムDBスクリプトでの変数の使用については、[設定パラメーター](/docs/ja-jp/connections/database/custom-db/create-db-connection#step-3-add-configuration-parameters)を参照してください ### ベストプラクティス テナント固有の値やカスタムコードで公開されるべきではない機密情報を含むために、変数を使用することが推奨されるベストプラクティスです。カスタムコードがGitHub/Gitlab/Bitbucket/VSTSにデプロイされている場合、テナント固有の変数を使用することでリポジトリを通じた機密値の公開を避けられます。 ## バックアップ/復元 プロジェクトに必要なバックアップ/復元機能をサポートするための計画と仕組みを用意しておく必要があります。これは、データ用のAuth0 Management APIと、Auth0構成の自動デプロイメントセクションで説明した自動デプロイメント機能を使用して実行できます。 Auth0[データテナント復元ポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies)と[データ転送ポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/data-export-and-transfer-policy)に記載されているように、Auth0は削除済みのテナントを復元したり、テナント間でデータを移動したりしません。Auth0で用意されているAuth0 Management APIでは、お客様が必要に応じてデータをバックアップ、復元、移動できる、完全に柔軟な機能を提供しています。バックアップ目的でAuth0からデータを取得するスクリプトを作成したり、同様に、自動デプロイメント機能で使用するためのスクリプトを作成してAuth0構成のあらゆる側面を復元したりできます。 ## 最新バージョン 問題発生時にAuth0が提供できるサポート能力に影響するため、アプリケーションスタック内のすべてのテクノロジーと、ユーザーが使用するブラウザーが最新バージョンであることを再確認してください。 * [Auth0 Dashboardの設定](/docs/ja-jp/get-started/tenant-settings)で、最新のサポート対象バージョンのnode.jsを使用していることを確認する。 * [Auth0のサポートマトリックス](/docs/ja-jp/troubleshoot/customer-support/product-support-matrix)で、Auth0のサポート対象バージョンのSDK/ライブラリーを使用していることを確認する。 ## 証明書のロールオーバー計画 証明書は、IDの導入で使用される場合があります。証明書が突然有効期限切れにならないようにするには、環境内の証明書と有効期限のリスト、有効期限が近づいたときに通知する方法、証明書のロールオーバープロセスの手順を用意しておく必要があります。 ### SAML接続 SAML接続の場合、IdPから証明書を取得し、Auth0 Dashboard内でIdP用にSAML接続へアップロードします。これらの証明書のいずれかが有効期限に近づくと、Auth0は有効期限が近づいていることを警告するメールをダッシュボード管理者に送信します。新しい証明書を取得し、接続構成画面を使用してアップロードすることができます。 ### WS-Fed接続 Webサービスフェデレーション（WS-Fed）接続の場合、ADFS URLを指定して接続を構成すると、変更があったときには日次更新によって反映されます。手動で更新をトリガーするには、Auth0 Dashboardの接続構成ページにアクセスしてSave（保存）します。リモートIdPで証明書が変更された場合、Auth0の更新は、これらのメカニズムによって、または同じ接続構成画面で新しいメタデータファイルをアップロードすることによって実施できます。 ## 災害復旧/事業継続の計画 ローンチ前の絶対的要件ではありませんが、システム停止や重要なスタッフがいる地域が自然災害に襲われるなど、さまざまな種類の災害に直面した場合にも事業継続性を確保するために、災害復旧計画を用意しておくことは有用です。 ## 手順の文書化 これも絶対的要件ではありませんが、Auth0に関連するすべての手順を文書化することをお勧めします。以下のような内容を文書化します。 * 構成の変更管理 * 新しい変更のデプロイメント、自動デプロイメントを使用している場合はその仕組み、問題が見つかった場合に旧バージョンへ戻す方法 * 証明書のロールオーバー手順 (ある場合) * 新しいIDプロバイダーの追加または削除 (該当する場合) * Auth0内またはAuth0が取得するディレクトリ内のユーザープロファイル構造の変更 * アプリケーションやAPIの追加または削除 * ログのキャプチャとエクスポート * 実装したバックアップ/復元の手順 * ユーザー管理 (パスワード忘れ、電話の紛失） * インシデント発生後の根本原因分析 ## プロジェクト計画ガイド 当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。 [B2B IAM Project Planning Guide](http:///assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)