IAMを別アカウントへ移行するには？ユーザー・ロール・ポリシーの再作成と確認

AWSアカウントを分けるとき、アプリケーションだけでなく、その実行ロールや運用担当者の権限も移行先に用意する必要があります。IAMは、ユーザー名やポリシー名をそろえるだけでは同じ権限関係になりません。移行先にIAMリソースを再作成し、参照先と関連付けを確認する順序で進めます。

同じ名前でも、別アカウントでは別のIAMリソース

IAMのARNにはAWSアカウントIDが含まれます。同名のロールを別アカウントに作成してもARNは異なるため、Lambdaの実行ロールや外部の信頼ポリシーなど、旧ARNを参照している設定は確認が必要です。識別子の形式はIAM識別子の公式資料で確認できます。

移行作業は「定義を取得する → 移行先用に修正する → 再作成する → 利用側を切り替える」の4段階に分けると、作り忘れと参照先の取り違えを防ぎやすくなります。

最初に一覧化するのは、名前より関連付け

GetAccountAuthorizationDetailsでは、ユーザー・グループ・ロール・ポリシーと相互の関係を取得できます。棚卸しの起点にはなりますが、取得結果をそのまま投入して全環境を復元する機能ではありません。APIを直接扱う場合は、結果が途中で切れていないかを確認し、必要なページをすべて取得します。サービス側の設定も別途照合してください。

再作成の方法は、件数と今後の運用で選ぶ

例えばCloudFormationのAWS::IAM::Roleでは、信頼ポリシー、管理ポリシーのARN、インラインポリシーなどを定義できます。IAMリソースに名前を明示する構成では、デプロイ時に必要なIAM関連の承認設定も確認します。

ポリシーは種類ごとに扱いを分ける

AWS管理ポリシーは、必要なものを移行先のユーザーやロールへアタッチします。カスタマー管理ポリシーは、移行先で作成して、その新しいARNをアタッチ先に指定します。インラインポリシーはユーザー・グループ・ロールに埋め込まれているため、管理ポリシーの一覧だけを見ていると漏れることがあります。

それぞれの違いは管理ポリシーとインラインポリシーを参照してください。名前を一致させることより、どの主体にどの許可が付いているかを照合することが重要です。

アカウントIDの一括置換だけでは足りない

ポリシーのResourceに旧アカウントのリソースが残っている場合でも、必ず誤りとは限りません。移行後も旧アカウントのデータを読む設計なら、意図的に残す参照もあります。反対に、新アカウントのリソースへ切り替えるなら、ARNやリソース名と、相手側の許可を一緒に見直します。

ロールの信頼ポリシーに特定ロールのARNを指定すると、保存時に固有のプリンシパルIDへ変換されます。そのロールを削除して同じ名前で作り直しても、元の信頼関係が自動的に復元されるわけではありません。Principalの仕様に沿って、新しい主体を参照するよう確認してください。

認証情報と権限定義は別に切り替える

IAMユーザーを再作成しても、既存のアクセスキーが新しいユーザーの認証情報になるわけではありません。アプリケーションが長期アクセスキーを使っている場合は、新しい認証方法への切替と動作確認を別作業として計画します。シークレットアクセスキーは作成時以外には取得できないため、棚卸し結果から復元できると考えないでください。詳細はアクセスキーの管理を参照してください。

切替後は「許可される操作」と「拒否される操作」を確認

1. 移行先のポリシー、ユーザー・グループ・ロールを作成し、必要な関連付けを設定する。
2. 信頼関係、リソース側のポリシー、利用サービスのロール参照を確認する。
3. 代表的な業務処理を実行し、必要な読み取り・更新が成功することを確認する。
4. 不要な操作まで許可していないか、意図した拒否も確認する。
5. 利用側の切替と監視が完了した後、旧環境の権限を段階的に整理する。

移行完了の基準は、IAMの一覧がそろったことではなく、新しい権限で業務が動き、不要なアクセスが許可されていないことです。

関連する移行手順

• Lambdaを別アカウントへ移行する方法
• EFSを別アカウントへ移行する方法