AWS KMS（Key Management Service）

AWS Black Belt

AWS KMS

AWS Black Belt Online Seminar AWS Key Management Service (KMS) from Amazon Web Services Japan

■分かりやすい解説

10分でわかる！Key Management Serviceの仕組み #cmdevio

https://dev.classmethod.jp/articles/10minutes-kms

※図解且つシンプルな解説で分かりやすい。

AWS KMS の特徴

AWS Key Management Service (KMS) を使用することで、暗号化キーを簡単に作成して管理し、幅広い AWS のサービスやアプリケーションでの使用を制御できるようになります。

各アカウントで自動的に作成される AWS 管理のマスターキーを利用できます。AWS 管理のマスターキーを使用したくない場合（アカウント間またはサービス間でキーのアクセスを共有する機能など、キーの管理を完全にコントロールしたい場合）は、AWS KMS に独自のカスタマーマスターキー (CMK) を作成できます。ユーザー独自のアプリケーション内で、直接作成した CMK を使用することもできます。カスタマーマスターキー（CMK）はデータ暗号化キーを制御することができます。

データキーは、大量のデータや他のデータ暗号化キーといったデータを暗号化するための暗号化キーです。

KMS には 3 つのタイプ ①AWS 所有キー（AWS owned key）、②AWS 管理キー（AWS managed key）、③カスタマーマネージドキーがあります。カスタマーマネージドキー（CMK）をクライアント側で管理することも可能です。

KMS を利用して RDS、EC2 インスタンス、S3、Redshift などのデータを保護することができます。 

キーの有効期限を設定する場合はカスタマーマネージドキー（旧 CMK）を使用する

AWS 管理キー（AWS Managed Key）には有効期限を設定して無効にする制御はできません。有効期限を設定したい場合はカスタマーマネージドキー（Customer Managed Key）を使用する必要があります。更にカスタマーマネージドキーは持ち込みのキーでインポートをする際に有効期限を設定します。

KMS キーとデータキーの違い

様々な用語で混乱することがありますが、KMS キーとデータキーは異なります。

• KMS キー　…　データキーを保護する親キー
• データキー　…　実際にデータを暗号化するための一時的なキー

AWS 所有キー（AWS owned key）、AWS 管理キー（AWS managed key）、カスタマーマネージドキーの違いについて

様々な用語が異なるコンテキストで出てくるので混乱することがあります。まずは、以下の3種類をまとめて KMS Key（KMS キー）と言います。KMS Key（KMS キー）は、キー階層の最上位を表します。KMS Key には以下の 3種類のキーが含まれます。

• AWS 所有キー（AWS owned key）　…　AWS が所有・管理するキーでユーザー側は管理できません。
• AWS 管理キー（AWS managed key）　…　AWS がユーザーのアカウント内に作るキーです。
• カスタマーマネージドキー（Customer Managed Key）　…　ユーザーが作成するキーです。

AWS 所有キー（AWS owned key）

AWS が所有しているキー です。特徴は、ユーザーがアカウントのキーとして見えない、キーポリシーも見えない、基本的に管理もできないことです。

AWS 管理キー（AWS managed key）

AWS サービスがユーザーのアカウント内に自動作成する KMS キー です。たとえば aws/rds、aws/ebs、aws/s3 のような AWS 管理エイリアスで見えるものがこれです。

ユーザーのアカウント内に存在するので、メタデータ や CloudTrail の記録は見えますが、自由にキーポリシーを編集したり削除したりはできません。ローテーションはAWS側が毎年実施します。イメージとしては、自分のアカウントにはあるけれど、管理権はほぼAWS側にある鍵です。

使い道として向いているのは、まずは簡単にAWSサービスの暗号化を有効にしたい 場合です。ただし、アクセス制御や運用を細かく詰めたいときは不向きです。

カスタマーマネージドキー（Customer Managed Key、旧CMK）

ユーザーが作るKMSキー です。キーポリシー、IAMポリシー、Grant、エイリアス、タグ、有効/無効、削除予約、ローテーション まで自分で管理できます。AWS公式でも、フルコントロールしたい場合に推奨されるのがこれです。月額料金と使用料金がかかります。

イメージとしては、自分で所有・運用する本命の鍵です。向いているのは以下のようなケースです。

• 特定ロールだけに復号を許したい
• キーポリシーを細かく書きたい
• クロスアカウント利用したい
• 削除や無効化の運用を自分で管理したい
• 監査要件で自分が管理する鍵が必要

こういうときは、基本的にカスタマーマネージドキーを使います。

■AWS KMSが利用できる対象サービス

• AWS KMS は、ほとんどの AWS のサービスとシームレスに統合されています。

■AWS KMSが利用できる対象サービスに入っていないサービス

• EC2 インスタンス
• Route53

カスタムキーストア

AWS マネジメントコンソールの KMS のメニューにカスタムキーストアがあります。

カスタムキーストアは KMS キーのキーマテリアルを通常の AWS KMS 標準保管ではなく、別の保管先で扱うための仕組みです。カスタムキーストアとして主に AWS CloudHSM キーストア と 外部キーストア（XKS） を案内しています。

AWS CloudHSM キーストア

これは、ユーザー自身が所有・管理する CloudHSM クラスター内でキーマテリアルを生成・保存・利用する方式です。KMS への暗号操作リクエストは、裏で CloudHSM クラスターに転送されて処理されます。CloudHSM は AWS 上でホストされますが、シングルテナントで、可用性や運用の責任をユーザー自身で持つ点が標準 KMS と大きく違います。

AWS KMS External Key Store（外部キーストア、XKS）

AWS KMS External Key Store（外部キーストア）とは、AWS の外部にある鍵管理システムや HSM でキーマテリアル（鍵素材）を保持し、AWS KMS からはプロキシ経由で利用する方式です。規制要件の強いワークロード向けの上級機能です。鍵を AWS の外に置きたいという要件で使われます。AWS KMS のキーを使う形は保ちつつ、実際の鍵素材と暗号処理を AWS の外に置く仕組みです。

通常の KMS ではキーマテリアル（鍵素材）は AWS KMS 内にありますが、XKS ではキーマテリアル（鍵素材）は外部キーマネージャーから出ません。

カスタムキーストアの重要な特徴

カスタムキーストアのキーは、標準の KMS キーよりも可用性・性能・レイテンシの面で不利になる可能性があります。外部依存が増えるからです。また、外部キーストアでは、作成できるキーは外部キーストア起源の対称暗号化 KMS キーに限られ、非対称キー、HMAC キー、インポートキーマテリアル付きキーは作れません。CloudFormation の AWS::KMS::Key でも、カスタムキーストア上の KMS キーは作成対象にできないとされています。

サーバ側暗号化とクライアント側暗号化がある

• サーバ側暗号化（SSE-S3、SSE-KMS、SSE-C）
• クライアント側暗号化（CSE-KMS、CSE-C）

クライアント側暗号化の何が嬉しいかというと「Amazon S3 に送信する前にデータを暗号化できる」ことです。

クライアント側の暗号化を使用したデータの保護

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/UsingClientSideEncryption.html

その一方、サーバ側暗号化は「送信先でデータを暗号化する」ことを言います。

Amazon S3 は、データセンターのディスクに書き込まれるときにデータをオブジェクトレベルで暗号化し、クライアントがデータにアクセスするときに復号します。その為、例えば会社のPCからS3バケットへファイルをアップロードするとか保存する場合は、サーバ側の暗号化だけでなく、クライアント側の暗号化もするとよりセキュリティが高まります。

x-amz-server-side-encryption

x-amz-server-side-encryption は、S3 にオブジェクトを書き込むリクエストに付ける指定ヘッダーです。このヘッダーを付けるのはアップロードする側のクライアントで、判断するのは S3、対象は S3 に保存されるそのオブジェクトです。S3 の REST API では、PutObject やマルチパートアップロード開始時にこのヘッダーを指定できます。

どこで有効になる（判断される）？

S3 に保存されるオブジェクトの保存時の暗号化の際に判断されます。通信経路ではなくバケット内に保存された後のデータに対して判断されます。S3 のサーバー側暗号化は at rest の保護であり、S3 がオブジェクトを保存するときに暗号化を行います。

暗号化キーとは何か？

そもそも暗号化キーとは何でしょうか。公開鍵認証基盤の秘密鍵と公開鍵をイメージすればいいのでしょうか？それとも共通鍵をイメージすればいいのでしょうか？KMS は、「対称キー」と「非対称キー」のどちらも提供しています。なのでどちらをイメージしても間違いではありません。

対称キーと非対称キーの使用

https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/symmetric-asymmetric.html

AWS KMS は、対称暗号化 KMS キーと非対称 KMS キーをサポートしています。

対称暗号化 KMS キー

AWS KMS が生成する単一の対称鍵を表します。標準の対称暗号化 KMS キーは、通常 256-bit AES-GCM のキーマテリアルを使用します。このキーマテリアルが AWS KMS を平文のまま外部に出ることはありません。このキーを使った暗号化・復号を行うには、AWS KMS を呼び出す必要があります。

非対称 KMS キー

数学的に関連した公開鍵と秘密鍵のペアを表します。秘密鍵が AWS KMS を平文のまま外部に出ることはありませんが、公開鍵は取得して AWS KMS の外部で利用できます。非対称 KMS キーは、キー仕様に応じて、暗号化と復号、署名と検証、または鍵共有（key agreement）のいずれか1つの用途に使用します。

Encryption Context（暗号化コンテキスト）

KMSキーの Encryption Context（暗号化コンテキスト） は、暗号化するデータにひも付ける「追加の説明情報」 です。形式としては キーと値のペア で渡し、これを AAD（Additional Authenticated Data: 追加認証データ） として使い、暗号文に“結び付けて”保護します。暗号化時に付けた暗号化コンテキストと、復号時に指定する暗号化コンテキストが 完全一致 しないと復号できません。

Encryption Context（暗号化コンテキスト） は、復号時の取り違え防止のために使用します。対称暗号化 KMS キーを使う暗号化操作で利用します。非対称鍵の暗号化 や HMAC では暗号化コンテキストは利用できません。

KMS の自動キーローテーション機能

KMS の自動キーローテーション機能は、KMS キーそのものを作り直すのではなく、同じ KMS キーの中の鍵素材（キーマテリアル、key material）を定期的に入れ替える機能です。AWS KMS では、対称暗号のカスタマーマネージドキーに対して自動ローテーションを有効化でき、AWS マネージドキーは毎年自動でローテーションされます。

鍵素材（キーマテリアル、key material）とは

KMS キーの中の鍵素材（キーマテリアル、key material） とは、実際に暗号計算に使われる生の暗号鍵データそのものです。KMS キーは、見た目上は 1 つのキー ID や ARN を持つ論理的なキーですが、KMS キーはトップレベルキーマテリアルのコンテナとして説明されています。キー ID や ARN は入れ物で、その中身が鍵素材です。

以下の構成です。

• KMS キー = 管理用の箱、識別子、ポリシー、設定を持つ論理オブジェクト
• 鍵素材 = その箱の中で実際に暗号化・復号・署名・MAC 生成に使われる秘密データ

KMS コンソールで見ているキー ARN やエイリアスそのものが暗号処理しているわけではなく、その背後にある鍵素材が処理しています。

AWS KMS の制限

AWS KMS には API リクエストの制限（レートリミット）があります。一定期間に大量のリクエストを送信するとスロットリング（リクエスト拒否）が発生します。

KMS グラント（Grant）

KMS グラントとは、AWS プリンシパルが KMS キーに対して、暗号化操作（暗号化・復号・データキー生成）できる権限を与える仕組みです。特定の KMS キーに対して、特定のプリンシパルへ一時的な権限を与えます。既存のポリシーを書き換えずに使用し、不要になったら削除できるので一時的な権限付与で利用します。

STS は期限が切れれば無効になりますが KMS グラントは期限を設定できなく利用が終わったら自身で削除する必要があります。

Grant 作成直後に失敗することがある

AWS KMS API は結果整合性モデルに従います。グラントの作成時、グラントがすぐに有効にならないことがあります。変更が AWS KMS全体に適用されるまでに数秒もかかりませんが、場合によっては数分かかることがあります。その場合、リクエストはAccessDeniedExceptionエラーで失敗する可能性があります。

新しいグラントでアクセス許可をすぐに使用するには、グラントのグラントトークンを使用します。CreateGrant オペレーションによって返されるグラントトークンを保存して利用します。