次の方法で共有

Azure Lighthouse のシナリオにおけるテナント、ユーザー、ロール

  • [アーティクル]

顧客を Azure Lighthouse にオンボードする前に、Microsoft Entra のテナント、ユーザー、ロールがどのように機能するか、およびそれらを Azure Lighthouse シナリオでどのように使用できるかを理解しておくことが重要です。

"テナント" は、Microsoft Entra ID の専用の信頼されたインスタンスです。 通常、各 Azure テナントは 1 つの組織を表します。 Azure Lighthouse を使用すると、あるテナントから別のテナントにリソースを論理的に投影できます。 これにより、(サービス プロバイダーに属するユーザーなどの) 管理テナントのユーザーは、顧客のテナント内の委任されたリソースにアクセスできるようになります。また、複数のテナントを持つ企業が、管理操作を一元的に実行できるようになります。

この論理的な投影を実現するには、顧客テナントのサブスクリプション (またはサブスクリプション内の 1 つ以上のリソース グループ) を、Azure Lighthouse に "オンボード" する必要があります。 オンボードは、Azure Resource Manager のテンプレートを使用して行うか、Azure Marketplace にパブリックまたはプライベート サービスを発行して行います。

いずれのオンボード方法を選択しても、承認を定義する必要があります。 各承認には、principalId (管理テナント内の Microsoft Entra ユーザー、グループ、またはサービス プリンシパル) と、委任されたリソースに対して付与される特定のアクセス許可を定義する組み込みロールが含まれます。

Note

明示的に指定されていない限り、Azure Lighthouse ドキュメント内で言及されている「ユーザー」は、認可に含まれる Microsoft Entra ユーザー、グループ、またはサービス プリンシパルに該当します。

ユーザーとロールを定義するためのベスト プラクティス

ご自分の承認を作成するときは、次のベスト プラクティスに従うことをお勧めします。

  • ほとんどの場合、一連の個々のユーザー アカウントではなく、Microsoft Entra のユーザー グループまたはサービス プリンシパルにアクセス許可を割り当てます。 これにより、個々のアクセス要件が変更されるごとに委任を更新することなく、テナントの Microsoft Entra ID を介して個々のユーザーのアクセスを追加または削除できます。
  • 最小限の特権の原則に従います。 不注意によるエラーが発生する可能性を減らすために、ユーザーは特定のジョブを実行するために必要なアクセス許可のみを持っている必要があります。 詳細については、「推奨セキュリティ プラクティス」を参照してください。
  • 必要に応じて委任へのアクセスを削除できるように、マネージド サービスの登録割り当ての削除ロールに承認を含めます。 このロールが割り当てられていない場合、委任されたリソースへのアクセは顧客のテナント内のユーザーによってのみ削除できます。
  • Azure portal の [マイ カスタマー] ページを表示する必要があるすべてのユーザーには、必ず閲覧者ロール (または閲覧者アクセスを含む別の組み込みロール) を付与します。

重要

Microsoft Entra グループのアクセス許可を追加するには、[グループの種類] を [セキュリティ] に設定する必要があります。 このオプションは、グループの作成時に選択します。 詳細については、「Microsoft Entra ID を使用した基本グループの作成およびメンバーの追加」を参照してください。

Azure Lighthouse 用のロールのサポート

承認を定義する場合、各ユーザー アカウントには、Azure の組み込みロールの 1 つを割り当てる必要があります。 カスタム ロールと従来のサブスクリプション管理者ロールはサポートされていません。

現在、Azure Lighthouse では、以下を除く、すべての組み込みロールがサポートされています。

  • 所有者ロールはサポートされていません。

  • ユーザー アクセス管理者ロールは、顧客のテナントのマネージド ID にロールを割り当てる目的限定でサポートされています。 このロールで通常付与されるその他の権限は適用されません。 ユーザーにこのロールを定義する場合は、このユーザーがマネージド ID に割り当てることができるロールも指定する必要があります。

  • DataActions 権限を持つすべてのロールはサポートされていません。

  • 次のいずれかのアクションを含むロールはサポートされていません。

    • */write
    • */delete
    • Microsoft.Authorization/*
    • Microsoft.Authorization/*/write
    • Microsoft.Authorization/*/delete
    • Microsoft.Authorization/roleAssignments/write
    • Microsoft.Authorization/roleAssignments/delete
    • Microsoft.Authorization/roleDefinitions/write
    • Microsoft.Authorization/roleDefinitions/delete
    • Microsoft.Authorization/classicAdministrators/write
    • Microsoft.Authorization/classicAdministrators/delete
    • Microsoft.Authorization/locks/write
    • Microsoft.Authorization/locks/delete
    • Microsoft.Authorization/denyAssignments/write
    • Microsoft.Authorization/denyAssignments/delete

重要

ロールを割り当てるときは、各ロールに対して指定されたアクションを確認してください。 DataActions アクセス許可を持つロールがサポートされていない場合でも、サポートされているロールに含まれるアクションによってデータへのアクセスが許可される場合があります。 これは一般に、ユーザーの ID を介してアクセスされず、アクセス キーを介してデータが公開されるときに発生します。 たとえば、仮想マシン共同作成者ロールには、特定の顧客データを取得するために使用できるストレージ アカウントのアクセス キーを返す Microsoft.Storage/storageAccounts/listKeys/action アクションが含まれます。

場合によっては、Azure Lighthouse で以前にサポートされていたロールが使用できなくなる場合があります。 たとえば、以前に DataActions アクセス許可を持っていなかったロールにそのアクセス許可が追加された場合、そのロールは新しい委任をオンボードする際に使用できなくなります。 そのロールが既に割り当てられているユーザーは、以前に委任されたリソースで引き続き作業できますが、DataActions アクセス許可を使用するタスクを実行することはできません。

適用可能な新しい組み込みロールが Azure に追加されるとすぐに、Azure Resource Manager テンプレートを使用してお客様をオンボードする際に割り当てることができます。 マネージド サービス オファーを発行する際に、新しく追加したロールがパートナー センターで使用できるようになるまでに時間がかかる場合があります。 同様に、ロールが使用できなくなった場合でも、パートナー センターにしばらく表示されることがあります。しかし、このようなロールを使用して新しいオファーを発行することはできません。

Microsoft Entra テナント間での委任されたサブスクリプションの転送

サブスクリプションが別の Microsoft Entra テナント アカウントに転送された場合、Azure Lighthouse オンボーディング プロセスで作成された登録定義と登録割り当てリソースは保持されます。 つまり、Azure Lighthouse で付与した管理テナントに対するアクセス権は、そのサブスクリプションで (あるいは、そのサブスクリプション内の委任リソース グループで) 引き続き有効です。

唯一の例外は、サブスクリプションが以前に委任された Microsoft Entra テナントに転送される場合です。 この場合、そのサブスクリプションは (Azure Lighthouse を通じて委任するのではなく) 直接そのテナントに属することになるため、テナントへの委任リソースは削除され、Azure Lighthouse で付与したアクセス権は適用されなくなります。 ただし、そのサブスクリプションを他の管理テナントに委任したこ場合は、それらの管理１テナントに、そのサブスクリプションに対するアクセス権がそのまま残ります。

次のステップ