AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. GuardDutyのサービスリンクロール(AWSServiceRoleForAmazonGuardDuty)に定義されたポリシー内容を、そのままSOCチームのIAMロールへコピーしてアタッチする

サービスリンクロール(SLR)のポリシー内容をコピーしても、それはGuardDuty サービス自身が環境を監視するための権限（ログの読み取りなど）であり、リストを管理するための権限ではありません。
また SLR は AWS が管理する特別なロールで、その内容をコピーした自作ポリシーはSLR そのものを書き換える権限にはならないため、リストの追加・削除は依然として失敗します。
むしろ不要に広い権限を配ることになり、最小権限の原則にも反します。

正解

B. GuardDutyのフルアクセス管理ポリシー(AmazonGuardDutyFullAccess_v2)をSOCチームのIAMロールにアタッチする

GuardDuty の操作権限そのものを与える土台であり、この管理ポリシーが無ければリストの参照・名前変更・無効化すらできません。
公式ドキュメントは現在 AmazonGuardDutyFullAccess_v2 を推奨版として案内しており、これをアタッチした ID はアップロード済みリストの名前変更と無効化までが可能です。
ただしこれだけでは要件のうち「アップロード（追加）」「再有効化」「削除」に届かないため、選択肢 D と組み合わせる必要があります。

C. AWS Configでカスタムルールを作成し、コンプライアンス違反の検知結果をもとにGuardDutyのリスト管理権限を自動的に払い出す仕組みを構築する

AWS Config はリソース構成の評価とコンプライアンス検出のサービスであり、IAM 権限を動的に払い出す仕組みではありません。
権限の付与はあくまで IAM ポリシーの設計で行うものであり、検出結果を起点に権限を配るのは責務の取り違えです。
要件（SOC メンバーにリスト管理権限を与える）に対して過剰かつ的外れな構成で、運用も複雑になります。

正解

D. GuardDutyのサービスリンクロール(AWSServiceRoleForAmazonGuardDuty)に対してiam:PutRolePolicyおよびiam:DeleteRolePolicyアクションを許可するインラインポリシーを、SOCチームのIAMロールに追加する

GuardDuty の信頼できる IP リスト / 脅威 IP リストは、S3 上のリストファイルを読むための権限を SLR のインラインポリシーとして書き込む実装になっています。
そのためリストの追加・有効化・削除・場所や名前の更新を行うには、AWSServiceRoleForAmazonGuardDuty に対する iam:PutRolePolicy と iam:DeleteRolePolicy が必要で、これらは GuardDuty のフルアクセス管理ポリシーに含まれていません。
Resource を当該 SLR の ARN に限定したインラインポリシーを足すのが、公式ドキュメントが示す正しい与え方です。

E. SOCチームのIAMロールにAWSアカウントのルートユーザー認証情報を一時的に共有し、コンソールから直接操作させる

ルートユーザーの認証情報はいかなる理由でも共有してはならないもので、AWS のベストプラクティスでは MFA を有効化して封印し、日常業務では使いません。
そもそも「IAM ロールにルート認証情報を共有する」という操作自体が成立せず、実現手段としても誤りです。
監査証跡が個人に紐づかなくなる点でも、SOC の運用として論外です。

正解への思考ルート

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

要件	判断ポイント
既存リストの名前変更・無効化をさせたい	GuardDuty のフルアクセス管理ポリシー（現行は AmazonGuardDutyFullAccess_v2）が土台。これが無ければ何も操作できない →選択肢（B）は正解の一つ
アップロード（追加）・再有効化・削除まで含む「フル機能」	リストの実体はSLR のインラインポリシーとして S3 読み取り権限が書き込まれる。よって iam:PutRolePolicy / iam:DeleteRolePolicy が別途必要 →選択肢（D）は正解の一つ
権限は「サービスリンクロールを書き換える権限」であって「SLR の中身」ではない	SLR のポリシーをコピーしても GuardDuty サービス用の権限が複製されるだけで、リスト管理には無関係 →選択肢（A）を消す
権限付与の手段は IAM ポリシー設計に限られる	AWS Config は構成評価のサービスで、権限の払い出しは行わない。ルート認証情報の共有は禁止事項 →選択肢（C・E）を消す

ひっかけポイント

• 「フルアクセス管理ポリシーを付けたのだから全部できるはず」が最大の罠。公式ドキュメントはこれらの iam アクションはフルアクセス管理ポリシーに含まれないと明記しており、名前変更と無効化までしかできない
• 選択肢 A は「サービスリンクロールのポリシー」というキーワードで正しそうに見えるが、必要なのはSLR の中身をコピーすることではなくSLR に対して PutRolePolicy できること。似た用語のすり替えに注意
• iam:PutRolePolicy を無制限（Resource "*"）で与えると任意のロールに権限を追加できる＝実質的な権限昇格になる。Resource は AWSServiceRoleForAmazonGuardDuty の ARN に限定するのが必須
• リストの管理はマルチアカウント環境ではGuardDuty 管理者アカウントのみが行える。メンバーアカウントの担当者に同じ権限を配っても要件は満たせない

出題バリエーション

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

問題文がこう変わったら	正解はこう変わる
「リストの参照・無効化だけを許可したい」	フルアクセス管理ポリシー（AmazonGuardDutyFullAccess_v2）だけで足り、iam:PutRolePolicy は不要になる。
「リストファイルを SSE-KMS で暗号化した S3 に置いている」	KMS キーポリシーで AWSServiceRoleForAmazonGuardDuty に kms:Decrypt を許可する必要が追加される。
「IP アドレスだけでなくドメイン名も脅威情報として登録したい」	IP リストではなくエンティティリストを使う。権限も SLR の書き換えではなく、S3 バケットへの s3:GetObject が中心になる。
「特定の IP からの検出結果を抑制したい（リスト運用ではなく）」	信頼できる IP リストではなく抑制ルール（suppression rules）が正解軸になる。

関連サービスの解説

Amazon GuardDuty
AWS Identity and Access Management (AWS IAM)

リファレンス

この問題を解くために必要な知識を扱う公式ドキュメントです。

知識項目	公式ドキュメント
信頼できる IP リスト / 脅威 IP リストの管理に必要な IAM 権限	エンティティリストと IP アドレスリストの前提条件の設定
GuardDuty のリストのアップロードと運用	GuardDuty での信頼できる IP リストと脅威リストの操作
GuardDuty のフルアクセス管理ポリシー（推奨版）	AmazonGuardDutyFullAccess_v2 - AWS Managed Policy