【AWSセキュリティ基礎】AWS Key Management Service(KMS)
こんにちは、SAAYAです。AWSのセキュリティに焦点を当て、いくつかのサービスについてまとめてみました。自己学習用ですが、参考になれば幸いです…！
KMSとは
データ暗号化に使用される暗号化キーの作成と管理を行う、AWSのマネージドサービス。
AWSのサービスで暗号化処理が行われる場合、ほとんどはこのKMSのキーが使用される。
KMSを使用するメリット
マネージドサービスのため、以下の管理がAWS側の責任となる
マネージドサービスのため、以下の管理が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
AWSサービスが利用者に代わって作成・管理・使用するCMK
KMSのマネジメントコンソール上に”aws/[サービス名]”といった形で表示される
例：redshiftで使用されるCMK→「aws/redshift」
この仕様により、カスタマー管理CMKでは「aws」から始まるCMKは作成できない
可能な操作はキーポリシーの表示のみ
3年ごとにAWS側で自動ローテーションされる
AWS所有CMK
アカウントに関係なくAWSが所有し管理しているCMK
アカウントに関係なくAWSが所有し管理しているCMK
利用者側からは見えない
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サービスまでの通信経路は暗号化されないため、クライアントサイド暗号化に比べるとセキュリティ強度が落ちる
アプリケーションに暗号化の処理を加える必要がないため、簡単に実装できる