Azure Lighthouse のアーキテクチャ

  • [アーティクル]

Azure Lighthouse は、サービス プロバイダーによる顧客のエンゲージメントとオンボードのエクスペリエンスを簡略化しながら、機敏かつ正確に委任されたリソースを大規模に管理する上で役立ちます。 承認されたユーザー、グループ、サービス プリンシパルは、顧客の Microsoft Entra テナントにアカウントを持っていない場合や、顧客のテナントの共同所有者になっていない場合でも、顧客のサブスクリプションのコンテキストで直接作業できます。 このアクセスをサポートするために使用されるメカニズムは、Azure の委任されたリソース管理と呼ばれます。

Diagram illustrating Azure delegated resource management.

ヒント

独自の Microsoft Entra テナントが複数存在する企業内で Azure Lighthouse を使用することで、テナント間の管理を簡素化することもできます。

このトピックでは、Azure Lighthouse のテナントと、そのリレーションシップを有効にする顧客のテナントで作成されたリソースとの関係について説明します。

注意

Azure Lighthouse に顧客をオンボードするためには、ゲスト以外のアカウントが、オンボード対象サブスクリプションの Microsoft.Authorization/roleAssignments/write アクセス許可を含むロール (所有者など) を持っている (またはオンボード対象のリソース グループを含む) 顧客のテナント内でデプロイを実行する必要があります。

顧客テナントで作成された委任リソース

顧客のサブスクリプションまたはリソース グループが Azure Lighthouse にオンボードされると、登録定義と登録の割り当てという 2 つのリソースが作成されます。 ユーザーは API と管理ツールを使用することで、これらのリソースにアクセスしたり、Azure portal で操作したりすることができます。

登録定義

登録定義には、Azure Lighthouse オファーの詳細 (管理テナントの特定のユーザー、グループ、サービス プリンシパルに組み込みロールを割り当てる管理テナント ID と承認) が含まれています。

登録定義は、委任されたサブスクリプションごとに、または委任されたリソース グループを含むサブスクリプションごとに、サブスクリプション レベルで作成されます。 API を使用して登録定義を作成する場合は、サブスクリプション レベルで作業する必要があります。 たとえば、Azure PowerShell を使用する場合は、新しい登録定義 (New-AzManagedServicesDefinition) を作成する前に New-AzureRmResourceGroupDeployment を使用するのではなく、New-AzureRmDeployment を使用する必要があります。

登録の割り当て

登録割り当てによって、登録定義が特定のスコープ (オンボードされたサブスクリプションやリソース グループ) に割り当てられます。

登録割り当ては、委任されたスコープごとに作成されます。そのため、オンボードされた内容に応じて、サブスクリプション グループ レベルまたはリソース グループ レベルのいずれかになります。

各登録割り当ては、サブスクリプション レベルで有効な登録定義を参照する必要があります。これにより、そのサービス プロバイダーに対する認証を委任されたスコープに結びつけ、それによりアクセス権が付与されます。

論理プロジェクション

Azure Lighthouse を使用すると、あるテナントから別のテナントへの、リソースの論理プロジェクションが作成されます。 これにより、承認されたサービス プロバイダー ユーザーは、委任された顧客サブスクリプションとリソース グループを操作できる認証を使用して、自分のテナントにサインインできます。 その後、サービス プロバイダーのテナント内にいるユーザーは、個々の顧客テナントにサインインしなくても、顧客に代わって管理操作を実行できるようになります。

サービス プロバイダー テナント内のユーザー、グループ、またはサービス プリンシパルが顧客のテナント内のリソースにアクセスするたびに、Azure Resource Manager に要求が送信されます。 Resource Manager では、顧客のテナント内のユーザーが行った要求の場合と同様に、これらの要求が認証されます。 Azure Lighthouse の場合、登録定義と登録の割り当てという 2 つのリソースが顧客のテナントに存在するかどうかを確認することでこれを行います。 その場合、Resource Manager では、これらのリソースによって定義された情報に従ってアクセスが承認されます。

Diagram illustrating the logical projection in Azure Lighthouse.

サービス プロバイダーのテナント内のユーザーからのアクティビティは、顧客のテナントに格納されているアクティビティ ログで追跡されます。 これにより、顧客はどのような変更が誰によって行われたのかを確認できます。

Azure Lighthouse のしくみ

管理テナントに対する Azure Lighthouse の大まかなしくみは以下のとおりです。

  1. 顧客の Azure リソースを管理するために必要なグループ、サービス プリンシパル、またはユーザーのロールを特定します。
  2. このアクセス権を指定し、Azure Marketplace にマネージド サービス オファーを公開するか、Azure Resource Manager テンプレートを展開して、顧客を Azure Lighthouse にオンボードします。 このオンボード プロセスによって、前述した 2 つのリソース (登録定義と登録割り当て) が顧客のテナントに作成されます。
  3. 顧客のオンボードが完了したら、許可されているユーザーは、定義したアクセス権に基づいて、指定した顧客のスコープ (サブスクリプションまたはリソース グループ) で、管理テナントにサインインしてタスクを実行します。 顧客は実行されたすべてのアクションを確認でき、いつでもアクセスを削除できます。

ほとんどの場合、1 社のサービス プロバイダーが顧客の代わりに特定のリソースの管理を行いますが、顧客が同じサブスクリプションやリソース グループに対して複数の委任を作成し、複数のサービス プロバイダーがアクセスできるようにすることも可能です。 このシナリオにより、サービス プロバイダーのテナントから複数の顧客にリソースをプロジェクションする ISV のシナリオも可能になります。

次のステップ