Secret Manager

解決する課題

APIキー・データベースのパスワード・トークンといった機密値を、ソースコードや環境変数、設定ファイルに直書きしてしまうと、リポジトリの漏えいや権限の広がりから一気に流出します。Secret Manager はこうした機密値を専用の保管庫に集約し、暗号化・アクセス制御・バージョン管理・監査をマネージドに提供します。

• 認証情報をコードや設定ファイルに直書きしたくない（誤コミットによる漏えいを防ぐ）
• 機密値のアクセス制御と利用監査を組織として統制したい
• パスワードやキーの**ローテーション（差し替え）**を、アプリを止めずに行いたい
• どのアプリ・サービスアカウントがどのシークレットを読めるかを最小権限で管理したい

主要概念と用語

• シークレット（Secret）: 機密値を入れる論理的な入れ物。名前・ラベル・レプリケーションポリシーなどのメタデータを持ち、値そのものは保持しない
• シークレットバージョン（SecretVersion）: 実際の機密値（ペイロード）を持つ単位。値を更新するたびに新しいバージョンが連番で追加される（追記型で、過去バージョンは上書きされない）
• バージョンの状態: 各バージョンは有効、無効、破棄のいずれか。無効化で一時停止、破棄で値を恒久的に消去できる
• エイリアス latest: 最新の有効バージョンを指す特別な参照。本番ではバージョン番号を固定する運用も推奨される
• レプリケーションポリシー: 値を保存するロケーションの方針。Google が自動で複数リージョンに複製する自動レプリケーションと、対象リージョンを利用者が指定するユーザー管理レプリケーションがある
• アクセス（access）操作: シークレットのペイロード（値）を実際に読み取る操作。メタデータの参照とは別の権限で制御される
• Secret Accessor ロール: シークレットの値を読み取るための代表的な IAM ロール。アプリのサービスアカウントには原則これだけを付与する

仕様・制限・クォータ

• 暗号化: 保存時は既定で暗号化される。組織のコンプライアンス要件に応じて Cloud KMS の CMEK（顧客管理の暗号鍵） を使い、暗号鍵を利用者管理に置き換えることもできる
• バージョンは追記型: 値の更新は新バージョンの追加であり、既存バージョンは上書きされない。これによりロールバックや差し替えの履歴管理が容易
• ペイロードサイズ: 1 バージョンに格納できる値にはサイズ上限がある。証明書やキーファイルなど比較的大きめのものは入るが、巨大なファイルやデータベース本体の保管には向かない
• ロケーション: グローバルなエンドポイントに加え、特定リージョンに保存・処理を限定するリージョン版も利用できる。データ所在地（データレジデンシー）要件がある場合に選ぶ
• クォータ: アクセス（読み取り）等の API 呼び出しには QPS のレート上限があり、必要に応じて引き上げ申請が可能。高頻度アクセスは値のキャッシュで呼び出しを削減する
• 課金対象: 後述のとおり、アクティブなシークレットバージョン数とアクセス操作数が主な課金軸

内部の仕組み

シークレットは「メタデータを持つ入れ物（Secret）」と「実際の値を持つバージョン（SecretVersion）」に分かれています。値の取得は必ず特定のバージョン（または latest エイリアス）に対する access 操作として行われ、この操作と管理操作は Cloud Audit Logs に記録されます。

• 値は保存時に暗号化され、access 操作のときだけ復号して返されます。CMEK を構成した場合、その暗号鍵の管理・ローテーション・監査を Cloud KMS 側で握れます
• レプリケーションポリシーに従って値が複数ロケーションに複製され、可用性と耐久性が確保されます。自動レプリケーションは運用が簡単、ユーザー管理レプリケーションは保存先リージョンを明示的に制御できます
• バージョンは追記型で連番管理されます。古い値の無効化・破棄、新しい値の追加といったライフサイクル操作を通じて、アプリを止めずに機密値を差し替えられます

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

• 認証情報はコードや設定ファイルに直書きせず、実行時に Secret Manager から取得する。CI/CD やコンテナのビルド成果物にも値を焼き込まない
• アプリのサービスアカウントには原則 Secret Accessor のみを、対象シークレット単位で付与し、管理権限と読み取り権限を分離する
• 本番では latest をそのまま使うのではなく特定バージョンに固定し、検証後に参照バージョンを切り替える（誤った値が即時に本番へ波及するのを防ぐ）
• ローテーションは新バージョン追加 → アプリ側の参照切り替え → 旧バージョンの無効化 → 破棄の順で段階的に行う
• データレジデンシー要件があればリージョン版やユーザー管理レプリケーションを選び、強い統制が必要なら CMEK を併用する
• 高頻度に読むアプリは取得した値をアプリ内でキャッシュし、過剰な access 呼び出しとコストを抑える

運用・監視

• シークレットの access（値の読み取り）・追加・破棄は Cloud Audit Logs で監査する。Data Access ログは明示的な有効化が必要なことに注意
• 値が読めず PERMISSION_DENIED になる場合は、呼び出し元サービスアカウントへの Secret Accessor ロール付与と、対象シークレット（またはプロジェクト）のスコープを確認する
• 参照しているバージョンが無効化・破棄されていないか、latest が想定どおりの有効バージョンを指しているかを確認する
• ローテーション後は古いバージョンを即破棄せず、いったん無効化して問題なければ破棄する運用が安全
• 高頻度アクセスでレート上限に当たる場合は、値のキャッシュ間隔を延ばして access 呼び出しを削減する

コスト

課金は「アクティブなシークレットバージョン数（月額）」と「アクセス（access）操作などの API 呼び出し数」が主な軸です。さらに、自動・ユーザー管理いずれのレプリケーションを使うか、保存ロケーションの数によってもコスト感が変わります。一定の無料枠が用意されており、小規模な利用では費用が小さく収まる傾向があります。

セキュリティ

• アクセスはシークレット単位で IAM により最小権限化する。アプリには値を読む Secret Accessor、管理者には作成・破棄を行う管理ロール、というように役割を分離する
• プロジェクト全体にまとめて読み取り権限を付与せず、個別シークレット単位でバインドして影響範囲を絞る
• 強いコンプライアンス要件には CMEK を構成し、暗号鍵の管理・ローテーション・監査を Cloud KMS 側で統制する。データ所在地要件にはリージョン版を使う
• 値の破棄は不可逆なため、ローテーション時はまず無効化で一時停止し、安全を確認してから破棄する
• 組織ポリシーや IAM 条件を併用し、誤って広い読み取り権限が付かないようガードレールを敷く

Well-Architected の観点

• セキュリティ: 機密値を一元保管し、IAM による最小権限、CMEK による暗号鍵統制、Cloud Audit Logs による監査で、認証情報の漏えいと権限の広がりを抑える
• 運用の優秀性: バージョン管理とローテーションにより、アプリを止めずに機密値を差し替え・ロールバックでき、認証情報のライフサイクルを標準化できる
• 信頼性: レプリケーションにより値の可用性と耐久性を確保し、参照バージョンの固定で誤った値の即時波及を防ぐ

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# シークレットを作成（自動レプリケーション）
gcloud secrets create db-password \
  --replication-policy automatic

# 値（バージョン）を追加。標準入力からパイプで渡す例
printf "S3cr3t-P@ssw0rd" | gcloud secrets versions add db-password \
  --data-file -

# アプリのサービスアカウントに、このシークレットの読み取り権限のみを付与
gcloud secrets add-iam-policy-binding db-password \
  --member "serviceAccount:app@PROJECT_ID.iam.gserviceaccount.com" \
  --role roles/secretmanager.secretAccessor

# 最新の有効バージョンの値を取得（latest エイリアス）
gcloud secrets versions access latest \
  --secret db-password

# 特定バージョンを明示して取得（本番はバージョン固定が推奨）
gcloud secrets versions access 1 \
  --secret db-password

# ローテーション後、古いバージョンをまず無効化（破棄は安全確認後）
gcloud secrets versions disable 1 \
  --secret db-password