このガイドを使う場面
- VaultまたはクラウドのSecret Managerが組織の標準である場合
- Kubernetes、VM、ECSなどで中央ストアを共用している場合
- 運用チームがシークレットのローテーションとアクセス制御を一元管理している場合
推奨する方法
- コードには値そのものを残さず、シークレットの名前、パス、参照キーだけを記載してください。
- 起動時に、環境に合ったSDK、サイドカー、CSIドライバー、initコンテナーなどで値を取得してください。
- シークレットの登録時に、ローテーション周期、アクセスポリシー、監査ログの確認範囲も決めてください。
- ストアが対応している場合は、長期間使う固定シークレットより、動的な認証情報や短期間のトークンを検討してください。
- Google Cloud Secret Managerでは、可能ならファイルや環境変数での受け渡しより、APIによる直接取得や公式の連携方法を検討してください。
例
変更前
python
API_KEY = "sk-prod-123456"
DB_PASSWORD = "super-secret-password"
変更後
python
import os
API_KEY = os.getenv("API_KEY")
DB_PASSWORD = os.getenv("DB_PASSWORD")
実際のAPI_KEYとDB_PASSWORDは、VaultまたはSecret Managerから実行環境に注入します。この例は注入済みの環境変数を読み取るもので、ストアのAPIを直接呼び出しません。必須の値を検証し、欠けている場合は起動を中止してください。
担当者の対応手順
- 露出したシークレットを速やかに無効化し、新しい値を発行してください。
- 新しいシークレットを組織標準のストアに登録し、コードと設定ファイルから実値を削除してください。
- アプリケーションでは名前や参照値だけを使うように変更してください。
- 対応している場合は、固定シークレットを動的な認証情報に置き換えられるか確認してください。
- 新しい値でサービスが動作し、古い値が使えなくなったことを確認してください。
- 読み取り権限は、必要なサービスアカウントだけに限定してください。
担当者への案内例
- 「コード内のシークレットを削除し、VaultまたはSecret Managerに登録して、実行時に取得する構成に変更してください。」
- 「アプリケーションには参照名だけを残し、実値は中央ストアから注入してください。」
- 「露出した値は再利用せず、新しい値を発行し、移行時にアクセス権限も最小限にしてください。」
追加の確認事項
- シークレットを読むサービスアカウントに過剰な権限がないか。
- ローテーション方針があるか。
- アプリケーションのエラーでシークレットがログに出ないか。
- バージョン固定が必要な環境なのに、常に
latestを参照していないか。