AWS IAM 完全ガイド 2026

初心者から実務者向けの包括的解説

AWS IAM（Identity and Access Management） は、AWS リソースへのアクセスを ID ベースで精密に制御する AWS の根幹サービスです。認証（Authentication）と認可（Authorization）の基盤として機能し、AWS セキュリティの最重要ピースです。本ドキュメントは、IAM の概念・アーキテクチャ・ポリシー・ベストプラクティス・実装例を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： IAM とは何か、なぜ必要かを学びたい方
• 開発者向け： ロール・ポリシー・クレデンシャルを管理したい方
• SRE / インフラ向け： クロスアカウント・フェデレーション・最小権限を実装したい方
• セキュリティ管理者向け： 組織全体の IAM ガバナンス・監査・コンプライアンスを設計したい方
• 意思決定者向け： IAM と他の認証基盤（Azure AD / GCP IAM / Okta）の比較

2026 年の IAM エコシステム

• IAM Identity Center（旧 AWS SSO）：30+ の SaaS アプリケーション統合、SCIM 対応
• IAM Access Analyzer：外部アクセス検出の継続改善、Resource Control Policies 対応
• IAM Roles Anywhere：オンプレ・マルチクラウド環境での IAM ロール利用
• EKS Pod Identity：IRSA（IAM Roles for Service Accounts）の後継、簡素化
• Verified Access：CloudTrail 統合強化、デバイス検証・セッション管理の高度化
• AI ポリシー生成：生成 AI による IAM ポリシー提案・最適化
• CloudTrail Lake：1 年間のログ保持、IAM 監査ログの長期分析
• Resource Control Policies（RCP）：SCP の後継、より細粒度な制御

定義

AWS 公式による定義：

“AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources.”

IAM は アクセス制御そのもの であり、AWS を安全に使用するための前提条件です。IAM 自体の使用は完全無料。

目次

1. 概要
2. IAM が解決する課題
3. 主な特徴
4. アーキテクチャ
5. IAM の構成要素（プリンシパル、ポリシー、リソース）
6. ポリシータイプの完全解説
7. ポリシー評価ロジック
8. 主要ユースケース（10 パターン以上）
9. IAM Roles と Trust Policy
10. STS と一時認証情報
11. IAM Identity Center（旧 SSO）
12. IAM Access Analyzer
13. サービスコントロールポリシー（SCP）
14. Permission Boundary
15. IAM Roles Anywhere
16. ABAC（Attribute-Based Access Control）
17. EKS IRSA / Pod Identity
18. EC2 Instance Profile
19. Lambda 実行ロール
20. クロスアカウントアクセスパターン
21. 他の類似ツールとの比較
22. クライアントとエコシステム
23. ベストプラクティス
24. トラブルシューティング
25. 2025-2026 最新動向
26. 学習リソース
27. 実装例・活用シーン
28. 導入ロードマップ
29. 実装チェックリスト
30. まとめ
31. 参考文献

概要

初心者向けメモ： IAM は「AWS リソースへのアクセスを 誰が（プリンシパル）何を（アクション）どのリソースに対して（リソース）できるかを定義する仕組み」です。IAM ポリシーは JSON 形式で書かれ、すべての AWS API 呼び出しはこのポリシー評価を経由します。

IAM（Identity and Access Management）は AWS の アクセス制御基盤 です。以下の機能を提供します：

IAM が解決する課題

1. 長期クレデンシャルの管理困難性

課題：アプリケーションにハードコードされたアクセスキーは漏洩リスク・ローテーション管理が複雑

IAM の解決：

• IAM ロール → STS による一時的認証情報（15 分〜12 時間）
• → 期限切れで自動無効化、キー管理不要

2. 多人数アクセス管理

課題：複数の個人が AWS にアクセスする際、同じアカウント・パスワード共有は監査不可・セキュリティリスク

IAM の解決：

• 個人ごとの IAM ユーザー（または IAM Identity Center）
• → CloudTrail で誰が何をしたか追跡可能
• → MFA 強制で認証強度向上

3. マルチアカウント環境での権限管理

課題：複数の AWS アカウント間でアクセスを制御するのが複雑

IAM の解決：

• クロスアカウントロール + Trust Policy
• → アカウント A の IAM ユーザーがアカウント B のロールを引き受け
• → 複数アカウント間での安全なアクセス

4. サービス間認証の安全性

課題：EC2 から S3 へアクセスする際、アクセスキーを埋め込むと漏洩リスク

IAM の解決：

• EC2 インスタンスプロファイル（IAM ロール）
• → STS 自動的に一時的認証情報を提供
• → アプリケーションコードに認証情報をハードコード不要

主な特徴

アーキテクチャ

初心者向けメモ： IAM は 3 層構造です。プリンシパル層（誰が）→ ポリシー層（何ができるか）→ リソース層（どのリソースか）で成り立ちます。AWS API 呼び出しがあると、このポリシー評価エンジンが「許可」「拒否」を判定します。

【図1】IAM アーキテクチャ：プリンシパル → ポリシー → リソース

graph TD
    subgraph Principals["プリンシパル層（Who）"]
        User["IAM ユーザー"]
        Role["IAM ロール"]
        FedUser["フェデレーテッドユーザー"]
    end
    
    subgraph Policies["ポリシー層（What）"]
        Identity["Identity-based ポリシー"]
        Resource["Resource-based ポリシー"]
        SCP_pol["SCP（Organization レベル）"]
        PB["Permission Boundary"]
    end
    
    subgraph Resources["リソース層（Which）"]
        S3["S3"]
        EC2["EC2"]
        RDS["RDS"]
        Lambda["Lambda"]
        DDB["DynamoDB"]
    end
    
    User --> Identity
    Role --> Identity
    FedUser --> Identity
    
    Identity --> SCP_pol
    SCP_pol --> PB
    PB --> Resources
    Resource --> Resources

IAM の構成要素

1. プリンシパル（Principal）：誰が

2. ポリシー（Policy）：何ができるか

3. リソース（Resource）：どのリソース

ポリシータイプの完全解説

初心者向けメモ： AWS には複数のポリシータイプが存在し、異なる層で制御が行われます。最初は「Identity-based ポリシー」だけを理解していれば OK です。その後、複数アカウント・クロスアカウント環境が必要になったら「Resource-based ポリシー」を学んでください。

ポリシータイプ比較表

1. Identity-based ポリシー（最も基本）

管理ポリシー（AWS 管理）

AWS が管理・定期的に更新するポリシー。一般的な用途は大体カバーされています。

例：

• ReadOnlyAccess：すべての AWS サービスの読み取り専用
• PowerUserAccess：IAM 以外のすべてのサービスへのフルアクセス
• AmazonS3ReadOnlyAccess：S3 の読み取り専用

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": "*"
    }
  ]
}

カスタマー管理ポリシー

自社で定義・管理するポリシー。複数のエンティティに再利用可能。本番環境はこの方式を推奨。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadWriteSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

インラインポリシー

単一のエンティティにのみ紐付けられるポリシー。エンティティ削除時に一緒に削除。特殊な場合のみ使用。

2. Resource-based ポリシー

リソース側に定義するポリシー。クロスアカウントアクセスに必須。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::other-account-bucket/*"
    }
  ]
}

ポイント：Principal フィールドが必須（Identity-based には不要）。

3. SCP（Service Control Policy）

AWS Organizations で OU（Organization Unit）に適用し、その配下のメンバーアカウント全体に対して「禁止」を設定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging"
      ],
      "Resource": "*"
    }
  ]
}

重要：

• ✅ 明示的な Deny で拒否
• ❌ Allow を定義しても「上限」として機能（要注意）
• ❌ マスターアカウントには適用されない

4. Permission Boundary

IAM ユーザー/ロールが付与できる権限の「最大許可範囲」を定義。权限エスカレーション防止。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*"
      ],
      "Resource": "*"
    }
  ]
}

ユースケース：開発者にセルフサービスでロール作成を許可するが、RDS・KMS へのアクセスロールは作成させない

5. Session Policy

AssumeRole で一時セッションを取得する際に追加制限を与える。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:DeleteBucket",
      "Resource": "*"
    }
  ]
}

ポリシー評価ロジック

初心者向けメモ： IAM のアクセス制御は「デフォルトは拒否」が原則です。Allow が明示されなければ、どんなに高い権限でも拒否されます。これを理解することが IAM 習得の鍵です。

AWS API 呼び出しがあると、以下のフローで「許可」「拒否」が判定されます：

【図2】ポリシー評価ロジック（Decision Tree）

graph TD
    A["リクエスト"] --> B{"1. 明示的 Deny\nがあるか？"}
    B -->|YES| C["❌ アクセス拒否\n（終了）"]
    B -->|NO| D{"2. SCP（組織レベル）\nで Allow か？"}
    D -->|NO| C
    D -->|YES| E{"3. Resource-based\nポリシーで Allow か？"}
    E -->|YES| F["クロスアカウントか？"]
    F -->|NO| G["✅ アクセス許可"]
    F -->|YES| H{"4. Identity-based\nポリシーで Allow か？"}
    E -->|NO| H
    H -->|NO| C
    H -->|YES| I{"5. Permission Boundary\nで Allow か？"}
    I -->|NO| C
    I -->|YES| J{"6. Session Policy\nで Allow か？"}
    J -->|NO| C
    J -->|YES| G

評価ロジック詳細：

1. 明示的 Deny（Explicit Deny）がある？
   → YES：拒否（デフォルト拒否）。Deny は最強

2. SCP（組織レベル）に Allow または Allow がない？
   → NO：拒否

3. Resource-based ポリシーに Allow がある？
   → YES（クロスアカウント以外）：許可
   → YES（クロスアカウント）：次へ

4. Identity-based ポリシーに Allow がある？
   → NO：暗黙的拒否（Implicit Deny）

5. Permission Boundary（最大範囲）に Allow がある？
   → NO：拒否

6. Session Policy に Allow がある？
   → NO：拒否
   → YES：✅ アクセス許可

実例：

シナリオ：EC2（IAM ロール A）が S3 バケットにアクセス

ロール A のポリシー：
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

S3 バケットポリシー：
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*"
}

→ 結果：拒否（Deny が Deny を超える）

IAM ポリシー JSON 具体例

例1：S3 特定バケットの読み取り専用

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3ReadOnlySpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::app-data",
        "arn:aws:s3:::app-data/*"
      ]
    }
  ]
}

例2：EC2 インスタンスの起動・停止のみ

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2StartStop",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:DescribeInstances"
      ],
      "Resource": "arn:aws:ec2:ap-northeast-1:123456789012:instance/*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "dev"
        }
      }
    }
  ]
}

例3：Lambda 関数実行ロール（DynamoDB・CloudWatch Logs アクセス）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DynamoDBAccess",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/orders"
    },
    {
      "Sid": "CloudWatchLogsAccess",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/lambda/*"
    }
  ]
}

例4：MFA 必須でコンソールアクセス制限

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowConsoleWithMFA",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    },
    {
      "Sid": "DenyWithoutMFA",
      "Effect": "Deny",
      "Action": [
        "ec2:TerminateInstances",
        "rds:DeleteDBInstance"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

例5：特定 IP からのみアクセス（VPN / 企業ネットワーク）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowFromCorporateNetwork",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "198.51.100.0/24"
          ]
        }
      }
    },
    {
      "Sid": "DenyFromPublicInternet",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "198.51.100.0/24"
          ]
        }
      }
    }
  ]
}

主要ユースケース

初心者向けメモ： IAM は「セキュリティの基礎」というイメージが強いですが、実は様々なユースケースがあります。自分の業務パターンに合うものから学ぶことをお勧めします。

1. CI/CD パイプラインでの最小権限制御

課題：GitHub Actions / GitLab CI で AWS にデプロイする際、長期アクセスキーの安全管理が困難

IAM の解決：

• GitHub OIDC → IAM ロール（Web Identity Federation）
• → 短期クレデンシャル（1 時間以下）自動取得
• → リポジトリ・ブランチごとに権限を分離
• 例：本番デプロイロールは本番ブランチからのみ引き受け可

具体的なポリシー：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": "arn:aws:s3:::app-dist/*"
    },
    {
      "Effect": "Allow",
      "Action": "cloudfront:CreateInvalidation",
      "Resource": "arn:aws:cloudfront::123456789012:distribution/ABCDEFG"
    }
  ]
}

2. クロスアカウントアクセス

課題：複数の AWS アカウント間でアクセスを制御（本番・開発・監視アカウント分離）

IAM の解決：

Account A（本番）のロール ← Account B（監視）から AssumeRole
Trust Policy で Account B を信頼
→ 監視アカウントから本番リソースを読み取り

Account A ロールの Trust Policy:
{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::222222222222:role/MonitoringRole"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "unique-external-id"
    }
  }
}

3. 外部 IdP フェデレーション（SSO）

課題：個人の Google / GitHub アカウントで AWS にログインしたい

IAM の解決：

• Google / GitHub OIDC Provider → IAM ロール自動引き受け
• → 長期クレデンシャル不要
• → Google / GitHub で MFA 済みなら AWS でも MFA 扱い

4. マイクロサービスのサービスロール

課題：ECS / Kubernetes で各コンテナに異なる権限を付与したい

IAM の解決：

• Task A（決済処理）：RDS・KMS アクセスのみ
• Task B（監視エージェント）：CloudWatch Logs・X-Ray アクセスのみ
• → コンテナが機能する最小権限のみ
• → Task A が漏洩しても決済データの外部流出を防止

5. 最小権限の原則（Least Privilege）実装

課題：開発者に「充分な権限」と「セキュリティ」を両立したい

IAM の解決：

1. ユースケースごとのカスタムポリシー定義
   - 開発環境：EC2・Lambda・S3・DynamoDB のフルアクセス
   - 本番環境：読み取り専用 + 限定的な変更
   
2. Permission Boundary で上限設定
   - これ以上の権限は付与不可
   
3. CloudTrail で監査
   - 誰が何をしたか記録

6. Privileged Access Management（PAM）

課題：root / admin ユーザーのアクセスを厳しく制御したい

IAM の解決：

1. 個人が一般ロールで通常業務
2. 特権操作が必要 → 一時的に高権限ロールを引き受け
3. MFA + IP 制限 + 期限付き（セッション 1 時間等）
4. すべての操作を CloudTrail でログ

7. AWS IAM Identity Center（旧 SSO）での統一認証

課題：複数の AWS アカウント・SaaS に個別に ID を管理するのが煩雑

IAM の解決：

• Identity Center で統一認証
• → 社員ディレクトリ（Okta / Azure AD）と同期
• → Slack / Salesforce / GitHub 等 30+ の SaaS に SSO
• → 離職時に Identity Center から削除すると全リソースアクセス失効

8. EKS での Pod Identity（IRSA 進化版）

課題：Kubernetes Pod が AWS リソースにアクセスする際、認証情報管理が複雑

IAM の解決（IRSA）：

Pod → OIDC Provider → IAM ロール自動引き受け
→ クレデンシャルファイル配置不要
→ Pod 単位で異なるロール引き受け可

Kubernetes YAML:
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT:role/pod-role

9. CodePipeline での本番デプロイ権限制御

課題：自動デプロイは本番環境に影響するため、特定のパイプラインのみ許可

IAM の解決：

CodePipeline 実行ロール → CloudFormation AssumeRole
→ CloudFormation ロールに実際の権限を付与
→ CodePipeline の権限は限定的に

このパターンで：
- CodePipeline が乗っ取られても本番を直接変更できない
- CloudFormation で何ができるか明確に制御

10. Bastion ホストでのセッション管理

課題：Bastion ホストを介してプライベートリソースにアクセスする際、SSH キー管理が複雑

IAM の解決：

• EC2 Instance Connect / Session Manager
• → IAM 権限で制御
• → SSH キー不要
• → CloudTrail で全セッション記録

IAM Roles と Trust Policy

初心者向けメモ： IAM ロールは「一時的なセッションをシェアする仕組み」です。複数のプリンシパルが同じロールを引き受けることで、短期クレデンシャルを取得します。

IAM ロールの構成

IAM ロール = Trust Policy（誰がこのロールを引き受けられるか）+ Attached Policies（引き受けた後に何ができるか）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Trust Policy の例

EC2 インスタンスが引き受けられるロール

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

クロスアカウントの別ロールが引き受けられるロール

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/SourceRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-id-for-security"
        }
      }
    }
  ]
}

OIDC 経由（GitHub / Google）がロール引き受け

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

STS と一時認証情報

初心者向けメモ： STS（Security Token Service） は「IAM ロールを引き受けて一時的なクレデンシャル（アクセスキー・シークレット・セッショントークン）を発行するサービス」です。

STS が発行する認証情報

• AccessKeyId : ASIABCDEFGHIJKLMNOP（一時キーは AS で始まる）
• SecretAccessKey : xxxxx…
• SessionToken : xxxxx…（一般的な長期キーにはない）
• Expiration : 2026-04-26T10:30:00Z（期限）

AssumeRole API

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name my-session \
  --duration-seconds 3600

戻り値：

{
  "Credentials": {
    "AccessKeyId": "ASIABCDEFGHIJKLMNOP",
    "SecretAccessKey": "abc123...",
    "SessionToken": "FwoGZXIvYXdzEF...",
    "Expiration": "2026-04-26T10:30:00Z"
  }
}

STS による認証フロー

EC2 インスタンス（IAM インスタンスプロファイル）
    ↓ STS 自動引き受け（バックグラウンド）
    EC2 メタデータサービス（169.254.169.254）に問い合わせ
    ↓
STS が一時クレデンシャルを発行
    ↓ SessionToken 付きで返却
    アプリケーションコード内から自動的に利用

IAM Identity Center（旧 SSO）

初心者向けメモ： IAM Identity Center は「AWS 独自のユーザー管理」と「外部ディレクトリ連携」の両方をサポートする統一認証基盤です。複数アカウント・複数 SaaS への SSO が可能です。

主な特徴

フロー

社員が Identity Center ポータルにログイン
    ↓
Azure AD / Okta で認証（または Identity Center ユーザーディレクトリ）
    ↓ MFA
    ↓
複数 AWS アカウント・SaaS に自動ログイン
    ↓ SAML / OIDC

IAM Access Analyzer

初心者向けメモ： IAM Access Analyzer は「あなたのリソースが想定外に公開されていないか」を自動検出するセキュリティツールです。

機能

Access Analyzer スキャン
    ↓
以下を自動検出：
    - S3 バケットパブリックアクセス
    - KMS キーを外部アカウントで使用可能
    - IAM ロール（クロスアカウント）が外部ユーザーで引き受け可
    - Lambda 関数が外部アカウントから呼び出し可
    - 他多数のリソースベースポリシー
    ↓
異常を検出 → アラート生成

ポリシー検証機能

IAM ポリシーを変更 → 構文・ロジックエラーをリアルタイム検出
例：
  - 存在しないサービスアクションを指定
  - ワイルドカード乱用
  - 矛盾した Allow / Deny

サービスコントロールポリシー（SCP）

初心者向けメモ： SCP は「AWS Organizations で全メンバーアカウントに対して『禁止』を適用する仕組み」です。個別ポリシーより強力です。

SCP と Identity-based ポリシーの関係

ユーザーポリシー：
  "Effect": "Allow",
  "Action": "s3:*"

組織の SCP：
  "Effect": "Deny",
  "Action": "s3:DeleteBucket"

結果：s3:DeleteBucket は拒否（Deny が勝利）
      その他の s3:* は許可

典型的な SCP 設計

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-xxxxxxxxxx"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "ec2:TerminateInstances",
        "rds:DeleteDBInstance"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:username": "admin-*"
        }
      }
    }
  ]
}

Permission Boundary

初心者向けメモ： Permission Boundary は「このロールが作成できる権限の上限」を制限します。権限エスカレーション防止に有効。

使用例

状況：開発者がセルフサービスでロールを作成可能にしたい、ただし RDS・KMS には触らせたくない

バウンダリー定義：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "apigateway:*"
      ],
      "Resource": "*"
    }
  ]
}

開発者のポリシー：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

結果：

• ✅ 開発者は EC2・Lambda・S3 ロールを作成可
• ❌ RDS・KMS ロールは作成不可（バウンダリーで弾かれる）

IAM Roles Anywhere

初心者向けメモ： IAM Roles Anywhere は「オンプレミス・他クラウド（GCP / Azure）で AWS IAM ロールを使用する仕組み」です。

ユースケース

オンプレミスサーバー
    ↓ X.509 証明書で認証
    ↓ IAM Roles Anywhere
    ↓
AWS IAM ロールを引き受け
    ↓
短期クレデンシャル取得
    ↓
AWS API を呼び出し

使用方法

# 証明書を使ってロールを引き受け
aws sts assume-role-with-web-identity \
  --role-arn arn:aws:iam::123456789012:role/OnPremiseRole \
  --role-session-name on-premise-session \
  --certificate /path/to/cert.pem

ABAC（Attribute-Based Access Control）

初心者向けメモ： ABAC は「タグベースのアクセス制御」です。特定のタグを持つユーザーのみが、特定のタグを持つリソースにアクセス可能という仕組み。

RBAC vs ABAC

ABAC ポリシー例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "${aws:PrincipalTag/Environment}",
          "ec2:ResourceTag/Team": "${aws:PrincipalTag/Team}"
        }
      }
    }
  ]
}

ポイント：

• ユーザータグ Environment=dev
• リソースタグ Environment=dev
• → マッチする環境のみアクセス可

EKS IRSA / Pod Identity

初心者向けメモ： Kubernetes Pod が AWS リソースにアクセスする際、認証情報を安全に管理する仕組みです。IRSA は旧方式、Pod Identity が最新です。

IRSA（IAM Roles for Service Accounts）

Kubernetes ServiceAccount
    ↓ OIDC トークン
    ↓
IAM ロール（Trust Policy で検証）
    ↓
短期クレデンシャル取得
    ↓
Pod が AWS API 利用

Trust Policy：

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.ap-northeast-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "oidc.eks.ap-northeast-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:default:my-app"
    }
  }
}

Pod Identity（新方式、AWS EKS ウィジェット 1.24+）

Pod Identity Agent（EKS アドオン）
    ↓ より簡単な設定
    ↓
IAM ロール
    ↓
短期クレデンシャル取得

Kubernetes Annotation：

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/PodRole

EC2 Instance Profile

初心者向けメモ： EC2 インスタンスプロファイルは「EC2 インスタンスが IAM ロールを自動的に引き受ける仕組み」です。

フロー

EC2 インスタンス起動
    ↓ インスタンスプロファイル設定
    ↓
メタデータサービス（169.254.169.254）
    ↓ 自動的に STS AssumeRole
    ↓
短期クレデンシャル（AWS_ACCESS_KEY_ID 等）を環境変数で提供
    ↓
アプリケーションコードが自動的に利用（AWS SDK が自動取得）

設定例（CloudFormation）

Resources:
  MyRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

  MyInstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Roles:
        - !Ref MyRole

  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref MyInstanceProfile
      ImageId: ami-12345678

Lambda 実行ロール

初心者向けメモ： Lambda 関数を実行する際に、その関数が AWS リソースにアクセスするための権限を持つロールです。

設定例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "logs:CreateLogGroup",
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/lambda/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Trust Policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

クロスアカウントアクセスパターン

初心者向けメモ： 複数の AWS アカウント間でアクセスを制御するのが、IAM で最も複雑な部分です。ここは重要なので丁寧に解説します。

パターン1：基本的なクロスアカウントロール

状況：Account A（監視）から Account B（本番）を読み取りたい

Account B 側（リソースオーナー）：

ロール B の Trust Policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/MonitoringRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

ロール B のアタッチポリシー：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "cloudwatch:GetMetricStatistics"
      ],
      "Resource": "*"
    }
  ]
}

Account A 側（リソース利用側）：

Monitoring ロールのポリシー：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::222222222222:role/RoleB"
    }
  ]
}

CLI での引き受け：

aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/RoleB \
  --role-session-name monitoring-session

パターン2：ExternalId を使った外部識別

理由：ロール ARN が漏洩しても、ExternalId がないと引き受け不可

Account B の Trust Policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/MonitoringRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-secret-string-12345"
        }
      }
    }
  ]
}

CLI での引き受け：

aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/RoleB \
  --role-session-name monitoring-session \
  --external-id unique-secret-string-12345

パターン3：S3 バケットポリシー（リソースベースポリシー）

状況：Account A のユーザーが Account B の S3 バケットにアクセス

Account B の S3 バケットポリシー：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::shared-bucket/*"
    }
  ]
}

Account A のユーザーポリシー：

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

他の類似ツールとの比較

初心者向けメモ： AWS IAM の役割を理解するために、他の認証・認可プラットフォームと比較します。

AWS IAM vs Azure AD / Entra ID

AWS IAM vs GCP IAM

AWS IAM vs Okta / Auth0

AWS IAM vs HashiCorp Vault

クライアントとエコシステム

公式ツール

AWS CLI

# IAM ユーザー作成
aws iam create-user --user-name john

# ポリシーをアタッチ
aws iam attach-user-policy \
  --user-name john \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# ロール作成
aws iam create-role \
  --role-name MyRole \
  --assume-role-policy-document file://trust-policy.json

AWS Management Console

• IAM ダッシュボード
• ユーザー / グループ / ロール管理
• ポリシーエディター
• アクセスレポート

IAM Policy Simulator

• IAM ポリシーが実際に「許可」「拒否」を判定するか事前に検証

Web UI：https://policysim.aws.amazon.com/

# CLI 版
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/john \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/*

Access Advisor

• ユーザー/ロール が最後にアクセスした日時を確認
• → 未使用権限を削除してセキュリティ改善

サードパーティツール

Terraform（IAM Module）

module "lambda_role" {
  source = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"

  role_name = "my-lambda-role"

  attach_s3_policy = true
  s3_resources     = ["arn:aws:s3:::my-bucket/*"]

  attach_dynamodb_policy = true
  dynamodb_table_arns    = [aws_dynamodb_table.orders.arn]
}

Pulumi

import pulumi
import pulumi_aws as aws

role = aws.iam.Role("my-role",
    assume_role_policy={
        "Version": "2012-10-17",
        "Statement": [{
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            }
        }]
    })

CloudFormation

Resources:
  MyRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/ReadOnlyAccess

CDK（TypeScript）

import * as cdk from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam';

const role = new iam.Role(this, 'MyRole', {
  assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonS3ReadOnlyAccess')
  ]
});

ベストプラクティス

1. Root アカウント保護

❌ してはいけない：

• Root アカウントで日常業務
• Root アクセスキー作成・使用
• Root アカウント MFA なし

✅ すべきこと：

1. Root アカウント MFA を設定（ハードウェアトークン推奨）
2. Root アクセスキーを全て削除
3. Root ログイン時は監査用ルール/アラート設定
4. CloudTrail で全ログ記録

2. IAM Identity Center を推奨

❌ 非推奨：

• 個人ごとの IAM ユーザー + 長期アクセスキー
• → キー管理が煩雑、漏洩リスク

✅ 推奨：

• IAM Identity Center + 外部ディレクトリ連携
• → SSO、MFA 標準装備、一元管理

3. 最小権限の原則

❌ してはいけない：

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

✅ すべきこと：

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ]
}

4. CloudTrail ログ記録

✅ すべきこと：

1. CloudTrail を全リージョン・全アカウントで有効化
2. ログを S3 に保存（MFA Delete 有効化）
3. CloudTrail Lake で 1 年間保持
4. CloudWatch Logs 連携でリアルタイム監視

5. Access Advisor で未使用権限削除

✅ 定期的（月 1 回以上）に実施：

1. IAM ユーザー/ロール の Access Advisor を確認
2. 「最後にアクセス」が 90 日以上前の権限を削除
3. CloudTrail で実際のアクセスパターンを確認

6. Permission Boundary の活用

✅ 開発者セルフサービスの場合：

1. Permission Boundary を定義
2. 開発者に「ロール作成権限」を付与
3. 開発者が作成できるロールの権限は Boundary に制限

• → RDS・KMS 等へのアクセス防止

7. SCP で組織全体を守る

✅ Organizations 環境で必須：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging"
      ],
      "Resource": "*"
    }
  ]
}

8. クロスアカウント時は ExternalId

✅ セキュリティ向上：

{
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "unique-secret-id"
    }
  }
}

9. MFA を強制

✅ 管理者・本番環境操作：

{
  "Condition": {
    "Bool": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

10. IAM Access Analyzer で継続監視

✅ 定期的な外部アクセス検証：

1. Access Analyzer を有効化
2. 意図しない外部アクセス を自動検出
3. 定期的（週 1 回）にレポート確認

トラブルシューティング

パターン1：「アクセスが拒否された」エラー

診断方法：

1. IAM Policy Simulator で検証：

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/john \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/*

2. CloudTrail で実際の API 呼び出しを確認：

CloudTrail → イベント検索 → アクション = "GetObject" など
→ errorCode / errorMessage を確認

3. Permission Boundary が制限していないか確認

4. SCP で禁止されていないか確認（Organizations の場合）

パターン2：「AssumeRole に失敗」

チェック項目：

1. Trust Policy で Principal が正しいか
2. ExternalId が正しいか
3. 呼び出し元に sts:AssumeRole 権限があるか
4. セッションの期限が切れていないか

パターン3：「リソースベースポリシーの競合」

S3 バケットに「アクセス可」のポリシー + 「アクセス不可」の IAM ユーザーポリシー

• 結果：最初の Deny が勝利 → アクセス拒否

解決：

• リソースベースポリシーで Allow
• AND IAM ユーザーポリシーで Allow → 両方必要

2025-2026 最新動向

1. AI ポリシー生成

AWS が生成 AI を使って IAM ポリシーを自動生成

• 「S3 バケット my-bucket に読み書きしたい」
• → AI が自動的に最小権限ポリシーを提案
• → ユーザーが確認・修正

2. Verified Access 統合強化

• CloudTrail との連携拡大
• デバイス検証・セッション管理の高度化
• ゼロトラストセキュリティ実装支援

3. Resource Control Policies（RCP）

SCP の後継、より細粒度な制御

• SCP：アクション単位の制御
• RCP：リソース単位の制御

4. Identity Center 統合強化

• SCIM 2.0 サポート
• SaaS 連携拡大（50+ アプリケーション対応予定）
• オン・プレミス AD との同期改善

5. CloudTrail Lake での IAM 監査ログ保持

• 1 年間の CloudTrail ログを SQL で分析可能
• IAM 変更履歴の長期追跡

学習リソース

公式ドキュメント

• AWS IAM User Guide
• IAM Best Practices
• IAM JSON Policy Reference

オンラインコース

• AWS Skill Builder：IAM Fundamentals
• Pluralsight：AWS IAM Deep Dive
• Linux Academy / A Cloud Guru：IAM for AWS

書籍

• 「AWS セキュリティ徹底解説」（AWS 公式ガイド）
• 「イラストでわかる AWS 根本から理解する」

実装例・活用シーン

シーン1：スタートアップの初期段階

要件：

• 少人数チーム（5 名以下）
• AWS アカウント 1 つ
• セキュリティは基本的に

構成：

1. Root アカウント保護（MFA 設定）
2. 開発者用 IAM ユーザー作成（PowerUserAccess）
3. CloudTrail で監査ログ記録

シーン2：中規模企業・複数アカウント

要件：

• 複数チーム（開発・本番・監視）
• 複数 AWS アカウント
• クロスアカウントアクセス制御

構成：

1. Organizations 構成
   - Management Account（監査用）
   - Production Account
   - Development Account
   
2. IAM Identity Center を中央で運用
3. クロスアカウント監視ロール
4. SCP で Organizations 全体を保護
5. CloudTrail Lake で長期監査

シーン3：エンタープライズ（コンプライアンス重視）

要件：

• 数十アカウント
• SOX / HIPAA / PCI-DSS コンプライアンス
• 厳格な監査・ログ管理

構成：

1. 監査用アカウント分離
2. Permission Boundary で権限管理
3. SCP で禁止操作を強制
4. CloudTrail Lake での長期保持
5. IAM Access Analyzer で継続監視
6. AWS Config で設定变更追跡
7. 定期的なセキュリティ監査（年 2 回以上）

導入ロードマップ

フェーズ 1：基礎構築（1-2 週間）

• ✅ Root アカウント MFA 設定
• ✅ CloudTrail 有効化
• ✅ 開発者用 IAM ユーザー作成
• ✅ 基本的なポリシー定義

フェーズ 2：セキュリティ強化（1 ヶ月）

• ✅ IAM Identity Center セットアップ
• ✅ 外部ディレクトリ連携（Azure AD 等）
• ✅ MFA 義務化
• ✅ Access Advisor で権限監査

フェーズ 3：ガバナンス確立（2-3 ヶ月）

• ✅ Organizations + SCP 導入
• ✅ クロスアカウント構造整備
• ✅ Permission Boundary 定義
• ✅ CloudTrail Lake 導入

フェーズ 4：継続改善（以降）

• ✅ 月 1 回の権限監査
• ✅ 四半期ごとのセキュリティレビュー
• ✅ ポリシーテンプレート更新
• ✅ 新サービス・新機能の導入評価

実装チェックリスト

セキュリティ

• [ ] Root アカウント MFA 設定済み
• [ ] Root アクセスキー削除済み
• [ ] CloudTrail 全リージョン有効
• [ ] S3 ログ保存バケット MFA Delete 有効
• [ ] アクセスキー自動ローテーション設定
• [ ] 90 日以上使用されていない権限削除

アイデンティティ管理

• [ ] IAM Identity Center 導入済み
• [ ] 外部ディレクトリ連携設定
• [ ] MFA デバイス配布済み
• [ ] 長期 IAM ユーザー排除（Identity Center に移行）

ポリシー管理

• [ ] 最小権限ポリシー定義
• [ ] Permission Boundary 定義
• [ ] SCP で禁止操作を強制
• [ ] ポリシードキュメント化
• [ ] ポリシーレビュー頻度設定（四半期ごと）

モニタリング・監査

• [ ] CloudTrail Lake 導入
• [ ] IAM Access Analyzer 有効
• [ ] 月 1 回の権限監査実施
• [ ] CloudWatch Logs アラート設定
• [ ] セキュリティ監査報告体制構築

まとめ

IAM は AWS セキュリティの根幹 です。以下のポイントを押さえることが重要です：

IAM を正しく理解・運用することで、AWS 環境全体のセキュリティレベルが大きく向上します。

参考文献

AWS 公式ドキュメント

1. AWS IAM User Guide - Introduction
2. IAM Best Practices
3. IAM JSON Policy Reference
4. IAM Policies and Permissions
5. AWS IAM Features
6. IAM Access Analyzer User Guide
7. AWS Organizations Service Control Policies
8. AWS IAM Identity Center
9. AWS STS Assumed Role User
10. EKS IAM Roles for Service Accounts
11. AWS Security Best Practices

外部リソース

12. Open Policy Agent (OPA) - Decoupled Authorization - IAM ポリシー外部化、プロビジョニング自動化
13. HashiCorp Vault - Identity and Access Management - マルチクラウド ID 管理
14. NIST Cybersecurity Framework - IAM に関連するセキュリティフレームワーク
15. Zero Trust Architecture - Google Cloud Security Whitepaper
16. AWS Well-Architected Framework - Security Pillar
17. IAM Policy Autopilot - AWS Labs - AI ポリシー生成（2026新機能）
18. SPIFFE/SPIRE - Workload Identity at Scale - マイクロサービス ID 管理
19. AWS IAM Identity Center MFA Documentation - フェデレーション統合

2025-2026 参考URL

• IAM Access Analyzer Policy Generation
• Resource Control Policies (RCPs) - AWS Organizations
• AWS Security Blog - IAM Updates

最終更新：2026-04-26