はじめに
AWSコンソールを触っていて「自分が今どんな権限でログインしているのか」「ロールとポリシーって何が違うのか」が曖昧なまま使っていたので、自分の理解を整理してみました。同じところでつまずいている人の助けになれば。
登場人物の整理
まず、IAM周りの用語を「役者と舞台」の比喩で整理すると一気に分かりやすくなりました。
| 用語 | 役割 | 比喩 |
|---|---|---|
| アカウント | ユーザー・ロール・ポリシーを入れておく器 | 舞台 |
| ユーザー | ログインする本人（固定された身分） | 役者本人 |
| ロール | 引き受けて使う一時的な身分 | 衣装 |
| ポリシー | 「できることの中身」を書いた定義 | 台本 |
ポイントは、実体を持って「操作する主体」になれるのはユーザーやロールで、アカウントはそれらを内包する箱にすぎないということです。
ポリシーは「できることの定義書」
ポリシーは、たとえば「ec2:DescribeInstances を許可する」のように、できることの中身そのものを書いた定義です。
重要なのは、ポリシーは単体では誰にも効力を持たないという点です。ユーザーやロールにアタッチして初めて意味を持ちます。台本だけ置いてあっても、誰かが演じなければ何も起きないのと同じです。
ロールは「台本を持った衣装」
ロールは、ユーザーのように特定の人へ固定された身分ではなく、必要なときに人やサービスが「引き受ける（assume する）」ための、権限の入れ物です。
- 衣装（ロール）には、どの台本（ポリシー）を持たせるかが結びついている
- 人がその衣装を着ている間は、台本に書かれた権限で動ける
ログイン時に特定のロールを引き受けて、そのロールの権限で操作している、というのがよくある構成です。
許可セットとロールの関係（IAM Identity Center）
IAM Identity Center（旧 AWS SSO）を使っている場合、「許可セット（Permission Set）」という概念が登場します。
許可セットは、アタッチするポリシーをまとめたテンプレートです。「ポリシーの集まり」と捉えてよいです（AWS管理ポリシー、独自ポリシー、付帯設定などを束ねられる）。
そして関係を整理すると、「許可セットの集まりがロール」ではなく、逆に近いです。
許可セット（テンプレート / Identity Center側で管理）
↓ ユーザー × AWSアカウント の組み合わせに割り当てると
各アカウント内にIAMロールが自動生成される
↓ ログイン時に
そのロールを引き受けて操作する
つまり 「許可セット1つから、割り当て先アカウントごとにロールが1つ生成される」 という対応です。
自動生成されるロールの命名規則
Identity Center が自動生成するロールは、次のような名前になります。
AWSReservedSSO_<許可セット名>_<ランダムな16進文字列>
-
AWSReservedSSO_… Identity Centerが管理する予約済みロールの目印 -
<許可セット名>… 元になった許可セットの名前 -
<ランダム文字列>… 同じ許可セットを複数アカウントに割り当てたときの名前衝突を防ぐためのサフィックス
逆に言うと、AWSReservedSSO_接頭辞のないロールは、Identity Centerの自動生成ではなく、手動で作られたロールやフェデレーション用ロールの可能性が高いです。これは環境の構成を見分ける手がかりになります。
「ユーザー × アカウント」で権限を出し分けられる
許可セットの割り当ては「誰に / どのアカウントで / どの許可セットを」の3点セットで決まります。これにより、
- 同じアカウント内でも、田中さんには管理者権限、佐藤さんには閲覧のみ、という出し分けができる
- 一人のユーザーでも、アカウントAでは管理者、アカウントBでは閲覧のみ、というようにアカウントごとに権限を変えられる
「Aさんは開発アカウントでは何でもできるが、本番アカウントでは見るだけ」といった設計が、ユーザーごと・アカウントごとに細かくできるわけです。
自分が今どんな身分か（ARNの読み方）
コンソールの右上や、エラーメッセージなどに出てくる ARN（Amazon Resource Name = AWSリソースの住所）を読むと、自分が今何者として動いているかが分かります。
たとえば次のようなARNがあったとします。
arn:aws:sts::123456789012:assumed-role/ExampleRole/user@example.com
区切って読むと、
| 部分 | 意味 |
|---|---|
arn:aws:sts:: |
STS（Security Token Service）が発行した一時的な認証情報。ロールを「引き受けた」状態を表す |
123456789012 |
AWSアカウントID（12桁の数字）。アカウント名やエイリアスではなく数字の本体ID |
assumed-role/ExampleRole/... |
引き受けているロール名は ExampleRole
|
user@example.com |
セッション名（誰がこのセッションを使っているかの識別子） |
sts かつ assumed-role になっているのは、「ロールという衣装を着ている状態」だからです。ここを読めば、今まさに自分が引き受けているロール名が分かります。
補足：ARNにヒントが隠れていることも
ロール名の部分に ADFS などの文字が入っていれば、ADFS（Active Directory フェデレーション）経由でログインしている構成だと推測できます。社内のActive Directoryで認証してAWSのロールを引き受けるパターンです。ARNは身分証であると同時に、環境構成のヒントにもなります。
まとめ
- アカウントは器。実体を持って操作するのはユーザーとロール
- ポリシーは「できることの定義書」、単体では効力なし。何かにアタッチして初めて効く
- ロールは「台本（ポリシー）を持った衣装」。引き受けて使う一時的な身分
-
許可セットはポリシーをまとめたテンプレート。割り当てると各アカウントにロールが自動生成される（
AWSReservedSSO_接頭辞） -
ARNを読めば、自分が今どのアカウントで、どのロールを引き受けているかが分かる
用語の対応関係さえ掴めば、「自分が今どんな権限で動いているのか」を自力で読み解けるようになります。