AWS IAM 完全ガイド|認証認可の中核サービス

IAM は AWS の全サービスへのアクセスを認証認可する中核セキュリティ機能。ユーザー・グループ・ロール・ポリシーの 4 要素で権限を管理し、「誰が・どのリソースに・何ができるか」をきめ細かく制御する。全 AWS サービスの土台で、CLF から SOA まで全試験で頻出。...

AWS の認証認可サービス。ユーザー・グループ・ロール・ポリシーで権限を細かく制御する全 AWS の中核セキュリティ。


1. 概要(端的に)

IAM は AWS の全サービスへのアクセスを認証認可する中核セキュリティ機能。ユーザー・グループ・ロール・ポリシーの 4 要素で権限を管理し、「誰が・どのリソースに・何ができるか」をきめ細かく制御する。全 AWS サービスの土台で、CLF から SOA まで全試験で頻出。


2. 何ができるか

  • ユーザー管理:人間の AWS アカウント
  • グループ:ユーザーをまとめて権限管理
  • ロール:一時的な権限委譲(EC2 → AWS 等)
  • ポリシー:JSON で記述する権限定義
  • MFA:多要素認証
  • アクセスキー:プログラムからの認証
  • 連携 ID:SAML / OIDC 統合
  • アクセス分析:Access Analyzer で過剰権限検出

3. 特徴

観点特徴
追加料金無料(IAM 自体)
グローバルリージョンに依存しない
最小権限の原則必要最小限の権限を付与
ベストプラクティスroot 不使用、MFA 有効、アクセスキー定期ローテ
ポリシー評価明示的拒否 > 明示的許可 > デフォルト拒否

4 つの主要要素

要素役割
ユーザー個人の AWS 利用者
グループユーザーの集合(権限まとめ管理)
ロールサービス間の権限委譲(人間ではない)
ポリシーJSON で書かれた権限ルール

ポリシーの種類

  • AWS 管理ポリシー:AWS 提供(AmazonS3FullAccess 等)
  • カスタマー管理ポリシー:自社作成(再利用可)
  • インラインポリシー:ユーザー / グループ / ロールに直接埋込

4. 仕組み

IAM は 「誰が(Principal)」「どのアクション(Action)を」「どのリソース(Resource)に」「条件(Condition)下で実行できるか」 を JSON ポリシーで定義する。

ポリシー JSON 構造

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
      "IpAddress": {"aws:SourceIp": "10.0.0.0/8"}
    }
  }]
}

評価ロジック

1. デフォルト拒否(暗黙)
2. 明示的拒否があれば → 拒否
3. 明示的許可があれば → 許可
4. 何もなければ → 拒否

明示的拒否は最強(許可ポリシーがあっても拒否される)

IAM ロールの活用

  • EC2 ロール:EC2 から AWS API を叩く時の一時クレデンシャル
  • クロスアカウントロール:別アカウントへのアクセス
  • フェデレーション:オンプレ AD / SAML との統合
  • AssumeRole:一時的なロール切替

5. ユースケース

ユースケース 1:開発者の権限管理

グループ「Developers」に開発者用権限を付与、メンバー追加で自動継承。

ユースケース 2:EC2 から S3 アクセス

EC2 にロール付与 → アクセスキーを EC2 に置かずに S3 操作。

ユースケース 3:マルチアカウント

複数 AWS アカウント間での権限移譲(AssumeRole)。

ユースケース 4:CI/CD パイプライン

GitHub Actions → OIDC 連携 → IAM Role → AWS リソースへ。

ユースケース 5:監査・コンプライアンス

Access Analyzer で過剰公開を検出。


6. 関連用語


7. 関連サイト

AWS 公式

参考


🎓 試験での出題傾向

試験重要度主な出題パターン
CLFIAM の基本概念、ベストプラクティス
SAAロール設計・クロスアカウント・最小権限(最頻出
DVAアプリからの IAM 利用、ロール付与
SOA運用・監査・トラブルシュート