AWSマルチアカウント環境のIAM管理

2026/4/16

はじめに

AWSアカウントが増えていく。開発環境、本番環境、プロダクトごと。3つ、5つ、8つと。そのたびにIAMユーザーを作って、パスワードを発行して、MFAを設定する。新しいメンバーが入れば同じことを全アカウントで繰り返し、退職者が出れば全アカウントを巡回して削除する。

この運用、どこかで破綻しないでしょうか。

この記事では、マルチアカウント環境でIAMユーザーを量産することの何が辛いのかを具体的に整理し、解決策を段階的に見ていきます。

前提知識の確認

この記事で使う3つの概念を簡単に整理しておきます。

AWSアカウント : AWSリソースを所有・管理する独立した区画のこと。12桁の数字のIDで識別される。環境分離・請求分離・権限の境界として、複数のアカウントを使い分けるのが一般的。

IAMユーザー : 特定のAWSアカウントの中に作成される認証情報のこと。ユーザー名とパスワード（コンソールログイン用）やアクセスキー（CLI/API用）を持つ。重要なのは、IAMユーザーはアカウントに閉じるという点。アカウントAのtanakaはアカウントBには存在しません。

IAMロール : 一時的に引き受ける（AssumeRole）ことができる権限の束のこと。パスワードやアクセスキーを持たないのが、IAMユーザーとの決定的な違いになる。IAMロールについてはこのあと詳しく見ていきます。

IAMユーザー量産の何が辛いのか

エンジニアの田中さんが3つのAWSアカウントで作業する、という例で考えてみます。各アカウントにIAMユーザーを作ると、こうなります。

	アカウントA (product a)	アカウントB (product b)	アカウントC (product c)
田中さん	IAMユーザー作成	IAMユーザー作成	IAMユーザー作成

この例をもとに、何が辛いのかをもう少し具体的に見てみましょう。

認証情報が分散する。 田中さんは3つのアカウントそれぞれで別のパスワードを持つことになります。パスワードマネージャーに3エントリ。変更するときも3回。MFAデバイスも各アカウントで個別に登録しなければなりません。CLIアクセス用のアクセスキーも、アカウントの数だけ必要です。

管理操作が重複する。 田中さんが退職したら、3アカウント全てでIAMユーザーを削除しなければなりません。1つ忘れたら、そこがセキュリティホールになる。さらに、この方式はスケールしません。10アカウント × 50人 = 500 IAMユーザー。これを手動管理するのは現実的ではないですよね。

組織が成長してアカウントと人が増えれば、管理コストとリスクは掛け算で膨れ上がります。

ではどうすればいいのでしょうか。

解決策①: クロスアカウントAssumeRole

IAMロールをもう少し詳しく

前提知識の確認で「IAMロールはパスワードやアクセスキーを持たない」と書きました。ではIAMユーザーの代わりに何を持っているのか。

IAMロールには2種類のポリシーが付いています。

信頼ポリシー（Trust Policy）: 「誰がこのロールを引き受けていいか」を定義する
権限ポリシー（Permissions Policy）: 「このロールを引き受けたら何ができるか」を定義する

信頼ポリシーが通らないとロールを引き受けられません（AssumeRole拒否）。信頼ポリシーが通った上で、権限ポリシーの範囲内でしか操作できない、という二段構えです。

信頼ポリシーはJSON形式で書かれます。たとえば「アカウントA（111111111111）からのAssumeRoleを許可する」場合はこうなります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

パスワードの代わりに信頼ポリシーがある、と考えるとわかりやすいと思います。IAMユーザーは「パスワードを知っている人が使える」。IAMロールは「信頼ポリシーで許可された相手が引き受けられる」。

踏み台アカウントからのSwitch Role

このAssumeRoleという仕組みを使うと、マルチアカウント環境のIAM管理を改善できます。

アカウントA（「踏み台アカウント」と呼ばれます）にだけIAMユーザーを作る
アカウントB/CにはIAMユーザーを作らず、IAMロールを作る。そのロールの信頼ポリシーに「アカウントAからのAssumeRoleを許可する」と書く
田中さんはアカウントAにログインし、「ロールの切り替え（Switch Role）」でアカウントBのロールを引き受ける
一時的なクレデンシャル（有効期限付き）が発行され、アカウントBを操作できるようになる

IAMユーザーの作成はアカウントAだけで済みます。

何が改善されて、何が残るか

ユーザー管理が1つのアカウントに集約されました。パスワード管理、退職時の削除、MFA設定、いずれも踏み台アカウントだけで完結します。これは大きな改善です。

一方で、各アカウントでのIAMロール作成と信頼ポリシーの設定は手動のままです。

管理者が自分で:

アカウントBにログインする
IAMロールを手動で作成する
信頼ポリシーを手動で書く
権限ポリシーを手動で付ける

アカウントが増えるたびに、この手順を繰り返します。10アカウントあれば10回。とはいえアカウントが増える頻度が高くないのであれば、そこまでの負担ではないかもしれません。

この手作業まで自動化したくなったら、IAM Identity Centerの出番です。

解決策②: IAM Identity Center

IAM Identity Center（旧称: AWS Single Sign-On / AWS SSO）は、AWSが提供するマルチアカウント環境向けのID管理・認証サービスです。AWS Organizationsと統合して動作します。

ポータルからのログイン

IAM Identity Centerを使うと、アクセスの流れはこう変わります。

田中さんはIAM Identity Centerのポータル（1つのURL）にログインする
ポータル画面に「あなたがアクセスできるAWSアカウント一覧」が表示される
「アカウントAのAdministratorAccess」をクリックすると、そのアカウントのマネジメントコンソールが開く

各アカウントにIAMユーザーは存在しません。ログインURLも1つだけ。では、クリックしたとき裏側で何が起きているのでしょうか。

裏側で起きていること

ポータルで「アカウントAのAdministratorAccess」をクリックした瞬間、裏側では次のことが起きています。

アカウントA内のIAMロール（許可セットから自動生成されたもの）を特定する
STSのAssumeRoleを実行して、一時的なクレデンシャルを発行する
そのクレデンシャルでマネジメントコンソールにリダイレクトする

気づいたでしょうか。解決策①のクロスアカウントAssumeRoleと同じ仕組みが、裏側で自動的に動いているのです。

許可セットからIAMロールが自動で作られる

「許可セットから自動生成されたIAMロール」とは何でしょうか。

IAM Identity Centerでは、管理者は次の操作を行います。

許可セット「AdministratorAccess」を作成する（中身はAWS管理ポリシーAdministratorAccessを含む）
アカウント割り当てを行う。「IdCユーザーtanakaに、アカウントAで、AdministratorAccessを使わせる」という割り当てです

この2を実行した瞬間、IAM Identity CenterがアカウントAの中にIAMロールを自動で作成します。


アカウントA (111111111111)
┌───────────────────────────────────────────────────┐
│                                                   │
│  自動作成されたIAMロール:                          │
│  ┌───────────────────────────────────────────┐    │
│  │ ロール名:                                 │    │
│  │   AWSReservedSSO_AdministratorAccess_xxxxx│    │
│  │                                           │    │
│  │ 権限ポリシー:                             │    │
│  │   AdministratorAccess（管理者権限）        │    │
│  │                                           │    │
│  │ 信頼ポリシー:                             │    │
│  │   IAM Identity Centerサービスが           │    │
│  │   AssumeRoleすることを許可                │    │
│  └───────────────────────────────────────────┘    │
│                                                   │
│  ※ 管理者が手動で作ったものではない                │
│  ※ IAM Identity Centerが自動で作成・管理する      │
│  ※ ロール名は「AWSReservedSSO_」で始まる          │
│                                                   │
└───────────────────────────────────────────────────┘

解決策①の手動方式では、アカウントにログインし、IAMロールを作り、信頼ポリシーを書き、権限ポリシーを付ける、という4ステップをアカウントの数だけ繰り返す必要がありました。IAM Identity Centerでは、許可セットを1つ作ってアカウントに割り当てるだけ。IAMロールは自動で配置されます。

ルートユーザー・IAMユーザー・IdCユーザーの違い

AWSには3種類の「ユーザー」が登場します。整理しておきましょう。

	ルートユーザー	IAMユーザー	IdCユーザー
住んでいる場所	アカウント内	アカウント内	アカウントの外（IdCサービス内）
用途	緊急時のみ	日常アクセス	日常アクセス

IdCユーザーはアカウントの外にいます。だからこそ、1つのユーザーで複数のアカウントにアクセスできる。各アカウント内にはIAMロールだけが配置され、IdCユーザーがそれを引き受ける形になっています。

まとめ

IAMユーザーの量産、クロスアカウントAssumeRole、IAM Identity Center、どの選択肢でも中心にいるのはIAMロールとAssumeRoleです。IAM Identity Centerが裏側でやっているのは、手動で行っていたIAMロールの作成・信頼ポリシーの設定・AssumeRoleの実行の自動化です。仕組みの中心がAssumeRoleだと分かっていれば、どの選択肢を選ぶときも迷わずに済みます。私もこの軸を頭に置いて、アカウントが増えても慌てないIAM管理をしていきたいです。