▪️目的
AWSを利用していると、「IAM」という言葉を頻繁に目にします。
AWSでは、EC2やS3、RDSなど、さまざまなサービスを利用します。
しかし、
- 誰がAWSを操作できるの？
- EC2からS3へアクセスするにはどうするの？
- IAMユーザーって何？
- IAMロールって何？
- IAMポリシーって何？
- 管理者権限と一般ユーザーの違いは？
- 「最小権限」ってどういう意味？
と疑問に思う方も多いのではないでしょうか。
IAMは、AWSのセキュリティを理解するうえで非常に重要なサービスです。
この記事では、AWS初心者の方向けに、IAMの基本的な仕組みからIAMユーザー、IAMロール、IAMポリシー、アクセス権限の考え方まで分かりやすく解説します。
▪️IAMとは？
IAMとは、AWS Identity and Access Managementの略です。
簡単にいうと、
AWSのリソースに対するアクセスを管理するためのサービス
です。
例えばAWSには、
- EC2
- S3
- RDS
- VPC
- Lambda
- CloudWatch
など、さまざまなサービスがあります。
IAMでは、
「誰が、どのAWSリソースに対して、何をしてよいのか」
を管理します。
例えば、
ユーザー
│
▼
IAM
│
├─ EC2を操作してよい
├─ S3を読み取ってよい
└─ RDSは操作してはいけない
といったアクセス制御を行います。
▪️AWSでは「認証」と「認可」が重要
IAMを理解するためには、認証と認可という2つの言葉を理解しておくと分かりやすいです。
♦︎認証
認証とは、
「あなたは誰ですか？」
を確認することです。
例えばAWSへログインするときに、ユーザーを識別します。
ユーザー
│
▼
ログイン
│
▼
「このユーザーは誰か？」
これが認証です。
♦︎認可
認可とは、
「あなたは何をしてよいですか？」
を決めることです。
例えば、
ユーザーA
↓
S3のファイルを読み取る → 許可
S3のファイルを削除する → 拒否
といった制御です。
つまり、
認証
↓
誰なのか？
認可
↓
何をしてよいのか？
と考えると分かりやすいでしょう。
▪️IAMユーザーとは？
IAMユーザーとは、AWS上で利用者を識別するためのユーザーです。
例えば、
IAM
│
├─ user-a
├─ user-b
└─ user-c
のようにユーザーを作成できます。
それぞれのユーザーに異なる権限を設定することもできます。
例えば、
user-a
↓
EC2の操作を許可
user-b
↓
S3の読み取りを許可
user-c
↓
管理者権限
といった形です。
ただし、現在のAWS環境では、AWS IAM Identity Centerなどを利用して人間のユーザーアクセスを管理する構成も重要です。
そのため、**「人がAWSを使う＝必ずIAMユーザーを作る」**と考えるのではなく、組織の認証・アクセス管理方式に応じて適切な仕組みを選択します。
▪️IAMグループとは？
IAMグループは、IAMユーザーをまとめて管理するための仕組みです。
例えば、
IAMグループ
│
└─ 開発者
├─ user-a
├─ user-b
└─ user-c
というようにユーザーをグループ化できます。
そしてグループにポリシーを設定することで、複数のユーザーへ同じ権限をまとめて付与できます。
例えば、
開発者グループ
↓
EC2操作権限
↓
user-a
user-b
user-c
といった管理ができます。
▪️IAMポリシーとは？
IAMを理解するうえで、非常に重要なのがIAMポリシーです。
IAMポリシーとは、
AWSリソースに対して、どのような操作を許可・拒否するかを定義したルール
です。
例えば、
S3のオブジェクトを読み取ることを許可する
というルールを作れます。
代表的なアクションとして、
s3:GetObject
があります。
これは、S3オブジェクトを取得するためのアクションです。
例えば、
IAMポリシー
│
└─ s3:GetObject
│
▼
S3オブジェクト
というイメージです。
▪️IAMポリシーの基本構造
IAMポリシーはJSON形式で記述します。
例えば、
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}
]
}
というような形です。
初心者の方は、まず以下の4つを覚えておくと分かりやすいでしょう。
Effect
↓
許可 or 拒否
Action
↓
何をするのか
Resource
↓
どのAWSリソースに対してか
Principal
↓
誰に対するルールなのか
ただし、すべてのポリシータイプに同じ要素が出てくるわけではありません。
▪️AllowとDeny
IAMポリシーでは、アクセスを許可するAllowや、明示的に拒否するDenyを定義できます。
例えば、
Allow
↓
S3の読み取りを許可
Deny
↓
S3の削除を拒否
といった設定ができます。
AWSのアクセス制御では、明示的なDenyがAllowより優先されるという重要なルールがあります。
そのため、
Allow
+
Explicit Deny
の場合は、アクセスが拒否されます。
▪️IAMロールとは？
IAMを理解するときに、もう一つ非常に重要なのがIAMロールです。
IAMロールとは、
AWSリソースやユーザーなどが、一時的な認証情報を使ってAWSリソースへアクセスするために利用する仕組み
です。
特にAWSでは、EC2やLambdaなどのAWSサービスに権限を与えるときによく利用します。
例えば、
EC2
│
▼
IAMロール
│
▼
S3
という構成です。
EC2にIAMロールを関連付けることで、
「このEC2にはS3を読み取る権限を与える」
といった設定ができます。
▪️EC2からS3へアクセスする場合
IAMロールのイメージを具体的に見てみましょう。
例えば、EC2上で動作するアプリケーションからS3のファイルを取得したいとします。
EC2
│
│ S3:GetObject
▼
S3
このとき、EC2に必要なIAMロールを関連付けます。
EC2
│
▼
IAMロール
│
└─ S3:GetObject
│
▼
S3
これによって、EC2上のアプリケーションがS3へアクセスできるようになります。
▪️なぜIAMロールを使うの？
もしIAMロールを使わず、EC2の中にAWSアクセスキーを直接保存してしまうと、
EC2
│
└─ アクセスキー
のような状態になります。
アクセスキーが漏れてしまうと、その認証情報を使ってAWSへアクセスされる危険があります。
そこで、AWSサービスから別のAWSサービスへアクセスする場合には、IAMロールを利用するのが基本的な考え方です。
EC2
│
▼
IAMロール
│
▼
S3
という形にすることで、長期的なアクセスキーをEC2へ直接埋め込まずに権限を付与できます。
▪️IAMユーザーとIAMロールの違い
ここは非常に重要です。
簡単に整理すると、
| 項目 | IAMユーザー | IAMロール |
|---|---|---|
| 主な用途 | ユーザーを識別 | 権限を引き受ける |
| 主な対象 | 人など | AWSサービス・ユーザーなど |
| 認証情報 | 長期認証情報を持てる | 一時的な認証情報を利用 |
| EC2からS3 | 基本的に適さない | よく利用される |
例えば、
人
↓
IAM Identity Centerなど
↓
AWS
EC2
↓
IAMロール
↓
S3
というように、人のアクセスとAWSサービスのアクセスでは適切な仕組みが異なります。
▪️最小権限の原則
IAMを設計するときに非常に重要なのが、最小権限の原則です。
これは簡単にいうと、
必要な権限だけを与える
という考え方です。
例えば、EC2からS3のファイルを読み取るだけなら、
必要
↓
s3:GetObject
だけで十分かもしれません。
それなのに、
S3のすべての操作を許可
してしまうと、必要以上の権限を与えることになります。
理想としては、
必要な操作
↓
必要なリソース
↓
必要なユーザー・サービス
に絞って権限を設計します。
▪️「AdministratorAccessなら全部できる」は危険
AWSでは、管理者権限を持つユーザーやロールを作ることもできます。
しかし、
とりあえず全部の権限を付ける
という設計はセキュリティ上のリスクになります。
例えば開発者が、
EC2
S3
RDS
IAM
CloudTrail
KMS
など、すべてを操作できる必要があるとは限りません。
そのため、
開発者
↓
必要なAWSサービスだけ
運用担当
↓
運用に必要な権限だけ
管理者
↓
管理に必要な権限
というように、役割に応じて権限を分けます。
▪️IAMとSecurity Groupの違い
ここまでの記事で紹介したSecurity GroupとIAMは、どちらも「アクセスを制御する仕組み」です。
そのため、初心者の方は混乱しやすいポイントです。
しかし、役割は大きく異なります。
| 項目 | IAM | Security Group |
|---|---|---|
| 主な対象 | AWS API・リソースへの操作 | ネットワーク通信 |
| 制御するもの | AWS操作の権限 | 通信 |
| 例 | S3:GetObject | TCP 443 |
| 主な用途 | 認証・認可 | ネットワークアクセス制御 |
例えば、
EC2
│
├─ IAM
│ └─ S3:GetObjectを許可
│
└─ Security Group
└─ TCP 443を許可
というように、両者は別の役割を持っています。
つまり、
IAMでAWSリソースを操作する権限を制御し、Security Groupでネットワーク通信を制御する
と考えると分かりやすいでしょう。
▪️IAMとS3を組み合わせる
前回の記事で紹介したS3もIAMと深く関係しています。
例えば、
EC2
│
▼
IAMロール
│
└─ S3:GetObject
│
▼
S3
という構成です。
このとき、
「EC2がS3へアクセスできる」
という状態を作るだけではなく、
「EC2がS3の何をできるのか？」
までIAMポリシーで制御します。
例えば、
読み取り → 許可
書き込み → 拒否
削除 → 拒否
といった設計ができます。
▪️IAMを利用したAWSのアクセス管理
AWSでは、IAMを中心にさまざまなアクセス制御を組み合わせます。
例えば、
AWS
│
┌───────┴────────┐
▼ ▼
人間 AWSサービス
│ │
▼ ▼
IAM Identity Center IAMロール
│ │
└───────┬────────┘
▼
IAMポリシー
│
▼
AWSリソースへのアクセス
というようなイメージです。
さらに、S3バケットポリシーなど、リソース側に設定するポリシーも組み合わせてアクセスを制御します。
▪️IAMを利用するときに考えること
IAMの設定では、単純に「アクセスできる・できない」だけではなく、
- 誰がアクセスするのか
- 何を操作するのか
- どのリソースを操作するのか
- どの環境からアクセスするのか
- 必要な権限は何か
- 不要な権限は何か
- 長期認証情報を持たせる必要があるか
- 最小権限になっているか
などを考えることが重要です。
特に本番環境では、
「とりあえずAdministratorAccess」
ではなく、
「この作業に本当に必要な権限は何か？」
という考え方で設計することが重要です。
▪️まとめ
今回は、AWSのIAMについて解説しました。
IAMは、AWSのリソースに対するアクセスを管理するためのサービスです。
ポイントを整理すると、
- IAMはIdentity and Access Managementの略
- AWSリソースへのアクセスを管理する
- 「誰なのか」を確認する認証と「何をしてよいか」を決める認可がある
- IAMユーザーはユーザーを識別するために利用できる
- IAMグループはユーザーをまとめて管理するために利用できる
- IAMポリシーによってアクセス権限を定義する
- IAMロールはAWSサービスなどが権限を利用するときによく使われる
- EC2からS3へアクセスする場合などにIAMロールを利用できる
- 必要な権限だけを与える「最小権限」が重要
- IAMとSecurity Groupは役割が異なる
- IAMはAWSのセキュリティ設計を理解するうえで非常に重要
特に、
IAM＝AWSリソースへの操作権限を管理
Security Group＝ネットワーク通信を制御
という違いを覚えておくと、AWSのセキュリティを理解しやすくなります。
AWSでは、EC2やS3、RDSなどのサービスを作るだけではなく、
「誰がそのサービスを操作できるのか」
「どのサービスからどのサービスへアクセスできるのか」
まで考えてシステムを設計します。
IAMは、そのアクセス制御を支えるAWSの基本的なサービスです。
次回は、AWS上の操作やAPI呼び出しなどを記録するCloudTrailについて解説します。
＊「CloudTrail」の記事はこちら
→「https://lovelabengineer.com/2026/10/08/awsのcloudtrailとは？awsの操作履歴を記録する仕組みを初心/」
No responses yet