S3暗号化の設定｜SSE-S3とSSE-KMSの違いとCLIでの確認方法

S3 のサーバー側暗号化は、SSE-S3（S3 が鍵を管理）と SSE-KMS（AWS KMS の鍵を使う）のどちらかをバケットの既定に設定して使うのが基本で、違いは「だれが鍵を管理し、鍵の利用をどこまで制御・記録できるか」です。 2023年1月5日以降、新しくアップロードされるオブジェクトは何も設定しなくても SSE-S3 で暗号化されます。

この記事では、4つの方式の比較表、方式別にそのまま使える put-bucket-encryption の JSON、バケットの既定とオブジェクトごとの方式を見分けるコマンドを、出力と一緒に載せます。設定を変えても既存のオブジェクトはそのまま、という点と、その対処まで扱います。

確認環境：Linux、AWS CLI 1.46.1。AWS の API をローカルで再現するツール（moto 5.2.3）で実行しています。掲載するコマンドは実際の AWS でそのまま使える形です（アカウント ID は 123456789012 としています）。

S3 暗号化方式の早見表

やりたいことからコマンドを引く表です。

SSE-S3 と SSE-KMS はどちらを選ぶか

鍵の利用を制御・記録する必要がなければ SSE-S3、必要があれば SSE-KMS とカスタマー管理キー、という分け方で十分です。SSE-KMS で鍵を指定しなかったときに使われる AWS管理キー（aws/s3）は、公式ドキュメントによると別アカウントとの共有には使えません。共有の予定があるなら、最初からカスタマー管理キーにしておきます。

2023年以降の既定：新しいオブジェクトは SSE-S3 で暗号化される

公式ドキュメントの要点は次の3つです。

• 2023年1月5日から、すべての新しいオブジェクトは追加料金なしで SSE-S3 によって自動的に暗号化される
• 既定の暗号化を設定していなかった既存のバケットにも、SSE-S3 が既定として設定された
• それより前から入っていた暗号化されていないオブジェクトは、自動では暗号化されない

つまり「暗号化を有効にする」作業は必要なくなり、いま設定で決めるのはどの方式・どの鍵を既定にするかです。

put-bucket-encryption の JSON（方式別）

バケットを作り、方式ごとの JSON を順に設定していきます。

aws s3api create-bucket --bucket example-docs-bucket \
  --create-bucket-configuration LocationConstraint=ap-northeast-1

{
    "Location": "/example-docs-bucket"
}

SSE-S3 を既定にする

sse-s3.json:

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": { "SSEAlgorithm": "AES256" }
    }
  ]
}

aws s3api put-bucket-encryption --bucket example-docs-bucket \
  --server-side-encryption-configuration file://sse-s3.json

aws s3api get-bucket-encryption --bucket example-docs-bucket

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

put-bucket-encryption は成功すると何も表示しません。get-bucket-encryption の SSEAlgorithm が AES256 なら SSE-S3 です。

SSE-KMS を既定にする（バケットキーつき）

先に KMS キーを作り、ARN を控えます。

aws kms create-key --description "docs bucket key" \
  --query KeyMetadata.Arn --output text

arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173

sse-kms.json（KMSMasterKeyID は自分の鍵の ARN に置き換えます）:

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173"
      },
      "BucketKeyEnabled": true
    }
  ]
}

aws s3api put-bucket-encryption --bucket example-docs-bucket \
  --server-side-encryption-configuration file://sse-kms.json

aws s3api get-bucket-encryption --bucket example-docs-bucket

{
    "ServerSideEncryptionConfiguration": {
        "Rules": [
            {
                "ApplyServerSideEncryptionByDefault": {
                    "SSEAlgorithm": "aws:kms",
                    "KMSMasterKeyID": "arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173"
                },
                "BucketKeyEnabled": true
            }
        ]
    }
}

KMSMasterKeyID には鍵の完全な ARN を書くのが確実です。公式ドキュメントは、別アカウントからの操作ではエイリアスが要求した側のアカウントで解決されるため、完全な ARN を使うよう案内しています。

DSSE-KMS を既定にする

DSSE-KMS は、KMS のデータキーによる暗号化と、S3 が管理する鍵による暗号化を重ねる2層の方式です。JSON は SSEAlgorithm を aws:kms:dsse に変えます。バケットキーには対応していないので BucketKeyEnabled は書きません。

dsse-kms.json:

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms:dsse",
        "KMSMasterKeyID": "arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173"
      }
    }
  ]
}

aws s3api put-bucket-encryption --bucket example-docs-bucket \
  --server-side-encryption-configuration file://dsse-kms.json

aws s3api get-bucket-encryption --bucket example-docs-bucket

{
    "ServerSideEncryptionConfiguration": {
        "Rules": [
            {
                "ApplyServerSideEncryptionByDefault": {
                    "SSEAlgorithm": "aws:kms:dsse",
                    "KMSMasterKeyID": "arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173"
                },
                "BucketKeyEnabled": false
            }
        ]
    }
}

バケットの既定とオブジェクトごとの方式を見分ける

get-bucket-encryption が示すのは「これからアップロードされるものの既定」、head-object が示すのは「そのオブジェクトが実際にどう暗号化されているか」です。2つは一致するとは限りません。順に確かめます。

既定が SSE-S3 のときにアップロードしたオブジェクト

バケットの既定が SSE-S3 の状態で a.txt をアップロードした結果です。

aws s3 cp a.txt s3://example-docs-bucket/a.txt
aws s3api head-object --bucket example-docs-bucket --key a.txt

{
    "AcceptRanges": "bytes",
    "LastModified": "Mon, 05 Oct 2026 06:50:52 GMT",
    "ContentLength": 6,
    "ETag": "\"eb260e9ae827821beceeed4104f0ad89\"",
    "ContentType": "text/plain",
    "ServerSideEncryption": "AES256",
    "Metadata": {}
}

既定を SSE-KMS に変えたあとにアップロードしたオブジェクト

既定を SSE-KMS（バケットキーつき）に変えてから b.txt をアップロードします。

aws s3 cp b.txt s3://example-docs-bucket/b.txt
aws s3api head-object --bucket example-docs-bucket --key b.txt

{
    "AcceptRanges": "bytes",
    "LastModified": "Mon, 05 Oct 2026 06:51:02 GMT",
    "ContentLength": 7,
    "ETag": "\"59d0d19fc45ca69230d858f60a5557f8\"",
    "ContentType": "text/plain",
    "ServerSideEncryption": "aws:kms",
    "Metadata": {},
    "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173",
    "BucketKeyEnabled": true
}

head-object の読み方をまとめます。

既存のオブジェクトは設定変更では変わらない

既定を SSE-KMS に変えたあとで、先にアップロードしてあった a.txt を見ます。

aws s3api head-object --bucket example-docs-bucket --key a.txt \
  --query ServerSideEncryption

"AES256"

SSE-S3 のままです。既定の暗号化は、設定したあとにアップロードされるオブジェクトにだけ効きます。

アップロード時に --sse を付けると既定より優先される

既定が SSE-KMS のバケットに、--sse AES256 を付けてアップロードします。

aws s3 cp c.txt s3://example-docs-bucket/c.txt --sse AES256
aws s3api head-object --bucket example-docs-bucket --key c.txt \
  --query '[ServerSideEncryption,SSEKMSKeyId]'

[
    "AES256",
    null
]

リクエストに暗号化の指定が入っていると、S3 はバケットの既定ではなくリクエストの指定を使います。そのため、既定を SSE-KMS にしていても、SSE-S3 のオブジェクトが混ざることがあります。そろえたいときは、後半のバケットポリシーで指定を必須にします。

バケット内の暗号化方式を一覧にする

オブジェクトごとに head-object を実行して、方式・鍵・バケットキーを一覧にするスクリプトです。

list-sse.sh:

#!/usr/bin/env bash
# 使い方: ./list-sse.sh バケット名
set -euo pipefail
BUCKET="$1"
aws s3api list-objects-v2 --bucket "$BUCKET" --query 'Contents[].Key' --output text |
tr '\t' '\n' | while read -r KEY; do
  [ -z "$KEY" ] && continue
  SSE=$(aws s3api head-object --bucket "$BUCKET" --key "$KEY" \
    --query '[ServerSideEncryption, SSEKMSKeyId, BucketKeyEnabled]' --output text)
  printf '%s\t%s\n' "$KEY" "$SSE"
done

chmod +x list-sse.sh
./list-sse.sh example-docs-bucket

a.txt   AES256  None    None
b.txt   aws:kms arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173    True
c.txt   AES256  None    None

3つのうち2つが、バケットの既定（SSE-KMS）と違う方式で入っていることがわかります。オブジェクトの数だけリクエストが発生するので、数が多いバケットではプレフィックスを絞って使います。

既存のオブジェクトを cp の上書きで暗号化し直す

既存のオブジェクトの方式を変えるには、同じ場所へのコピーで書き直します。--sse と --sse-kms-key-id で新しい方式を指定します。

aws s3 cp s3://example-docs-bucket/a.txt s3://example-docs-bucket/a.txt \
  --sse aws:kms \
  --sse-kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173

aws s3api head-object --bucket example-docs-bucket --key a.txt \
  --query '[ServerSideEncryption,SSEKMSKeyId,BucketKeyEnabled]'

[
    "aws:kms",
    "arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173",
    true
]

バケット全体をまとめて書き直すときは --recursive を付けます。先に --dryrun で対象を確かめてから実行します。

aws s3 cp s3://example-docs-bucket/ s3://example-docs-bucket/ --recursive \
  --sse aws:kms \
  --sse-kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173 \
  --dryrun

(dryrun) copy: s3://example-docs-bucket/a.txt to s3://example-docs-bucket/a.txt
(dryrun) copy: s3://example-docs-bucket/b.txt to s3://example-docs-bucket/b.txt
(dryrun) copy: s3://example-docs-bucket/c.txt to s3://example-docs-bucket/c.txt

--dryrun を外して実行し、もう一度一覧を取ると、すべて SSE-KMS にそろいます。

copy: s3://example-docs-bucket/b.txt to s3://example-docs-bucket/b.txt
copy: s3://example-docs-bucket/a.txt to s3://example-docs-bucket/a.txt
copy: s3://example-docs-bucket/c.txt to s3://example-docs-bucket/c.txt

a.txt   aws:kms arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173    True
b.txt   aws:kms arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173    True
c.txt   aws:kms arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173    True

上書きコピーは新しいオブジェクトを書き込む操作なので、更新日時が変わり、バージョニングが有効なら新しいバージョンが増えます。オブジェクトの数が多いときは、公式ドキュメントが案内している S3 バッチオペレーションのコピーが向いています。

バケットキーで KMS へのリクエストを減らす

SSE-KMS では、オブジェクトを読み書きするたびに S3 から KMS へリクエストが出ます。バケットキーを有効にすると、S3 がバケット単位の鍵を短い時間だけ保持してデータキーを作るため、KMS へのリクエストが減ります。公式ドキュメントは、KMS のリクエスト料金を最大 99% 減らせるとしています。

有効にする前に知っておきたい点は3つです。

設定は SSE-KMS の JSON に "BucketKeyEnabled": true を足すだけです。オブジェクト単位で指定するときは s3api put-object に --bucket-key-enabled を付けます。

DSSE-KMS と SSE-C をオブジェクト単位で指定する

DSSE-KMS は s3api put-object で指定する

AWS CLI 1.46.1 の aws s3 cp --sse が受け付ける値は2つです。aws:kms:dsse を渡すと、送信前に次のメッセージで止まります。

aws s3 cp d.txt s3://example-docs-bucket/d.txt --sse aws:kms:dsse

…（省略）…
aws: error: argument --sse: Invalid choice, valid choices are:
AES256                                   | aws:kms

DSSE-KMS をオブジェクト単位で指定するときは s3api put-object を使います。

aws s3api put-object --bucket example-docs-bucket --key d.txt --body d.txt \
  --server-side-encryption aws:kms:dsse \
  --ssekms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/b671fb0a-c4ba-4845-b17a-c0b45444a173

aws s3api head-object --bucket example-docs-bucket --key d.txt \
  --query ServerSideEncryption

"aws:kms:dsse"

バケットの既定を DSSE-KMS にしてある場合は、aws s3 cp に何も付けなくても DSSE-KMS で暗号化されます。

SSE-C は鍵をリクエストごとに渡す

SSE-C は、256 ビットの鍵を自分で用意してリクエストのたびに渡す方式です。S3 は鍵を保存しません。アップロードとダウンロードで同じ鍵を指定します。

# 32 バイト（256 ビット）の鍵を作る
openssl rand -out ssec.key 32

# アップロード
aws s3 cp d.txt s3://example-docs-bucket/secret.txt \
  --sse-c AES256 --sse-c-key fileb://ssec.key

# ダウンロード（標準出力へ）
aws s3 cp s3://example-docs-bucket/secret.txt - \
  --sse-c AES256 --sse-c-key fileb://ssec.key

upload: ./d.txt to s3://example-docs-bucket/secret.txt
fourth

公式ドキュメントで押さえておきたい点です。

• 取得（GET）にもメタデータの取得（HEAD）にも、アップロード時と同じ鍵が必要。どの鍵でどのオブジェクトを暗号化したかは利用者が管理する
• SSE-C のヘッダーを付けたリクエストは HTTPS が必須
• バケットの既定の暗号化には設定できない
• 2026年4月から、新しい汎用バケットでは SSE-C が既定で無効。使うときは put-bucket-encryption で BlockedEncryptionTypes を NONE にする

SSE-C を使えるようにする JSON です（allow-ssec.json）。

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": { "SSEAlgorithm": "AES256" },
      "BlockedEncryptionTypes": { "EncryptionType": ["NONE"] }
    }
  ]
}

aws s3api put-bucket-encryption --bucket example-docs-bucket \
  --server-side-encryption-configuration file://allow-ssec.json

無効になっているバケットに SSE-C でアップロードすると、公式ドキュメントによれば HTTP 403 の AccessDenied が返ります。

指定した方式以外のアップロードを拒否するバケットポリシー

--sse での上書きを防ぎ、方式をそろえたいときは、バケットポリシーで暗号化ヘッダーが指定の値でないアップロードを拒否します。次の例は SSE-KMS を必須にします。

require-kms.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUploadsWithoutSseKms",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-docs-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    }
  ]
}

aws s3api put-bucket-policy --bucket example-docs-bucket --policy file://require-kms.json
aws s3api get-bucket-policy --bucket example-docs-bucket --query Policy --output text

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUploadsWithoutSseKms",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-docs-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    }
  ]
}

条件キー s3:x-amz-server-side-encryption は、リクエストに付いた暗号化ヘッダーの値を見ます。値を aws:kms:dsse に変えれば DSSE-KMS を必須にする形になり、これは公式ドキュメントに載っている例と同じ構造です。

このポリシーを付けると、アップロードする側は毎回 --sse aws:kms を付ける必要があります。バケットの既定だけに任せる（ヘッダーを付けない）アップロードも拒否の対象になるので、アプリケーションや連携しているサービスの設定を先に確かめておきます。

つまずきやすい点と対処の一覧

よくある質問

Q. 暗号化を設定していないバケットは、暗号化されていないのですか？

A. 2023年1月5日以降にアップロードされたオブジェクトは SSE-S3 で暗号化されています。それより前に暗号化なしでアップロードされたオブジェクトは、そのまま残っています。head-object に ServerSideEncryption が出るかどうかで見分けられます。

Q. SSE-S3 から SSE-KMS に変えると、既存のオブジェクトは読めなくなりますか？

A. 読めます。既定の変更は既存のオブジェクトに影響しません。SSE-S3 のオブジェクトはそのまま SSE-S3 で復号されます。

Q. SSE-KMS の料金を抑える方法はありますか？

A. バケットキーを有効にします。JSON に "BucketKeyEnabled": true を足すだけで、KMS へのリクエストが減ります。DSSE-KMS では使えません。

Q. バケットの既定の暗号化を「なし」にできますか？

A. 新しいオブジェクトは必ず暗号化されます。選べるのは SSE-S3・SSE-KMS・DSSE-KMS のどれを既定にするかです。

まとめ

• 新しいオブジェクトは何もしなくても SSE-S3 で暗号化される（2023年1月5日以降）
• SSE-KMS は鍵の利用を制御・記録したいときに選ぶ。kms:GenerateDataKey と kms:Decrypt の権限が必要
• バケットの既定は get-bucket-encryption、オブジェクトごとの実際の方式は head-object で確かめる
• アップロード時の --sse はバケットの既定より優先される
• 既定を変えても既存のオブジェクトは変わらない。同じ場所への aws s3 cp で暗号化し直す
• SSE-KMS にはバケットキーを付けて KMS へのリクエストを減らす（DSSE-KMS は対象外）
• 方式をそろえたいときは、s3:x-amz-server-side-encryption を条件にしたバケットポリシーを使う

参考・出典

• Amazon S3 のデフォルト暗号化に関するよくある質問
• Setting default server-side encryption behavior for Amazon S3 buckets
• Using server-side encryption with AWS KMS keys (SSE-KMS)
• Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys
• Using dual-layer server-side encryption with AWS KMS keys (DSSE-KMS)
• Using server-side encryption with customer-provided keys (SSE-C)

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。