次の方法で共有

テナント間の管理エクスペリエンス

  • [アーティクル]

サービス プロバイダーは、Microsoft Entra テナント内の顧客の Azure リソースを管理するために、Azure Lighthouse を使用できます。 多くの一般的なタスクおよびサービスは、これらの管理対象テナントをまたがって実行できます。

ヒント

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

テナントと委任について

Microsoft Entra テナントは、組織を表すものです。 これは、組織が Azure、Microsoft 365、またはその他のサービスへのサインアップによって Microsoft との関係を築いたときに受け取る Microsoft Entra ID 専用のインスタンスです。 各 Microsoft Entra テナントは、他の Microsoft Entra テナントとは異なり、区別されており、独自のテナント ID (GUID) を持ちます。 詳細については、「Microsoft Entra ID とは」を参照してください。

通常、顧客の Azure リソースを管理するために、サービス プロバイダーは、その顧客のテナントに関連付けられたアカウントを使用して Azure portal にサインインする必要があります。 このシナリオでは、顧客のテナント内の管理者がサービス プロバイダー用のユーザー アカウントを作成し、管理する必要があります。

Azure Lighthouse を使用する場合、オンボード プロセスでは、顧客のテナント内の委任されたサブスクリプションおよびリソース グループにロールが割り当てられる、サービス プロバイダーのテナント内のユーザーを指定します。 その後、これらのユーザーは、独自の資格情報を使用して Azure portal にサインインし、自分がアクセスできるすべての顧客に属しているリソースを操作できます。 管理側テナントのユーザーは、Azure portal の [マイ カスタマー] ページにアクセスして、これらのすべての顧客を表示できます。 彼らは、Azure portal または API を使用して、顧客のサブスクリプションのコンテキスト内で直接リソースを操作することもできます。

Azure Lighthouse を使用すると、テナントによって異なるアカウントにサインインしなくても、複数の顧客のリソースを柔軟に管理できます。 たとえば、サービス プロバイダーには、責任とアクセス レベルが異なる 2 人の顧客が存在するとします。 Azure Lighthouse を使用すれば、許可されているユーザーはサービス プロバイダーのテナントにサインインし、委任ごとに割り当てられたロールにしたがって、これらの顧客にわたってすべての委任されたリソースにアクセスできます。

1 つのサービス プロバイダーのテナントを通じて管理される 2 人の顧客のリソースを示す図。

API と管理ツールのサポート

Azure portal で、委任されたリソースに対する管理タスクを実行できます。また、API および管理ツール (Azure CLI や Azure PowerShell など) を使用することもできます。 既存の API はすべて、委任されたリソースに対して使用できます。ただし、テナント間の管理において機能がサポートされており、ユーザーが適切なアクセス許可を持っている必要があります。

Azure PowerShell の Get-AzSubscription コマンドレットでは、既定で管理側テナントの TenantId が表示されます。 各サブスクリプションの HomeTenantId と ManagedByTenantIds 属性を使用すると、返されたサブスクリプションが管理対象のテナントと管理側テナントのどちらに属しているかを識別できます。

同様に、az account list などの Azure CLI コマンドでは、homeTenantId 属性と managedByTenants 属性が表示されます。 Azure CLI の使用時にこれらの値が表示されない場合は、az account clear を実行してから az login --identity を実行して、キャッシュをクリアしてみてください。

Azure REST API では、Subscriptions - Get コマンドと Subscriptions - List コマンドに ManagedByTenant が含まれています。

注意

Azure Lighthouse に関連するテナント情報に加え、これらの API で表示されるテナントには、Azure Databricks または Azure マネージド アプリケーションのパートナー テナントが反映されることがあります。

また、Azure Lighthouse タスクの実行に固有の API も用意されています。 詳細については、リファレンスを参照してください。

強化されたサービスとシナリオ

ほとんどの Azure タスクとサービスは、適切なロールが付与されていることを前提として、管理対象のテナント間で委任されたリソースと共に使用できます。 テナント間の管理が特に効果的な重要なシナリオの一部を以下に示します。

Azure Arc:

Azure Automation:

  • Automation アカウントを使用して、委任されたリソースにアクセスして操作する

Azure Backup:

  • Azure Backup を使用して顧客データをバックアップおよび復元します。 現在、以下の Azure ワークロードがサポートされています: Azure Virtual Machines (Azure VM)、Azure Files、Azure VM 上の SQL Server、Azure VM 上の SAP HANA。 現在、バックアップ コンテナーを利用するワークロード (Azure Database for PostgreSQL、Azure Blob、Azure マネージド ディスク、Azure Kubernetes Services) は、完全にはサポートされていません。
  • バックアップ センターで、委任された顧客リソースすべてのデータを表示する
  • バックアップ エクスプローラーを使用すると、バックアップ項目 (まだバックアップ対象として構成されていない Azure リソースを含む) の運用情報と、委任されたサブスクリプションの監視情報 (ジョブとアラート) を表示できます。 バックアップ エクスプローラーは、現在、Azure VM データに対してのみ使用できます。
  • 委任されたサブスクリプションにわたってバックアップ レポートを使用して、過去の傾向を追跡し、バックアップ ストレージの使用量を分析し、バックアップと復元を監査します。

Azure Blueprints:

  • Azure Blueprints を使用して、リソース テンプレートおよびその他の成果物のデプロイを調整します (顧客のサブスクリプションを準備するには、追加のアクセスが必要です)。

Azure Cost Management および Billing:

  • CSP パートナーは、管理しているテナントから、Azure プランに含まれるお客様に対する、(購入を含めずに) 税引き前消費コストを表示、管理、分析できます。 コストは、小売価格と、お客様のサブスクリプションに対してパートナーが持っている Azure ロールベースのアクセス制御 (Azure RBAC) アクセスに基づきます。 現時点では、Azure RBAC アクセスに基づいて、個々のお客様のサブスクリプションごとに消費コストを小売価格で表示できます。

Azure Key Vault:

  • 顧客テナント内で Key Vault を作成する
  • マネージド ID を使用して顧客テナント内で Key Vault を作成する

Azure Kubernetes Service (AKS):

  • ホストされている Kubernetes 環境を管理し、顧客のテナント内でコンテナー化されたアプリケーションをデプロイして管理する
  • 顧客テナントのクラスターをデプロイおよび管理する
  • コンテナーに対して Azure Monitor を使用して、顧客テナントをまたがってパフォーマンスを監視する

Azure Migrate:

  • 顧客テナントで移行プロジェクトを作成して VM を移行する

Azure Monitor:

  • すべてのサブスクリプションにわたるアラートを表示する機能を使って、委任されたサブスクリプションに対するアラートを表示および更新する
  • 委任されたサブスクリプションのアクティビティ ログの詳細を表示する
  • ログ分析:複数のテナントにあるリモートのワークスペースからデータを照会する (顧客テナントのワークスペースからデータにアクセスするために使用される Automation アカウントは、同じテナント内に作成する必要があることに注意してください)
  • 顧客のテナント内でアラートの作成、表示、および管理を行う
  • 顧客のテナント内に、Webhook を使用して管理側テナントで Azure Automation Runbook や Azure Functions などの自動化をトリガーするアラートを作成する
  • 顧客テナント内に作成されたワークスペースで診断設定を作成して、管理テナント内のワークスペースにリソース ログを送信する
  • SAP ワークロードに対しては、顧客のテナント全体で集計されたビューを使って SAP ソリューションのメトリックを監視する
  • Azure AD B2C では、サインインと監査ログをさまざまな監視ソリューションにルーティングします

Azure のネットワーク:

Azure Policy:

  • 委任されたサブスクリプション内でポリシー定義を作成および編集する
  • 複数のテナントにわたってポリシー定義とポリシー割り当てをデプロイする
  • 委任されたサブスクリプション内で顧客が定義したポリシー定義を割り当てる
  • 顧客には、サービス プロバイダーが作成したポリシーと顧客自身が作成したポリシーが並べて表示される
  • 管理対象のテナント内で deployIfNotExists の修復または割り当ての変更を行うことができる
  • 現在、顧客のテナント内にある準拠していないリソースのコンプライアンスの詳細を表示することはできません

Azure Resource Graph:

  • 返されるクエリ結果内のテナント ID を参照して、サブスクリプションが管理対象のテナントに属しているかどうかを特定できるようにする

Azure Service Health:

  • Azure Resource Health を使用して、顧客のリソースの正常性を監視する
  • 顧客が使用している Azure サービスの正常性を追跡する

Azure Site Recovery:

  • 顧客のテナント内にある Azure 仮想マシンのディザスター リカバリー オプションを管理する (VM 拡張機能のコピーには RunAs アカウントを使用できないことに注意してください)

Azure Virtual Machines:

  • 仮想マシン拡張機能を使用して、Azure VM のデプロイ後の構成と自動タスクを提供する
  • ブート診断を使用して、Azure VM のトラブルシューティングを行う
  • シリアル コンソールを使用して VM にアクセスする
  • ポリシーによるマネージド ID を使用して、ディスク暗号化のためのパスワード、シークレット、または暗号化キー用に VM を Azure Key Vault と統合して、シークレットが管理対象のテナントの Key Vault に確実に保存されるようにする
  • VM へのリモート ログインには Microsoft Entra ID は使えないことに注意します

Microsoft Defender for Cloud:

  • テナント間の表示
    • セキュリティ ポリシーへの準拠を監視し、セキュリティの適用範囲がすべてのテナントのリソースになるようにする
    • 1 つのビューで複数のテナントの規制へのコンプライアンスを継続的に監視する
    • セキュリティ スコアの計算を使用して実行可能なセキュリティの推奨事項の監視、トリアージ、優先度付けを行う
  • テナント間のセキュリティ体制の管理
    • セキュリティ ポリシーの管理
    • 実行可能なセキュリティの推奨事項に準拠していないリソースに対処する
    • セキュリティ関連のデータを収集して保存する
  • テナント間の脅威の検出と保護
    • テナントのリソース全体で脅威を検出する
    • Just-In-Time (JIT) VM アクセスなど、高度な脅威保護コントロールを適用する
    • アダプティブ ネットワーク強化を使用してネットワーク セキュリティ グループの構成を強化する
    • サーバーで、適応型アプリケーション制御の対象とすべきアプリケーションとプロセスのみが実行されるようにする
    • ファイルの整合性の監視 (FIM) を使用して、重要なファイルとレジストリ エントリに対する変更を監視する
  • 管理テナントにはサブスクリプション全体を委任する必要があることにご注意ください。Microsoft Defender for Cloud のシナリオでは、委任されたリソース グループではサポートされていません。

Microsoft Sentinel:

サポート リクエスト:

現在の制限

すべてのシナリオで、次に示す現在の制限事項に注意してください。

  • Azure Resource Manager で処理される要求は、Azure Lighthouse を使用して実行できます。 これらの要求の操作 URI は、https://management.azure.com で始まります。 ただし、リソースの種類のインスタンス (Key Vault のシークレット アクセスやストレージのデータ アクセスなど) によって処理される要求は、Azure Lighthouse ではサポートされていません。 これらの要求の操作 URI は、通常、https://myaccount.blob.core.windows.net や https://mykeyvault.vault.azure.net/ など、実際のインスタンスに固有のアドレスで始まります。 また、通常、後者は管理操作ではなくデータ操作です。
  • ロールの割り当てには Azure 組み込みロールを使用する必要があります。 所有者、または DataActions アクセス許可を持つ組み込みロールを除くすべての組み込みロールが、Azure Lighthouse で現在サポートされています。 マネージド ID へのロールの割り当てにおいて、ユーザー アクセス管理者ロールは、限定された用途のみに対してサポートされています。 カスタム ロールと従来のサブスクリプション管理者ロールはサポートされていません。 詳細については、「Azure Lighthouse 用のロールのサポート」を参照してください。
  • マネージド テナントのユーザーの場合、Azure Lighthouse を通じて行われたロールの割り当ては、アクセス制御 (IAM) や az role assignment list などの CLI ツールには表示されません。 これらの割り当ては、Azure portal の Azure Lighthouse の [委任] セクション、または Azure Lighthouse API 経由でのみ表示されます。
  • Azure Databricks を使用するサブスクリプションをオンボードすることはできますが、管理テナントのユーザーは、委任されたサブスクリプションで Azure Databricks ワークスペースを起動することはできません。
  • リソース ロックがあるサブスクリプションとリソース グループをオンボードすることはできますが、このようなロックがあっても、管理テナントのユーザーによるアクションの実行は妨げられません。 Azure マネージド アプリケーションまたは Azure Blueprints によって作成されたものなど、システムの管理対象リソースを保護する拒否割り当て (システム割り当ての拒否割り当て) がある場合、管理テナントのユーザーはそれらのリソースを操作できません。 ただし、顧客テナントのユーザーは自分の拒否割り当てを作成できません。
  • 各国のクラウドと Azure パブリック クラウドにわたって行われる、または 2 つの独立した国内クラウドにわたって行われるサブスクリプションの委任はサポートされていません。

次のステップ