KMS CMK を使って AWS のセキュリティを向上させる

こんにちは、ソフトエンジニアの宮川です。記念すべき Cloud Security Magazineの1本目は AWS の暗号化を司る AWS KMS の解説記事です。

一般的に暗号化することで、万が一、システムに侵入されたときや、それに伴ってデータが漏えいしたときに機密情報の取得を困難にできます。

KMS (Key Management Service)

KMS とは

KMS とは、AWS が提供するキーのマネージドサービスです。KMS で管理されるキーはデータの暗号化やデジタル署名に使用されます。

KMS を使うと単にデータの暗号化や署名をするだけでなく、AWS サービスの暗号化のキーとして指定することも可能です。（むしろこの用途の方が広く使われている認識です。）

KMS での暗号化は KMS を使うことで暗号化できる代表的なサービスは S3、RDS、EBS、ECR、Secrets Manager など、多くのサービスに対応しています。

また、AWS ユーザー自身が作成するキーのことを CMK (Customer Master Key) と呼びます。CMK を使うことでより柔軟に権限設定を行うことが可能です。

対応している暗号化方式

キー作成時は「対称キー」と「非対称キー」から選択することができます。また、「非対称キー」を選択した場合は、複数の暗号化アルゴリズム（RSA, ECC など複数）から選択することができます。

選択できる暗号化アルゴリズム: https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose.html#symm-asymm-choose-key-spec

2022/03/22 現在の対応している暗号化アルゴリズム（署名および検証用途の場合）

KMS のメリット

管理コストがかからない

KMS は AWS のマネージドサービスのためもちろん管理コストがかかりません。後述しますが、コンソールからでも Terraform からでも簡単に作成可能です。

また、AWS 側で自動的にキーのローテーションまで行ってくれます。追加の実装なくキーの安全性を担保し続けられます。

安全な設計

公式ドキュメントでも言及されているように外部にデータが転送されないように厳重な設計がされています。

AWS KMS のデータは、AWS KMS keys と、それらが表す暗号化キーマテリアルで構成されます。このキーマテリアルは、AWS KMS ハードウェアセキュリティモジュール (HSM) 内でのみ、かつ使用中の場合にのみ、プレーンテキストで存在します。それ以外の場合、キー素材は暗号化され、耐久性のある永続ストレージに保存されます。

from: https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/data-protection.html

AWS ユーザー、AWS 社員誰もがキー自体を参照できないようです。

CloudTrail でキーの監査ログを取得可能

CloudTrail を利用することで、キーの利用状況の監査ログを取得することができます。つまり、どのデータに誰がアクセスしたのかを追跡することが可能です。

インシデントの際に調査ができるため便利です。

CMK (Customer Master Key)

CMK とは

日本語では「カスタマー管理のキー」と呼ばれ、AWS 利用ユーザーが独自に作成したキーのことを指します。

CMK 以外には AWS 管理のキーが存在しています。RDS や Secrets Manager など暗号化を用いる AWS サービスのデフォルトのキーはこれに当たります。

CMK を使うメリット

CMK を使うことで、キーの利用をより細かく制御することができます。

具体的には、「キーポリシー」と「IAM ポリシー」での制御が可能です。これら2つの制御機構は基本的には OR 条件です。

つまり、キーポリシーで許可していない IAM Role であっても、CMK の利用の権限をその IAM Role に付与することでアクセスすることが可能です。逆も然りで、キーポリシーで許可しておくと、IAM Role に権限がなくてもアクセスすることができます。

KMS で回避することができるセキュリティリスク

AWS 側でのインシデントのリスク

万が一、AWS のデータセンターからディスクが盗難された場合や AWS 内部の人間が不正にアクセスしようとした場合に、暗号化していないデータは漏えいしてしまうリスクがあります。

また、廃棄したディスクも同様で、暗号化していないデータは読み出されるリスクがあります。

システムに侵入された際のリスク（CMK 限定）

内部に侵入された際であっても適切に CMK の権限管理がなされていると、データを復号化することができないのでデータの漏えいリスクを下げることができます。

例えば、Secrets Manager の場合、デフォルトキーを使って暗号化していると、Secrets Manager の権限のみで暗号化されたデータを復号化して取得できてしまいます。一方で、CMK を使って暗号化している場合は、Secrets Manager に加えて KMS のアクセスも必要です。

そのため、CMK を用いているケースの方がより詳細な権限管理となっているため、侵入された際のデータ漏えいリスクをさらに下げることが可能です。

とはいえ、データごとにキーを作っているとキーの管理自体が煩雑になってしまいます。そこで、弊社では機密度ごとの粒度でキーを発行して暗号化し、CMK へのアクセスするポリシーを最小限に絞るようにして運用しています。

コンプライアンス準拠

これは直接的なリスクではないですが、上記のようなリスクを回避することがコンプライアンス基準で求められるケースが多いです。これらに準拠しようとすると、KMS を使った暗号化は必須です。

代表的なコンプライアンス基準である PCI DSS でも、RDS や EBS など保存時の暗号化が求められています。