CloudFront 経由以外のオリジンアクセスの遮断
オンライン学習プラットフォームを提供する企業が、Amazon EC2 インスタンス上で REST API を稼働させています。EC2 インスタンスは 3 つのプライベートサブネットに配置された Auto Scaling グループで実行され、その前段の Application Load Balancer (ALB) は 3 つのパブリックサブネットに配置されています。同社は、この ALB を唯一のオリジンとする Amazon CloudFront ディストリビューションをデプロイしました。しかし現状では、CloudFront を経由せずに ALB の DNS 名へ直接リクエストを送ることでも API に到達できてしまいます。オリジンのセキュリティを強化するために、ソリューションアーキテクトが推奨すべきソリューションはどれですか。
解説を読む（正解: B）
CloudFront をウェブアプリケーションの前面に置いても、オリジンであるインターネット向け ALB のエンドポイントが公開されたままでは、攻撃者が CloudFront を迂回して直接オリジンを攻撃できてしまいます。ALB をオリジンとする場合の代表的な保護策は、CloudFront がオリジンへ転送するリクエストに秘密の値を持つカスタム HTTP ヘッダーを付与し、オリジン側でそのヘッダーが存在し値が一致するリクエストだけを通す方法です。ALB には AWS WAF のウェブ ACL を関連付けられるため、ヘッダーに対する文字列一致ルールを条件として、条件を満たさないリクエストをブロックできます。秘密の値は AWS Secrets Manager に保管し、Lambda 関数によるローテーションで定期的に更新すれば、値が漏えいした場合の影響も限定できます。正解の選択肢はこの構成をそのまま示しています。CloudFront の IP アドレス範囲を許可条件にしたうえで ALB をプライベートサブネットへ移動する選択肢は、内部向け ALB がインターネットから到達できなくなり CloudFront からのアクセス自体が成立しないため、アプリケーションが停止します。Systems Manager Parameter Store を使う選択肢は、Parameter Store にシークレットの自動ローテーション機能が組み込まれていないうえ、ALB 自体には HTTP ヘッダーの値を検査してリクエストを拒否する機能がなく (リスナールールのヘッダー条件は転送先の振り分けが目的で、AWS WAF のようなセキュリティ制御として設計されていません)、記述どおりには実装できません。AWS Shield Advanced にセキュリティグループポリシーを追加するという選択肢は、Shield Advanced が DDoS 攻撃の検出と緩和および対応支援を提供するサービスであり、セキュリティグループポリシーを登録して適用するような機能を持たないため、そもそも成立しません。
CloudFront と AWS WAF によるアプリケーション層攻撃の緩和
オンラインチケット販売のスタートアップが、購入アプリケーションを AWS Fargate 上の Amazon ECS クラスターで稼働させ、注文データを Amazon DynamoDB に保存しています。エンドユーザーはパブリックな Application Load Balancer (ALB) 経由でアプリケーションにアクセスします。ここ数か月、SQL インジェクションの試行や不正なボットによる大量リクエストが増加しており、同社は攻撃を防ぎつつ、攻撃が継続している間もサービス中断を最小限に抑えたいと考えています。これらの要件を最もコスト効率よく満たす手順の組み合わせはどれですか。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: A、B）
アプリケーション層への攻撃は、悪意のあるリクエストがアプリケーションに到達する前に、できるだけユーザーに近いエッジで遮断するのが基本方針です。Amazon CloudFront はグローバルなエッジロケーションで攻撃トラフィックを分散して受け止め、AWS WAF のウェブ ACL を関連付けることで SQL インジェクションや既知の不正リクエストパターンをマネージドルールグループで検査し、レートベースルールで単一送信元からの大量リクエストを制限できます。選択肢 B はこの検査層をエッジに置くもので、要件の中心を満たします。選択肢 A は、CloudFront が付与する秘密のカスタムヘッダーを ALB のリスナールールで検証することで、CloudFront と WAF を迂回して ALB のドメイン名に直接送られる攻撃を遮断する定番の手法であり、両者を組み合わせて初めて防御が完結します。選択肢 C は 2 つ目のリージョンにインフラ一式を複製するためコストがほぼ倍増し、しかも加重ルーティングでは攻撃トラフィックも両リージョンへ分散するだけで防御になりません。選択肢 D の DAX は読み取りキャッシュであり、タスク数を増やす対応は攻撃者のリクエストに合わせて課金が膨らむだけで、コスト効率の観点で不適切です。選択肢 E の ElastiCache も同様に攻撃の遮断には寄与せず、アプリケーション改修という追加コストが発生します。
レートベースルールによる認証エンドポイントの保護
あるオンライン旅行予約サービスは、会員向けサイトを Amazon ECS クラスター上のタスクとして稼働させ、Application Load Balancer (ALB) 経由でリクエストを受け付けています。運用チームは、毎週特定の曜日にログイン失敗が急増し、認証を担当するマイクロサービスの CPU 使用率が飽和状態になることを検知しました。調査の結果、失敗リクエストは毎回入れ替わる約 800 個の送信元 IP アドレスから短時間に大量送信されていることが判明しました。ソリューションアーキテクトは、世界中の正規会員のアクセスを妨げることなく、この大量の認証リクエストが認証サービスを圧迫しないようにする必要があります。最も運用効率が高いソリューションはどれですか。
解説を読む（正解: B）
AWS WAF のレートベースルールは、指定した評価期間 (既定では 5 分間) 内に同一の送信元 IP から到達したリクエスト数を継続的に集計し、しきい値を超えた IP を自動的にブロック対象へ加え、リクエスト量が下がれば自動的に解除する仕組みです。攻撃者が送信元 IP を頻繁に入れ替えるクレデンシャルスタッフィングのような事象では、個々の IP を人手で追跡して登録し続ける運用は破綻するため、量に基づく自動判定が有効です。本問では送信元 IP が毎週入れ替わるうえ数も多く、正規会員のアクセスは維持しなければならないため、レートベースルールを含むウェブ ACL を作成してアクションを Block に設定し、ALB に関連付ける B が最も運用効率に優れます。ウェブ ACL を ALB に関連付ければ、リクエストは ECS タスクに到達する前に遮断され、認証サービスに負荷が及びません。A の IP セット一致ルールは技術的にはブロックできますが、毎週 800 件規模の IP を人手で更新し続ける必要があり、運用効率の要件を満たしません。C はセキュリティグループに「拒否」ルールを定義できないため実現不可能です。D は許可する CIDR を限定する設計であり、世界中の会員が利用する公開サービスでは正規利用者まで遮断してしまいます。