AWS再入門 – Amazon KMS編

2015.12.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

当エントリは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 にデータ送信する前にクライアントが AWS KMS の暗号キーを利用してデータを暗号化します。 データ受信の場合は、暗号化されたデータを受け取ったあと、クライアントが AWS KMS の暗号キーを利用してデータを復号化します。

データを KMS で暗号化したあとで DynamoDB にデータ保存するケースなどがこのクライアントサイド暗号に該当します。

Amazon DynamoDB 向けのクライアントサイド暗号

アプリケーション内のデータをクライアントサイド暗号

AWS KMS の暗号化キーを利用して暗号化したデータ(クレデンシャルなど)をアプリケーションに埋め込み、アプリケーション実行時に復号化します。

AWS Lambda 関数内にセンシティブなデータを AWS KMS で暗号化するケースなどが該当します。

KMSで認証情報を暗号化しLambda実行時に復号化する

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年単位でキーを自動更新できます。

kms_key_rotation

キーが更新されても、キーIDが変わりません。キーが更新されるたびに、キーIDに新しいバージョンのキーがひもづきます。

暗号化は常に最新のキーで行われ、過去の暗号データは暗号化された時のキーで復号されます。ユーザーはキーIDを指定するだけで、キーIDに紐づくどのキーを利用するかを指定する必要はありません。

鍵の削除

不要になったキーは削除できます。

kms_delete_key

キーがうっかり削除されると、削除した鍵を利用したデータは復号できなくなります。 不慮の事故に備え、AWS KMS ではキー削除時に猶予期間が設定されます。

kms_schedule_key_deletion

キー削除が原因で復号できないデータが検出されたら、削除をキャンセルしましょう。

kms_cancel_deletion

ログ監査

AWS CloudTrail を有効にすると、AWS KMS への API はすべて履歴として残ります。 AWS のサービス全般で履歴は取得可能なため、全リージョンで CloudTrail を有効化しましょう。

AWS KMS の暗号処理について

テクニカルな点が気になるかた向けに、AWS KMS の暗号処理について説明します。

概要編

暗号の利用する鍵と鍵の権限管理については次の資料をご確認ください。

AWS KMSを使ったサーバーサイド暗号では、マスターキーデータキーをつかったエンベロープ暗号の理解が重要です。

クライアントサイドで AWS KMS を使ったエンベロープ暗号の実装例としては以下のプロジェクトがあります。

暗号化コンテキストを使った改ざん防止

AWS KMSには暗号化コンテキスト(Encryption Context)という形で追加認証データ(AAD)が組み込まれています。

この機能をつかうと、暗号時と復号時でコンテキストが異なる場合や暗号文が変更された場合に復号処理が失敗します。

詳細は次の資料をご確認ください。

あわせて読みたい公式情報

最後に

以上、『AWS サービス別 再入門アドベントカレンダー 2015』の5日目のエントリ『Amazon KMS編』でした。 AWS KMS を実際に触ったことがある方は少数と思われますが、データ保全の点では、非常に強力なサービスです。 今回の記事をきっかけに AWS KMS について少しでも興味を持っていただけると幸いです。

明日(12/6)は カジ さんによる『Amazon WAF』の予定です。お楽しみに!