AWS データ暗号化の at-rest / in-transit を整理する

監査ドキュメントで「暗号化されている」と書く前に、何が暗号化されていて、何が守れているのかを正確に説明できるか。曖昧なまま書くとあとで読み返したときに自分で意味を取り直せなくなる。整理しておく。

at-rest と in-transit

区分	何の暗号化か	守れるシナリオ
at-rest	保存時の暗号化（ディスク・スナップショット）	物理ディスクの盗難・廃棄、ストレージ機構レベルの不正アクセス
in-transit	通信時の暗号化（TLS 等）	ネットワーク経路上での盗聴・改ざん

両者は独立した概念で、片方だけ有効でも意味はある。ただし「データ暗号化」と一言で書くとどちらを指すかが曖昧になるので、必ず分けて記述する。

サービス別の at-rest / in-transit

EBS

• インスタンス起動時のボリューム作成オプションで Encrypted: true を指定するか、アカウント既定の EbsEncryptionByDefault を有効化することで at-rest 暗号化が有効になる
• どちらも未設定だとボリュームは平文で保存される
• 確認コマンド:

  aws ec2 get-ebs-encryption-by-default
  aws ec2 describe-volumes --volume-ids <id>

• in-transit は OS / アプリ層の責務（OS のディスク I/O は VPC 内ハイパーバイザ経由でホスト間転送される。AWS 公式ドキュメントでは特定インスタンスタイプ間で自動 in-transit 暗号化が掛かるケースもある）

RDS

• StorageEncrypted = true で at-rest 暗号化が有効。鍵は KMS で管理
• AWS Managed Key と Customer Managed Key (CMK) を選べる。CMK ならキーローテーション・無効化を顧客が制御可能
• in-transit は SSL/TLS パラメータグループで強制可能（rds.force_ssl = 1 等）
• 暗号化はインスタンス作成時に決まる。後から有効化はスナップショット → 暗号化コピー → リストアの手順が必要

ElastiCache (Redis)

• AtRestEncryptionEnabled と TransitEncryptionEnabled を独立して設定
• in-transit を有効にすると AUTH トークンと TLS による接続が要求される
• 一時データのみを保管していて VPC 内のセキュリティグループで通信制御している場合、暗号化なしでも運用上問題ないこともある。ただし監査文脈では「未有効」と明示する必要がある

S3

• aws_s3_bucket_server_side_encryption_configuration で SSE 方式を指定
• 2023年1月以降、AWS S3 は全バケットで SSE-S3 (AES-256) がデフォルトで自動有効。明示的に Terraform で書いていなくても at-rest 暗号化されている
• in-transit は HTTPS 通信が標準（バケットポリシーで aws:SecureTransport: true を必須化することもある）

SSE-S3 vs SSE-KMS で何が違うのか

S3 の at-rest 暗号化は方式によって意味が大きく変わる。

方式	鍵管理	監査価値
SSE-S3 (AES-256)	AWS 完全管理	2023年以降は自動有効。明示的に書く意味は限定的
SSE-KMS	顧客管理 (KMS CMK)	鍵単位アクセス制御・キー利用ログ・キーローテーション制御が可能
SSE-C	クライアント管理	クライアント側で完全制御

SSE-S3 のみで「at-rest 暗号化有効」と書くのは事実だが、それが守れるのは:

• 物理ディスクの盗難・廃棄時のデータ漏洩
• ストレージ機構レベルでの不正アクセス（hypothetical）

逆に、SSE-S3 で守れないもの:

• IAM 権限を持つユーザーからのアクセス（API 経由は透過的に復号される）
• バケットポリシー・ACL の設定ミスによる漏洩
• アプリケーション層の脆弱性経由の漏洩

つまり SSE-S3 のみだと「ディスクが盗まれても安心」レベルで、運用上の漏洩対策にはほぼ寄与しない。

SSE-KMS にすると何ができるのか

CMK を使う SSE-KMS だと以下が追加で可能になる:

1. 鍵レベルの多重防御 — IAM/Bucket Policy で許可されていても、KMS キーポリシーで弾けば復号できない
2. キー利用の CloudTrail ログ — 誰がいつどのオブジェクトを復号したか追跡できる（SSE-S3 ではこの粒度のログは取れない）
3. 顧客主導のキーローテーション・無効化 — 緊急時にキーを無効化して全オブジェクトを一時的に読めなくする運用が可能
4. クロスアカウント・きめ細かいアクセス制御 — KMS キーポリシーによる粒度の高い制御
5. コンプライアンス要件対応 — 金融・医療系の「顧客管理鍵必須」要件への対応

監査文脈で誠実に書くなら:

SSE-S3 (AWS Managed Key, AES-256) で at-rest 暗号化を有効化。顧客管理鍵 (SSE-KMS) は未使用のため、鍵単位のアクセス制御や鍵利用の CloudTrail ログ取得は実施していない。

「暗号化済み」と「鍵管理が統制されている」は別の話だと理解する。

報告書に書く前に確認すべきこと

監査ドキュメントで暗号化に言及するときのチェックリスト:

• at-rest と in-transit を分けて記述しているか
• サービスごとに状態を実機確認したか（Terraform の設定だけでなく AWS CLI で確認）
• EBS の場合、インスタンスのボリューム単位で Encrypted を確認したか（アカウント既定だけでは判断できない）
• S3 の場合、SSE-S3 か SSE-KMS かを区別して書いているか
• 「暗号化されている」と書いたとき、それが何から守っているかを説明できるか
• 不明点を「要確認」のまま書いていないか（調査して結論を書く）

実機確認なしに Terraform 設定だけで判断すると、AMI 由来の暗号化や手動設定の影響を見落とす。逆に Terraform 側に明示設定がなくてもアカウント既定で暗号化されているケースもある。両方見る。

まとめ

• 暗号化は at-rest / in-transit / 鍵管理の3軸で考える
• 「暗号化されている」だけでは何が守れているか分からない。鍵管理レベルまで踏み込んで記述する
• SSE-S3 は AWS デフォルトで自動有効。明示的に書く価値は限定的
• SSE-KMS は鍵レベル多重防御・利用ログ・キーローテーション制御で監査価値が高い
• 監査ドキュメントで「未確認」を残してはいけない。実機確認まで行って結論を書く