Amazon S3の暗号化ガイド｜SSE-S3・SSE-KMS・SSE-Cの違いと選び方

Amazon S3に保存するデータの暗号化は、クラウドセキュリティの基本です。「S3の暗号化って具体的に何をすればいいのか」「SSE-S3とSSE-KMSの違いは何か」——こうした疑問を持つエンジニアの方は多いのではないでしょうか。

本記事では、S3のサーバーサイド暗号化の3つの方式を比較しながら、設定方法と選定基準を実務の視点から解説します。

Amazon S3の暗号化とは？2023年以降のデフォルト動作

S3の暗号化とは、S3に保存されるオブジェクト（ファイル）をAES-256アルゴリズムで暗号化し、不正アクセス時にデータの中身を読み取れないようにする仕組みです。

2023年1月5日以降、AWSは重要な仕様変更を行いました。新規にアップロードされるすべてのS3オブジェクトに、SSE-S3（AES-256）による暗号化がデフォルトで自動適用されるようになったのです。

つまり、現在では何も設定しなくてもS3のデータは暗号化されています。ただし、「デフォルトの暗号化で十分なのか」「KMSキーを使うべきか」という判断は、プロジェクトのセキュリティ要件によって異なります。

S3サーバーサイド暗号化の3種類を比較

S3のサーバーサイド暗号化（SSE: Server-Side Encryption）には、以下の3つの方式があります。

項目	SSE-S3	SSE-KMS	SSE-C
正式名称	SSE with S3 managed keys	SSE with KMS managed keys	SSE with customer-provided keys
暗号化キーの管理者	AWS（S3サービス）	AWS KMS	ユーザー自身
キーのローテーション	自動（AWS管理）	自動 or 手動（設定可能）	ユーザー責任
アクセス制御の粒度	S3バケットポリシーのみ	KMSキーポリシー + IAM	ユーザー側で完全制御
監査ログ（CloudTrail）	なし	あり（キー使用履歴を記録）	なし
追加コスト	無料	KMS APIリクエスト料金	無料（キー管理コストは自前）
デフォルト適用	✅（2023年1月〜）	手動設定	手動設定
適用場面	一般的なデータ保護	コンプライアンス要件あり	独自のキー管理基盤がある場合

SSE-S3の仕組みと設定方法

SSE-S3は、AWSがS3サービス内部で暗号化キーを管理する方式です。2023年1月以降はすべてのS3バケットにデフォルトで適用されているため、追加の設定は基本的に不要です。

暗号化状態の確認方法

オブジェクトがSSE-S3で暗号化されているかどうかは、AWS CLIで確認できます。

aws s3api head-object --bucket my-bucket --key my-file.txt

SSE-S3で暗号化されている場合、レスポンスに以下が含まれます。

{
  "ServerSideEncryption": "AES256"
}

バケットのデフォルト暗号化設定を確認

aws s3api get-bucket-encryption --bucket my-bucket

{
  "ServerSideEncryptionConfiguration": {
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "AES256"
        },
        "BucketKeyEnabled": false
      }
    ]
  }
}

SSE-S3で十分なケース

ほとんどの一般的なユースケースでは、SSE-S3で十分なセキュリティが確保されます。特に以下の場合はSSE-S3がシンプルで最適です。

コンプライアンスで特定のキー管理要件が求められていない
データの暗号化は必要だが、誰がいつ復号したかの監査ログは不要
コストを最小限に抑えたい

SSE-KMSの仕組みと設定方法

SSE-KMSは、AWS Key Management Service（KMS）で管理するキーを使ってS3オブジェクトを暗号化する方式です。SSE-S3との最大の違いは、キーのアクセス制御と監査ログにあります。

SSE-KMSをデフォルト暗号化に設定する

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "aws:kms",
          "KMSMasterKeyID": "arn:aws:kms:ap-northeast-1:123456789012:key/your-key-id"
        },
        "BucketKeyEnabled": true
      }
    ]
  }'

💡 BucketKeyEnabled: true を設定すると、S3バケットキー機能が有効になり、KMS APIへのリクエスト数が削減されます。大量のオブジェクトを扱うバケットでは、これだけでKMSのAPI料金を大幅に抑えられます。

暗号化状態の確認

SSE-KMSで暗号化されたオブジェクトの場合、レスポンスは以下のようになります。

{
  "ServerSideEncryption": "aws:kms",
  "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/your-key-id"
}

SSE-KMSを選ぶべきケース

コンプライアンス要件: PCI DSS、HIPAA、ISMAPなど、暗号化キーの管理と監査ログが求められる規制環境
アクセス制御の粒度: KMSキーポリシーにより、「特定のIAMロールだけが復号可能」という制御が可能
監査証跡: CloudTrailにキーの使用履歴が記録されるため、「誰がいつデータにアクセスしたか」を追跡可能
クロスアカウントアクセス: 異なるAWSアカウント間でデータを共有する際、KMSキーポリシーで制御

SSE-KMSのコストに関する注意点

SSE-KMSには以下のコストが発生します。

KMSキーの保管: カスタマーマネージドキー1つあたり月額$1
APIリクエスト: 暗号化・復号のたびにKMS APIが呼ばれ、10,000リクエストあたり$0.03
S3バケットキー未使用時: オブジェクトのPUT/GETのたびにAPIコールが発生し、大量データでは無視できないコストに

筆者自身、以前バケットキーを有効にし忘れた状態で大量のオブジェクトをアップロードし、想定外のKMS料金が発生した経験があります。SSE-KMSを使用する場合は、BucketKeyEnabled: trueの設定を忘れないよう注意してください。

SSE-Cの使いどころと実装方法

SSE-C（Customer-Provided Keys）は、ユーザーが自分で管理する暗号化キーをリクエストのたびにS3に渡す方式です。AWSはキーを保存せず、処理後に破棄します。

SSE-Cの特徴

ユーザーがキーの生成・管理・ローテーションの全責任を負う
キーを紛失すると、データの復号が不可能になる（AWSでも復旧不可）
HTTPS経由でのみ使用可能（HTTPは不可）

SSE-Cでのアップロード例

# 256ビットのキーを生成
KEY=$(openssl rand -base64 32)
KEY_MD5=$(echo -n "$KEY" | base64 -d | openssl dgst -md5 -binary | base64)

# SSE-Cでアップロード
aws s3api put-object \
  --bucket my-bucket \
  --key my-file.txt \
  --body my-file.txt \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "$KEY" \
  --sse-customer-key-md5 "$KEY_MD5"

SSE-Cでのダウンロード

ダウンロード時にも同じキーを指定する必要があります。

aws s3api get-object \
  --bucket my-bucket \
  --key my-file.txt \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "$KEY" \
  --sse-customer-key-md5 "$KEY_MD5" \
  downloaded-file.txt

SSE-Cを選ぶべきケース

SSE-Cは一般的な用途ではほとんど使いません。以下のような特殊な要件がある場合にのみ検討してください。

社内の独自キー管理基盤（HSM等）と連携する必要がある
規制上、AWSにキーの管理を委ねられない
マルチクラウド環境で、暗号化キーを一元管理する必要がある

クライアント側暗号化（CSE）という選択肢

ここまで紹介したSSE-S3/SSE-KMS/SSE-Cはいずれも「サーバーサイド暗号化」——つまりS3のサーバー上でデータを暗号化する方式です。

これに対し、**クライアント側暗号化（CSE: Client-Side Encryption）**は、データをS3にアップロードする前に、アプリケーション側で暗号化する方式です。

S3には暗号化済みのデータが保存されるため、AWSの内部処理でもデータの中身を読み取ることができません。最も高いセキュリティレベルを求める場合の選択肢ですが、暗号化・復号の処理をアプリケーション側に実装する必要があり、開発・運用のコストが増加します。

S3暗号化方式の選定フローチャート

Q1: コンプライアンスで特定のキー管理要件があるか？
├── No → SSE-S3（デフォルトのまま）
└── Yes
    └── Q2: AWSにキー管理を委ねられるか？
        ├── Yes → SSE-KMS
        └── No
            └── Q3: 自社でキー管理基盤があるか？
                ├── Yes → SSE-C
                └── No → SSE-KMS（KMSのカスタマーマネージドキーが現実的）

迷ったらSSE-S3（デフォルト）で始めて、コンプライアンス要件が出てきた時点でSSE-KMSに移行するのが最も堅実なアプローチです。既存オブジェクトの暗号化方式は、S3バッチオペレーションで一括変更できます。

まとめ

Amazon S3の暗号化について、要点を整理します。

方式	キー管理	コスト	監査ログ	おすすめ度
SSE-S3	AWS自動管理	無料	なし	★★★（デフォルト）
SSE-KMS	KMS	API料金発生	あり	★★☆（コンプライアンス要件時）
SSE-C	ユーザー自身	無料	なし	★☆☆（特殊要件のみ）

2023年以降、S3に保存されるすべてのデータはデフォルトでSSE-S3により暗号化されています。多くのプロジェクトではこのデフォルト設定で十分ですが、監査ログやきめ細かいアクセス制御が必要な場合はSSE-KMSへの移行を検討してください。