TL

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と役割が別。
AWS KMS のアーキテクチャ図
AWS KMS の構成イメージ

解決する課題

  • データを暗号化したいが、鍵の管理が大変
  • 鍵のアクセス制御・ローテーション・監査を統制したい
  • 各サービスの暗号化を一元的に扱いたい

主要概念と用語

  • 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

セキュリティ・IDsecuritySCS-C02SAA-C03SOA-C02

他クラウドの同等サービス

役割が近いサービスです。設計の置き換えや比較検討の参考に。