翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AMS マルチアカウントランディングゾーンアカウントからのオフボード AMS Advanced マルチアカウントランディングゾーンからオフボード AWS できるアカウントには、次の 2 つのタイプがあります。 + アプリケーションアカウント + コアアカウント AMS マルチアカウントランディングゾーンからすべてのアカウントをオフボードするには、コアアカウントをオフボードする前に、すべてのアプリケーションアカウントをオフボードする必要があります。 オフボードのアプリケーションアカウントまたは Core アカウントでワークロードを引き継ぎ、引き続き運用するには、AMS アカウントチームでこのドキュメントを確認してください。このドキュメントでは、オフボードプロセス中に AMS が実行する変更の概要を説明します。 ## オフボーディングされたアカウントの継続的な運用のために完了するタスク AMS マルチアカウントランディングゾーンからオフボードしたアカウントの継続的なオペレーションには、次のタスクが必要です。 + **デベロッパーモードを有効にする:** アカウントに対するアクセス許可をさらに取得するには、アプリケーションアカウントを AMS からオフボードする前に、デベロッパーモードをオンにします。デベロッパーモードを有効にすると、オフボーディングの準備に必要な変更をより簡単に行うことができます。AMS インフラストラクチャリソースを削除または変更しようとしないでください。AMS インフラストラクチャリソースを削除すると、AMS はアカウントを正常にオフボードできない可能性があります。デベロッパーモードを有効にする方法については、「」を参照してください[AMS Advanced Developer モードの開始方法](developer-mode-implement.md)。 デベロッパーモードを有効にした後、オフボーディングの準備に必要な変更を完了できない場合は、AMS アカウントチームに連絡して要件について話し合ってください。 + **EC2 スタックアクセスの代替方法を選択:** AMS からアプリケーションアカウントをオフボードした後、RFCs を使用してスタックリソースにアクセスすることはできません。を確認してから[オフボーディングの変更](#offboarding-malz-offboarding-changes)、スタックへのアクセスを保持する代替アクセス方法を選択します。詳細については、「[代替手段にアクセスする](#offboarding-malz-access-alternatives)」を参照してください。 ## AMS アプリケーションアカウントのオフボード マルチアカウントランディングゾーン環境からアプリケーションアカウントをオフボードするには、アカウントごとに次の手順を実行します。 1. アカウントに開いている RFCs がないことを確認します。詳細については、「[RFCs の作成、クローン作成、更新、検索、キャンセル](ex-rfc-use-examples.md)」を参照してください。 1. アカウントのプライマリまたはルートユーザーの E メールアドレスにアクセスできることを確認します。 1. アプリケーションアカウントから、[アプリケーションアカウント \$1 オフボーディング](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-application-account-confirm-offboarding.html)の確認 (ct-2wlfo2jxj2rkj) 変更タイプを使用して RFC を送信します。RFC で、オフボードするアプリケーションアカウントを指定します。 1. 管理アカウントから、[管理アカウント \$1 オフボードアプリケーションアカウント](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-management-account-offboard-application-account.html) (ct-0vdiy51oyrhhm) の変更タイプを使用して RFC を送信します。RFC で、オフボードするアプリケーションアカウントを指定します。また、ランディングゾーンへの Transit Gateway アタッチメントを削除または保持するかどうかを指定します。 1. AMS 請求が停止されていることを確認するには、アカウントをオフボードしたことを CSDM に通知します。 アプリケーションアカウントがオフボードされた後、以下が発生します。 + すべてのコンポーネントは AMS サービスとの関連付けが解除されますが、作成したリソースはアカウントに残ります。AMS オフボードアカウントを保持または閉鎖することを選択できます。 + コアアカウントおよびその他の残りのアプリケーションアカウントは通常、アプリケーションアカウントがオフボードされた後に機能します。 + AMS 請求は停止されますが、アカウントを閉鎖するまで AWS 請求は停止されません。詳細については、[「アカウントを閉鎖する前に知っておくべきこと](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#close-account-considerations)」を参照してください。 + アカウントが閉鎖されている場合、アカウントは `suspended`状態で 90 日間組織に表示されます。90 日後、閉鎖されたアカウントは完全に削除され、組織に表示されなくなります。 + アカウントが閉鎖された後も、90 サポート 日間サインインしてサポートケースまたは連絡先を提出できます。 + 90 日後、アカウント内に残っているコンテンツはすべて完全に削除され、残りの AWS サービスは終了します。 ### アプリケーションアカウントのオフボーディングに関するよくある質問 **Q: フェデレーティッド IAM ロールを使用して、AMS マルチアカウントランディングゾーンからオフボードしたアプリケーションアカウントに引き続きアクセスできますか?** はい。AMS が作成した[デフォルト AWS Identity and Access Management (IAM) ロール](defaults-user-role.md)は、AMS オフボーディング後もアカウントで引き続き使用できます。ただし、これらのロールとポリシーは、AMS アクセス管理で使用するように設計されています。ユーザーに必要なアクセスを提供するには、独自の IAM リソースをデプロイする必要がある場合があります。 **Q: AMS マルチアカウントランディングゾーンからオフボードしたアプリケーションアカウントへのフルアクセスを取得するにはどうすればよいですか?** オフボーディングされたアプリケーションアカウントは、 AWS Organizations アカウント構造の**非推奨**組織単位 (OU) に移動されます。この移動により、以前にルートユーザーアクセスをブロックした SCP アクセス制限が解除されます。ルートユーザーの認証情報をリセットする方法については、[「紛失または忘れたルートユーザーのパスワードのリセット](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html)」を参照してください。 **Q: アプリケーションアカウントのオフボーディング中にどのような変更が行われますか?** サービスがアカウントをオフボードするときに AMS が実行するアクションの詳細については、「」を参照してください[オフボーディングの変更](#offboarding-malz-offboarding-changes)。 **Q: トランジットゲートウェイからデタッチせずにアプリケーションアカウントをオフボードできますか?** はい。[ 管理アカウント \$1 オフボードアプリケーションアカウント](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-management-account-offboard-application-account.html) (ct-0vdiy51oyrhhm) 変更タイプを使用して RFC を送信し、 `DeleteTransitGatewayAttachment`パラメータを として指定します`False`。 **Q: アプリケーションアカウントのオフボードにはどのくらいの時間がかかりますか?** [ 管理アカウント \$1 オフボードアプリケーションアカウント](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-management-account-offboard-application-account.html) (ct-0vdiy51oyrhhm) の変更タイプを使用すると、RFCs 1 時間以内に完了します。 **Q: オフボードされたアカウントを閉じることは必須ですか?** いいえ。AMS オフボーディング後のアカウント閉鎖は必須ではありません。オフボーディングプロセス中、AMS は AWS アカウントのアクセスと管理を削除しますが、アカウントとアカウント内のリソースは残ります。AMS オフボーディング後、 AWS アカウントとリソースの管理と保守はお客様の責任となります。AMS は、オフボーディングプロセスの完了後にアカウントで発生する可能性のある問題、インシデント、またはサービスの中断について責任を負いません。詳細については、[AWS 「アカウントを閉じるにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/close-aws-account/)」を参照してください。 **Q: アカウント閉鎖リクエストを送信すると、既存のリソースはすべてすぐに削除されますか?** いいえ。アカウントを閉鎖してもリソースは終了しません。アカウントのリソースは、閉鎖リクエストから 90 日後に自動的に終了します。AMS 請求は停止しますが、 AWS リソース請求はアカウントを閉鎖するまで停止しません。詳細については、[「アカウントを閉鎖する前に知っておくべきこと](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#close-account-considerations)」を参照してください。 **Q: アプリケーションアカウントのオフボーディングをスケジュールできますか?** はい。RFCs を特定の時間に実行するようにスケジュールできます。ただし、管理[アカウント \$1 オフボードアプリケーション](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-application-account-confirm-offboarding.html)アカウント RFC を[スケジュールする前に、アプリケーションアカウント \$1 オフボード](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-management-account-offboard-application-account.html) RFC を確認する必要があります。詳細については、[「RFC スケジューリング](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-scheduling.html)」を参照してください。 ### RACI のアプリケーションアカウントのオフボーディング + **R**: 責任者。リストされたタスクの完了を担当する当事者。 + **A**: 責任を負う当事者。完了したタスクを承認する当事者。 + **C**: 相談先。通常、対象分野の専門家として意見を求められ、双方向のコミュニケーションがある当事者。 + **I**: 情報提供者。多くの場合、タスクまたは成果物の完了時にのみ、進捗状況について通知される当事者。 | アクティビティ | お客様 | AWS Managed Services (AMS) | | --- | --- | --- | | 前提条件 | | | | オフボードされる各 AWS アカウント ID のルート E メールアドレスへのアクセスを検証する | R | C | | 推奨される顧客アクションに関する AMS ドキュメントを確認し、AMS オフボーディング用のアカウントを準備する | R | C | | 必要に応じて、RFC を送信してデベロッパーモードを有効にし、AMS オフボーディング用のアカウントを準備します。 | R | I | | 必要に応じて、EC2 スタックアクセスの代替方法を選択します。 | R | I | | オフボーディング | | | | RFCs を送信してアプリケーションアカウントのオフボーディングを確認してリクエストする | R | I | | アプリケーションアカウントから AMS コンポーネントをオフボードする | I | R | | オフボーディングされたアカウントを AMS CSDM に通知して AMS 請求を停止する | R | I | | オフボード後 | | | | ルートユーザーアカウントのパスワードをリセットし、オフボードアカウントのルートアクセスを検証する | R | C | | アカウントを閉鎖するか、AMS オフボーディングドキュメントの推奨顧客アクションに関する AMS ガイダンスに従って、アカウントの運用を継続します。 | R | C | ## オフボードコアアカウント マルチアカウントランディングゾーン Core アカウントをオフボードするには、次の手順を実行します。 1. ランディングゾーン内のすべてのアプリケーションアカウントが AMS からオフボードされていることを確認します。 1. アカウントに開いている RFCs がないことを確認します。詳細については、「[RFCs の作成、クローン作成、更新、検索、キャンセル](ex-rfc-use-examples.md)」を参照してください。 1. すべての Core アカウントのプライマリまたはルートユーザーの E メールアドレスにアクセスできることを確認します。詳細については、「[マルチアカウントランディングゾーンアカウント](malz-net-arch-accounts.md)」を参照してください。 1. 管理アカウントのプライマリまたはルートユーザーの電話番号にアクセスできることを確認します。IAM `AWSManagedServicesBillingRole` ロールを使用して電話番号を更新します。詳細については、[「アカウントに関連付けられている電話番号を更新するにはどうすればよいですか? AWS](https://repost.aws/knowledge-center/update-phone-number)」を参照してください。 1. AMS ランディングゾーン管理アカウントにログインし、AMS サービスリクエストを送信します。サービスリクエストで、 を指定してランディングゾーン全体をオフボードします。 Core アカウントがオフボードされた後、以下が発生します。 + すべてのコンポーネントは AMS サービスとの関連付けが解除されますが、一部の AWS リソースはアカウントに残ります。AMS オフボード Core アカウントを保持または閉鎖することを選択できます。 + AMS 請求は停止されますが、アカウントを閉鎖するまで AWS 請求は停止されません。詳細については、[「アカウントを閉鎖する前に知っておくべきこと](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#close-account-considerations)」を参照してください。 + アカウントが閉鎖されている場合、アカウントは `suspended`状態で 90 日間組織に表示されます。90 日後、閉鎖されたメンバーアカウントは完全に削除され、組織に表示されなくなります。 + アカウントが閉鎖された後も、90 サポート 日間サインインしてサポートケースまたは連絡先を提出できます。 + アカウントが 90 日間閉鎖されると、アカウントに残っているコンテンツはすべて完全に削除され、残りの AWS サービスは終了します。 ### コアアカウントのオフボーディングに関するよくある質問 **Q: フェデレーティッド IAM ロールを使用して、オフボードされた Core アカウントに引き続きアクセスできますか?** はい。AMS が作成した[デフォルト AWS Identity and Access Management (IAM) ロール](defaults-user-role.md)は、オフボードされたアカウントで引き続き使用できます。ただし、これらのロールとポリシーは AMS アクセス管理で使用するように設計されています。ユーザーに必要なアクセスを提供するには、独自の IAM リソースをデプロイする必要がある場合があります。 **Q: AMS マルチアカウントランディングゾーンからオフボーディングした後、管理、共有サービス、ネットワーク、またはその他のアプリケーション[以外の MALZ](malz-net-arch-accounts.md) アカウントへのフルアクセスを取得するにはどうすればよいですか?** オフボーディング後、[「紛失または忘れたルートユーザーパスワードのリセット](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html)」の手順に従って、プライマリ (ルート) ユーザー認証情報を使用して管理アカウント以外の Core アカウントにアクセスします。他のアカウントタイプとは異なり、管理アカウントは、ルートユーザーに関連付けられているアクセスできない多要素認証 (MFA) デバイスを保持して、使用を防止します。ルートアクセスを回復するには、[失われた MFA デバイス復旧プロセス](https://aws.amazon.com/blogs/security/reset-your-aws-root-accounts-lost-mfa-device-faster-by-using-the-aws-management-console/)に従う必要があります。 **Q: Core アカウントのオフボーディング中にどのような変更が行われますか?** サービスがアカウントをオフボードするときに AMS が実行するアクションの詳細については、「」を参照してください[オフボーディングの変更](#offboarding-malz-offboarding-changes)。 **Q: Core アカウントのオフボーディングが完了するまでにどれくらいかかりますか?** Core アカウントのオフボーディングプロセスは通常、完了までに最大 30 日かかります。ただし、必要なすべてのステップが正しく完了していることを確認するには、オフボーディング開始の少なくとも 7 日前にオフボーディングリクエストを開始する必要があります。移行を容易にするには、事前に計画し、オフボーディングリクエストを事前に送信してください。 **Q: AMS オフボーディング後に共有コンポーネントを管理するにはどうすればよいですか?** AMS Managed Active Directory およびその他の共有サービスインフラストラクチャコンポーネントは、AMS オペレーターアクセス用に設計されています。これらのコンポーネントへのフルアクセスを保持するには、Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループ、 AWS Organizations サービスコントロールポリシー (SCP) の更新、またはその他の変更が必要になる場合があります。 **Q: オフボーディングされた Core アカウントを閉鎖できますか?** デフォルトでは、アプリケーションアカウントには、 AWS Organizations メンバーシップ、トランジットゲートウェイネットワーク接続、AMS Managed Active Directory 経由の DNS 解決など、MALZ Core アカウントへの複数の依存関係があります。これらの依存関係を解決したら、オフボードされた Core アカウントを廃止して閉鎖できます。詳細については、「[マルチアカウントランディングゾーンアカウント](malz-net-arch-accounts.md)」を参照してください。 ### コアアカウントオフボーディング RACI + **R**: 責任者。リストされたタスクの完了を担当する当事者。 + **A**: 責任を負う当事者。完了したタスクを承認する当事者。 + **C**: 相談者。通常、対象分野の専門家として意見を求められ、双方向のコミュニケーションがある当事者。 + **I**: 情報提供者。多くの場合、タスクまたは成果物の完了時にのみ、進捗状況について通知される当事者。 | アクティビティ | お客様 | AWS Managed Services (AMS) | | --- | --- | --- | | 前提条件 | | | | オフボードされる各 AWS アカウント ID のルート E メールアドレスへのアクセスを検証する | R | C | | 管理アカウントのルートユーザーの電話番号へのアクセスを確認し、更新する | R | C | | 推奨される顧客アクションに関する AMS ドキュメントを確認し、AMS オフボーディング用のアカウントを準備する | R | C | | オフボーディング | | | | ランディングゾーンのオフボーディングをリクエストするサービスリクエストを送信する | R | I | | Core アカウントから AMS コンポーネントをオフボードする | I | R | | オフボード後 | | | | ルートユーザーアカウントのパスワードをリセットし、オフボードアカウントのルートアクセスを検証する | R | C | | アカウントを閉鎖するか、AMS オフボーディングドキュメントの推奨顧客アクションに関する AMS ガイダンスに従って、アカウントの運用を継続します。 | R | C | ## オフボーディングの変更 次の表は、マルチアカウントランディングゾーンのオフボーディング、潜在的な影響、推奨されるアクションに対して AMS が実行するアクションを示しています。 | コンポーネント | アカウントの種類 | オフボードのために実行されたアクション | 潜在的な影響 | 推奨される顧客アクション | | --- | --- | --- | --- | --- | | アクセス管理 | アプリケーションアカウント | オフボーディング後、just-in-timeの時間制限付きアクセス用のスタックアクセス RFCs を送信して、AMS 踏み台ホストを介して EC2 スタックにアクセスできなくなります。 AMS は、既存の EC2 リソーススタック (PBIS Open エージェント、ドメイン結合スクリプト) のアクセス関連コンポーネントを管理しなくなりました。 | RFS 経由で AMS 踏み台を使用して EC2 インスタンスにアクセスできない AMS 提供以外の AMIs から起動された EC2 インスタンスが Managed Active Directory ドメインに参加していない 削除しない場合、既存のリソーススタックの AMS 起動スクリプトは、AMS 依存関係がないためエラーを生成し、別のドメインへの再参加を防ぐ可能性があります。 | 代替方法を使用して EC2 インスタンスにアクセスする (「」を参照[代替手段にアクセスする](#offboarding-malz-access-alternatives)) 既存の EC2 リソーススタックから AMS 起動スクリプトを削除する (「」を参照[AMS EC2 起動スクリプトを無効にする](#offboarding-malz-disable-ec2-launch-scripts)) | | アクセス管理 (続き) | コアアカウント | PBIS Open から PBIS Enterprise (AD Bridge) に移行した場合、AMS はコアアカウントのオフボーディング後にライセンスを更新しなくなります。 | PBIS Enterprise ライセンスの有効期限が切れることが許可されている場合、Active Directory 認証情報は既存の Linux ベースの EC2 インスタンススタックでは無効です。 | PBIS Enterprise (AD Bridge) に移行した場合は、ライセンスを維持するか廃止するかを決定します (「」を参照[PBIS Open/Enterprise (AD Bridge)](#offboarding-malz-pbis-open-enterprise))。 | | ログ記録、モニタリング、インシデント/イベント管理 | アプリケーションアカウントとコアアカウント | デプロイする AMS コンポーネント[AMS でのベースラインモニタリングからのアラート](monitoring-default-metrics.md)が削除されます デプロイ済みの既存の Amazon CloudWatch アラームは残りますが、AMS インシデントは作成されなくなります AWS Config AMS と MALZ Core セキュリティアカウントからの集約認可が削除される AWS Config ルールはデプロイされたままで、Amazon GuardDuty は有効のままですが、AMS インシデントは作成されなくなります | 新しく作成されたリソースには、AMS ベースラインモニタリングとアラームが適用されていません インフラストラクチャメトリクスアラームとセキュリティイベントが AMS インシデントを生成しなくなった AWS Config は中央アカウントに集約されなくなりました | オペレーションメトリクスを定義、キャプチャ、分析してワークロードイベントを表示し、適切なアクションを実行します。 必要なアラートワークフローを実装して、必要な運用モニタリングとアラームを新しいリソースに引き続き適用し、 AWS Config と Amazon GuardDuty からセキュリティアラートを受信できるようにします。 | | 継続性管理 (バックアップと復元) | アプリケーションアカウント | AMS はバックアップジョブをモニタリングしたり、バックアップおよび復元リクエストを実行したりしなくなりました AMS のデフォルトのバックアップボールト、バックアップ暗号化キー、バックアップロールは残ります | バックアップオペレーションの失敗に気付かない場合があります | バックアッププラン設定のモニタリングとレビュー | | パッチ管理 | アプリケーションアカウントとコアアカウント | AMS は、パッチ適用オペレーションが正常に実行されるかどうかをモニタリングしたり、手動パッチ適用を実行したりしなくなりました。 AMS は AMS インフラストラクチャコンポーネントを更新しなくなりました AMS が提供するパッチベースラインは保持されます AMS が提供する AWS Systems Manager パッチオートメーションランブックは共有解除され、使用できなくなります | パッチ適用オペレーションの失敗に気付かない場合があります AMS が提供する Systems Manager Automation ランブックに依存する既存のパッチ設定は、中断されないように再設定する必要があります | 必要に応じてパッチ適用設定を確認して再設定する | | ネットワーク管理 | アプリケーションアカウント | 指定した場合、オフボーディングされたアプリケーションアカウントの Transit Gateway アタッチメントは削除されます。 | オフボードアプリケーションアカウントは、Transit Gateway を使用して Managed Active Directory や他のアプリケーションアカウントなどの共有サービスにアクセスできなくなります。 | トランジットゲートウェイ接続を保持するFalseには、 DeleteTransitGatewayAttachmentとして を指定します。 | | セキュリティ管理 | アプリケーションアカウント | アカウントは中央の Trend Micro DSM コンソールからデタッチされます。また、エンドポイントエージェントは AMS インシデントプロセスを通じてアラートを転送しなくなりました Trend Micro エージェントはインストールされたままですが、AMS によって管理または更新されなくなります。 Trend Micro エージェントをデプロイする AMS が提供する AMI のカスタマイズは、AMS によって維持または更新されなくなりました。 | EC2 インスタンスエンドポイントのマルウェア検出に気付かない可能性がある Trend micro エージェントは、AMS 提供以外の AMIs から起動された EC2 インスタンスにデプロイされません | Trend Micro を続行または中止するためのオプションを検討する (「」を参照[Trend Micro Deep Security](#offboarding-malz-trend-micro-deep-sec)) | | セキュリティ管理 (続き) | コアアカウント | Trend Micro DSM インフラストラクチャは共有サービスアカウント内に残りますが、AMS によって維持または更新されなくなりました Trend Micro DSM は AMS インシデントプロセスを通じてアラートを転送しなくなりました | EC2 インスタンスエンドポイントのマルウェア検出に気付かないことがある インフラストラクチャが維持されていない場合、EC2 インスタンスエンドポイントの保護に影響する可能性があります (定義の更新、ライセンスなど) | Trend Micro を継続するか中止するかを決定する (「」を参照[Trend Micro Deep Security](#offboarding-malz-trend-micro-deep-sec)) | | 変更管理 | アプリケーションアカウントとコアアカウント | AMS RFC コンソールと API が削除されました アカウントレベルのアクセス制限を含む AMS カスタムサービスコントロールポリシー (SCPs) は、アプリケーションアカウントのオフボーディング中にデタッチされ、コアアカウントのオフボーディング中に削除されます。 | 新しいリソースの作成、既存のリソースの変更、または既存の CloudFormation スタックの更新には、ネイティブ AWS API を使用する必要があります。 アクセス制限は、AMS が提供する SCPs。 | ユーザーロールが AWS サービスを使用するのに十分なアクセス権限を付与していることを確認します。 SCPs を作成してアカウントレベルのアクセス許可制限を提供する | | サービス管理用の AMS OS イメージとオートメーション | アプリケーションアカウントとコアアカウント | AMS は、AMS が提供する EC2 AMIs AMS が提供する EC2 AMIs、オフボーディングされたアカウントで引き続き使用できます。 AMS が提供する Systems Manager Automation ランブックは共有解除され、使用できなくなります | オフボーディング後、AMS コンポーネントへの依存関係がないため、AMS は cfn-signal CloudFormation の送信で起動`FAILURE`された AMIs を提供しました AMS が提供する Systems Manager Automation ランブックに依存する運用プロセスが失敗する可能性があります | AMS が提供する AMIs または Systems Manager Automation ランブックに依存するビルドまたは運用プロセスを確認して更新する | | 共有サービスインフラストラクチャ | コアアカウント | AMS アクセスは削除され、AMS は AMS Managed Active Directory などの共有コンポーネントを管理しなくなります AWS Transit Gateway。 AWS Organizations | 共有インフラストラクチャに対する管理の喪失 | AMS Managed Active Directory への管理者アクセスをリセットし、共有サービスコンポーネントの管理を引き受ける | | 報告 | アプリケーションアカウントとコアアカウント | AMS は、集計レポートのアカウントレベルまたはリソースレベルの詳細を収集しなくなりました | 運用メトリクスとビジネスメトリクス (バックアップとパッチの適用、変更管理、インシデントアクティビティ) に関するインサイトの喪失 | アカウント間で必要な集計データレポートを独自のソリューションに置き換える | | AMS アカウントチームとサービスデスク | アプリケーションアカウントとコアアカウント | AMS アカウントチーム (CSDM、CA) と AMS オペレーションサービスデスクがオフボードアカウントをサポートしなくなりました | AMS 設計のマルチアカウントランディングゾーンアーキテクチャと関連コンポーネントの専門知識による運用サポートの喪失 | 環境内のオペレーションをサポートするのに十分な人員と、アカウント構造とリソースに精通していることを確認します。 | ## 代替手段にアクセスする AMS アカウントをオフボードした後、EC2 スタックへのアクセスを保持するための代替方法は次のとおりです。 + **Session Manager **を使用して、踏み台やインバウンドネットワークアクセスを必要とせずに、昇格されたアクセス許可を持つ EC2 インスタンスにアクセスします。詳細については、「[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)」を参照してください。 + 新しい**ドメイン認証情報を使用して、EC2 インスタンスを別の Active Directory ドメインに再結合**します。を使用する場合は Directory Service、[EC2 インスタンスを AWS Managed Microsoft AD ディレクトリに結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_join_instance.html)」を参照してください。 + 他のいずれかのアクセス方法または [AWS Systems Manager Run Command ](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)を使用して作成した**ローカルユーザーアカウント**を使用します。 ## AMS EC2 起動スクリプトを無効にする ### Linux オペレーティングシステム: ディストリビューションのパッケージマネージャーを使用して、`ams-modules`パッケージをアンインストールします。例えば、Amazon Linux 2 の場合は を使用します`yum remove ams-modules`。 ### Windows オペレーティングシステム Windows で EC2 起動スクリプトを無効にするには、次の手順を実行します。 1. Windows Server 2008/2012/2012r2/2016/2019: マネージドサービス起動のスケジュールされたタスクをタスクスケジューラから無効化または削除します。スケジュールされたタスクを一覧表示するには、 `Get-ScheduledTask -TaskName '*Ec2*'` コマンドを実行します。 Windows Server 2022: [EC2Launch v2 タスク](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2launch-v2-settings.html#ec2launch-v2-schema-agent-config)を削除します。このタスクは`Initialize-AMSBoot`、インスタンスの C:\$1ProgramData\$1Amazon\$1EC2Launch\$1config\$1agent-config.yml の`postReady`ステージで実行されます。以下は、 の例のスニペットです`agent-config.yml`。 ``` { "task": "executeScript", "inputs": [ { "frequency": "always", "type": "powershell", "runAs": "localSystem" } ] } ``` 1. (オプション) 次のファイルコンテンツを削除します。 ``` C:\Program Files\WindowsPowerShell\Modules\AWSManagedServices.* C:\Windows\System32\WindowsPowerShell\v1.0\Modules\AWSManagedServices.Build.Utilities\* ``` ## PBIS Open/Enterprise (AD Bridge) PBIS Open または PBIS Enterprise (AD Bridge) エディションを使用しているかどうかを確認するには、Linux EC2 マネージドインスタンスで次のコマンドを実行します。 ``` yum info | grep pbis ``` PBIS Enterprise (AD Bridge) を示す出力例を次に示します。 ``` Name : pbis-enterprise From repo : pbise Name : pbis-enterprise-devel Repo : pbise Description : The pbis-enterprise-devel package includes the development ``` ### PBIS オープン PBIS Open は、BeyondTrust がサポートしなくなった非推奨製品です。詳細については、[BeyondTrust pbis-open ドキュメント](https://github.com/BeyondTrust/pbis-open/wiki/Documentation)を参照してください。 ### AD Bridge (PBIS Enterprise) 次のいずれかを試すことができます。 + **ライセンスを更新し、AD Bridge の運用を継続します。**ライセンスとサポートについては、BeyondTrust にお問い合わせください。 + **AD Bridge の使用を中止します。**次の Shell コマンドを実行して、Linux マネージドインスタンスから PBIS-Enterprise パッケージを削除します。詳細については、BeyondTrust ドキュメント[「ドメインを残して AD Bridge エージェントをアンインストール](https://www.beyondtrust.com/docs/ad-bridge/getting-started/installation/leaving-domain.htm)する」を参照してください。 ``` $ sudo /opt/pbis/bin/uninstall.sh purge ``` ### PBIS エージェントを削除せずに AMS マネージド Active Directory ドメインを残す PBIS エージェントを削除せずに AMS マネージド Active Directory を離れるオプションがあります。オペレーティングシステムに応じて、次のいずれかのソリューションを使用します。 ------ #### [ Linux operating systems ] AMS マネージド AD の PBIS を使用して、次のシェルコマンドを実行して Linux EC2 インスタンスの結合を解除します。詳細については、使用しているバージョンに応じて、[BeyondTrust pbis-open](https://github.com/BeyondTrust/pbis-open/wiki/Documentation) または [BeyondTrust AD Bridge](https://www.beyondtrust.com/docs/ad-bridge) のドキュメントを参照してください。 ``` $ sudo /opt/pbis/bin/domainjoin-cli leave ``` 次のようなエラーメッセージが表示される場合があります。 ``` Error: LW_ERROR_KRB5_REALM_CANT_RESOLVE [code 0x0000a3e1] Cannot resolve network address for KDC in requested realm ``` このエラーが発生した場合は、次のコマンドを実行して AD プロバイダーレジストリを削除し、`lwsm`サービスを再起動します。 ``` $ /opt/pbis/bin/regshell dir '[HKEY_THIS_MACHINE\Services\lsass\Parameters\Providers\ActiveDirectory\DomainJoin]' ``` 前のコマンドから受け取ったディレクトリ ID 出力 (例: **A123EXAMPLE.AMAZONAWS.COM**) を使用して、次のコマンドを実行します。 ``` $ /opt/pbis/bin/regshell delete_tree \ '[HKEY_THIS_MACHINE\Services\lsass\Parameters\Providers\ActiveDirectory\DomainJoin\DIRECTORYID]' $ /etc/pbis/redhat/lwsmd restart $ /opt/pbis/bin/lwsm restart lwreg ``` ------ #### [ Windows operating systems ] ``` # Collect hostname and domain name using: Test-ComputerSecureChannel -verbose # Disjoin computer from the domain: netdom remove hostname /domain:domain name /force ``` **注記** 「」で説明されているように、 Managed Services Startup スケジュールされたタスクを無効化または削除してください[AMS EC2 起動スクリプトを無効にする](#offboarding-malz-disable-ec2-launch-scripts)。 ------ ## Trend Micro Deep Security Trend Micro Deep Security の使用を続行または中止するには、次のいずれかのオプションを使用します。 **使用を継続する** + **(MALZ 全体をオフボーディングする場合) Core アカウントのオフボーディング後、オフボーディングされたアプリケーションアカウントを既存の Trend Micro Deep Security Manager (DSM) に再接続し、共有サービスアカウントのライセンスを維持します。**詳細については、[AWS 「クラウドアカウントの追加](https://help.deepsecurity.trendmicro.com/12_0/aws/Add-Computers/add-aws.html?Highlight=account%20sync)」および[「ライセンス情報の確認](https://help.deepsecurity.trendmicro.com/12_0/aws/Manage-Components/ui-admin-licenses.html)」を参照してください。 1. 共有サービスアカウントにログインし、Secrets Manager コンソールに移動します。 1. `/ams/eps/` パスに保存されている DSM コンソール管理者認証情報を取得します。 1. [https://dsm.sentinel.int](https://dsm.sentinel.int/) で DSM コンソールにログインします。 1. **クロスアカウントロールの使用** を選択し、 と入力します**arn:aws:iam::ACCOUNTID:role/mc\$1eps\$1cross\$1account\$1role**。**ACCOUNTID** をオフボーディングされたアプリケーションアカウント ID に置き換えます。 1. [**次へ**] を選択します。 1. DSM がアカウント検出を処理し、同期が成功したことを示すまで数分待ちます。 + **オフボードのアプリケーションアカウントを新しい Trend Micro DSM インストールに再接続します。**詳細については、[「エージェントのアクティブ化と保護](https://help.deepsecurity.trendmicro.com/12_0/aws/agent-initiated-activation-communication.html?Highlight=activation)」および[「エージェントのアクティブ化](https://help.deepsecurity.trendmicro.com/12_0/aws/Get-Started/Install/activate-agent.html?Highlight=activate%20agent)」を参照してください。 + **オフボーディングされたアプリケーションアカウントを Trend Micro Cloud One に再接続します。**詳細については、「[Migrate from Deep Security to Workload Security](https://help.deepsecurity.trendmicro.com/20_0/on-premise/migration.html)」および[「Migrate from an on-premises DSM](https://cloudone.trendmicro.com/docs/workload-security/migration/)」を参照してください。 **使用の中止** + **Trend Micro Deep Security Agents をオフボードされたアプリケーションアカウントからアンインストールします。**詳細については、[「ディープセキュリティのアンインストール](https://help.deepsecurity.trendmicro.com/12_0/aws/Get-Started/Install/ig-uninstall-basic.html?Highlight=uninstall%20agent)」を参照してください。