はじめに
AWSのアカウント・ユーザー・権限の関係性が複雑に感じていたので、一から IAM について調べたことをまとめます。
概要
- IAM とは
- IAM ユーザー
- IAM ポリシー
- IAM ロール
IAM とは
IAM は「Identity and Access Management」の略で、IDとアクセス権を管理するサービスになります。
複数のAWSアカウントが存在する際、誰がどのアカウントにアクセスできるか、どのサービスを利用できるのかといった権限を管理するためのサービスです。
※複数のAWSアカウントを持つメリットとデメリット
IAM ユーザー
IAM ユーザーは 人に与えられるID で、AWSアカウントにログインする際に必要となるユーザー名とパスワードが付与されます。
下記のように１つのAWSアカウントに複数のユーザーを作成することが可能で、従業員１人ずつ個別のIAMユーザーを作成することが推奨されます。
├── AWS アカウントA
│ ├── IAM ユーザーA1
│ └── IAM ユーザーA2
│
└── AWS アカウントB
├── IAM ユーザーB1
└── IAM ユーザーB2
新規作成したIAMユーザーには権限が存在しないため、後述する IAMポリシーを割り当てることでアクセス権を付与します。
ユーザーを複数まとめる「IAMユーザーグループ」という機能もあり、後述するIAMポリシー（アクセス権限）をグループに対して付与することも可能です。
別途として、AWSアカウントにログインするとき以外にも、プログラムに権限を渡したい場合にもIAMユーザーを作成することがあります。
IAM ポリシー
IAM ポリシーは
- 何に対して
- どんな操作を
- できる（できない）
ということを定義した認可用のドキュメントで、AWSリソース（EC2やRDSなど）にアクセスするための権限設定になります。
IAMユーザーや後述のIAMロールに割り当てることで、これらの認可情報を付与します。
AWSがデフォルトで用意してくれているポリシーもありますが、自作することも可能です。
| ポリシー | 作成者 | 説明 |
|---|---|---|
| AWS管理ポリシー | AWS | AWSによって事前に作成されているポリシー |
| カスタマー管理ポリシー | 利用者 | 複数のIAMユーザーやIAMグループ、IAMロール間で共有可能 |
| インラインポリシー | 利用者 | 1:1で特定のIAMユーザーやIAMグループ、IAMロールに対して適用する |
またIAMポリシーにはいくつかのアタッチ先が存在します。
| ポリシー | アタッチ先 |
|---|---|
| ユーザーベースのポリシー | IAMユーザー |
| リソースベースのポリシー | AWSリソース |
| IAMロールの信頼ポリシー | IAMロール |
IAM ロール
IAM ロールは IAMポリシーをグループ化したようなもので、IAMユーザー、IAMグループ、AWSリソース（EC2、RDSといったAWSサービス）に対して付与するものになります。
前述したIAMポリシーをまとめてグループ化したものに名前を付けて管理することができます。
例えるなら、
├── 人事部権限（IAM ロール）
│ ├── 人員管理表のアクセス権（IAM ポリシー）
│
└── 開発部権限（IAM ロール）
├── ソースコードへのアクセス権（IAM ポリシー）
└── 本番用AWS環境へのアクセス権（IAM ポリシー）
のようなイメージです。
AWSリソースへのアタッチですが、AWSリソースにはIAMポリシーを直接アタッチできるもの（S3、Lambdaなど）とできないもの（EC2、RDSなど）があります。
直接IAMポリシーをアタッチできればそれでよいのですが、できないリソースに対してはIAMロールとしてグループ化したものをアタッチすることで、リソースごとの権限を割り当てることができます。
また、IAMロールはアカウント間で共有して使用することが可能です。
ここでの詳しい説明は割愛させていただきますが、IAMロールを使うことでユーザーに対して一時的な権限を付与することもできます。
管理者が一時的に操作権限を割り当てて、完了したら権限を外して...といった面倒な作業も、STS（AWS Security Token Service）＋IAMロール の組み合わせにより、認証後の一定期間が過ぎると操作権限を無効にする、といったように自動化できるようになります。
最後に
他のAWSサービスにも言えることですが、実際に使ってみた方が覚えるのが早そうです。
【参考記事】