AWSの勉強を始めて最初に出会う高い壁、それがIAM（Identity and Access Management）です。
私も最初は「IAM …. えっ、アイアム？ 私は…何？」と名前からして戸惑いました。とりあえずルートユーザー（最初に作った最強アカウント）で何でも進めようとしていたのですが、教材を読むたびに「ルートユーザーを日常使いするのは、家の鍵を挿しっぱなしで出かけるのと同じくらい危険」という警告が出てきて、慌てて手を止めたのを覚えています。
今回は、CLF（クラウドプラクティショナー）試験合格を目指して奮闘中の私が、混乱しがちなIAMの正体を自分なりに整理してみました。図解も交えながら、つまずいたポイントも包み隠さずお伝えします。
1. そもそもIAMって何のためにあるの？
結論から言うと、「誰が、どのリソースを触っていいか」を決める門番です。
AWSはインターネット上にあるので、誰でもどこからでもアクセスできてしまいます。だからこそ、「適切な人に、適切な分だけ」権限を渡すことが命より大事（大げさではなく！）なんです。
IAMがないと起こる恐ろしいこと
私がAWSで起こった事件について調べていると、ある会社では退職者のアカウントが削除されず、数ヶ月後に不正アクセスされたケースがあったそうです。また、開発者が誤って本番環境のデータベースを削除してしまった事故も…。
こんな事態を防ぐために、IAMは以下を実現します。
- 個人ごとのアカウント管理で「誰が何をしたか」を追跡
- 最小限の権限付与でミスや不正のリスクを低減
- 監査ログでコンプライアンス対応
IAMは無料で使える！
嬉しいことに、IAM自体の利用に料金はかかりません。ユーザーを何人作っても、ポリシーをいくつ設定しても完全無料です。（もちろん、そのユーザーが作ったEC2やS3などのリソースには料金がかかりますが）
graph TD
A[AWSアカウント作成] -->|最初の状態| B[ルートユーザーのみ<br/>全権限保持]
B -->|危険な状態!| C[誰でも何でもできる]
B -->|IAMで保護| D[IAM管理者ユーザー作成]
D --> E[役割ごとにユーザー分離]
E --> F[最小権限の原則<br/>安全な運用]
style B fill:#ffe1e1
style C fill:#ff0000,color:#fff
style F fill:#e1ffe12. 混乱の元「4つの要素」を自分流に翻訳してみた
IAMを勉強していると「ユーザー」「グループ」「ロール」「ポリシー」という4つが出てきます。これが試験でもややこしい。私はこんなふうに脳内変換して納得しました。
graph TD
A[IAMの4大要素] --> B[IAMユーザー<br/>個人の社員証]
A --> C[IAMグループ<br/>部署]
A --> D[IAMロール<br/>変身ベルト]
A --> E[IAMポリシー<br/>権限の指示書]
B -.例.-> B1[山田太郎さん用ID]
C -.例.-> C1[開発チーム<br/>経理チーム]
D -.例.-> D1[EC2がS3にアクセス]
E -.例.-> E1[S3読み取り許可書]
style B fill:#e1f5ff
style C fill:#ffe1f5
style D fill:#fff4e1
style E fill:#e1ffe1① IAMユーザー ＝ 「個人の社員証」
これは分かりやすいです。私専用のログインID。一人一つ持つのが鉄則です。
つまずきポイント: 「チームで共有すれば楽じゃん」と思いがちですが、誰がミスしたか分からなくなるので絶対NGです。会社で社員証を使い回さないのと同じ理由ですね。
Tips:
IAMユーザーには2種類のアクセス方法があります。
- コンソールアクセス: ブラウザでログインするときのパスワード
- プログラムアクセス: コードやCLIで使うアクセスキー
② IAMグループ ＝ 「部署」
「開発チーム」「経理チーム」といった箱です。個々の社員にいちいち「君はS3を見ていいよ」と設定するのは面倒なので、部署（グループ）に権限をつけて、そこに社員（ユーザー）を所属させます。ちなみにグループの中にグループを入れる（入れ子）はできません。意外と不便ですが、試験に出る重要ポイントです。
graph LR
A[開発チーム] --> B[山田太郎]
A --> C[鈴木一郎]
A --> D[田中美咲]
E[管理チーム] --> F[佐藤花子]
B -.複数所属可能!.-> E
A -.付与.-> G[EC2/S3<br/>アクセス権限]
E -.付与.-> H[全サービス<br/>管理権限]
style A fill:#e1f5ff
style E fill:#ffe1e1一人が複数のグループに所属できる！
これも最初は知らなかったのですが、山田さんが「開発チーム」と「管理チーム」の両方に所属することも可能です。その場合、両方のグループの権限を合わせたものが適用されます。
③ IAMポリシー ＝ 「権限の指示書（JSON）」
「何をしてもいいか」が書かれた紙です。
覚え方: 「Effect（許可/拒否）」「Action（何をする）」「Resource（どこで）」という3要素だけ見ればOK。ラブレターや禁止命令を出すときの定型文だと思えば怖くありません。
実際のポリシー例は後ほど詳しく見ていきます。
④ IAMロール ＝ 「変身ベルト」
これが一番のクセモノでした。ユーザーではない「誰か」や「サービス」が、一時的に特定の力を借りる仕組みです。
例えば、EC2という仮想サーバーがS3（ストレージ）にデータを置きたいとき。EC2に「S3操作用ベルト」をガチャンと装着させるイメージです。パスワードを直接持たないので、万が一サーバーが乗っ取られても被害を抑えられる…という賢い仕組みなんです。
sequenceDiagram
participant EC2 as EC2インスタンス
participant Role as IAMロール
participant STS as AWS STS<br/>(一時認証発行)
participant S3 as S3バケット
EC2->>Role: ロールを引き受ける
Role->>STS: 一時認証情報をください
STS->>EC2: 一時トークン発行<br/>(有効期限付き)
EC2->>S3: トークンでアクセス
S3->>EC2: データ取得OK
Note over EC2,S3: パスワード不要で安全！ユーザーとロールの使い分け
最初はこの違いが本当に分からなかったのですが、こう整理しました。
- 人間がログインする → IAMユーザーを使う
- AWSサービス同士がやり取りする → IAMロールを使う
例えば、LambdaがDynamoDBにデータを書き込む場合、Lambdaにロールを付けます。人間が直接Lambdaにログインするわけではないですからね。
3. IAMポリシーの正体
ポリシーはJSON形式で書かれています。
基本的なポリシーの構造
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}これを日本語に翻訳すると…
「my-bucketの中のファイルを取得すること（GetObject）を許可（Allow）します」
たったこれだけです！
ポリシーを構成する全要素
実は、ポリシーにはもっと色々な要素があります。全部を使うことは少ないですが、試験では出題されるので押さえておきましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ReadFromSpecificIP",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/yamada"
},
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}各要素の詳しい説明
| 要素 | 必須？ | 意味 | 私の覚え方 |
|---|---|---|---|
| Version | ◎ 必須 | ポリシー言語のバージョン | 「2012-10-17」って書いとけばOK |
| Statement | ◎ 必須 | 権限の定義（配列で複数指定可） | メインの本文 |
| Sid | ○ 任意 | ステートメントID（メモ用） | 自分用のラベル、なくてもOK |
| Effect | ◎ 必須 | 許可か拒否か | Allow = ○、Deny = × |
| Principal | △ 場合による | 誰に対して適用するか | リソースベースポリシーで使用 |
| Action | ◎ 必須 | 何をするか | s3:GetObject = S3から取得 |
| Resource | ◎ 必須 | どこで | ARN形式のリソース名 |
| Condition | ○ 任意 | 条件付きで許可/拒否 | 「もし〜なら」の条件 |
Principalって何？誰に適用するの？
Principalは「誰が」を指定する要素です。 ただし、使う場面が限定的なので最初は混乱しました。
使い分けのルール:
- アイデンティティベースポリシー（ユーザーやグループに付ける）→ Principalは不要
- なぜなら、すでに「このユーザーに適用する」と決まっているから
- リソースベースポリシー**（S3バケットなどリソースに付ける）→ Principalが必要
- 「このバケットに、誰がアクセスできるか」を定義するため
graph TD
A[IAMポリシーの種類] --> B[アイデンティティベース<br/>ユーザー/グループ/ロールに付与]
A --> C[リソースベース<br/>S3/SQSなどに付与]
B --> B1[Principal不要<br/>すでに対象が明確]
C --> C1[Principal必須<br/>誰がアクセスできるか指定]
B -.例.-> B2["yamada.taroユーザーに<br/>「S3を読める」権限を付与"]
C -.例.-> C2["my-bucketに<br/>「yamadaさんが読める」設定"]
style B fill:#e1f5ff
style C fill:#ffe1f5Principal指定の具体例：
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/yamada"
}→ yamadaさんだけ
"Principal": {
"AWS": "*"
}→ 全員（パブリックアクセス、危険！）
"Principal": {
"Service": "ec2.amazonaws.com"
}→ EC2サービス（ロールで使用）
Conditionで条件を付ける
Conditionは「〜の場合のみ」という条件を追加する要素です。セキュリティを強化したいときに便利です。
よく使う条件の例:
① 特定のIPアドレスからのみアクセス許可
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}→ 会社のオフィスからのみアクセス可能にする
② MFAが有効な場合のみ許可
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}→ MFA設定していないとアクセス不可
③ 特定の時間帯のみアクセス許可
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2026-01-01T00:00:00Z"
},
"DateLessThan": {
"aws:CurrentTime": "2026-12-31T23:59:59Z"
}
}→ 2026年の間だけ有効
ARNって何？
Amazon Resource Nameの略で、AWSリソースの住所みたいなものです。arn:aws:s3:::my-bucketは「AWSのS3サービスにあるmy-bucketというバケット」を指します。最初は長くて覚えられませんでしたが、パターンさえ分かれば読めるようになります。
ARNの基本構造:
arn:aws:サービス名:リージョン:アカウントID:リソース例:
arn:aws:s3:::my-bucket→ S3バケット（リージョン・アカウントIDなし）arn:aws:ec2:ap-northeast-1:123456789012:instance/i-1234567890abcdef0→ 東京リージョンのEC2インスタンス
マネージドポリシーとインラインポリシーの違い
これも最初は混乱しました。
graph TD
A[IAMポリシーの種類] --> B[マネージドポリシー<br/>再利用可能]
A --> C[インラインポリシー<br/>特定用途専用]
B --> B1[AWS管理ポリシー<br/>AWSが用意]
B --> B2[カスタマー管理ポリシー<br/>自分で作成]
B1 -.例.-> B1A["ReadOnlyAccess<br/>全サービス読み取り専用"]
B2 -.例.-> B2A["MyCompanyS3Policy<br/>自社用カスタム設定"]
C --> C1[特定のユーザーに<br/>直接埋め込み]
C -.注意.-> C2[ユーザー削除で<br/>一緒に消える]
style B1 fill:#e1f5ff
style B2 fill:#ffe1f5
style C1 fill:#ffffe1使い分けルール:
- マネージドポリシー: 複数人に同じ権限を付けるとき
- インラインポリシー: 「この人だけ特別に」という例外的な権限
ちなみに、AWS公式は「できるだけマネージドポリシーを使いましょう」と言っています。管理が楽ですからね。
具体的なポリシー例で練習
例1: S3バケットの読み取り専用アクセス
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-company-bucket",
"arn:aws:s3:::my-company-bucket/*"
]
}
]
}解説:
- ListBucket: バケット内のファイル一覧を見る
- GetObject: 実際にファイルをダウンロードする
2つのResourceがあるのは、「バケット自体」と「バケット内のファイル」で別々に指定する必要があるからです。これ、最初は「/*」の意味が分からなくて悩みました。
例2: 特定のEC2インスタンスだけ起動・停止できる
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-1234567890abcdef0"
}
]
}
このポリシーは「開発環境のサーバーだけ再起動できる権限」みたいな使い方に便利です。本番環境は触れないので安全ですね。
4. セキュリティのベストプラクティス
① ルートユーザーにMFA（多要素認証）をかける
スマホのアプリで6桁の数字を出すアレです。設定した瞬間、ダッシュボードに緑のチェックがつくんですが、あれを見ると「よし、守られてる！」という謎の達成感があります。
graph LR
A[ルートユーザー] -->|初回のみ| B[IAM管理者<br/>ユーザー作成]
B --> C[MFA設定]
B --> D[アクセスキー削除]
E[日常業務] -.X 絶対使わない!.-> A
E -->|これを使う| F[IAM管理者<br/>ユーザー]
G[緊急時のみ<br/>請求設定など] -.仕方なくOK.-> A
style A fill:#ffe1e1
style F fill:#e1ffe1パスワード（知識情報）、スマホやカード（所持情報）、指紋（生体情報）といった異なる性質の認証要素のうち、2つ以上を組み合わせて本人確認を行うセキュリティ手法のこと！
② 最小権限の原則
「念のため管理者権限にしとこう」は卒業しました。新入社員にいきなり社長の判子を渡さないのと同じで、最初は「読み取り専用」から始めるのが、AWSの世界ではマナーだそうです。
段階的な権限付与の例
graph LR
A[新入社員] -->|初日| B[読み取り専用<br/>ViewOnlyAccess]
B -->|1週間後| C[開発環境の<br/>編集権限]
C -->|1ヶ月後<br/>承認必要| D[本番環境の<br/>限定的権限]
E[× ダメな例] -.最初から.-> F[AdministratorAccess<br/>何でもできる]
style B fill:#e1ffe1
style C fill:#fff4e1
style D fill:#ffe1e1
style F fill:#ff0000,color:#fff③ アクセスキーの管理方法
やってはいけないこと:
- コードに直接書く（GitHubに公開したら即アウト！）
- メールで送る
- Slackに貼り付ける
正しい方法:
- 環境変数に設定
- AWS Secrets Managerを使う
- できる限りIAMロールで代用
④ 定期的な権限レビュー
IAMダッシュボードには「認証情報レポート」という便利機能があります。これを使うと、「90日以上ログインしていないユーザー」や「使われていないアクセスキー」が一目瞭然です。
チェック項目:
- 最終ログイン日時
- パスワードの最終変更日
- MFA有効/無効
- アクセスキーの使用状況
退職者のアカウントが残ったままだったりすると怖いですね。定期的（例：月 1 回）に確認する必要がありますね。
6. よくある質問：私が最初に疑問に思ったこと
Q1: IAMユーザーとルートユーザーの違いは？
A: ルートユーザーは「神様」、IAMユーザーは「一般社員」です。
ルートユーザーはアカウント作成時に自動で作られる最強アカウントで、請求情報の変更やアカウントの閉鎖など、何でもできます。でも、だからこそ危険なんです。
一方、IAMユーザーは必要な権限だけを持つ個別アカウント。日常業務ではこちらを使います。
Q2: ロールとユーザーはどう使い分ける?
A: 人間→ユーザー、サービス→ロール
- IAMユーザー: 山田さんや佐藤さんなど、実際の人間がログインする
- IAMロール: EC2やLambdaなど、AWSサービスが他のサービスにアクセスする
具体例で言うと…
- EC2からS3にファイルをアップロード → ロールを使う
- 私がS3にファイルをアップロード → IAMユーザーでログイン
Q3: パスワードポリシーの設定方法は？
A: IAMダッシュボードの「アカウント設定」から設定できます。
設定例:
- 最小文字数: 12文字以上（8文字だと少し不安）
- 大文字・小文字・数字・記号を含める
- パスワードの有効期限: 90日
- 過去5つのパスワードは再利用不可
Q4: IAMの料金はかかる？
A: IAM自体は完全無料です！
ユーザーを100人作っても、ポリシーを1000個作っても、IAMサービス自体に料金はかかりません。安心して練習できます。
ただし、そのIAMユーザーが作ったEC2インスタンスやS3バケットには、通常通り料金が発生するので注意しましょう。
Q5: グループに所属していないユーザーに権限を付与できる？
A: できます！でも、推奨されません。
ユーザーに直接ポリシーをアタッチすることは技術的に可能ですが、管理が煩雑になります。10人、20人とユーザーが増えたとき、個別に設定していたら大変ですよね。
ベストプラクティス:
グループを作って、グループに権限を付けて、ユーザーをグループに所属させる。これが一番管理しやすいです。
Q6: 一つのユーザーに複数のグループを割り当てられる？
A: できます！
例えば、山田さんが「開発チーム」と「セキュリティチーム」の両方に所属することも可能です。その場合、両方のグループの権限が合算されて適用されます。
graph TD
A[山田太郎さん] --> B[開発チーム]
A --> C[セキュリティチーム]
B --> D[EC2/S3アクセス]
C --> E[CloudTrail/IAM管理]
A -.最終的な権限.-> F[EC2/S3/CloudTrail/<br/>IAM全て使える]
style A fill:#e1f5ff
style F fill:#e1ffe1まとめ：IAMを味方につけてAWSの世界へ
IAMは、最初は「不自由にするための制限」だと思っていました。でも、正しく設定することで、安心して色々なサービスを試せる「安全網」なんだと今は感じています。
IAMの基本概念:
- IAMは「誰が、どのリソースを触っていいか」を決める門番
- 利用は完全無料（作成したリソースには料金発生）
- グローバルサービス（リージョン指定不要）
4つの主要コンポーネント:
- IAMユーザー = 個人の社員証（人間用）
- IAMグループ = 部署（権限の一括管理）
- IAMロール = 変身ベルト（AWSサービス用、一時的）
- IAMポリシー = 権限の指示書（JSON形式）
セキュリティのベストプラクティス:
- ルートユーザーは日常使用しない（緊急時のみ）
- MFA（多要素認証）は必須設定
- 最小権限の原則を徹底
- アクセスキーはコードに直接書かない
- 定期的な権限レビュー（90日ごと推奨）
コメント