KMSによる暗号化(エンベロープ暗号化とデータキーキャッシング)難易度 高無料
大量のログを毎秒数千件クライアント側で暗号化してから保存するアプリケーションがある。1件ごとに kms:GenerateDataKey を呼び出す実装にしたところ、ThrottlingException が多発し、KMSの呼び出し課金も無視できないコストになった。セキュリティ(1つのデータキーを使い回しすぎない)とスループット・コストのバランスを取りたい。最も適切な対処を選べ。(単一選択)
- AAWS Encryption SDKのデータキーキャッシングを導入し、最大メッセージ数・最大バイト数・最大有効時間などの上限を設定した上で、上限内は同一のデータキーを複数の暗号化操作で再利用する。上限に達したら新しいデータキーに切り替える
- BAWSサポートにKMSの
GenerateDataKeyのリージョンデフォルトクォータの引き上げを依頼するだけで、アーキテクチャは変更しない - Cクライアント側暗号化をやめてSSE-S3に切り替え、KMSの呼び出しを完全になくす
- D最初に生成した1つのデータキーを、有効期限や再利用回数の上限を設けずアプリケーションのライフタイム全体で使い回し続ける
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解:AAI作成・独立検証済
解説
この種の高スループットなクライアント側エンベロープ暗号化のユースケースには、 AWS Encryption SDKのデータキーキャッシング(data key caching)機能が設計されている。
- データキーキャッシングは、生成したデータキーをローカルの暗号資料キャッシュ(cryptographic materials cache)に保持し、 一定の制限(最大メッセージ数・最大バイト数・最大有効時間などを設定可能)の範囲内であれば、 毎回KMSを呼ばず同じデータキーを複数の暗号化操作で再利用する。
- これにより
GenerateDataKeyの呼び出し回数・スロットリング・コストを大幅に削減しつつ、 設定した上限に達したら新しいデータキーへ切り替えるため、1つのデータキーが無制限に使われ続けることも防げる(露出範囲の限定)。
単にKMSのAPIクォータ引き上げをサポートに依頼するだけでは、根本のアーキテクチャ課題(呼び出し回数そのものの多さ・コスト)は解決しない。 またSSE-S3への切り替えはクライアント側暗号化を手放すことになり要件(クライアント側でのコントロール)にそぐわない場合が多く、 無期限にキャッシュし続ける設計はデータキーの露出範囲を限定するという安全上の目的を損なう。
- Bクォータ引き上げは対症療法であり、呼び出し回数自体もコストも変わらない。根本的な設計改善(データキーの再利用)にはならない。
- C「クライアント側で暗号化・鍵管理をコントロールしたい」という前提が失われる。KMSを使ったクライアント側暗号化の管理性・監査性を手放すことになり要件に合わない。
- D上限を設けない使い回しは、1つのデータキーの露出範囲(暗号化されるデータ量・期間)を際限なく広げてしまい、データキーキャッシングが意図する“安全な再利用”の設計から外れる。
ひっかけ: 「クォータ引き上げだけで解決(B)」は対症療法であり、呼び出し回数自体は減らせずコストの根本解決にならない。
「無期限にキャッシュし続ける(D)」はデータキーキャッシングの“上限を設けて安全に再利用する”という設計思想を欠いており、
1つのキーの露出(利用範囲)が際限なく広がってしまう点で不適切。
公式ドキュメント・関連AWS Encryption SDK Developer Guide ― Data key caching↗AWS KMS Developer Guide ― Request quotas↗
AIが作成し、独立した検証を経た解説です(有資格者による監修は経ていません)