AWS KMS入門 S3データ暗号化とキー管理の実践ガイド

「S3にアップロードしたデータ、暗号化しなくて大丈夫だろうか」——クラウドストレージを使い始めると、必ずぶつかるのがデータ保護の問題です。

オンプレ環境であれば、ディスク暗号化はdm-cryptやBitLockerで対応し、鍵はHSM（ハードウェアセキュリティモジュール）やセキュリティ担当者が厳重に管理していた方も多いでしょう。暗号鍵の管理は「物理的にアクセスできる人間を限定する」ことで成り立っていました。

しかしAWSでは、データは複数のデータセンターに分散保存され、APIひとつで誰でもアクセスできてしまう可能性があります。だからこそ、暗号化と鍵管理の仕組みを正しく理解して設計することが欠かせません。

この記事では、AWSの鍵管理サービス「AWS KMS（Key Management Service）」とAmazon S3の暗号化機能について、オンプレの暗号化運用との違いを交えながら、基本設定から実務での活用方法まで解説します。

なぜクラウドで暗号化と鍵管理が重要なのか

オンプレ環境では、データ保護の基本は「物理的なアクセス制御」でした。サーバールームに入れる人間を制限し、ディスクを持ち出されてもdm-cryptやLUKSで暗号化していれば中身は読めない。暗号鍵はHSMに格納するか、鍵管理サーバーに保管して運用していました。

クラウドでは、この前提が根本から変わります。

・データの物理的な場所を制御できない: S3のオブジェクトは複数AZのストレージに自動複製される
・アクセス経路がネットワーク経由: IAMポリシーの設定ミスひとつでバケットが公開状態になりうる
・退職者の鍵無効化が必須: オンプレのように「カードキーを回収して終わり」ではなく、IAMユーザーの削除と鍵のローテーションが必要

こうした背景から、AWSではデータの暗号化を「保存時（at rest）」と「転送時（in transit）」の2層で考えます。転送時の暗号化はTLS/SSLで自動的に保護されますが、保存時の暗号化は利用者が明示的に設定する必要があります。

AWS KMSは、この「保存時の暗号化」に使う鍵を一元管理するマネージドサービスです。オンプレでいえば、HSMと鍵管理サーバーをクラウド上にまとめたものと考えると理解しやすいでしょう。

AWS KMSとS3暗号化の基本設定

1. S3の暗号化方式を理解する

Amazon S3には、保存時の暗号化として3つの方式が用意されています。

・SSE-S3（S3マネージドキー）: AWSが鍵の生成・管理・ローテーションをすべて自動で行う。最もシンプルで、2023年1月以降はS3バケットのデフォルト暗号化として自動適用される
・SSE-KMS（AWS KMSキー）: AWS KMSで管理するカスタマーマネージドキー（CMK）またはAWSマネージドキーを使用する。鍵の使用履歴がCloudTrailに記録され、きめ細かいアクセス制御が可能
・SSE-C（カスタマー提供キー）: 利用者が自分で鍵を生成・管理し、S3にアップロード時に鍵を渡す。AWSは鍵を保存しない

オンプレの暗号化経験がある方にとっては、SSE-S3が「ストレージコントローラーの自動暗号化」、SSE-KMSが「HSMと連携した暗号化」、SSE-Cが「アプリケーション側で鍵を管理する暗号化」に対応すると考えるとわかりやすいです。

多くの本番環境では、監査証跡と鍵のアクセス制御が求められるため、SSE-KMSが推奨されます。

2. AWS KMSでカスタマーマネージドキーを作成する

マネジメントコンソールでの手順は以下の通りです。

1. AWSマネジメントコンソールで「KMS」を検索して開く
2. 左メニューの「カスタマー管理型のキー」→「キーの作成」をクリック
3. キータイプは「対称」を選択（S3暗号化にはAES-256対称鍵を使用する）
4. キーの使用は「暗号化および復号」を選択
5. エイリアス（表示名）を入力（例: s3-data-encryption-key）
6. キー管理者を指定する。これは鍵の削除やポリシー変更ができるIAMユーザー/ロール
7. キーの使用者を指定する。S3で暗号化・復号を行うIAMユーザー/ロールを選択
8. キーポリシーを確認して「完了」をクリック

AWS CLIで作成する場合は以下のコマンドを使います。

# AWS CLI: KMSカスタマーマネージドキーの作成
aws kms create-key \
  --description "S3データ暗号化用キー" \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS

# エイリアスを設定（管理しやすくするため）
aws kms create-alias \
  --alias-name alias/s3-data-encryption-key \
  --target-key-id <作成時に返されたKeyId>

作成したキーのARN（Amazon Resource Name）は、S3バケットの暗号化設定で使用するので控えておいてください。

3. S3バケットにSSE-KMS暗号化を設定する

既存のS3バケットにデフォルト暗号化としてSSE-KMSを設定します。

1. S3コンソールで対象バケットを開く
2. 「プロパティ」タブ→「デフォルトの暗号化」の「編集」をクリック
3. 暗号化タイプで「AWS Key Management Service キー（SSE-KMS）」を選択
4. 「AWS KMSキーから選択する」で先ほど作成したキーを選択
5. バケットキーを「有効にする」に設定（KMS APIコール数を削減しコストを抑えるため）
6. 「変更の保存」をクリック

AWS CLIでの設定はこちらです。

# AWS CLI: S3バケットにSSE-KMSデフォルト暗号化を設定
aws s3api put-bucket-encryption \
  --bucket my-secure-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      },
      "BucketKeyEnabled": true
    }]
  }'

この設定以降、バケットに新しくアップロードされるオブジェクトは自動的にSSE-KMSで暗号化されます。既存のオブジェクトは暗号化されないため、必要に応じてS3バッチオペレーションで再暗号化を行ってください。

料金の仕組み

AWS KMSの料金は、オンプレのHSM導入と比べると圧倒的に低コストですが、APIコール数に応じた従量課金がある点に注意が必要です（2026年4月時点）。

ポイントは「S3バケットキー」の有効化です。バケットキーを使わない場合、S3はオブジェクトごとにKMS APIを呼び出すため、大量ファイルを扱う環境ではAPIコール料金が想定外に膨らむことがあります。バケットキーを有効にすると、S3がバケット単位で一時的なデータキーを生成し、KMSへのAPIコールを大幅に削減できます。

たとえば、1日100万オブジェクトをアップロードする環境では、バケットキーなしだと月間のKMS APIコール料金だけで約$90になります。バケットキーを有効にすれば、これが$1以下に抑えられます。

SSE-S3を選択した場合は、暗号化に関する追加料金はかかりません。ただし、鍵の使用履歴がCloudTrailに記録されないため、コンプライアンス要件との兼ね合いで判断してください。

応用・実務Tips

1. キーポリシーで最小権限を実現する

KMSのキーポリシーは、IAMポリシーとは別の独立したアクセス制御レイヤーです。オンプレでHSMの操作権限を「管理者」と「利用者」に分離していたのと同じ考え方で、KMSでも「キー管理者」と「キー使用者」を明確に分離してください。

# キーポリシーの例（JSON）
# キー管理者: 鍵の有効化/無効化/削除が可能、暗号化/復号は不可
# キー使用者: 暗号化/復号のみ可能、鍵の管理操作は不可
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "KeyAdministration",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/KeyAdmin"},
      "Action": [
        "kms:Create*", "kms:Describe*", "kms:Enable*",
        "kms:List*", "kms:Put*", "kms:Update*",
        "kms:Revoke*", "kms:Disable*", "kms:Delete*",
        "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "KeyUsage",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/AppRole"},
      "Action": [
        "kms:Decrypt", "kms:Encrypt",
        "kms:GenerateDataKey", "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

2. 自動キーローテーションを有効にする

オンプレでは暗号鍵のローテーションは運用負荷の高い作業でしたが、AWS KMSではカスタマーマネージドキーの自動ローテーションをワンクリックで有効化できます。

# AWS CLI: 自動キーローテーションを有効化（365日周期）
aws kms enable-key-rotation \
  --key-id alias/s3-data-encryption-key

ローテーション後も、過去のキーマテリアルはKMS内部に保持されるため、古い鍵で暗号化されたデータも引き続き復号できます。アプリケーション側の変更は一切不要です。

3. CloudTrailで鍵の使用状況を監査する

SSE-KMSの大きなメリットのひとつが、すべての鍵の使用がAWS CloudTrailに記録される点です。「いつ、誰が、どのキーで、何を復号したか」が自動的にログに残ります。

CloudTrailのイベント履歴で「KMS」をフィルタすると、Decrypt、Encrypt、GenerateDataKeyといったAPI呼び出しを確認できます。不審な復号リクエストがあれば、Amazon EventBridgeと組み合わせてリアルタイムにアラートを飛ばすことも可能です。

セキュリティに関する基礎知識をより深く学びたい方は、姉妹サイトのSecurityMasters.TOKYOもあわせてご覧ください。暗号化の基礎理論やゼロトラストの考え方について体系的に解説しています。

よくあるトラブルと対処法

AccessDeniedException で復号できない

S3からオブジェクトをダウンロードしようとしたときに「AccessDeniedException」が発生する場合、原因の多くはKMSキーポリシーかIAMポリシーの権限不足です。

・確認ポイント1: IAMユーザー/ロールに kms:Decrypt 権限があるか
・確認ポイント2: KMSキーポリシーの「キー使用者」に該当のプリンシパルが含まれているか
・確認ポイント3: クロスアカウントアクセスの場合、双方のポリシーで許可しているか

特に見落としやすいのが、S3バケットポリシーでアクセスを許可していても、KMSキーポリシーで許可していないケースです。S3の暗号化にKMSを使っている場合、S3とKMSの両方で権限を設定する必要があります。

KMS APIのスロットリングが発生する

KMS APIにはアカウント・リージョンごとにリクエストレート制限があります。東京リージョン（ap-northeast-1）の場合、暗号化系APIのデフォルト上限は5,500リクエスト/秒です（2026年4月時点）。

大量ファイルの一括暗号化処理で「ThrottlingException」が発生する場合は、以下の対策を検討してください。

・S3バケットキーを有効にする: KMS APIコールを最大99%削減できる
・リトライにエクスポネンシャルバックオフを実装する: AWS SDKを使っていれば標準で組み込まれている
・上限緩和をリクエストする: AWS Service Quotasから申請可能

キーの削除を誤ってスケジュールしてしまった

KMSのカスタマーマネージドキーは、削除をスケジュールすると最短7日・最長30日の待機期間が設けられます。この待機期間中であれば、以下のコマンドでキャンセルできます。

# AWS CLI: キー削除のキャンセル
aws kms cancel-key-deletion \
  --key-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# キーを再度有効化
aws kms enable-key \
  --key-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

待機期間が過ぎてキーが完全に削除されると、そのキーで暗号化されたデータは二度と復号できなくなります。キーの削除は慎重に、CloudWatch Alarmを設定して削除スケジュールを検知する仕組みを入れておくと安心です。

本記事のまとめ

S3のデータ暗号化は「SSE-S3で自動暗号化されているから大丈夫」と思いがちですが、コンプライアンス要件や監査対応を考えると、SSE-KMSを使ったきめ細かい鍵管理が不可欠です。

まずは開発環境のS3バケットにSSE-KMSを設定してみて、キーポリシーの動作やCloudTrailへのログ記録を確認するところから始めてみてください。