IAM のユーザー・ロール・ポリシーという名前は知っていても、「ロールは結局どう使われているのか」を説明しようとすると詰まりがちです。ロールにはパスワードもアクセスキーも無いのに、なぜ誰かが使えるのか。信頼ポリシーと権限ポリシーは何が違うのか。EC2 や Lambda に「ロールを付ける」とは何が起きているのか。この記事は、その3つを「引き受ける」という一つの動きでつなげて説明します。
この記事の結論
- ロールは特定の一人に結びつかない ID で、長期の認証情報（パスワード・アクセスキー）を持ちません。
- ロールには2種類のポリシーが付きます。信頼ポリシーは「誰が引き受けてよいか」、権限ポリシーは「引き受けた間に何ができるか」を決めます。
- 引き受けると STS が一時認証情報（アクセスキー ID・秘密のアクセスキー・セッショントークン）を返し、期限が来れば使えなくなります。
- 引き受けている間、本人の元の権限は使えず、ロールの権限に置き換わります。
- 別アカウントのロールは、相手側の信頼ポリシーと、こちら側の AssumeRole を許す権限の両方が要ります。第三者に渡すときは外部 ID で「混乱した代理」を防ぎます。
- セッションポリシーで、そのセッションだけ権限をさらに絞れます（ロールの権限との重なりになります）。
ロールとは何か：ユーザーとの違いは「長期の鍵を持たない」こと
IAM ロールは、特定の一人に結びつかない ID です。IAM ユーザーは「この人」に結びつき、パスワードやアクセスキーという長期の認証情報を持ちます。ロールはそれを持たず、「引き受けた人（またはサービス）」にだけ、その都度、期限つきの鍵を渡します。
たとえるなら、ユーザーは「個人専用の合鍵」、ロールは「受付で身元を確かめてから貸し出す期限つきの入館証」です。合鍵は失くしたら誰かが拾えば使えてしまいますが、入館証は期限が来れば自然に使えなくなります。ここで正確な言い方に戻すと、ロールが渡すのは一時認証情報で、これを発行するのが AWS STS（Security Token Service）です。
| 観点 | IAM ユーザー | IAM ロール |
|---|---|---|
| 結びつく相手 | 特定の一人 | 引き受けた誰か（人・サービス・別アカウント） |
| 認証情報 | パスワード・アクセスキー（長期） | なし。引き受けるたびに一時認証情報が出る |
| 期限 | 自分で消すまで続く | 期限つき（切れたら使えない） |
| 向く場面 | 長期の鍵が避けられない場合 | 人・アプリ・サービスへの権限の受け渡し全般 |
詳しいユーザー・ロール・ポリシーの全体像は iam-toha にあります。
READ ALSO — 学習中向け・段1 入口
IAM とは何か｜ユーザー・ロール・ポリシーを「誰が・何に・何をしてよいか」で読み解く
CHECK 1ここまでの確認
IAM ロールが、IAM ユーザーと違って持っていないものはどれ?
答えと解説
答え: 2. 長期の認証情報（パスワードやアクセスキー）
ロールは引き受けた人やサービスに、その都度、期限つきの一時認証情報を渡す設計です。長期の鍵を持たない点が最大の違いです。読み直すなら「ロールとは何か」の章へ。
ロールを引き受けるとは？：AssumeRole で STS が一時認証情報を返す流れ
ロールを使うことを「引き受ける」（assume する）と言い、API 名は AssumeRole です。流れは次の6コマです。
- 呼び出し元（IAM ユーザー、別のロール、AWS サービスなど）が、ロールの ARN を指定して AssumeRole を呼びます。
- ロールの信頼ポリシーが、「この呼び出し元は引き受けてよい相手か」を確かめます。
- 許されれば、STS が一時認証情報を発行します。中身はアクセスキー ID、秘密のアクセスキー、セッショントークンの3点です。
- 呼び出し元は、この3点を使って AWS を操作します。操作できる範囲は、ロールの権限ポリシーで決まります。
- 期限が来ると、この認証情報は使えなくなります。
- 続けたいときは、もう一度引き受けて新しい認証情報を受け取ります。
ASSUME A ROLE引き受けの6コマ
ロールは引き受けた間だけ、期限つきの鍵が渡る
-
AssumeRole
呼び出し元がロールを指定
-
信頼ポリシー
引き受けてよい相手か確認
-
STS が発行
一時認証情報の3点セット
-
ロールの権限
権限ポリシーの範囲で操作
-
期限切れ
鍵は使えなくなる
-
もう一度
必要なら引き受け直す
ここで見落としやすいのが、引き受けている間は、本人の元の権限は使えないことです。ロールを引き受けたセッションは、元のユーザーの権限ではなく、ロールの権限に置き換わります。「自分の権限にロールの権限が足される」のではありません。
期限は AssumeRole の DurationSeconds で決まり、最小は 900 秒、指定しなければ既定は 3600 秒です。上限はロールごとに設定された最大セッション時間です。ロールからさらに別のロールを引き受ける「ロールチェーン」では、最大 1 時間に制限されます。
信頼ポリシーと権限ポリシーの違い：「誰が」と「何が」の2枚
ロールには2種類のポリシーが付きます。名前は似ていますが、答える問いが違います。
| 信頼ポリシー | 権限ポリシー | |
|---|---|---|
| 答える問い | 誰がこのロールを引き受けてよいか | 引き受けた間に何ができるか |
| 例える場所 | 受付（入口の門） | 入館証で入れる部屋 |
| 書く対象（Principal） | あり（引き受けてよい相手を書く） | なし（ロールに付くので対象は決まっている） |
| 効くタイミング | AssumeRole を呼んだとき | 引き受けた後、AWS を操作するたび |
TWO POLICIESロールの2枚のポリシー
信頼ポリシーは誰が、権限ポリシーは何がを決める
信頼ポリシー（誰が）
- 引き受けてよい相手
- AssumeRole のとき効く
- 外部 ID などの条件
権限ポリシー（何が）
- 引き受けた間にできること
- 操作のたびに効く
- セッションポリシーで絞れる
どちらが欠けても使えない
信頼ポリシーは、リソースベースポリシーの一種として「誰を信頼するか」を書きます。たとえば「このアカウントの、あのロール」や「EC2 サービス」を相手として書きます。権限ポリシーの書き方（Effect・Action・Resource）や、許可と拒否の評価順は iam-policy-shikumi と同じ考え方です。ここでは繰り返さず、2枚の役割が別であることだけを押さえてください。
READ ALSO — 未経験向け・段1 入口
IAM ポリシーの評価の仕組み｜許可と拒否はどの順で決まるか
2枚のどちらかが欠けると使えません。信頼ポリシーが相手を許していなければ、そもそも引き受けられません。引き受けられても、権限ポリシーに許可が無ければ、操作は拒否されます。
CHECK 2ここまでの確認
「どの ID がそのロールを引き受けてよいか」を決めているのはどちらのポリシー?
答えと解説
答え: 2. 信頼ポリシー
信頼ポリシーが入口（誰が）、権限ポリシーが引き受けた後（何ができるか）を決めます。2枚は役割が別です。「2枚のポリシー」の章を読み直してください。
EC2・Lambda に「ロールを付ける」とは何が起きているのか：サービスが引き受ける仕組み
EC2 や Lambda に「ロールを付ける」と言いますが、実際に起きているのは、サービスがそのロールを引き受けていることです。ロールの信頼ポリシーには、「EC2 サービス」「Lambda サービス」のようにサービスを相手として書きます。Lambda の場合は関数に付けるロールを実行ロールと呼び、EC2 の場合はインスタンスプロファイルという入れ物を介してインスタンスに渡します。このような、サービスのために作るロールをサービスロールと呼びます。
アプリのコードは、引き受けの処理を自分で書きません。SDK の既定の認証情報の探し方が、実行環境から一時認証情報を取り、期限の前に更新してくれます。だから、コードや設定ファイルにアクセスキーを書かずに済みます。
アクセスキーを書くやり方との違いは、事故の形に出ます。
- キーをコードや設定ファイルに書くと、漏えいしたときに、誰かが拾って期限なしで使えます。ローテーション（鍵の入れ替え）の手間も続きます。
- ロールで渡した一時認証情報は、漏れても期限が来れば使えなくなり、入れ替えは自動です。
Glue ジョブのような他のサービスでも同じです。アクセスキーではなく、必要最小限の権限を持つロールを割り当てます。
CHECK 3ここまでの確認
EC2 のアプリが S3 を読むとき、コードにアクセスキーを書かずに済むのはなぜ?
答えと解説
答え: 2. EC2 に付けたロールをサービスが引き受け、一時認証情報を受け取る仕組みだから
ロールを付けるとは、サービスに引き受けを任せることです。一時認証情報は期限前に更新されます。「サービスにロールを付ける」の章が該当します。
別アカウントのロールを使う仕組み：両側の許可と外部 ID
別の AWS アカウントのリソースに一時的に触りたいときは、相手アカウントに作ったロールを AssumeRole で引き受けるのが基本の形です（クロスアカウントロール）。このとき、許可が両側に要ります。
- 信頼する側（リソースを持つアカウント）：ロールを作り、信頼ポリシーで「呼ぶ側のアカウント（またはその ID）」を許す。権限ポリシーで触れる範囲を決める。
- 呼ぶ側（使いたいアカウント）：自分の ID に、そのロールへの AssumeRole を許す権限を付ける。
どちらか片方だけでは、引き受けは成立しません。
BOTH SIDES別アカウントは両側の許可
引き受けは、信頼する側と呼ぶ側の両方の許可がそろって成立する
呼ぶ側のアカウント
- AssumeRole を呼ぶ
- AssumeRole を許す権限
- 信頼ポリシー
- ロールの権限ポリシー
信頼する側のアカウント
- AssumeRole を呼ぶ
- AssumeRole を許す権限
- 信頼ポリシー
- ロールの権限ポリシー
自分で用意する相手側で用意
第三者に渡すときは外部 ID
外部のベンダー（監視やコスト分析の SaaS など）に自分のアカウントを読ませるときは、もう一つ気を付けることがあります。ベンダーは多数の顧客のロールを引き受けるため、ある顧客がほかの顧客のロールの ARN を知って、ベンダー経由で引き受けさせようとする余地が生まれます。これを混乱した代理（confused deputy）の問題と呼びます。
対策は、信頼ポリシーに外部 IDの条件を付けることです。外部 ID はベンダーが顧客ごとに発行する一意の値で、信頼ポリシーの条件（sts:ExternalId）に入れます。ベンダーは引き受けるときにその値を添える必要があります。
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::<ベンダーのアカウント ID>:root" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "<顧客ごとに一意の値>" }
}
}
同じアカウントの中で自分のロールを使うだけなら外部 ID は要りません。「他人（第三者）が、多数の顧客のために引き受ける」場面の備えです。
セッションの権限を絞る：セッションポリシーと有効期限
AssumeRole には、そのセッションだけに効くセッションポリシーを渡せます。使い道は、同じロールを共有しながら、リクエストごとに触れる範囲を狭めたいときです。たとえば複数のテナント（利用者）が同じロールを使う SaaS で、テナントごとに触れる S3 のプレフィックス（フォルダに当たる範囲）を分ける場面があります。
押さえる点は一つで、セッションポリシーは権限を足せず、絞るだけです。有効な権限は、ロールの権限ポリシーとセッションポリシーの重なりになります。ロールが許していないことは、セッションポリシーに書いても許されません。
| 状況 | 有効な権限 |
|---|---|
| セッションポリシーを渡さない | ロールの権限ポリシーのとおり |
| 渡す | ロールの権限とセッションポリシーの重なり |
もう一つ、有効期限も絞る道具です。必要な時間だけの DurationSeconds を指定すれば、認証情報が漏れても使える時間は短くなります。
CHECK 4ここまでの確認
ロールを引き受けるときにセッションポリシーを渡すと、そのセッションで有効な権限は?
答えと解説
答え: 2. ロールの権限とセッションポリシーの重なりだけになる
セッションポリシーは権限を足せず、絞るだけです。「セッションの権限を絞る」の章を読み直してください。
つまずきやすい点：AccessDenied を信頼ポリシーと権限ポリシーのどちらで探すか
ロールまわりの AccessDenied は、どの段階で止まったかで探す場所が変わります。
| 起きていること | 疑う場所 |
|---|---|
| AssumeRole の呼び出し自体が拒否された | ロールの信頼ポリシー（相手として許されているか）、呼ぶ側に AssumeRole を許す権限があるか、外部 ID などの条件が合っているか |
| 引き受けは成功したが、S3 などの操作が拒否された | ロールの権限ポリシー、セッションポリシー、リソース側のポリシー |
| しばらく動いていたが急に拒否された | 一時認証情報の期限切れ（更新されているか） |
「ロールに権限を付けたのに使えない」ときは、権限ポリシーばかり見がちです。まず AssumeRole が成功しているかを確かめると、探す範囲が半分になります。
ここまでの要点をまとめます。ロールは長期の鍵を持たず、引き受けた相手に STS が期限つきの一時認証情報を渡します。信頼ポリシーが入口、権限ポリシーが範囲を決める別々の2枚です。サービスにロールを付けるとは、サービスが引き受けることです。別アカウントでは両側の許可が要り、第三者には外部 ID を使います。この先、複数アカウントに人を入れる方法は identity-center-toha、権限をどう設計するかは kengen-sekkei-pro に続きます。
READ ALSO — 学習中向け・段2 構成
IAM Identity Center とは何か｜複数アカウントへのサインインを1か所にまとめ、許可セットで権限を配る
参照ソース
- IAM ロールの用語と概念（AWS 公式ドキュメント） — ロールの定義、信頼ポリシーと権限ポリシー、委任、ロールチェーン、サービスロールの説明の根拠
- AssumeRole（AWS STS API リファレンス） — 返る一時認証情報の中身、DurationSeconds（既定 3600 秒、最小 900 秒）、セッションポリシーと外部 ID の根拠
