🧠 AI生成のドキュメント
本文書はAI生成のドキュメントです。AIとの対話でできた、役に立つ情報をブログ形式に変換して蓄積していきます。
IAM Role はなぜ Principal なのか
AWS IAM をある程度触っていると、こんな違和感を持ったことはないだろうか。
- IAM の Role が Principal になる
- User も Service も Role を「Assume」する
- 認可は Role を中心に行われている
RBAC（Role-Based Access Control）をちゃんと知っている人ほど、
この設計に 強烈な違和感を覚える。
この記事では、その違和感の正体を
RBAC の Role と IAM Role の違いから整理し、
なぜ IAM が「Role = Principal」という設計を採用しているのかを説明する。
RBAC における「Role」とは何か
まず、原典的な RBAC（NIST RBAC）を思い出す。
User → Role → Permission
- User が主体
- Role は 権限のグルーピング
- Role 自体は主体ではない
Role はあくまで「属性」や「帽子」であり、
認可の主体（Principal）は User である。
多くの Web アプリや業務システムは、このモデルを採用している。
IAM を見ると何が起きているか
IAM を RBAC の感覚で見ると、こう見える。
- Role が Principal？
- User はどこ？
- Service も Role を使う？
実際、IAM では以下が成り立つ。
- IAM User も Principal になれる
- IAM Role も Principal になれる
- 認可の中心は Role
これは RBAC の常識とは明確に異なる。
違和感の正体
違和感の正体はこれ。
IAM の Role は、RBAC の Role ではない
名前が同じなだけで、責務がまったく違う。
IAM Role の正体
IAM Role は次の特徴を持つ。
- 認証情報を持たない
- 自分では何も実行できない
- 権限（ポリシー）が直接アタッチされる
- User や Service が「引き受ける」
つまり IAM Role は、
「権限そのもの」を表す抽象的な主体
である。
IAM における Principal とは何か
IAM の認可評価は、概念的には次の形をしている。
Can(Principal, Action, Resource, Context)?
ここで重要なのは、
- 認可の評価軸は Principal
- Principal に紐づくポリシーだけが評価される
AssumeRole が起きた瞬間、
- User / Service の違いは消え
- Role が Principal になる
「誰が使ったか」はどこに行くのか
User や Service の情報は消えるわけではない。
- STS セッション
- CloudTrail
- Condition（aws:PrincipalTag など）
といった Context / 監査情報として扱われる。
IAM は意図的に次を分離している。
| 観点 | 担当 |
|---|---|
| 認可 | Role |
| 実行文脈 | Session |
| 実行者 | 監査ログ |
なぜ RBAC ではなく Role-centric なのか
AWS が直面している前提条件は RBAC の想定を超えている。
- 実行主体が人とは限らない
- 一時的な実行主体が大量に生まれる
- 外部 IdP、越境、マルチアカウント
- 自動生成・自動破棄されるワークロード
この世界では、
- User を Principal にするとスケールしない
- 権限を「人」に結びつけると破綻する
結果として AWS は、
「権限の集合」を Principal にする
という設計を選んだ。
それが IAM Role である。
RBAC と IAM の Role を対比する
| 観点 | RBAC Role | IAM Role |
|---|---|---|
| 役割 | 権限のグループ | 権限主体 |
| 主体になれるか | No | Yes |
| 認可の中心 | User | Role |
| 実行者 | User | User/Service |
| 一時性 | なし | 前提 |
実務での安全な再解釈
IAM を RBAC の延長で理解すると事故る。
実務では、頭の中でこう置き換えると腑に落ちる。
IAM の用語 再解釈
Role Permission Principal
AssumeRole 権限コンテキスト切替
Trust Policy 委譲ルール
結論
- IAM では User も Role も Principal になりうる
- しかし設計・運用の中心は明確に Role
- IAM Role は RBAC Role とは別物
IAM Role は
「Role」という名前の Principal である
この前提で見ると、IAM の複雑さは「必然」だったと分かる。