> ## Documentation Index
> Fetch the complete documentation index at: https://auth0-actions-modules-ga.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> B2B IAM 実装のローンチ前に行う運用チェック。

# 運用準備 (B2B)

<h2 id="status">
  ステータス
</h2>

運用担当者が Auth0 のサービスステータスを監視する方法を把握し、Auth0 のステータス更新通知を受け取る手段を設定していることを確認してください。

Auth0 の [ステータスダッシュボード](https://status.auth0.com/) と Auth0 の [稼働状況ダッシュボード](http://uptime.auth0.com/) では、Auth0 サービスの現在および過去のステータスを、人が見てわかりやすい形式で確認できます。監視アラートが発生した場合は、トラブルシューティングの最初の手順として、運用担当者はステータスダッシュボードを確認し、現在障害が発生していないかを確認する必要があります。パブリッククラウドのステータスページでは障害通知を受け取るための登録もできるため、Social Providers など、依存しているサードパーティの [外部サービス](/docs/ja-jp/deploy-monitor/monitor/check-external-services-status) のステータスも併せて確認することをお勧めします。こうした情報をすぐに参照できるようにしておくと、問題のトラブルシューティング時に考えられる原因をすばやく切り分けるのに役立ちます。これは、開発者だけでなくヘルプデスク担当者にとっても、トラブルシューティングのチェックリストの最上位に置くべき項目です。

<Info>
  <h3 id="best-practice">
    ベストプラクティス
  </h3>

  Auth0 および依存サービス (Social Providers など) のステータスを確認する方法に関する情報は、開発者とヘルプデスク担当者の両方にとって、トラブルシューティングのチェックリストの最上位に置くべきです。また、ステータス更新の通知を受け取れるよう、Auth0 のステータスページから登録しておくことをお勧めします。
</Info>

パブリッククラウドサービスで障害が発生した場合、Auth0 は Root Cause Analysis (RCA) を実施し、その結果を Auth0 のステータスページで公開します。Auth0 は障害発生後、根本原因の特定に加え、寄与要因の分析や再発防止策の検討を含む徹底的な調査を行うため、RCA 文書の公開までに数週間かかることがあります。

<h2 id="email-provider-setup">
  メールプロバイダーの設定
</h2>

サインアップ、メールアドレスのバリデーション、アカウント復旧などで顧客に送信される可能性がある本番環境向けのメール配信量に対応できるよう、独自のメールプロバイダーが設定されていることを必ず再確認してください。

Auth0 は、サインアップ時のウェルカムメール、メールアドレスのバリデーション、漏えいしたパスワード、パスワードリセットなどのイベントに応じて、ユーザーに[メール](/docs/ja-jp/customize/email)を送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理自体をさらに高度にカスタマイズすることも可能です。Auth0 には、基本的なテスト用として容量が限られたテストメールプロバイダーが用意されていますが、本番利用には独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまで、メールテンプレートのカスタマイズは機能しません。

<Info>
  <h3 id="best-practice-2">
    ベストプラクティス
  </h3>

  Auth0 のデフォルトのメールプロバイダーは、本番環境レベルのメール送信量やメールテンプレートのカスタマイズには対応していません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定してください。
</Info>

<h2 id="infrastructure">
  インフラストラクチャ
</h2>

<h3 id="firewalls">
  ファイアウォール
</h3>

Auth0 で実行されるカスタムコード (Action、Rule、Hook、またはカスタムデータベーススクリプトなど) からお使いのネットワーク内のサービスを呼び出す場合や、Auth0 でオンプレミスの SMTP プロバイダーを設定する場合は、[Auth0 からの受信トラフィック](/docs/ja-jp/secure/security-guidance/data-security/allowlist)を許可するようにファイアウォールを設定する必要が生じることがあります。ファイアウォールで許可する IP アドレスはリージョンごとに異なり、<Tooltip tip="サービスを設定するための Auth0 の主要製品です。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Auth0+dashboard">Auth0 Dashboard</Tooltip> のルール、Hooks、カスタムデータベーススクリプト、およびメールプロバイダーの設定画面に一覧表示されています。

<h2 id="ntp">
  NTP
</h2>

ホスティング環境でこれが自動的に処理されない場合は、NTP (Network Time Protocol) に障害が発生した際に自動的に再起動するスクリプトと、NTPが停止している場合に担当者へ通知するアラートを用意する必要があります。認証トランザクションは、正確なシステム時刻に依存しています。送信側と受信側のシステム間で時刻のずれがあると、<Tooltip tip="Security Token: ユーザーの認証が正常に完了したことを証明するために使われる、デジタル署名された成果物。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=security+tokens">セキュリティトークン</Tooltip>が受信時に期限切れと判定されることがあるためです。

<h2 id="loadbalancer-timeouts-checked">
  LoadBalancer のタイムアウトを確認する
</h2>

AD/LDAP Connector を使用している場合は、環境内のロードバランサーの設定を確認し、非アクティブな長時間接続を切断するようになっていないか確認してください。切断する設定になっている場合は、[Auth0 AD/LDAP 接続の設定](/docs/ja-jp/authenticate/identity-providers/enterprise-identity-providers/active-directory-ldap/ad-ldap-connector/ad-ldap-connector-to-auth0)を変更して `LDAP_HEARTBEAT_SECONDS` 設定を使用し、定期的にハートビートメッセージを送信することで、接続を維持できます。

<h2 id="loadbalancer-configuration">
  LoadBalancer の設定
</h2>

アプリケーションがサーバー側で状態を保持しており、ユーザーを特定のサーバーに振り分けるためにスティッキー負荷分散に依存している場合は、すべてのロードバランサーの設定が正しいことをあらためて確認しておくとよいでしょう。プール内のロードバランサーのうち1台でも設定の同期が取れていないと、原因の特定が難しい断続的なエラーが発生することがあります。ロードバランサーの設定をひととおり確認しておけば、こうした問題を未然に防げます。

<h2 id="logs">
  ログ
</h2>

ログデータを取得できるよう設定されていること、ログがデータ保持ポリシーの対象になっていること、さらにログデータの保持上限を適用する仕組みがあることを確認してください。また、開発チーム、サポートチーム、セキュリティチームが、トラブルシューティングやフォレンジックの目的でログデータにアクセスする方法を把握していることも確認してください。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、利用傾向やエラーなどのパターンを特定しやすくなります。

Auth0 には、イベントのログ記録や、イベントの異常を特定するためのログのスキャンに関する幅広い機能があります (詳しくは[ログのドキュメント](/docs/ja-jp/deploy-monitor/logs)を参照してください) 。Auth0 ログの標準的な保持期間はサブスクリプションレベルによって決まり、最短で 2 日、最長でも 30 日です。外部のログサービスとの連携に Auth0 Support を活用すれば、この期間を超えてログを保持できるほか、organization 全体でログを集約することも可能になります。

<Info>
  <h3 id="best-practice-3">
    ベストプラクティス
  </h3>

  ログデータを外部のログ分析サービスに送信するには、ログストリーミングソリューションのいずれかを活用してください。これにより、データをより長期間保持できるようになり、ログデータに対する高度な分析も可能になります。
</Info>

ご利用のサブスクリプションレベルにおけるログデータの[保持期間](/docs/ja-jp/deploy-monitor/logs/log-data-retention)を確認し、ログデータを外部のログ分析サービスに送信するためのログデータエクスポート extension を導入してください。Auth0 Marketplace にある当社の[ログストリーミングソリューション](https://marketplace.auth0.com/features/log-streaming)のいずれかを利用できます。

開発チームは、QA テストでは見つけにくい断続的なエラーのトラブルシューティングや検出にログファイルを活用できます。セキュリティチームも、フォレンジックデータが必要になった場合に備えて、ログデータを必要とする可能性があります。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、利用傾向や <Tooltip tip="攻撃対策: Auth0 が提供する、攻撃を検出して軽減するための機能です。これには、総当たり攻撃対策、不審な IP スロットリング、漏えいパスワードの検知、ボット検出、適応型多要素認証が含まれます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=attack+protection">攻撃対策</Tooltip> のトリガーなどのパターンを把握するのに役立ちます。

<h3 id="rate-limits-and-other-errors">
  レート制限とその他のエラー
</h3>

Auth0 では、[レート制限を超過した](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)際に報告されるエラーごとに固有のエラーコードを提供しています。レート制限エラーを確認できるようにログの自動スキャンを設定し、ユーザーに大きな影響が出る前に、レート制限に達するアクティビティへ先回りして対処することをおすすめします。Auth0 はこのほかの種類のエラーについてもエラーコードを公開しており、[認証エラー](/docs/ja-jp/libraries/common-auth0-library-authentication-errors)に加えて、Auth0 の<Tooltip tip="Management API: 顧客が管理タスクを実行するための製品。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip>呼び出しによるエラーについてもログをスキャンすると役立ちます (Management API のエラーコードは、[Management API Explorer](https://auth0.com/docs/api/management/v2) で各呼び出しの下に表示されます) 。

<Info>
  <h3 id="best-practice-4">
    ベストプラクティス
  </h3>

  Rule 内からユーザープロファイル情報を取得するために Management API を呼び出すことは、レート制限エラーのよくある原因です。これは、そのような API 呼び出しがログインのたびに実行される可能性があるうえ、定期的なセッションチェック時にも実行されるためです。
</Info>

<h2 id="monitoring">
  監視
</h2>

アプリケーション全体を通した認証のエンドツーエンド監視に加えて、Auth0 サービスのプロアクティブな監視も必ず設定してください。

サポートチームや運用チームがサービス停止に先回りして対応するために必要な情報を適時受け取れるよう、[Auth0 実装の監視](/docs/ja-jp/deploy-monitor/monitor)の仕組みを整備する必要があります。Auth0 では、監視インフラストラクチャに組み込める監視用エンドポイントを提供しています。これらのエンドポイントは、監視サービスで利用しやすい応答を返すよう設計されています。ただし、提供されるのは Auth0 に関するデータのみである点に注意してください。ユーザーがログインできるかどうかを確認するために不可欠な、完全なエンドツーエンド監視を行うには、[シンセティックトランザクション監視](/docs/ja-jp/deploy-monitor/monitor/monitor-applications)を設定することを推奨します。これにより、よりきめ細かな監視が可能になり、Auth0 に起因しない停止やパフォーマンス低下も検出できるため、より迅速かつ先回りした対応が可能になります。

<Info>
  <h3 id="best-practice-5">
    ベストプラクティス
  </h3>

  認証のエンドツーエンド監視を行いやすくするために、シンセティックなログイントランザクションを送信できるようにしておく必要があります。これは、権限を持たないテストユーザーと組み合わせて、[リソース所有者パスワードグラント](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow)を使用するシンプルなアプリケーションで実現できます。また、[Auth0 のレート制限ポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)も忘れないでください。
</Info>

<h2 id="auth0-notifications">
  Auth0 の通知
</h2>

重要なお知らせや変更を把握できるよう、Auth0 からの以下のすべての連絡チャネルをチームで確認するようにしてください。

Auth0 からは複数の種類の通知が送られてきます。これらには、テナントやプロジェクトに影響する可能性のある重要な情報が含まれているため、見落とさないよう注意が必要です。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Auth0 は、事前対応が必要なセキュリティ通知やその他の運用に関するお知らせを Auth0 Dashboard 管理者に送信します。こうしたメッセージを受け取る必要がある担当者が Auth0 Dashboard 管理者になっていることを確認してください。
</Callout>

<h3 id="dashboard-notifications">
  Auth0 Dashboard の通知
</h3>

Auth0 は、お客様のテナントに関する重要なお知らせを随時送信することがあります。こうしたサービスに関するお知らせは Auth0 Dashboard に送信され、重要度に応じて、登録済みの Auth0 Dashboard 管理者へメールでも送信されます。定期的に Auth0 Dashboard にログインし、画面上部のベルアイコンに重要なお知らせが届いていないか確認する習慣をつけてください。また、必要な変更や対応に関する重要な情報が含まれている可能性があるため、Auth0 からのメールも速やかに確認してください。

<h3 id="change-log">
  変更ログ
</h3>

Auth0 では、サービスの変更に関する情報を Auth0 の[変更ログ](https://auth0.com/changelog)で提供しています。変更を把握できるよう、Auth0 の変更ログを定期的に確認する習慣をつけてください。問題を調査しているサポートチームにとっては、最近の変更が関係している可能性がないかを確認するうえで、変更ログが役立つ場合があります。特に、互換性のない変更が含まれている場合は重要です。開発チームも、導入すると有益な新機能を見つけるために変更ログを確認するとよいでしょう。

また、チームでの対応が必要になる可能性のある今後の非推奨化に関する情報を確認するため、[Auth0 の移行ページ](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations)も定期的に確認してください。

<h2 id="automated-deployment-version-control">
  自動デプロイ、バージョン管理
</h2>

必須ではありませんが、バージョン管理とあわせて自動デプロイを導入することをお勧めします。自動化によって dev、test、production 環境への変更のデプロイや切り戻しを行えるようにしておくと、ローンチ後に問題が発生した場合でも、より効率的に対応できます。

変更管理や [QA](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/quality-assurance) のベストプラクティスを採り入れることに加え、導入に成功しているお客様は、自動デプロイのプロセスの一環として Auth0 の構成要素の管理も組み込んでいます。[SDLC のサポート](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/architecture#sdlc-support) の Architecture セクションで説明しているように、開発、テスト、本番環境ごとに個別の Auth0 テナントを構成しつつ、各環境で同じテナント設定になるようにする必要があります。デプロイの自動化を利用することで、環境間でテナント設定の一貫性を保ちやすくなり、バグやその他の問題の軽減につながります。

<Info>
  <h3 id="best-practice-6">
    ベストプラクティス
  </h3>

  デプロイ自動化の構成方法にかかわらず、デプロイ前にルール、Custom DB スクリプト、フックのユニットテストを行い、デプロイ後にはテナントに対して連携テストもいくつか実施することをお勧めします。詳細については、[Quality Assurance](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/quality-assurance) のガイダンスを参照してください。
</Info>

Auth0 では、必要に応じて組み合わせて使用できる、次のデプロイ自動化アプローチをサポートしています。

* [Auth0 Deploy CLI tooling](/docs/ja-jp/deploy-monitor/deploy-cli-tool) は、既存の Continuous Integration/Continuous Deployment (CI/CD) パイプラインと連携できる、使いやすいスクリプトを提供します。
* Auth0 の [Source Control Extensions](/docs/ja-jp/customize/extensions) は、CI/CD パイプラインがない場合や、CI/CD パイプラインと直接連携できない場合に、設定しやすく保守の手間も非常に少ない基本的な自動化プロセスを提供します。
* 開発ワークフローで [Terraform](https://www.terraform.io/) を利用している場合は、[Auth0 Terraform Provider](/docs/ja-jp/deploy-monitor/auth0-terraform-provider) を使って Auth0 テナント設定を管理できます。

<Warning>
  Deploy CLI Tool とソース管理拡張機能はいずれも破壊的な変更を引き起こす可能性がある点に注意してください。自動デプロイの合間にダッシュボードで直接加えた手動変更は失われるおそれがあります。そのため、いずれかを使用する場合は、**すべての**変更をツールが参照するソース管理サブシステムからデプロイし、手動では変更しないようにする必要があります。
</Warning>

また、各環境では環境固有の設定も必要になる場合があります。たとえば、アプリケーションの <Tooltip tip="Client ID: Auth0 によって登録済みリソースに付与される識別値。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Client+ID">Client ID</Tooltip> や <Tooltip tip="Client Secret: クライアント（アプリケーション）が認可サーバーで認証するために使用する Secret です。これはクライアントと認可サーバーだけが知っているべきものであり、推測できないよう十分にランダムである必要があります。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Client+Secrets">Client Secrets</Tooltip> は Auth0 テナントごとに異なります。そのため、値をハードコードするのではなく、これらを動的に参照できる何らかの方法が必要になります。Auth0 は、環境固有の設定情報を扱うために、次の 2 つのアプローチのいずれかをサポートしています。

* [Tenant Specific Variables](#tenant-specific-variables) を使用する
* Auth0 Deploy CLI tool を使用している場合は [keyword replacement](/docs/ja-jp/deploy-monitor/deploy-cli-tool/configure-the-deploy-cli) を使用する

<h2 id="tenant-specific-variables">
  テナント固有の変数
</h2>

Auth0 では、カスタム[拡張](/docs/ja-jp/customize/extensions)内から利用できる変数を設定できます。これは、Auth0 テナント用の環境変数と考えることができます。開発、テスト、Production 環境の間でコードを移動するたびに変わる参照をハードコードする代わりに、テナントで設定した変数名をカスタム拡張コードから参照できます。これにより、実行時にテナント固有の値が設定される変数をコードから参照できるため、同じカスタムコードを変更せずに異なるテナントでも使いやすくなります。

* Actions で変数を使用する場合は、エディターで secrets を設定する方法について [Write Your First Action](/docs/ja-jp/customize/actions/write-your-first-action) を参照してください
* ルール で変数を使用する場合は、[値を設定する](/docs/ja-jp/customize/rules/configuration)方法を参照してください
* Hooks で変数を使用する場合は、エディターで [secrets](/docs/ja-jp/customize/hooks/hook-secrets) を設定する方法を参照してください
* Custom DB Scripts で変数を使用する場合は、[設定パラメータ](/docs/ja-jp/authenticate/database-connections/custom-db/create-db-connection#step-3-add-configuration-parametersn#step-3-add-configuration-parameters)を参照してください

<Info>
  <h3 id="best-practice-7">
    ベストプラクティス
  </h3>

  テナント固有の値や、カスタムコード内で公開すべきでない機密性の高い secrets を保持するために、変数を使用することを推奨します。カスタムコードを GitHub/GitLab/Bitbucket/VSTS で管理している場合、テナント固有の変数を使用することで、リポジトリ経由で機密値が漏洩するのを防げます。
</Info>

<h2 id="backup-restore">
  バックアップ / 復元
</h2>

プロジェクトに必要なバックアップ / 復元機能に対応できるよう、あらかじめ計画と仕組みを整えておく必要があります。これは、データについては Auth0 Management API を使用し、Auth0 の設定については automated deployment セクションで説明している Automated Deployment 機能を使用することで実現できます。

Auth0 の [Data Tenant Restore policy](/docs/ja-jp/troubleshoot/customer-support/operational-policies) および [Data Transfer policy](/docs/ja-jp/troubleshoot/customer-support/operational-policies/data-export-and-transfer-policy) にあるとおり、Auth0 は削除されたテナントを復元せず、テナント間でデータを移動することもありません。Auth0 は、お客様が必要に応じてデータのバックアップ、復元、移動を柔軟に行えるよう、Auth0 Management API を提供しています。お客様は、バックアップを目的として Auth0 からデータを取得するスクリプトを作成でき、同様に Automated Deployment 機能と組み合わせて、Auth0 の設定のあらゆる要素を復元するためのスクリプトを作成することもできます。

<h2 id="versions-up-to-date">
  バージョンを最新の状態に保つ
</h2>

問題が発生した場合にAuth0のサポート提供へ影響する可能性があるため、アプリケーションスタックで使用しているすべてのテクノロジーと、ユーザーが使用するブラウザーが、いずれも最新のバージョンであることを必ず再確認してください。

* [Auth0 Dashboard の設定](/docs/ja-jp/get-started/tenant-settings)で、サポート対象の最新バージョンの node.js を使用していることを確認してください。
* [Auth0 Support Matrix](/docs/ja-jp/troubleshoot/customer-support/product-support-matrix)に基づき、Auth0 がサポートしているバージョンの SDK/ライブラリを使用していることを確認してください。

<h2 id="certificate-rollover-plan">
  証明書ロールオーバー計画
</h2>

証明書は、アイデンティティのデプロイで使用される場合があります。証明書の有効期限切れに不意を突かれないようにするには、環境内で使用している証明書の一覧とその有効期限日、有効期限が近づいた際の通知方法、そして証明書のロールオーバー手順を把握しておく必要があります。

<h3 id="saml-connections">
  SAML 接続
</h3>

<Tooltip tip="Security Assertion Markup Language (SAML): パスワードなしで 2 者間の認証情報のやり取りを可能にする標準化されたプロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=SAML">SAML</Tooltip> 接続では、<Tooltip tip="Security Assertion Markup Language (SAML): パスワードなしで 2 者間の認証情報のやり取りを可能にする標準化されたプロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=IdP">IdP</Tooltip> から証明書を取得し、Auth0 Dashboard でその IdP の SAML 接続にアップロードします。これらの証明書のいずれかの有効期限が近づくと、Auth0 は期限切れが近いことを知らせる警告メールを Auth0 Dashboard 管理者に送信します。新しい証明書を取得し、接続の設定画面からアップロードできます。

<h3 id="ws-fed-connections">
  WS-Fed 接続
</h3>

<Tooltip tip="Web Service Federation (WS-Fed): ドメイン間でユーザー ID を管理するためのプロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Web+Service+Federation">Web Service Federation</Tooltip> (WS-Fed) 接続では、ADFS URL を指定して設定している場合、変更内容は毎日の更新時に反映されます。Auth0 Dashboard の接続設定ページを開いて Save を実行すると、手動で更新をトリガーできます。リモート IdP で証明書が変更された場合、Auth0 はこれらの方法、または同じ接続設定画面で新しいメタデータファイルをアップロードすることで更新できます。

<h2 id="disaster-recovery-business-continuity-plan-in-place">
  災害復旧／事業継続計画が整備されている
</h2>

ローンチ前の必須条件ではありませんが、システム障害や、重要な担当者がいる地域で発生する自然災害など、さまざまな災害が起きた場合にも事業継続を確保できるよう、災害復旧計画を整備しておくことは有効です。

<h2 id="processes-documented">
  文書化されているプロセス
</h2>

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

* 構成の変更管理
* 新しい変更のデプロイ、使用している自動デプロイの仕組み、問題が見つかった場合に以前のバージョンに戻す方法
* 証明書のロールオーバープロセス (ある場合)
* 新しい IDプロバイダー の追加または削除 (該当する場合)
* Auth0 内、または Auth0 が参照元とするディレクトリ内でのユーザープロファイル構造の変更
* アプリケーション または API の追加または削除
* ログの取得とエクスポート
* 実装済みのバックアップ/復元プロセス
* ユーザー管理 (パスワードを忘れた場合、電話を紛失した場合)
* インシデント発生後の根本原因分析

<h2 id="project-planning-guide">
  プロジェクト計画ガイド
</h2>

推奨する戦略の詳細をご確認いただけるよう、PDF形式の計画ガイドをご用意しています。ダウンロードしてご参照ください。

[B2B IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)