AWS Secrets Manager

AWS Secrets Manager は、データベースの接続情報や外部サービスの API キーといった機密情報を安全に保管し、アプリケーションから API 経由で安全に取得するためのマネージドサービスです。機密情報の暗号化、アクセス制御、自動ローテーション、世代管理を一括して提供します。

解決する課題

アプリケーションが必要とする認証情報を、ソースコードや設定ファイル、環境変数に平文で埋め込むと、リポジトリへの漏洩や権限のないユーザーによる閲覧といったリスクが生じます。また、認証情報を定期的に変更しようとしても、複数のアプリケーションや環境に散在していると、安全な差し替えが難しく運用負荷が高くなります。

Secrets Manager は、機密情報を一元的に暗号化保管し、必要なときだけ API で取得させることで平文の散在を防ぎます。さらに認証情報を新しい値へ自動的に切り替えるローテーション機能を備え、古い値と新しい値を世代として管理するため、切り替え中の整合性も保てます。

主要概念と用語

• シークレット: 保管する機密情報の単位。キーと値のペア（JSON 形式）または任意の文字列として保存でき、メタデータやタグも付与できる。
• シークレットの値（シークレット値）: 実際に保管される認証情報そのもの。暗号化されて保存され、取得時に復号される。
• バージョン: シークレット値の世代。値を更新すると新しいバージョンが作られ、過去のバージョンも一定範囲で保持される。
• ステージングラベル: 各バージョンに付与する目印。代表的なものに現在値を指す AWSCURRENT、ローテーション中の新しい値を指す AWSPENDING、直前の値を指す AWSPREVIOUS がある。
• ローテーション: 認証情報を新しい値へ自動的に切り替える仕組み。RDS などと統合したマネージドな方式と、Lambda 関数を用いた独自方式がある。
• リソースベースのポリシー: シークレットに直接付与できるポリシー。クロスアカウントアクセスの制御などに用いる。
• KMS キー: シークレット値の暗号化に用いる鍵。AWS マネージドキーと顧客管理キーのいずれかを選べる。

仕様・制限・クォータ

• シークレットの保存形式は、複数のキーと値を持つ JSON、または単一の文字列のいずれかを選べる。バイナリも保存できる。
• 各シークレットは KMS によって暗号化される。鍵を指定しない場合は AWS マネージドキーが使われ、より細かい制御が必要な場合は顧客管理キーを指定する。
• 1 つのシークレット値のサイズには上限があり、大きなファイルの保管には向かない。サイズ上限や 1 アカウントあたりのシークレット数、API のスロットリングといった具体的な数値はリージョンや時期で変動しうるため、最新の公式クォータを確認すること。
• 削除には復元可能な待機期間（回復ウィンドウ）が設けられ、誤削除からの復旧が可能。即時削除を強制することもできるが慎重に扱う。
• リージョン単位のサービスであり、必要に応じて他リージョンへレプリケートして可用性を高められる。

内部の仕組み

シークレット値は保存時に KMS キーを使って暗号化され、取得時に呼び出し元の権限を検証したうえで復号して返されます。アプリケーションは GetSecretValue 系の API を呼び出すことで、平文の認証情報をメモリ上で受け取ります。

ローテーションは、ステージングラベルを使った世代の付け替えによって整合性を保ちます。新しい値はまず AWSPENDING ラベルが付いたバージョンとして作成され、対象システム（例: データベース）側にも反映・検証されたうえで、AWSCURRENT ラベルが新しいバージョンへ移動します。これにより、切り替えの途中でも現在有効な値が一意に定まり、取得側が不整合な値を受け取りにくい設計になっています。マネージドな方式では AWS が用意したローテーションの仕組みを利用でき、独自方式では Lambda 関数に作成・設定・テスト・確定の各ステップを実装します。

設計パターン / ベストプラクティス

アプリケーションには認証情報を直接配布せず、起動時や必要時に API で取得する設計にします。これにより、認証情報を更新しても再デプロイなしに新しい値を反映できます。

• データベースには可能な限りマネージドなローテーションを設定し、認証情報の定期的な更新を自動化する。
• IAM ポリシーで取得可能なシークレットを限定し、最小権限を徹底する。タグやリソース名の条件で対象を絞る。
• 環境ごと（本番・検証など）にシークレットを分離し、誤った環境の値を参照しないようにする。

運用・監視

シークレットに対する API 呼び出し（取得・更新・削除・ローテーションなど）は CloudTrail に記録されるため、誰がいつどのシークレットにアクセスしたかを監査できます。CloudWatch のメトリクスやイベントと組み合わせることで、ローテーションの失敗や想定外のアクセスを検知できます。

• ローテーションの成功・失敗を監視し、失敗時に通知する仕組みを用意する。
• 一定期間ローテーションされていないシークレットを棚卸しし、リスクを可視化する。
• 削除予定のシークレットや、参照されていないシークレットを定期的に洗い出して整理する。

コスト

課金は主に、保管しているシークレットの数（保管期間に応じた月額）と、API 呼び出し回数に基づきます。取得を頻繁に繰り返すワークロードではクライアント側キャッシュによって呼び出し回数を抑えることが、コスト面でも有効です。具体的な単価はリージョンや時期によって変わるため、最新の料金ページで確認してください。なお、暗号化に顧客管理キーを使う場合は KMS 側の費用も発生します。

セキュリティ

シークレット値は常に暗号化され、アクセスは IAM とリソースベースのポリシーで制御します。取得操作には専用の API 権限が必要で、KMS キーの利用権限とあわせて成立するため、二重のアクセス制御が機能します。

クロスアカウントで共有する場合は、リソースベースのポリシーと KMS キーポリシーの双方を適切に設定する必要があります。顧客管理キーを使うと、鍵の利用権限を通じてアクセスをさらに細かく制御でき、鍵の無効化によってアクセスを一括停止することもできます。

Well-Architected の観点

試験で問われるポイント

関連サービス・比較

機密情報やパラメータの保管では、Systems Manager Parameter Store と比較されることが多いです。Parameter Store は設定値の保管に広く使われ、機密値は安全な文字列として保管できますが、認証情報のマネージドな自動ローテーションは Secrets Manager の強みです。

ハンズオン / CLI例

# シークレットの作成（DB認証情報をJSONで保存）
aws secretsmanager create-secret \
  --name prod/app/db \
  --description "Production database credentials" \
  --secret-string '{"username":"app_user","password":"REPLACE_ME"}'

# シークレット値の取得（平文の取り扱いに注意）
aws secretsmanager get-secret-value \
  --secret-id prod/app/db \
  --query SecretString \
  --output text

# シークレット値の更新（新しいバージョンが作成される）
aws secretsmanager put-secret-value \
  --secret-id prod/app/db \
  --secret-string '{"username":"app_user","password":"NEW_VALUE"}'

# 回復ウィンドウ付きでの削除予約
aws secretsmanager delete-secret \
  --secret-id prod/app/db \
  --recovery-window-in-days 30