AWS認定資格 WEB問題集＆徹底解説
CloudOpsエンジニア -アソシエイト
問題文と選択肢
運用上のオーバーヘッドを最小限に抑えながら、この要件を満たすにはどの方法が最適ですか。
- AWS KMS でカスタマー管理キーを作成して DynamoDB テーブルの保存時の暗号化に使用し、ローテーション周期を 2 年に設定して自動キーローテーションを有効化する
- アプリケーション層でデータを暗号化してから DynamoDB に保存し、キーの保管とローテーションをアプリケーション側で独自に実装する
- DynamoDB のデフォルト暗号化（AWS 所有キー）をそのまま使用し、AWS 側で自動的にキーをローテーションさせる
- 外部のハードウェアセキュリティモジュール（HSM）でキーマテリアルを生成して AWS KMS にインポートし、そのキーで自動キーローテーションを有効化する
A. AWS KMS でカスタマー管理キーを作成して DynamoDB テーブルの保存時の暗号化に使用し、ローテーション周期を 2 年に設定して自動キーローテーションを有効化する
Amazon DynamoDB の保存時の暗号化では、テーブルの暗号化キーにAWS KMS のカスタマー管理キーを指定できる。
カスタマー管理キー（AWS KMS が生成した対称キー）は自動キーローテーションに対応しており、ローテーション周期は既定 365 日だが 90〜2560 日の範囲で指定できるため、2 年（730 日）ちょうどの周期を設定できる。有効化はスイッチ 1 つで、以降 AWS が自動でキーマテリアルを更新するため運用負荷は最小。
さらにキーポリシー・ローテーション設定・使用履歴（AWS CloudTrail）を利用者側で確認できるため、監査人へのローテーション実施の証明も可能。要件をすべて満たす正解。
B. アプリケーション層でデータを暗号化してから DynamoDB に保存し、キーの保管とローテーションをアプリケーション側で独自に実装する
クライアントサイド暗号化は技術的には可能だが、キーの安全な保管・配布、ローテーション処理の実装、再暗号化、全アプリケーションへの展開をすべて自前で背負うことになる。
「運用上のオーバーヘッドを最小限に抑える」という要件と正面から衝突し、マネージドサービスで実現できることをわざわざ自作している。
DynamoDB は標準で保存時の暗号化を備えており、そもそもアプリ側で暗号化する必要がない。
C. DynamoDB のデフォルト暗号化（AWS 所有キー）をそのまま使用し、AWS 側で自動的にキーをローテーションさせる
DynamoDB のデフォルトは AWS 所有キー（AWS owned key）で、追加料金なしに保存時の暗号化を提供する。しかしこのキーは複数の AWS アカウントで共有される AWS 管理下のキーで、利用者のアカウントには存在しない。
そのためキーポリシーを設定できず、CloudTrail でキーの使用状況を追跡することもできず、ローテーションの周期や実施状況を利用者が確認・制御できない。
「2 年ごとにローテーションしていることを監査人に証明する」という要件を満たせないため不適。
D. 外部のハードウェアセキュリティモジュール（HSM）でキーマテリアルを生成して AWS KMS にインポートし、そのキーで自動キーローテーションを有効化する
外部で生成したキーマテリアルを KMS にインポートした KMS キー（オリジン EXTERNAL）は、自動キーローテーションに対応していない（対応するのはオンデマンドローテーション、すなわち新しいキーマテリアルを都度インポートする方式のみ）。
したがって「自動キーローテーションを有効化する」という選択肢の記述自体が成立せず、2 年ごとのローテーションを人手または独自の自動化で回し続けることになる。
キーマテリアルの生成・保管・再インポートの手間が増え、運用負荷最小の要件に反する。
ローテーションを「自分で決めて・証明する」ならカスタマー管理キー。AWS 所有キーは見えない、インポートキーは自動回せない。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| DynamoDB の保存時の暗号化を使用する | DynamoDB は標準で保存時の暗号化に対応。アプリ層で自前暗号化する必要はない →選択肢（B）を消す |
| 暗号化キーを 2 年ごとにローテーションする | KMS の自動キーローテーションは周期を 90〜2560 日で指定可能（既定 365 日）。2 年＝730 日を設定できる →選択肢（A）が正解 |
| ローテーションの実施を監査人に証明できる | AWS 所有キーはキーポリシーも使用履歴も利用者から見えないため、証明できない →選択肢（C）を消す |
| 運用上のオーバーヘッドを最小限に抑える | インポートしたキーマテリアルは自動ローテーション非対応で、都度の再インポートが必要になる →選択肢（D）を消す |
| キーの種類の選択 | 制御・監査・自動ローテーションを両立できるのはKMS カスタマー管理キーだけ →選択肢（A）が正解 |
ひっかけポイント
- 選択肢 C の「AWS 側で自動的にローテーションされる」は事実ではあるが、その周期も実施状況も利用者からは確認できない。コンプライアンス証跡が要件に入った瞬間に AWS 所有キーは脱落する
- 「HSM で生成したキー」は最も堅牢そうに見えるのが罠。インポートされたキーマテリアルは KMS の自動キーローテーションが使えない（オンデマンドローテーションのみ）
- 自動キーローテーションは対称暗号化のカスタマー管理キー（KMS 生成）限定。非対称キー・HMAC キー・カスタムキーストアのキーは対象外
- 自動ローテーションで入れ替わるのは裏側のキーマテリアルだけで、キー ID や ARN は変わらない。古いデータの再暗号化も不要（過去のキーマテリアルが保持され復号できる）
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「キーは1 年ごとにローテーションすればよい」 | 正解は変わらないが、KMS の既定周期（365 日）のまま自動ローテーションを有効化するだけで済む。 |
| 「今すぐキーをローテーションしたい（漏洩の疑い）」 | オンデマンドローテーション（RotateKeyOnDemand）が正解軸に。インポートキーでも実行できる。 |
| 「キーマテリアルを自社の HSM で生成・管理し続けたい（BYOK）」 | インポートされたキーマテリアルまたは AWS CloudHSM キーストアが正解軸になり、ローテーションは手動運用になる。 |
| 「暗号化のコストを抑えたい・キーの制御は不要」 | AWS 所有キー（DynamoDB のデフォルト）で十分という結論に変わる（追加料金なし）。 |
| 「誰がいつこのキーで復号したかを追跡したい」 | カスタマー管理キー＋AWS CloudTrail でのキー使用状況の記録が正解軸に。 |
リファレンス
この問題を解くために必要な知識を扱う公式ドキュメントです。| 知識項目 | 公式ドキュメント |
|---|---|
| KMS キーの自動キーローテーション（対象キー・周期・インポートキーの制限） | AWS KMS keys のローテーション |
運用上のオーバーヘッドを最小限に抑えながら、この要件を満たすにはどの方法が最適ですか。
- AWS KMS でカスタマー管理キーを作成して DynamoDB テーブルの保存時の暗号化に使用し、ローテーション周期を 2 年に設定して自動キーローテーションを有効化する
- アプリケーション層でデータを暗号化してから DynamoDB に保存し、キーの保管とローテーションをアプリケーション側で独自に実装する
- DynamoDB のデフォルト暗号化（AWS 所有キー）をそのまま使用し、AWS 側で自動的にキーをローテーションさせる
- 外部のハードウェアセキュリティモジュール（HSM）でキーマテリアルを生成して AWS KMS にインポートし、そのキーで自動キーローテーションを有効化する