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

DevOpsエンジニア-プロフェッショナル

正解 B問題
分野6:セキュリティとコンプライアンス タスクステートメント6.2:セキュリティ統制とデータ保護のための自動化の適用
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
ある学術出版社は、会員向けの論文閲覧サイトを Amazon CloudFront で配信しており、ディストリビューションには AWS WAF のウェブ ACL を関連付けています。このウェブ ACL にはマネージドルールグループが 2 つ登録されているだけで、既定アクションは Allow のままです。

来月から契約形態が変わり、このサイトの利用を提携大学のキャンパスネットワーク経由に限ることが決まりました。提携大学から提示された固定の IPv4 レンジ(198.51.100.0/24 と 203.0.113.128/26)から届いたリクエストにだけコンテンツを返し、それ以外の発信元からのリクエストはすべて拒否しなければなりません。

既存のウェブ ACL をそのまま活かし、新たな構成要素や独自の処理を増やさずにこの制限をかける方法はどれですか。
  • 提携大学の 2 つのレンジを登録した IP セットを作成する。既定アクションは Allow のまま維持し、この IP セットに一致したリクエストを Block するルールを優先度 0 で追加する。
  • 提携大学の 2 つのレンジを登録した IP セットを作成する。既定アクションを Block に変更したうえで、この IP セットに一致したリクエストを Allow とするルールを優先度 0 で追加する。
  • リクエストの X-Forwarded-For ヘッダーに提携大学の IP アドレスが含まれる場合に Allow とする文字列一致ルールステートメントを追加し、既定アクションを Block に変更する。
  • CloudFront のオリジンである Application Load Balancer のセキュリティグループを変更し、提携大学の 2 つのレンジからのインバウンド通信だけを許可する。ウェブ ACL には手を加えない。
解説 頻出度★★★★★
この問題は、「提示されたレンジだけ通す × 既存ウェブ ACL を活かす × 追加の構成要素なし」の要件で、既定アクションを Block に反転し、IP セットに一致したものだけを Allow するという許可リスト型の構成を選べるかがポイント

A. 提携大学の 2 つのレンジを登録した IP セットを作成する。既定アクションは Allow のまま維持し、この IP セットに一致したリクエストを Block するルールを優先度 0 で追加する。

既定アクションが Allow のままだと、どのルールにも一致しなかったリクエストはすべて通過します。そこへ「IP セットに一致したら Block」を足すと、遮断されるのは提携大学からのリクエストだけになり、それ以外の世界中からのアクセスは素通りします。
要件とちょうど正反対の挙動になる、拒否リスト型の構成です。

正解

B. 提携大学の 2 つのレンジを登録した IP セットを作成する。既定アクションを Block に変更したうえで、この IP セットに一致したリクエストを Allow とするルールを優先度 0 で追加する。

正解です。既定アクションを Block にすると、どのルールにも一致しなかったリクエストは拒否されます。そのうえで提携大学の 2 レンジを登録した IP セットに一致したリクエストだけを Allow するルールを置けば、「提携レンジだけ通し、他はすべて拒否」という許可リストが完成します。
AWS WAF の IP セットは CIDR 表記をそのまま登録できるため、198.51.100.0/24 と 203.0.113.128/26 を 1 つの IP セットにまとめられます。
既存のマネージドルールグループ 2 つはそのまま残せて、追加するのは IP セットとルール 1 本だけ。新しいサービスも独自処理も増やさずに要件を満たせます。

C. リクエストの X-Forwarded-For ヘッダーに提携大学の IP アドレスが含まれる場合に Allow とする文字列一致ルールステートメントを追加し、既定アクションを Block に変更する。

文字列一致ルールステートメントは文字列としての一致しか判定できないため、198.51.100.0/24 のような CIDR レンジを表現できません。256 個のアドレスを列挙するような運用になり、「独自の処理を増やさない」という条件に反します。
さらに X-Forwarded-For はクライアントが偽装した値がそのまま前方に残るヘッダーで、単純な部分一致では偽装値を拾ってしまいます。
AWS WAF には送信元 IP を正しく評価する IP セットという専用の仕組みがあるため、この方法を選ぶ理由がありません。

D. CloudFront のオリジンである Application Load Balancer のセキュリティグループを変更し、提携大学の 2 つのレンジからのインバウンド通信だけを許可する。ウェブ ACL には手を加えない。

CloudFront 経由のリクエストは、オリジンの Application Load Balancer から見ると送信元がクライアントではなく CloudFront のエッジの IP アドレスになります。提携大学のレンジだけを許可すると、CloudFront からの通信が届かなくなり全利用者がアクセスできなくなります
クライアント IP による制御は、ビューワーに最も近い CloudFront 側(=関連付けたウェブ ACL)で行うのが正しい層です。
「ウェブ ACL には手を加えない」という点でも、既存のウェブ ACL を活かすという要件から外れています。

これだけ覚える(記憶フック)
許可リストを作るなら既定アクションは Block。Allow のまま Block ルールを足すのは拒否リストの発想。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
提携レンジ以外からのリクエストはすべて拒否する 「明示的に許可したものだけ通す」許可リスト型。既定アクションを Block に反転させる必要がある
→選択肢(A)を消す
提携大学から固定の IPv4 レンジ(CIDR)を提示されている AWS WAF の IP セットは CIDR をそのまま登録できる専用の仕組み。レンジ判定はここに任せる
→選択肢(B)が正解
新たな構成要素や独自の処理を増やさない 文字列一致ではCIDR を表現できず、アドレス列挙や偽装対策という独自処理が必要になる
→選択肢(C)を消す
CloudFront で配信しており、判定したいのはビューワーの IP オリジン側から見た送信元はCloudFront のエッジ IP。クライアント IP では制御できない
→選択肢(D)を消す
既存のウェブ ACL とマネージドルールグループはそのまま活かす 既定アクションの変更とルール 1 本の追加だけで完結する構成が最小
→選択肢(B)が正解
ひっかけポイント
  • 選択肢 A と B は「IP セットを作る」ところまで同一で、違うのは既定アクションと一致時のアクションの向きだけ。許可リストか拒否リストかを読み分けさせるのが本問の核心
  • 既定アクションを Allow のまま残すと「明示的に Block したもの以外は全部通る」。「それ以外はすべて拒否」という要件は、既定アクション Block でしか実現できない
  • 選択肢 D はネットワーク層で堅く見えるが、CloudFront を挟んだ時点で ALB に届く送信元はエッジの IP。「オリジンのセキュリティグループでクライアント IP を絞る」は成立しない
  • 優先度 0 に置いた Allow ルールに一致したリクエストはそこでウェブ ACL の評価が終了し、後続のマネージドルールグループの検査を受けない。設問は IP 制限の方法を問うているため B が正解だが、実運用では優先度の置き方が別途論点になる
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「提携大学からのリクエストもマネージドルールで検査したい」に変わったら Allow ルールの優先度をマネージドルールグループより後ろに下げる構成が正解軸に。
「アクセスを国単位で制限したい」に変わったら IP セットではなく地理的一致(Geo match)ルールステートメントが正解に。
「提携レンジが頻繁に追加・変更される」に変わったら ウェブ ACL は触らず IP セットだけを API で更新する運用(Lambda 等)が論点に。
オリジンへの直接アクセスも塞ぎたい」に変わったら CloudFront の OAC やカスタムヘッダー検証、ALB を CloudFront のマネージドプレフィックスリストで絞る構成に。
「特定 IP からのリクエスト数だけ制限したい」に変わったら Block ではなくレートベースルール(IP 単位のしきい値)が正解軸に。
関連サービスの解説 Amazon CloudFront
AWS WAF
+ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。(コメント投稿にはログインが必要です)
正答率 0%
No.7 解説
ある学術出版社は、会員向けの論文閲覧サイトを Amazon CloudFront で配信しており、ディストリビューションには AWS WAF のウェブ ACL を関連付けています。このウェブ ACL にはマネージドルールグループが 2 つ登録されているだけで、既定アクションは Allow のままです。

来月から契約形態が変わり、このサイトの利用を提携大学のキャンパスネットワーク経由に限ることが決まりました。提携大学から提示された固定の IPv4 レンジ(198.51.100.0/24 と 203.0.113.128/26)から届いたリクエストにだけコンテンツを返し、それ以外の発信元からのリクエストはすべて拒否しなければなりません。

既存のウェブ ACL をそのまま活かし、新たな構成要素や独自の処理を増やさずにこの制限をかける方法はどれですか。
  • 提携大学の 2 つのレンジを登録した IP セットを作成する。既定アクションは Allow のまま維持し、この IP セットに一致したリクエストを Block するルールを優先度 0 で追加する。
  • 提携大学の 2 つのレンジを登録した IP セットを作成する。既定アクションを Block に変更したうえで、この IP セットに一致したリクエストを Allow とするルールを優先度 0 で追加する。
  • リクエストの X-Forwarded-For ヘッダーに提携大学の IP アドレスが含まれる場合に Allow とする文字列一致ルールステートメントを追加し、既定アクションを Block に変更する。
  • CloudFront のオリジンである Application Load Balancer のセキュリティグループを変更し、提携大学の 2 つのレンジからのインバウンド通信だけを許可する。ウェブ ACL には手を加えない。

(会員限定)当問題の評価をお願いします。改善に活用します。