AWS再入門 – Amazon KMS編
当エントリはDevelopers.IOで弊社AWSチームによる2015年アドベントカレンダー『AWS サービス別 再入門アドベントカレンダー 2015』の5日目のエントリです。 昨日4日目のエントリはしんやの『Amazon Redshift 』でした。
このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
本日5日目のテーマは『Amazon Key Management Service』です。
Amazon KMSとは
Amazon Key Management Service(AWS KMS)はデータの暗号化に使用する暗号化キーを簡単に作成および管理できるマネージドサービスです。
以下のような特徴があります
- 完全マネージドである
- 暗号化鍵を一元管理できる
- 暗号鍵は99.999999999%の耐久性
- AWSの各種サービスのデータを暗号化
- アプリケーションデータを暗号化
- キーの操作履歴をCloudTrailログに残し、監査可能
ユースケース
AWS KMS は他のサービスと連携して利用されることが一般的です。 サービス単体ではイメージがつかみにくいため、幾つかのユースケースを見ていきましょう。
サーバーサイド暗号
サーバーサイド暗号では、AWS にデータ送信した後でサーバー(AWS)が AWS KMS の暗号キーを利用してデータを暗号化します。 データ受信の場合は、サーバー(AWS)が AWS KMS の暗号キーを利用してデータを復号化します。
S3 に保存するオブジェクトを AWS KMS の暗号キーで暗号化するケースなどがこのサーバーサイド暗号に該当します。
AWS KMS で管理されたキーによるサーバー側の暗号化 (SSE-KMS) を使用したデータの保護
AWS KMS は
- AWS CloudTrail
- Amazon Elastic Block Store (Amazon EBS)
- Amazon Elastic MapReduce (Amazon EMR)
- Amazon Elastic Transcoder
- Amazon Redshift
- Amazon Relational Database Service (Amazon RDS)
- Amazon Simple Email Service (Amazon SES)
- Amazon Simple Storage Service (Amazon S3)
- Amazon WorkMail
- Amazon WorkSpaces
など多くの AWS サービスと連携してデータを暗号化します。詳細は次のページをご確認ください。
クライアントサイド暗号
クライアントサイド暗号では、AWS にデータ送信する前にクライアントが AWS KMS の暗号キーを利用してデータを暗号化します。 データ受信の場合は、暗号化されたデータを受け取ったあと、クライアントが AWS KMS の暗号キーを利用してデータを復号化します。
データを KMS で暗号化したあとで DynamoDB にデータ保存するケースなどがこのクライアントサイド暗号に該当します。
Amazon DynamoDB 向けのクライアントサイド暗号
アプリケーション内のデータをクライアントサイド暗号
AWS KMS の暗号化キーを利用して暗号化したデータ(クレデンシャルなど)をアプリケーションに埋め込み、アプリケーション実行時に復号化します。
AWS Lambda 関数内にセンシティブなデータを AWS KMS で暗号化するケースなどが該当します。
PCI 準拠
別角度で PCI DSS に準拠したシステムを AWS 上で構築することを考えてみましょう。
どれだけ強力なサービスか、PCI 準拠の観点から見てみましょう。
セキュリティインテリジェンス会社 Anitian が AWS と共同でまとめた AWS クラウド上の PCI コンプライアンスに関するレポートによると、準拠のために利用できる AWS サービスとして KMS は IAM とともに欠かせないサービスであることがわかります(セクション 4.1.3 から)。
AWS サービス | 対応するPCI 要求項目 |
IAM
KMS |
1.3.8 ,2.2.4 ,3.4.1 ,3.5.1 ,3.6.1-5 ,3.6.7 ,6.4.1-2 ,7.1.1-3 ,7.2.1-3 ,8.1.1-2 ,8.2.1-6 ,8.3 ,8.7 |
S3 | 3.1, 3.4.1, 10.5.1-5, 10.7 |
CloudTrail
CloudWatch |
10.1-3, 11.5 |
EC2
Security Groups AMI EBS |
1.1.4 ,1.2.1 ,1.3.1-3 ,1.3.5-7 ,2.1 ,3.4.1 ,4.1 ,6.4.1 |
RDS | 34.1 |
Config | 11.5 |
AWS CloudHSM との違い
AWS には AWS ClouhdHSM という専用ハードウェアを利用した Key Management Service もあります。 オンプレミスの KMS ソリューションも含めた比較は次の表をご覧ください。
Key Management Service という点では三者とも機能は同じですが、AWSサービスとの親和性や運用コストの点では、AWS KMSの優位性が際立っています。
AWS KMS の鍵管理
AWS KMS の鍵は管理と利用の2面があり、それぞれ個別に権限設定できます。鍵の管理を考えてみましょう。
キーの更新
1年単位でキーを自動更新できます。
キーが更新されても、キーIDが変わりません。キーが更新されるたびに、キーIDに新しいバージョンのキーがひもづきます。
暗号化は常に最新のキーで行われ、過去の暗号データは暗号化された時のキーで復号されます。ユーザーはキーIDを指定するだけで、キーIDに紐づくどのキーを利用するかを指定する必要はありません。
鍵の削除
不要になったキーは削除できます。
キーがうっかり削除されると、削除した鍵を利用したデータは復号できなくなります。 不慮の事故に備え、AWS KMS ではキー削除時に猶予期間が設定されます。
キー削除が原因で復号できないデータが検出されたら、削除をキャンセルしましょう。
ログ監査
AWS CloudTrail を有効にすると、AWS KMS への API はすべて履歴として残ります。 AWS のサービス全般で履歴は取得可能なため、全リージョンで CloudTrail を有効化しましょう。
AWS KMS の暗号処理について
テクニカルな点が気になるかた向けに、AWS KMS の暗号処理について説明します。
概要編
暗号の利用する鍵と鍵の権限管理については次の資料をご確認ください。
AWS KMSを使ったサーバーサイド暗号では、マスターキーとデータキーをつかったエンベロープ暗号の理解が重要です。
クライアントサイドで AWS KMS を使ったエンベロープ暗号の実装例としては以下のプロジェクトがあります。
暗号化コンテキストを使った改ざん防止
AWS KMSには暗号化コンテキスト(Encryption Context)という形で追加認証データ(AAD)が組み込まれています。
この機能をつかうと、暗号時と復号時でコンテキストが異なる場合や暗号文が変更された場合に復号処理が失敗します。
詳細は次の資料をご確認ください。
あわせて読みたい公式情報
- Amazon Key Management Service ドキュメント | アマゾン ウェブ サービス
- AWS KMS と暗号法の用語
- AWS Black Belt Techシリーズ AWS Key Management Service
- AWS Black Belt Tech シリーズ 2015 - AWS Cloud HSM & AWS Key Management Service
- AWS re:Invent 2015 | (SEC301) Strategies for Protecting Data Using Encryption in AWS
- ホワイトペーパー:AWS Key Management Service 暗号詳細
- AWS Key Management ServiceとEncryptionContextを利用して暗号化データの完全性を保護する方法
最後に
以上、『AWS サービス別 再入門アドベントカレンダー 2015』の5日目のエントリ『Amazon KMS編』でした。 AWS KMS を実際に触ったことがある方は少数と思われますが、データ保全の点では、非常に強力なサービスです。 今回の記事をきっかけに AWS KMS について少しでも興味を持っていただけると幸いです。
明日(12/6)は カジ さんによる『Amazon WAF』の予定です。お楽しみに!