暗号化（KMS / CloudHSM / Secrets Manager / ACM）

このページで押さえる論点

• 保管中と転送中の暗号化、サーバー側とクライアント側の暗号化
• AWS KMS（キーの種類・キーポリシー・エンベロープ暗号化・ローテーション・削除・マルチリージョンキー）
• S3・EBS・RDS の暗号化の選択肢（SSE-S3・SSE-KMS・SSE-C など）
• AWS CloudHSM（専用の HSM が必要なとき）
• Secrets Manager と Parameter Store（秘密情報の保管とローテーション）
• ACM（証明書の発行・自動更新・リージョンの注意点）
• どのサービスを選ぶか（選択フロー）

保管中と転送中の暗号化

暗号化は、データを鍵がないと読めない形に変えることです。守る場面によって 2 つに分けます。

保管中の暗号化には、AWS のサービス側で暗号化するサーバー側の暗号化と、アプリがデータを暗号化してから AWS に送るクライアント側の暗号化があります。「AWS に届く前に暗号化しておく」「AWS 側では平文を一切扱わせない」という要件ならクライアント側の暗号化を選びます。

暗号化の責任は 責任共有モデル（AWS と利用者の責任の分担）で利用者側にあります。どのデータを暗号化するか、鍵を誰に使わせるかは利用者が決めます。

AWS KMS

AWS KMS（Key Management Service）は、暗号鍵を作って保管し、使える人を管理するマネージドサービスです。KMS の鍵（KMS キー）は、AWS が管理する HSM（ハードウェアセキュリティモジュール = 鍵を安全に保管・計算する専用の機器）の中にあり、平文のまま外へ持ち出せません。すべての利用は CloudTrail に記録されるので、「いつ誰が鍵を使ったか」を監査できます。

キーの種類

キーポリシー

KMS キーには必ずキーポリシー（リソースベースポリシーの一種）が付きます。キーを使えるかどうかは、まずキーポリシーで決まります。キーポリシーでアカウントに権限を委ねている場合に限り、IAM ポリシーでも使える人を追加できます。キーを管理する人（削除や設定変更ができる）とキーを使う人（暗号化・復号ができる）を分けて書けるので、「管理者でもデータは復号できない」といった職務分離ができます。別アカウントに使わせるときは、キーポリシーで相手のアカウントを許可し、相手側でも IAM ポリシーで許可します（両側での許可）。

エンベロープ暗号化

KMS の Encrypt API に直接渡せるデータは、対称キーで最大 4,096 バイト（4 KB）までです。大きなデータはエンベロープ暗号化で暗号化します。KMS キーからデータキー（実際にデータを暗号化する使い捨ての鍵）を発行してもらい、データキーでデータを暗号化し、データキー自体は KMS キーで暗号化して一緒に保存します。S3 や EBS の暗号化も裏側ではこの仕組みです。

ローテーション・削除・マルチリージョンキー

S3・EBS・RDS の暗号化の選択肢

S3 のサーバー側の暗号化は、鍵の管理方法で次のように分かれます。現在は、すべての新しいオブジェクトが既定で SSE-S3 で暗号化されます。

SSE-KMS はオブジェクトの読み書きのたびに KMS を呼ぶため、大量のリクエストがあると KMS の API のリクエスト数の上限（クォータ）や料金が問題になります。S3 バケットキーを有効にすると、KMS への呼び出しを減らせます。

EBS と RDS は、ボリュームや DB インスタンスを作るときに KMS キーで暗号化します。暗号化されていない既存の RDS インスタンスや EBS ボリュームは、後から暗号化を有効にできません。スナップショットを作り、暗号化を指定してスナップショットをコピーし、そこから復元します。暗号化されたスナップショットを別のリージョンにコピーするときは、コピー先のリージョンの KMS キーを指定します。

AWS CloudHSM

AWS CloudHSM は、利用者専用（シングルテナント）の HSM を AWS 上で使えるサービスです。FIPS 140-2 レベル 3 または FIPS 140-3 レベル 3 の検証を受けた機器で、鍵は利用者だけが管理し、AWS からは見えません。

問題文に「シングルテナント」「専用のハードウェア」「FIPS 140 レベル 3」「鍵を AWS に管理させない」とあれば CloudHSM を選びます。それ以外の一般的な暗号化は KMS が第一候補です。

Secrets Manager と Parameter Store

DB のパスワードや外部サービスの API キーを、アプリのコードや設定ファイルに直接書くと、ソースコードの共有や流出で漏れてしまいます。そこで秘密情報は専用のサービスに保管し、アプリは実行時に API で取り出します。

「パスワードを定期的に自動で変更したい」なら Secrets Manager、「ローテーションは不要で、設定値を低コストで一元管理したい」なら Parameter Store です。EC2 や Lambda からは、IAM ロールで取り出す権限を渡します。

ACM（AWS Certificate Manager）

ACM は、HTTPS 通信に使う SSL/TLS 証明書（Web サイトの身分証明書）を発行・管理するサービスです。ACM が発行するパブリック証明書は、ELB・CloudFront・API Gateway などの統合されたサービスに付けると、期限が切れる前に自動で更新されます。証明書を発行するときは、ドメインを持っていることを DNS（Route 53 などにレコードを追加）かメールで確認します。DNS で確認しておくと、更新も自動で進みます。

• リージョンの注意点: 証明書はリージョンごとのリソースです。ALB などに付ける証明書は、そのロードバランサーと同じリージョンで発行します。CloudFront に付ける証明書は、米国東部（バージニア北部）リージョン（us-east-1）で発行（またはインポート）する必要があります。
• インポートした証明書: 他の認証局で取得した証明書も ACM にインポートできますが、自動更新はされません。期限の管理は利用者が行います。
• TLS の終端: ALB に証明書を付けると、ALB で HTTPS を復号（TLS 終端）し、背後の EC2 の負荷を減らせます。背後まで暗号化が必要なら、ALB からターゲットへの通信も HTTPS にします。

どのサービスを選ぶか

ここまでのサービスを、「何を守りたいか」から選べるように整理します。

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「AWS マネージドキーのキーポリシーを編集して、別アカウントに使わせる」→ ✕。AWS マネージドキーのキーポリシーは変更できない。共有するならカスタマーマネージドキー
• 「KMS キーをすぐ削除できる」→ ✕。7〜30 日の待機期間がある。削除すると暗号化したデータは復号できなくなる
• 「既存の暗号化されていない RDS インスタンスで、設定から暗号化を有効にする」→ ✕。スナップショットを暗号化してコピーし、復元する
• 「CloudFront 用の証明書を、オリジンと同じ東京リージョンで発行する」→ ✕。CloudFront は us-east-1 の証明書を使う
• 「Parameter Store でパスワードの自動ローテーション」→ ✕。自動ローテーションは Secrets Manager
• 「インポートした証明書も ACM が自動更新する」→ ✕。自動更新されるのは ACM が発行した証明書
• 「CloudHSM を使えば S3 の暗号化にそのまま使える」→ ✕。AWS サービスと統合するには KMS のカスタムキーストアを経由する

まとめ: SAA 試験で押さえるポイント

• 保管中の暗号化は KMS、転送中の暗号化は TLS（ACM の証明書）が基本
• KMS キーはキーポリシーで使える人を決める。細かい制御・共有・監査が必要ならカスタマーマネージドキー
• 大きなデータはエンベロープ暗号化（データキーで暗号化し、データキーを KMS キーで暗号化）。KMS キー自体は外に出ない
• KMS キーの削除は 7〜30 日の待機期間つき。自動ローテーションの既定は 365 日
• 専用 HSM・FIPS 140 レベル 3 が必要なら CloudHSM
• 秘密情報の自動ローテーションは Secrets Manager、ローテーション不要の設定値は Parameter Store
• ACM の証明書は統合サービスで自動更新。CloudFront 用は us-east-1