AWS を安全に使えるかどうかは、IAM を理解しているかでほぼ決まります。にもかかわらず、IAM は「最初はよく分からないから AdministratorAccess を付けておく」で通り過ぎられがちです。そのまま実務に入ると、ポリシーの JSON が読めず、「なぜこの操作が拒否されるのか」「なぜこの鍵で何でもできてしまうのか」が説明できません。この記事は、IAM を「誰が・何に・何をしてよいか」の3つの問いに分け、ポリシーの JSON を読めるところまでを扱います。
この記事の結論
- IAM（Identity and Access Management）は、AWS で誰が（アイデンティティ）・どのリソースに・何をしてよいか（権限）を決める仕組みです。
- 「誰が」には、人が使うユーザー（とそれをまとめるグループ）と、サービスやほかのアカウントが一時的に引き受けるロールがあります。
- 「何をしてよいか」は、JSON で書くポリシーで決めます。読むのは Effect・Action・Resource の3つです。
- 評価の順番は決まっています。明示的な拒否が最優先、許可が無ければ拒否。この2行を覚えれば「なぜ拒否されるか」の大半が説明できます。
- 基本は最小権限（要る操作だけを許可する）と、人には Identity Center、サービスにはロール。ルートユーザーとアクセスキーの常用は避けます。
IAM は「誰が・何に・何をしてよいか」を決める
IAM（AWS Identity and Access Management）は、AWS アカウントの中で、誰がどのリソースにどんな操作をしてよいかを決めるサービスです。リージョンに関係なく1つの「グローバルサービス」で、料金はかかりません。
3つの問いに分けると、部品の位置が分かります。
| 問い | IAM の部品 | 例 |
|---|---|---|
| 誰が | ユーザー、グループ、ロール（アイデンティティ） | 開発者の A さん、EC2 で動くアプリ |
| 何に | リソース（ARN で指定） | S3 の特定のバケット、特定の EC2 インスタンス |
| 何をしてよいか | ポリシー（Action と Effect） | s3:GetObject を許可、ec2:TerminateInstances を拒否 |
「誰が」に「何をしてよいか」を付ける（アタッチする）と、その「誰か」はその操作ができるようになります。IAM の設定は、最終的にはこの「誰に、どのポリシーを付けたか」の一覧です。
「誰が」: ユーザー・グループ・ロールの違い
USERS VS ROLES「誰が」の2種類
人にはユーザー、人でないものにはロール
ユーザーとグループ
人（または人が使う道具）のため
- 長期の認証情報を持つパスワード・アクセスキー。漏れると事故
- グループでまとめて権限を付ける1人ずつポリシーを付けない
- 日常の作業には Identity Center を推奨一時的な認証情報で動く
ロール
サービスや別アカウントが一時的に引き受ける
- 長期の鍵を持たない引き受けた間だけ短命の認証情報
- EC2・Lambda が AWS の API を呼ぶときに使う鍵をコードに書かずに済む
- 別アカウントからの操作もロールクロスアカウントアクセス
- ユーザーは、人（または人が使う道具）のためのアイデンティティです。パスワードでコンソールにログインし、アクセスキーで CLI や SDK から API を呼びます。長期の認証情報を持つのが特徴で、それが漏れると事故になります。
- グループは、ユーザーの束です。「開発者グループ」にポリシーを付けておけば、新しい開発者はグループに入れるだけで同じ権限になります。ポリシーをユーザー1人ずつに付けない。
- ロールは、「一時的に引き受ける権限の束」です。ユーザーと違って長期の認証情報を持たず、引き受けた（AssumeRole した）間だけ、短い有効期限の一時的な認証情報が発行されます。EC2 で動くアプリが S3 にファイルを置くとき、Lambda が DynamoDB を読むとき、別のアカウントの人がこのアカウントを操作するとき。「人ではないもの」と「一時的な引き受け」はロールと覚えると位置づけが掴めます。
AWS は、人が日常の作業で使う認証には IAM ユーザーではなく IAM Identity Center（旧 AWS SSO）を勧めています。理由は、Identity Center のユーザーも一時的な認証情報で動くので、長期のアクセスキーを人に配らずに済むからです。学習用の1人のアカウントなら IAM ユーザーでも構いませんが、「アクセスキーを作って手元に置く」ことの危険は最初から知っておいてください。
CHECK 1ここまでの確認
EC2 で動くアプリが S3 にファイルを置くとき、使うべきなのはどれ?
答えと解説
答え: 3. EC2 に付けた IAM ロール
「人ではないもの」と「一時的な引き受け」はロールです。ロールは長期の鍵を持たないので、鍵をコードに書く事故がなくなります。
「何をしてよいか」: ポリシーの JSON を読む
ポリシーは、権限を JSON で書いたものです。読む練習に、1つ見ます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"]
}
]
}
読む順番は3つです。
- Effect —
Allow（許可）かDeny（拒否）か。 - Action — どの操作か。
サービス名:操作名の形で、s3:GetObjectは「S3 からオブジェクトを取る」。*はワイルドカードで、s3:*なら S3 の全操作。 - Resource — どのリソースに対してか。ARN（Amazon Resource Name）で指定します。
arn:aws:s3:::my-bucket/*は「my-bucket の中の全オブジェクト」。
上のポリシーは、「my-bucket の一覧を見て、中のオブジェクトを取ってよい。それ以外は書いていないので、できない」という意味です。
この3つの組を Statement と呼び、ポリシーは Statement の並びです。Condition（条件。「この IP アドレスからだけ」「MFA を通していれば」など）は4つ目の要素ですが、3つが読めるようになってからで足ります。
READ A POLICYポリシーを読む3つ
Effect → Action → Resource の順に読めば、ポリシーは読める
-
Effect
許可か、拒否か
Allow / Deny
-
Action
どの操作か
s3:GetObject。* はワイルドカード
-
Resource
どのリソースに対してか
ARN で指定。arn:aws:s3:::my-bucket/*
ポリシーには、AWS があらかじめ用意した管理ポリシー（AdministratorAccess、ReadOnlyAccess など）と、自分で書くカスタマーマネージドポリシーがあります。学習の最初は管理ポリシーを使い、「何が許可されているか」を JSON で読む習慣を付けると、自分で書くときに困りません。
評価の順番: 明示的な拒否が最優先、許可が無ければ拒否
「なぜこの操作が拒否されるのか」を説明できるかどうかは、評価の順番を知っているかで決まります。IAM は、リクエストが来るたびに、関係する全ポリシーを見て次の順で判断します。
ポリシーの評価の順番（単一アカウントの基本形）
- 既定は拒否。 何も書かれていなければ、できない（暗黙の拒否）
- 明示的な Deny があれば、必ず拒否。 どこかに
Effect: Denyが当たれば、ほかにAllowがあっても拒否 - 明示的な Allow があれば、許可。 Deny が無く、どこかの
Allowが当たれば許可 - 組織のポリシー（SCP）、権限境界、セッションポリシーがある場合はさらに絞られる（段4の話）
この順番から、2つの実務上の性質が出てきます。
EVALUATION ORDER評価の順番
明示的な拒否が最優先、許可が無ければ拒否
-
既定は拒否
何も書かれていなければ、できない（暗黙の拒否）
-
明示的な Deny があれば拒否
ほかに Allow があっても拒否
-
明示的な Allow があれば許可
Deny が無く、Allow が当たれば許可
- 「できない」の原因は、たいてい「Allow が無い」か「どこかに Deny がある」のどちらかです。前者はポリシーを足し、後者は Deny を探します。
- 「決してさせたくない操作」は、Allow を消すのではなく Deny を書きます。Allow はあとから誰かが足せますが、Deny は明示的に消さない限り効き続けるからです。
DENY WINS門で見る評価の順番
Deny は必ず止め、Allow が無ければ黙って止める
IAM の評価
- Deny明示的な拒否が当たる 止まるほかに Allow があっても
- Allow明示的な許可が当たる 通るDeny が無ければ
- なし何も書かれていない 止まる暗黙の拒否
CHECK 2ここまでの確認
ポリシーの JSON で、最初に読む3つはどれ?
答えと解説
答え: 2. Effect・Action・Resource
Effect（許可か拒否か）・Action（どの操作か）・Resource（どのリソースに）の3つが1つの Statement です。Condition は3つが読めるようになってからで足ります。
最小権限と、やってはいけない3つ
IAM の設計の基本は最小権限です。要る操作だけを、要るリソースに対して、要る期間だけ許可する。「とりあえず全部許可」は、鍵が漏れたときの被害を全部に広げます。
IAM でやってはいけない3つ
- ルートユーザーを日常の作業に使う。 ルートユーザーは IAM の外にいて、ポリシーで縛れない。MFA を付けて金庫にしまう（AWS とは何か）
- アクセスキーをコードやリポジトリに書く。 GitHub に上がった鍵は数分で拾われる。EC2 や Lambda にはロールを付けて、鍵そのものを持たない
*の Action と*の Resource を、理由なく組み合わせる。AdministratorAccessを付けるなら、それが「何でもできる鍵」だと分かったうえで、期間と持ち主を限定する
最小権限は「最初から完璧に絞る」ことではありません。まず狭く付けて、拒否されたら理由（Allow が無い）を確かめて足す。この往復が、ポリシーを読む練習そのものになります。
CHECK 3ここまでの確認
ある操作に Allow と Deny の両方が当たった。結果はどれ?
答えと解説
答え: 2. 拒否される（明示的な Deny が最優先）
評価の順番は「既定は拒否、明示的な Deny があれば必ず拒否、Deny が無く Allow があれば許可」です。「絶対にさせたくない操作」は Deny で書きます。
まとめ
IAM は、誰が・何に・何をしてよいかを決める仕組みです。「誰が」はユーザー・グループ・ロールで、人には Identity Center、サービスにはロール。「何をしてよいか」は JSON のポリシーで、Effect・Action・Resource の3つを読みます。評価は「明示的な拒否が最優先、許可が無ければ拒否」。基本は最小権限で、ルートユーザーの常用・鍵のコード埋め込み・理由の無い * を避けます。次はVPC とは何かで、権限の次に「ネットワークの境界」を扱います。
参照ソース
- IAM とは（AWS IAM ユーザーガイド） — IAM の定義、ユーザー・グループ・ロール・ポリシーの位置づけの根拠。2026年9月時点の記載
- ポリシーの評価論理（AWS IAM ユーザーガイド） — 「既定は拒否・明示的な Deny が最優先・Allow で許可」の評価の順番の根拠
- IAM でのセキュリティのベストプラクティス（AWS IAM ユーザーガイド） — 人には Identity Center、サービスにはロール、最小権限、ルートユーザーとアクセスキーの常用を避けることの根拠
- IAM JSON ポリシーの要素（AWS IAM ユーザーガイド） — Effect・Action・Resource・Condition の各要素の意味の根拠
