特殊なケースを処理する

プロジェクトを移行する際の特殊なケースの処理方法について説明します。プロジェクトを移行する前に、プロジェクト、その親リソース、移行先リソースに必要な Identity and Access Management（IAM） 権限があることを確認してください。

組織リソースに関連付けられていないプロジェクトを移行する

関連する組織リソースなしで作成されたプロジェクトは、組織リソースの階層に移行できます。ただし、このプロセスを元に戻すことはできません。プロジェクトを [**組織なし**] に戻すには、 Cloud カスタマーケアにお問い合わせください。

組織リソースに関連付けられていないプロジェクトを移行するには、プロジェクトに対する roles/resourcemanager.projectIamAdmin ロールが必要です。また、移行先の組織リソースに対する roles/resourcemanager.projectCreator ロールも必要です。

親組織リソースに対する resourcemanager.organizations.get 権限がない場合、プロジェクトが コンソールの組織に想定どおりに表示されないことがあります。 Cloud de Confiance これにより、プロジェクトが組織リソースに関連付けられていないように見えることがあります。詳細については、 ユーザーのプロジェクト公開設定の制限をご覧ください。

プロジェクトが組織リソースに関連付けられているかどうかを確認するには、次の操作を行います。

gcloud

次のコマンドを実行します。

gcloud projects describe PROJECT_ID

PROJECT_ID は、移行するプロジェクトの ID に置き換えます。

出力に parent リソースが表示されない場合、プロジェクトが組織リソースに関連付けられていないことが確認できます。

出力に parent リソース（フォルダまたは組織リソース）が表示される場合、プロジェクトが組織リソースに関連付けられていることが確認できます。

組織リソースに関連付けられていないプロジェクトを移行するプロセスは、組織リソース間でプロジェクトを移行するプロセスと類似していますが、移行計画にかかわるすべての手順が必要になるわけではありません。プロジェクトを組織リソースに移行する手順は次のとおりです。

  1. 継承される ポリシーがこのプロジェクトに与える影響を確認してください。

  2. 必要に応じて、移行先の組織リソースに専用のインポート フォルダを 作成します。

  3. 権限を割り当てるで詳しく説明しているように、プロジェクト と宛先の親 リソースに Identity and Access Management の権限を割り当てます。

  4. 請求先アカウントを変更する必要があるかどうかを確認します。

その後、次のいずれかの方法で移行を実行できます。

コンソール

  1. コンソール Cloud de Confiance で [IAM と管理 > 設定] ページを開きます。

    [設定] ページを開く

  2. プロジェクト選択ツールを使用して、プロジェクト（[組織なし] のプロジェクト）を選択します。

  3. [設定] ページの上部にある [移行] をクリックします。

  4. 表示されるダイアログで、プロジェクトの移行先の組織リソースを選択し、[移行] をクリックします。

gcloud

組織リソースにプロジェクトを移行するには、以下のコマンドを実行します。

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

次のように置き換えます。

  • PROJECT_ID: 移行するプロジェクトの ID
  • ORGANIZATION_ID: 移行先の組織 リソースの ID

API

Resource Manager API を使用して、parent フィールドを組織リソースの組織リソース ID に設定することで、組織リソースにプロジェクトを移行できます。

組織リソースにプロジェクトを移行するには:

  • projects.get() メソッドを使用して project オブジェクトを取得します。
  • parent フィールドを組織リソースの組織リソース ID に設定します。
  • project オブジェクトを projects.update() メソッドを使用して更新します。

設定した parent フィールドは変更できません。

次のコード スニペットは、これらの手順を示しています。

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

ソース プロジェクトで Cloud OS Login API が 有効になっている場合は、そのプロジェクトにアクセスできるプリンシパルに roles/compute.osLoginExternalUser ロールを割り当てます。

共有 VPC

共有 VPC プロジェクトは、次の特定の条件に従って移行できます。まず、ソース組織リソースの roles/orgpolicy.policyAdmin ロールを持つユーザーは、エクスポート対象プロジェクトの親に対する constraints/resourcemanager.allowEnabledServicesForExport 制約を含む組織のポリシーを設定する必要があります。この制約により、SHARED_VPC は allowed_value として表示されるはずです。

移行前に共有 VPC を無効にする必要はありません。ただし、共有 VPC ホスト プロジェクトを最初に移行してから、そのサービス プロジェクトのすべてを移行する必要があります。ソース組織リソースと移行先組織リソース間でファイアウォール ルールを一致させることをおすすめします。これにより、潜在的な問題を最小限に抑え、ダウンタイムを回避できます。一部のサービス プロジェクトをソース組織リソースに残し、他のプロジェクトを移行した場合、ネットワークの健全性は保証されません。

ホスト プロジェクトを移行すると、移行元の組織リソースに戻すことができます。ホスト プロジェクトとサービス プロジェクトが異なる組織に存在できる期限は厳密に決まっていません。ただし、サービス プロジェクトの移行を開始したら、ホスト プロジェクトが再び移行できるようになる前に、すべてのプロジェクトを移行する必要があります。

カスタムの IAM の役割

Identity and Access Management のカスタムロールを使用すると、組織リソース レベルでリソースへのアクセス権を きめ細かく管理できますが、 これはそのロールを作成した組織リソース内でのみ有効です。組織レベルのカスタム IAM ロールへの許可ポリシー バインディングを含むプロジェクトを移行すると、移行は失敗します。このエラーは、移行先の組織リソースにロールが存在しないことを示しています。

組織リソース内のすべてのカスタム IAM ロールを一覧表示するには、次のコマンドを実行します。

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_ID は組織リソースの ID に置き換えます。 詳細については、組織リソース ID を取得するをご覧ください。

組織リソース内のカスタムの Identity and Access Management ロールに関する情報を取得するには、次のコマンドを実行します。

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

次のように置き換えます。

  • ORGANIZATION_ID: 組織リソースの ID
  • ROLE_ID: 説明するロールの名前

このエラーを回避するには、継承された組織レベルのカスタムロールごとに、同等のプロジェクト レベルのカスタムロールを作成します。次に、組織レベルのカスタムロールを参照する IAM ロール バインディングを削除します。

プロジェクトの移行後、許可ポリシーを更新して、移行先組織リソースで組織レベルのカスタムロールを使用できます。

詳しくは、カスタム役割の作成と管理をご覧ください。

バケットロック

Cloud Storage のバケットロックを使用すると、Cloud Storage バケットのデータ 保持ポリシーを構成できます。このポリシーは、オブジェクトを保持する期間を管理します。バケットロックは、 リーエンを使用して保護され、プロジェクトが誤って削除されるのを防止します。

保持ポリシーとリーエンは移行中もプロジェクトに保持されます。リーエンによってプロジェクトの移行が妨げられることはありません。

VPC Service Controls のセキュリティ境界

VPC Service Controls は、サービスを中心にプロジェクト ベースのセキュリティ境界を設定することで、データ の引き出しのリスクを軽減します Cloud de Confiance by S3NS 。VPC Service Controls のセキュリティ境界で保護されているプロジェクトは移行できません。

セキュリティ境界からプロジェクトを削除するには、サービス境界の管理をご覧ください。プロジェクトをサービス境界から削除してから移行できるようになるまで、数時間から 1 日かかることがあります。

サービス アカウントのコンテキストアウェア アクセス ポリシー

コンテキストアウェア アクセス を使用すると、ネットワーク、ロケーション、時間などのコンテキスト属性に基づいて、 Cloud de Confiance by S3NS サービス アカウントの リソースに対するアクセス ポリシーを定義できます。 サービス アカウントのコンテキストアウェア アクセス ポリシーが 1 つ以上あるプロジェクトは移行できません。

サービス アカウントのコンテキストアウェア アクセス ポリシーを削除するには、 アクセス バインディングの管理をご覧ください。

ポリシーの作成または削除を行う際は、次のタイミングに関する考慮事項に注意してください。

  • ポリシーの作成: 新しく作成されたコンテキストアウェア アクセス ポリシーによって、移行がすぐにブロックされないことがあります。この伝播の遅延は、ポリシーの作成後 24 時間続くことがあります。
  • ポリシーの削除: プロジェクトからすべてのコンテキストアウェア アクセス ポリシーが削除された後、プロジェクトを移行できるようになるまでに数時間かかることがあります。

Dedicated Interconnect

Dedicated Interconnect オブジェクトを使用するプロジェクトと VLAN アタッチメントを使用するプロジェクトを一緒に移行することをおすすめします。これらのオブジェクトを使用するプロジェクトは、組織リソース間の移行後も引き続き機能します。ただし、組織リソースが分割されている間は、組織リソース間に新しい VLAN アタッチメントを作成することはできません。

分割されたプロジェクトに加えられた構成変更は、組織リソース間で伝播されない場合があります。プロジェクトを長時間分割したままにしないことをおすすめします。

Partner Interconnect

Partner Interconnect を使用してプロジェクトを移行する場合、特別な考慮事項はありません。 Partner Interconnect を使用してプロジェクトを移行する場合、特別な考慮事項はありません。

管理プロジェクト

管理プロジェクト は、 Cloud de Confiance by S3NS アプリ対応フォルダ内のプロジェクトで、すべての アプリケーション中心のメタデータの中央リポジトリとして機能します。各アプリ対応フォルダに含まれる管理プロジェクトは 1 つのみです。 管理プロジェクトは、アプリケーション ライブラリと API のインフラストラクチャを提供します。これには、課金、割り当て、アクセス制御が含まれます。管理プロジェクトは移行できません。

プロジェクト間のサービス アカウント

プロジェクト間のサービス アカウントを移行する場合は、 次のケースが適用されます。

  • プロジェクト間のサービス アカウントが付加されているプロジェクトを移行する場合、そのサービス アカウントは移行先の組織リソースで引き続き機能します。これは、組織のポリシーでドメインが制限されている場合でも適用されます。
  • 別のプロジェクトで使用されているプロジェクト間のサービス アカウントを所有するプロジェクトを移行する場合、サービス アカウントは引き続き機能します。ただし、移行元組織リソースのドメインに制限するドメイン制限の組織ポリシーが適用されているリソースでは、サービス アカウントを使用できません。

たとえば、organizations/12345678901 の project-A に serviceAccount-1 が付加されているとします。同じ組織内の project-B と project-C も serviceAccount-1 を使用します。

project-C には、organizations/12345678901 ドメインのみを許可する組織のポリシーがあります。

project-A を organizations/45678901234 に移行する前に、project-C の IAM バインディングに serviceAccount-1 を追加すると、サービス アカウントが機能します。

project-A を organizations/45678901234 に移行し、project-C の IAM バインディングに serviceAccount-1 を追加しようとすると、バインディングがドメイン制限制約に違反するため、そのバインディングは失敗します。

サポートケース

未解決のサポート記録があるプロジェクトを移行する場合は、移行後に Cloud カスタマーケアに通知してください。Cloud カスタマーケアがメタデータを新しい組織リソースに更新するまで、そのサポート記録を表示することはできません。

プロジェクトで内部 OAuth 同意 画面を使用している場合、移行後にリクエストを承認できるのは移行先 組織リソースのメンバーのみです。この変更が有効になるまでに最長で 24 時間かかることがあります。それまでは、移行元の組織リソースのメンバーもリクエストを承認できます。

移行元のメンバーがアクセス権を失わないようにするには、移行先組織リソースに新しいユーザーを作成するか、OAuth 同意画面の構成を更新することを検討してください。

  1. OAuth 同意画面の設定を内部設定ではなく外部設定に更新します。

  2. アプリでセンシティブ データを使用する場合は、アプリの確認を機密性の高いスコープまたは制限されたスコープに対して申請します。そうしないと、ユーザーに未確認のアプリの画面が表示されます。

Cloud OS Login API

ソース プロジェクトで Cloud OS Login API が 有効になっている場合は、そのプロジェクトにアクセスできるプリンシパルに roles/compute.osLoginExternalUser ロールを割り当てます。これにより、プリンシパルが移行先の組織リソースでアクセス権を失いません。

仮想マシン（VM）インスタンスの共有予約

共有予約では、予約を作成したプロジェクト（オーナー プロジェクト）または（コンシューマ プロジェクト）で予約を共有するプロジェクトで、VM インスタンスを作成して予約を使用できます。予約を共有できるのは、オーナー プロジェクトと同じ組織内のプロジェクトのみです。

オーナー プロジェクトまたはコンシューマ プロジェクトを移行すると、次のようになります。

  • オーナー プロジェクトを移行すると、そのプロジェクトによって作成された予約は Compute Engine によってすべて削除されます。実行中の VM インスタンスには影響しません。
  • コンシューマ プロジェクトを移行すると、コンシューマ プロジェクトは前の組織の共有予約からのリソースを消費しなくなります。

詳細については、共有予約の仕組みをご覧ください。

サービス アカウントとリソースの関連付け

ほとんどの Cloud de Confiance by S3NS サービスでは、サービス アカウントをリソースに関連付けるには iam.serviceAccounts.actAs 権限が必要です。ただし、一部のサービスでは、明示的ななりすまし権限がなくても、この操作が許可されていました。これについては、 サービス アカウントをリソースに関連付ける権限を要求するで説明しています。

移行元の組織リソースにこの従来の動作があり、移行先にない場合は、これらのサービス アカウントを関連付けるユーザーに roles/iam.serviceAccountUser ロールを付与します。権限の詳細については、 サービス アカウント認証用のロールをご覧ください。

組織リソースに従来の動作があるかどうかを確認するには:

  1. Cloud de Confiance コンソールで、[組織のポリシー] ページに移動します。

    [組織のポリシー] ページに移動

  2. リソース セレクタで、確認する組織リソースを選択します。

  3. フィルタ ボックスに「constraints/appengine.enforceServiceAccountActAsCheck」と入力します。

  4. ポリシーが表示された場合、組織リソースには従来の動作が存在します。

  5. 次の制約ごとに、ステップ 3 と 4 を繰り返します。

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck

これらの制約のいずれかが表示された場合は、組織リソースで従来の動作を使用します。両方の組織リソースで従来の動作を使用している場合は、何も操作する必要はありませんが、意図しないなりすましを回避するため、ポリシーの適用を検討してください。

BigQuery Sharing を使用してプロジェクトを移行する

BigQuery Sharing を使用するプロジェクトを別の組織リソースに移行すると、エラーが発生する可能性があります。解決するには、Cloud カスタマーケアにお問い合わせください。

前の組織のデータ エクスチェンジ リソースが新しい組織の Sharing 管理者ページに表示されない場合は、BigQuery Sharing API を使用してフィールド（description など）を更新し、キャッシュの更新をトリガーします。

projects.locations.dataExchanges.patch メソッドを使用します。

PATCH https://analyticshub.googleapis.com/v1/projects/ \
    PROJECT_ID/locations/LOCATION/ \
    dataExchanges/DATA_EXCHANGE_ID \
    ?update_mask=UPDATE_DX_FIELD \
    -d { UPDATE_DX_FIELD:UPDATE_DX_VALUE }

次のように置き換えます。

  • PROJECT_ID: プロジェクトの一意の識別子
  • LOCATION: データ エクスチェンジのロケーション
  • DATA_EXCHANGE_ID: データ エクスチェンジの ID
  • UPDATE_DX_FIELD: 更新するフィールド（description など）
  • UPDATE_DX_VALUE: 更新された値

Backup and DR サービス

プロジェクトを別の組織リソースに移行する前に、Backup and DR を無効にします。サービスが無効になっている場合は、停止のリスクを考慮してください。 移行が完了したら、Backup and DR を再度有効にします。

Workload Identity 連携

Workload Identity 連携を使用すると、オンプレミスまたはマルチクラウドのワークロードに リソースへのアクセス権を付与できます。 Cloud de Confiance by S3NS Workload Identity 連携プールは、プロジェクト スコープのリソースです。

プロジェクトを移行すると、そのプロジェクト内で構成された Workload Identity プールとそのプロバイダがプロジェクトとともに移行されます。これらのプールを使用するワークロードのアクセス権を維持するために追加の操作は必要ありません。

タグ

タグは、リソースに関連付けられた Key-Value ペアです。組織レベルで作成されたタグは移行されません。

プロジェクトで組織レベルのタグをポリシー バインディングまたは制約に使用している場合は、移行先の組織リソースでタグキーと値を再作成し、移行したプロジェクトに再アタッチする必要があります。

継承された Privileged Access Manager の権限付与を使用してプロジェクトを移行する

プロジェクトを移行する前に、そのプロジェクトに対する有効なスコープ付き権限付与を 取り消すことをおすすめします。 スコープ付き権限付与は、フォルダまたは組織から継承されたエンタイトルメントで作成され、子プロジェクトにスコープ設定されます。

有効なスコープ付き権限付与を含むプロジェクトを移行すると、IAM ポリシーは新しい組織に移動しますが、それを管理する権限付与は前の組織に残ります。Privileged Access Manager サービス エージェントは、新しい組織で IAM ポリシーを変更する権限を失います。その結果、その権限付与に対する取り消しまたは取り下げオペレーションは失敗し、リクエスタは権限付与の有効期限が切れるまでアクセス権を保持します。

次のステップ