企業がAWSを本格活用するとき、ほぼ必ず登場するのが「マルチアカウント構成のIAM設計」です。本番・開発・ステージングを別アカウントで運用しながら、ユーザーには1セットの認証情報だけを持たせる——この要件をどう実現するかが、AWS認定ソリューションアーキテクト プロフェッショナル（SAP-C02）でも頻繁に問われます。
この記事では、IAMロール・IAMポリシーの基本から、AssumeRoleによるクロスアカウントアクセスの仕組み、試験頻出の設計パターンまでをステップごとに解説します。
この記事で学べること
- AWSで複数アカウントを運用する際のIAM設計ベストプラクティス
- 「1セットの認証情報」の意味と実現方法
- IAMロールとIAMポリシーの違いと関係
- AssumeRoleによるクロスアカウントアクセスの仕組み
- SAP-C02試験で頻出する「マルチアカウント設計問題」の解き方
複数AWSアカウントを運用するとき、権限設計の何が問題になるか
企業がAWSを本格的に使い始めると、「本番環境」「開発環境」「ステージング環境」など用途ごとに複数のAWSアカウントを分けて運用することになります。このとき悩ましいのが、IAMユーザーの権限設計です。たとえば、以下のような要件が同時に求められる場面があります。
- 開発チームは開発環境だけにアクセスできるようにしたい
- 運用チームは開発と本番の両方を操作したい
- 開発チームは本番環境には絶対にアクセスさせたくない
- ユーザーには1セットの認証情報しか持たせたくない
一見矛盾しているように見えるこの要件も、AWSが提供するIAMロールとAssumeRoleの仕組みを使えばシンプルに解決できます。
「1セットの認証情報」がなぜ重要なのか
AWSにログインするための情報が「認証情報」です。主に2種類あります。
| 種類 | 内容 | 用途 |
|---|---|---|
| コンソールログイン用 | ユーザー名・パスワード | Webブラウザからのログイン |
| プログラムアクセス用 | アクセスキーID・シークレットアクセスキー | CLIやSDKからのアクセス |
アカウントごとに別々の認証情報を持つと、以下のような問題が生じます。
- パスワードや鍵の管理が煩雑になる
- 鍵を使い回すセキュリティリスクが発生する
- ユーザーが退職したときにすべてのアカウントから個別に削除する手間がかかる
- 監査・ログ管理が複雑化する
そこでAWSでは、「1つのアカウントにIAMユーザーを集約し、他のアカウントへはIAMロールを使って乗り換える」という設計が推奨されています。
マルチアカウントIAM設計の全体像
まず、今回解説する設計の全体像を図で見てみましょう。
ポイントは以下の通りです。
- AMユーザーは開発アカウント側にのみ作成する
- 運用チームは開発グループと運用グループの両方に所属する
- 運用グループには「本番ロールを引き受ける許可」が付与されている
- 本番アカウントには共有IAMロールが1つだけ存在する
- 本番ロールは開発アカウントを信頼するよう信頼ポリシーで設定されている
IAMグループはアカウントをまたいで権限を付与できません。アカウント横断のアクセスには必ずIAMロール＋AssumeRoleを使います。
IAMの4つの基本要素
マルチアカウントIAM設計を理解するには、IAMの基本要素を正確に把握することが先決です。
1. IAMユーザー
AWSにアクセスする「人」や「個別のアプリケーション」を表すエンティティです。認証情報（パスワード、アクセスキー）を持ち、削除されるまで永続的に有効です。1人1ユーザーが原則です。
2. IAMグループ
複数のIAMユーザーをまとめて、同じ権限を一括で付与するための仕組みです。グループ自体は認証情報を持ちません。グループにIAMポリシーを付与すると、所属する全ユーザーに適用されます。
3. IAMロール
「一時的に引き受ける権限の集合」です。AWSサービスや別アカウントのユーザーが引き受けることで、その権限を一時的に使えるようになります。永続的な認証情報を持たず、「信頼ポリシー（誰が使えるか）」と「アクセス許可ポリシー（何ができるか）」の2つで構成されます。
4. IAMポリシー
「何ができるか」というルールを定義したJSONドキュメントです。ユーザー・グループ・ロールに付与して使います。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["ec2:*", "rds:*"],
"Resource": "*"
}
]
}ロールとポリシーの関係を会社組織で例えると、ロールは「部長・課長」という役職の箱、ポリシーはその役職でできる仕事内容のルールです。太郎さんが部長ロールを引き受けると、部長として許可された仕事ができるようになります。
クロスアカウントアクセスとAssumeRoleの仕組み
クロスアカウントアクセスとは、あるAWSアカウントのユーザーが別のAWSアカウントのリソースにアクセスすることです。これを実現する仕組みが、IAMロールの引き受け（AssumeRole）です。
AssumeRoleは一言でいえば「一時的な通行手形」です。開発アカウントのユーザーが本番アカウントへのアクセスを必要とするとき、AWS STS（Security Token Service）に申請して有効期限付きの一時認証情報を発行してもらい、その手形を使って本番アカウントのリソースを操作します。有効期限が切れれば手形は失効します。
実際のAssumeRoleは次の4ステップで進みます。
Step 1：AssumeRole APIの呼び出し
開発アカウントのユーザーが、AWS STSのAssumeRole APIを呼び出します。
aws sts assume-role
--role-arn "arn:aws:iam::222222:role/production-admin"
--role-session-name "taro-session"Step 2：STSが信頼ポリシーを確認
AWS STSは、本番アカウントの共有ロールに設定された信頼ポリシーを確認します。以下のように「開発アカウント（111111）からのAssumeRoleを許可」と記載されていれば、STSは許可と判定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111:root"
},
"Action": "sts:AssumeRole"
}
]
}Step 3：一時認証情報の発行
STSは以下の4つの要素を含む一時認証情報を発行します。
- AccessKeyId（一時的なアクセスキー）
- SecretAccessKey（一時的なシークレットキー）
- SessionToken（セッショントークン）
- Expiration（有効期限・デフォルト1時間）
Step 4：一時認証情報で本番環境を操作
発行された一時認証情報を使い、本番アカウントのリソースを操作できます。操作範囲は、本番ロールに付与されたアクセス許可ポリシーの範囲内に限定されます。
AssumeRoleが成功するには「開発側：本番ロールを引き受けてよい（IAMポリシー）」と「本番側：開発アカウントからの引き受けを許可（信頼ポリシー）」の両方が必要です。どちらか一方でも欠けるとアクセスは拒否されます。
SAP-C02試験の典型問題と正解の設計
以下はSAP-C02試験で出題される典型的なシナリオです。
- 会社に2つのAWSアカウント（本番用・開発用）がある
- 開発チームは開発インフラを作成・削除できる必要がある
- 運用チームは開発・本番の両方のインフラを作成・削除できる必要がある
- 開発チームは本番インフラにアクセスできてはならない
- すべてのユーザーが1セットのAWS認証情報を持つ必要がある
この要件を満たす正解の設計は次のとおりです。
| 場所 | 設定内容 |
|---|---|
| 本番アカウント | インフラ作成・削除できる共有IAMロールを作成。信頼ポリシーで開発アカウントを信頼する。 |
| 開発アカウント | 開発IAMグループ（開発インフラ権限）を作成。運用IAMグループ（本番ロールをAssumeRoleする権限）を作成。 |
| IAMユーザー | 全員のIAMユーザーを開発アカウントに作成。開発チームは開発グループのみ、運用チームは両グループに所属。 |
この設計がすべての要件を満たす理由を確認しておきましょう。
- 開発チームは開発インフラを作成・削除可能（開発グループに権限）
- 運用チームは開発インフラを操作可能（開発グループ所属）
- 運用チームは本番インフラも操作可能（運用グループのAssumeRole経由）
- 開発チームは本番にアクセス不可（本番ロールを引き受ける権限なし）
- 全ユーザーが1セットの認証情報（開発アカウントのIAMユーザーのみ）
マルチアカウントIAM設計の4原則
今回のケースから導けるベストプラクティスをまとめます。
- IAMユーザーは1か所に集約する：分散させると管理コストが増大し、セキュリティリスクも高まります。
- アカウント横断はIAMロールで実現する：IAMグループはアカウントをまたげないため、必ずIAMロール＋AssumeRoleを使います。
- IAMロールは「使われる側のアカウント」に作成する：本番リソースを操作するロールは本番アカウントに作る必要があります。
- 最小権限の原則を徹底する：必要な人に、必要な権限だけを付与します。
混同しやすいIAM用語の完全ガイド
| 用語 | 意味 | 一言で |
|---|---|---|
| IAMユーザー | 個別の認証情報を持つエンティティ | ログインする「人」 |
| IAMグループ | ユーザーをまとめる論理単位 | ユーザーの「まとまり」 |
| IAMロール | 一時的に引き受ける権限の集合 | 一時的に着る「役職」 |
| IAMポリシー | 権限のルールを記述したJSON | 具体的な「許可ルール」 |
| 信頼ポリシー | ロールを誰が使えるかを定義 | ロール専用の「入室許可書」 |
| アクセス許可ポリシー | 何ができるかを定義 | 通常の「権限ルール」 |
| AssumeRole | ロールを引き受けるAPI操作 | ロールに「乗り換える」行為 |
| AWS STS | 一時認証情報を発行するサービス | 通行手形の「発行窓口」 |
まとめ
本記事では、AWSのマルチアカウント環境でのIAM設計について解説しました。要点を振り返ります。
- 複数アカウントを扱う際は、IAMユーザーを1つのアカウントに集約する
- 他アカウントへのアクセスはIAMロール＋AssumeRoleで実現する
- IAMロールには「信頼ポリシー」と「アクセス許可ポリシー」の2種類がある
- AssumeRoleは「一時的な通行手形」を発行する仕組み
- IAMグループに付けるのはRoleではなく、Roleを引き受ける許可を記述したPolicy
この設計パターンはSAP-C02試験で頻出するだけでなく、実務でも必ず使う基礎知識です。試験合格と実務スキルの両方を目指して、ぜひしっかり定着させてください。
参考リソース
- AWS公式ドキュメント：IAMロールを使用したAWSアカウント間のアクセス委任 — IAMロールを使ったクロスアカウントアクセスのチュートリアル
- AWS公式ドキュメント：IAMのクロスアカウントリソースアクセス — クロスアカウントリソースアクセスの詳細な解説
- AWS re:Post：IAMによるクロスアカウントアクセスの許可 — よくある質問形式で実装方法が学べる
- AWS公式：Security Token Service（STS）の仕組み — 一時認証情報の発行元であるAWS STSの公式ドキュメント
コメント