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

  • [アーティクル]

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

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

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

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

Note

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

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

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

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

重要

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

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

Azure AD テナント間での委任サブスクリプションの移転

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

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

次のステップ