AWS 認定資格 ラボ
SAA（Solutions Architect Associate）攻略 ・

SAA IAM 設計問題の頻出パターン10選｜ロール・ポリシー評価ロジック・クロスアカウント・SCP を要件文で即断する

AWS SAA-C03 で IAM は配点30%の最重要ドメイン1（セキュアなアーキテクチャ）の中核として毎回問われる。本記事は IAM 設計問題を「誰に権限を渡すか（主体）／どう許可を与えるか（ポリシーの種類）／どう評価されるか（許可と拒否の優先順位）／どう横断で制御するか（組織・境界）」の頻出10パターンに分解する。アクセスキーではなくロール、ユーザー直付けではなくグループ、クロスアカウントは AssumeRole、明示的 Deny が常に勝つ、SCP はガードレール——要件文のどのキーワードが正解を一意に決めるかを示す。結論は「IAM 設計問題は暗記ではなく、主体・ポリシー種別・評価順・横断ガバナンスの4評価軸で解く」こと。

#AWS #SAA #SAA-C03 #Solutions Architect #IAM #IAMロール #IAMポリシー #クロスアカウント #SCP #最小権限 #試験対策 #AWS認定資格

IAM 設計問題を「ユーザーを作ってポリシーを付ける仕組み」で片づけようとすると、ロールとアクセスキーの使い分け・ポリシー評価の優先順位・クロスアカウントの信頼関係・SCP と許可境界の役割で足をすくわれる。 SAA-C03 で AWS IAM は、配点30%と最大のドメイン1（セキュアなアーキテクチャの設計）の中核であり、他ドメインの設問にも認証・認可の前提として顔を出す最頻出テーマだ。だが問われるのは「機能の暗記」ではなく、誰に権限を渡すのか・どうやって許可を与えるのか・許可と拒否がどう評価されるのか・組織全体でどう横断制御するのかという設計判断である。攻略の鍵は、頻出テーマを「主体の選択」「ポリシーの種類とクロスアカウント」「評価ロジック」「横断ガバナンス」の4系統×10パターンに畳み、要件文のキーワードから正解を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、IAM 設計問題の頻出10パターンを分解する。読み終えれば、「最も安全で、かつ運用負荷の低いアクセス制御はどれか」という問いに、迷わず正解を当てられるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

📑 目次

  1. 結論：IAM 設計問題は「4つの評価軸」で解く
  2. パターン1〜2：主体の選択（サービスにはロール・ユーザー直付けは避ける）
  3. パターン3〜4：ポリシーの種類とクロスアカウント（AssumeRole）
  4. パターン5：評価ロジック（明示的 Deny が常に勝つ）の最頻出の罠
  5. パターン6〜7：フェデレーションと一時的認証情報（Identity Center・STS）
  6. パターン8〜10：横断ガバナンス（SCP・許可境界・条件と MFA）
  7. 頻出ひっかけパターンと打ち手の整理
  8. 次のアクション チェックリスト
  9. 関連記事
  10. 関連サイト

1. 結論：IAM 設計問題は「4つの評価軸」で解く

SAA-C03 の IAM 設計問題を最短で解く骨格は、**「要件文が4つの評価軸——誰に権限を渡すか・どうやって許可を与えるか・許可と拒否がどう評価されるか・組織全体でどう制御するか——のどれを問うているかを特定し、その軸で選択肢を振るう」**ことだ。これが本記事の結論である。

理由は明快で、IAM の登場人物はどれも「ある評価軸を制御するための道具」だからだ。IAM ロールとアクセスキーの選択は「誰に・どう権限を渡すか」を、アイデンティティベース／リソースベースのポリシーは「どうやって許可を与えるか」を、明示的 Deny・暗黙的 Deny・明示的 Allow の優先順位は「どう評価されるか」を、SCP・許可境界・IAM Identity Center は「組織全体でどう横断制御するか」を担う。つまり要件文のキーワードが軸を指し示し、軸が正解の設定を一意に決める構造になっている。

具体例で見よう。「EC2 上のアプリから S3 にアクセスさせたい」——主体の軸だから IAM ロール（アクセスキーは埋め込まない）。「別アカウントのユーザーに自社バケットを触らせたい」——ポリシーとクロスアカウントの軸だから ロールの AssumeRole またはバケットポリシー。「管理者ポリシーを付けたのに特定操作だけ拒否される」——評価ロジックの軸だから どこかに明示的 Deny がある。「組織の全アカウントで特定リージョンの利用を禁止したい」——横断ガバナンスの軸だから SCP。ここで「とりあえず強い権限を付ければ動く」と考えると、最小権限や評価順を問う設問で誤答する。軸で解く——この一点が IAM 設計問題の攻略法だ。

2. パターン1〜2：主体の選択（サービスにはロール・ユーザー直付けは避ける）

パターン1：アクセスキーではなく IAM ロール（サービスへの権限付与の鉄則）

IAM 設計で最初に反射で引くべきのがこれだ。AWS のサービスやアプリケーションに権限を与えるときは、アクセスキーを埋め込むのではなく IAM ロールを使う。

  • EC2 上のアプリから S3 / DynamoDB にアクセス → EC2 インスタンスプロファイル（ロール）をアタッチ：コードや設定ファイルにアクセスキーを書くのは誤答。ロールなら一時的な認証情報が自動でローテーションされ、鍵の漏洩・失効管理が不要になる。
  • Lambda から他サービスへアクセス → Lambda 実行ロール：関数に付与したロールの権限で動く。
  • オンプレや外部からの一時アクセス → ロールを AssumeRole：長期のアクセスキー発行より安全。

パターン2：ユーザーへの直付けではなくグループ／ロールで管理（最小権限）

人間のユーザーが多数いる場合、個々の IAM ユーザーにポリシーを直接アタッチするのは運用が破綻する。役割ごとに IAM グループを作り、グループにポリシーを付けてユーザーを所属させる。これで「開発者グループ」「監査グループ」のように権限をまとめて管理でき、最小権限の原則（必要な権限だけを与える）を保ちやすい。

3. パターン3〜4：ポリシーの種類とクロスアカウント（AssumeRole）

パターン3：アイデンティティベース vs リソースベースポリシー

ポリシーには大きく2種類あり、「誰に貼るか」で使い分ける。

  • アイデンティティベースポリシー：IAM ユーザー・グループ・ロールに貼る。「この主体は何をできるか」を定義する。
  • リソースベースポリシー：S3 バケットポリシー、KMS キーポリシー、SQS キューポリシーなど、リソース側に貼る。「このリソースに誰がアクセスできるか」を定義し、別アカウントのプリンシパルを直接指定できるのが特徴。
ポリシーの種類の使い分け（要件キーワード → 正解）
評価項目
アイデンティティベース 推奨
リソースベース
貼る対象 ユーザー・グループ・ロール S3・KMS・SQS などのリソース
答える問い この主体は何ができるか このリソースに誰が触れるか
クロスアカウント ロールの引き受けで実現 別アカウントを直接許可できる
代表用途 社内ユーザーの権限設計 S3 バケットへの外部公開・共有
同一アカウント内なら両者の許可は『和（どちらかで許可されれば OK）』。迷ったら『主体に付ける＝アイデンティティ』『モノに付ける＝リソース』。

パターン4：クロスアカウントアクセスは AssumeRole（信頼ポリシー＋許可ポリシーの2枚）

「アカウント B のユーザーに、アカウント A のリソースを操作させたい」——これはクロスアカウントの鉄板パターンだ。アカウント A にロールを作り、次の2枚のポリシーで構成する。

  • 信頼ポリシー（Trust Policy）：「誰がこのロールを引き受けられるか」を定義。ここにアカウント B を信頼相手として指定する。
  • 許可ポリシー（Permissions Policy）：「このロールで何ができるか」を定義。

アカウント B 側のユーザーは STS の AssumeRole でこのロールを引き受け、一時的な認証情報を得て A のリソースを操作する。

4. パターン5：評価ロジック（明示的 Deny が常に勝つ）の最頻出の罠

IAM 設計問題で最も間違えやすく、最も出題頻度が高いのがポリシー評価ロジックだ。単独のセクションとして押さえたい。

AWS がアクセス可否を判定する順序はシンプルなルールに従う。

  • デフォルトは暗黙的 Deny：何も許可されていなければ拒否。
  • 明示的 Allow が1つでもあれば許可：アイデンティティ／リソースいずれかのポリシーで許可されれば通る（同一アカウント内は和）。
  • 明示的 Deny があれば、Allow の有無に関わらず必ず拒否：どこか1つのポリシーに Deny があれば、他の全てが Allow でも最終結果は拒否。

あわせて、リソースベースポリシーとの関係も押さえたい。同一アカウント内なら、アイデンティティベースとリソースベースは「どちらかで許可されれば OK（和）」。だがクロスアカウントでは、引き受け先の許可と、リソース側の許可の両方が必要になる場面がある。「同一アカウント＝和、跨ぐと双方の許可が要る」と整理しておこう。

5. パターン6〜7：フェデレーションと一時的認証情報（Identity Center・STS）

パターン6：外部 ID との連携（フェデレーション）

「既存の社内 Active Directory / IdP のアカウントで AWS にログインさせたい」「アプリのエンドユーザーを認証したい」——IAM ユーザーを人数分作るのは誤答だ。用途で使い分ける。

  • 社員の SSO・複数アカウント横断アクセス → IAM Identity Center（旧 AWS SSO）：Organizations 配下の複数アカウントに、外部 IdP（SAML）や内蔵ディレクトリの ID で一元的にサインインさせる。マルチアカウント環境の標準解。
  • モバイル／Web アプリのエンドユーザー認証 → Amazon Cognito：数百万規模のユーザー認証と、一時的な AWS 認証情報の払い出しに使う。
  • 企業 IdP との SAML 2.0 フェデレーション：オンプレ AD と連携し、IAM ロールにマッピングしてアクセスさせる。

パターン7：一時的認証情報（STS）と長期キーの回避

フェデレーションやロールの引き受けの裏側で動くのが STS（Security Token Service） だ。AssumeRole すると STS が有効期限付きの一時認証情報を発行する。長期のアクセスキーと違い、期限切れで自動失効するため漏洩時の被害が限定される。「認証情報のローテーション運用を無くしたい」「一時的にだけ権限を渡したい」という要件は、一時認証情報（ロール／STS）が答えだ。

6. パターン8〜10：横断ガバナンス（SCP・許可境界・条件と MFA）

パターン8：SCP（Organizations）はアカウント全体の上限＝ガードレール

サービスコントロールポリシー（SCP）は、AWS Organizations で組織／OU／アカウント単位に適用する**権限の上限（ガードレール）だ。重要なのは、SCP 自体は権限を「付与」しないこと。あくまで「アカウント内の IAM がどこまで許可できるかの天井」を決める。実効権限は SCP と IAM ポリシーの交差（両方が許可した分だけ）**になる。

パターン9：許可境界（Permission Boundary）で委任時の最大権限を絞る

「開発者に IAM ロールの作成を許可したいが、作れるロールの権限が強くなりすぎるのを防ぎたい」——これは許可境界（Permissions Boundary）だ。IAM エンティティ（ユーザー／ロール）に付与できる最大権限の枠を定義し、権限委任を安全にする。実効権限は、アイデンティティベースポリシーと許可境界の交差になる。

横断ガバナンスの使い分け（要件キーワード → 正解）
評価項目
SCP 推奨
許可境界
IAM ポリシー
適用単位 組織・OU・アカウント IAM ユーザー／ロール個別 ユーザー／グループ／ロール
役割 アカウントの権限上限 委任時の権限上限 実際に権限を付与
許可するか しない（上限のみ） しない（上限のみ） する
キーワード 「組織全体で禁止」 「権限委任を安全に」 「この主体に許可」
SCP と許可境界は『天井』、IAM ポリシーが『実際の許可』。実効権限は全ての交差で決まる。

パターン10：条件（Condition）・MFA・IAM Access Analyzer

最後に、細かな制御と検証の道具を押さえる。

  • 条件キー（Condition）：ポリシーに aws:SourceIp（特定 IP のみ）、aws:MultiFactorAuthPresent（MFA 必須）、aws:RequestedRegion などの条件を付け、アクセスを絞る。「MFA なしでは削除させない」「社内 IP からのみ許可」は条件で実装する。
  • MFA とルートユーザー保護：ルートユーザーは日常利用せず MFA を有効化し、重要操作は MFA 必須にするのがベストプラクティス。
  • IAM Access Analyzer：外部（別アカウント・公開）からアクセス可能なリソースを検出し、意図しない共有を洗い出す。「誰が外部からアクセスできるかを可視化・監査したい」なら Access Analyzer。

7. 頻出ひっかけパターンと打ち手の整理

IAM 設計問題は、正しい打ち手と“やりがちな誤答”が明確に対になっている。表で押さえれば本番で機械的に振るえる。

8. 次のアクション チェックリスト

IAM 設計パターンを、今日からの学習に落とし込むための具体アクションをまとめる。

9. 関連記事

10. 関連サイト

AWS 公式