AWS認定資格 WEB問題集&徹底解説
セキュリティ-専門知識
問題文と選択肢
セキュリティエンジニアが検討すべきDDoS対策のベストプラクティスとして適切なものはどれか。(3つ選択)
- AWS Shield Advancedを契約している場合、Elastic IPアドレスを保護対象リソースとして登録できる。登録しておくことで攻撃をより早く検知でき、緩和までの時間を短縮できる
- Application Load Balancerにアタッチするセキュリティグループは、コネクション追跡(connection tracking)を行わない設定にすることが推奨される。追跡対象のコネクション数上限に達すると、DDoS攻撃時に新規の接続を確立できなくなるおそれがあるためである
- Amazon CloudFrontとAWS WAFをAmazon API Gatewayのリージョンエンドポイントと組み合わせて使う場合、ディストリビューションのキャッシュビヘイビアで全ヘッダーをAPI Gatewayへ転送するよう設定する。これによりCloudFrontはコンテンツを動的なものとして扱い、キャッシュをスキップする
- コンテンツベースのルーティングや、リクエストが正しい形式かどうかのチェックが必要であれば、Application Load BalancerではなくNetwork Load Balancerを使うことで、SYNフラッドなど一般的なDDoS攻撃の多くをブロックできる
- 重要データを格納するAmazon S3バケットに、AWS WAFのWeb ACLを直接アタッチし、リクエストシグネチャに基づいてフィルタリングする
- エッジでのDDoS吸収帯域を確保するには、AWS Global Acceleratorを導入するよりも、Amazon Route 53のレイテンシーベースルーティングだけで十分であり、追加のサービスは不要である
A. AWS Shield Advancedを契約している場合、Elastic IPアドレスを保護対象リソースとして登録できる。登録しておくことで攻撃をより早く検知でき、緩和までの時間を短縮できる
AWS Shield Advanced では、Elastic IP アドレスを保護対象リソースとして登録できます。登録されたリソースへの攻撃はより早く検知され、緩和までの時間が短縮されます。
攻撃検知時には、対象の Elastic IP に対応するネットワーク ACL をサブネットではなく AWS ネットワークの境界で適用するため、インフラ層への攻撃の影響を大幅に減らせます。
公式のベストプラクティスに沿った正しい記述です。
B. Application Load Balancerにアタッチするセキュリティグループは、コネクション追跡(connection tracking)を行わない設定にすることが推奨される。追跡対象のコネクション数上限に達すると、DDoS攻撃時に新規の接続を確立できなくなるおそれがあるためである
ロードバランサーにアタッチしたセキュリティグループは既定でコネクションを追跡しますが、追跡テーブルの上限に達すると新規接続が確立できなくなるため、DDoS 攻撃時のリスクになります。
リスナーポートへのインバウンドを 0.0.0.0/0 で許可し、対応するアウトバウンドもすべて許可した状態にすると、その通信は「追跡されない(untracked)」フローとして扱われ、パケット処理のスループットとスケーリングが阻害されません。
そのうえでバックエンドのサブネットはネットワーク ACL でロードバランサーの範囲に絞る、という組み合わせが推奨される形です。
C. Amazon CloudFrontとAWS WAFをAmazon API Gatewayのリージョンエンドポイントと組み合わせて使う場合、ディストリビューションのキャッシュビヘイビアで全ヘッダーをAPI Gatewayへ転送するよう設定する。これによりCloudFrontはコンテンツを動的なものとして扱い、キャッシュをスキップする
API Gateway のリージョンエンドポイントを自前の CloudFront ディストリビューションの背後に置くと、AWS WAF をエッジで適用でき、AWS グローバルエッジネットワークの大規模な緩和能力を利用できます。
この構成では、キャッシュビヘイビアで全ヘッダーをオリジンへ転送する設定が推奨されます。CloudFront はコンテンツを動的なものとして扱いキャッシュをスキップするため、API の応答が誤ってキャッシュされる事故を防げます。
公式のベストプラクティスに明記された構成であり、正しい記述です。
D. コンテンツベースのルーティングや、リクエストが正しい形式かどうかのチェックが必要であれば、Application Load BalancerではなくNetwork Load Balancerを使うことで、SYNフラッドなど一般的なDDoS攻撃の多くをブロックできる
説明が逆です。コンテンツベースのルーティング(パス/ホストベース)やリクエストの形式検査は Application Load Balancer の機能であり、レイヤー 4 で動作する Network Load Balancer は HTTP の内容を解釈しません。
ALB は不正な形式の HTTP リクエストを受け付けずに落とすため、この用途では ALB を選ぶのが正解です。
「SYN フラッドをブロックできるから NLB」という結び付けも、ALB / NLB のいずれもマネージドに緩和される点を無視した誤った理由付けです。
E. 重要データを格納するAmazon S3バケットに、AWS WAFのWeb ACLを直接アタッチし、リクエストシグネチャに基づいてフィルタリングする
AWS WAF の Web ACL は Amazon S3 バケットに直接アタッチできません。関連付けられるのは CloudFront ディストリビューション、Application Load Balancer、Amazon API Gateway、AWS AppSync、Amazon Cognito ユーザープールなどです。
S3 上のコンテンツをフィルタリングしたい場合は、CloudFront をオリジンアクセスコントロール(OAC)付きで前段に置き、その CloudFront に Web ACL を関連付けるのが正しい構成です。
実現不可能な構成であり、誤りです。
F. エッジでのDDoS吸収帯域を確保するには、AWS Global Acceleratorを導入するよりも、Amazon Route 53のレイテンシーベースルーティングだけで十分であり、追加のサービスは不要である
Amazon Route 53 のレイテンシーベースルーティングはDNS による宛先の振り分けにすぎず、それ自体が攻撃トラフィックを吸収するわけではありません。
AWS Global Accelerator はエッジロケーションでトラフィックを受けて AWS のバックボーンへ引き込むため、非 HTTP のワークロードでも大規模な DDoS 緩和能力を活用でき、Shield による保護の対象にもなります。
「Route 53 だけで十分」という結論は、エッジで受けるという DDoS 耐性の基本設計に反しています。
DDoS 耐性は「エッジで受け、追跡させず、動的はキャッシュしない」。WAF は S3 には付かない。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| エッジで攻撃を受け止める(インフラ層の緩和) | Shield Advanced にElastic IP を保護対象登録すると検知が早まり、緩和が AWS ネットワーク境界で適用される。Global Accelerator もエッジ吸収の手段 →選択肢(A)が正解、選択肢(F)を消す |
| ロードバランサーの接続処理を詰まらせない | セキュリティグループのコネクション追跡テーブルの枯渇を避ける(untracked なルール設計) →選択肢(B)が正解 |
| API を CloudFront + AWS WAF で守る | リージョンエンドポイント+自前ディストリビューション。全ヘッダー転送でキャッシュをスキップさせ、動的コンテンツとして扱わせる →選択肢(C)が正解 |
| L7 の検査・ルーティングが必要かどうか | コンテンツベースルーティングとリクエスト形式チェックは ALB の機能。NLB は L4 で HTTP を解釈しない →選択肢(D)を消す |
| AWS WAF を関連付けられるリソースはどれか | CloudFront / ALB / API Gateway / AppSync / Cognito など。S3 バケットには直接アタッチできない →選択肢(E)を消す |
ひっかけポイント
- 選択肢 D は「ALB ではなく NLB」と役割を入れ替えた典型的な引っかけ。コンテンツベースルーティングやリクエスト形式チェックを挙げている時点で ALB の説明であり、結論が逆になっている
- 選択肢 E の「S3 に Web ACL を直接アタッチ」は実在しない構成。S3 を守るなら CloudFront を前段に置き、そこへ WAF を関連付けるという一段の間接が必要
- 選択肢 C は「全ヘッダーを転送するとキャッシュされない」という一見不利に思える挙動がむしろ推奨という点が理解しづらい。API のレスポンスは動的であり、誤ってキャッシュされる方が事故になる
- セキュリティグループの追跡は「ステートフルで便利」と覚えていると選択肢 B を切りたくなるが、DDoS の文脈では追跡テーブルの上限が新規接続を阻むという逆の側面が問われる
- 選択肢 F の「Route 53 だけで十分」のように、追加のサービスは不要と断言する選択肢はベストプラクティス問題ではまず誤り。DNS の振り分けは攻撃トラフィックの吸収とは別物
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「保護対象が非 HTTP(UDP/TCP)のゲームサーバー」 | CloudFront ではなく AWS Global Accelerator + Shield Advanced でエッジ吸収する構成が正解軸になる。 |
| 「アプリケーション層の大量リクエストを制限したい」 | AWS WAF のレートベースルール(動的エンドポイントには低いしきい値で絞り込む)が正解軸に。 |
| 「攻撃時に専門家の支援と料金保護を受けたい」 | Shield Advanced の Shield レスポンスチーム(SRT) とコスト保護(スケーリング費用の返金)が答えになる。 |
| 「オリジンを直接叩かれないようにしたい」 | CloudFront のカスタムヘッダー検証+オリジン側で CloudFront の IP 範囲のみ許可、S3 なら OAC で直アクセスを遮断する。 |
| 「攻撃の検知と可視化を強化したい」 | Shield Advanced のグローバル脅威ダッシュボード、CloudWatch メトリクス(DDoSDetected)とアラームによる通知が正解軸になる。 |
リファレンス
この問題を解くために必要な知識を扱う公式ドキュメントです。| 知識項目 | 公式ドキュメント |
|---|---|
| Shield Advanced の保護対象としての Elastic IP と、DDoS 緩和のためのセキュリティグループ / ネットワーク ACL 設計 | Security groups and network ACLs (BP5) - AWS Best Practices for DDoS Resiliency |
| API Gateway のリージョンエンドポイントを CloudFront + AWS WAF で保護する(全ヘッダー転送でキャッシュをスキップ) | Protecting API endpoints (BP4) - AWS Best Practices for DDoS Resiliency |
| ロードバランサーのセキュリティグループとコネクション追跡(untracked 設計) | Infrastructure Protection - ELB Best Practices Guides |
セキュリティエンジニアが検討すべきDDoS対策のベストプラクティスとして適切なものはどれか。(3つ選択)
- AWS Shield Advancedを契約している場合、Elastic IPアドレスを保護対象リソースとして登録できる。登録しておくことで攻撃をより早く検知でき、緩和までの時間を短縮できる
- Application Load Balancerにアタッチするセキュリティグループは、コネクション追跡(connection tracking)を行わない設定にすることが推奨される。追跡対象のコネクション数上限に達すると、DDoS攻撃時に新規の接続を確立できなくなるおそれがあるためである
- Amazon CloudFrontとAWS WAFをAmazon API Gatewayのリージョンエンドポイントと組み合わせて使う場合、ディストリビューションのキャッシュビヘイビアで全ヘッダーをAPI Gatewayへ転送するよう設定する。これによりCloudFrontはコンテンツを動的なものとして扱い、キャッシュをスキップする
- コンテンツベースのルーティングや、リクエストが正しい形式かどうかのチェックが必要であれば、Application Load BalancerではなくNetwork Load Balancerを使うことで、SYNフラッドなど一般的なDDoS攻撃の多くをブロックできる
- 重要データを格納するAmazon S3バケットに、AWS WAFのWeb ACLを直接アタッチし、リクエストシグネチャに基づいてフィルタリングする
- エッジでのDDoS吸収帯域を確保するには、AWS Global Acceleratorを導入するよりも、Amazon Route 53のレイテンシーベースルーティングだけで十分であり、追加のサービスは不要である
次の問題前の問題
会員機能
お役立ち情報
- プレミアム会員のご紹介
- 「徹底解説」のご紹介
- 「模擬試験」のご紹介
- 収録問題と試験ガイドの対応
- 会員機能のご紹介
- おすすめの勉強方法
- AWSサービスの解説
- AWS認定資格の種類・対象者・受験料・合格ライン
- スマホのホーム画面に登録する方法
姉妹サイト
- CLF:AWS 認定クラウドプラクティショナー
- SAA:AWS 認定ソリューションアーキテクト-アソシエイト
- AIF:AWS 認定AIプラクティショナー
- SOA:AWS 認定CloudOpsエンジニア-アソシエイト
- DVA:AWS 認定デベロッパー-アソシエイト
- DEA:AWS 認定データエンジニア-アソシエイト
- MLA:AWS 認定機械学習エンジニア-アソシエイト
- SAP:AWS 認定ソリューションアーキテクト-プロフェッショナル
- DOP:AWS 認定DevOpsエンジニア-プロフェッショナル
- AIP:AWS 認定生成AIデベロッパー-プロフェッショナル
- SCS:AWS 認定セキュリティ-専門知識
- AZ-900:Microsoft Azure Fundamentals
- AI-900:Microsoft Azure AI Fundamentals