Azure サブスクリプションを別の Microsoft Entra ディレクトリに移転する

組織には複数の Azure サブスクリプションがある場合があります。 各サブスクリプションは特定の Microsoft Entra ディレクトリと関連付けられています。 管理を容易にするために、サブスクリプションを別の Microsoft Entra ディレクトリに移転することが必要になる場合があります。 サブスクリプションを別の Microsoft Entra ディレクトリに移転する場合、一部のリソースはターゲット ディレクトリに移転されません。 たとえば、Azure のロールベースのアクセス制御 (Azure RBAC) でのすべてのロールの割り当てとカスタム ロールは、ソース ディレクトリからは完全に削除され、ターゲット ディレクトリには移転されません。

この記事では、サブスクリプションを別の Microsoft Entra ディレクトリに移転し、移転後にいくつかのリソースを再作成するために実行できる基本的な手順について説明します。

代わりに、ご自身の組織内のさまざまなディレクトリに対するサブスクリプションの転送をブロックする必要がある場合は、サブスクリプション ポリシーを構成できます。 詳細については、「Azure サブスクリプションのポリシーを管理する」を参照してください。

Note

Azure クラウド ソリューション プロバイダー (CSP) のサブスクリプションでは、サブスクリプションに対する Microsoft Entra ディレクトリの変更はサポートされていません。

概要

別の Microsoft Entra ディレクトリへの Azure サブスクリプションの移転は、慎重に計画して実行する必要がある複雑なプロセスです。 多くの Azure サービスでは、セキュリティ プリンシパル (ID) が通常どおりに動作するか、他の Azure リソースを管理する必要があります。 この記事では、セキュリティ プリンシパルに大きく依存する Azure サービスのほとんどについて説明しますが、これは包括的なものではありません。

重要

一部のシナリオでサブスクリプションを移転する場合、プロセスの完了にダウンタイムが必要なことがあります。 自分の移転でダウンタイムが必要になるかどうかを評価するには、慎重に計画する必要があります。

次の図では、サブスクリプションを別のディレクトリに移転するときに従う必要がある基本的な手順を示します。

  1. 移転を準備する

  2. Azure サブスクリプションを別のディレクトリに移転する

  3. ロールの割り当て、カスタム ロール、マネージド ID などのリソースをターゲット ディレクトリで再作成する

    サブスクリプションの移転の図

サブスクリプションを別のディレクトリに移転するかどうかを決定する

サブスクリプションを移転する理由には、次のようなものがあります。

  • 会社の合併や買収のため、取得したサブスクリプションをプライマリ Microsoft Entra ディレクトリで管理する必要があります。
  • 組織内のだれかが作成したサブスクリプションの管理を、特定の Microsoft Entra ディレクトリに統合する必要があります。
  • 特定のサブスクリプション ID または URL に依存するアプリケーションがあり、アプリケーションの構成やコードを簡単に変更することができません。
  • ビジネスの一部が別の会社に分割され、一部のリソースを別の Microsoft Entra ディレクトリに移動する必要があります。
  • セキュリティを分離するため、リソースの一部を別の Microsoft Entra ディレクトリで管理する必要があります。

別のアプローチ

サブスクリプションを移転するには、プロセスを完了するためにダウンタイムが必要です。 シナリオによっては、次の代替方法を検討できます。

  • リソースを再作成し、ターゲット ディレクトリおよびサブスクリプションにデータをコピーする。
  • マルチディレクトリ アーキテクチャを採用し、サブスクリプションをソース ディレクトリに残す。 ターゲット ディレクトリのユーザーがソース ディレクトリ内のサブスクリプションにアクセスできるように、Azure Lighthouse を使用してリソースを委任します。 詳しくは、「エンタープライズ シナリオにおける Azure Lighthouse」をご覧ください。

サブスクリプションの移転による影響を把握する

いくつかの Azure リソースは、サブスクリプションまたはディレクトリに依存しています。 次の表では、状況に応じたサブスクリプションの移転による既知の影響を示します。 この記事の手順を実行することで、サブスクリプションの移転前に存在していたリソースの一部を再作成できます。

重要

このセクションでは、サブスクリプションに依存する既知の Azure サービスまたはリソースの一覧を示します。 Azure のリソースの種類は絶えず進化しているため、ここに記載されていない追加の依存関係で、環境の破壊的変更の原因になるものがある可能性があります。

サービスまたはリソース 影響を受ける 回復可能 影響を受けますか? 実行可能な操作
ロールの割り当て はい はい ロールの割り当てを一覧表示する すべてのロールの割り当ては完全に削除されます。 ユーザー、グループ、サービス プリンシパルを、ターゲット ディレクトリ内の対応するオブジェクトにマップする必要があります。 ロールの割り当てを再作成する必要があります。
カスタム ロール はい はい カスタム ロールを一覧表示する すべてのカスタム ロールは完全に削除されます。 カスタム ロールとロールの割り当てを再作成する必要があります。
システム割り当てのマネージド ID はい はい マネージド ID を一覧表示する マネージド ID を無効にして、再度有効にする必要があります。 ロールの割り当てを再作成する必要があります。
ユーザー割り当て済みマネージド ID はい はい マネージド ID を一覧表示する マネージド ID を削除して再作成し、適切なリソースにアタッチする必要があります。 ロールの割り当てを再作成する必要があります。
Azure Key Vault はい はい Key Vault アクセス ポリシーを一覧表示する キー コンテナーに関連付けられているテナント ID を更新する必要があります。 アクセス ポリシーを削除して、新しく追加する必要があります。
Microsoft Entra 認証の統合が有効になってた Azure SQL データベース はい いいえ Azure SQL データベースと Microsoft Entra 認証を確認する Microsoft Entra 認証が有効になっている Azure SQL データベースを別のディレクトリに転送することはできません。 詳細については、「Microsoft Entra 認証を使用する」を参照してください。
Microsoft Entra 認証の統合が有効になった Azure Database for MySQL はい いいえ Microsoft Entra 認証が有効になっている Azure Database for MySQL (単一およびフレキシブル サーバー) を別のディレクトリに転送することはできません。
Azure Storage と Azure Data Lake Storage Gen2 はい はい すべての ACL を再作成する必要があります。
Azure Data Lake Storage Gen1 はい はい すべての ACL を再作成する必要があります。
Azure Files はい はい すべての ACL を再作成する必要があります。
Azure File Sync はい はい ストレージ同期サービスやストレージ アカウントは、別のディレクトリに移動できます。 詳細については、「Azure Files についてよく寄せられる質問 (FAQ)」を参照してください。
Azure Managed Disks はい はい ディスク暗号化セットを使用して、カスタマー マネージド キーで Managed Disks を暗号化する場合は、ディスク暗号化セットに関連付けられているシステム割り当て ID を無効にしてから、再度有効にする必要があります。 また、ロールの割り当てを再作成する必要があります。つまり、Key Vault 内にあるディスク暗号化セットに対し、必要なアクセス許可を再度付与します。
Azure Kubernetes Service はい いいえ AKS クラスターとそれに関連付けられているリソースを別のディレクトリに転送することはできません。 詳細については、「Azure Kubernetes Service (AKS) についてよく寄せられる質問」を参照してください。
Azure Policy はい いいえ カスタム定義、割り当て、除外、コンプライアンス データなど、すべての Azure Policy オブジェクト。 定義をエクスポート、インポート、および再割り当てする必要があります。 次に、新しいポリシー割り当てと、必要なポリシーの除外を作成します。
Microsoft Entra Domain Services はい いいえ Microsoft Entra Domain Services のマネージド ドメインを別のディレクトリに転送することはできません。 詳細については、Microsoft Entra Domain Services に関してよくあるご質問 (FAQ) についてのページを参照してください
アプリの登録 はい はい
Microsoft Dev Box はい いいえ 開発ボックスとそれに関連付けられているリソースを別のディレクトリに転送することはできません。 サブスクリプションを別のテナントに移行した後は、開発ボックスに対するアクションを実行できなくなります
Azure Deployment Environments はい いいえ 環境とそれに関連付けられているリソースを別のディレクトリに転送することはできません。 サブスクリプションを別のテナントに移行した後は、環境に対するアクションを実行できなくなります
Azure Service Fabric はい いいえ クラスターを再作成する必要があります。 詳細については、SF クラスターの FAQ に関するページまたは SF マネージド クラスターの FAQ に関するページを参照してください
Azure Service Bus はい はい マネージド ID を削除して再作成し、適切なリソースにアタッチする必要があります。 ロールの割り当てを再作成する必要があります。
Azure Synapse Analytics ワークスペース はい はい Synapse Analytics ワークスペースに関連付けられているテナント ID を更新する必要があります。 ワークスペースが Git リポジトリに関連付けられている場合、ワークスペースの Git 構成を更新する必要があります。 詳細については、「サブスクリプションを別の Microsoft Entra ディレクトリ (テナント) に移転した後の Synapse Analytics ワークスペースの回復」を参照してください。
Azure Databricks はい いいえ 現在、Azure Databricks では、新しいテナントへのワークスペースの移動はサポートされていません。 詳細については、「Azure Databricks アカウントを管理する」を参照してください。

警告

ストレージ アカウントや SQL データベースなどのリソースに対して保存時の暗号化を使用していて、それが移転されているキー コンテナーに対する依存関係を持つ場合、復旧不可能なシナリオが発生する可能性があります。 このような状況が発生した場合は、別のキー コンテナーを使用するか、ユーザーが管理するキーを一時的に無効にして、この復旧不可能なシナリオを回避する必要があります。

サブスクリプションを譲渡するとき、影響を受ける一部の Azure リソースの一覧を取得するには、Azure Resource Graph でクエリを実行することもできます。 サンプル クエリについては、Azure サブスクリプションの譲渡時に影響を受けるリソースの一覧に関するページを参照してください。

前提条件

これらの手順を完了するには、以下が必要です。

  • Azure Cloud Shell の Bash または Azure CLI
  • ソース ディレクトリ内で移動させるサブスクリプションの課金アカウント オーナー
  • ディレクトリを変更するユーザーのソース ディレクトリおよびターゲット ディレクトリ内のユーザー アカウント

手順 1: 移転を準備する

ソース ディレクトリにサインインする

  1. 管理者として Azure にサインインします。

  2. az account list コマンドを使用して、サブスクリプションの一覧を取得します。

    az account list --output table
    
  3. az account set を使用して、移転するアクティブなサブスクリプションを設定します。

    az account set --subscription "Marketing"
    

Azure Resource Graph 拡張機能をインストールする

Azure Resource Graph の Azure CLI 拡張機能である resource-graph を使用すると、az graph コマンドを使用して、Azure Resource Manager によって管理されているリソースを照会できます。 このコマンドは、後の手順で使用します。

  1. az extension list を使用して、resource-graph 拡張機能がインストールされているかどうかを確認します。

    az extension list
    
  2. プレビュー バージョンまたは古いバージョンの resource-graph 拡張機能を使用している場合は、az extension update を使用してこの拡張機能を更新します。

    az extension update --name resource-graph
    
  3. resource-graph 拡張機能がインストールされていない場合は、az extension add を使用してこの拡張機能をインストールします。

    az extension add --name resource-graph
    

すべてのロールの割り当てを保存する

  1. az role assignment list を使用して、すべてのロールの割り当ての一覧を表示します (継承されたロールの割り当てを含む)。

    一覧を簡単に確認できるように、出力を JSON、TSV、またはテーブルとしてエクスポートできます。 詳細については、「Azure RBAC と Azure CLI を使用してロールの割り当てを一覧表示する」を参照してください。

    az role assignment list --all --include-inherited --output json > roleassignments.json
    az role assignment list --all --include-inherited --output tsv > roleassignments.tsv
    az role assignment list --all --include-inherited --output table > roleassignments.txt
    
  2. ロールの割り当ての一覧を保存します。

    サブスクリプションを移転すると、すべてのロールの割り当てが完全に削除されます。そのため、コピーを保存しておくことが重要です。

  3. ロールの割り当ての一覧を確認します。 ターゲット ディレクトリに必要のないロールの割り当てが存在する可能性があります。

カスタムロールを保存する

  1. カスタム ロールの一覧を表示するには、az role definition list を使用します。 詳細については、「Azure CLIを使用して Azure カスタム ロールを作成または更新する」を参照してください。

    az role definition list --custom-role-only true --output json --query '[].{roleName:roleName, roleType:roleType}'
    
  2. ターゲット ディレクトリに必要な各カスタム ロールを、別の JSON ファイルとして保存します。

    az role definition list --name <custom_role_name> > customrolename.json
    
  3. カスタム ロール ファイルのコピーを作成します。

  4. 次の形式を使用するように各コピーを変更します。

    後でこれらのファイルを使用して、ターゲット ディレクトリにカスタム ロールを再作成します。

    {
      "Name": "",
      "Description": "",
      "Actions": [],
      "NotActions": [],
      "DataActions": [],
      "NotDataActions": [],
      "AssignableScopes": []
    }
    

ユーザー、グループ、サービス プリンシパルのマッピングを決定する

  1. ロールの割り当ての一覧に基づいて、ターゲット ディレクトリでマップするユーザー、グループ、サービス プリンシパルを決定します。

    各ロールの割り当ての principalType プロパティを参照することで、プリンシパルの種類を特定できます。

  2. 必要に応じて、ターゲット ディレクトリに、必要なユーザー、グループ、またはサービス プリンシパルを作成します。

マネージド ID のロールの割り当ての一覧を表示する

サブスクリプションを別のディレクトリに移転したとき、マネージド ID は更新されません。 その結果、既存のシステム割り当てマネージド ID やユーザー割り当てマネージド ID は破損します。 移転後、システム割り当てマネージド ID を再び有効にすることができます。 ユーザー割り当てマネージド ID の場合は、ターゲット ディレクトリで再作成してアタッチする必要があります。

  1. マネージド ID がサポートされている Azure サービスの一覧を確認して、マネージド ID を使用している可能性がある場所を記録します。

  2. システム割り当てとユーザー割り当てのマネージド ID の一覧を表示するには、az ad sp list を使用します。

    az ad sp list --all --filter "servicePrincipalType eq 'ManagedIdentity'"
    
  3. マネージド ID の一覧で、システム割り当てのものとユーザー割り当てのものを特定します。 次の条件を使用して、種類を特定できます。

    基準 マネージド ID の種類
    alternativeNames プロパティに isExplicit=False が含まれる システム割り当て
    alternativeNames プロパティに isExplicit が含まれない システム割り当て
    alternativeNames プロパティに isExplicit=True が含まれる ユーザー割り当て

    また、az identity list コマンドを使用して、ユーザー割り当てマネージド ID だけの一覧を表示することもできます。 詳細については、「Azure CLI を使用してユーザー割り当てマネージド ID を作成、一覧表示、または削除する」を参照してください。

    az identity list
    
  4. マネージド ID の objectId 値の一覧を取得します。

  5. ロールの割り当ての一覧を検索して、マネージド ID に対するロールの割り当てがあるかどうかを確認します。

Key Vault のリスト

キー コンテナーを作成すると、それが作成されたサブスクリプションの既定の Microsoft Entra テナント ID に自動的に関連付けられます。 また、すべてのアクセス ポリシー エントリがこのテナント ID に関連付けられます。 詳細については、「Azure Key Vault を別のサブスクリプションに移動する」を参照してください。

警告

ストレージ アカウントや SQL データベースなどのリソースに対して保存時の暗号化を使用していて、それが移転されているキー コンテナーに対する依存関係を持つ場合、復旧不可能なシナリオが発生する可能性があります。 このような状況が発生した場合は、別のキー コンテナーを使用するか、ユーザーが管理するキーを一時的に無効にして、この復旧不可能なシナリオを回避する必要があります。

Azure SQL データベースと Microsoft Entra 認証を一覧表示する

  • Microsoft Entra 認証の統合が有効になっている Azure SQL データベースを使用しているかどうかを確認するには、az sql server ad-admin listaz graph 拡張機能を使用します。 詳細については、SQL による Microsoft Entra 認証の構成と管理に関する説明を参照してください。

    az sql server ad-admin list --ids $(az graph query -q "resources | where type == 'microsoft.sql/servers' | project id" --query data[*].[id] -o tsv)
    

ACL の一覧を表示する

  1. Azure Data Lake Storage Gen1 を使用している場合は、Azure portal または PowerShell を使用して、ファイルに適用されている ACL の一覧を表示します。

  2. Azure Data Lake Storage Gen2 を使用している場合は、Azure portal または PowerShell を使用して、ファイルに適用されている ACL の一覧を表示します。

  3. Azure Files を使用している場合は、ファイルに適用されている ACL の一覧を表示します。

他の既知のリソースの一覧を表示する

  1. az account show を使用して、サブスクリプション IDを取得します (bash 内)。

    subscriptionId=$(az account show --output tsv --query id)
    
  2. az graph 拡張機能を使用して、Microsoft Entra ディレクトリの既知の依存関係がある他の Azure リソースの一覧を表示します (bash 内)。

    az graph query -q 'resources 
        | where type != "microsoft.azureactivedirectory/b2cdirectories" 
        | where  identity <> "" or properties.tenantId <> "" or properties.encryptionSettingsCollection.enabled == true 
        | project name, type, kind, identity, tenantId, properties.tenantId' --subscriptions $subscriptionId --output yaml
    

手順 2: サブスクリプションを移転する

この手順では、サブスクリプションを、ソース ディレクトリからターゲット ディレクトリに移転します。 この手順は、課金所有権も移転するかどうかによって変わります。

警告

サブスクリプションを移転すると、ソース ディレクトリ内のすべてのロールの割り当てが完全に削除されて復元できなくなります。 サブスクリプションの移転は、元に戻すことはできません。 このステップを実行する前に、これまでの手順を完了していることを確認してください。

  1. 課金所有権も別のアカウントに移転するかどうかを決定します。

  2. サブスクリプションを別のディレクトリに移転します。

  3. サブスクリプションの移転が完了したら、この記事に戻り、ターゲット ディレクトリにリソースを再作成します。

手順 3: リソースを再作成する

ターゲット ディレクトリにサインインする

  1. ターゲット ディレクトリで、移転要求を受け入れたユーザーとしてサインインします。

    移転要求を受け入れた新しいアカウントのユーザーだけが、リソースにアクセスして管理できます。

  2. az account list コマンドを使用して、サブスクリプションの一覧を取得します。

    az account list --output table
    
  3. az account set を使用して、使用するアクティブなサブスクリプションを設定します。

    az account set --subscription "Contoso"
    

カスタム ロールを作成する

ロールの割り当て

システム割り当てのマネージド ID を更新する

  1. システム割り当てのマネージドID を無効にした後、再び有効にします。

    Azure サービス 詳細情報
    仮想マシン Azure CLI を使用して Azure VM 上に Azure リソースのマネージド ID を構成する
    仮想マシン スケール セット Azure CLI を使用して仮想マシン スケール セットで Azure リソースのマネージド ID を構成する
    その他のサービス Azure リソースのマネージド ID をサポートするサービス
  2. az role assignment create を使用して、システム割り当てマネージド ID にロールを割り当てます。 詳細については、「Azure CLI を使用して、リソースにマネージド ID アクセスを割り当てる」を参照してください。

    az role assignment create --assignee <objectid> --role '<role_name_or_id>' --scope "/subscriptions/<subscriptionId>/resourceGroups/<resource_group>"
    

ユーザー割り当てのマネージド ID を更新する

  1. ユーザー割り当てのマネージド ID を削除し、再作成して、アタッチします。

    Azure サービス 詳細情報
    仮想マシン Azure CLI を使用して Azure VM 上に Azure リソースのマネージド ID を構成する
    仮想マシン スケール セット Azure CLI を使用して仮想マシン スケール セットで Azure リソースのマネージド ID を構成する
    その他のサービス Azure リソースのマネージド ID をサポートするサービス
    Azure CLI を使用してユーザー割り当てマネージド ID を作成、一覧表示、または削除する
  2. az role assignment create を使用して、ユーザー割り当てマネージド ID にロールを割り当てます。 詳細については、「Azure CLI を使用して、リソースにマネージド ID アクセスを割り当てる」を参照してください。

    az role assignment create --assignee <objectid> --role '<role_name_or_id>' --scope "/subscriptions/<subscriptionId>/resourceGroups/<resource_group>"
    

キー コンテナーを更新する

ここでは、キー コンテナーを更新する基本的な手順について説明します。 詳細については、「Azure Key Vault を別のサブスクリプションに移動する」を参照してください。

  1. サブスクリプションで既存のすべてのキー コンテナーに関連付けられているテナント ID を、ターゲット ディレクトリに更新します。

  2. すべての既存のアクセス ポリシー エントリを削除する。

  3. ターゲット ディレクトリに関連付けられた新しいアクセス ポリシー エントリを追加します。

ACL を更新する

  1. Azure Data Lake Storage Gen1 を使用している場合は、適切な ACL を割り当てます。 詳細については、「Securing data stored in Azure Data Lake Storage Gen1 (Azure Data Lake Storage Gen1 に格納されているデータのセキュリティ保護)」をご覧ください。

  2. Azure Data Lake Storage Gen2 を使用している場合は、適切な ACL を割り当てます。 詳細については、Azure Data Lake Storage Gen2 でのアクセス制御に関するページを参照してください。

  3. Azure Files を使用している場合は、適切な ACL を割り当てます。

他のセキュリティ メソッドを確認する

ロールの割り当ては移転の間に削除されますが、元の所有者アカウントのユーザーが、次のような他のセキュリティ メソッドを使用して、引き続きサブスクリプションにアクセスできる場合があります。

  • Storage などのサービス用のアクセス キー。
  • サブスクリプションのリソースに対する管理者アクセス権をユーザーに付与する管理証明書
  • Azure Virtual Machines などのサービス用のリモート アクセス資格情報。

ソース ディレクトリのユーザーがターゲット ディレクトリにアクセスできないように、アクセス権を削除する場合は、すべての資格情報のローテーションを検討する必要があります。 資格情報が更新されるまで、移転後もユーザーは引き続きアクセスできます。

  1. ストレージ アカウントのアクセス キーをローテーションします。 詳細については、「ストレージ アカウントのアクセス キーの管理」を参照してください。

  2. Azure SQL Database や Azure Service Bus メッセージングなどの他のサービスにアクセス キーを使用している場合は、アクセス キーをローテーションします。

  3. シークレットを使用しているリソースについては、リソースの設定を開き、シークレットを更新します。

  4. 証明書を使用しているリソースについては、証明書を更新します。

次のステップ