🔐【初心者向け】AWS IAMをやさしく解説

AWSを勉強し始めると、かなり早い段階で登場するのが IAM（Identity and Access Management） です。

ところがIAMを学び始めると、

• IAMユーザーって何？
• IAMグループは何のためにある？
• IAMロールとIAMユーザーは何が違う？
• ポリシーって結局何を書いているの？
• AllowとDenyが両方あったらどうなる？

と、一気に登場人物が増えます。

ですが、IAMの本質は意外とシンプルです。

「誰が」「何に対して」「何をしてよいのか」をAWS上で管理する仕組み と考えると、全体像が見えやすくなります。

この記事ではまずIAMを初心者向けに整理し、その後、 AWS内部で権限がどのように判定されるのかまで一歩深く見ていきます。

---

✅ 結論

IAMについて、まず押さえておきたいポイントはこちらです。

• IAMはAWSへのアクセスを管理する仕組み
• IAMユーザーは、AWS上に作成する個別のID
• IAMグループは、複数のIAMユーザーをまとめる仕組み
• IAMロールは、必要なときに引き受ける権限のまとまり
• IAMポリシーは、「何を許可・拒否するか」を記述したルール
• AWSのアクセスは基本的に最初は許可されていない
• 明示的なDeny（拒否）はAllow（許可）より強い

まずはこの関係を頭に置いて、順番に見ていきましょう。

---

🌱 IAMとは何か？

IAMは、 Identity and Access Management の略です。

日本語にすると、 「IDとアクセスの管理」 といった意味になります。

たとえばAWSの中に、次のようなサービスがあるとします。

Amazon EC2
Amazon S3
Amazon RDS
AWS Lambda

ここで、 「AWSへログインできる人なら何でも操作できる」 という状態では危険ですよね。

そこでIAMを使って、

田中さん
  ↓
EC2は操作してよい
S3は閲覧してよい
RDSは操作してはいけない

あるいは、

アプリケーション
  ↓
特定のS3バケットだけ読み取り可能

というようにアクセスを制御します。

つまりIAMは、 AWSという建物の「入館証＋鍵＋利用ルール」を管理する仕組み と考えるとイメージしやすいです。

---

👤 IAMユーザーとは？

IAMユーザーは、 AWSアカウントの中に作成する個別のID です。

イメージすると、

AWSアカウント
  │
  ├─ IAM User：Tanaka
  ├─ IAM User：Suzuki
  └─ IAM User：Sato

という関係です。

それぞれのIAMユーザーに対して、 異なるアクセス許可を設定できます。

たとえば、

Tanaka
  ↓
EC2を操作可能
Suzuki
  ↓
S3を閲覧可能

という設定もできます。

IAMユーザー = 人、とは限らない

ここで一つ注意があります。

IAMユーザーは歴史的に、 人間やアプリケーションなどに対して利用されてきました。

しかし現在のAWSでは、 人間の利用者については可能な限り 一時的な認証情報を使う方法 が推奨されています。

つまり、

人がAWSを使う
   ↓
必ずIAMユーザーを作る

という理解ではありません。

IAMを学ぶ上ではIAMユーザーの仕組みを理解することは重要ですが、 実際のシステム設計ではIAM Identity Centerやフェデレーション、 IAMロールなどを使う構成も重要になります。

---

👥 IAMグループとは？

IAMグループは、 複数のIAMユーザーをまとめて管理する仕組み です。

たとえば開発チームに10人いたとします。

Developer Group
  │
  ├─ Tanaka
  ├─ Suzuki
  ├─ Sato
  └─ ...

10人それぞれに同じ権限を設定するのは大変です。

そこで、 Developerというグループに権限を設定 します。

Developer Group
      │
      └─ EC2操作可能
             │
      ┌──────┼──────┐
      ↓      ↓      ↓
   Tanaka Suzuki  Sato

ユーザーをグループへ追加すれば、 グループに設定されたアクセス許可を利用できるようになります。

IAMグループ自体がAWSを操作するわけではない

ここは初心者が混乱しやすいポイントです。

IAMグループは、 ユーザーをまとめて権限管理しやすくするための箱 です。

グループそのものがAWSへログインしたり、 EC2を起動したりするわけではありません。

---

🎭 IAMロールとは？

IAMで特に理解しづらいのが、 IAMロール です。

IAMロールを一言で表すなら、

必要なときに引き受けて使う「権限のセット」

です。

たとえばEC2上で動いているアプリケーションが、 S3のファイルを読み取りたいとします。

EC2
 ↓
S3を読みたい

このときEC2にIAMロールを関連付けることで、 必要な権限を与えることができます。

EC2
 ↓
IAM Role
 ↓
S3 Read
 ↓
Amazon S3

IAMユーザーに長期間使用する認証情報を持たせ、 それをEC2の中へ保存するような設計よりも、 IAMロールを利用して一時的な認証情報を利用する方が安全です。

---

🤔 IAMユーザーとIAMロールは何が違う？

初心者のうちは、まず次のように整理すると分かりやすいです。

項目	IAMユーザー	IAMロール
イメージ	個別のID	引き受ける権限
長期認証情報	持つことができる	通常は持たない
利用方法	ユーザーとして利用	Assume（引き受け）して利用
代表的な用途	個別IDとしてのアクセス	AWSサービス・一時的アクセス・別アカウントアクセスなど

特に覚えておきたいのは、 IAMロールには通常、固定されたパスワードやアクセスキーを持たせない という点です。

ロールを引き受けることで、 一定期間だけ利用できる一時的な認証情報を取得します。

---

📜 IAMポリシーとは？

IAMユーザーやIAMロールそのものには、 「EC2を操作してよい」 といったルールが最初から書かれているわけではありません。

そこで登場するのが、 IAMポリシー です。

IAMポリシーには、

どの操作を許可するのか、あるいは拒否するのか

を記述します。

IAMポリシーはJSON形式で記述されます。

簡略化した例を見てみましょう。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

初めて見ると少し怖そうですが、 重要なのは主に次の部分です。

Effect

許可するのか、拒否するのか を指定します。

"Effect": "Allow"

なら許可です。

"Effect": "Deny"

なら拒否です。

Action

何の操作を対象にするか を指定します。

"Action": "s3:GetObject"

なら、 S3オブジェクトを取得する操作が対象です。

Resource

どのAWSリソースを対象にするか を指定します。

"Resource": "arn:aws:s3:::example-bucket/*"

この例では、 指定したS3バケット内のオブジェクトが対象になります。

ざっくり日本語へ置き換えると、

Effect
 ↓
許可する
Action
 ↓
S3からファイルを取得する
Resource
 ↓
example-bucketの中

というルールです。

---

🧩 IAM全体の関係を整理しよう

ここまで登場したものを一度つなげてみましょう。

IAM User
   │
   ├─ IAM Group
   │      │
   │      └─ Policy
   │
   └──────── Policy
EC2など
   │
   ↓
IAM Role
   │
   ↓
Policy
   │
   ↓
AWS Resource

大切なのは、 「誰・何がアクセスするのか」と「何を許可するのか」を分けて考えること です。

IAMユーザーやIAMロールはアクセスする主体側、 IAMポリシーはアクセス許可のルール、 というイメージを持つと整理しやすくなります。

---

👑 rootユーザーとの違い

AWSアカウントを作成したときに最初に存在する特別なユーザーが、 rootユーザー です。

rootユーザーは非常に強い権限を持っています。

そのため、普段のAWS操作にrootユーザーを使うのは避けます。

root user
   ↓
アカウント管理など
本当に必要な場面だけ
普段の作業
   ↓
適切な権限を持つID・Role

またrootユーザーにはMFAを設定し、 認証情報を適切に保護することが重要です。

---

🔑 最小権限の原則

IAMを理解する上で非常に重要なのが、 最小権限の原則 です。

これは、

必要な操作に必要な権限だけを与える

という考え方です。

たとえば、 S3のファイルを読むだけのアプリケーションに、 AWS全体の管理者権限を与える必要はありません。

必要な権限
S3 Read
   ↓
○
AdministratorAccess
   ↓
権限が大きすぎる

権限が大きければ設定は楽になる場合があります。

しかし、 認証情報が漏えいしたり、 アプリケーションが侵害されたりした場合の被害も大きくなります。

IAMでは、 必要な範囲まで権限を絞る ことが基本になります。

---

☕ ここまでのまとめ

初心者向け部分を一度整理しましょう。

IAM

AWS上で「誰が何をしてよいのか」を管理する仕組み。

IAMユーザー

AWSアカウント内に作成する個別のID。

IAMグループ

複数のIAMユーザーをまとめて権限管理するための仕組み。

IAMロール

必要なときに引き受けて使用する権限のまとまり。

IAMポリシー

どのAWS操作を許可・拒否するかを定義したルール。

最小権限

必要な操作だけ許可する、IAMにおける重要な考え方。

まずはここまで理解できれば、 IAMの基本的な全体像はつかめています。

---

🔬【後半：ニッチ・深掘り編】

ここからは、 IAMが実際にどのようにアクセス可否を判断しているのか を少し深掘りしていきます。

---

🚦 IAMは「許可リスト」を上から順番に見るだけではない

IAMポリシーについて、

Allowがあれば許可
Denyがあれば拒否

とだけ覚えてしまうと、 実際のAWSで混乱することがあります。

IAMの権限評価では、まず基本として アクセスは暗黙的に拒否された状態 から始まります。

最初
 ↓
Implicit Deny
（暗黙的な拒否）

つまり、 「禁止と書かれていないから使える」 わけではありません。

必要なアクセス許可が存在して、 初めて操作が許可されます。

---

Allowがあれば必ず許可される？

答えは、 必ずしもそうではありません。

IAMでは明示的なDenyが非常に強く扱われます。

基本イメージは、

Implicit Deny
     ↓
Allowがある
     ↓
許可候補
     ↓
Explicit Denyがある？
   ↓       ↓
  YES      NO
   ↓       ↓
拒否      許可

です。

たとえば、

Policy A
Allow：S3すべて
Policy B
Deny：特定Bucket

という状態なら、 Policy Aで許可されていても、 Policy Bによる明示的なDenyの対象については拒否されます。

つまり、

Explicit Deny（明示的な拒否）はAllowより優先される

という点が非常に重要です。

---

🧠 「権限があるはずなのにAccessDenied」になる理由

AWSを触っていると、

AccessDenied

に遭遇することがあります。

そしてIAMポリシーを見ると、 ちゃんとAllowが設定されている。

それでも拒否されることがあります。

なぜならAWSの権限には、 IAMユーザーやIAMロールへ直接設定したポリシー以外にも 複数の制御が存在するからです。

たとえば、

• Identity-based policy
• Resource-based policy
• Permissions boundary
• Session policy
• AWS Organizations SCP
• AWS Organizations RCP

などがあります。

そのため実際の権限は、 単純に

IAM Policy
 ↓
AllowだからOK

では決まりません。

複数のポリシーや制限を組み合わせて、 最終的な有効権限 が決定されます。

---

📦 Identity-based policyとResource-based policy

IAMでよく登場するのが、 Identity-based policy と Resource-based policy です。

Identity-based policy

IAMユーザーやIAMロールなど、 アクセスする側 に設定するポリシーです。

IAM Role
   │
   └─ S3を読んでよい

Resource-based policy

S3バケットなど、 アクセスされるリソース側 に設定するポリシーです。

S3 Bucket
   │
   └─ このPrincipalからの
      アクセスを許可

同じ「アクセス許可」でも、 どちら側から定義しているか が違います。

S3のBucket Policyなどを学ぶと、 この違いが特に重要になってきます。

---

🪪 Roleの正体は「一時的に別の権限を借りる」仕組み

IAMロールをもう少し深く見ると、 重要なのが AssumeRole という考え方です。

利用者やAWSサービスがロールを引き受けると、 AWS Security Token Service（STS）などを通じて 一時的なセキュリティ認証情報を利用します。

利用者 / AWS Service
        ↓
   Assume Role
        ↓
     IAM Role
        ↓
一時的なCredentials
        ↓
   AWS Resource

そのためIAMロールは、

「ユーザーの別名」

というより、

一時的に利用できる権限セット

として理解する方が本質に近くなります。

---

🪤 IAMの落とし穴

① とりあえずAdministratorAccessを付ける

学習中やトラブル対応中に、 権限エラーを解消するため、

AdministratorAccess

を付けたくなることがあります。

確かに問題が解決することはあります。

しかし、それでは 本来どの権限が不足していたのか分からなくなります。

本番環境では特に、 必要なActionやResourceを確認して 最小権限へ近づけることが重要です。

② Access Keyをソースコードへ書く

たとえば、

ACCESS_KEY=...
SECRET_KEY=...

のような長期認証情報を ソースコードへ直接書く設計は避けるべきです。

Gitリポジトリへの誤公開などによって、 認証情報が漏えいする危険があります。

EC2やLambdaなどAWSサービスからAWSリソースへアクセスする場合は、 IAMロールなどを利用して 長期的な認証情報を埋め込まない設計を検討します。

③ rootユーザーを普段使いする

rootユーザーは非常に強力です。

普段の作業で使用せず、 rootユーザーでなければ実行できない作業など、 必要な場合に限定します。

またMFAを設定し、 rootユーザーの認証情報自体を厳重に管理する必要があります。

④ 「Allowがあるから使える」と思い込む

IAMでは複数のポリシータイプが権限評価に関係します。

そのため、 IAMポリシーにAllowがあるだけで 必ずアクセスできるとは限りません。

AccessDeniedを調査するときは、

• Identity-based policy
• Resource-based policy
• Permissions boundary
• SCP
• Session policy
• 明示的なDeny

なども含めて考える必要があります。

---

📝 この記事のまとめ

AWS IAMは、 AWSへのアクセスを制御する中心的な仕組み です。

初心者のうちは、まず次の関係を理解しておきましょう。

誰・何がアクセスする？
       ↓
IAM User / IAM Role
何をしてよい？
       ↓
IAM Policy
ユーザーをまとめたい
       ↓
IAM Group
実際のAWS Resource
       ↓
EC2 / S3 / RDS / Lambda ...

そしてIAMのアクセス許可は、

デフォルト
   ↓
暗黙的に拒否
必要なAllow
   ↓
許可
Explicit Deny
   ↓
Allowがあっても拒否

という基本的な考え方で評価されます。

IAMはAWSの中でも、 ほぼすべてのサービスに関係してくる重要な分野です。

EC2、S3、Lambdaなどを勉強するときも、 「そのサービスを誰が操作できるのか？」 という部分にはIAMが登場します。

---

🌙 ニッチ後書き

IAMを学び始めたときは、 User、Group、Role、Policyを それぞれ別々に暗記しがちです。

ですが、少し視点を変えると整理しやすくなります。

Principal
「誰が？」
Permission
「何をしてよい？」
Resource
「何に対して？」
Condition
「どんな条件なら？」

IAMは結局、 このアクセス要求を許可してよいのか？ を判断する仕組みです。

そしてAWS内部では、 人間がコンソールのボタンを押した場合でも、 アプリケーションがAPIを呼び出した場合でも、 最終的には

誰が
 ↓
何に対して
 ↓
どんな操作を要求し
 ↓
その操作が許可されているか

という世界に落ちていきます。

この感覚を持ってIAMを見ると、 単なる「AWSのユーザー管理機能」ではなく、 AWS全体を守っている巨大な権限判定システム として見えてきます。

IAMを理解することは、 AWSのサービスを一つ覚えるというより、 AWS全体の「鍵の仕組み」を理解すること に近いのです。🔑