はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した AWS IAM 関連の知識をまとめました。
IAM はほぼすべての問題に関わる基盤サービスであり、ポリシーの種類と評価ロジック、Permissions Boundary、クロスアカウントアクセスの仕組みなど、正確な理解が求められます。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
IAM ポリシーの種類
| ポリシー種類 | 適用対象 | 説明 |
|---|---|---|
| Identity-based | ユーザー、グループ、ロール | 権限を付与 |
| Trust Policy | IAM ロール（リソースベース） | 誰がロールを引き受けられるか |
| Permissions Boundary | ユーザー、ロール | 最大権限の境界（自分で外せない） |
| SCP | OU、アカウント | Organizations の権限上限 |
| ACL | S3、WAF、VPC 等 | サービスレベル |
| Session Policy | 一時セッション | セッション権限制限 |
IAM ポリシー評価の原則
- デフォルトは暗黙的 Deny
- 明示的 Allow があれば許可
- 明示的 Deny は常に Allow に優先
- Condition が一致しない場合、そのステートメントは適用されない
IAM 条件キー
| キー | 意味 |
|---|---|
| aws:SourceIp | API 呼び出し元の IP（インスタンスの IP ではない） |
| aws:RequestedRegion | API コールのターゲットリージョン |
| aws:PrincipalTag | プリンシパルのタグ |
| aws:RequestTag | リクエストで渡されるタグ |
| aws:ResourceTag | リソースのタグ |
aws:SourceIp と aws:RequestedRegion の違いは試験で頻出です。SourceIp は「誰が呼んだか」、RequestedRegion は「どこに対して呼んだか」です。
Permissions Boundary vs IAM ポリシー vs SCP
| メカニズム | 適用対象 | 特徴 |
|---|---|---|
| Permissions Boundary | ユーザー、ロール | 最大権限を設定（自分で外せない） |
| IAM ポリシー | ユーザー、ロール、グループ | 権限付与 |
| SCP | OU、アカウント | Organizations 必須、ルートユーザーも適用 |
Permissions Boundary はグループには適用できない点は頻出の引っかけです。
クロスアカウントアクセス
- 常に IAM ロールを使う（IAM ユーザー認証情報の共有は NG）
- 本番アカウントにロール作成 → 開発アカウントのユーザーが Assume
EC2 から AWS サービスへのアクセス
- 常に IAM ロール（インスタンスプロファイル）を使う
- アクセスキーの保存（暗号化しても）は NG
- IAM ロールは一時認証情報を自動ローテーション
クロスアカウント S3 アクセス
- 同一アカウント: IAM ロールのみで OK
- クロスアカウント: IAM ロール + バケットポリシーの両方 が必要
ルートユーザーのベストプラクティス
- 強力なパスワード設定
- MFA 有効化
- アクセスキーは作成しない
- パスワード / キーは誰とも共有しない
- 日常業務には使わない（IAM ユーザー / ロールを使う）
S3 IAM ポリシーの ARN
-
s3:ListBucket→arn:aws:s3:::bucket（/*なし） -
s3:GetObject/PutObject/DeleteObject→arn:aws:s3:::bucket/*（/*あり） - 2つのステートメントに分けて正しい ARN を指定
IAM Access Analyzer vs Access Advisor
| ツール | 用途 |
|---|---|
| IAM Access Analyzer | 外部アクセスの検出（ポリシー分析） |
| IAM Access Advisor | 最終アクセス日時の確認（未使用権限の特定） |
インスタンスプロファイル
- IAM ロールを EC2 にアタッチするためのコンテナ
- 1つのインスタンスプロファイルに1つのロールのみ
- 1つの EC2 に1つの IAM ロールのみ（2つは不可）
試験で問われる設計パターン
アクセス制御系
クロスアカウントアクセス → IAM ロールを Assume
シナリオ: 開発アカウントのユーザーが本番アカウントのリソースにアクセスする必要があります。最もセキュアな方法はどれでしょうか？
正解: 本番アカウントに IAM ロールを作成 → 開発アカウントのユーザーが Assume
- IAM ユーザーの認証情報を共有するのは NG
- 一時認証情報で安全にアクセスできる
EC2 から AWS サービスへのアクセス → IAM ロール（インスタンスプロファイル）
シナリオ: EC2 インスタンスから DynamoDB にアクセスしたいです。認証情報をコードに埋め込まずに安全にアクセスするにはどうすればよいでしょうか？
正解: IAM サービスロールを作成 → インスタンスプロファイルで EC2 にアタッチ
- EC2 用サービスロール作成時、EC2 は自動的に信頼エンティティに設定される
- アクセスキーの保存は暗号化していても NG
Lambda（アカウント A）→ S3（アカウント B）クロスアカウント
シナリオ: アカウント A の Lambda からアカウント B の S3 バケットにアクセスしたいです。
正解: Lambda 実行ロールに S3 権限 + S3 バケットポリシーで Lambda 実行ロールを許可
- クロスアカウント = IAM ロール + バケットポリシーの両方が必要
権限制御系
権限エスカレーション防止 → Permissions Boundary
シナリオ: 開発者に IAM ユーザーやロールの作成を許可しつつ、自分自身に過剰な権限を付与できないようにしたいです。どの機能を使うべきでしょうか？
正解: Permissions Boundary をユーザーに定義
- Permissions Boundary はグループには適用できない（頻出の引っかけ）
- IAM ポリシーだけで制限しても、開発者自身が外せる
- SCP は Organizations が前提
ルートユーザーのセキュリティベストプラクティス
シナリオ: ルートユーザーのセキュリティを強化するために実施すべきことを2つ選んでください。
正解:
- 強力なパスワードを作成
- MFA を有効化
- アクセスキーの作成は非推奨
- メール / S3 での認証情報共有は NG
ポリシー読み解き系
aws:SourceIp の意味
シナリオ: IAM ポリシーの Condition に aws:SourceIp: "34.50.31.0/24" と記載されています。これはどういう意味でしょうか？
正解: API 呼び出し元の IP が 34.50.31.0/24 の範囲内の場合のみ許可
-
aws:SourceIpは API 発信元（インスタンスの IP ではない）
aws:RequestedRegion の意味
シナリオ: IAM ポリシーの Condition に aws:RequestedRegion: "eu-west-1" と記載されています。これはどういう意味でしょうか？
正解: eu-west-1 でのみ EC2 起動が可能（呼び出し元はどこでも OK）
- RequestedRegion = ターゲットリージョン
- SourceIp = 発信元 IP
IAM ポリシーの Deny + Allow + Condition の読み解き
シナリオ: IAM ポリシーに Deny と Allow が混在し、StringNotEquals 条件が含まれています。どのように評価されますか？
ポイント:
-
StringNotEqualsは「一致しない場合に適用」（二重否定に注意） - 明示的 Deny の条件が一致しなければ、その Deny ステートメントは適用されない
その他
IAM サービスがサポートする唯一のリソースベースポリシー → Trust Policy
シナリオ: IAM サービス自体がサポートするリソースベースポリシーはどれですか？
正解: Trust Policy（信頼ポリシー）
- IAM ロールにアタッチし、誰がロールを引き受けられるかを定義
- ACL / SCP / Permissions Boundary は IAM サービスのリソースベースポリシーではない
外部アカウント / パブリックアクセスの検出 → IAM Access Analyzer
シナリオ: S3 バケットや IAM ロールが外部アカウントやパブリックに公開されていないか検出したいです。
正解: IAM Access Analyzer
- リソースベース / ID ベースのポリシーを自動分析
- Access Advisor = 最終アクセス日時
- Inspector = EC2 / コンテナの脆弱性
EC2 パッチ管理の自動化 + 既存 IAM ロール維持 → Default Host Management Configuration
シナリオ: EC2 のパッチ管理を自動化したいですが、既存の IAM ロールを変更したくありません。どの方法が最適でしょうか？
正解: SSM Quick Setup - Default Host Management Configuration
- 既存 IAM ロールを変更せず SSM 機能を自動有効化
- EC2 には1つの IAM ロールしかアタッチできない
- Hybrid Activation はオンプレ / 非 EC2 用
おわりに
IAM は SAA のすべてのドメインに関わる基盤サービスです。特に「クロスアカウント = IAM ロール + リソースポリシーの両方」「Permissions Boundary はグループに適用不可」「明示的 Deny は常に優先」の3つのルールは、確実に押さえておきましょう。
間違いや補足があればぜひコメントで教えてください。