3.3暗号化とシークレット管理（KMS・Secrets Manager）

機密データは暗号化し、パスワードや API キーはコードに書かず安全に保管します。AWS では KMS（鍵）と Secrets Manager（シークレット）が要です。

3.3.1鍵とシークレット

• AWS KMS：暗号鍵を一元管理し、S3・EBS・RDS などの保管時暗号化に使う。鍵の利用は CloudTrail で監査できる。
• Secrets Manager：DB 資格情報や API キーを暗号化保管し、自動ローテーションに対応。実行時に SDK で取得する。
• SSM パラメータストア：設定値やシークレットを保管（SecureString は KMS で暗号化）。自動ローテーションは無いが安価。
• エンベロープ暗号化：データキーでデータを暗号化し、そのデータキーを KMS のマスターキーで暗号化する仕組み。

セキュリティでは「鍵の管理」と「シークレットの管理」を分けて考えます。AWS KMS は暗号鍵を一元管理し、S3・EBS・RDS などの保管時暗号化に使います。実体は エンベロープ暗号化 で、データはデータキーで暗号化し、そのデータキーを KMS のマスターキー（CMK）で暗号化します。鍵の使用は CloudTrail で監査できます。一方、DB のパスワードや API キーといった シークレット は Secrets Manager に暗号化保管し、自動ローテーションして実行時に SDK で取得します（コードや環境変数に平文で置かない）。ローテーションが不要で安価に済ませたい設定値・小さなシークレットは SSM パラメータストア の SecureString（KMS で暗号化）が向きます。要件が「自動ローテーション」なら Secrets Manager、「低コストな設定/小さなシークレット」なら Parameter Store、と切り分けます。

KMS の鍵には種類があります。AWS マネージドキー はサービスが自動管理し手軽ですが、ローテーション周期や鍵ポリシーを細かく制御できません。カスタマーマネージドキー（CMK） は自分で鍵ポリシーを定義し、年次の自動キーローテーションを有効化でき、削除前の待機期間も設定できます。誰がどの鍵で暗号化/復号できるかは鍵ポリシー＋IAM ポリシーの組み合わせで決まり、一時的に権限を委譲する グラント（Grant） も使えます。アプリ実装では、大きなデータを直接 KMS で暗号化するのではなく、データキー（GenerateDataKey） を取得してローカルで暗号化し、暗号化済みデータキーだけを保存するエンベロープ暗号化が定石です（KMS API 呼び出し回数とサイズ上限を回避できる）。Secrets Manager は内部でこの KMS を使ってシークレットを暗号化し、Lambda 連携で自動ローテーションを実現します。

3.3.2設定とフィーチャーフラグの外部化（Systems Manager・AppConfig）

シークレット以外の設定値（接続先、しきい値、機能の ON/OFF）もコードに直書きせず外部化します。AWS Systems Manager（SSM）はサーバーやアプリの運用を束ねるサービス群で、なかでも Parameter Store は設定値やシークレット参照を階層的なキーで安価に保存し、SecureString なら KMS で暗号化できます。設定を再デプロイなしに安全に変更したいときは AWS AppConfig を使います。AppConfig は フィーチャーフラグや動的設定を管理し、検証（スキーマ/Lambda バリデーター）を通したうえで段階的にロールアウトし、CloudWatch アラームに連動して異常時は自動ロールバックします。判断の勘所は「静的な設定値/シークレット参照の保存＝Parameter Store」「稼働中アプリへ動的設定/フィーチャーフラグを安全に配信＝AppConfig」「自動ローテーションする機密＝Secrets Manager」です。

3.3.3この節のまとめ

• KMS＝鍵/保管時暗号化／Secrets Manager＝シークレット＋自動ローテーション
• シークレットはコードや平文に置かず、専用サービスで管理