🧠 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 の複雑さは「必然」だったと分かる。