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

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

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

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

注意

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

概要

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

重要

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

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

  1. 移転を準備する

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

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

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

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

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

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

別のアプローチ

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

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

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

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

重要

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

サービスまたはリソース 影響を受ける 復旧可能 影響を受けるかどうか? 実行可能な操作
ロールの割り当て はい はい ロールの割り当てを一覧表示する すべてのロールの割り当ては完全に削除されます。 ユーザー、グループ、サービス プリンシパルを、ターゲット ディレクトリ内の対応するオブジェクトにマップする必要があります。 ロールの割り当てを再作成する必要があります。
カスタム ロール はい はい カスタム ロールを一覧表示する すべてのカスタム ロールは完全に削除されます。 カスタム ロールとロールの割り当てを再作成する必要があります。
システム割り当てのマネージド ID はい はい マネージド ID を一覧表示する マネージド ID を無効にして、再度有効にする必要があります。 ロールの割り当てを再作成する必要があります。
ユーザー割り当て済みマネージド ID はい はい マネージド ID を一覧表示する マネージド ID を削除して再作成し、適切なリソースにアタッチする必要があります。 ロールの割り当てを再作成する必要があります。
Azure Key Vault はい はい Key Vault アクセス ポリシーを一覧表示する キー コンテナーに関連付けられているテナント ID を更新する必要があります。 アクセス ポリシーを削除して、新しく追加する必要があります。
Azure AD 認証が統合された Azure SQL データベース はい いいえ Azure SQL データベースと Azure AD 認証を確認する Azure AD 認証が有効になっている Azure SQL データベースを別のディレクトリに転送することはできません。 詳細については、「Azure Active Directory 認証を使用する」を参照してください。
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 オブジェクト。 定義をエクスポート、インポート、および再割り当てする必要があります。 次に、新しいポリシー割り当てと、必要なポリシーの除外を作成します。
Azure Active Directory Domain Services はい いいえ Azure AD Domain Services の管理対象ドメインを別のディレクトリに転送することはできません。 詳細については、「Azure Active Directory (AD) Domain Services に関してよく寄せられる質問 (FAQ)」を参照してください。
アプリの登録 はい はい

警告

ストレージ アカウントや 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 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 のリスト

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

警告

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

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

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 --query id | sed -e 's/^"//' -e 's/"//' -e 's/\r$//')
    
  2. az graph 拡張機能を使用して、Azure AD ディレクトリの既知の依存関係がある他の 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 <scope>
    

ユーザー割り当てのマネージド 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 <scope>
    

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

ここでは、キー コンテナーを更新する基本的な手順について説明します。 詳細については、「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. 証明書を使用しているリソースについては、証明書を更新します。

次のステップ