Cloud Service
AWS KMS
暗号鍵を集中管理するサービス。S3/EBS/RDS等と統合し、鍵のアクセス制御・自動ローテーション・利用監査を提供。
中級SCS-C02SAA-C03SOA-C02SAP-C02セキュリティ
最終更新: 2026-05-31公式ドキュメント ↗
TL;DR要点だけ先に
- 1.暗号化の鍵を安全に作成・管理・監査する金庫。S3/EBS/RDS等と統合。
- 2.エンベロープ暗号化を採用。誰がいつ復号したかをCloudTrailで追跡。
- 3.鍵の管理がKMS、パスワード等の値はSecrets Managerと役割が別。

解決する課題
- データを暗号化したいが、鍵の管理が大変
- 鍵のアクセス制御・ローテーション・監査を統制したい
- 各サービスの暗号化を一元的に扱いたい
主要概念と用語
- KMSキー(CMK): AWS管理キー / カスタマー管理キー
- エンベロープ暗号化: データキーで暗号化し、その鍵をKMSで暗号化
- キーポリシー / グラント: 鍵ごとのアクセス制御
- 自動ローテーション: 定期的に鍵を更新
- CloudHSM: 専用ハードウェアが必要な場合
仕様・制限・クォータ
- 各AWSサービスの「SSE-KMS」等と統合
- リージョン単位(マルチリージョンキーも可)
- API呼び出しに対するスロットリング上限
内部の仕組み
KMSはエンベロープ暗号化を使います。実データは高速なデータキーで暗号化し、そのデータキー自体をKMSのマスターキーで暗号化して保管。復号時はKMSにデータキーの復号を依頼します。鍵の利用はCloudTrailに記録され、誰がいつ復号したかを監査できます。
KMS と Secrets Manager の違い
KMS=「鍵」の管理、Secrets Manager=「シークレット値(パスワード/APIキー)」の保管・自動ローテーション。役割が別。
設計パターン / ベストプラクティス
- 統制が要るデータはSSE-KMS(監査・細かい制御が可能)
- カスタマー管理キー+自動ローテーション
- キーポリシーで最小権限、用途別に鍵を分割
運用・監視・トラブルシュート
- 鍵の利用はCloudTrailで監査
AccessDenied時はキーポリシー/IAM/グラントを確認- スロットリング時はデータキーキャッシュを検討
コスト
- 鍵ごとの月額+APIリクエスト課金
- データキーキャッシュでKMS呼び出しを削減
セキュリティ
- 最小権限のキーポリシー、用途分離
- 多リージョン要件はマルチリージョンキー
- FIPS/専用HW要件はCloudHSM
Well-Architected の観点
- セキュリティ: 保存データ保護・鍵管理・追跡可能性の中核
試験で問われるポイント
頻出
- SSE-KMS=鍵の監査+細かいアクセス制御(SSE-S3との違い)
- KMS(鍵)vs Secrets Manager(シークレット値)
- エンベロープ暗号化・自動ローテーション・CloudTrail監査
📝 KMS ミニ確認テスト第 1 問 / 全 3 問
暗号化キーの作成・管理・ローテーション・利用監査を一元化するサービスは?
関連サービス・比較
| サービス | 守るもの | 主な用途 |
|---|---|---|
| KMS | 暗号鍵 | S3/EBS/RDS等の暗号化と鍵管理 |
| Secrets Manager | シークレット値 | DB資格情報/APIキーの保管・自動ローテーション |
| CloudHSM | 専用HWの鍵 | FIPS等の厳格要件 |
ハンズオン / CLI例
# カスタマー管理キーを作成し自動ローテーションを有効化
aws kms create-key --description "app data key"
aws kms enable-key-rotation --key-id <key-id>
# S3バケットのデフォルト暗号化をSSE-KMSに
aws s3api put-bucket-encryption --bucket my-bucket \
--server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"<key-id>"}}]}'
AWS Service
AWS KMSを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
セキュリティ・ID
比較で見る軸
クラウド: AWS / カテゴリ: セキュリティ・ID / 難易度: intermediate
導入後に効く点
エンベロープ暗号化を採用。誰がいつ復号したかをCloudTrailで追跡。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
数字・仕様の読み方
- クラウド
- AWS
- カテゴリ
- セキュリティ・ID
- 難易度
- intermediate
- 関連資格
- SCS-C02 / SAA-C03 / SOA-C02 / SAP-C02
- 設計柱
- security
判断チェックリスト
- 自社の用途が「セキュリティ・ID / security」に近いか確認する。
- 強みである「暗号化の鍵を安全に作成・管理・監査する金庫。S3/EBS/RDS等と統合。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
他クラウドの同等サービス
役割が近いサービスです。設計の置き換えや比較検討の参考に。