AWS IAM

解決する課題

• 全員がフルアクセス、では事故が起きる → 必要な人に必要な権限だけ渡したい
• アプリにパスワードやキーを埋め込みたくない → 一時的な認証情報で安全に
• 監査で「誰が何をできるか」を説明したい

主要概念と用語

• ルートユーザー: アカウント作成時の最強アカウント。日常利用しない
• IAMユーザー: 人やアプリに紐づくID（長期認証情報を持つ）
• IAMグループ: ユーザーの束。権限をまとめて付与
• IAMロール: 「引き受ける」ことで一時認証情報が発行されるID。EC2/Lambda/クロスアカウントで使う
• ポリシー: 許可/拒否を記述したJSON（Effect / Action / Resource / Condition）

仕様・制限・クォータ

• グローバルサービス（リージョンに依存しない）
• ポリシーは IDベース（誰に付けるか）と リソースベース（リソース側に付ける。例: S3バケットポリシー）
• 一時認証情報は STS（Security Token Service）が発行

内部の仕組み

リクエストが来ると、IAMは次の順で評価します。

1. デフォルトは全拒否（暗黙のDeny）
2. 適用されるポリシーに明示的なAllowがあれば許可
3. ただし明示的なDenyが1つでもあれば最優先で拒否

設計パターン / ベストプラクティス

• 最小権限の原則: 必要な操作・リソースだけに絞る
• ロールを使う: EC2やLambdaにはロールをアタッチし、キーをハードコードしない
• ルートユーザーは封印: MFAを設定し、日常はIAM/IAM Identity Centerで運用
• IAM Identity Center（旧SSO）: 複数アカウント・人の管理を一元化

運用・監視・トラブルシュート

• IAM Access Analyzer で過剰権限・外部公開を検出
• CloudTrail で「誰がいつ何をしたか」を監査
• 権限エラー時は、IDポリシー・リソースポリシー・明示的Denyの順で確認

コスト

IAM自体は無料。STSの一時認証情報発行も無料。

セキュリティ

• MFA を必須化（特にルートと特権ユーザー）
• アクセスキーよりロール（一時認証情報）を優先
• 条件（Condition）でIP/MFA/時間などを縛る

Well-Architected の観点

• セキュリティ: 最小権限・多層・追跡可能性の中核そのもの
• 運用上の優秀性: 権限をコード（ポリシー/IaC）で管理し再現性を確保

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# S3読み取り専用ポリシーをロールにアタッチして引き受け
aws iam create-role --role-name app-readonly \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy --role-name app-readonly \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# 現在の自分の権限主体を確認（トラブル時に便利）
aws sts get-caller-identity