なぜこの記事を書いたのか
AWS の暗号化に使われるサービスをはっきりと選択できませんでした。SSE-KMS 、SSE-S3 やSSE-C 、CloudHSM の違いをはっきりさせました。
それぞれの名前
- SSE-KMS ：AWS KMS キー によるサーバー側の暗号
- SSE-S3 ：Amazon S3 マネージド キーによるサーバー側の暗号化
- SSE-C ：顧客提供のキーによるサーバー側の暗号化
- CloudHSM ：法令遵守のためのハードウェアベースキーストレージ
AWS-SAA 認定試験における SSE-KMS、SSE-S3、SSE-C、CloudHSM の比較
| 項目 | SSE-KMS | SSE-S3 | SSE-C | CloudHSM |
|---|---|---|---|---|
| 暗号化キーの管理 | ユーザー | AWS | ユーザー | ユーザー |
| 暗号化アルゴリズム | AES-256 (デフォルト) | AES-256 | AES-256 (推奨) | RSA 2048 (デフォルト) |
| データの保存場所 | ユーザーが選択した KMS キーの場所 | S3 リージョン | ユーザーが選択した場所 | HSM クラスタ |
| 費用 | KMS の使用量に基づいて課金 | 無料 | 無料 | HSM クラスタの使用量に基づいて課金 |
| 監査 | ユーザー | AWS | ユーザー | ユーザー |
| コンプライアンス | ユーザーが KMS キーのコンプライアンス証明書を管理 | AWS が提供するコンプライアンス証明書 | ユーザー | ユーザー |
| ユースケース | より高度な制御が必要な場合 | S3 オブジェクトの暗号化に適している | コスト重視の場合 | 機密性の高いデータの暗号化に適している |
問題文中の取捨選択
- SSE-KMS は、要件に対して2択に絞られる確率が高いです。キーローテーションを手動/自動の設定可能で、キーの管理とローテーションの作業を削減したい企業に大人気です
- SSE-S3 はキー管理をAWS に任せて無料で利用できる暗号化サービスですが、SSE-KMS に比べると機能が劣ります。そのため、コスト重視であったり、機密性の低いデータの保護に用いられることがあります。
- また、S3 バケットを複数のリージョンに複製するクロスリージョンレプリケーション(CRR)を使い、双方のS3 で同じKMS キーを使う「マルチリージョンキー」の要件がない限り、SSE-S3 のほうが運用上のオーバーヘッドが最小限になります
- SSE-C はSSE-KMS と同じユーザー管理のサーバー側暗号化ですが、機能も少なく、コストを重視するとき以外は選択肢に入りません
- CloudHSM はKMS より高価で、機密性の高いデータの暗号化に用いられることが多いので、あまり正解になりません。ただし、ユーザー側からキーマテリアルを即時に削除したり、AWS CloudTrail とは関係のない独自の監査ログを提供できることから、要件に合致することがあります。
閑話休題、CloudHSM のディザスタリカバリー(DR)
CloudHSM がハードウェアなら、DR 戦略が必要で、バックアップ計画も立てられるのでしょうか？
Amazon 公式の説明では、できると書かれています。HSM バックアップでは、HSM は暗号化されてS3 に保存されます。S3 に保存されるHSM バックアップデータは、AWS-KMS によって暗号化されます。復元は、同じ製造元の AWS HSM にのみ可能です。とはいえ、CloudHSM 自体が個人で使うには高額なので、DR テストは企業や団体のプロジェクトに組み込んだとき1度試しておきたいです。
Security of cluster backups
https://docs.aws.amazon.com/cloudhsm/latest/userguide/data-protection-backup-security.html
AWS CloudHSM が HSM からバックアップを作成する際、HSM はすべてのデータを暗号化してから AWS CloudHSM に送信します。データは平文形式で HSM を出ることがありません。さらに、AWS はバックアップを復号化できません。なぜなら、AWS はバックアップの復号化に使用されるキーにアクセスできないからです。
HSM は、データを暗号化するために、一時的で固有の暗号化キーである「Ephemeral Backup Key (EBK)」を使用します。EBK は、AWS CloudHSM がバックアップを作成する際に HSM 内で生成される AES 256 ビットの暗号化キーです。HSM は EBK を生成してから、FIPS 承認済み AES キーラップ メソッド (NIST 特殊出版物 800-38F 準拠) を使用して HSM のデータを暗号化します。その後、HSM は暗号化されたデータを AWS CloudHSM に渡します。暗号化されたデータには、暗号化された EBK のコピーも含まれます。
EBK を暗号化するために、HSM は別の暗号化キーである「Persistent Backup Key (PBK)」を使用します。PBK も AES 256 ビットの暗号化キーです。HSM は、PBK を生成するために、FIPS 承認済みキー導出関数 (KDF) をカウンターモードで使用します (NIST 特殊出版物 800-108 準拠)。この KDF の入力には以下が含まれます。
ハードウェア製造元によって HSM ハードウェアに永続的に組み込まれている「Manufacturer Key Backup Key (MKBK)」
最初に AWS CloudHSM によって設定されたときに HSM に安全にインストールされる「AWS Key Backup Key (AKBK)」
暗号化処理は、以下の図にまとめています。この図では、バックアップ暗号化キーは、PBK (Persistent Backup Key) と EBK (Ephemeral Backup Key) を表しています。
AWS CloudHSM のバックアップ復元と暗号化
AWS CloudHSM は、同じ製造元が作成した AWS 所有の HSM にのみバックアップを復元できます。すべてのバックアップには、すべてのユーザー、キー、およびオリジナルの HSM からの構成が含まれているため、復元された HSM はオリジナルと同じ保護とアクセス制御を含みます。復元されたデータは、復元前に HSM にあった可能性がある他のデータをすべて上書きします。バックアップは暗号化されたデータのみで構成されます。サービスはバックアップを Amazon S3 に保存する前に、AWS Key Management Service (AWS KMS) を使用してバックアップを再度暗号化します。
ポイントまとめ:
復元は、同じ製造元の AWS HSM にのみ可能
バックアップには、オリジナル HSM の全情報が含まれる
復元は、既存のデータを上書きする
バックアップ自体も、Amazon S3 に保存前に AWS KMS で暗号化される