暗号化とAWS KMSのシナリオ判断

顧客資料を保存する会社の事例で、暗号化の種類、キーの管理責任、更新後の復号を判断します。

この単元で学ぶこと

保護したい場面から暗号化方式を選ぶ
キーの管理要件とサービスの役割を対応させる
更新・削除に伴う業務への影響を説明する

本文解説

1. 要件を分けて読む「顧客資料を安全に保管する」には複数の意味があります。保存媒体から読まれない、通信を盗み見られない、無関係な社員へ見せない、誤削除から戻せる、という要件を分けます。それぞれ保存時暗号化、TLS、権限管理、バックアップが対応し、一つで全部を満たすわけではありません。

2. HTTPSだけの案を評価する WebアプリがHTTPSを使っていても、保存先のデータをどう保護するかは別に確認します。反対に保存時暗号化済みでも、通信を平文にしてよい理由にはなりません。データの流れを利用者からアプリ、保管先まで描き、各区間と各保管場所を点検します。

3. 鍵の制御を求められたら監査担当が「どのアプリがキーを使えるかを自社で設定し、必要時に無効化したい」と求めた場合はカスタマー管理キーが候補です。利用サービスがそのキーに対応することも確認します。AWS管理キーを利用者の規則で自由に変更する案や、AWS所有キーを直接編集する案は制御範囲を取り違えています。

4. データキーを安全に残す設計書に暗号文と平文キーを同じバックアップへ入れると書かれていたら、両方の流出で読まれると指摘できます。エンベロープ暗号化では暗号化したデータキーを残します。復号するアプリには必要な権限を与え、処理中の平文キーや復号後のデータがログへ出ないようにします。

5. 過去の請求書を読む昨年の請求書を暗号化した後、AWS_KMS由来のKMSキーがローテーションしても、通常は以前の鍵素材で復号できます。ローテーションしたから請求書を全部作り直す必要がある、とは判断しません。一方、新しい別キーへ移行する場合には既存データの依存が残るので、古いキーをすぐ削除しません。

6. 更新しても漏えいは消えない平文データキーが既に盗まれた場合、KMSキーをローテーションしても、盗まれたキーで読める暗号文は自動的に書き換わりません。影響対象を確認し、権限の見直しやデータの再暗号化等を別途検討します。ローテーションは過去の流出を取り消す処理ではありません。

7. 一時停止と完全削除キーの無効化は再有効化を検討できる操作ですが、実際の削除は不可逆です。削除を予約した待機中もキーは通常の暗号操作に使えません。データだけ残っているからサービスを継続できる、とは考えず、アプリとバックアップ両方の依存を調べます。

8. 監査で確かめることカスタマー管理キー等の利用はCloudTrailで追跡し、権限を持つアプリの成功と不要な主体の拒否を確認します。ログの取得だけで最小権限になるわけではありません。AWS所有キーの個別監査は同じ方式ではできないため、必要な証跡が得られる暗号化構成を要件に合わせて選びます。

図解

資料の流れを分けて確認 — 一つの対策で全段階を保護したとは判断せず、各段階の条件を確認します。

重要ポイント

通信・保存・認可・復元を別の要件として読む。
自社でキーを制御する要件ではカスタマー管理キーを確認する。
鍵の更新は過去の流出を取り消さない。

間違えやすい点

暗号文と平文データキーを同じ場所へ保存する。
データを残せばキーを削除しても復元できると思う。

用語解説

鍵素材: 暗号計算に使う秘密の値。キーの名前やIDとは異なる。
依存関係: データの復号や業務が特定のキーを必要とする関係。
無効化: キーを暗号操作に使えない状態にする操作。削除とは異なる。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。