はじめる前に
- 必須AWS アカウントを持っていること
- 必須マネジメントコンソールにサインインできること
- 必須ローカルに AWS CLI が導入されていること
- 必須S3バケットの作成、IAMユーザー・ポリシーの作成経験
- あると良いS3の「デフォルトの暗号化（SSE-S3）」を扱った経験
※ ローカル端末は Windows を想定し、PowerShell から AWS CLI を実行する手順で説明します。複数のIAM認証情報を切り替えるため、名前付きプロファイルを使用します。
参照する公式ドキュメント
手順に迷ったときや、用語の意味を確かめたいときに開きましょう。
※ リンク切れの場合は、ページタイトルで検索してください。
背景・シナリオ
S3の「デフォルトの暗号化」をSSE-S3（AWSが管理する鍵）で確認したことがある方は、保存したデータが自動的に暗号化される安心感を体験しました。しかし、SSE-S3で使われる鍵はAWSが管理しており、「誰が復号できるか」を自分で細かく制御することはできません。
カスタマー管理のKMSキーを自分で作成すると、キーポリシーによって「誰がこの鍵を使って暗号化・復号できるか」を自分でコントロールできるようになります。今回は、S3バケットのデフォルト暗号化をこのカスタマー管理キーを使うSSE-KMSに変更し、S3の読み取り権限（s3:GetObject）を持つIAMユーザーであっても、KMSキーへのkms:Decrypt権限がなければファイルを復号できない、という「2つの許可が両方必要」という体験をします。
SSE-S3とSSE-KMSの違いは何？
SSE-S3はAWSが管理する鍵を使い、自分でアクセス制御することはできません。SSE-KMSは自分で作成・管理するカスタマー管理キー（またはAWS管理キー）を使い、キーポリシーやIAMポリシーで「誰が使えるか」を細かく制御できます。その代わり、SSE-KMSにはKMSの利用料金（キーの保管料・APIコール料）がかかります。
S3の読み取り権限（s3:GetObject）があれば、ファイルの中身を見られるんじゃないの？
SSE-KMSで暗号化されたオブジェクトの場合、s3:GetObjectの権限だけでは不十分です。オブジェクトを復号するには、それを暗号化したKMSキーに対するkms:Decrypt権限も別途必要です。今回はこの「2つの許可が両方必要」という点を、実際にIAMユーザーを使って確認します。
カスタマー管理のKMSキーを作成し、S3バケットのデフォルト暗号化をこのキーを使うSSE-KMSに設定したうえで、s3:GetObjectのみを許可されたIAMユーザーがオブジェクトのダウンロードに失敗し、キーポリシーでkms:Decryptも許可した後は成功することを確認する。
つくる構成
同じIAMユーザー・同じS3オブジェクトのまま、KMSキーポリシーの設定だけを変えて、ダウンロードできるかどうかを比較します。
S3の権限だけでは復号できない
S3とKMS、両方の許可がそろう
※ S3バケットポリシー・IAMユーザーのポリシーは変更していません。KMSキーポリシーだけを変えています。
要件
以下の要件を満たし、「失敗する」→「キーポリシーを直す」→「成功する」という変化を確認してください。
| No | 要件 |
|---|---|
| 1 | リージョンは「東京（ap-northeast-1）」を使用する。 |
| 2 | カスタマー管理の対称KMSキーを1つ作成する（エイリアスは自由、例：alias/s3-demo-key）。キー管理者は自分のIAMユーザー/ロールのみにしておく。 |
| 3 | テスト用のS3バケットを1つ作成し（名前は一意に、例：kms-demo-yourname）、デフォルト暗号化をSSE-KMSに変更してこのキーを指定する。テストファイルを1つアップロードする。 |
| 4 | そのバケットへのs3:GetObjectのみを許可するIAMユーザーを1人作成する。このユーザーの認証情報でファイルのダウンロードを試し、失敗（アクセス拒否）することを確認する。 |
| 5 | KMSキーのキーポリシーに、このIAMユーザーへのkms:Decrypt（および関連する権限）の許可を追加し、再度ダウンロードが成功することを確認する。 |
構築の進め方
「鍵を作る」→「S3をSSE-KMSにする」→「権限不足で失敗を確認する」→「直して成功させる」という順番で進めます。
- フェーズ1 — カスタマーキーを作る
-
マネジメントコンソールにサインインし、リージョンを合わせる
ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。
-
カスタマー管理のKMSキーを作成する
KMSコンソールで「キーを作成」を選び、キータイプは「対称」、用途は「暗号化と復号」を選びます。エイリアスを自由に決め（例：
s3-demo-key）、キー管理者には自分の現在のIAMユーザー/ロールのみを指定して作成します。この時点ではキー利用者は誰も指定しないキー利用者（Key Users）の指定はこの時点ではスキップ、または自分自身だけにしておきます。後ほどフェーズ3〜4で、テスト用のIAMユーザーへの許可をキーポリシーに直接追加します。
- フェーズ2 — S3をSSE-KMSにする
-
テスト用のS3バケットを作成する
S3コンソールでバケットを1つ作成します（名前は一意に、例：
kms-demo-yourname）。 -
デフォルト暗号化をSSE-KMSに変更する
バケットの「プロパティ」タブから「デフォルトの暗号化」を編集し、暗号化タイプを「AWS Key Management Service キー（SSE-KMS）」に変更して、手順2で作成したキーを選択します。
-
テストファイルをアップロードする
適当なテストファイルを1つアップロードします。アップロード後、オブジェクトの「プロパティ」タブで、サーバー側の暗号化がSSE-KMS、使用しているKMSキーが手順2のキーになっていることを確認します。
- フェーズ3 — 権限不足で失敗を確認する
-
S3の読み取り権限だけを持つIAMユーザーを作成する
IAMコンソールでユーザーを1人作成します（例：
kms-demo-user）。「プログラムによるアクセス」用のアクセスキーを発行し、このバケットへのs3:GetObjectのみを許可するインラインポリシーをアタッチします。 -
ローカルにこのユーザー用のプロファイルを設定する
発行したアクセスキーを使って、名前付きプロファイルを設定します。
aws configure --profile kms-demo-user # AWS Access Key ID、Secret Access Key、リージョン(ap-northeast-1)を入力 -
ダウンロードが失敗することを確認する
このプロファイルを使って、テストファイルのダウンロードを試みます。
# AccessDenied 系のエラーになるはず aws s3 cp s3://kms-demo-yourname/<ファイル名> . --profile kms-demo-userS3の権限はあるのに失敗するこのユーザーには
s3:GetObjectの権限があります。それでも失敗するのは、オブジェクトを復号するためのKMSキーへのアクセス権限がまだないためです。 - フェーズ4 — 直して成功させる
-
KMSキーポリシーに許可を追加する
KMSコンソールでキーを選び、「キーポリシー」タブを編集します。
kms-demo-userのARNをPrincipalとして、kms:Decryptとkms:GenerateDataKeyを許可するステートメントを追加します。 -
もう一度ダウンロードを試す
同じコマンドをもう一度実行します。
# 今度は成功するはず aws s3 cp s3://kms-demo-yourname/<ファイル名> . --profile kms-demo-userこれがゴールさきほど失敗した同じコマンドが、今度は成功する——この変化を確認できたら、このハンズオンの目的は達成です。
つまずきポイント
初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直すか」の手がかりとして使ってください。
「AccessDeniedとしか表示されず、S3とKMSどちらが原因か分からない」
エラーメッセージに含まれるリソースのARN（S3バケットのARNか、KMSキーのARNか）を確認してみましょう。どちらに対する権限が拒否されているかが、原因を絞り込むヒントになります。
「Principalを追加したのに、まだ失敗する」
追加したPrincipalのARNが、対象のIAMユーザーのARNと完全に一致しているかを見直しましょう。また、IAMユーザー側のポリシーに s3:GetObject が正しくアタッチされているかも併せて確認しましょう。
完了チェック
要件の再確認ではなく、画面・コマンドのどこを見れば達成を確認できるかをまとめました。次を順に確かめましょう。
- S3オブジェクトの「プロパティ」タブで、サーバー側の暗号化がSSE-KMS、使用しているKMSキーが自分で作成したカスタマー管理キーになっている。
s3:GetObjectのみを持つIAMユーザーでダウンロードを試すと失敗する（キーポリシー編集前）。- キーポリシーに
kms:Decryptの許可を追加した後、同じコマンドで成功する。 - KMSキーの「キーポリシー」タブで、追加したIAMユーザーのARNが許可リストに含まれていることを確認できる。
考えてみよう
手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。
- SSE-KMSでは「S3の権限」と「KMSの権限」の両方が必要なのに、SSE-S3では意識する必要がなかったのはなぜでしょうか。
ヒント
SSE-S3はAWSが管理する鍵を使い、アクセス制御の対象になっていません。SSE-KMSでは、鍵自体が独立したリソースとして存在し、その鍵自体にもアクセス制御（キーポリシー）が設定されている、という点がヒントです。 - キー管理者（Key Administrators）とキー利用者（Key Users）を分けて設定する設計には、どのような利点があるでしょうか。
ヒント
「キーの設定そのものを変更できる人」と「キーを使って暗号化・復号できるだけの人」を分けることで、何を防げるか考えてみましょう。権限の最小化という観点がヒントです。 - 本番運用でカスタマー管理キーを使う場合、キーのローテーションや削除に関して、何に注意するべきでしょうか。
ヒント
KMSキーの削除には、誤削除を防ぐための待機期間が設けられています。一度削除したキーで暗号化されたデータがどうなるか、という観点で考えてみましょう。
後片づけ
作成したリソースを順番に削除します。
- S3バケットを空にして削除する：アップロードしたテストファイルを削除してから、バケット本体を削除します。
- IAMユーザーを削除する：作成したアクセスキーを無効化・削除し、
kms-demo-userを削除します。 - ローカルのプロファイルを削除する：
~/.aws/credentialsからkms-demo-user用の設定を削除します。 - KMSキーを削除予約する：KMSコンソールでキーを選び、「キーの削除をスケジュール」します。最短でも7日間の待機期間があり、即座には削除されません。
削除予約後も、待機期間中は料金が発生する
KMSキーの削除には、誤削除によるデータ復旧不可能な事故を防ぐため、7日〜30日の待機期間が設けられています。待機期間中はキーが残っているため、料金も発生し続けます。今後使う予定がなければ、待機期間を最短（7日）に設定して削除予約しましょう。
コストに関する注意: カスタマー管理のKMSキーには、キー1つあたりの月額料金と、暗号化・復号などのAPIコールに応じた料金がかかります（無料利用枠の対象外です）。削除をスケジュールしても、待機期間（最短7日）中は料金が発生し続けます。S3の保存容量・リクエストにも別途料金がかかりますが、少量であれば無料利用枠の範囲内に収まることが多いです。IAMユーザー自体に料金はかかりません。検証が終わったら、上の「後片づけ」に沿って忘れずに削除しましょう。最新の料金は AWS の公式料金ページで確認してください。