KMS の暗号鍵はどこに保存されているのか - エンベロープ暗号化と HSM の仕組み
KMS のマスターキーが FIPS 140-2 認定の HSM 内に保存される仕組み、エンベロープ暗号化でデータキーを二重に保護する設計、キーローテーションの内部動作を解説します。
KMS キーは平文で保存されていない
AWS KMS (Key Management Service) で作成した暗号鍵 (KMS キー、旧称 CMK) は、平文の状態でディスクに保存されることはありません。KMS キーのキーマテリアル (実際の暗号鍵データ) は、FIPS 140-2 Level 3 認定を受けた HSM (Hardware Security Module) 内でのみ平文として存在します。HSM は暗号処理専用のハードウェアデバイスで、物理的な耐タンパー性 (不正な開封や改ざんを検知して鍵を自動消去する機能) を備えています。KMS キーが HSM の外部に保存される際は、HSM 内部のドメインキーで暗号化された状態 (暗号文) で保存されます。暗号化・復号の処理が必要な場合、暗号化されたキーマテリアルが HSM にロードされ、HSM 内部で復号されて暗号処理に使用され、処理が完了すると HSM のメモリから消去されます。つまり、AWS のストレージシステムに保存されているのは暗号化されたキーマテリアルであり、これを復号できるのは HSM だけです。AWS の従業員がストレージにアクセスしても、暗号化されたキーマテリアルしか見えません。
エンベロープ暗号化 - なぜ鍵で鍵を暗号化するのか
KMS の暗号化モデルの核心は「エンベロープ暗号化」(Envelope Encryption) です。データを直接 KMS キーで暗号化するのではなく、まず KMS にデータキー (Data Key) の生成を依頼し、そのデータキーでデータを暗号化し、データキー自体を KMS キーで暗号化して保存します。なぜこの二重構造が必要なのでしょうか。理由は 2 つあります。第 1 に、パフォーマンスです。KMS の暗号化 API は 1 リクエストあたり最大 4KB のデータしか処理できません。数 GB のファイルを暗号化するには、KMS に数百万回のリクエストを送る必要があり、現実的ではありません。データキーをローカルで使用すれば、任意のサイズのデータを高速に暗号化できます。第 2 に、レイテンシです。KMS の API 呼び出しにはネットワークのラウンドトリップが発生します。データキーをメモリにキャッシュすれば、暗号化処理のたびに KMS を呼び出す必要がなくなります。S3 の SSE-KMS (Server-Side Encryption with KMS) は、このエンベロープ暗号化を内部で自動的に実行しています。オブジェクトごとに一意のデータキーが生成され、オブジェクトのデータはデータキーで暗号化され、データキーは KMS キーで暗号化されてオブジェクトのメタデータとして保存されます。
キーローテーションの内部動作
KMS の自動キーローテーションを有効にすると、毎年 (設定により 90 日〜2560 日) 新しいキーマテリアルが生成されます。ここで重要なのは、キーローテーション後も古いキーマテリアルは削除されないという点です。KMS キーの ARN と Key ID は変わらず、古いキーマテリアルで暗号化されたデータは、古いキーマテリアルで自動的に復号されます。新しいデータの暗号化には新しいキーマテリアルが使用されます。この設計により、キーローテーションは完全に透過的です。アプリケーションコードの変更は一切不要で、暗号化されたデータの再暗号化も不要です。KMS は内部的に、暗号文にどのバージョンのキーマテリアルで暗号化されたかの情報を埋め込んでおり、復号時に適切なキーマテリアルを自動的に選択します。手動キーローテーション (新しい KMS キーを作成してエイリアスを切り替える方式) の場合は、古い KMS キーで暗号化されたデータを新しい KMS キーで再暗号化する必要があります。自動ローテーションと手動ローテーションの違いを理解していないと、手動ローテーション後に古いデータが復号できなくなる事故が発生します。
KMS と CloudHSM の使い分け
KMS はマルチテナントの HSM 上で動作するマネージドサービスです。複数の顧客の KMS キーが同じ HSM クラスター上で処理されますが、各キーは暗号学的に分離されており、他の顧客のキーにアクセスすることはできません。一方、CloudHSM はシングルテナントの HSM を提供するサービスです。専用の HSM アプライアンスが VPC 内に配置され、顧客だけがアクセスできます。CloudHSM が必要なケースは限定的です。第 1 に、規制要件で「専用の HSM」が求められる場合です。金融機関や政府機関の一部の規制は、暗号鍵を専用のハードウェアで管理することを要求しています。第 2 に、PKCS#11、JCE、CNG などの標準的な暗号 API を使用する必要がある場合です。KMS は AWS 独自の API を使用しますが、CloudHSM は業界標準の暗号 API をサポートしています。第 3 に、KMS のリクエストレート制限 (デフォルトで秒間 5,500〜30,000 リクエスト、リージョンにより異なる) を超える暗号処理が必要な場合です。CloudHSM は専用ハードウェアのため、レート制限がありません。ほとんどのユースケースでは KMS で十分であり、CloudHSM は特殊な要件がある場合にのみ検討すべきです。
暗号鍵の削除 - 取り消せない最も危険な操作
KMS キーの削除は、AWS で最も危険な操作の一つです。KMS キーを削除すると、そのキーで暗号化されたすべてのデータが永久に復号不可能になります。S3 のオブジェクト、EBS のボリューム、RDS のスナップショットなど、そのキーに依存するすべてのデータが事実上消失します。AWS はこのリスクを軽減するために、KMS キーの削除に 7〜30 日の待機期間を設けています。削除をスケジュールすると、キーは「削除保留中」(Pending Deletion) 状態になり、待機期間中は暗号化・復号に使用できなくなります。待機期間中に削除をキャンセルすれば、キーは復活します。待機期間が経過すると、キーマテリアルが HSM から完全に消去され、二度と復元できません。削除保留中のキーが使用された場合 (暗号化や復号のリクエストが発生した場合)、CloudTrail にログが記録されます。このログを監視することで、まだそのキーに依存しているリソースが存在するかどうかを確認できます。本番環境の KMS キーには、キーポリシーで kms:ScheduleKeyDeletion アクションを制限し、誤削除を防止することが強く推奨されます。暗号化とキー管理の設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。