KMSキーと暗号化方式のシナリオ判断

この単元で学ぶこと

• エンベロープ暗号化の障害原因を特定する
• キーポリシーとコンテキストを条件から評価する
• キー移行とリージョン復旧の境界を判断する

本文解説

1. 復号経路を追跡する 設計例では各ファイルをデータキーで暗号化し、その暗号化コピーとコンテキストをメタデータに保存します。復号エラーでは、対象の暗号化データキー、KMSキー、コンテキスト、呼出し主体を順に照合します。ファイルの存在だけを確認してストレージ障害と断定しないことが重要です。

2. 平文を保管する案の修正 障害を避けるため平文データキーもバックアップする案は、漏えい時の保護を弱めます。必要なのは暗号化コピーを確実に保持し、復号に必要なKMS権限を設計することです。KMSが生成済みのデータキー一覧を保管してくれるわけではないため、アプリのメタデータ保存も検証します。

3. IAMだけ変更した場合 キーポリシーにIAMによる許可を有効にする記述がなく、直接許可もgrantもないとします。この条件でIAMへDecryptのAllowを追加しても、利用許可が完成したとはいえません。例外の経路があると答えが変わるので、試験問題でも許可経路と他の制限の有無を読んで判断します。

4. 部門のコンテキスト Finance用に暗号化したデータへSalesのコンテキストを渡しても、同じキーだから成功するとは限りません。暗号化時の値と一致させる必要があります。コンテキスト条件で権限も限定できますが、コンテキスト自体は秘密ではありません。秘密の社員番号やパスワードを埋め込む設計は避けます。

5. ローテーション後の問い合わせ キーIDが変わらないのは自動更新が失敗した証拠ではありません。論理キーを維持して素材を変えるためです。逆に漏えいした平文データキーで読めるファイルがあるなら、KMS素材の更新とは別にそのファイルの保護を見直します。旧暗号文の再暗号化が自動実施されたと判断しません。

6. 移行の完了条件 alias/projectの参照先を新キーへ変えても、旧キーで守ったデータキーは残ります。新規作成の動作確認だけでなく、過去のファイルとバックアップの復号も試します。移行対象の再暗号化や保存期限が完了するまで旧キーを保持するなど、削除の条件を具体化します。

7. 複数リージョンの復旧演習 アプリがクライアント側で関連マルチリージョンキーを使う場合、複製済み暗号文を宛先のキーで復号できます。ただし宛先キーは有効で必要な許可があり、暗号文等が移動済みであることが条件です。鍵素材が同じだからポリシーやアプリ配置も揃っているという判断はできません。

8. サービスの動作まで調べる S3等のサービスが暗号化データを複製するときは、そのサービス固有の宛先キー指定と許可を確認します。マルチリージョンキーを導入すれば複製設計の設定を省略できるわけではありません。復旧テストではデータ読取り成功だけでなく、不要な主体の拒否、キー停止時の影響も確認します。

図解

重要ポイント

• エラーはキー・データキー・コンテキスト・許可の流れで調べる。
• キーIDの維持は素材未更新の証拠ではない。
• レプリカの権限とデータ複製を独立に確認する。

間違えやすい点

• 直接許可やgrantの有無を省いてIAMだけで判断する。
• 新規ファイルが読めれば旧キーを削除できると思う。

用語解説

キー移行

新しい論理キーへ暗号化や復号の依存を移す作業。

クライアント側暗号化

保管サービスへ渡す前にアプリ側でデータを暗号化する方式。

復号依存

暗号文を読むために特定キー・素材・条件を必要とすること。

関連教材

• ACMとTLS証明書を理解する
• KMSキーと暗号化方式を理解する
• ACMとTLS証明書のシナリオ判断
• S3 Block Public Accessとバケットポリシーのシナリオ判断
• Secrets ManagerとParameter Storeを理解する