マルチテナント アーキテクチャでの Azure Active Directory B2C の使用に関する考慮事項

Azure Active Directory (Azure AD) B2C では、サービスとしての企業-消費者間 ID を提供します。 通常、ユーザー ID は、マルチテナント アプリケーションを設計する際の主要な考慮事項の 1 つです。 ID ソリューションはアプリケーションへのゲートキーパーとして機能し、テナントが、定義された境界内に留まるようにします。 この記事では、マルチテナント ソリューションでの Azure AD B2C の使用に関する考慮事項とその方法について説明します。

Azure AD B2C を使用する最も一般的な理由の 1 つは、アプリケーションの ID フェデレーションを有効にすることです。 ID フェデレーションは、ユーザーが既存のアカウントでサインインできるように、2 つの ID プロバイダー間で信頼を確立するプロセスです。 Azure AD B2C を使用する場合、ID フェデレーションを実装して、ユーザーがそのソーシャル アカウントまたはエンタープライズ アカウントを使用してサインインできるようにすることができます。 フェデレーションを使用すると、ユーザーはアプリケーション固有のローカル アカウントを個別に作成する必要がなくなります。

このトピックについて詳しくない場合は、次のリソースを確認することをお勧めします。

• Azure Active Directory B2C とは
• マルチテナント ID に関する考慮事項
• マルチテナント ID のアプローチ
• テナント モデル

Note

この記事では、アプリケーション テナントと Azure AD B2C テナントというよく似た名前の 2 つの概念について説明します。

"アプリケーション テナント" という用語は、"お客様の" テナントを指すために使用されます。これは、顧客またはユーザー グループである可能性があります。

Azure AD B2C では、個々のディレクトリに関してもテナントの概念が使用されます。"マルチテナント" という用語は、複数の Azure AD B2C テナント間の相互作用を指すために使用されます。 用語は同じですが、概念が異なります。 この記事で Azure AD B2C テナントに言及する場合は、完全な用語 "Azure AD B2C テナント" を使用します。

マルチテナント ソリューションの ID

マルチテナント ソリューションでは、複数の ID サービスを組み合わせてさまざまな要件セットを実現するのが一般的です。 多くのソリューションには、次の 2 つの異なる ID セットがあります。

• 顧客 ID。これは、エンド ユーザー アカウント用であり、 テナントのユーザーがアプリケーションにアクセスする方法を制御します。
• 内部 ID。これは、自社のチームがソリューションを管理する方法を処理します。

さらに、これらの異なる種類の ID では、通常、個別の ID サービスが使用されます。 Azure AD B2C は、テナントのユーザーがソリューションへのアクセスに使用する顧客 ID およびアクセス管理 (CIAM) サービスです。 Microsoft Entra ID は、自分や自分のチームが、Azure リソースの管理とアプリケーションの制御に使用する ID およびアクセス管理 (IAM) サービスです。

Fabrikam によって作成されたマルチテナント ソリューションの例について考えてみましょう。 このソリューションでは、Fabrikam の要件を満たすために 2 つのサービスの組み合わせを使用します。

• Fabrikam では、会社の顧客 (テナント) がアプリケーションにサインインできるように、Azure AD B2C を実装しています。
• Fabrikam の従業員は、管理目的でソリューションにアクセスするために、組織の Microsoft Entra ディレクトリを使用しています。 彼らは、Microsoft Office などの他の Fabrikam リソースへのアクセスに使用するものと同じ ID を使用しています。

次の図にこの例を示します。

分離モデル

Azure AD B2C を使用する場合、異なるアプリケーション テナント間でユーザー アカウントを分離する方法を決定する必要があります。

次のような点を考慮する必要があります。

• サインインを顧客の ID プロバイダーにフェデレーションする必要がありますか? たとえば、SAML、Microsoft Entra ID、ソーシャル サインイン プロバイダー、またはその他のソースへのフェデレーションを有効にする必要がありますか?
• 自分またはテナントにデータ所在地の要件がありますか?
• ユーザーは複数のアプリケーション テナントにアクセスする必要がありますか?
• 複雑なアクセス許可やロールベースのアクセス制御 (RBAC) が必要ですか?
• アプリケーションにサインインするのは誰ですか? 多くの場合、ユーザーのさまざまなカテゴリは "ユーザー ペルソナ" と呼ばれます。

次の表は、Azure AD B2C の主なテナント モデル間の違いをまとめたものです。

考慮事項	共有 Azure AD B2C テナント	垂直方向にパーティション分割された Azure AD B2C テナント	アプリケーションごとに 1 つの Azure AD B2C テナント
データの分離	各アプリケーション テナントのデータは 1 つの Azure AD B2C テナントに格納されるが、アクセスできるのは管理者のみ	各アプリケーション テナントのデータは複数の Azure AD B2C テナント間で分散されるが、アクセスできるのは管理者のみ	各アプリケーション テナントのデータは専用の Azure AD B2C テナントに格納されるが、アクセスできるのは管理者のみ
デプロイの複雑性	低	パーティション分割戦略に応じて中から高	非常に高
考慮すべき制限	Azure AD B2C テナントあたりの要求数、クライアント IP アドレスあたりの要求数	パーティション分割戦略に応じた、要求数、サブスクリプションあたりの Azure AD B2C テナントの数、1 人のユーザーのディレクトリの数の組み合わせ	サブスクリプションあたりの Azure AD B2C テナントの数、1 人のユーザーのディレクトリの最大数
操作の複雑さ	低	パーティション分割戦略に応じて中から高	非常に高
必要な Azure AD B2C テナントの数	1 つ	パーティション分割戦略に応じて、1 から n の間	n (n は、アプリケーション テナントの数)
シナリオ例	音楽や動画のストリーミング サービスなど、データ所在地の要件が低い、またはまったくないコンシューマー向けの SaaS オファリングの構築。	企業向けの会計および記録保持アプリケーションなどの SaaS オファリングの構築。 データ所在地の要件または多数のカスタム フェデレーション ID プロバイダーをサポートする必要があります。	企業向けの政府の記録保持アプリケーションなどの SaaS サービスの構築。 顧客は、他のアプリケーション テナントからの高度なデータ分離を義務付けています。

共有 Azure AD B2C テナント

一般に、要件で共有が許可されていれば、単一の共有 Azure AD B2C テナントを管理するのが最も簡単です。 1 つのテナントのみを長期間維持する必要があり、このオプションを使用すると、オーバーヘッドが最も少なくなります。

Note

ほとんどのシナリオでは、共有 Azure AD B2C テナントを使用することをお勧めします。

次の場合は、共有 Azure AD B2C テナントを検討する必要があります。

• データ所在地の要件や厳格なデータ分離要件がない。
• アプリケーション要件が、Azure AD B2C サービス制限内である。
• フェデレーション ID プロバイダーがある。この場合、ホーム領域の検出使用して、ユーザーがサインインするプロバイダーを自動的に選択するか、ユーザーがリストからプロバイダーを手動で選択することができます。
• すべてのアプリケーション テナントに対して統一されたサインイン エクスペリエンスを提供している。
• エンド ユーザーは、1 つのアカウントを使用して複数のアプリケーション テナントにアクセスする必要がある。

次の図は、共有 Azure AD B2C テナント モデルを示しています。

垂直方向にパーティション分割された Azure AD B2C テナント

垂直方向にパーティション分割された Azure AD B2C テナントのプロビジョニングは、必要な Azure AD B2C テナントの数を可能な限り最小限に抑えるように設計された戦略です。 これは、他のテナント モデルの中間に位置するモデルです。 垂直方向のパーティション分割を使用すると、必要に応じて特定のテナントのカスタマイズの柔軟性を高めます。 ただし、すべてのアプリケーション テナントの Azure AD B2C テナントのプロビジョニングに関連する運用上のオーバーヘッドは発生しません。

このテナント モデルのデプロイとメンテナンスの要件は、単一の Azure AD B2C テナントの要件よりも高くなりますが、アプリケーション テナントごとに 1 つの Azure AD B2C テナントを使用する場合よりは低くなります。 環境全体での複数のテナントのデプロイと メンテナンスの戦略を設計して実装する必要があります。

垂直方向のパーティション分割は、データ シャーディング パターンに似ています。 Azure AD B2C テナントを垂直方向にパーティション分割するには、アプリケーション テナントを論理グループに整理する必要があります。 このテナントの分類は、多くの場合、"パーティション分割戦略" と呼ばれます。 パーティション分割戦略は、リージョン、サイズ、アプリケーション テナントのカスタム要件など、アプリケーション テナントの共通の安定した要素に基づいている必要があります。 たとえば、データ所在地の要件を解決することが目標である場合、アプリケーション テナントをホストするリージョンごとに Azure AD B2C テナントをデプロイすることを決定できます。 または、サイズ別にグループ化する場合、ほとんどのアプリケーション テナントの ID を 1 つの Azure AD B2C テナントに配置し、最大のアプリケーション テナントを専用の Azure AD B2C テナントに配置することができます。

重要

Azure AD B2C テナント間でユーザーを移動するのは難しいため、時間の経過と共に変化する可能性がある要因に基づいてパーティション分割戦略を作成しないようにしてください。 たとえば、複数の SKU または製品レベルを持つ SaaS オファリングを作成する場合、選択した SKU に基づいてユーザーをパーティション分割しないでください。SKU は、顧客が製品をアップグレードすると変更される可能性があるためです。

次の場合は、垂直方向にパーティション分割された戦略を使用して Azure AD B2C テナントをプロビジョニングすることを検討する必要があります。

• データ所在地の要件がある、またはユーザーを地域別に分離する必要がある。
• 多数のフェデレーション ID プロバイダーがあり、ホーム領域の検出 を使用して、ユーザーがサインインする ID プロバイダーを自動的に選択できない。
• アプリケーションではマルチテナントを認識している、または認識することができ、ユーザーがどの Azure AD B2C テナントにサインインする必要があるかを認識している。
• 大規模なアプリケーション テナントが Azure AD B2C の制限に達する可能性があると思われる。
• 中間の数から多数までの Azure AD B2C テナントをデプロイしてメンテナンスするための長期的な戦略がある。
• Azure サブスクリプションにデプロイできる Azure AD B2C テナントの数に関する制限内で動作するように、1 つ以上の Azure サブスクリプション間でアプリケーション テナントをシャード化するための戦略がある。

次の図は、垂直方向にパーティション分割された Azure AD B2C テナント モデルを示しています。

アプリケーションごとに 1 つの Azure AD B2C テナント

アプリケーション テナントごとに Azure AD B2C テナントをプロビジョニングする場合、各テナントの多くの要素をカスタマイズできます。 ただし、この方法を使用すると、オーバーヘッドが大幅に増加します。 多数の Azure AD B2C テナントが作成される可能性があるため、デプロイとメンテナンスの戦略を策定する必要があります。

また、サービスの制限も認識しておく必要があります。 Azure サブスクリプションを使用すると、限られた数の Azure AD B2C テナントのみをデプロイできます。 制限を超えてデプロイする必要がある場合は、複数のサブスクリプション間で Azure AD B2C テナントのバランスを取ることができるように、適切な サブスクリプション設計を検討する必要があります。 1 人のユーザーが作成できるディレクトリの数や、ユーザーが属することができるディレクトリの数など、他にも適用される Microsoft Entra の制限があります。

警告

このアプローチは複雑であるため、最初に他の分離モデルを検討することを強くお勧めします。 このオプションは、完全を期すためにここに含まれていますが、ほとんどのユース ケースでは、適切なアプローチではありません。

よくある誤解として、デプロイ スタンプ パターンを使用する場合、各スタンプに ID サービスを含める必要があると考えられています。 これは必ずしも正しいとは限りません。多くの場合、代わりに別の分離モデルを使用できます。 この分離モデルを使用する場合は、慎重に検討し、ビジネス上の正当な理由を明確にする必要があります。 デプロイとメンテナンスのオーバーヘッドはかなりのものです。

次の場合にのみ、すべてのアプリケーション テナントに対して Azure AD B2C テナントをプロビジョニングすることを検討する必要があります。

• アプリケーション テナントに対する厳格なデータ分離要件がある。
• 大量の Azure AD B2C テナントをデプロイしてメンテナンスするための長期的な戦略がある。
• Azure AD B2C のサブスクリプションごとのテナント制限に準拠するために、1 つ以上の Azure サブスクリプション間で顧客をシャード化する戦略がある。
• アプリケーションではマルチテナントを認識している、または認識することができ、ユーザーがどの Azure AD B2C テナントにサインインする必要があるかを認識している。
• "すべて" のアプリケーション テナントに対してカスタム構成を実行する必要がある。
• エンド ユーザーは、同じサインイン アカウントを使用して複数のアプリケーション テナントにアクセスする必要がない。

次の図は、アプリケーション テナントごとに 1 つの Azure AD B2C テナントを使用する場合を示しています。

ID フェデレーション

ユーザー フローを使用して、またはカスタム ポリシーで、各フェデレーション ID プロバイダーを構成する必要があります。 通常、ユーザーはサインイン時に、認証に使用する ID プロバイダーを選択します。 共有テナント分離モデルを使用している場合、またはフェデレーション ID プロバイダーが多数ある場合は、ホーム領域の検出を使用してサインイン時に ID プロバイダーを自動的に選択することを検討してください。

Azure AD B2C テナントを相互にフェデレーションすることにより、複数の Azure AD B2C テナントを管理するためのツールとして ID フェデレーションを使用することもできます。 そうすることで、アプリケーションでは単一の Azure AD B2C テナントを信頼できるようになります。 アプリケーションでは、顧客が複数の Azure AD B2C テナント間で分割されていることを認識する必要はありません。 この方法は、ユーザーがリージョン別にパーティション分割されている場合に、垂直方向にパーティション分割された分離モデルで最も一般的に使用されます。 この方法を採用する場合は、いくつかの点を考慮する必要があります。 この方法の概要については、グローバル ID ソリューションに関するページを参照してください。

ホーム領域検出

"ホーム領域の検出" は、ユーザーのサインイン イベントのフェデレーション ID プロバイダーを自動的に選択するプロセスです。 ユーザーの ID プロバイダーを自動的に選択する場合、プロバイダーを選択するようにユーザーに求める必要はありません。

ホーム領域の検出は、共有 Azure AD B2C テナントを使用し、顧客が独自のフェデレーション ID プロバイダーを持ち込むことができるようにする場合に重要です。 ユーザーが ID プロバイダーの一覧から選択する必要がある設計を避けることが必要な場合があります。 そのような設計を行うと、サインイン プロセスが複雑になります。 また、ユーザーが誤って正しくないプロバイダーを選択すると、サインインの試行が失敗する可能性もあります。

ホーム領域の検出は、さまざまな方法で構成できます。 最も一般的な方法は、ユーザーのメール アドレスのドメイン サフィックスを使用して ID プロバイダーを決定することです。 たとえば、Northwind Traders は Fabrikam のマルチテナント ソリューションの顧客であるとします。 メール アドレス user@northwindtraders.com には、Northwind Traders のフェデレーション ID プロバイダーにマップできるドメイン サフィックス northwindtraders.com が含まれています。

詳細については、ホーム領域の検出に関するページを参照してください。 Azure AD B2C でこのアプローチを実装する方法の例については、Azure AD B2C サンプルの GitHub リポジトリを参照してください。

データの保存場所

Azure AD B2C テナントをプロビジョニングする際、データ所在地を設定するために、テナントをデプロイするリージョンを選択します。 この選択は、保存された顧客データが存在するリージョンを指定するため、重要です。 顧客のサブセットにデータ所在地の要件がある場合は、垂直方向にパーティション分割された戦略の使用を検討してください。

承認

強力な ID ソリューションの場合は、"認証" に加えて "承認" についても検討する必要があります。 Microsoft ID プラットフォームを使用してアプリケーションの承認戦略を作成するには、いくつかの方法があります。 AppRoles サンプルは、Azure AD B2C アプリ ロールを使用してアプリケーションに承認を実装する方法を示します。 また、代替の承認方法についても説明します。

承認には単一のアプローチはありません。アプローチを決定する際には、アプリケーションと顧客のニーズを考慮する必要があります。

メンテナンス

Azure AD B2C のマルチテナント デプロイを計画する場合、Azure AD B2C リソースの長期的なメンテナンスについて考慮する必要があります。 組織の Microsoft Entra テナントと同様に、Azure AD B2C テナントは、作成、保守、運用、セキュリティ保護に必要なリソースです。 次の一覧は包括的ではありませんが、次のような領域で発生するメンテナンスを考慮する必要があります。

• テナント ガバナンス。 Azure AD B2C テナントを維持するのは誰ですか? これらの管理者に必要な昇格されたロールは何ですか? 管理者の条件付きアクセスおよび MFA のポリシーをどのようにして構成しますか? Azure AD B2C テナントをどのようにして長期的に監視しますか?
• ユーザー体験の構成。 1 つまたは複数の Azure AD B2C テナントにどのようにして変更をデプロイしますか? ユーザー フローまたはカスタム ポリシーに対する変更をデプロイする前に、どのようにしてテストしますか?
• フェデレーション ID プロバイダー。 時間の経過と共に ID プロバイダーを追加または削除する必要がありますか? 各顧客が独自の ID プロバイダーを持ち込むことを許可する場合、どのようにしてそれを大規模に管理しますか?
• アプリの登録。 多くの Microsoft Entra アプリの登録では、認証にクライアント シークレットまたは証明書が使用されます。 これらのシークレットまたは証明書を必要に応じてローテーションするにはどうしますか?
• ポリシー キー。 カスタム ポリシーを使用している場合、ポリシー キーを必要に応じてローテーションするにはどうしますか?
• [ユーザー資格情報]。 ユーザー情報と資格情報をどのようにして管理しますか? ユーザーの 1 人がロックアウトされるか、パスワードを忘れてしまったために、管理者またはカスタマー サービスの介入が必要になった場合はどうなりますか?

デプロイするすべての Azure AD B2C テナントについて、これらの点を考慮する必要があります。 また、維持する Azure AD B2C テナントが複数ある場合、プロセスがどのように変化するかを検討する必要もあります。 たとえば、カスタム ポリシー変更を 1 つの Azure AD B2C テナントに手動でデプロイするのは簡単ですが、5 つのテナントに手動でデプロイするのは時間がかかり、リスクも高まります。

デプロイと DevOps

適切に定義された DevOps プロセスは、Azure AD B2C テナントの維持に必要なオーバーヘッドを最小限に抑えるのに役立ちます。 開発プロセスの早い段階で DevOps プラクティスを実装する必要があります。 理想的には、カスタム ポリシーやユーザー フローへの変更のデプロイなど、メンテナンス タスクのすべてまたはほとんどの自動化を試みる必要があります。 また、運用環境のテナントにデプロイする前に、下位環境で変更を段階的にテストするために、複数の Azure AD B2C テナントを作成することを計画する必要もあります。 DevOps パイプラインは、これらのメンテナンス アクティビティを実行する場合があります。 Microsoft Graph API を使用して、Azure AD B2C テナントをプログラムで管理できます。

Azure AD B2C の自動デプロイと管理の詳細については、次のリソースを参照してください。

• Azure AD B2C 運用上のベスト プラクティス
• Azure Pipelines を使用してカスタム ポリシーをデプロイする
• GitHub Actions を使用してカスタム ポリシーをデプロイする
• カスタム ポリシーの DevOps パイプラインのサンプル
• Graph API リファレンス:
  • カスタム ポリシー
  • ユーザー フロー
  • アプリの登録
  • ポリシー キー

重要

Azure AD B2C をプログラムで管理するために使用されるエンドポイントの一部は一般提供されていません。 Microsoft Graph のベータ版の API は、いつでも変更される可能性があり、プレリリースのサービス条件の対象となります。

Microsoft Entra B2B と Azure AD B2C の比較

Microsoft Entra B2B コラボレーションは Microsoft Entra External ID の機能です。この機能を使用すると、ゲスト ユーザーを組織の Microsoft Entra テナントに招待して、共同作業を行えるようにすることができます。 通常、B2B コラボレーションは、ベンダーなどの外部ユーザーに Microsoft Entra テナント内のリソースへのアクセス権を付与する必要がある場合に使用します。

Azure AD B2C は、異なる機能セットを提供する Microsoft Entra 外部 ID とは別の固有製品です。 Azure AD B2C は、製品の顧客が使用することを目的としています。 Azure AD B2C テナントは、組織の Microsoft Entra テナントとは異なります。

ユーザー ペルソナとシナリオによっては、Microsoft Entra B2B、Azure AD B2C、またはその両方を同時に使用することが必要になる場合があります。 たとえば、アプリケーションで、組織内のスタッフ、ベンダーで働くユーザー、顧客など、複数の種類のユーザーをすべて同じアプリ内で認証する必要がある場合は、Microsoft Entra B2B と Azure AD B2C を一緒に使用してこの要件を満たすことができます。

詳細については、以下を参照してください:

• Microsoft Entra ID または Azure AD B2C を使用する
• External Identities 機能セットの比較
• Woodgrove のデモ。 Microsoft Entra B2B と Azure AD B2C を使用するアプリケーションの例。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• Landon Pierce | FastTrack for Azure のカスタマー エンジニア

その他の共同作成者:

• Mick Alberts | テクニカル ライター
• Michael Bazarewsky | FastTrack for Azure のシニア カスタマー エンジニア
• John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア
• Jelle Druyts | FastTrack for Azure のプリンシパル カスタマー エンジニア
• Simran Jeet Kaur | FastTrack for Azure のカスタマー エンジニア
• LaBrina Loving | FastTrack for Azure のプリンシパル カスタマー エンジニアリング マネージャー
• Arsen Vladimirsky | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• Azure AD B2C カスタム ポリシーのサンプル
• Microsoft Authentication Library (MSAL)
• チュートリアル: Azure Active Directory B2C テナントの作成
• Azure AD B2C: 認証プロトコル
• Azure AD B2C の制限事項

関連リソース

• マルチテナント ソリューションのサービス固有のガイダンス
• Azure でマルチテナント ソリューションを設計および構築するためのチェックリスト
• マルチテナント ソリューションのアーキテクチャに関する考慮事項