セキュリティ・IAM
IAMユーザー・ロール・ポリシー
IAMユーザーとIAMロールはどちらも「誰が/何が」AWSにアクセスするかを表すプリンシパルですが、認証情報の性質が異なります。IAMポリシーはその両方に「何を許可するか」をアタッチする権限ドキュメントです。
| 観点 | IAMユーザー | IAMロール |
|---|---|---|
| 認証情報 | 長期的なアクセスキーやパスワードを保持 | 一時的なセキュリティ認証情報（STS）を都度発行 |
| 想定される利用者 | 長期認証情報が不可避な例外的ワークロード | AWSサービス（EC2/Lambda等）、他アカウント、IAM Identity Center等のフェデレーションユーザー |
| 認証情報のローテーション | 手動でのローテーションが必要（漏洩リスク） | 自動的に発行・失効される（有効期限あり） |
| 利用方法 | 直接ログイン（パスワード）またはアクセスキーで利用 | AssumeRoleにより一時的に引き受けて利用 |
| 典型用途 | ロールや一時認証情報に対応できないレガシーツール等の例外 | EC2/Lambdaへの権限付与、クロスアカウントアクセス、IAM Identity Center/フェデレーション |
使い分けの判断基準
人がAWSへアクセスする場合は、IAM Identity Centerまたは外部IdPとのフェデレーションを使い、ロールと一時的な認証情報を利用することがAWSの推奨です。IAMユーザーは、ロールや一時認証情報に対応できず長期認証情報が不可避な例外に限定します。EC2やLambdaなどAWSリソース、クロスアカウントアクセスにもIAMロールを使い、ユーザー・ロールには最小権限のIAMポリシーをアタッチします。
試験で問われるポイント
- 全試験共通で「最小権限の原則」と「長期的な認証情報よりロールを優先する」という設計思想が頻出
- 「EC2からS3にアクセスしたい」→EC2にIAMロールを付与、アクセスキーをハードコードしないという定番のアンチパターン問題がSAAで頻出
- ポリシーの評価ロジック（明示的Deny＞明示的Allow＞デフォルトDeny）やSCP（サービスコントロールポリシー）との違いも頻出
関連するサービス解説
参照元
最終更新日: 2026-09-06
本ページの内容は、AWS公式ドキュメントを基に作成し、運営者が編集・監修しています。詳しくは編集・品質管理方針をご覧ください。