Azure Lighthouse の一般的なシナリオには、顧客の Microsoft Entra テナント内のリソースを管理するサービス プロバイダーが含まれます。 Azure Lighthouse の機能を使うと、複数の Microsoft Entra テナントを使用する企業内のテナント間の管理を簡略化することもできます。 このシナリオでは、企業のいずれかのテナントのユーザーは、他のサービス プロバイダーを関与させることなく、Azure Lighthouse を介して他のテナントで管理タスクを実行できます。
シングル テナントと複数テナント
ほとんどの組織では、1 つの Microsoft Entra テナントの方が管理が簡単です。 1 つのテナント内にすべてのリソースを配置することで、そのテナント内の指定されたユーザー、ユーザー グループ、またはサービス プリンシパルによる管理タスクを一元化できます。 可能な場合は、組織で 1 つのテナントを使用することをお勧めします。
組織によっては、複数の Microsoft Entra テナントを使う必要がある場合があります。 これは、買収が行われ、長期的なテナント統合戦略がまだ定義されていない場合など、一時的な状況になる可能性があります。 また、場合によっては、組織が複数のテナントを継続的に管理する必要があります (完全に独立した子会社、地理的または法的な要件や、その他の考慮事項のため)。
マルチテナント アーキテクチャが必要な場合は、Azure Lighthouse を利用することで管理操作の一元化と合理化が容易になります。 Azure Lighthouse を使用すると、ある管理テナント内のユーザーが、一元管理されたスケーラブルな方法でテナントにまたがる管理機能を実行できます。
テナント管理のアーキテクチャ
企業で Azure Lighthouse を使用するには、他のテナントで管理操作を実行するユーザーを含めるテナントを決定する必要があります。 つまり、1 つのテナントを他のテナントの管理テナントとして指定します。
たとえば、組織に 1 つのテナントがあるとします。ここでは、Tenant A と呼びます。その後、その組織は Tenant B と Tenant C を取得します。これらを個別のテナントとして維持する必要があるビジネス上の理由があります。 ただし、同じポリシー定義、バックアップ プラクティス、およびセキュリティ プロセスを、同じユーザー セットによって実行される管理タスクと共に使用する必要があります。
テナント A には、テナント A に対してこれらのタスクを実行している組織内のユーザーが既に含まれているので、テナント A を管理テナントとして指定できます。 その後、 テナント B とテナント C 内のサブスクリプションをオンボードして、テナント A に委任することができます。オンボード プロセス中に、テナント A のユーザーにアクセス許可を付与する承認を作成し、テナント B とテナント C 全体で管理タスクを実行できるようにします。
セキュリティとアクセスに関する考慮事項
ほとんどのエンタープライズ シナリオでは、完全なサブスクリプションを Azure Lighthouse に委任する必要があります。 サブスクリプション内の特定のリソース グループだけを委任することもできます。
いずれの方法でも、委任されたリソースにアクセスできるユーザーを定義するときは、 最小限の特権の原則に従ってください 。 こうすることで、ユーザーが必要なタスクを実行するために必要なアクセス許可のみを持ち、不注意によるエラーが発生する可能性を減らすことができます。
Azure Lighthouse では、データやリソースを物理的に移動するのではなく、管理側テナントと管理対象テナントの間に論理的なリンクのみを提供します。 さらに、アクセスは、常に管理側テナントから管理対象テナントへの一方向のみです。 マネージド テナントのリソースに対して管理操作を実行する場合、管理側テナントのユーザーとグループは多要素認証を使用する必要があります。
内部または外部のガバナンスとコンプライアンスのガードレールを持つ企業の場合、Azure アクティビティ ログを使用して透過性の要件を満たすことができます。 企業がテナントの管理と管理の関係を確立すると、各テナントのユーザーはログに記録されたアクティビティを 表示して、管理しているテナントのユーザーが実行したアクションを確認できます。
詳細については、「推奨セキュリティ プラクティス」を参照してください。
導入プロセスの考慮事項
サブスクリプション (またはサブスクリプション内のリソース グループ) を Azure Lighthouse にオンボードするには、Azure Resource Manager テンプレートをデプロイするか、Azure Marketplace に発行されたマネージド サービス オファーを使用します。
エンタープライズ ユーザーは通常、企業のテナントに直接アクセスでき、管理オファリングを販売または促進する必要がないため、通常は、Azure Resource Manager テンプレートを迅速かつ簡単にデプロイできます。 オンボード ガイダンスではサービス プロバイダーと顧客の場合について説明していますが、エンタープライズは同じプロセスを使用してテナントをオンボードできます。
必要に応じて、マネージド サービス オファーを Azure Marketplace に公開して、企業内のテナントをオンボーディングすることもできます。 オファーが適切なテナントでのみ使用できるようにするには、 プランがプライベートに設定されていることを確認します。 非公開プランの場合、オンボードする予定の各テナントのサブスクリプション ID を指定します。また、他のユーザーはあなたのプランを取得できなくなります。
Microsoft Entra 外部 ID
Microsoft Entra External ID は、サービスとしての企業間 ID を提供します。 Azure Lighthouse を通じてリソース グループを委任する場合は、Azure Monitor を使用して、Microsoft Entra External ID のサインインと監査ログをさまざまな監視ソリューションにルーティングできます。 そのログを、長期的な使用のために保持したり、サードパーティのセキュリティ情報およびイベント管理 (SIEM) ツールと統合して環境の分析情報を取得したりすることができます。
詳細については、「 外部テナントでの Azure Monitor の設定」を参照してください。
用語に関する注意事項
エンタープライズ内でのクロステナント管理の場合、Azure Lighthouse ドキュメント内のサービス プロバイダーに関する説明を理解すると、エンタープライズ内の管理側テナト (つまり、Azure Lighthouse を使用して、他のテナント内のリソースを管理するユーザーを含むテナント) に適用することができます。 同様に、顧客に関する説明を理解すると、管理側テナントのユーザーによって管理されるリソースを委任するテナントに適用することができます。
たとえば、上記の例では、テナント A はサービス プロバイダー テナント (管理側テナント)、テナント B とテナント C は顧客テナントと考えることができます。
またこの例では、適切なアクセス許可を持つテナント A のユーザーは、Azure portal の [マイ カスタマー] ページで、委任されたリソースを表示および管理できます。 同様に、適切なアクセス許可を持つテナント B とテナント C のユーザーは、Azure portal の [サービス プロバイダー] ページで委任に関する詳細を表示および管理できます。
次のステップ
- マルチテナント アーキテクチャでのリソース組織のオプションについて確認します。
- テナント間の管理エクスペリエンスについて学習します。
- Azure Lighthouse の動作に関する詳細については、こちらを参照してください。