> ## Documentation Index > Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt > Use this file to discover all available pages before exploring further. # 操作方法（B2B） > Auth0テナント環境を利用できるようにする方法について説明します。 利用可能な状態にするには、インフラストラクチャーを構成またはセットアップして、ビジネスの継続性において求められるスケーラブルで、測定可能、そして定量化が可能な運用に対応する必要があります。Auth0には、サポートサービスの手配（メールプロバイダーなど）、デプロイメントの監視サービス、異常状態の検出に加え、本番環境において問題が発生した際に、迅速かつスムーズにリカバリーするための対処方法を準備することが含まれています。 成功しているお客様によれば、効果的な運用動作を確立することでそれに見合った利益がもたらされることが分かっています。また、ワークフローに目を向ければ、検討すべき事項がいくつも出てきます。 * 不具合を積極的に検出するには、どうしたら良いでしょうか？ * Auth0の操作上のステータスに関するデータは、どのようにしたら取得できるでしょうか？ * Auth0サービスに関連するAuth0のセキュリティ情報については、どのように対応したら良いでしょうか？ * Auth0には、Auth0サービスでは近い将来予定されている変更に関する情報は用意されていますか？ * Auth0から送られてくる重要なお知らせは、どのように確認したら良いでしょうか？ * Auth0ログデータを利用して、その内容を分析したり、Auth0で制限されているデータ保持期間よりも長く保存するには、どうしたら良いでしょうか？ * Auth0ログをスキャンして、アプリケーション内のピーク負荷がレート制限やその他のエラーを引き起こしていないかどうかを見極める方法を教えてください。 * ユーザーに送信するメール数に対応するには、どのメールサービスを使用したら良いでしょうか？現在の本番環境で、すぐに使用できるAuth0のメールプロバイダーは利用可能ですか？ * ファイアウォールを構成したり、Auth0からの情報を受け取る必要がある社内サービス用（カスタムデータサービス、Webサービス、メールサービスなど）に、どのファイアウォールポートを開くのかを知る必要がありますか？ * 新しい組織をどのようにプロビジョニングしますか？ * お客様ご自身で組織のIdPを構成出来るようにするために、お客様に対してセルフサービスプロビジョニングを提供する必要がありますか？ Auth0では、Auth0サービスオペレーションの[監視](#monitoring)に加え、Auth0[サービスステータス](#service-status)に関する情報も提供しています。また、Auth0ではさまざまな[通知](#notifications)を介して、セキュリティ関連情報に加え、Auth0サービスに関して今後予定されている変更情報を入手することができます。Auth0[ログイン](#logging)サービスには、レート制限や過大な負荷にゆる制限も含め、運用上の異常を追跡および特定するための機能も豊富に用意されています。 Auth0には、すぐに使用できるメール配信サービスが用意されており、統合を加速します。ただし、このサービスは、本番環境における本格的な利用を対象としたものではありません。また、メールの配信において、特定のサービスレベルや保証をお勧めするものではありません。推奨されるベストプラクティスは、お客様が通常行うものがあり、独自の[メールサービスプロバイダー](#email-provider-setup)を構成することです。 また場合によっては、Auth0との統合をサポートし、Auth0の拡張性に対応するには[インフラストラクチャー](#infrastructure)構成を変更する必要があります。たとえば、内部または外部のインフラストラクチャー（Actions、Rules、またはHooks内で外部APIコールを呼び出したり、既存のレガシーIDストレージを活用する必要がある場合には、カスタムデータスクリプトを経由したりなど）にもコールバックを提供する必要がある場合には、ファイアウォールを構成しなければならないことがあります。 組織がシステムでどのように準備されるのかが決まったら、組織自体をどのようにしてプロビジョニングするのかを検討します。詳細については、「[組織をプロビジョニングする](#provisioning-organizations)」を参照してください。 加えて、当社のお客様の大半が顧客の組織管理者が使用するために、複数のセルフサービスポータルを開発しており、独自の[IdP](#self-service-idp-provisioning)を構成するためのセルフサービス機能を提供しています。
## サービスステータス
Auth0[ステータスダッシュボード](https://status.auth0.com/)と、Auth0[アップタイムダッシュボード](http://uptime.auth0.com/)には、人が解読可能な形式で、Auth0サービスの現在そして過去のステータスが表示されます。監視アラートが発動した場合、運営スタッフはトラブルシューティングの第一歩として、停電が発生していないか、ステータスダッシュボードを確認する必要があります。パブリッククラウドステータスページでは、契約している電力会社の停電に関する通知も確認することができます。また、ソーシャルプロバイダーなど、利用しているサードパーティの[外部サービス](/docs/ja-JP/ja-jp/deploy-monitor/monitor/check-external-services-status)のステータスも併せて確認することを推奨しています。こうした便利な情報を活用することで、問題のトラブルシューティングにあたる際に、考えられる原因を迅速に取り除くことができます。また、開発者だけでなく、ヘルプデスク要員にとっては、トラブルシューティング時において確認すべきチェックリストの最初の項目として役立ちます。 ### ベストプラクティス Auth0および依存するサービス（ソーシャルプロバイダーなど）の状態を確認する方法に関する情報は、開発者とヘルプデスクスタッフにとって、トラブルシューティングチェックリストのトップに来るべきです。Auth0のステータスページで利用登録し、ステータスの更新通知を受け取るようにセットアップすることをお勧めします。 パブリッククラウドサービスの停電が発生した場合、Auth0は根本原因分析（RCA）を実行し、Auth0ステータスページにて結果を公開します。Auth0は、停電後徹底的な調査を行います。この中には、根本原因の究明に加え、その要因、ならびに再発防止策も含まれます。そのため、結果的にRCAドキュメントが公開されまでに数週間を要する場合もあります。
## メールプロバイダーのセットアップ
Auth0は、会員登録、メール検証、侵害されたパスワード、パスワードリセットのイベントに関する[メール](/docs/ja-JP/ja-jp/customize/email)をユーザーに送信します。イベントの種類ごとにメールテンプレートをカスタマイズしたり、メール処理を詳細に設定したりすることも可能です。Auth0には、テスト用のメールプロバイダーが用意されており、基本テスト用の機能は制限されています。本番での使用には、メールプロバイダーを独自にセットアップする必要があります。メールテンプレートのカスタマイズは、独自のプロバイダーを確立するまで有効になりません。 ### ベストプラクティス デフォルトのAuth0メールプロバイダーは、大量のメールの送信やメールテンプレートのカスタマイズに対応していません。運用環境にデプロイする前に独自のメールプロバイダーを設定するようにしましょう。
## インフラストラクチャ
### ファイアウォール
Auth0で実行するカスタムコードでネットワーク内のサービスを呼び出す場合（Action、Rule、Hook、またはカスタムデータベーススクリプトなど）、または、Auth0でオンプレミスSMTPプロバイダーを構成した場合は、[Auth0からのインバウンドトラフィック](/docs/ja-JP/ja-jp/secure/security-guidance/data-security/allowlist)を許可するようにファイアウォールを構成しなければならないことがあります。ファイアウォールの通過を許可するIPアドレスは、各地域特有のものであり、Auth0 Dashboard内のRules、Hooks、カスタムデータベーススクリプト、およびメールプロバイダーの構成画面に表示されています。
## ロギング
イベントのロギングに加え、ログのスキャニングにおいて、Auth0にはイベントの異常を特定するために豊富な機能が用意されています（詳細に関しては、「[ログドキュメンテーション](/docs/ja-JP/ja-jp/deploy-monitor/logs)」を参照してください）。Auth0ログの標準的なログ保存期間は、サブスクリプションレベルによって決まります。最短で2日間、最長で30日間の保存期間となります。Auth0サポートを活用して、外部のロギングサービスと統合することで、ログを外部で保存したり、組織全体にログアグリケーションを提供することもできます。 ### ベストプラクティス ログデータを外部のログ分析サービスに送信するには、ログストリーミングソリューションをぜひご活用ください。データの長期保存とログデータに対する高度な分析を可能にします。 サブスクリプションレベルのログデータ[保存期間](/docs/ja-JP/ja-jp/deploy-monitor/logs/log-data-retention)を見直してから、ログデータエクスポートの拡張を実行して、外部ログ分析サービスにログデータを送る必要があります。Auth0 Marketplace内にある、[ログストリーミングソリューション](https://marketplace.auth0.com/features/log-streaming)の一つを使用することができます。 開発チームは、QAテストでは検出しにくいと思われる断続的なエラーのトラブルシューティングや検出にログファイルを使用することができます。フォレンジックデータが必要になった場合、セキュリティチームにはログデータが必要になるでしょう。総合的な分析結果を含むログファイルをサービスにエクスポートすると、使用傾向や攻撃防御のトリガーなどのパターンを確認するのに役立ちます。
### レート制限とその他のエラー
Auth0には、[レート制限を超過する](/docs/ja-JP/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)と報告されるエラーに独自のエラーコードを用意しています。ログの自動スキャンをセットアップしてレート制限エラーを確認する必要があります。こうすれば、ユーザーに影響が及ぶ前に、レート制限を超過しそうなアクティビティへ事前に対処することが可能です。また、Auth0では、他の種類のエラーに対するエラーコードも公開している、[認証エラー](/docs/ja-JP/ja-jp/libraries/common-auth0-library-authentication-errors)に関するログだけでなく、Auth0 Management APIコールからのエラーをスキャンするのにも役立ちます（Management APIエラーコードは、[Management API Explorer](/docs/ja-JP/ja-jp/api/management/v2)内の各コールの下に表示されます）。 ### ベストプラクティス ルール内からユーザープロファイル情報を取得するためにManagement APIを呼び出すことは、レート制限の発生の一般的な原因になります。なぜなら、そのようなAPIはすべてのログインと定期的なセッションチェックを呼び出すからです。
## 監視
[Auth0の実装を監視する](/docs/ja-JP/ja-jp/deploy-monitor/monitor)ためのメカニズムを構築する必要があります。構築することで、サポートまたはオペレーションチームは、先を見越してサービス停止に対処する上で必要な情報を適時受け取ることができます。Auth0にはモニタリングエンドポイントが用意されており、ご使用のモニタリングインフラストラクチャーに組み込むことができます。モニタリングエンドポイントは、サービスをモニタリングして消費に適切に対処するために開発されました。エンドポイントからは、Auth0に関するデータのみが提供されるという点に留意しておく必要があります。ユーザーのログイン能力を確認する上で必要不可欠である、完全なエンドツーエンドのモニタリングについては、合成トランザクションのモニタリングをセットアップすることを推奨しています。合成トランザクションのモニタリングをセットアップすることで、モニタリングの粒度が増し、Auth0とは無関係の停止状態に加え、性能の低下を検出できるようになりますので、これまで以上に積極的に対応することが可能になります。 ### ベストプラクティス 代理ログイントランザクションを送信できる機能をセットアップすることで、認証のエンドツーエンドのモニタリングが容易になります。これは[リソース所有者パスワード付与](/docs/ja-JP/ja-jp/api-auth/tutorials/password-grant)と権限のないテストユーザーを組み合わせて使用する簡単なアプリケーションで行うことができます。[Auth0レート制限ポリシー](/docs/ja-JP/ja-jp/policies/rate-limits)についてもご確認ください。
## 通知
Auth0からは数種類の通知が発せられます。通知には、テナントやプロジェクトに影響を与える可能性がある重要な情報が記載されているため、見落とさないように注意する必要があります。 Auth0によって、予見的なセキュリティ通知など、操作に関する告知がダッシュボード管理者に送信されます。これらのメッセージを受け取るべき人がダッシュボード管理者になっていることを確認してください。
### ダッシュボード通知
適時、Auth0からテナントに関連する重要なお知らせが送られてくることがあります。サービスに関するこれらのお知らせは、Auth0 Dashboardに届きます。お知らせする内容の重要度に応じて、Auth0 Dashboardに登録されている管理者にメールで通知されます。Dashboardには定期的にログインし、画面上部のベルアイコンで重要なお知らせが届いていないかを確認してください。また、Auth0からのメールは適時に確認する必要があります。メールには、対処すべき変更や実行すべきアクションに関する重要な情報が記載されている場合があります。
### Auth0のセキュリティ情報
Auth0では、複数のセキュリティ関連のテストを定期的に実行します。何らかの問題が見つかった場合は、事前に特定した上で、セキュリティ関連の変更を行う必要があるお客様に通知します。Auth0製品は拡張性を備えていますが、Auth0では影響が及ぶすべてのお客様を特定することは難しいため、Auth0[セキュリティ情報](/docs/ja-JP/ja-jp/secure)を定期的に確認する必要があります。 ### ベストプラクティス 定期的にAuth0 [「セキュリティ情報」](/docs/ja-JP/ja-jp/security/bulletins)ページを確認し、セキュリティ情報の影響を受けている場合には、推奨される対策を講じることがベストプラクティスです。
### 変更ログ
Auth0では、Auth0[変更ログ](https://auth0.com/changelog)内でサービスの変更に関する情報を確認できます。変更内容を把握しておくために、Auth0変更ログは定期的に確認しておく必要があります。問題をリサーチするサポートチームは、最新の変更が関連しているかを判断する上で、変更ログを確認することが有効な場合があります。特に、[破壊的変更](/docs/ja-JP/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations)の場合には有効です。開発チームも、変更ログを確認して、有益と思われる新しい機能を特定したいと考えるはずです。
## 組織をプロビジョニングする
### ベストプラクティス あるOrganizationをプロビジョニングする際に行う必要があることは、システム内でOrganizationがどのように存在しているかによります。これらのOrganizationのユーザーがどのようにアプリケーションとやり取りするようになるかを考慮するために時間が必要になるかもしれません。[「Organizationの複数アーキテクチャ」](https://cdn2.auth0.com/docs/1.14567.0/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Overview.pdf)をチェックして、あなたのIAMシステムでOrganizationを構成する方法を決定してください。 組織のプロビジョニングでは、以下を考慮する必要があります。 * 独自のアプリケーションの構成とデータベースの両方または片方に組織の追加が必要になります。 * 使用しているAuth0の構成を変更する必要があります。これには、以下の一部またはすべてが含まれます。 * 一意のテナントを作成する * データベース接続を追加する（組織ごとにユーザーを分離する場合） * この組織にエンタープライズ接続を追加する * これには、レガシー組織でない場合に、組織について、既存の構成を更新するか、Auth0テナントに構成を追加する作業が含まれます。 * 組織の管理者をプロビジョニングする * 間違いを防ぐために、[組織管理者ポータル](#organization-admin-portal)を作成して、新しい組織をプロビジョニングしやすくすることをお勧めします。
### 組織管理者ポータル
組織管理者ポータルでは、管理者が組織の作成、編集、削除を行えます。独自のシステムとAuth0テナントの両方で、複数の作業を実行する必要があります。このポータルは、システム内のデータストアと構成にアクセスできるよう、独自のシステム内に必要となる可能性があります。ただし、Auth0は[Auth0 Management API](/docs/ja-JP/ja-jp/api/management/v2)を提供しているため、独自のシステム内で変更を行うと同時に、変更内容をAuth0テナントに反映することができます。 新しい組織を作成するには、主に2つの方法があります。どちらを選択するかは、新しい組織がデプロイされるまでに、どれだけの時間的な余裕があるかに依存します。 * **Auth0テナントにライブで更新** ：新しい組織をリアルタイムに作成したい場合には、Auth0 Management APIを使って、Auth0テナントを直接変更することをお勧めします。変更内容がリアルタイムで反映されるため、新しい組織の追加も即座に反映されます。 ライブアップデートには、いくつか考慮すべき点があり、一連の操作を順番に行うことで問題の発生を防がなければなりません。たとえば、接続でクライアントを有効にすること、アプリケーションにコールバックURLを追加すること、などです。Management APIで行う操作のうち、リスト全体を取得してそれに新しい値を追加し、リストを再発行するものは、必ず2つの操作を順番に実行しなければなりません。2つの操作が同時に行われると、いずれかの値が上書きされてしまうためです。 * **リポジトリを変更してデプロイし直す** ：[CI/CDパイプライン](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/business-to-business/deployment)の一部としてDeploy CLI（またはカスタムCLI）を活用している場合には、変更内容をリポジトリに直接プッシュしてから、新しいデプロイメントを始める方が好ましいかもしれません。多少時間がかかりますが、バージョン履歴や、以前のバージョンをデプロイし直して変更を取り消せるなどの利点があります。 ### ベストプラクティス Organizationが必要とするアイテムだけを含む別のリポジトリを持つことで、他の共通コンポーネントを再度デプロイする必要や、エラーが発生するリスクもなくなります。
## セルフサービスのIdPプロビジョニング
Auth0[接続](/docs/ja-JP/ja-jp/identityproviders)を利用すると、IdPを簡単に構成することができる一方で、オンボードの顧客組織IdPには時間がかかる工程となる可能性があります。定期的に新規顧客組織やIdP要件を変更中の既存組織に販売する場合には、いっそう時間を要します。そのため、顧客の組織管理者用にセルフサービスのポータルを構築することは意義があると、多くのお客様が答えています。結果的に、顧客が自社専用のIdPを構成できるようになるからです。その結果、IT部署の作業負荷を削減することになります。[Auth0 Management API](/docs/ja-JP/ja-jp/api/management/v2)には、これを実現する上で必要となる[接続管理機能](/docs/ja-JP/ja-jp/api/management/v2#!/Connections/get_connections)がすべて用意されています。
## プロジェクト計画ガイド
当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。 [B2B IAM Project Planning Guide](http:///assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)
## 複数Organizationアーキテクチャ（マルチテナント機能）
B2Bプラットフォームの多くが顧客のOrganizationを何らかの形で分離・ブランディングし、これがIDおよびアクセス管理（IAM）システムをさらに複雑にしています。この問題でお困りであれば、当社がそのような環境に合ったガイダンスとベストプラクティスをご紹介していますので、時間を割いてお読みになることをお勧めします。 [複数Organizationアーキテクチャ](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture)