AWS 基礎コース / Chapter 05

IAMスイッチロールで、必要なときだけ別アカウントへ入る

「相手のアカウントのユーザーを作る」のではなく、相手側のロールを一時的に引き受ける。誰が、どのアカウントへ、何のために入るかを明文化する。

TL;DR

  1. スイッチロールは、現在のログイン主体が別アカウントのIAMロールを一時的に引き受ける操作。
  2. 信頼ポリシーは「誰が引き受けられるか」、許可ポリシーは「引き受けた後に何ができるか」を分ける。
  3. 講師など外部の運用者を受け入れる場合も、恒久的なユーザー配布より一時権限として設計する。

01ロール引受を「一時的な身分証」として捉える

ログインの主体と、いま使う権限は別にできる

AWSで別アカウントのロールを一時的に引き受ける流れ
元の認証情報を共有せず、対象側の一時権限へ切り替える。

スイッチロールでは、今ログインしている主体が対象アカウントのロールを引き受ける。認証情報そのものを相手と共有するのではなく、一時的なセッションとして操作する。

「誰がログインしたか」と「どの権限で操作中か」を分けて考えるのが、クロスアカウントの出発点。

02信頼と権限を二枚のポリシーで分ける

入室できる人と、部屋でできることを混ぜない

IAMロールの信頼ポリシーと許可ポリシーの役割分担
ロールは「誰が引き受けるか」と「何を実行できるか」の交点。

対象ロールの信頼ポリシーで引受元を指定し、付与する許可ポリシーでAWS操作を絞る。一方だけでは意図したアクセス制御にならない。

権限が強すぎる問題と、信頼元が広すぎる問題は別の診断対象として確認する。

03環境切替の事実を確認してから操作する

名前だけを信用せず、アカウントとロールを表示して確認する

スイッチロール後にアカウントIDとロールを確認する図
環境名の見た目だけでなく、実際の操作主体を確認する。

切り替えが成功しても、期待した環境にいるとは限らない。コンソールのロール表示やCLIのcaller identityを確認し、stg・prdの操作先を明確にしてから作業する。

クロスアカウントでは、操作前に「いま誰として、どのアカウントにいるか」を確認する習慣が最も効く。

結論

  1. スイッチロールは認証情報を共有せず別アカウントへ一時アクセスする仕組み。
  2. 信頼ポリシーと許可ポリシーを別々に設計する。
  3. 操作前にアカウントIDとロール名を必ず確認する。