【AWS】S3暗号化!SSE-S3とSSE-KMSの違いとは?セキュリティ要件別の選び方

AWS

今回は、AWS S3のサーバーサイド暗号化(SSE)において、よく比較されるSSE-S3SSE-KMSの違いについて詳しく解説します。

「S3にデータを保存するとき、暗号化はどうすればいいの?」「SSE-S3とSSE-KMSって何が違うの?」という疑問を持つ方は多いのではないでしょうか。

特にセキュリティ要件を満たす必要があるプロジェクトでは、どちらの暗号化方式を選ぶべきか悩むケースが少なくありません。

本記事では、両者の違いを比較表で整理しながら、それぞれのメリット・デメリットを深掘りしていきます。


S3の暗号化には2つのパターンがある

まず前提として、Amazon S3でデータを暗号化する方法は大きく分けてサーバーサイド暗号化(SSE)とクライアントサイド暗号化の2種類があります。

今回フォーカスするのは、AWSが自動的にデータを暗号化してくれるサーバーサイド暗号化(SSE)です。サーバーサイド暗号化では、S3にオブジェクトをアップロードする際にAWS側で暗号化が行われ、ダウンロード時には自動的に復号されます。

このサーバーサイド暗号化には、主に以下の2つの方式があります。

暗号化方式 概要
SSE-S3 S3が管理する鍵で暗号化(Amazon S3 managed keys)
SSE-KMS AWS KMSが管理する鍵で暗号化(AWS Key Management Service keys)

※他にも顧客提供の鍵を使うSSE-Cがありますが、鍵管理の負担が大きいため、一般的にはSSE-S3またはSSE-KMSが選択されることが多いです。

どちらもAES-256による暗号化が行われ、保存データ(Data at Rest)のセキュリティを確保できます。しかし、鍵の管理方法監査機能コストなどに違いがあるため、要件に応じて適切な方式を選ぶ必要があります。


SSE-S3とSSE-KMSの比較表

それでは、SSE-S3とSSE-KMSの違いを一覧表で見ていきましょう。

比較項目 SSE-S3 SSE-KMS
暗号化アルゴリズム AES-256 AES-256
鍵の管理者 AWS(S3サービス) AWS KMS(ユーザーが制御可能)
鍵のローテーション 自動(AWS管理、ユーザー制御不可) 自動または手動(ユーザーが設定可能)
アクセス制御 S3バケットポリシー、IAMポリシー S3ポリシー + KMSキーポリシー(二重制御)
監査ログ(鍵の使用履歴) なし AWS CloudTrailで記録可能
コスト 追加料金なし KMS APIリクエストごとに課金あり
クロスアカウントアクセス S3ポリシーのみで制御 KMSキーポリシーでの許可も必要
カスタマーマネージドキー(CMK) 使用不可 使用可能
設定の手軽さ 非常に簡単 やや複雑(KMSの理解が必要)
コンプライアンス要件対応 基本的な暗号化要件には対応 厳格な監査・鍵管理要件に対応

この表を見ると、SSE-S3は「シンプルで手軽」、SSE-KMSは「高度な制御と監査が可能」という特徴が浮かび上がってきます。


SSE-S3のメリット・デメリット

SSE-S3のメリット

1. 追加コストがかからない

SSE-S3の最大の魅力は、追加料金が一切かからない点です。S3の標準料金のみで暗号化が利用できるため、コストを抑えたいプロジェクトには最適です。

2. 設定が非常に簡単

S3バケットのデフォルト暗号化設定でSSE-S3を選択するだけで、以降アップロードされるすべてのオブジェクトが自動的に暗号化されます。KMSの知識がなくても、すぐに暗号化を導入できます。

3. 運用負荷がゼロに近い

鍵の管理、ローテーション、バックアップなど、暗号化に関する運用はすべてAWSが行います。インフラエンジニアが鍵管理について意識する必要がほとんどありません。

4. パフォーマンスへの影響が少ない

SSE-S3はS3サービス内で完結するため、KMS APIを呼び出すオーバーヘッドがありません。大量のオブジェクトを扱う場合でも、スロットリング(リクエスト制限)を心配する必要がありません。

SSE-S3のデメリット

1. 鍵の使用履歴を追跡できない

SSE-S3では、いつ・誰が・どのオブジェクトを復号したかという監査ログを取得できません。セキュリティ監査やコンプライアンス対応で「鍵の使用履歴」を求められる場合、SSE-S3では要件を満たせない可能性があります。

2. 鍵に対するアクセス制御ができない

SSE-S3の鍵はAWSが完全に管理しているため、「特定のユーザーだけが復号できる」といった細かいアクセス制御ができません。S3バケットやオブジェクトへのアクセス権があれば、自動的に復号されてしまいます。

3. 鍵のローテーション間隔を制御できない

AWSが自動的に鍵をローテーションしていますが、その間隔やタイミングをユーザーが制御することはできません。セキュリティポリシーで「年1回の鍵ローテーション」などの具体的な要件がある場合、証跡として示すことが難しくなります。

4. クロスアカウントでの鍵共有ができない

SSE-S3の鍵は、そのS3バケットが存在するAWSアカウント専用です。別のAWSアカウントと暗号化されたオブジェクトを共有する際、鍵自体を共有する仕組みがないため、柔軟性に欠けます。


SSE-KMSのメリット・デメリット

SSE-KMSのメリット

1. CloudTrailで鍵の使用履歴を監査できる

SSE-KMSの最大の強みは、AWS CloudTrailとの連携による監査機能です。誰がいつ暗号化・復号を行ったかがログとして記録されるため、セキュリティ監査やコンプライアンス対応に必要な証跡を残せます。

2. KMSキーポリシーによる細かいアクセス制御

SSE-KMSでは、S3のアクセス権限に加えて、KMSキーポリシーによる二重のアクセス制御が可能です。「S3バケットにはアクセスできるが、復号はできない」という設定も実現できます。これにより、最小権限の原則をより厳密に適用できます。

3. カスタマーマネージドキー(CMK)が使用可能

AWS管理のキー(aws/s3)だけでなく、自分で作成したカスタマーマネージドキーを使用できます。これにより、鍵のローテーション間隔を自由に設定したり、特定の鍵を無効化・削除したりといった柔軟な鍵管理が可能になります。

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

KMSキーポリシーで他のAWSアカウントに対して鍵の使用を許可できるため、マルチアカウント環境でも暗号化されたデータを安全に共有できます。

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

金融業界や医療業界など、厳格なセキュリティ基準(PCI DSS、HIPAA、SOCなど)への準拠が求められる環境では、SSE-KMSの監査機能と鍵管理機能が大きな強みになります。

SSE-KMSのデメリット

1. 追加コストが発生する

SSE-KMSを使用すると、KMS APIリクエストごとに料金が発生します。2024年現在、リクエストあたり約$0.03/10,000リクエストですが、大量のオブジェクトを頻繁に読み書きする場合は無視できないコストになる可能性があります。

また、カスタマーマネージドキーを作成した場合は、キーの保管料金(約$1/月/キー)も発生します。

2. スロットリング(リクエスト制限)に注意が必要

KMSには、リージョンごとにリクエストレート制限があります。大量のオブジェクトを一度に処理する場合、KMS APIのスロットリングに引っかかり、処理が失敗する可能性があります。必要に応じてAWSサポートに制限緩和を申請する必要があります。

3. 設定が複雑になる

SSE-KMSを使用する場合、S3のポリシーだけでなくKMSキーポリシーも正しく設定する必要があります。IAMポリシー、S3バケットポリシー、KMSキーポリシーの3つが絡み合うため、設定ミスによるアクセス不可や意図しないアクセス許可が発生しやすくなります。

4. KMSキーの削除に伴うデータアクセス不可リスク

カスタマーマネージドキーを誤って削除してしまうと、そのキーで暗号化されたすべてのデータにアクセスできなくなります。KMSには削除待機期間(7〜30日)がありますが、運用には十分な注意が必要です。


どちらを選ぶべきか?ユースケース別の選定ガイド

SSE-S3が適しているケース

  • コストを最小限に抑えたい場合
  • 暗号化の監査ログが不要な場合
  • とにかく手軽に暗号化を導入したい場合
  • 開発環境やテスト環境など、厳格なセキュリティ要件がない場合
  • 大量のオブジェクトを頻繁に読み書きし、スロットリングを避けたい場合

SSE-KMSが適しているケース

  • 監査ログの取得が必須(コンプライアンス要件)の場合
  • 鍵のアクセス制御を細かく設定したい場合
  • 鍵のローテーション間隔を自分で制御したい場合
  • マルチアカウント環境で暗号化されたデータを共有する場合
  • 金融・医療・官公庁など、厳格なセキュリティ基準への準拠が必要な場合

実務での選定ポイント

暗号化方式を選定する際は、以下のポイントを確認することをおすすめします。

  1. セキュリティポリシーの確認:自社のセキュリティポリシーや、顧客から求められるセキュリティ要件に「鍵の使用履歴の監査」が含まれているかを確認しましょう。
  2. コストシミュレーション:想定されるS3オブジェクトの読み書き頻度から、SSE-KMSを使用した場合のKMSコストを試算してみましょう。
  3. 運用体制の確認:KMSキーポリシーの設計・管理ができるメンバーがいるかを確認しましょう。SSE-KMSは設定ミスによるトラブルが起きやすいため、十分な理解が必要です。
  4. 将来的な拡張性:現時点ではSSE-S3で十分でも、将来的にコンプライアンス要件が厳しくなる可能性がある場合は、最初からSSE-KMSを選択しておくのも一つの考え方です。

まとめ

本記事では、AWS S3のサーバーサイド暗号化におけるSSE-S3とSSE-KMSの違いについて解説しました。

ポイント SSE-S3 SSE-KMS
手軽さ ◎ 非常に簡単 △ KMSの理解が必要
コスト ◎ 追加料金なし △ APIリクエスト課金あり
監査機能 × なし ◎ CloudTrailで記録可能
アクセス制御 △ S3ポリシーのみ ◎ 二重制御が可能
コンプライアンス対応 △ 基本的な要件のみ ◎ 厳格な要件に対応

シンプルさとコストを重視するならSSE-S3監査機能と細かい制御を重視するならSSE-KMSが適しています。

どちらが正解ということはなく、プロジェクトの要件に応じて適切な方式を選択することが重要です。本記事が、暗号化方式の選定に悩むエンジニアの方の参考になれば幸いです。


参考リンク(AWS公式ドキュメント)

【注意】

このブログは技術に関する知識や経験を共有することを目的としており、情報の正確性に努めていますが、その内容の正確性や完全性を保証するものではありません。ブログの情報を利用する場合は、自己の責任において行動してください。ブログの内容に基づいて行った行動や決定によって生じた損害や被害について、筆者は一切の責任を負いません。

 

記事の内容の一部は、生成AIで作成しています。

AWSセキュリティ
この記事の作者
StarTeller

30歳で異業種からITエンジニアへ転身し、10年以上にわたりインフラエンジニアとして様々な現場でシステム構築・運用に携わってきました。
得意分野はLinux/Windowsのサーバー構築・運用で、ネットワークやAWSなども実務で活用しています。このブログでは、これまでの業務で培った経験を基に、日々の業務で遭遇した問題の解決方法や、システム構築の具体的な手順を解説。現場のエンジニアが実際に「困ったとき」に参照できる情報を意識して投稿していこうと思っています。
※サーバ運用費がかかっているので、広告を掲載させて頂いてます。

StarTellerをフォローする
シェアする
StarTellerをフォローする
タイトルとURLをコピーしました