WEB問題集
ある企業は IAM ロールを使用して、Amazon EC2 インスタンスから S3 バケットへの読み取りを許可しています。バケット所有者は別の AWS アカウントです。バケットポリシーでロール ARN に対する s3:GetObject を許可していますが、アクセスは拒否されます。CloudTrail には AccessDenied と表示されています。セキュリティエンジニアは原因を最も効率的に特定する必要があります。
どの解決策が要件を満たしますか。
正解：B
正解の根拠
クロスアカウント S3 アクセスでは、リクエスタ側の identity-based policy と所有者側の resource-based policy の両方で許可が必要です。バケットポリシーで許可があっても IAM ロール側で s3:GetObject が許可されていなければ AccessDenied になります。両側のポリシーの和集合ではなく積集合に近い評価が行われるため、まず IAM ロール側の権限を確認するのが最短ルートです。
不正解の理由
- A: SG はネットワーク層の制御であり、S3 への HTTPS アウトバウンドは通常許可済みで AccessDenied の原因ではありません。
- C: Block Public Access の解除はセキュリティを大幅に低下させ、原則としての禁則であり対処になりません。
- D: クロスアカウント設計の放棄は要件外であり、根本原因の特定にもなりません。
あるグローバル企業は AWS Organizations を使用しています。開発 OU 配下のすべてのアカウントで、IAM ユーザーの新規作成を組織レベルで完全に禁止する必要があります。アカウント管理者が誤って許可ポリシーを付与した場合でも、IAM ユーザー作成は確実にブロックされる必要があります。
どのアプローチが最も適切ですか。
正解：C
正解の根拠
SCP は OU またはアカウントに対する権限の上限を定義する組織ガードレールであり、たとえメンバーアカウント内で iam:CreateUser を Allow するポリシーが付与されても、SCP の Deny が優先され API がブロックされます。事後検知ではなく予防的コントロールが必要な要件に最適です。
不正解の理由
- A: ルートユーザー常用は重大なリスクで、AWS のベストプラクティスに反します。
- B: Config は事後検知のみで、作成自体をブロックできず予防要件に合致しません。
- D: Athena 毎時クエリは検知遅延が大きく、削除前に悪用される可能性があります。
参考：SCP の概要
ある企業は AWS IAM Identity Center を導入し、複数の AWS アカウントへの SSO を提供しています。財務チームには月次の請求レポート閲覧権限のみを与えたいと考えています。同じ permission set を複数アカウントで使い回し、運用負荷を最小限にする必要があります。
どの設計が最も適切ですか。
正解：A
正解の根拠
IAM Identity Center の permission set は、複数アカウントへ一貫したアクセスを割り当てる仕組みです。Billing マネージドポリシーをアタッチした permission set を作成し、各 AWS アカウントにアサインメントすることで、最小権限と運用効率の両立が図れます。
不正解の理由
- B: アカウント数 × 人数の IAM ユーザー管理は scale せず、ベストプラクティスに反します。
- C: 単一アカウント内のロールでは複数アカウントへの SSO アクセス要件を満たせません。
- D: ルートユーザー共有は最も避けるべきパターンであり、職務分離も成立しません。
セキュリティエンジニアは ABAC を採用し、開発者が自身のプロジェクトタグが付いた EC2 インスタンスのみ起動・停止できるようにしたいと考えています。プロジェクトが追加されてもポリシーを変更せず運用したいです。
どのポリシー条件が要件を満たしますか。
正解：A
正解の根拠
ABAC では、プリンシパルに付与されたタグ (aws:PrincipalTag) とリソースに付与されたタグ (aws:ResourceTag) を比較する条件キーを使い、一致時のみ許可するポリシーを記述します。プロジェクトが増えても、ユーザー/リソース双方に同じタグキーを付ければポリシー変更なしでスケールできます。
不正解の理由
- B: IP 制限はネットワーク条件で、プロジェクト単位のリソース所有制御ではありません。
- C: 時刻条件は営業時間制御で、プロジェクト所有者の検証は実現できません。
- D: MFA 条件は強い認証強制で、プロジェクト一致の検証要件と無関係です。
参考：ABAC の概要
ある企業はクロスアカウントで他社 SaaS ベンダーに IAM ロールへの sts:AssumeRole を許可します。混乱した代理人 (confused deputy) 攻撃を防ぐため、ベンダーが意図せず他顧客のロールを引き受けないようにする必要があります。
どの仕組みを使用すべきですか。
正解：D
正解の根拠
External ID は SaaS ベンダーが他顧客のロールを誤って (または悪意で) 引き受けることを防ぐ AWS 公式の confused deputy 対策です。顧客ごとに一意の external ID を発行し、信頼ポリシーの sts:ExternalId 条件で必須化します。
不正解の理由
- A: アクセスキーの直接共有は最悪のアンチパターンで、漏洩リスクと監査困難を招きます。
- B: ネットワーク層の制御では他顧客との混同問題そのものを防げません。
- C: Principal 指定だけでは、ベンダー内の任意プリンシパルが任意顧客ロールを引き受け得ます。