TLS 証明書の安全な管理と保管データの暗号化 保険金請求の査定を行う企業が、Windows Server ベースのコンテナアプリケーションを Amazon ECS クラスターで稼働させています。このアプリケーションは外部の与信情報プロバイダの API からデータを取得する際に、クライアント TLS 証明書を提示して通信を暗号化する必要があります。また、取得したデータは高い耐久性を持つストレージに暗号化して保存しなければなりません。証明書はプロバイダの規約により定期的に更新する必要があります。運用上のオーバーヘッドを最小限に抑えて、これらの要件を満たす構成はどれですか。
A AWS App Mesh を導入し、仮想ノードと仮想ゲートウェイの間で TLS 証明書による接続を構成する。データは SSE-KMS で暗号化した Amazon S3 に保存し、IAM ポリシーでアクセスを制御する B Python の暗号化ライブラリで証明書の取り扱いとデータの暗号化を実装した AWS Lambda 関数を自作する。関数のデプロイパッケージと暗号化済みデータを Amazon S3 バケットに保存し、バケットポリシーでアクセスを制御する C AWS KMS のカスタマー管理キーを作成し、EC2 インスタンスプロファイルにそのキーの使用を許可する。証明書はインスタンスのローカルディスクに配置し、暗号化したデータを Amazon S3 に保存してバケットポリシーでアクセスを制御する D TLS 証明書を AWS Secrets Manager のシークレットとして暗号化保存し、自動ローテーションを設定してタスクの実行時に取得する。データは SSE-KMS で暗号化した Amazon S3 に保存し、IAM ポリシーでアクセスを制御する
解説を読む（正解: D） TLS 通信に用いるクライアント証明書や秘密鍵をコンテナイメージやインスタンスのディスクに直接埋め込むと、更新のたびにイメージの再ビルドや配布作業が必要になり、有効期限の管理も人手に依存してしまいます。AWS Secrets Manager は AWS KMS で暗号化した状態でシークレットを保持し、IAM で取得権限を制御でき、ローテーションを自動化できるマネージドサービスです。D では ECS タスクロールに付与した権限で実行時に証明書を取得するため、イメージへの埋め込みが不要になります。保存データは SSE-KMS で暗号化した Amazon S3 に置き、IAM ポリシーでアクセスを制御することで、高い耐久性と保管中の暗号化という要件も同時に満たせます。結果として、転送中と保管中の双方の暗号化要件を最小の運用負荷で実現できます。A の App Mesh はメッシュ内のサービス間通信を制御する仕組みであり、外部のサードパーティ API への接続を保護する用途には合わず、サイドカーの導入や証明書配布の運用負荷も増えます。B は暗号化処理を自前のライブラリで実装するもので、鍵管理と保守の負担が最も大きく、Lambda 関数を S3 に保存するという記述も要件と噛み合いません。C は証明書をインスタンスのローカルディスクに置く前提であり、更新や配布を手作業で行うことになるため、運用オーバーヘッドが最小とは言えません。
ニアリアルタイムなログ収集・変換・分析基盤の選択 全国のスキー場に設置した約80台の気象観測ゲートウェイが、積雪量と風速のログを絶え間なく送信しています。運用チームは、流れ込むログを継続的に受け取り、おおむね60秒間隔でまとめてオブジェクトストレージに書き出したいと考えています。書き出す前にタイムスタンプの正規化と観測地点マスタの付与という変換処理を挟む必要があり、蓄積されたファイルに対しては後からアドホックな SQL 集計を実行したいという要望もあります。ゲートウェイは今後300台規模まで増える見込みで、サーバーの管理はできる限り避けたいという方針です。
この要件を満たす最も適切な構成はどれですか。
A Amazon EventBridge のスケジュールルールで5分ごとに AWS Lambda を起動し、各ゲートウェイへ順番にポーリングしてログを取得・変換してから Amazon S3 に書き込む。分析は Amazon Athena で行う。 B 各ゲートウェイから Amazon SQS 標準キューにログを送信し、AWS Lambda で取り出して変換したうえで Amazon EBS ボリュームに保存する。分析は Amazon Athena で EBS 上のファイルを直接クエリする。 C Amazon Data Firehose の配信ストリームでログを受信し、バッファ間隔を60秒に設定したうえで AWS Lambda によるレコード変換を有効化して Amazon S3 に配信する。蓄積されたファイルは Amazon Athena の SQL クエリで分析する。 D Amazon Kinesis Data Streams でログを受信し、Amazon EC2 上に自作のコンシューマーアプリケーションを常時稼働させて変換したうえで Amazon DynamoDB テーブルに書き込む。分析は Amazon Athena で DynamoDB テーブルを直接クエリする。
解説を読む（正解: C） Amazon Data Firehose (旧称 Amazon Kinesis Data Firehose) は、ストリーミングデータを受け取ってバッファリングし、Amazon S3 などの宛先へ自動的に配信するフルマネージドサービスです。配信ストリームにはバッファサイズとバッファ間隔を設定でき、間隔は最短60秒まで短縮できるため「約1分ごとにまとめて書き出したい」という要件にそのまま合致します。さらに Firehose にはレコード変換機能があり、指定した Lambda 関数を Firehose 側が自動的に呼び出して整形やマスタ情報の付与を行えるほか、JSON から Parquet への形式変換もサポートします。S3 に置かれたファイルは Amazon Athena がサーバーレスで直接 SQL クエリできるため、インスタンスを一切運用せずに収集から分析までを完結でき、ゲートウェイが300台に増えても Firehose 側が自動的にスケールします。したがって選択肢 C が最適です。選択肢 A はスケジュール起動のポーリング型であり、継続的に流れてくるログをニアリアルタイムに取り込めず、台数の増加に応じて取得ロジックとエラー処理の運用負荷が跳ね上がります。選択肢 D は Kinesis Data Streams 自体は妥当ですが、コンシューマーを EC2 で自作・運用する手間がかかり方針に反するうえ、Athena は DynamoDB テーブルを標準では直接クエリできません (別途フェデレーテッドクエリ用コネクタの構築が必要です)。選択肢 B は Amazon EBS が単一インスタンスにアタッチするブロックストレージであり、Athena がその上のファイルをクエリすることはできないため、分析基盤の保存先として成立しません。
踏み台ホストを廃止したセキュアな運用アクセス 医療機関向けに電子カルテ SaaS を提供する企業が、プライベートサブネット上の Amazon Linux インスタンス群を運用しています。現在は運用担当者がパブリックサブネットの踏み台ホストに SSH で入り、そこから各インスタンスに接続していますが、SSH 鍵の配布と失効、踏み台自体のパッチ適用が負担になっています。監査部門からは「インスタンスへのインバウンドポートを一切開けないこと」と「誰がいつどのインスタンスで何を実行したかを記録に残すこと」を求められています。最も適した解決策はどれですか。
A AWS Systems Manager Session Manager を利用し、インスタンスに SSM Agent と適切なインスタンスプロファイルを設定して、セッションログを Amazon S3 と Amazon CloudWatch Logs に出力する B 踏み台ホストのセキュリティグループで 22 番ポートの送信元を社内の固定 IP アドレスだけに絞り、SSH 鍵を毎月ローテーションする C すべてのインスタンスに Elastic IP を付与し、インスタンスごとのセキュリティグループで SSH を許可する D インスタンスのユーザーデータで毎回 root パスワードを再生成し、運用担当者にメールで通知する
解説を読む（正解: A） AWS Systems Manager Session Manager は、EC2 インスタンスにブラウザベースまたは CLI のシェルセッションを提供するマネージド機能です。接続はインスタンス上の SSM Agent が Systems Manager のエンドポイントに向けて張るアウトバウンド通信で確立されるため、インスタンス側でインバウンドポートを開ける必要がなく、踏み台ホストや SSH 鍵の配布も不要になります。アクセス制御は IAM ポリシーで行えるため、退職や異動の際は IAM 側の権限を外すだけで即座にアクセスを断てます。さらにセッションの開始・終了は AWS CloudTrail に記録され、セッション中の入出力ログを Amazon S3 や Amazon CloudWatch Logs に保存する設定も可能なので、監査証跡の要件も満たせます。
インバウンドポート閉鎖と操作ログの両方を同時に満たすのは A です。
B は 22 番ポートを送信元制限付きとはいえ開けたままであり、「インバウンドポートを一切開けない」という要件に反します。踏み台の運用負荷と鍵管理の課題も残ります。C は全インスタンスをインターネットに露出させるもので、プライベートサブネットに配置した意図を損ない、攻撃対象領域を大きく広げます。D はパスワード認証への回帰であり、メールでの認証情報配布は漏えいリスクが高く、操作内容の記録も残らないため監査要件を満たせません。