医療機器メーカーが、AWS Lambda 関数から Amazon RDS for Microsoft SQL Server の DB インスタンスへアクセスするサーバーレスの在庫管理システムを構築しています。同社は開発環境と本番環境を分けており、両環境に同一構成のデータベースを用意しています。開発者は開発環境のデータベース認証情報を自由に参照できますが、本番環境の認証情報は、情報セキュリティ部門の IAM ユーザーグループに所属するメンバーだけが管理できる暗号化キーで保護し、そのキーは定期的にローテーションする必要があります。本番環境でソリューションアーキテクトが実装すべき構成はどれですか。
解説を読む（正解: C）
アプリケーションが利用するデータベース認証情報は、コードやデプロイパッケージから切り離し、専用のシークレットストアで暗号化して保管し、誰が復号でき誰が管理できるのかを鍵と保管先の両方のポリシーで制御するのが基本です。AWS Secrets Manager はシークレット単位のリソースポリシーを持ち、暗号化に指定した AWS KMS のカスタマーマネージドキーにはキーポリシーを設定できるため、二層で権限を絞り込めます。さらにカスタマーマネージドキーは自動キーローテーションを有効化でき、シークレット自体のローテーションも設定できます。選択肢 C はこの両方の制御点を使って情報セキュリティ部門だけに管理権限を残しつつ、Lambda 実行ロールには取得に必要な最小限の権限を与えているため要件を満たします。選択肢 B の AWS マネージドキーはキーポリシーを利用者が編集できないため、特定の IAM グループだけがアクセスできる状態を作れません。選択肢 A は環境変数に認証情報を持たせるため、認証情報を変更するたびに全関数の再デプロイが必要になり、また関数の実行ロールが復号できなければ関数自体が起動できず、キーへのアクセスを情報セキュリティ部門のみに限定するという条件と矛盾します。選択肢 D も AWS マネージドキーを使うためキーポリシーによる限定ができず、加えて認証情報の定期的な入れ替え手段も用意されていません。
金融機関のデータ分析基盤では、アプリケーションが AWS Encryption SDK を用いてクライアントサイドで暗号化したオブジェクトを東京リージョンの S3 バケットに保存し、S3 クロスリージョンレプリケーションで大阪リージョンへ複製しています。ディザスタリカバリ演習の要件として、東京リージョンが完全に利用不能になった状況でも、大阪リージョンのアプリケーションがレプリケート済みの暗号文をそのまま復号できなければなりません。東京リージョンへの API 呼び出しに一切依存しない設計はどれですか。
解説を読む（正解: B）
AWS KMS のキーは原則としてリージョン内に閉じており、あるリージョンのキーで生成された暗号文は他リージョンの別キーでは復号できません。この制約を解消するのがマルチリージョンキーで、プライマリキーと同じキーマテリアルとキー ID を持つレプリカキーを別リージョンに作成でき、プライマリで暗号化した暗号文をレプリカ側だけで復号できます。したがって B のように東京にプライマリ、大阪にレプリカを作成すれば、レプリケートされた暗号文をそのまま大阪で復号でき、東京リージョンへの API 依存が完全に排除されます。A は暗号文をいったん復号する必要があり、その復号処理自体が東京のキーを呼び出すため、東京が利用不能な状況では機能しません。C は平時なら動作しますが、東京リージョンの KMS が利用不能になった瞬間に復号できなくなるため、まさに排除したかったクロスリージョン依存を温存しており DR 要件を満たしません。D の AWS CloudHSM クラスターはリージョン内のリソースであり、バックアップをクロスリージョンにコピーして別クラスターを作ることはできても、他リージョンから同一クラスターを共有利用する構成ではないため要件を満たしません。
南米の物流企業は、通関書類を取引先から受け取るための SFTP エンドポイントを自社データセンターで運用しています。取引先各社は自社ファイアウォールの許可リストにこの SFTP エンドポイントのパブリック IP アドレスを登録しており、社内統制上その IP アドレスの変更は認められていません。企業はこのファイル受信基盤を AWS へ移行し、サーバーの運用と OS パッチ適用の負担を減らしつつ、受信ファイルを暗号化して保存したいと考えています。使用している IP アドレスブロックは企業自身が所有し、ルーティング権限も保有しています。この要件を最も適切に満たすソリューションはどれですか。
解説を読む（正解: D）
AWS Transfer Family は SFTP、FTPS、FTP プロトコルのフルマネージドなエンドポイントを提供し、受信したファイルをそのまま Amazon S3 や Amazon EFS に格納できるサービスです。サーバーの構築、冗長化、OS パッチ適用が不要になるため、移行の主目的である運用負荷の削減を直接満たします。一方、取引先のファイアウォール許可リストに登録済みの IP アドレスを維持するという制約は、Bring Your Own IP (BYOIP) で解決します。BYOIP では自社が所有し ROA で権限を証明できる IP アドレスブロックを AWS アカウントに持ち込み、そのプールから Elastic IP アドレスを払い出せます。VPC でホストするインターネット向けの Transfer Family サーバーはサブネットごとに Elastic IP アドレスを関連付けられるため、既存のパブリック IP アドレスをそのまま引き継げます。保存先を S3 とし AWS KMS のキーでサーバー側暗号化を行えば、保管時の暗号化とキーの監査要件も満たせます。Application Load Balancer を使う選択肢は、ALB が HTTP/HTTPS 用のレイヤー 7 ロードバランサーであり SFTP のような任意の TCP を扱えず、Elastic IP アドレスの直接関連付けもできない (固定 IP を持てるのは Network Load Balancer) ため誤りです。加えて EC2 上で SFTP を自前運用するのは運用負荷削減の要件に反します。Route 53 に IP アドレスブロックを登録する選択肢は、Route 53 が DNS サービスであり IP アドレスの持ち込み先ではないうえ、FTP は平文通信のためセキュリティ要件も満たしません。S3 の VPC エンドポイントに Elastic IP アドレスを割り当てる選択肢は、VPC エンドポイントに Elastic IP アドレスを関連付ける機能がなく、S3 自体も SFTP プロトコルを直接受け付けないため成立しません。