【初心者向け】AWS KMS 入門!完全ガイド
AWS Key Management Service(KMS)
☘️ はじめに
本ページは、AWS に関する個人の勉強および勉強会で使用することを目的に、AWS ドキュメントなどを参照し作成しておりますが、記載の誤り等が含まれる場合がございます。
最新の情報については、AWS 公式ドキュメントをご参照ください。
👀 Contents
- KMS とは
- 基本概念
- マスターキーとデータキー
- マスターキー
- エイリアス
- キーマテリアル
- キーポリシー
- マルチリージョンキー
- 別の AWS アカウントへの許可
- キーの削除
- データキーキャッシュ
- クライアントサイド暗号化とサーバサイド暗号化
- 📖 まとめ
KMS とは
暗号化操作に使用されるキーを簡単に作成および管理できるマネージドサービスです。
【AWS Black Belt Online Seminar】AWS Key Management Service(YouTube)(0:59:33)
基本概念
KMS では、エンベロープ暗号化を使用しています。
これは、データを暗号化する鍵(データキー)とデータキーを暗号化する鍵(マスターキー)を利用する方式で、セキュリティが強化されます。
KMS のキーに対する操作は CloudTrail に記録されます。詳しくは、「AWS KMS による AWS CloudTrail API コールのログ記録」を参照してください。
マスターキーとデータキー
KMS では、マスターキーとデータキーという 2 種類の鍵が登場します。
- マスターキー(Customer Master Key: CMK)
- データキーを暗号化するキー
- AWS の管理下において、マスターキーも暗号化して格納されています
- データキー(Customer Data Key: CDK)
- データを暗号化するキー
-
kms:GenerateDataKey
を使用して平文のデータキーと暗号化されたデータキーを都度生成します。 -
kms:GenerateDataKeyWithoutPaintext
では、暗号化されたデータキーのみを生成します。 - 後述のサーバサイド暗号化の場合はデータ暗号化後に平文のキーは削除されますが、クライアントサイド暗号化の場合はクライアント側が保持している平文のキーを削除するようにします。残しておいて第三者の手に渡った場合、暗号化されたデータを簡単に復号できてしまいます。
マスターキー
- AWS マネージド型キー
- AWS サービスが作成・管理する CMK で、キー名が「aws/s3」 のようになっています。
- 1 年ごとに自動的にローテーションされます
- 無効化や削除ができません
- カスタマー管理型のキー
- 利用者が作成・管理する CMK です。
- 自動ローテーションを有効化することで、1 年ごとにローテーションさせることができます。
- 1 年より短い周期でローテーションしたい場合は手動で新しいキーを作成します。
- 無効化や削除ができます。
- AWS 所有のキー
- AWS サービスの裏側で使用されるキーで、ユーザーからは見えないため、意識する必要はありません。
- 利用者から見えないので、無効化や削除はできません
エイリアス
CMK にはエイリアス(別名)を付けることができます。エイリアスを使用することで、キーをローテーションした場合など、エイリアスの紐づけを変更するだけで、アプリケーション側の更新が不要になります。
エイリアス名の ARN は次のようになります。そのため、リージョン/アカウントで一意にする必要があります。
arn:aws:kms:ap-northeast-1:123456789012:alias/aliasName
キーマテリアル
キーマテリアルとは、「暗号化キーを生成するために必要な材料」であり「CMK 作成時に使用されるデータのこと」をいいます。
キーマテリアルは、次の 3 種類が指定できます。
- KMS
- デフォルト
- AWS 独自のキーストアに作成され管理されます。
- アクセス制限はされていますが、物理的には他のアカウントと同じサーバ上に保管されています。
- 外部
- 利用者が作成した共通鍵を指定します
- カスタムキーストア(CloudHSM)
- これを利用するには、AWS CloudHSM クラスターを事前に作成しておく必要があります。
- AWS CloudHSM クラスター とは、ユーザー自身しかアクセスできない 専用 HSM(ハードウェアセキュリティモジュール)インスタンスを作成してデータセキュリティのコンプライアンスを満たすことができるキーストアを作成できるもの。HSM は VPC 内で実行されます。
- VPC 内に配置しているので、レイテンシーは低い。
- 冗長化構成は利用者の責任範囲となる。推奨は AZ を跨いだ 2 台以上の HSM インスタンス
- AWS CloudHSM の概要
- AWS CloudHSM のよくある質問
- 料金は東京リージョンでは、1 時間当たり 1.81USD と KMS に比べると高額です。
- 次のような要件がある場合に利用します。
- PCI DSS やその他の特定の縦断的なセキュリティ標準
- 政府のワークロード
- FIPS 認可要求ポリシー
- RDS Oracle での透過的なデータ暗号化 (Transparent data encryption: TDE) サポート
キーポリシー
CMK にはリソースベースのキーポリシーを付与することができます。
これにより、特定のサービスからのみアクセスさせるといった制御ができます。
CMK 作成時にはデフォルトのキーポリシーが設定されているので、必要に応じて変更します。
キーポリシーに指定できる代表的な条件は次のとおりです。その他については、AWS KMS 条件キーを参照してください。
- kms:ViaService
- kms:CallerAccount
- kms:EncryptionAlgorithm
- kms:KeyOrigin
- kms:ValidTo
マルチリージョンキー
単一リージョンで作成した CMK はエクスポートのインポートも出来ないため、作成したリージョン以外では使用することができません。
しかし、マルチリージョンキーを選択することで、複数のリージョンにレプリケートすることが可能です。
別の AWS アカウントへの許可
CMK は別のアカウントに使用を許可することができます。
次のように使用を許可するアカウントを指定すると、キーポリシーに反映されます。
キーの削除
CMK は即時削除することはできません。削除スケジュールを設定し、一定期間後に削除されます。
削除スケジュールは、7 日~ 30 日を指定できます。この期間内であれば削除をキャンセルすることができます。
削除されると、既存データを二度と復号できなくなるので注意が必要です。
削除ではなく、無効化することもできますのでまずは無効化を行い、本当にキーが使用されていないことを確認することを推奨します。
削除予定の CMK が利用されたら通知させることもできます。
削除予定または無効化された CMK の使用を通知
削除保留中の KMS キーの使用を検出するアラームの作成
キーステータスの表
CloudTrail に以下のイベントが記録されます。
-
削除予定
- KMSInvalidStateException
{ "errorCode": "KMSInvalidStateException", "errorMessage": "arn:aws:kms:ap-northeast-1:123456789012:key/XXX is pending deletion." }
-
無効化
- DisabledException
{ "errorCode": "KMSInvalidStateException", "errorMessage": "arn:aws:kms:ap-northeast-1:123456789012:key/XXX is disabled." }
フィルタパターン例
{($.eventSource=kms.amazonaws.com) && (($.errorCode="KMSInvalidStateException") || ($.errorCode="DisabledException"))}
OR
{($.eventSource=kms.amazonaws.com) && (($.errorCode="*Exception"))}
キーが削除予定または無効化された場合の通知
次の CloudTrail イベントを監視することで通知が可能です。
- 削除予定
- 「eventName」がScheduleKeyDeletion
- 無効化
- 「eventName」がDisableKey
フィルタパターン例
{($.eventSource=kms.amazonaws.com) && (($.eventName="DisableKey") || ($.eventName="ScheduleKeyDeletion"))}
データキーキャッシュ
AWS Encryption SDK の機能として、「データキーキャッシュ」があります。
これを利用することでデータキー取得の API コールを減らすことができます。
クライアントサイド暗号化とサーバサイド暗号化
KMS を利用した暗号化は、次の 2 種類があります。
- クライアントサイド暗号化(Client-Side-Encryption: CSE)
- アプリケーション側で暗号化を実施します。
- アプリケーション側で暗号化済みデータを送信するので、AWS までの通信経路上は暗号化された状態となります。
- クライアントサイドで暗号化/復号の処理が必要なため、実装に手間がかかります
- サーバサイド暗号化(Server-Side-Encryption: SSE)
- AWS の各サービスが提供する暗号化を利用します。(例:S3 バケット)
- AWS 側で暗号化し、データにアクセスがあった場合は自動的に復号されます。
- 通信経路上では暗号化されていません。(使用しているプロトコルによる暗号化は別)
- クライアントサイドでの暗号化/復号の処理が必要ないため、実装が容易になります。
Discussion