AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

セキュリティ-専門知識

正解 C問題

分野4：Identity and Access Management タスクステートメント4.1：認証戦略を設計、実装、トラブルシューティングする。

1 2 3 4

次の問題

問題文と選択肢

ある人材紹介会社は、社内で運用しているOktaをIDプロバイダー（IdP）とし、SAML 2.0によるフェデレーションを設定して、Okta側のグループメンバーシップに応じて社員にAWS上の求人管理システムへのアクセス権限を付与したいと考えている。

Oktaのグループ属性に基づいて、AWS側で適切な権限にマッピングするために、AWSアカウント内に作成すべき主要なリソースはどれか。

Oktaのグループ名と同名のIAMグループを作成し、フェデレーションされたユーザーセッションをそのグループに参加させる
OktaをSAML IDプロバイダーとして連携させたAmazon Cognitoユーザープールを作成し、アプリケーション側で発行されたIDトークンを検証する
IAMロールを作成し、信頼ポリシーでOktaのSAML IDプロバイダーからのアサーションを受け入れ、許可ポリシーで必要な権限を定義する
組織のメンバーアカウント全体に適用するサービスコントロールポリシー（SCP）を作成し、Oktaのグループ名を条件キーとして権限を割り当てる

解説頻出度★★★★★

この問題は、「外部 IdP（Okta）× SAML 2.0 × グループに応じた権限付与」の要件で、AWS 側は SAML ID プロバイダーと IAM ロールで受けるというフェデレーションの定石を選べるかがポイント

A. Oktaのグループ名と同名のIAMグループを作成し、フェデレーションされたユーザーセッションをそのグループに参加させる

IAM グループのメンバーになれるのは IAM ユーザーだけです。
SAML でフェデレーションした社員は IAM ユーザーとして存在せず、AssumeRoleWithSAML で発行される一時的なセッションとしてアクセスするため、「グループに参加させる」という操作自体が存在しません。
Okta のグループ名と同じ名前の IAM グループを作っても、権限はどこにも結び付きません。

B. OktaをSAML IDプロバイダーとして連携させたAmazon Cognitoユーザープールを作成し、アプリケーション側で発行されたIDトークンを検証する

Amazon Cognito ユーザープールは SAML IdP と連携できますが、その役割はアプリケーション（Web / モバイル）のサインインと ID トークンの発行です。
ユーザープールが発行する ID トークンはアプリ内の認可に使うもので、AWS API を呼び出す権限（IAM 権限）にはなりません。
AWS の一時認証情報が必要ならさらに ID プールと IAM ロールが要り、そもそも社員（ワークフォース）の AWS アクセスには IAM の SAML フェデレーションや IAM Identity Center を使うのが定石です。

正解

C. IAMロールを作成し、信頼ポリシーでOktaのSAML IDプロバイダーからのアサーションを受け入れ、許可ポリシーで必要な権限を定義する

正解です。AWS アカウントに SAML ID プロバイダー（Okta のメタデータを登録）を作成し、信頼ポリシーでその IdP からのアサーションによる sts:AssumeRoleWithSAML を許可した IAM ロールを用意します。
ロールの許可ポリシーに求人管理システムへ必要な権限を定義すれば、社員は Okta で認証した後にそのロールの一時的な認証情報でアクセスできます。
グループごとの出し分けは、Okta 側が SAML アサーションの Role 属性に「引き受けさせたいロール ARN」を載せることで実現でき、AWS 側はグループ単位にロールを用意するだけで済みます。

D. 組織のメンバーアカウント全体に適用するサービスコントロールポリシー（SCP）を作成し、Oktaのグループ名を条件キーとして権限を割り当てる

サービスコントロールポリシー（SCP）は、メンバーアカウントで使える権限の上限（ガードレール）を定めるだけで、権限を付与することはできません。
SCP をいくら書いても、引き受ける IAM ロールが無ければ社員はサインインすらできません。
また SCP の評価対象は AWS の認証済みプリンシパルであり、Okta のグループ名をそのまま条件キーとして扱うこともできません。

これだけ覚える（記憶フック）
外部 IdP の権限は IAM ロールで受ける。フェデレーテッドユーザーは IAM グループには入れない。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
社内 Okta を IdP とし SAML 2.0 でフェデレーションする	AWS 側の受け口は IAM の SAML ID プロバイダー＋ロールの引き受け（AssumeRoleWithSAML）が唯一の形 →選択肢（C）が正解
Okta のグループメンバーシップに応じて権限を変えたい	IdP が SAML アサーションの Role 属性でロール ARN を送り、AWS 側はグループごとに別ロールを用意する →選択肢（C）が正解
AWS 側に IAM ユーザーは作らない（フェデレーション前提）	IAM グループに入れられるのは IAM ユーザーだけで、一時セッションをグループに所属させる仕組みは無い →選択肢（A）を消す
対象は社員による AWS 上のシステムへのアクセス（ワークフォース）	Cognito ユーザープールはアプリ利用者のサインイン用で、AWS リソースへの IAM 権限を与える仕組みではない →選択肢（B）を消す
「権限を付与する」ためのリソースを問われている	SCP は許可の上限を絞るだけで付与はしないため、これ単体ではアクセスを成立させられない →選択肢（D）を消す

ひっかけポイント

設問の「グループメンバーシップ」に引っ張られて IAM グループを選ばせるのが選択肢 A の罠。グループは IAM ユーザー用の入れ物で、フェデレーションでは登場しない
選択肢 B は「ID プロバイダー」「トークン検証」と語感が合うが、Cognito ユーザープールが出すのはアプリ用の ID トークン。AWS API を呼ぶ一時認証情報は ID プール＋IAM ロールでしか得られない
選択肢 D の SCP は「組織全体に適用」「条件キー」ともっともらしいが、SCP は許可を与えない。付与と制限（ガードレール）の役割の違いを問う定番のひっかけ
グループ → ロールの対応付けは Okta（IdP）側の属性マッピングの仕事。AWS 側でやることは「ID プロバイダーの登録」と「ロールの用意」だけ、という役割分担を押さえる

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「アカウントが多数あり、全社員へ複数アカウントのアクセスを配布したい」	IAM Identity Center（外部 IdP と接続し、許可セットで割り当て）が正解軸に。
「IdP が OpenID Connect（OIDC）を話す／CI/CD や EKS の Pod からアクセスしたい」	IAM の OIDC ID プロバイダー＋AssumeRoleWithWebIdentity が正解に。
「モバイルアプリの一般ユーザーに S3 への直接アクセスを許可したい」	Cognito ID プール（認証済み ID 用の IAM ロール）が正解に。
「1 つのロールのまま、部署などの属性で細かくアクセスを分けたい」	セッションタグ（aws:PrincipalTag）を使った ABAC が正解軸に。
「特定の操作を組織の誰にも実行させないようにしたい」	SCP によるガードレールが正解に。

AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

A. Oktaのグループ名と同名のIAMグループを作成し、フェデレーションされたユーザーセッションをそのグループに参加させる

B. OktaをSAML IDプロバイダーとして連携させたAmazon Cognitoユーザープールを作成し、アプリケーション側で発行されたIDトークンを検証する

C. IAMロールを作成し、信頼ポリシーでOktaのSAML IDプロバイダーからのアサーションを受け入れ、許可ポリシーで必要な権限を定義する

D. 組織のメンバーアカウント全体に適用するサービスコントロールポリシー（SCP）を作成し、Oktaのグループ名を条件キーとして権限を割り当てる

次の問題

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報