共通鍵を公開鍵で暗号化し、復号は秘密鍵。実際の通信は共通鍵暗号で暗号化/復号を行う。
安全性とパフォーマンスの両立を実現。

独自のキーマテリアルをインポートするには、最初にキーマテリアルなしで KMS キーを作成。そして、独自のキーマテリアルをインポート。キーマテリアルなしで KMS キーを作成するには、AWS KMS コンソールまたは CreateKey オペレーションを使用する。キーマテリアルなしでキーを作成するには、オリジンとして EXTERNAL を指定。

• キーマテリアル
  CMKのメタデータを除く暗号・復号に利用する部分。

[マスターキーの種類]

●KMSキー（CMK３種類）

データの暗号化、復号、再暗号化を行い、外部が使用するデータキーを作成する。キーストアに厳重に格納される。KMS キーには、キー ID、キー仕様、キー使用法、作成日、説明、およびキーステータスなどのメタデータが含まれる。

[データーキー]

●CDK(Customer Data Key)

対象のデーターを暗号化するための鍵（データキー）。
※公式の資料ではCDKという言葉はほとんど使われていない
[使われている関連記事]

●KMS Generate Data Key

アプリケーションでデータをローカルで暗号化することができる。一意の対象データキーを生成する。データキーのプレーンテキストコピーと、指定したCMKで暗号化されたコピーを返す。プレーンテキストキーを使用して、KMSの外部でデータを暗号化し、暗号化されたデータと主に暗号化されたデータキーを保存できる。

●マルチリージョンキー

複数のリージョンで同じように KMS Key を相互使用ができる。関連するマルチリージョンキーセットごとに、同じキーマテリアルおよびキーIDがあるため、1つのAWSリージョンでデータを暗号化し、再暗号化やAWS KMS へのクロスリージョン呼び出しを行うことなく異なるAWS リージョンで復号できる。
・キーは個別に管理、独立して使用、連携させて使用することもできる。

[自動キーローテーション]
KMSで生成した各キーマテリアル（ベース）を年次(1年)で更新する。エイリアス、Key ID、Key ARNは新キーに引き継がれる。

・古いキーマテリアルがすべて永続的に保存する。削除されない限り、KMS キーで暗号化されたすべてのデータを復号できる。
・サポートするのは、AWS KMS が作成するキーマテリアルを持つ対称暗号化 KMS キーのみ。（インポートしたCMKは対応不可）
・KMS キーのキーマテリアルに関するローテーションの追跡は、Amazon CloudWatch とAWS CloudTrail で実行できる。

[CloudTrailとの統合]
・KMSで内ユーザーやロール、またはAWSのサービスによってじっこうされたアクションを記録。
・KMSコンソールからのコールやKMS APIへのコード呼び出しを含むKMSのすべてのAPI呼び出しをイベントとしてキャプチャし、証跡を作成。
（リクエスト作成元のIPアドレス、リクエストの実行者・実行日など、）

・すべてのキーの使用ログを表示できるため、規制およびコンプライアンスの要求に応えるために役立つ

共通鍵と公開鍵。占有タイプ(Amazonの管理者もアクセスできない)のハードウェアで暗号化キーを保管(不正防止機能を装備したハードウェアデバイス内でキーを操作)

・物理デバイス制御とキーへのアクセスを持たないアプリケーションで秘密鍵を強力に保護できる。そのため、キーがAWS環境の外に移動されない。

CloudHSM クラスターの HSM に対するHTTPS同様の計算の一部をオフロードできる。ウェブサーバーの計算負荷が軽減され、サーバーのプライベートキーを HSM に保存するとセキュリティが強化される。このプロセスは、SSL アクセラレーションとも呼ぶ。

・ウェブサーバーとそのクライアント (ウェブブラウザ) では、SSL または TLS を使用できる。

※一般的に HTTPS として知られており、パブリック/プライベートのキーペアと SSL/TLS パブリックキー証明書を使用して、各クライアントとのHTTPS セッションを確立するため、このプロセスは、ウェブサーバーにとって多くの計算を伴う。

パスワード、ユーザーネーム、APIトークン、データベース認証、パスワードなどの一連の認証情報、OAuth トークン、または、暗号化された形式。
[参考サイト]

[アクセス]
・きめ細かい IAM とリソースベースのポリシーを使用して、シークレットへのアクセスを管理する。
・各シークレット情報は各サーバーからAPIを叩くことでシークレット情報を取得でき、認証やサーバセットアップに利用できる
・シークレットはデフォルトで KMS によって暗号化されるが、この暗号化キーの管理はAWSが行う。

[シークレットのローテーション]
(Rotation Schedule リソース)
暗号化された安全なストレージを提供され、シークレット、データベースまたはサービスの認証情報が更新する。定期的なキーローテーションスケジュールを設定できる。
※長期のシークレットを短期のシークレットに置き換えることが可能となり、侵害されるリスクを大幅に減少させることができる。

以下の2つの方式がある。

• マネージドローテーション
  ・ほとんどのマネージドシークレットで利用される。
  ・サービス側がローテーションを設定・管理するため、Lambda関数は不要。
• Lambda関数によるローテーション
  ・その他のタイプのシークレットで使用される。
  ・ユーザーが用意したLambda関数を使って、シークレットと関連サービス（データベースなど）の認証情報を更新する。

Secrets ManagerにはCloudFormationテンプレートの一部として作成できるリソースタイプが複数ある。

• クライアント側
  クライアント側でデータを暗号化し、暗号化したデータをS3にアップロードする。
  この場合、暗号化プロセス、暗号化キー、関連ツールはユーザ管理。
  
• サーバー側
  送信先で暗号化を実施する方法。暗号化キーによって管理方法が変わる。
  オブジェクトをデータセンター内のディスクに保存する前にオブジェクトレベルで暗号化。アクセスするときに復号するようにS3にリクエストする。

「AWS S3でサーバー側暗号化をしたい」というニーズに応えつつ、セキュリティ運用の方針に合わせて選べるようになっている。「AWSにキー管理を任せて利便性やセキュリティレベルを高めたい企業」はSSE-KMS。
「AWSにキーを預けたくない」「極限まで自分で管理したい」というセキュリティポリシーが厳格な組織やプロジェクトではSSE-C。一番簡単に使える暗号化方式で、「保存時に暗号化されればOK」という基本的なセキュリティ要件にはSSE-S3。クライアント側暗号化はAWS外で処理を完結したい場合に有効。

たとえば、

• 金融や医療分野などで「クラウドでも鍵は一切預けない」といった方針があるならSSE-C。
• 監査対応やIAM連携を重視する企業であればSSE-KMS。