【入門編】 S3バケットの暗号化設定(SSE-S3 vs SSE-KMS) – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

はじめまして！セキュリティの世界へようこそ。国内外でインシデント対応やセキュリティ監査、そしてシステムの堅牢化（ハードニング）を手がけているセキュリティ責任者です。

「クラウドのセキュリティって、専門用語が多くて何から手を付けたらいいか分からない…」と悩んでいませんか？特にAWSのストレージサービスである「Amazon S3」の暗号化設定を見つめながら、「SSE-S3」と「SSE-KMS」のどちらを選べばいいんだろう？ と立ち止まってしまう方は非常に多いです。

結論から言うと、この2つの違いを理解することは、「泥棒から我が家の大事な財産をどう守るか」という防犯対策を考えるのと全く同じです。

今回は、難しい暗号理論の数式は一切使わずに、身近な「家の鍵」や「泥棒の心理」に例えながら、現場のプロが使う本質的なセキュリティの考え方を優しく紐解いていきます。一歩ずつ、一緒に学んでいきましょう！

—

そもそも「データの暗号化」ってなに？

まずは基本のイメージから整理しましょう。

データを「暗号化する」というのは、「大切な書類（生データ）を、頑丈な金庫（暗号化されたデータ）に入れて鍵をかけること」です。

鍵を持っていない泥棒（ハッカー）がその金庫を盗み出しても、中身を読むことはできません。これが「保存データの暗号化（Encryption at Rest）」の目的です。この金庫のロックに使われるのが、現代の暗号規格で最も信頼されている「AES-256（共通鍵暗号）」という、非常に頑丈な鍵になります。

ここで問題になるのが、「その金庫の鍵を、誰が、どこで、どうやって保管するのか？」という点です。実は、セキュリティの成否はこの「鍵の管理（キーマネジメント）」で決まります。

AWSでは、この鍵の管理方法として主に2つの選択肢を用意しています。それが「SSE-S3」と「SSE-KMS」です。

—

SSE-S3：マンションの管理人が鍵を預かってくれるシステム

まずは、一番手軽な SSE-S3（Amazon S3 管理の暗号化キー） から見ていきましょう。

身近な例えで言うと？

これは、「信頼できるマンションの管理人に、部屋の鍵を預けておくシステム」です。

あなたが自分の部屋（S3バケット）に荷物を出し入れしようとすると、管理人が「あ、住人の◯◯さんですね」と自動的に鍵を開けてくれます。あなたは鍵を持ち歩く必要すらありません。

メリット： とにかく楽。追加料金もかからず、設定のスイッチをONにするだけでAWSが裏側で自動的に鍵を作って、管理してくれます。
弱点（盲点）： 管理人は「住人の名札（AWSのアクセス権限）」を持っている人なら、誰にでも自動で鍵を開けて部屋に入れてしまいます。

攻撃者（泥棒）はどう狙う？

ホワイトハッカーの視点から見ると、SSE-S3は「設定ミス」にとても弱いです。

もし、新人の開発者メンバーが「S3バケットのアクセス権限（ポリシー）」の設定を間違えて、インターネット全体に公開（パブリックアクセス許可）してしまったとします。
すると、泥棒（ハッカー）は「通りすがりの一般人」なのに、AWSの管理人から「はい、どうぞ」と自動的に鍵を開けてもらい、中身のデータを丸見えにされてしまうのです。

つまり、「データへのアクセス権を持っている人＝暗号を解除できる人」になってしまうのが、SSE-S3の特徴であり、知っておくべき盲点になります。

—

SSE-KMS：自分専用の「生体認証付き二重ロック」

そこで登場するのが、より強力な SSE-KMS（AWS KMS 管理の暗号化キー） です。

「KMS」とは、Key Management Serviceの略。文字通り「鍵を安全に管理するための専用の部屋」だと思ってください。

身近な例えで言うと？

これは、マンションの鍵とは別に、「自分だけが暗号番号を知っている、特注の電子南京錠（二重ロック）」をかけるシステムです。

部屋（S3）に入るための鍵（IAM権限）を持っているだけでは、まだ中の金庫は開きません。金庫を開けるには、隣の「鍵管理室（KMS）」にわざわざ行って、「私はこの金庫を開ける許可（KMSのキーポリシー）を持っています」という別の証明書を提示して、鍵を借りてこなければならないのです。

メリット： 鍵の管理と、データの管理を「完全に分離」できる。
弱点： 鍵を使うたびにほんの少しのAPI料金（ミリセント単位）がかかるため、超大量のアクセスがあるシステムではコストを意識する必要があります。

なぜこれが強力な防御になるのか？

先ほどと同じように、誰かが間違えてS3バケットのアクセス権を「一般公開」にしてしまったとしましょう。

泥棒は、部屋（S3）の中に入ることはできます。金庫（暗号化されたデータ）を盗み出すこともできるでしょう。
しかし、いざ金庫を開けようとした瞬間、「おっと、お前はKMSの鍵を使う権限を持っていないな！」と、KMS側でアクセスが完全にブロックされます。

結果として、データは1文字も解読されず、情報漏洩を防ぐことができるのです。セキュリティの世界では、これを「防衛の多層化（Defense in Depth）」と呼びます。一つの設定ミスが、即座に大惨事になるのを防いでくれる頼もしい味方ですね！

—

「鍵のローテーション（交換）」も自動でラクラク！

防犯の世界では、「同じ鍵を何年も使い続けない」のが鉄則ですよね。万が一、過去に鍵のコピー（漏洩）が作られていた場合、定期的に鍵を交換（ローテーション）していれば、被害を最小限に抑えられます。

AWS KMSの素晴らしいところは、この「鍵の交換作業」をボタン一つで自動化できる点です。

「古い鍵で暗号化したデータはどうなるの？」と心配になるかもしれませんが、安心してください。AWSが裏側で「どのデータに、どの世代の鍵を使ったか」を全部覚えてくれているので、私たちは何も意識せずに、常に最新の安全な鍵を使い続けることができます。

—

【実践】Terraformで安全なS3バケットを作ってみよう！

それでは、実際に実務で使える設定例を見てみましょう。
インフラをコード化するツール「Terraform（テラフォーム）」を使って、「SSE-KMSで厳重に守られた、自動ローテーション付きのS3バケット」を作成するコードになります。

ぜひ参考にして、あなたのプロジェクトに取り入れてみてくださいね。

# 1. まずは「鍵（AWS KMSキー）」を作ります
resource "aws_kms_key" "my_s3_key" {
  description             = "S3バケットのデータを暗号化するための専用の鍵です"
  deletion_window_in_days = 30 # 万が一削除ボタンを押しても、30日間は復活できるように猶予を設けます

  # 【超重要】鍵の自動ローテーションを「有効（true）」にします！
  # これで1年ごとにAWSが自動で新しい鍵に更新してくれます。
  enable_key_rotation     = true

  tags = {
    Name        = "s3-encryption-key"
    Environment = "Production"
  }
}

# 2. 鍵に分かりやすい「名札（エイリアス）」をつけます
resource "aws_kms_alias" "my_s3_key_alias" {
  name          = "alias/s3-secure-storage-key"
  target_key_id = aws_kms_key.my_s3_key.key_id
}

# 3. 大事なデータを保存する「S3バケット」を作ります
resource "aws_s3_bucket" "secure_bucket" {
  bucket = "my-company-ultra-secure-bucket-2023" # 世界で唯一のバケット名にしてくださいね

  tags = {
    Name        = "SecureDataBucket"
    Environment = "Production"
  }
}

# 4. バケットの「暗号化設定」を行い、先ほど作ったKMSキーを紐付けます（SSE-KMS）
resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket_encryption" {
  bucket = aws_s3_bucket.secure_bucket.id

  rule {
    apply_server_side_encryption_by_default {
      # ここで「aws:kms」を指定することで、SSE-KMSを有効にします
      # （SSE-S3にしたい場合は「AES256」を指定します）
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.my_s3_key.arn
    }
    # 二重で暗号化を施すことで、鍵の管理をさらに強固にします（Bucket Keyの有効化）
    bucket_key_enabled = true
  }
}

# 5. 【おまけの防犯対策】バケットへのパブリックアクセス（一般公開）を完全に遮断します！
resource "aws_s3_bucket_public_access_block" "secure_bucket_block" {
  bucket = aws_s3_bucket.secure_bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

—

まとめ：どう使い分ければいいの？

最後に、現場で迷わないためのシンプルな判断基準を整理しておきます。

セキュリティ対策は、一兆円をかけて完璧な城壁を築くことではありません。「守るべきものの価値」に合わせて、適切な高さのハードルを設置することです。

開発するシステムが扱うデータが、もし「漏洩したときにニュースになってしまうような大切な情報（個人情報や社外秘のデータ）」であれば、迷わず SSE-KMS を選択しましょう。

難しそうに見えるクラウドセキュリティも、こうして仕組みを紐解いていけば、決して恐れるものではありません。大切なデータを守る頼もしいエンジニアへの第一歩、一緒にゆっくりと歩んでいきましょう！