S3 暗号化が SSE-S3 のみで SSE-KMS 未使用だと、何が『できていない』のか

監査ドキュメントに「S3 は SSE-S3 で at-rest 暗号化されています」と書く。それは事実として正しいが、「SSE-KMS は未使用」という事実が同時に意味する できていないこと を説明できないと、報告書として不十分だ。

「暗号化済み」と「鍵管理が統制されている」は別物。ここを言語化しておく。

前提：S3 の at-rest 暗号化方式

方式	鍵管理	デフォルト
SSE-S3	AWS 完全管理 (AES-256)	2023年1月以降、全バケット自動有効
SSE-KMS	顧客管理 (KMS Customer Managed Key)	明示設定が必要
SSE-C	クライアント側で鍵を管理	クライアント側完全制御
DSSE-KMS	KMS 二重暗号化	規制要件向けの強化版

「SSE-S3 のみ運用」とは、暗号化はされているが、鍵に対して顧客側が触れる手段が一切ない状態を指す。

SSE-S3 で守れているもの・守れていないもの

SSE-S3 で守れるのは限られる:

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

SSE-S3 で守れないもの:

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

つまり、運用上の漏洩シナリオに対してはほぼ寄与しない。「ディスクが盗まれても大丈夫」レベルの保証しか提供していない。

SSE-KMS 未使用で『できていない』こと

監査文脈で書くべきなのは、SSE-KMS を使うと得られる以下の統制が すべて欠けている という事実。

1. 鍵レベルの多重防御（kms:Decrypt の独立した関門）

SSE-S3 では、IAM/Bucket Policy で s3:GetObject を許可された主体は 無条件で復号できる。鍵側のチェックが存在しない。

SSE-KMS の場合、s3:GetObject だけでは足りず、KMS キーポリシーでも kms:Decrypt が許可されている必要がある。

[SSE-S3]
  s3:GetObject 許可 → 復号成功

[SSE-KMS]
  s3:GetObject 許可 AND kms:Decrypt 許可 → 復号成功
  s3:GetObject 許可 AND kms:Decrypt 拒否 → 復号失敗

これにより、IAM 設定ミスで s3:GetObject が広めに付与されてしまっても、KMS キーポリシー側で実質的な復号権限を絞れる。多層化された認可境界を構成できないのが SSE-S3 のみの運用。

2. 鍵利用の CloudTrail ログ（誰がいつ何を復号したか）

SSE-S3 では、s3:GetObject の API ログは取れるが、復号イベント自体のログは存在しない。AWS が裏側で透過的に復号しているため、鍵利用の粒度では追えない。

SSE-KMS なら CloudTrail に Decrypt イベントが記録される:

• どのプリンシパルが
• いつ
• どの KMS キーで
• どのリソース（暗号化コンテキスト経由でオブジェクト特定可能）を

復号したかが追跡できる。

監査・インシデント対応で「あのオブジェクトは過去 90 日に誰が読んだか」を答える必要がある場合、SSE-S3 のみだとこの問いに答えられない。

3. 顧客主導のキーローテーション・無効化

SSE-S3 の鍵ローテーションは AWS 側で透過的に実施されるが、顧客側からは制御できない。

SSE-KMS の Customer Managed Key (CMK) なら:

• 自動年次ローテーションの有効/無効を顧客が選べる
• 手動ローテーションを任意のタイミングで発動できる
• 緊急時にキーを無効化（DisableKey）して、全関連オブジェクトを一時的に読めなくする運用が可能

最後の点は事故対応で重要で、漏洩疑いがあるバケットに対して鍵レベルで一斉に「読めなくする」操作ができるかどうかは、即応力に直結する。

4. クロスアカウント・きめ細かいアクセス制御

SSE-KMS のキーポリシーは IAM とは独立した認可レイヤなので、クロスアカウント共有時に「アカウント A のロールには許可、アカウント B のロールには拒否」という鍵単位の制御が組める。

SSE-S3 にはこのレイヤが存在しない。バケットポリシーと IAM だけで全部表現する必要がある。

5. コンプライアンス要件への対応

金融・医療系の規制で「顧客管理鍵での暗号化」が要件化されているケースがある。SSE-S3 はクラウド事業者の管理鍵なので、この要件を満たせない。SOC2 / ISO27001 の鍵管理統制セクション、PCI-DSS の鍵管理要件等で問われる。

監査ドキュメントの書き方

「未使用」を書くときは、それが何を意味するかまで踏み込む。

悪い例:

S3 は AES-256 で暗号化済み。

→ 何が守れているか不明。SSE-S3 か SSE-KMS かも不明。

普通の例:

S3 は SSE-S3（AES-256, AWS Managed Key）で at-rest 暗号化を有効化。SSE-KMS は未使用。

→ 事実は正しいが、「SSE-KMS 未使用」が何を意味するか読み手が判断する必要がある。

良い例:

S3 は SSE-S3（AES-256, AWS Managed Key）で at-rest 暗号化を有効化。Customer Managed Key (SSE-KMS) は未使用のため、以下の統制は実施していない:

• 鍵単位のアクセス制御（IAM/Bucket Policy 以外の認可境界）
• CloudTrail での鍵利用ログ取得（誰がどのオブジェクトを復号したかの追跡）
• 顧客主導のキーローテーション・キー無効化（緊急時の鍵単位封鎖）

物理ディスク盗難・廃棄時のデータ保護は SSE-S3 で確保されている。運用面の漏洩対策は IAM ポリシー・バケットポリシーで実装。

→ 事実 + ギャップ + 何で代替しているか、まで明記。これで監査側が「鍵管理レベルで何があって何がないか」を判断できる。

SSE-KMS 採用判断のポイント

SSE-KMS への移行を検討するときの観点:

観点	SSE-S3 で十分	SSE-KMS が必要
データの機密度	公開予定/低機密	個人情報・金融情報
監査要件	内部のみ	外部監査・規制対応
インシデント対応	IAM レベルで十分	鍵単位で封鎖したい
クロスアカウント	単一アカウント	複数アカウント共有
復号ログ要件	API ログで足りる	鍵利用粒度で追跡

KMS には費用が発生する点（リクエスト課金）と、KMS 障害時に S3 操作も巻き込まれる点はトレードオフとして考慮する。

まとめ

• SSE-S3 のみの運用は「暗号化されている」が「鍵管理は統制されていない」状態
• SSE-S3 で守れるのは物理層レベルの脅威のみ。運用面の漏洩には寄与しない
• SSE-KMS 未使用 = 鍵レベル多重防御・鍵利用ログ・顧客主導キーローテーション・クロスアカウント鍵制御・コンプライアンス対応がすべて欠落
• 監査ドキュメントでは「SSE-KMS 未使用」だけでなく、それが意味する できていない統制 まで明記する
• SSE-KMS への移行判断は、機密度・監査要件・インシデント対応の必要性で決める