ElastiCache for Redis の転送時暗号化と AUTH による認証
動画配信サービスを運営する企業が、視聴履歴とセッション情報のキャッシュ層として Amazon ElastiCache for Redis のクラスターを運用しています。セキュリティ監査の結果、保管時の暗号化は有効化されている一方で、転送時の暗号化が構成されておらず、さらに VPC 内からであれば認証なしでキャッシュに接続できる状態であることが判明しました。ソリューションアーキテクトは、クライアントに認証を要求し、かつ通信経路も含めたエンドツーエンドの暗号化を実現する必要があります。これらの要件を満たすソリューションはどれですか。
解説を読む（正解: D）
Amazon ElastiCache for Redis における「認証」と「転送時の暗号化」は密接に結び付いた機能です。Redis AUTH は接続時にトークンの提示を要求する仕組みですが、トークンが平文でネットワークを流れないよう、AUTH を利用するには転送時の暗号化 (TLS) を有効にしたクラスターである必要があります。また転送時の暗号化はクラスター (レプリケーショングループ) の作成時に指定する設定であり、監査で指摘された既存クラスターに対しては、暗号化と AUTH を有効にした新しいレプリケーショングループを作成して切り替えるのが確実な手順です。選択肢 D は新しいクラスターで TLS と AUTH を有効化し、トークン自体も AWS Secrets Manager で安全に保管して実行時に取得するため、認証とエンドツーエンドの暗号化の両方を満たします。選択肢 B は転送時の暗号化を行わないため経路上の盗聴に対して無防備であり、そもそも AUTH は転送時の暗号化と組み合わせて利用する前提であるうえ、保管時の暗号化は通信の保護にはなりません。選択肢 C は ElastiCache for Redis がクライアント証明書による相互 TLS 認証をサポートしていないため実装できません。選択肢 A はロードバランサーで TLS を終端しても Redis エンドポイントまでの区間が保護されず、セキュリティグループはネットワークの到達制御であって利用者の認証にはならないため、いずれの要件も満たしません。
EC2 の SSH キーペアの安全な自動ローテーション
ゲノム解析を受託する企業が、解析ジョブ用に多数の Linux ベースの Amazon EC2 インスタンスを運用しています。運用担当者は EC2 の SSH キーペアを使ってインスタンスにログインしており、セキュリティ方針上、マシンごとに一意のキーペアを割り当てる必要があります。同社は、要求に応じてすべての EC2 キーペアを自動的にローテーションし、キーを安全に暗号化された場所へ保管するキーローテーションポリシーを導入したいと考えています。ローテーション中に発生するダウンタイムは 1 分以内に収める必要があります。これらの要件を満たすソリューションはどれですか。
解説を読む（正解: A）
SSH の秘密鍵のような長期認証情報は、暗号化された専用のストアに保管し、定期的かつオンデマンドにローテーションできる仕組みで管理することが求められます。AWS Secrets Manager はシークレットを AWS KMS のキーで自動的に暗号化して保管し、ローテーション用の AWS Lambda 関数を紐付けることで、スケジュールに沿ったローテーションと RotateSecret API による「要求に応じた」即時ローテーションの両方を実現できます。Lambda 関数の中で新しいキーペアを生成し、インスタンス上の authorized_keys の公開鍵を置き換えてから新しい秘密鍵をシークレットの新バージョンとして保存すれば、公開鍵の差し替えは数秒で完了し、SSH デーモン自体は再起動不要のため 1 分以内という条件も満たせます。したがって A が正解です。B は Parameter Store を String 型で使う点が致命的で、String 型は暗号化されないため秘密鍵の保管先として不適切です (暗号化するには SecureString 型が必要です)。加えて Parameter Store にはネイティブのローテーション機能がなく、メンテナンスウィンドウはスケジュール実行の仕組みであってオンデマンドのローテーション要求には向きません。C は誤りで、AWS KMS に EC2 の SSH キーペアをインポートして SSH 認証に使うことはできず、インポートされたキーマテリアルは自動ローテーションの対象外です。D の Run Command で公開鍵を配布する方法自体は技術的に可能ですが、生成した秘密鍵を安全に暗号化保管する仕組みが欠けており、Fleet Manager はインスタンス管理の UI であってキーストアではないため、要件を満たしません。
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 攻撃の検出と緩和および対応支援を提供するサービスであり、セキュリティグループポリシーを登録して適用するような機能を持たないため、そもそも成立しません。