AWS Certified Solutions Architect - Associate (SAA-C03) #3 Domain 1-2 安全なアーキテクチャ — KMS と暗号化

読了 7分

#2 IAM の深掘り で「誰が何にアクセスするか」を押さえました。今回は一段深く入り込んで、アクセスを突破されてもデータそのものを読めなくする暗号化 を扱います。SAA で暗号化の問題はほとんど「このデータをどう安全に保存/転送するか」と「キーを誰が制御するか」という 2 つの軸で出ます。その中心に KMS があります。

KMS とは何か #

AWS Key Management Service (KMS) は 暗号化キーを作って管理するマネージドサービス です。重要な前提が 2 つあります。

  • KMS は リージョンサービス です。キーは生成されたリージョンを出ません (マルチリージョンキーは例外)。
  • KMS は一度に 最大 4KB までしか直接暗号化しません。そのため実際のデータはエンベロープ暗号化方式で処理します (下で説明)。

キーの種類 #

キーの種類誰が管理ローテーションコストキーポリシー制御
AWS マネージドキー (AWS managed)AWS自動 (1 年)無料不可
カスタマーマネージドキー (Customer managed, CMK)ユーザー選択 (自動/手動)月 $1 + 使用量可能
AWS 所有キー (AWS owned)AWSAWS の裁量無料不可 (見えない)

試験で分かれる箇所は 「キーの使用を監査または制御する必要があるか」 です。キーポリシーを直接制御し、CloudTrail で使用記録を残す必要があるなら カスタマーマネージドキー (CMK) が答えです。単に「暗号化さえできればよい」なら AWS マネージドキーで十分です。

対称キー vs 非対称キー #

KMS キーは基本的に 対称キー (256-bit AES) です。同じキーで暗号化・復号し、キー素材が KMS の外に出ません。非対称キー (RSA/ECC) は公開キーで暗号化して秘密キーで復号したり、署名/検証に使ったりします。ほとんどの保存暗号化は対称キーであり、非対称は外部と公開キーをやり取りする必要があるときだけ使います。

エンベロープ暗号化 (Envelope Encryption) #

KMS が 4KB までしか直接暗号化しないのに、どうやって数十 GB のファイルを暗号化するのでしょうか。答えは エンベロープ暗号化 です。

  1. KMS に データキー (Data Key) の生成 をリクエストします (GenerateDataKey)。
  2. KMS は 平文のデータキー暗号化されたデータキー の 2 つを返します。
  3. 平文のデータキーで実際のデータを暗号化したあと、平文キーはメモリから破棄 します。
  4. 暗号化されたデータと 暗号化されたデータキーを一緒に保存 します。
  5. 復号時には、暗号化されたデータキーを KMS に送って平文キーを受け取り、そのキーでデータを復号します。

核心は KMS キー (KEK) はデータキー (DEK) だけを暗号化し、実際のデータはデータキーが暗号化する という点です。おかげで大きなデータも KMS 呼び出し一回で処理でき、KMS のマスターキーは KMS を離れません。S3 SSE-KMS、EBS、RDS の暗号化はすべて内部的にこの方式を使います。

at rest vs in transit #

区分意味代表的な手段
保存時の暗号化 (at rest)ディスク/ストレージに書かれるときに暗号化S3 SSE、EBS 暗号化、RDS 暗号化
転送中の暗号化 (in transit)ネットワークを通るときに暗号化TLS/SSL、HTTPS

試験で「データを保存と転送の両方で保護せよ」という要件が出たら、保存は KMS ベースの暗号化、転送は TLS という 2 つの軸で答えを構成します。

S3 暗号化オプション #

S3 の保存暗号化はキーを誰が握るかで分かれます。

方式キー管理特徴
SSE-S3AWS がキー管理 (AES-256)最もシンプル。キー制御が不要なとき
SSE-KMSKMS キーを使用キー使用の監査・アクセス制御が可能
SSE-C顧客がキーを提供キーを AWS に預けない。リクエストごとにキーを渡す
クライアント側暗号化アップロード前に自分で暗号化AWS が平文をまったく見ない

「誰がオブジェクトを復号したか追跡する必要がある」なら SSE-KMS、「キーそのものを AWS に置いてはならない」という規制があるなら SSE-C またはクライアント側暗号化 が方向です。

EBS と RDS — すでに作ったリソースを暗号化する #

SAA 定番の落とし穴がここにあります。EBS ボリュームと RDS インスタンスの暗号化は 作成時にのみ有効化でき、あとからトグルで切り替えられません。 すでに作られた非暗号化リソースを暗号化するには、迂回経路が必要です。

  • EBS — 非暗号化ボリューム → スナップショット作成 → スナップショットを 暗号化してコピー → そのスナップショットから新しいボリューム作成。EBS 暗号化はボリューム・スナップショット・インスタンスとボリューム間の転送まで一緒に保護します。
  • RDS — 非暗号化インスタンス → スナップショット作成 → スナップショットを 暗号化してコピー → そのスナップショットから 新しいインスタンスへ復元。既存のインスタンスを直接暗号化するオプションはありません。

キーポリシーとクロスアカウント共有 #

KMS キーには キーポリシー (Key Policy) というリソースベースポリシーが必ず付きます。キーへのアクセスは次の組み合わせで決まります。

  • キーポリシー — キーに直接付くポリシー。デフォルトのキーポリシーはルートアカウントに全権限を与えます。
  • IAM ポリシー — キーポリシーが IAM への委任を許可している場合にのみ効力。
  • Grant — 一時的・きめ細かな権限委任。

他アカウントにキーを使わせるには、キーポリシーでそのアカウントの Principal を許可 し、相手アカウント側では IAM ポリシーでキーの使用を許可します。クロスアカウントの暗号化データ (例: 他アカウントと共有する暗号化 S3、暗号化スナップショット) は、このキーポリシー設定が抜けるとアクセスが遮断されます。

KMS vs CloudHSM #

項目KMSCloudHSM
テナンシーマルチテナント (共有)シングルテナント (専用ハードウェア)
キー制御AWS と共有管理顧客が完全に制御
標準FIPS 140-2 Level 3 検証モジュールを使用専用 HSM、FIPS 140-2 Level 3
用途ほとんどの AWS 統合暗号化規制でキーを完全に単独制御する必要があるとき

「キー素材を自社だけで制御しなければならない」「専用のハードウェアセキュリティモジュールが規制要件」という手がかりがあれば CloudHSM が答えです。それ以外のほとんどは KMS で十分です。

試験の出題パターン #

  • 「保存データを暗号化しつつ 誰が復号したか監査 しなければならない。」 → SSE-KMS (カスタマーマネージドキー)
  • 「キーを AWS に預けてはならない という規制がある。」 → SSE-C / クライアント側 / CloudHSM
  • すでに運用中の 非暗号化 RDS を暗号化するには?」 → スナップショット → 暗号化コピー → 復元
  • 「非暗号化 EBS ボリュームを暗号化するには?」 → スナップショット → 暗号化コピー → 新しいボリューム
  • 「数十 GB のオブジェクトを KMS で暗号化する原理は?」 → エンベロープ暗号化 (データキー)
  • 「他アカウントが自社の暗号化スナップショットを復元できない。」 → キーポリシーにそのアカウントの許可が抜けている

よく出会う落とし穴 #

1) KMS がデータを直接すべて暗号化すると思う #

KMS は 4KB までしか直接処理しません。大きなデータはエンベロープ暗号化でデータキーが処理します。

2) EBS/RDS の暗号化をあとから有効化できると誤解する #

作成時にのみ可能です。既存のリソースはスナップショット → 暗号化コピーの経路を通ります。

3) AWS マネージドキーのローテーションを止められると思う #

AWS マネージドキーは 1 年周期で 自動ローテーション され、止められません。ローテーション周期を制御するにはカスタマーマネージドキーを使う必要があります。

4) クロスアカウントで IAM ポリシーだけいじる #

KMS のクロスアカウントアクセスは キーポリシーの許可が先 です。キーポリシーに相手アカウントがなければ、IAM でいくら許可しても遮断されます。

まとめ #

この記事で押さえたこと:

  • KMS は リージョンサービス、直接暗号化は 4KB まで。大きなデータは エンベロープ暗号化
  • キーの種類 — AWS マネージド (制御不可、無料) vs カスタマーマネージド (制御・監査可能、月 $1)
  • S3 — SSE-S3 / SSE-KMS (監査) / SSE-C / クライアント側。キー制御の要求に応じて選択
  • EBS・RDS は 作成時のみ暗号化。既存のリソースはスナップショット → 暗号化コピー
  • クロスアカウント — キーポリシーの許可が先行、その次に IAM
  • CloudHSM — 専用ハードウェアでキーを完全に単独制御する必要があるとき

次へ — Domain 1-3 VPC セキュリティ #

データの暗号化を押さえたので、次は ネットワーク境界でのセキュリティ です。

#4 Domain 1-3 VPC セキュリティ では、セキュリティグループ (Security Group) とネットワーク ACL の違い (stateful vs stateless)、VPC Endpoint の 2 種類 (Gateway・Interface)、PrivateLink でサービスをプライベートに公開する方法、そして VPC Flow Logs と踏み台ホストまでまとめます。

X