セキュアなソリューション設計において、データ暗号化は「保管時（at rest）」と「転送時（in transit）」の2つの軸で考える必要があります。本記事ではその実践的な選択肢を解説します。

SAA レベル：基礎概念

保管時暗号化の基本

ほとんどのAWSストレージサービス（S3、EBS、RDS等）は、KMSと統合した保管時暗号化をサポート
多くのサービスで、作成時に暗号化を有効化するだけで、透過的にデータが暗号化される

転送時暗号化の基本

TLS/SSLを使い、クライアントとAWSサービス間の通信を暗号化する
AWS内部のサービス間通信の多くも、デフォルトでTLSが使用される

SAA 試験のポイント

S3などのAWSサービスへのAPIアクセスは、HTTPSエンドポイントを使う限り自動的にTLSで保護されます。「転送時暗号化のために追加の設定が必要」という誤解に注意しましょう（ただし、バケットポリシーでaws:SecureTransport条件によりHTTP接続自体を明示的に拒否する設計は推奨されます）。

SAP レベル：高度な設計シナリオ

S3における3種類の保管時暗号化の違い

SAP 試験のポイント

S3の保管時暗号化には主に3種類あり、鍵の管理主体が異なります。SSE-S3はAWSが完全に管理し利用者は鍵を意識しません。SSE-KMSはKMSのカスタマーマネージドキーを使い、詳細なアクセス制御・監査ログを取得できます。SSE-Cは利用者が鍵そのものを管理し、リクエストごとに鍵を提供する必要があります。

種類	鍵の管理	監査ログ（CloudTrail）	主な用途
SSE-S3	AWSが完全管理	記録されない	特別な鍵管理要件がない場合
SSE-KMS	KMSカスタマーマネージドキー	詳細に記録される	鍵へのアクセス監査・クロスアカウント制御が必要な場合
SSE-C	利用者が管理・提供	AWSは鍵を保持しない	規制上、AWSに鍵を一切預けられない場合

設計上の落とし穴

「コンプライアンス要件があるので、常にSSE-KMSを使うべき」という判断は、コストとパフォーマンスの観点で過剰な場合があります。SSE-KMSはKMSへのAPI呼び出しが発生するため、大量の小さいオブジェクトへの高頻度アクセスではコストとレイテンシが増加します。監査ログや詳細なアクセス制御が本当に必要かどうかを要件から判断することがSAPで問われます。

クライアントサイド暗号化

SAP 試験のポイント

サーバーサイド暗号化（AWSのサービス側でデータを暗号化）では、AWS側が一時的に平文データを扱う瞬間が存在します。極めて厳格なゼロトラスト要件（AWSにすら平文データを一切見せたくない）がある場合は、クライアントサイド暗号化を採用し、アプリケーション側でデータを暗号化してからAWSにアップロードする設計が必要です。AWS Encryption SDKやS3 Encryption Clientといったツールが提供されています。

鍵ローテーションの設計

KMSカスタマーマネージドキーの自動ローテーション（年1回）は、キーマテリアルのみが更新され、キーID・ARNは変わらないため、アプリケーション側の変更は不要
より短い周期でのローテーションや、鍵の完全な入れ替え（新しい鍵での再暗号化）が必要な場合は、手動でのローテーション運用を設計する必要がある

転送時暗号化の強制

S3バケットポリシーでaws:SecureTransport: falseの場合に明示的にDenyすることで、HTTP経由のアクセスを完全にブロックできる
ALBではHTTPリスナーからHTTPSリスナーへのリダイレクトルールを設定し、暗号化されていない通信を排除する設計が一般的

まとめ

SAA: 保管時・転送時暗号化の基本概念、多くのAWSサービスでTLSがデフォルトで使われることを理解する。
SAP: SSE-S3/KMS/Cの鍵管理主体の違いとコスト・監査のトレードオフ、クライアントサイド暗号化が必要な場面、鍵ローテーション設計ができる。

次は Secrets Manager／Systems Manager Parameter Storeを見ていきましょう。