AWS CLF(Cloud Practitioner)対策
IAMのきほん
このレッスンを終えると、AWS Identity and Access Management（通称 IAM）のユーザー・グループ・ロール・ポリシーの4つを区別し、問題文の要件からどれを使うべきかを選べるようになります。
自分でサーバーを1台建てるなら
Linux サーバーを自分で建てたとき、権限まわりで何をしたか思い出してください。作業する人ごとに useradd でアカウントを作り、共通の権限をまとめるために group を作り、パーミッションや sudoers で「誰が何をしてよいか」を書きました。IAM はこれとほぼ同じ発想を、AWS のアカウント全体に広げたものです。違いは2つあります。サーバー1台ではなくアカウント全体が対象であること、そして人だけでなくプログラムにも身分を与えられることです。
4つの登場人物
| 名前 | 何者か | 使いどころ |
|---|---|---|
| ユーザー | 人やアプリに固定で紐づく身分 | 個人が AWS を操作するとき |
| グループ | ユーザーを束ねる入れ物 | 「開発チームには読み取りだけ」のような一括付与 |
| ロール | 一時的に借りる身分 | EC2 やアプリ、他アカウントに権限を渡すとき |
| ポリシー | 許可・拒否を書いた JSON の文書 | 上の3つに貼り付けて権限を与える |
権限はポリシーだけが持ちます。ユーザー・グループ・ロールは、ポリシーを貼る先という関係です。グループに権限があるのではなく、グループに貼ったポリシーが所属ユーザーに効く、という順序で覚えると混乱しません。
ロールがこのコースの山場
初学者がいちばんつまずくのがロールです。ユーザーとの違いは認証情報を永続的に持たないことにあります。ロールは必要なときに引き受け（AssumeRole）、一時的な認証情報を受け取り、時間が来ると失効します。
たとえば EC2 上のアプリから Amazon Simple Storage Service（通称 S3）にファイルを置きたいとします。やってはいけないのは、IAM ユーザーのアクセスキーをサーバーの設定ファイルに書き込むことです。キーは漏れますし、失効もしません。正しいのは EC2 インスタンスに IAM ロールを割り当てることです。こうするとキーを一切書かずに済み、権限の変更もロール側で完結します。「アクセスキーをコードに埋め込みたくない」という文が出たら、答えはほぼロールです。
ポリシーの読み方
ポリシーは Effect（Allow か Deny）、Action（どの操作か）、Resource（どの対象か）の3点セットです。判定の規則は2つだけ覚えれば足ります。
- 何も書かれていなければ拒否（暗黙的な拒否）
- 明示的な Deny は、どんな Allow よりも強い
また、権限は必要最小限だけ与えるのが原則です。これを最小権限の原則と呼び、CLF でも Well-Architected の文脈でも繰り返し出ます。
試験ではこう出る
- 「EC2 上のアプリケーションから S3 にアクセスさせたい。認証情報をコードに保存せずに」→ IAM ロール。IAM ユーザーとアクセスキーは誤答の定番です
- 「新入社員10人に同じ権限を与えたい。管理の手間を減らしたい」→ グループにポリシーを貼り、ユーザーを所属させる
- 「別の AWS アカウントから自社のリソースを一時的に操作させたい」→ ロール（クロスアカウントアクセス）
- 「IAM の利用に追加料金はかかるか」→ かからない。IAM そのものは無料です
- 「IAM はグローバルか、リージョンごとか」→ グローバル。リージョンを選んで作るものではありません
- Allow と Deny が両方当たる状況を作って「結果はどうなるか」と聞く問題もあります。答えは常に Deny が勝つです
まとめ
- 権限を持つのはポリシー。ユーザー・グループ・ロールはポリシーを貼る先
- グループは人をまとめる仕組み。ログインする身分ではない
- ロールは一時的に借りる身分で、アクセスキーを持たせたくない場面の答え
- 判定は「書いていなければ拒否」「明示的な Deny が最優先」
- IAM は無料でグローバル。最小権限の原則で設計する
復習ミニクイズ
EC2 インスタンス上で動くアプリケーションから Amazon S3 のバケットにファイルをアップロードさせたいと考えています。認証情報をアプリケーションのコードや設定ファイルに保存したくありません。最も適切な方法はどれですか。