セクション 02 · タスク 1.2 · SAP-C02-017

KMSによる暗号化アーキテクチャ

AWS KMS / KMSキー / キーポリシー / IAMポリシー / データキー / エンベロープ暗号化 / クロスアカウント暗号化 / AWS CloudHSM

このページのゴール

保存データを暗号化する要件から、適切なKMSキーとアクセス制御を選び、データキー・エンベロープ暗号化・クロスアカウント利用・AWS CloudHSMの必要性まで判断できることをゴールにします。

1. 暗号化設計では「暗号化するか」だけで終わらない

機密データをAmazon S3やAmazon EBSへ保存するとき、保管中の暗号化を有効にするだけでは設計は完成しません。

どのキーで暗号化？
        ↓
誰がキーを使える？
        ↓
誰がキーを管理できる？
        ↓
別アカウントから使う？
        ↓
大量データをどう効率的に暗号化？
        ↓
専用HSM要件はある？

AWS KMSは、こうした暗号化キーの生成・管理と暗号化オペレーションを中央化するサービスです。

2. AWS KMSの主役はKMSキー

AWS KMSではKMSキーを使って暗号化処理や鍵保護を行います。

アプリケーション / AWSサービス
        │
        ▼
      AWS KMS
        │
        ▼
      KMSキー

標準的な対称暗号化KMSキーのキーマテリアルはAWS KMS内で保護され、アプリケーションがキーマテリアルをダウンロードして利用する仕組みではありません。アプリケーションやAWSサービスはAWS KMS APIやサービス統合を通じてKMSキーを利用します。

3. KMSキーは管理主体で選ぶ

キー	管理主体	主な判断
AWS所有のキー	AWSサービス	管理負荷を最小化
AWSマネージドキー	AWSサービス	自分のアカウント内に存在するが、ポリシー / ライフサイクルはサービス側が管理
カスタマーマネージドキー	顧客	ポリシー / ライフサイクル / 利用方法を自社で制御

細かなキー制御が必要ならカスタマーマネージドキーを評価し、サービス標準の暗号化で要件を満たせるなら不要な管理負荷を追加しません。

4. カスタマーマネージドキーを選ぶ決定打

次のようにキーそのものへの制御が必要な場合は、カスタマーマネージドキーを評価します。

セキュリティチームがキーポリシーを管理

キーを無効化できる必要がある

利用プリンシパルを自社で制御

クロスアカウントでキーを共有

利用状況をCloudTrailで監査

一方、サービス標準の暗号化で十分で、独自キーポリシーやクロスアカウントキー制御が不要なら、カスタマーマネージドキーを追加すること自体を目的にしません。

重要なのは、カスタマーマネージドキーの方が常に正解なのではなく、制御要件があるかです。

5. キーポリシーはKMSキー側のアクセス制御

すべてのKMSキーにはキーポリシーがあり、KMSキーに関連付けられるリソースポリシーとしてアクセス制御の中心を担います。

誰が
↓
どのKMS操作を
↓
このキーへ実行できる？

キーポリシーでは、KMSキーを利用するプリンシパルと、キーを管理するプリンシパルを分けて設計できます。

6. IAM ポリシーはプリンシパル側の権限

IAM ポリシーでは、プリンシパル側へKMS操作の権限を与えます。

アプリケーションロール
↓
kms:Decrypt
↓
特定KMSキー ARN

ただし、IAM ポリシーにkms:Decryptを書いただけで必ずKMSキーを利用できるわけではありません。キーポリシー側がIAM ポリシーによる委任を認めていなければ、IAM ポリシーの許可は有効になりません。

7. キーポリシーとIAM ポリシーは同じ役割ではない

ポリシー	主な責任
キーポリシー	KMSキー側から、誰にキーアクセスを認めるか
IAM ポリシー	プリンシパル側から、どのKMS操作を実行できるか

同一アカウントでは代表的に、キーポリシーでアカウントへIAM ポリシーによる委任を認め、そのうえでIAM ポリシーからアプリケーションロールへkms:Decryptなどを許可できます。

一方、キーポリシーから特定プリンシパルへ直接権限を与える構成もあります。したがって、同一アカウントでは常に「キーポリシーとIAM ポリシーの両方に同じ許可を書く」と暗記しないことが重要です。

8. キー管理者とキー利用者を分ける

セキュリティチーム
→ キーポリシー変更
→ 有効化 / 無効化
→ キーライフサイクル管理

アプリケーションロール
→ 暗号化 / 復号だけ

キー管理者とキーユーザーは別の責任です。アプリケーションへkms:*を与えるのではなく、暗号化処理に必要な運用だけを許可し、キー管理権限は必要な管理者へ分離します。

9. 大量データはデータキーで暗号化する

AWS KMSで大量のアプリケーションデータそのものを直接暗号化し続けるのではなく、一般的にはデータキーを使用します。

KMSキー
    │
    ▼
データキー
    │
    ▼
大規模アプリケーションデータ

データキーは実データを暗号化するための対称キーで、AWS KMSの外部で暗号化処理に利用できます。

10. GenerateDataKeyで2つのデータキー表現を受け取る

GenerateDataKeyを利用すると、概念的に次の2つを取得します。

出力	用途
平文データキー	実データの暗号化に利用し、不要になればメモリから破棄
暗号化済みデータキー	暗号化済みデータと一緒に保存可能

AWS KMSはデータキーの平文と、指定したKMSキーで暗号化したコピーを返します。

11. エンベロープ暗号化

この階層構造をエンベロープ暗号化と呼びます。

暗号化時

KMSキー
    │
    │ GenerateDataKey
    ▼
平文データキー
    │
    ├──────────────┐
    │              │
    ▼              ▼
データを暗号化暗号化済みデータキー
    │              │
    └──────┬───────┘
           ▼
       一緒に保存

KMSキーが大規模データを直接暗号化するのではなく、KMSキーがデータキーを保護し、データキーが実際のデータを暗号化すると考えます。

12. 復号時

保存されているのは、暗号化済みデータと暗号化済みデータキーです。

暗号化済みデータキー
        │
        ▼
      AWS KMS
        │
        │ Decrypt
        ▼
平文データキー
        │
        ▼
暗号化済みデータを復号

暗号化済みデータを取得できても、必要なKMS 権限がなければ平文へ復号できない設計にできます。

13. データアクセスとキーアクセスを分離する

SSE-KMSで暗号化されたS3 オブジェクトを概念的に考えると、アプリケーションにはストレージ側の権限とKMS側の権限がそれぞれ必要になります。

アプリケーションロール
│
├─ S3 権限
│    → オブジェクトを取得
│
└─ KMS 権限
     → データキーをDecrypt

これにより、ストレージ管理者と暗号化キー管理者を分けるなど、データアクセスとキーアクセスの責任分離を設計できます。

14. 別アカウントのKMSキーを使う

エンタープライズ環境では、セキュリティアカウントにカスタマーマネージドKMSキーを集約し、アプリケーションアカウントから利用する構成があります。

セキュリティアカウント
└─ カスタマーマネージド KMSキー

アプリケーションアカウント
└─ アプリケーションロール

この場合はクロスアカウント KMS アクセスを設計します。

15. クロスアカウントでは両アカウント側の権限が必要

キー 所有者 アカウント
キーポリシー
↓
外部アカウント / プリンシパルへ
キー利用を許可

        AND

外部アカウント
IAM ポリシー
↓
呼び出し元へ
必要なKMS操作を許可

クロスアカウントでKMSキーを利用する場合、キー所有者側のキーポリシーと、外部アカウント側のIAM ポリシーの両方を確認します。どちらか一方だけでは成立しません。

16. クロスアカウント権限はキー管理全般を委譲しない

クロスアカウントで有効になる権限は、暗号化運用や一部の付与 / キー情報運用などに限定されます。

例えば外部アカウントへkms:ScheduleKeyDeletionを許可するポリシーを書いても、別アカウントのKMSキーを削除できるわけではありません。

キー 所有者 アカウント
→ キーライフサイクル / ポリシー管理

アプリケーションアカウント
→ 必要な暗号化 / Decrypt利用

運用一覧を暗記するより、外部アカウントへキーの利用は委譲できても、キー所有者としてのライフサイクル管理まで移るわけではないと理解します。

17. 集中鍵管理では依存関係も評価する

中央セキュリティチーム
↓
キーポリシー / ライフサイクルを統制

アプリケーションアカウント
↓
必要な暗号化権限だけ使用

集中管理にはガバナンス上の利点がありますが、中央キーを無効化したときに複数ワークロードへ影響する可能性もあります。

したがって、中央ガバナンス + 最小権限 + 可用性 / 影響範囲を一緒に評価します。

18. 標準KMSで満たせないHSM 制御要件を確認する

多くのワークロードでは標準AWS KMSで要件を満たせます。しかし次のような明確な要件がある場合はAWS CloudHSMを評価します。

シングルテナント HSMが必須

HSMクラスターを自社で直接管理したい

キーマテリアルの配置を
カスタマーマネージド HSMへ限定したい

AWS CloudHSMでは、自分のAWSアカウント内のHSMクラスターを管理し、そのHSM内で暗号キーを生成・保存・利用できます。

19. AWS KMSとAWS CloudHSMは「上位・下位」ではない

判断	AWS KMS	AWS CloudHSM
キー管理の運用負荷	低い	高い
AWSサービス統合	広い	アプリケーション側統合が必要
HSMを直接管理	AWS側	顧客
シングルテナント HSM 制御	通常は不要	○
主な用途	一般的なエンタープライズ暗号化	明示的な専用HSM要件

CloudHSMは「KMSより常にセキュリティが高い」選択肢ではありません。HSM 制御と引き換えに顧客側の管理・可用性責任が増えます。

20. KMSの使い勝手とCloudHSM 制御を組み合わせる

「AWSサービスからKMS API / 統合は使いたいが、キーマテリアルは自社管理CloudHSMクラスターへ置きたい」という要件では、AWS CloudHSM キーストアを使用するAWS KMS カスタムキー保管先を評価できます。

AWSサービス / アプリケーション
        │
        ▼
      AWS KMS
        │
        ▼
カスタムキー保管先
        │
        ▼
カスタマーマネージド
AWS CloudHSMクラスター

この構成ではKMSキーの暗号化運用がCloudHSMクラスター内のHSMで実行されます。ただし、標準KMSより機能制約があり、CloudHSMクラスターの可用性・バックアップ・運用について顧客責任が増えます。

専用HSM要件がないのに「より安全そう」という理由だけで追加しないことが重要です。

21. マルチリージョンキーは明示的な要件がある場合だけ評価する

KMSキーは基本的にリージョン規模のリソースです。複数リージョンで同じキーマテリアルを利用し、リージョンをまたいだKMS呼び出しや再暗号化を避けたいという明確な要件ではマルチリージョンキーを評価できます。

関連するマルチリージョンキーは同じキー IDとキーマテリアルを持ちますが、各リージョンのKMSキーリソースは独立しており、キーポリシー・付与・エイリアス・有効/無効状態などの独立プロパティは自動で完全同期されません。

マルチリージョンキーは、明示的なマルチリージョン要件がある場合に評価する補足的な選択肢です。

22. 要件からアーキテクチャを選ぶ

要件	基本判断
AWS標準暗号化で十分、独自キー制御不要	AWS所有 / サービス管理キーをまず評価
キーポリシーやライフサイクルを自社管理	顧客マネージドKMSキー
アプリケーションで大量データを暗号化	データキー + エンベロープ暗号化
データアクセスとキーアクセスを分離	ストレージ権限 + KMS 権限
別アカウントから顧客マネージドキーを利用	キーポリシー + 外部アカウント IAM ポリシー
セキュリティアカウントでキーを集中管理	クロスアカウント KMS + 最小権限
シングルテナント HSMを直接管理する必要	AWS CloudHSM
KMS 統合 + カスタマーマネージド HSM	AWS CloudHSM キーストア
複数リージョンで同じキーマテリアルが必要	マルチリージョンキーを評価

23. 混同ポイント

IAM ポリシーにkms:Decryptがある = 必ずDecrypt可能：キーポリシー側のアクセス制御も確認します。
同一アカウントのKMS アクセス = キーポリシーとIAM ポリシーへ必ず同じ許可を書く：キーポリシーが直接プリンシパルを許可する方式と、IAM ポリシーへ委任する方式があります。
KMSキー = 大量データを直接暗号化するキー：大量データではデータキー / エンベロープ暗号化が基本です。
暗号化済みデータキー = 平文キー：KMSキーで保護された状態なので暗号化済みデータと保存できます。
クロスアカウント KMS = 外部 IAM ポリシーだけ：所有者側キーポリシーも必要です。
CloudHSM = KMSより常に優れている：HSM 制御と引き換えに顧客責任が増えます。
マルチリージョンキー = 世界に1つのグローバル KMSキー：各リージョンに独立したKMSキーリソースがあります。

24. SAP-C02判断フロー

保存データを保護したい
        │
        ▼
独自キー制御が必要？
   ┌────┴────┐
  いいえ      はい
   │          │
   ▼          ▼
サービスカスタマーマネージド
デフォルト     KMSキー
暗号化      │
                ▼
       誰がキーを管理？
       誰がキーを利用？
                │
                ▼
       キーポリシー / IAM ポリシー
                │
                ▼
       大量データを暗号化？
          ┌─────┴─────┐
         はい      いいえ
          │            │
          ▼            ▼
       データキー       KMS操作
          │
          ▼
エンベロープ暗号化
          │
          ▼
クロスアカウント利用？
          │
         はい
          ▼
所有者 キーポリシー
+
外部 IAM ポリシー
          │
          ▼
専用HSM 制御が必須？
          │
         はい
          ▼
AWS CloudHSM
または
CloudHSM カスタムキー保管先

25. まとめ

AWS KMS
→ 暗号化キー管理

カスタマーマネージド KMSキー
→ ポリシー / ライフサイクル / 利用方法を自社管理

キーポリシー
→ KMSキー側

IAM ポリシー
→ プリンシパル側

データキー
→ 実際のデータを暗号化

KMSキー
→ データキーを保護

エンベロープ暗号化
→ データとキーを階層化して保護

クロスアカウント
→ 所有者 キーポリシー
   +
   外部 IAM ポリシー

AWS CloudHSM
→ シングルテナント HSMを顧客管理

CloudHSM カスタムキー保管先
→ KMS統合
   +
   カスタマーマネージド HSM

最重要ポイントは、「KMSで暗号化する」で止めず、キーの管理主体・権限・データキー・アカウント境界・HSM要件まで分解してアーキテクチャを決めることです。

26. 主要AWS公式資料

理解確認

このページの内容を17問で確認します。

理解確認17問へ →