AWS Certified Developer - Associate (DVA-C02) #8 Domain 2-2 セキュリティ — 暗号化とシークレット
#7 認証と認可 で「誰がアクセスするか」を整理したので、次は データと秘密値そのものをどう保護するか です。DVA の暗号化は「パスワード・API キー・DB 認証情報をコードと環境変数に平文で置かない」という一つの原則に圧縮されます。
KMS — キー管理 #
Key Management Service (KMS) は暗号化キーを作成・管理するサービスです。ほとんどの AWS サービスが KMS と統合して保存データを暗号化します。
| キーの種類 | 管理主体 | 特徴 |
|---|---|---|
| AWS マネージドキー | AWS | サービスが自動生成・管理 (aws/s3 など)。無料 |
| カスタマーマネージドキー (CMK) | ユーザー | キーポリシー・ローテーション・削除を直接制御。監査・細かい制御 |
| AWS 所有キー | AWS | 複数のアカウントが共有、見えない |
カスタマーマネージドキー はキーポリシーで誰がキーを使えるかを制御し、CloudTrail でキーの使用を監査し、自動ローテーション (年 1 回) を有効にできます。「誰がいつデータを復号したかを監査する必要がある」の答えはカスタマーマネージドキー (または SSE-KMS) です。
エンベロープ暗号化 (Envelope Encryption) #
KMS で大容量のデータを直接暗号化しません。KMS API は 4KB までしか直接暗号化できないからです。代わりに エンベロープ暗号化 を使います。
- KMS に
GenerateDataKeyをリクエストして データキー を受け取ります (平文 + 暗号化版のペア)。 - 平文のデータキーで 実際のデータをローカルで暗号化 します。
- 平文のデータキーはメモリから消し、暗号化されたデータキーをデータの隣に保存 します。
- 復号のときは暗号化されたデータキーを KMS に送り、
Decryptで平文のキーを受け取ってデータを解きます。
エンベロープ暗号化の要点: KMS は小さなデータキーだけを扱い、大きなデータはそのデータキーでローカルで暗号化 します。大容量暗号化の問題で「KMS で直接暗号化」は通常不正解です。
at rest vs in transit #
- at rest (保存データ) — S3・EBS・RDS・DynamoDB の保存時暗号化。たいてい KMS 統合。
- in transit (転送データ) — TLS/SSL。ACM (Certificate Manager) で証明書を発行・管理。
S3 サーバー側暗号化 #
S3 の保存時暗号化オプションは試験の常連です。
| オプション | キー管理 | 特徴 |
|---|---|---|
| SSE-S3 | S3 が管理 (AES-256) | 最もシンプル。デフォルト |
| SSE-KMS | KMS キー | 使用監査 (CloudTrail)・キーポリシー制御。キーごとの権限 |
| SSE-C | 顧客がキーを提供 | 顧客がキーを直接渡し、AWS は保存しない |
| クライアント側暗号化 | 顧客がアップロード前に暗号化 | AWS は暗号文だけを見る |
「誰が復号したかを監査」が必要なら SSE-KMS、シンプルなら SSE-S3、キーを AWS に絶対に預けたくないなら SSE-C またはクライアント側暗号化です。
Lambda 環境変数の暗号化 #
#2 で見たとおり、環境変数は保存時に暗号化されます。より強い保護が必要なら KMS カスタマーマネージドキーで暗号化 し、転送中の露出を防ぐために「転送中の暗号化ヘルパー」でデプロイ時点に暗号化できます。ただし 機密性の高い秘密値は環境変数ではなく Secrets Manager・Parameter Store からランタイムに読む のが推奨です。
Secrets Manager vs Parameter Store #
秘密値・設定値をコードの外に置く 2 つのサービスの違いは必ず覚える必要があります。
| 区分 | Secrets Manager | Parameter Store (SSM) |
|---|---|---|
| 主な用途 | 秘密値 (DB 認証情報、API キー) | 設定値 + 秘密値 (SecureString) |
| 自動ローテーション | 内蔵 (RDS などと統合) | なし (自前で Lambda 実装が必要) |
| コスト | シークレットごとに有料 | 標準パラメータは 無料、Advanced は有料 |
| サイズ・階層 | シークレット中心 | 階層型パス (/app/db/host) |
| 統合 | クロスサービスの自動ローテーション | 単純な保存・取得 |
核心となる決定: 自動ローテーション (rotation) が必要なら Secrets Manager、単純な設定値かコストが重要なら Parameter Store です。「RDS 認証情報を定期的に自動ローテーション」の答えは Secrets Manager です。「コストなしで設定値を階層的に保存」の答えは Parameter Store の標準パラメータです。
Parameter Store は Secrets Manager のシークレットと KMS キーも参照できるので、2 つを一緒に使うこともあります。ただし「自動ローテーション内蔵」は Secrets Manager だけの機能です。
試験の出題パターン #
- 「DB 認証情報を定期的に自動ローテーション。」 → Secrets Manager。
- 「設定値を無料で階層的に保存・取得。」 → Parameter Store の標準パラメータ。
- 「パスワードを Lambda にどう渡すか。」 → Secrets Manager/Parameter Store からランタイムに取得 (環境変数の平文ではない)。
- 「誰が S3 オブジェクトを復号したかを監査。」 → SSE-KMS。
- 「大容量ファイルを KMS で暗号化しようとする。」 → エンベロープ暗号化 (データキーを使用)。
- 「キーを AWS に絶対に保存せず S3 暗号化。」 → SSE-C またはクライアント側暗号化。
- 「転送中の暗号化証明書を管理。」 → ACM。
よく出会う落とし穴 #
1) Parameter Store に自動ローテーションがあると誤解する #
自動ローテーション内蔵は Secrets Manager です。Parameter Store は自前で実装する必要があります。
2) KMS で大容量を直接暗号化する #
KMS の直接暗号化は 4KB の上限です。大きなデータはエンベロープ暗号化です。
3) シークレットを環境変数の平文で #
環境変数は暗号化されていても、機密性の高いシークレットはシークレットストアから読むのが推奨です。
まとめ #
この記事の要点:
- KMS — AWS マネージド vs カスタマーマネージド (監査・制御)。直接暗号化は 4KB の上限
- エンベロープ暗号化 — KMS のデータキーで大きなデータをローカル暗号化
- SSE-KMS は復号の監査が可能、SSE-S3 はシンプル、SSE-C は顧客キー
- Secrets Manager (自動ローテーション内蔵) vs Parameter Store (無料・階層・ローテーションなし)
- シークレットはコード・環境変数の平文ではなく シークレットストアからランタイムに取得
次へ — Domain 3-1 CI/CD #
セキュリティを終えました。次は 24% を占めるデプロイです。#9 CI/CD では、CodeCommit・CodeBuild・CodeDeploy・CodePipeline・CodeArtifact の役割分担と buildspec.yml・appspec.yml、そしてパイプラインの構成を見ていきます。