【基本的な暗号化技術】

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

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

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

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

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

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

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

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

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

【CloudTrailとの統合】

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

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

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

〇鍵の種類

[情報を展開する]

マスターキー	データーキー
・データキーを暗号化する ・AWS内部で永続化される ・ユーザーがローカルにエクスポートできない	・データを暗号化する ・AWS内部で永続化されない ・ユーザーがローカルにエクスポートできる

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

カスタマーマネージドキー (カスタマーマスターキー)	ユーザーが作成するKMSキー。データーキーを暗号化するための鍵。削除した直後であれば、削除のキャンセルができる。
AWSマネージドキー	AWSがユーザーのAWSアカウントで作成するキー。AWSサービスが作成・管理・使用するCMK。 キーの名前は「aws/サービス名」。このため、名前の先頭に「aws」を付けられない。 3年ごとに自動ローテーション。
AWSが所有するキー	AWSがユーザーのサービスアカウントで作成するキー。ユーザーからは見えない。

【データーキー】
●CDK(Customer Data Key)
対象のデーターを暗号化するための鍵（データキー）。

※公式の資料ではCDKという言葉はほとんど使われていない
[使われている関連記事]

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

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があるため、1つのAWSリージョンでデータを暗号化し、再暗号化やAWS KMS へのクロスリージョン呼び出しを行うことなく異なる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 にシークレットを保存して使用される。
※アプリケーションにシークレット情報を保存する必要がなくなる。

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

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

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

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

〇リソースタイプ

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

AWS::SecretsManager::Secret	シークレットを作成し、Secrets Manager に保存。パスワードは、ユーザーが指定するか、Secrets Manager に生成できる。空のシークレットを作成し、後でパラメータ SecretString を更新もできる。
AWS::SecretsManager::ResourcePolicy	リソースベースのポリシーを作成し、指定されたシークレットにアタッチ。リソースベースのポリシーは、シークレットに対してアクションを実行できるユーザーを制御する。
AWS::SecretsManager::RotationSchedule	指定した Lambda ローテーション関数を使用して、定期的な自動ローテーションを実行するようにシークレットを設定する。
AWS::SecretsManager::SecretTargetAttachment	シークレットを作成後、サービスまたはデータベースの作成時にそれを参照して認証情報にアクセスすると、このリソースタイプはシークレットに戻ってその設定を完了する。Secrets Manager は、ローテーションが機能するために必要なサービスまたはデータベースの詳細をシークレットに設定する。

S3 の暗号化

デフォルトで暗号化が有効化。HTTPSを使用してデータをS3にプッシュして転送中に暗号化できる。

※転送時：S3との間でデータを送受信するとき。
※保管時：S3データセンター内のディスクに格納されている時。

・HTTP 503 レスポンスとは「サービスが利用できない」ときに表示されるエラー
・Secure File Transfer Protocol (SFTP) を使用して ファイルを直接転送することができる

【暗号化する場所】

• クライアント側
  クライアント側でデータを暗号化し、暗号化したデータをS3にアップロードする。
  この場合、暗号化プロセス、暗号化キー、関連ツールはユーザ管理。

• サーバー側
  送信先で暗号化を実施する方法。暗号化キーによって管理方法が変わる。
  オブジェクトをデータセンター内のディスクに保存する前にオブジェクトレベルで暗号化。アクセスするときに復号するようにS3にリクエストする。

【比較表】

「AWS S3でサーバー側暗号化をしたい」というニーズに応えつつ、セキュリティ運用の方針に合わせて選べるようになっている。

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

たとえば、

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

観点	SSE-S3	SSE-KMS	SSE-C	クライアント側暗号化
🔑 キー管理	AWSが自動的に管理（AES-256）	AWS KMSで管理されたキー	顧客が自分で管理・提供	顧客がローカルで暗号化・管理
🧠 利便性	高い：設定だけで利用可能	高め：KMS連携の設定が必要	低め：毎回キー提供が必要	低め：全て手動で管理する必要あり
📜 監査・制御	CloudTrail対象外	CloudTrail対応・IAM制御可能	CloudTrail対象外・制御困難	自前で監査ログを準備する必要あり
💰 コスト	無料	KMS利用料が発生	無料（但し運用負荷高）	暗号化ツールの導入コストあり
🛡️ セキュリティ水準	基本的な保護（AES-256）	より強力・柔軟な制御	顧客が鍵を持つため強力	最も厳密な管理が可能（自己責任）
🏢 代表用途	一般的な暗号化要件を満たす用途	企業・監査向け用途	金融・法務など高セキュリティ用途	機密性重視の組織や独自運用環境

SSE-S3 S3で管理された 暗号化キー	S3が暗号化キーの生成・管理・保管を行う。そのため、暗号化キーの変更、管理を行えない。 ・各オブジェクトは、強力な多要素暗号化機能を備えた一意のキーで暗号化される。 ・キー自体が定期的に更新されるマスターキーによって暗号化される。 ・256ビットの高度暗号化規格(AES-256)を使用してデータを暗号化。
SSE-KMS KMSで管理された 暗号化キー	AWS KMSが暗号化キーの生成・管理・保管を行う。追加の料金がかかる。 ・任意のキーを用いて暗号化できる ・キー自体へのアクセス制御によって、暗号化・復号化できるユーザーを制御できる ・いつ、だれによってキーが使用されたか、ClouodTrailから監査証跡が提供される。 ・エンベロープキー(データの暗号化を保護するキー)オブジェクトの不正アクセスに対する追加の保護を提供する。
SSE-C ユーザー側で用意した暗号化キー	ユーザー自身が暗号化キーの生成・管理・保管を行う。S3に送信する前にデータが暗号化される。 ・どのキーでどのオブジェクトが暗号化されたのかという情報は自分自身で管理。 ・暗号化・復号化に伴う料金は発生しない ・任意のキーを用いて暗号化することができる ・AES-256暗号化タイプを使用 ・HTTPSだけサポートしている ・キーの管理全般はユーザーであるため、セキュリティ面が弱い。

【必要な準備】

各API呼び出しで以下の情報を指定する必要がある。
・暗号化アルゴリズムの指定