【基本的な暗号化技術】

• 共通鍵暗号【１つ使う】
  暗号化と復号に同じ鍵を使う、高速に暗号化、復号できる。安全な受け渡し、保管を実現。ストレージの暗号化に使用されるケースが多い。

• 公開鍵【２つ使う】
  公開鍵認証形式（非対称鍵暗号）
  鍵を持っている人からのみ、一般ユーザーのログインを許可する。 公開鍵と秘密鍵のキーペア。
  
  ・秘密鍵ファイル：パソコン側に置く
  ・公開鍵ファイル：サーバー側に配置する
  
  公開鍵で暗号化したデータは秘密鍵で復号できる。
  共通鍵暗号と比べて、複雑で処理は重い(CPU能力を使う)暗号化に加えて、デジタル署名やデジタル証明書に使われる技術。
  
  ※受信者は鍵のペアを予め作っておき、公開鍵を送信者に渡しておく
  ※公開鍵認証ではログイン時に「パスフレーズ」を使用する

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

KMS(Key Management Service)【鍵管理サービス】

データ暗号化に利用する暗号化（または復号化）できるKMSキーの作成・管理を行うためのAWSのマネージドサービス。AWS所有のマルチテナント管理を共有で利用し、耐久性が高く、高可用性である。

• 鍵の保管：KMSキーを安全に保管するストレージ（安全なロケーションの提供）
• 鍵の管理：KMSキーのライフサイクル管理、及び鍵の管理や利用に対する認証・認可・記録するアクセス制御
  [参考]

・他のAWSと連携しやすい(S3サーバー、オブジェクト側の暗号化など)(連携するAWSサービス：50以上)

・CloudHSMに比べると安価に利用でき、手軽に暗号化キーを管理

・キーの使用・管理の監査証跡として、有効

【CloudTrailとの統合】

・KMSで内ユーザーやロール、またはAWSのサービスによってじっこうされたアクションを記録。

・KMSコンソールからのコールやKMS APIへのコード呼び出しを含むKMSのすべてのAPI呼び出しをイベントとしてキャプチャし、証跡を作成。
（リクエスト作成元のIPアドレス、リクエストの実行者・実行日など、）

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

〇鍵の種類

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

• KMSキー（CMK３種類）
  データの暗号化、復号、再暗号化を行い、外部が使用するデータキーを作成する。
  キーストアに厳重に格納される。KMS キーには、キー ID、キー仕様、キー使用法、作成日、説明、およびキーステータスなどのメタデータが含まれる。
  
  
  ●カスタマーマネージドキー（別名：カスタマーマスターキー）
  ユーザーが作成するKMSキー。データーキーを暗号化するための鍵。
  削除した直後であれば、削除のキャンセルができる。
  
  ●AWSマネージドキー
  AWSがユーザーのAWSアカウントで作成するキー。AWSサービスが作成・管理・使用するCMK。
  キーの名前は「aws/サービス名」。このため、名前の先頭に「aws」を付けられない。
  
  3年ごとに自動ローテーション。
  
  ●AWSが所有するキー
  AWSがユーザーのサービスアカウントで作成するキー。ユーザーからは見えない。
  

〇暗号化（エンベロープ暗号化）

AWS KMS はセキュアで弾力性の高いサービス。データーキー、マスターキーを用いる。
暗号化や復号の際にはKMS（またはCloudHSM）に鍵の使用リクエストAPIを送信し、データキーを一時的に復号化して暗号化、復号する。

【暗号化機能】

●Encrypt：文字通りデータを暗号化するためのAPI(4KBまでの平文字に対応)
●Decrypt：復号のためのAPI
●GenerateDataKey：ユーザーがデーターの暗号化に利用するための、カスタマーキーを作成する

[参考]

【暗号化の流れ】

1. アプリケーションから AWS SDK の GenerateDataKey オペレーション（キーID）を使って CDK を生成。
   
2. 作成されたCDKをCMKで暗号化する。CMKはデータキーを２つ作成する。
   ※認識が混ざるためＣＤＫという単語は不使用
   
   ●データーキー：「A」とする
   ●暗号化されたデーターキー：暗号化された「Ａ」とする
   
   
3. ユーザーは工程「2.」で作成された、「A」で暗号化したいデータを暗号化する。
   後に、「A」は削除して、暗号化された「Ａ」を手元に残す。

【復号化の流れ】

1. 暗号化された「A」をKMSに送る。
2. CMKが暗号化された「A」と「A」を結果として返す。
3. ユーザーは結果として返された「A」でデータを復号化。不要であれば「A」は削除。

【独自のキーマテリアルの場合】

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

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

〇キーの管理

【自動キーローテーション】

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

・古いキーマテリアルがすべて永続的に保存する。削除されない限り、KMS キーで暗号化されたすべてのデータを復号できる。

・サポートするのは、AWS KMS が作成するキーマテリアルを持つ対称暗号化 KMS キーのみ。（インポートしたCMKは対応不可）

・KMS キーのキーマテリアルに関するローテーションの追跡は、Amazon CloudWatch とAWS CloudTrail で実行できる。

• KMS GenerateDataKey
  アプリケーションでデータをローカルで暗号化することができる。一意の対象データキーを生成する。データキーのプレーンテキストコピーと、指定したCMKで暗号化されたコピーを返す。プレーンテキストキーを使用して、KMSの外部でデータを暗号化し、暗号化されたデータと主に暗号化されたデータキーを保存できる。
  
• マルチリージョンキー
  複数のリージョンで同じように KMS Key を相互使用ができる。
  関連するマルチリージョンキーセットごとに、同じキーマテリアルおよびキーIDを持つ複数の関連するマルチリージョンキーとなる。
  ・キーは個別に管理、独立して使用、連携させて使用することもできる。

AWS CloudHSM（Hardware Security Module）

ハードウェアセキュリティモジュール（HSM）を使用した暗号鍵管理サービス。KMSに比べると高価。
※HSMインフラの管理責任：ユーザー⇒AWS クラウドで暗号化キーを簡単に生成して使用できる

・HSMのFIPS認定 ：FIPS140-2 Level 3(3認証済み)

【他サービスとの連携】
・KMS経由でAWSサービスと連携可能。
・異なるリージョンからCloudHSMにアクセス出来ない
・バックアップイメージを異なるリージョンに転送してサービスをリストアすることは可能。
・VPC外からアクセスする場合には、CloudHSMがあるVPCにルーティングする必要がある

〇サポートする暗号鍵

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

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

〇オフロード機能

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

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

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

Secrets Manager
【認証情報管理】

データベース認証情報、アプリケーション認証情報、OAuth トークン、API キー、およびその他のシークレットを安全に暗号化し、アクセス管理情報を一元的に監査する。

それらシークレット情報を、Secrets ManagerへのAPIコールに置き換えて取得できる。
各サーバからAPIを叩くことでシークレット情報を取得でき、認証やサーバセットアップに利用できる。（アプリケーションにシークレット情報を保存する必要がなくなる）

AWS のサービスの多くは、Secrets Manager にシークレットを保存して使用される。
※アプリケーションにシークレット情報を保存する必要がなくなる。

・ライフサイクルを通じて「管理」、「取得」、「ローテーション」することができる。

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

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

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

〇リソースタイプ

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

• AWS::SecretsManager::Secret
  シークレットを作成し、SecretManagerに保存する。パスワードはユーザーが指定するかSecretManagerに生成させることが可能。

• AWS::SecretsManager::ResourcePolicy
  リソースベースのポリシーを作成し、指定されたシークレットにアタッチする。リソースベースのポリシーは、シークレットに対してアクションを実行できるユーザーを制御する

• AWS::SecretsManager::RationSchedule
  指定したLambdaローテーション関数を使用して、定期的な自動ローテーションを実行するようにシークレットを設定する。

• AWS::SecretsManager::SecretTargetAttachment
  シークレットを作成後、サービスまたはデータベースの作成時にそれを参照して認証情報にアクセスすると、このリソースタイプはシークレットに戻ってその設定を完了させる。SecretsManagerはローテーションが機能するために必要なサービス、データベースの詳細をシークレットに設定する。