プロジェクトの移行

このガイドでは、リソース階層内の組織または場所間でプロジェクトを移行する方法について説明します。

プロジェクト リソースは、Google Cloud 組織での基本レベルの構成エンティティです。プロジェクトは組織の下に作成され、フォルダまたは組織リソース自体の下に配置でき、リソース階層を形成します。組織間では、買収、規制要件、事業部門間の分離などにより、プロジェクトの移行が必要な場合があります。

Resource Manager API を使用して、プロジェクトを組織間で移行したり、現在の組織のリソース階層内の別の場所に移行したりできます。また、Resource Manager API を使用すると、移行をロールバックし、プロジェクトをリソース階層内の元の場所に移行できます。

移行計画の作成

プロジェクトの移行時に考慮すべき最も重要な点は、移行がプロジェクト内で実行されているサービスに与える影響です。Resource Manager API は、プロジェクト リソースとその下位にあるすべてのサービスを単一のユニットとして扱います。つまり、構成変更がプロジェクト内で適用されることはありません。

移行によって直接プロジェクトの構成が変更されることはありませんが、リソース階層の変更はプロジェクトの機能と実行中のサービスに影響する可能性があります。Identity and Access Management や組織のポリシーなどの継承されたポリシーは、移行時にプロジェクトと一緒に移動しません。移動するのは、リソースに直接接続されているポリシーとサービス アカウントのみです。このため、移行の完了後に意図しない動作が発生することがあります。

プロジェクトを移動する前に、移行計画を作成して、組織と移行するプロジェクトの両方で準備状況を判断する必要があります。この移行計画では、プロジェクトで実行されている各サービスや、移行またはプロジェクトの移行先のリソース階層によって影響を受ける可能性のあるその他のサービスのインベントリを利用します。

インベントリの概要

Cloud Asset Inventory を使用して、Identity and Access Management ポリシーなど、使用中のリソースの概要を作成します。この概要は、移行計画の概要を示すのに活用できます。

Cloud Asset Inventory を使用して、このデータを BigQuery に転送することもできます。これにより、SQL を使用してデータをクエリできます。これは、JSON 形式のデータに比べて解釈が容易です。このデータをエクスポートする方法については、BigQuery へのエクスポートをご覧ください。

ポリシーの確認

プロジェクトを移行すると、リソース階層内の現在の場所からポリシーが継承されなくなり、移行先の有効なポリシー評価の対象となります。プロジェクトの移行先の有効なポリシーが、そのプロジェクトの元の場所にあるポリシーとできる限り一致するようにすることをおすすめします。

プロジェクトに直接適用されるポリシーは、移行の完了後も引き続きアタッチされます。移動が完了した時点から適切なポリシーが適用されていることを確認するには、プロジェクトに直接ポリシーを適用するのが最適な方法です。

Identity and Access Management のポリシーと組織のポリシーはリソース階層によって継承され、正しく設定されていない場合はサービスが機能しなくなることがあります。リソース階層のプロジェクトの移行先で有効なポリシーを決定し、ポリシーがガバナンスの目的に適合していることを確認します。

暗号鍵を管理する

プロジェクトで顧客管理の暗号鍵や他の Cloud Key Management Service が有効になっているかどうかを確認する必要があります。暗号鍵はプロジェクトで所有されます。したがって、そのプロジェクトへの owner アクセス権を持つユーザーは、そのプロジェクトの Cloud KMS の鍵の管理と暗号オペレーションを実行できます。

詳細については、職掌分散をご覧ください。

プレビューの機能

組織、フォルダ、プロジェクトでプレビュー機能を有効にできます。プロジェクトのアルファ版またはベータ版の機能を移動できるようにしている場合、移行後もこの機能は引き続き機能します。プレビュー機能が非公開で、移動先の組織の許可リストに含まれていない場合は、移動の完了後に設定を変更できなくなります。

ロールバック プラン

移行したどのプロジェクトでも機能していない何かがあることがわかった場合は、元の場所に戻すことができます。実行するには、必要な IAM 権限を持ち、必要な組織のポリシーを設定する必要があります。そうすることで、プロジェクトの逆への移行を実行できます。

必要な権限のリストについては、権限を割り当てるをご覧ください。プロジェクトの移行を許可するように構成する必要がある組織のポリシーについては、組織のポリシーを構成するをご覧ください。

専用のインポート フォルダとエクスポート フォルダ

ポリシーを継承すると、プロジェクトを移行するときに、移行元と移行先の両方の組織で不測の影響が生じる可能性があります。このリスクを軽減するために、エクスポートとインポート用のプロジェクトのみを保持する特定のフォルダを作成し、両方の組織のフォルダに同じポリシーが継承されるようにします。これらのフォルダ内で移動したプロジェクトに継承される権限をそれらのフォルダで設定すると、プロジェクトの移行プロセスが加速します。

移行を計画する場合は、最初に専用のソースフォルダを設定するようにしてください。これを行うために、プロジェクトをエクスポートする予定の組織ごとにフォルダを作成します。次に、これらのフォルダに組織ポリシーを設定します。各フォルダーには、プロジェクトのエクスポート先の単一の組織に constraints/resourcemanager.allowedExportDestinations 制約が設定されています。

たとえば、Export to Marketing OrgExport to Sales Org のフォルダを設定し、それぞれに適切な組織ポリシー制約を設定できます。

同様に、宛先組織に専用のインポートフォルダを設定し、プロジェクトのインポート元組織にも 1 つ設定します。これを行うために、プロジェクトをインポートする予定の組織ごとにフォルダを作成します。次に、これらのフォルダに組織ポリシーを設定します。各フォルダーには、プロジェクトのインポート元の単一の組織に constraints/resourcemanager.allowedImportSources 制約が設定されています。

たとえば、Import from Marketing OrgImport from App Development Org のフォルダを設定し、それぞれに適切な組織ポリシー制約を設定できます。

それぞれのインポート フォルダとエクスポート フォルダで、プロジェクトを移行するユーザーに roles/resourcemanager.projectMover ロールを割り当てます。このロールは、これらのフォルダ内に含まれるすべてのプロジェクトに継承され、ユーザーはこれらのフォルダに移行されたプロジェクトに対して移行オペレーションを実行できます。

プロジェクトの移行が完了したら、これらの専用フォルダを削除する必要があります。

組織のポリシーの設定については、組織のポリシーの構成をご覧ください。

権限の割り当て

組織間でプロジェクトを移動するには、次の権限が必要です。

これらの権限を取得するには、リソース階層に見合うレベルで示されたロールを付与するように管理者へ依頼してください。

プロジェクト移動の権限

移動するプロジェクト リソースとその親リソースには、プロジェクト移動のロール(roles/resourcemanager.projectMover)、または v1 Resource Manager API に対する次の権限を含む別のロールが必要です。

  • 移動するリソースに対して必要な権限:

    • resourcemanager.projects.update
  • 親リソースに対して必要な権限:

    • resourcemanager.projects.move

移行先のリソースでは、必要となる権限は、プロジェクトを移行するリソースによって異なります。

  • 移行先のリソースがフォルダの場合は、プロジェクト移行のロール(roles/resourcemanager.projectMover)または resourcemanager.projects.move 権限を含む別のロールが必要です。

  • 移行先のリソースが組織である場合は、プロジェクト作成者のロール(roles/resourcemanager.projectCreator)または resourcemanager.projects.create 権限を含む別のロールが必要です。

組織のポリシーの権限

移行元の組織と移行先の組織には roles/orgpolicy.policyAdmin ロールが必要です。このロールには、組織のポリシーを作成し管理する権限が付与されます。

組織のポリシーの構成

プロジェクト リソースを新しい組織に移行するには、まず、プロジェクトの移行先の組織を定義する組織のポリシーを適用します。また、プロジェクトのインポートを許可する組織を定義する組織のポリシーを移行先に設定する必要もあります。

移行するプロジェクトの親リソースで、constraints/resourcemanager.allowedExportDestinations 制約を含む組織のポリシーを設定します。これにより、対象とする移行先が、プロジェクトの移行を受け入れる有効な場所として定義されます。

移行先のリソースで、constraints/resourcemanager.allowedImportSources 制約を含む組織のポリシーを設定します。これにより、移行元は、プロジェクトを移行できる有効な場所として定義されます。

たとえば、プロジェクト my-test-project が ID 12345678901 の組織に存在し、そのプロジェクトをセカンダリ ビジネス ユニットの新しい組織に ID 45678901234 を使用して移行するとします。

その場合、constraints/resourcemanager.allowedExportDestinations 制約を適用して organizations/12345678901 に組織ポリシーを設定し、under:organizations/45678901234allowed_value として設定します。

次に、constraints/resourcemanager.allowedImportSources 制約を適用して organizations/45678901234 に組織ポリシーを設定し、under:organizations/12345678901allowed_value として設定します。

これらの組織のポリシーが適用されると、my-test-projectorganizations/12345678901 から organizations/45678901234 に移動できるようになり、権限の割り当てで説明された権限を持っていると仮定されます。

プロジェクトの請求先アカウントの変更

Cloud Billing アカウントは組織間で使用できます。プロジェクトをある組織から別の組織に移行しても課金に影響はありません。料金は、古い請求先アカウントに対して継続して課せられます。ただし組織を移行すると、新しい請求先アカウントへの移行が必要になる場合もあります。

既存のプロジェクトの請求先アカウントを変更するには、プロジェクトにおける roles/owner のロールと、変更後の請求先アカウントにおける roles/billing.admin のロールが必要です。請求先アカウントを変更するには:

  1. Cloud Console の [お支払い] ページに移動します。
    [お支払い] ページに移動
  2. 変更する請求先アカウントの名前をクリックします。
  3. [この請求先アカウントにリンクされているプロジェクト] で、移行するプロジェクトの名前を見つけて、右側のメニューボタンをクリックします。
  4. [お支払い情報の変更] をクリックして、新しい請求先アカウントを選択します。
  5. [アカウントを設定] をクリックします。

トランザクション履歴でまだ報告されていない料金がすでに発生している場合は、変更前の請求先アカウントに請求されます。これには、最大でプロジェクトを移行する 2 日前までの料金が含まれます。

請求先アカウントを組織間で移行する

請求先アカウントをある組織から別の組織へ移行できますが、これは必ずしも必要な手順ではありません。ほとんどの既存組織はすでに請求先アカウントを持っているので、それらを代わりに使用することをおすすめします。既存の請求先アカウントを移行する必要がある場合は、次の手順を実施します。

  1. 移行元と移行先の組織の roles/billing.admin ロールを取得します。
  2. Cloud Console の [お支払い] ページに移動します。
    [お支払い] ページに移動
  3. 移行させる請求先アカウントの名前をクリックします。
  4. [アカウント管理] ページの上部にある [組織を変更] をクリックします。
  5. 移行先組織を選択して、[OK] をクリックします。

これで、請求先アカウントは指定した組織に関連付けられました。

移行を実行する

適切な IAM 権限があり、必須の組織のポリシーが適用されている場合、Resource Manager API を使用してプロジェクト リソースを移動できます。

gcloud

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

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

次のコマンドで、対象リソースとしてフォルダを指定することもできます。

gcloud beta projects move PROJECT_ID \
    --folder FOLDER_ID

ここで

  • PROJECT_ID は、移行するプロジェクトの ID または番号です。
  • ORGANIZATION_ID は、プロジェクトの移行先となる組織の ID です。1 つの組織またはフォルダのどちらか 1 つの対象のみを指定できます。
  • FOLDER_ID は、プロジェクトの移行先フォルダの ID です。1 つのフォルダまたは組織のどちらか 1 つの対象のみを指定できます。

API

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

プロジェクトの移行手順

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

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

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

    project = crm.projects().update(
    projectId=flags.projectId, body=project).execute()

移行のロールバック

プロジェクトを誤って移行した場合は、古いソースを新しい移行先、元の移行先を新しいソースとしてもう一度移行を実行することで、そのオペレーションをロールバックできます。実行するには、これがまったく新しい移行であるかのように、必要な IAM 権限と組織のポリシーが適用されている必要があります。

特殊なケースの処理

組織なしのプロジェクトの移行

組織に関連付けられていないプロジェクトでも、組織に移行することは可能です。ただし、このプロセスを使用して [組織なし] に戻すことはできません。組織に関連付けられたプロジェクトがあり、[組織なし] に戻す場合は、サポート担当者にお問い合わせください。

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

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

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

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

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

その後で、移行を実施できます。

コンソール

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

  1. Cloud Console で [IAM と管理] > [設定]ページを開きます。

    [設定] ページを開く

  2. ページの上部にあるプロジェクト選択ツールを選択します。

  3. 組織選択ツールから、[組織なし] を選択します。組織に関連付けられていない場合は、組織選択ツールは表示されないため、この手順は省略できます。

  4. 移行するプロジェクトを選択します。

    プロジェクト選択ツールのスクリーンショット

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

  6. [組織] プルダウン リストで、プロジェクトの移行先となる組織を選択します。

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 に設定します。
  • projects.update() メソッドを使用して、project オブジェクトを更新します。

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

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

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

共有 VPC

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

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

ホスト プロジェクトを移行しても、移行元の組織に戻すことはできますが、サービス プロジェクトの移行を開始したら、ホスト プロジェクトが再び移行できるようになる前に、すべてのプロジェクトを移行する必要があります。

Identity and Access Management のカスタムロール

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

組織レベルですべてのカスタム IAM ロールを一覧表示するには、次の gcloud コマンドライン ツールのコマンドを実行します。

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_ID は、ロールを一覧表示する組織 ID です。組織 ID を検出する方法については、組織の作成と管理をご覧ください。

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

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

ここで

  • ORGANIZATION_ID はロールの親組織の組織 ID です。

  • ROLE_ID は、説明するロールの名前です。

前提条件でのエラーによる失敗を回避するには、プロジェクトが継承する組織レベルのカスタムロールごとに、同等のプロジェクト レベルのカスタムロールを作成する必要があります。次に、組織レベルのカスタムロールを参照する IAM ロール バインディングを削除します。

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

カスタムロールの詳細については、カスタムロールの作成と管理をご覧ください。

バケットロック

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

保持ポリシーとリーエンは移行中もプロジェクトに保持されますが、バケットロックが適用されているプロジェクトを移行する場合は、誤って移行しないように注意してください。

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

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

セキュリティ境界からプロジェクトを削除するには、サービス境界の管理をご覧ください。VPC Service Controls の境界内のプロジェクトは、境界の作成または更新後、最長で 1 日間は組織間での移動がブロックされないようにする必要があります。プロジェクトがサービス境界から削除されてから移行可能になるまでに数時間かかることがあります。

Dedicated Interconnect

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

Dedicated Interconnect オブジェクトに接続されている、または Dedicated Interconnect オブジェクトへの VLAN アタッチメントがある、特定の組織のプロジェクトに加えられた構成変更は、他の組織に反映されない場合があるため、可能であれば、そのようなプロジェクトを組織間で長期にわたり分割したままにしないことをお勧めします。

Partner Interconnect

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

Assured Workloads

Assured Workloads プロジェクトを組織間で移行することはできません。移行しようにすると、プログラムによってブロックされます。

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

プロジェクト間のサービス アカウントが付加されているプロジェクトを移行する場合、そのサービス アカウントは移行先の組織でも引き続き機能します。そのプロジェクトのドメインを制限する組織ポリシーがある場合でも、そのプロジェクトは、不可されたサービス アカウントを使って引き続き動作します。

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

たとえば、organizations/12345678901project-A があるとします。このプロジェクトには serviceAccount-1 が接続されており、プロジェクト間サービス アカウントとして設定されています。project-Bproject-Corganizations/12345678901 にあるため、同様に serviceAccount-1 を使用します。

ドメイン制限の制約を含む組織のポリシーを project-C に適用したため、organizations/12345678901. のドメインのみにアクセスが許可されます。

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

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

サポート記録

未解決のサポート記録があるプロジェクトを移行する場合は、Google サポートに連絡して、移行が発生したことを通知する必要があります。Google で未解決のサポート記録があるプロジェクトでは、Google サポートがケース メタデータを新しい組織を指すように更新するまで、そのサポート記録は表示されません。

内部 OAuth 同意画面を使用するようにプロジェクトを構成し、画面を別の組織に移行した場合は、移管先組織のメンバーのみがリクエストを承認できます。この動作が有効になるまでに、最大で 24 時間を要する場合があります。それまでは、移行元の組織のメンバーがリクエストを承認できます。

以下の手順では、移行元組織のメンバーが移行中にアクセス権を失うことがないようにする方法を説明します。OAuth 同意画面の構成を変更する必要がないよう、組織メンバーの移行先の組織に新しいユーザーを作成することを検討してください。

移行元組織内のユーザーがアクセス権を失うことを回避するには:

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

  2. 内部としてマーク付けされ、機密データを使用しているアプリは、アプリの確認を申請する必要はありません。アプリが機密データを使用している場合、同意画面が外部に更新されると、移行元組織のユーザーには、認証画面の前に未確認アプリ画面が表示されます。これを回避するには、機密性の高いスコープまたは制限されたスコープの使用に対してアプリの確認を申請します。

OS ログイン

ソース プロジェクトで OS Login が有効になっている場合は、ソース プロジェクトのメンバーがアクセス権を失わないよう、移行先組織で roles/compute.osLoginExternalUser IAM ロールを割り当てます。

サービス アカウントをリソースに関連付ける

ほとんどの Google Cloud サービスでは、サービス アカウントをリソースに関連付けるには、ユーザーにサービス アカウントに対する iam.serviceAccounts.actAs 権限が必要です。ただし、これまで特定のサービスのオンボーディングを簡易にする目的で、ユーザーがサービス アカウントになりすます権限を付与されていない場合でも、ユーザーがサービス アカウントをリソースに関連付けることを許可していました。この点についてはこちらのドキュメントを参照してください。

お客様の移行元組織に従来の動作があり(通常のロール付与がない場合に、サービス アカウント アタッチメントが可能)、移行先の組織にそれらの動作がない場合は、これらのサービス アカウントをリソースに関連付けるユーザーに roles/iam.serviceAccountUser を付与します。サービス アカウントへのなりすましについては、サービス アカウントへのなりすましをご覧ください。

組織で従来の挙動があるかどうかを確認するには、次のとおりにします。

  1. Cloud Console で、[組織のポリシー] ページに移動します。

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

  2. ページの上部にあるプロジェクト セレクタから、以前の状態であるかを確認する組織を選択します。

  3. 組織のポリシーリストの上部にあるフィルタ ボックスに、「constraints/appengine.enforceServiceAccountActAsCheck」と入力します。

  4. appengine.enforceServiceAccountActAsCheck 組織ポリシーがリストに表示されている場合、組織には以前の動作が存在します。

  5. 次の組織のポリシー c の制約ごとに、ステップ 3 と 4 を繰り返します。

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. これらの組織ポリシーの制約のいずれかが表示された場合は、組織でレガシー動作を使用します。

移行元の組織に以前の動作があり、移行先に同じ動作がない場合は、上に記載したロールを付与します。移行元と移行先の組織にすでに従来の動作がある場合は、何も操作する必要はありませんが、意図しないなりすましを回避するため、ポリシーの適用を検討してください。