IAMまわりの「〇〇ユーザ・ロール・ポリシー」系用語まとめ

#前提

IAMについて勉強する過程で、色んな所で色んな単語が使われすぎててよくわからなくなってきたので頻出の用語をまとめました。
IAM関連の情報を理解する手助けになればという目的でざっくりまとめたので、それぞれの詳細や設定方法については各自調べてください。


#基本

- IAMはAWS内において『誰がどのサービスに対して何ができるか』を設定するサービス
- このうち、『誰が』をIAMユーザで指定し、『どのサービスに対して何ができるか』をIAMポリシーで設定する(例外有り)
- IAMユーザとIAMポリシーはそれぞれ独立しており、両者を紐づける（「IAMユーザにIAMポリシーをアタッチする」と表現する）ことで各ユーザの権限を設定する
- 『誰が』の部分は人である必要はなく、AWSが提供するサービスや別のAWSアカウント等であってもかまわない。このような場合はIAMユーザではなくIAMロールという別の認証情報を使用する
- IAMユーザとIAMポリシーは一対一対応である必要はなく、1つのIAMユーザに複数のIAMポリシーがアタッチされることが多い。また複数のIAMユーザに同様のIAMポリシーをアタッチしたい場合も多く、このような場合ユーザとポリシーの管理が複雑になりやすい
- この複雑さを解消するために、両者の組み合わせをまとめるIAMグループという括りを利用することができる


#（プリンシパル）エンティティ

　IAM関連の情報内でこの言葉が使用される場合はIAMユーザ・IAMロール・IAMグループの総称。
　IAMポリシーをアタッチする対象をまとめてこう言ってるんだな、と考えればOK

#ユーザ・アカウント

- [IAMユーザ](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_users.html)
    - エンティティの一種で、AWSにおける利用者の認証に使用される情報の総称
    - 基本的にすべての利用者は何らかのIAMユーザが割り当てられている

- [ルートユーザ](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_root-user.html)
    - AWSアカウント作成後最初にログインするユーザをルートユーザと呼ぶ
    - 上記IAMユーザが割り振られない例外的存在
    - ルートユーザは「なんのIAMユーザも付与されていない、あらゆる権限を持つ者」として振る舞うことができる
    - ルートユーザの権限はあまりに大きいので、現在は最初のログイン時にのみルートユーザを使用し、以降は適切な権限を持ったIAMユーザを作成し、そちらを使用することが推奨されている
    -  **〇〇ユーザと呼ばれはするが、「ルートユーザという名前のIAMユーザがある」わけではないので注意**


- [AWSアカウント](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_root-user.html)
    - IAM関連の文脈で使用される場合はルートユーザのこと

#ポリシー

- [IAMポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html)
    - AWSにおける権限をまとめたもの
    - 「基本」も書いた通り、IAMポリシーは「どのサービスにおいて（どのリソースに対して）何ができるか」という「権限の集合」であり「誰が」の部分は定義されない。そのためIAMポリシーをエンティティにアタッチして初めて権限を付与できる

- [(カスタマー)管理ポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)
    - IAMポリシーのうち、ユーザが作成するもの
    - インラインポリシーと違い、アタッチ対象のエンティティから独立して存在できるポリシー
    - 「カスタマー管理ポリシー」と「AWS管理ポリシー」をまとめて「管理ポリシー」と呼ぶこともある

- [AWS管理ポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)
    - IAMポリシーのうち、AWSによってデフォルトで作成されているもの
    - AWS管理ポリシーの内容をユーザが変更することはできない

- [インラインポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)
    - 「〇〇管理ポリシー」との対比で使用される単語
    - エンティティに直接付与されるポリシーの総称
    - 上の「基本」ではIAMポリシーとIAMユーザを紐づけることで権限の付与を行うと書いたが、その例外がインラインポリシー
    - 実はエンティティを作成する際に、IAMポリシーを使わず直接エンティティに権限を付与することもできる
    - このような場合に作成されるエンティティに固有な権限の集合をインラインポリシーと呼ぶ
    - エンティティに直接付与されるポリシーなので、当然アタッチされたエンティティと一対一対応する
    - 管理が複雑になるため通常は非推奨

- [アイデンティティベースのポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)
    - 「リソースベースのポリシー」との対比で使用される単語
    - IAMユーザ・ロール・グループにアタッチする通常のIAMポリシーのこと

- [リソースベースのポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)
    - 「アイデンティティーベースのポリシー」との対比で使用される単語
    - IAMポリシーとしてではなくリソースに直接設定するポリシーのこと
    - Lambda関数を動かす時なんかによく利用される
    - リソースベースのポリシーは全てインラインポリシーである

- [Lambda関数ポリシー](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/access-control-resource-based.html)
    - リソースベースのポリシーのうちLambda関数にアタッチされるもの
    - リソースベースのポリシーが利用されるシーンの多くがlambda関数を動かす時なので、リソースベースポリシー全体を指す言葉としてこの言葉が使用されることもたまにある

- [アクセスポリシー](https://dev.classmethod.jp/cloud/aws/policies-for-lambda/)
    - リソースベースのポリシーの一種で、S3(AWSのストレージサービス)へのアクセスを管理する際に使用する

- [信頼ポリシー](https://dev.classmethod.jp/cloud/aws/policies-for-lambda/)
    - 「信頼関係」とも呼ばれる
    - AWSにおけるクロスアカウントアクセス（あるアカウントから別アカウント内のリソースに対して閲覧・操作等ができるようにする）に使用する特殊なポリシー
    - 他のAWSアカウントを便宜上一種の「リソース」とみなしてそのアカウントにIAMロールを設定し、そのIAMロールに対して信頼ポリシーを設定することで、別アカウントからのリソース操作を可能にする（あるアカウントから別のアカウント内のリソースに対して操作を行うとき、この「権限を与えられた操作主体」のことをプリンシパルと呼ぶ）


- [セッションポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html)
    - 一時セッションに対して権限を付与するために使用されるポリシー
    - セッションポリシーは単独で存在するポリシーではなく、既存のアイデンティティベース/リソースベースのポリシーに基づいて作成される
    - セッションポリシーは既存のポリシーに追加で権限を加える機能はなく、制限する機能しか持たない
    - つまりセッションポリシーは許可を付与するために使用するものではなく「既存のポリシーの権限の一部をセッションに許可するために、許可しない権限についてまとめたもの」

- [サービスコントロールポリシー（SCP）](https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scp.html)
    - 複数のAWSアカウントを跨いだ権限管理に使用するポリシー
    - SCPのみで全ての権限を厳密に定義することはできない（例：サービスコントロールポリシーと個別のAWSアカウントの両方で許可されて初めてその権限が有効になる・個別のAWSアカウントのルートユーザの権限は制限できない）

- [スタンドアロンポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) 
    - IAMポリシーのうち、ARN(Amazon Resource Nameの略、AWS内のリソースを一意に識別するために使用する)がついているもの


#ロール

- [IAMロール](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles.html)
    - エンティティの一種で、IAMポリシーをアタッチするリソースの認証に使用される情報の総称

- [実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)
    - Lambda関数を実行する際に使用されるIAMロール。Lmabda実行ロールと呼ばれることもある

- [タスクロール](https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_IAM_role.html)
    - AmazonECSにおいて、コンテナエージェントに対して付与されるIAMロール。タスク実行ロールと呼ばれることもある。


#グループ

- [IAMグループ](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles.html)
    - エンティティの一種で、複数のIAMユーザとIAMポリシーをまとめたもの
    - 大規模な組織でAWSを利用していると、IAM情報の管理が複雑化してくる。これを解消するために用意されているのがIAMグループ
    - チーム・部門ごとにIAMグループを作成した後、そのグループに対して複数のIAMポリシーとIAMユーザ（IAMロール）をアタッチすることで複数のIAM情報を一元的に管理できる




---

上記リンク以外で参考にさせていただいたページ

- [[AWS]管理ポリシーとインラインポリシーの違いが分からなかったので改めてIAMポリシーのお勉強をする](https://qiita.com/Batchi/items/a2dde3d2df27568cc078)
- [AWS LambdaのIAMポリシーとリソースポリシーを理解しよう](https://dev.classmethod.jp/cloud/aws/policies-for-lambda/)
- [AWS IAMポリシーを理解する](https://dev.classmethod.jp/cloud/aws-iam-policy/)
- [超簡単！今すぐ使える「クロスアカウントアクセス」](https://dev.classmethod.jp/cloud/aws/signin-with-cross-account-access/)
- [AWS OrganizationsのSCP（サービスコントロールポリシー）を理解する](https://dev.classmethod.jp/cloud/aws/aws-organizations-scp/)
- [Amazon ECSのタスクロールとタスク実行ロールの違い](https://qiita.com/working-cat/items/194830e18a7a3123f89f)