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

ソリューションアーキテクト-プロフェッショナル

正解 C問題
分野3:既存のソリューションの継続的な改善 タスクステートメント3.2:セキュリティを向上させる戦略の決定
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
あなたは、非常に大規模な e コマースサイトの全体的なセキュリティ体制を強化するために雇われました。このサイトは VPC 上で稼働する適切に設計された多層アプリケーションで、Web 層とアプリ層のそれぞれの前段に ELB を配置し、静的アセットは Amazon S3 から直接配信しています。動的データには Amazon RDS と Amazon DynamoDB を組み合わせて使用​​し、Amazon EMR でさらに処理するために毎晩 Amazon S3 へアーカイブしています。最近、疑わしいログエントリが見つかり、SQL インジェクションなどの Web アプリケーション層への攻撃が試みられているのではないかと懸念しています。この種の攻撃に対して費用対効果が高く、スケーラブルな緩和策を提供するアプローチはどれですか。
  • AWS Direct Connect パートナーのロケーションにラックスペースを借り、VPC への 1Gbps の Direct Connect 接続を確立する。そのラックにインターネット回線を引き込み、ハードウェア型の Web アプリケーションファイアウォール (WAF) でトラフィックをフィルタリングしたうえで、Direct Connect 接続を介して VPC 内のアプリケーションへトラフィックを渡す。
  • これまでに特定された攻撃元の送信元 IP アドレスを、Web 層サブネットのネットワーク ACL にインバウンドの DENY ルールとして明示的に追加する。
  • AWS WAF で Web ACL を作成し、SQL インジェクション対策の AWS マネージドルールグループ (AWSManagedRulesSQLiRuleSet など) を適用する。この Web ACL を Web 層の Application Load Balancer、またはサイトの前段に配置する Amazon CloudFront ディストリビューションに関連付け、HTTP リクエストの中身を検査して攻撃パターンをブロックする。AWS WAF はマネージドサービスであり、検査用のインスタンスを自前で用意・運用する必要がなく、リクエスト数に応じた従量課金でトラフィックの増減に自動的に追従する。
  • Web 層の ELB から TLS 1.2 以外のプロトコルをすべて削除し、高度なプロトコルフィルタリングを有効にする。これにより、ELB 自体が WAF の機能を実行できるようになる。
解説 頻出度★★★★
この問題は、「SQL インジェクションなどアプリケーション層(L7)の攻撃 × 費用対効果 × スケーラブル」の要件で、ALB や CloudFront に関連付ける AWS WAF のマネージドルールを選べるかがポイント

A. AWS Direct Connect パートナーのロケーションにラックスペースを借り、VPC への 1Gbps の Direct Connect 接続を確立する。そのラックにインターネット回線を引き込み、ハードウェア型の Web アプリケーションファイアウォール (WAF) でトラフィックをフィルタリングしたうえで、Direct Connect 接続を介して VPC 内のアプリケーションへトラフィックを渡す。

ラックスペースを借りてハードウェア型 WAF を置く構成は、機器購入・ラック賃料・専用線という固定費が先に発生し、「費用対効果が高い」という要件に真っ向から反する。
さらに 1Gbps の Direct Connect が帯域の上限になるため、e コマースサイトの繁忙期にトラフィックが増えてもスケールできない
そもそも AWS Direct Connect はオンプレミス拠点と VPC を結ぶ専用線であり、インターネット上のエンドユーザーの入り口として使う構成ではない。

B. これまでに特定された攻撃元の送信元 IP アドレスを、Web 層サブネットのネットワーク ACL にインバウンドの DENY ルールとして明示的に追加する。

ネットワーク ACL が判断できるのは送信元 IP アドレス・プロトコル・ポートという L3/L4 の情報だけで、HTTP リクエストの中身は一切見ない。SQL インジェクションはクエリ文字列やリクエストボディに潜むため、NACL では検知すらできない。
加えて攻撃元 IP は容易に変えられるので、判明した IP を後から拒否し続けるのはいたちごっこの対症療法にすぎない。
NACL にはルール数の上限もあり、拒否リストを増やし続ける運用は破綻する。

正解

C. AWS WAF で Web ACL を作成し、SQL インジェクション対策の AWS マネージドルールグループ (AWSManagedRulesSQLiRuleSet など) を適用する。この Web ACL を Web 層の Application Load Balancer、またはサイトの前段に配置する Amazon CloudFront ディストリビューションに関連付け、HTTP リクエストの中身を検査して攻撃パターンをブロックする。AWS WAF はマネージドサービスであり、検査用のインスタンスを自前で用意・運用する必要がなく、リクエスト数に応じた従量課金でトラフィックの増減に自動的に追従する。

AWS WAF の Web ACL に AWSManagedRulesSQLiRuleSet(SQL データベース用のマネージドルールグループ)を適用すれば、クエリ文字列・リクエストボディ・ヘッダー・Cookie・URI パスを検査して SQL インジェクションのパターンをブロックできる。ルールの中身は AWS 側で維持されるため、シグネチャの自作・更新が不要。
Web ACL は Application Load Balancer や Amazon CloudFront ディストリビューションに関連付けるだけで有効になり、既存の多層アプリの構成やアプリケーションコードを変えずに導入できる。
マネージドサービスなので検査用インスタンスの構築・パッチ・スケーリングが不要で、リクエスト数に応じた従量課金でトラフィックの増減に自動追従する。費用対効果とスケーラビリティの両方を満たす唯一の選択肢。

D. Web 層の ELB から TLS 1.2 以外のプロトコルをすべて削除し、高度なプロトコルフィルタリングを有効にする。これにより、ELB 自体が WAF の機能を実行できるようになる。

TLS 1.2 に限定するのは通信路の暗号化強度を上げる設定であって、暗号化された中身に SQL インジェクションが含まれていればそのまま素通りする。攻撃者も普通に TLS 1.2 で接続してくる。
また「高度なプロトコルフィルタリングを有効にすれば ELB が WAF として機能する」という記述自体が誤りで、ELB 単体に L7 攻撃を検査する機能はない
ALB が HTTP リクエストの中身を検査できるのは、あくまで AWS WAF の Web ACL を関連付けた場合である。

これだけ覚える(記憶フック)
L7 の攻撃は AWS WAF。ALB か CloudFront に Web ACL を貼るだけで、検査用の箱は要らない。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
懸念しているのは SQL インジェクションなど Web アプリケーション層への攻撃 HTTP リクエストの中身(クエリ文字列・ボディ・ヘッダー)を検査できる仕組みが必須。IP やポート、暗号化設定をいじる対策では止まらない
→選択肢(B・D)を消す
費用対効果が高いこと ラック賃借・専用線・ハードウェア機器はトラフィックが無くても発生する固定費が大きく、要件に反する
→選択肢(A)を消す
スケーラブルであること AWS WAF はマネージド&リクエスト従量課金で増減に自動追従。1Gbps の専用線は帯域が上限で固定
→選択肢(C)は候補
既存は ELB を前段に置いた多層アプリで、静的アセットは S3 から配信 Web ACL は Application Load Balancer や CloudFront に関連付けるだけで導入でき、アプリの再設計もサーバー追加も不要
→選択肢(C)が正解
疑わしいログエントリから攻撃元 IP は判明しているが、攻撃元は変えられる 判明済み IP の拒否リストは後追いの対症療法で、未知の攻撃元には無力
→選択肢(B)を消す
ひっかけポイント
  • 選択肢 A は「専用のハードウェア WAF」という響きが本格的に見えるが、AWS Direct Connect はインターネットからの入り口ではなく拠点間の専用線。エンドユーザーのトラフィックをそこへ通す前提自体が不自然で、コストも帯域上限も要件に反する
  • 「疑わしいログエントリから攻撃元 IP が分かっている」という記述に引っ張られると選択肢 B を選びたくなるが、ネットワーク ACL は L3/L4 しか見ないため、SQL インジェクションというペイロード内の攻撃は原理的に検知できない
  • 選択肢 D の「TLS 1.2 以外を削除」はそれ自体は正しいセキュリティ強化なので選ばれやすい。しかし守るレイヤーが違い、ELB が WAF の機能を実行できるようになるという後半の記述は事実として誤り
  • SAP では「EC2 に WAF ソフトを載せた検査層を Auto Scaling で並べる」自作構成も選択肢に現れる。動作はするがインスタンスの運用とスケーリング設計を自前で抱えるため、マネージドルールを使える AWS WAF より劣る
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「大規模なL3/L4 の DDoSに備えたい」 AWS Shield Advanced(+CloudFront / Route 53)が正解軸に。AWS WAF は L7 担当。
「特定の国からのアクセスだけを遮断したい」 AWS WAF の地理的一致(Geo match)ルールで対応。
「同一 IP からの過剰なリクエストを抑えたい」 AWS WAF のレートベースルールが正解に。
「多数のアカウント・リソースに同じ Web ACL を強制し、逸脱を検出したい」 AWS Firewall Manager による一元管理が正解軸に。
「VPC 内のアウトバウンド通信をドメイン単位でフィルタしたい」 AWS Network Firewall が登場する(L7 でも HTTP アプリ保護とは別物)。
関連サービスの解説 Amazon CloudFront
AWS WAF
Elastic Load Balancing (ELB)
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
SQL インジェクション対策の AWS マネージドルールグループ ユースケース固有のルールグループ - AWS WAF
+ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。(コメント投稿にはログインが必要です)
正答率 97%
No.15 解説
あなたは、非常に大規模な e コマースサイトの全体的なセキュリティ体制を強化するために雇われました。このサイトは VPC 上で稼働する適切に設計された多層アプリケーションで、Web 層とアプリ層のそれぞれの前段に ELB を配置し、静的アセットは Amazon S3 から直接配信しています。動的データには Amazon RDS と Amazon DynamoDB を組み合わせて使用​​し、Amazon EMR でさらに処理するために毎晩 Amazon S3 へアーカイブしています。最近、疑わしいログエントリが見つかり、SQL インジェクションなどの Web アプリケーション層への攻撃が試みられているのではないかと懸念しています。この種の攻撃に対して費用対効果が高く、スケーラブルな緩和策を提供するアプローチはどれですか。
  • AWS Direct Connect パートナーのロケーションにラックスペースを借り、VPC への 1Gbps の Direct Connect 接続を確立する。そのラックにインターネット回線を引き込み、ハードウェア型の Web アプリケーションファイアウォール (WAF) でトラフィックをフィルタリングしたうえで、Direct Connect 接続を介して VPC 内のアプリケーションへトラフィックを渡す。
  • これまでに特定された攻撃元の送信元 IP アドレスを、Web 層サブネットのネットワーク ACL にインバウンドの DENY ルールとして明示的に追加する。
  • AWS WAF で Web ACL を作成し、SQL インジェクション対策の AWS マネージドルールグループ (AWSManagedRulesSQLiRuleSet など) を適用する。この Web ACL を Web 層の Application Load Balancer、またはサイトの前段に配置する Amazon CloudFront ディストリビューションに関連付け、HTTP リクエストの中身を検査して攻撃パターンをブロックする。AWS WAF はマネージドサービスであり、検査用のインスタンスを自前で用意・運用する必要がなく、リクエスト数に応じた従量課金でトラフィックの増減に自動的に追従する。
  • Web 層の ELB から TLS 1.2 以外のプロトコルをすべて削除し、高度なプロトコルフィルタリングを有効にする。これにより、ELB 自体が WAF の機能を実行できるようになる。

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