KMSとは

データ暗号化に使用される暗号化キーの作成と管理を行う、AWSのマネージドサービス。
AWSのサービスで暗号化処理が行われる場合、ほとんどはこのKMSのキーが使用される。

KMSを使用するメリット

マネージドサービスのため、以下の管理がAWS側の責任となる
- キーの可用性
- 物理的セキュリティ
- ハードウェア管理
暗号化キーの操作履歴がすべてCloudTrailに保存されるため、監査やコンプライアンスの要件にも応えることができる

KMSの暗号化の仕組み

KMSでは、Envelope Encryption(エンベロープ暗号化)という仕組みが採用されている。
具体的には、CMKとCDKという2種類のキーを使用し、データを暗号化するキー(CDK)をさらに別のキー(CMK)で暗号化するという仕組み。

データ暗号化の流れ

①アプリケーションからGanerateDataKeyオペレーションを使用してCDKを生成
②KMSでCMKが複号される
③復号されたCMKを使用し、生成されたCDKを暗号化
④アプリケーションにプレーンなCDKと暗号化されたCDKが返される
⑤④で返されたプレーンなCDKを使用して対象データを暗号化。この時点でプレーンなCDKとプレーンなデータは必ず破棄される。
⑥暗号化されたデータと暗号化されたCDKをDBに格納する

データ復号の流れ

①アプリケーションからDecryptオペレーションを使用してKMSからCMKを取り出す
②保存していた暗号化CDKを復号する
③復号したCDKを使用して、保存していた暗号化データを復号する

CMKのタイプ

CMKには以下3つのタイプがある。

カスタマー管理CMK
AWS管理CMK
AWS所有CMK

カスタマー管理CMK

カスタマー側（AWS利用者）が作成・所有・管理するCMK
ユーザが開発したアプリケーションでデータを暗号化する際に使用する
以下の操作が可能
- キーポリシーやIAMポリシーによるアクセス制御
- 有効化と無効化
- ローテーション
- エイリアス作成
- 削除のスケジューリング
- 1年ごとの自動ローテーション有効化/無効化

AWS管理CMK

AWSサービスが利用者に代わって作成・管理・使用するCMK
KMSのマネジメントコンソール上に”aws/[サービス名]”といった形で表示される
- 例：redshiftで使用されるCMK→「aws/redshift」
- この仕様により、カスタマー管理CMKでは「aws」から始まるCMKは作成できない
可能な操作はキーポリシーの表示のみ
3年ごとにAWS側で自動ローテーションされる

AWS所有CMK

アカウントに関係なくAWSが所有し管理しているCMK
利用者側からは見えない
AWSサービスが裏側で暗号化のために使用するもの

CMK比較表

CMKのタイプ	CMK管理	AWSアカウント内	メタデータ表示	ローテーション
カスタマー管理CMK	〇	〇	〇	1年間
AWS管理CMK	×	〇	〇	3年間
AWS所有CMK	×	×	×	-

CMKの有効化と無効化

カスタマー管理のCMKは、無効化と、無効化後の再有効化ができる（※AWS管理のCMKは永続的に有効化されていて、無効化できない）。
そのため、CMKを削除するのが不安な場合はまず無効化を実施し、そのCMKを使用していない（エラーが発生していない）ことを確認するのが望ましい。

CMKの削除

カスタマー管理CMKは削除することができる。
ただし削除したCMKは元に戻せないため、2度と使用することはできない。
これは対象のCMKで暗号化したデータが復号できなくなることを意味しているので、非常にリスクが高い。

そのため、CMKの削除は即時実行ができない仕様となっており、7～30日の待機期間が設けられている（デフォルトは30日間）。
待機期間はCMKの削除は実行されず、「削除保留中」というステータスとなる。
このステータスの間、対象のCMKを使用することはできない。

CMKのローテーション

KMSには自動キーローテーションという機能がある。
自動キーローテーションを有効化すると、1年ごとにキーが自動でローテーションされる（1年という期間は変更することができない）。

ローテーションにより新しいCMKが作成されるが、もちろんローテーション前のキーで暗号化していたデータも問題なく復号することができる。
これは、CMKがローテーション前の古いキー情報も保持しているためである。
この、過去の情報を保持しているキーを**「バッキングキー」**と呼ぶ。
古いキーで暗号化されたデータは新しいキーで再暗号化されるわけではなく、暗号化時には最新のキーが使われ、復号時には暗号化に使用したバッキングキーが使用される仕組みとなっている。

ポリシーによるアクセス制御

CMKのアクセス制御にはキーポリシーとIAMポリシーを使用することができ、それぞれ以下の役割を担っている。

キーポリシー：CMKを対象にアクセス制御を行う
IAMポリシー：CMKを使用する側（IAMユーザーやIAMロール）に対してアクセス制御を行う

キーポリシーとIAMポリシー両方で許可された操作のみ可能となるため、これらを上手く組み合わせてアクセス制御を行うことが必要。

キーポリシーの書き方

キーポリシーは以下のように記載する。基本的にはIAMポリシーの書き方と同様。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "statement identifier",
    "Effect": "effect",
    "Principal": "principal",
    "Action": "action",
    "Resource": "resource",
    "Condition": {"condition operator": {"condition context key": "context key value"}}
  }]
}

各ステートメントの内容
- Sid：任意の識別子。（オプション）
- Effect：AllowもしくはDenyを記載する。（必須）
- Principal：キーポリシーに書かれた権限を利用できるのは誰か指定する。（必須）
- Action：AllowまたはDenyするAPIを指定する。（必須）
- Resource：対象リソースを指定する。（必須）
- Condition：キーポリシーを有効にするために満たす必要がある要件を指定する。（オプション）

クライアントサイド暗号化とサーバーサイド暗号化

KMSを利用した暗号化は、暗号化を行うタイミングにより、「クライアントサイド暗号化（Client-Side-Encryption）」と「サーバーサイド暗号化（Server-Side-Encryption）」の2種類に分けられる。

クライアントサイド暗号化

ユーザーがアプリケーションで暗号化を行う場合のこと
SDKでKMSのAPIを呼び出し、取り出したキーでデータを暗号化する
カスタマー管理CMKを使用することになる
暗号化した後、そのデータは通信経路上も暗号化された状態となり、よりセキュアにデータを扱うことができる
アプリケーションに暗号化の処理を加える必要があるため手間がかかる

サーバーサイド暗号化

AWSの各サービスが提供する暗号化機能を使用する場合のこと
AWSサービスがデータを受信後、自動的に暗号化する
カスタマー管理CMKまたはAWS管理CMKを使用することになる
AWSサービスまでの通信経路は暗号化されないため、クライアントサイド暗号化に比べるとセキュリティ強度が落ちる
アプリケーションに暗号化の処理を加える必要がないため、簡単に実装できる

参考