SECRET
MANAGER
秘密を、
安全に渡す仕組み
Secret Managerは、APIキーやパスワードを保管する「金庫」だけではありません。 誰が、どの秘密を、いつ取得できるかを、ID・権限・履歴と一緒に管理する仕組みです。
身元と権限を確認してから秘密を返し、その操作を監査ログへ残します。
CONTENTSこの記事の目次＋
QUICK OVERVIEW
30秒でつかむ
秘密の配布をやめる
値を一か所で管理し、必要な処理が必要な瞬間だけ取得します。
IDとIAMで制限する
誰がどのSecretを取得できるかを、ワークロード単位で決めます。
取得後は平文になる
ログ出力や過剰な権限など、アプリ側の扱いまで安全になるわけではありません。
01 — THE PROBLEM
秘密をコードに
置けない理由
パスワードをソースコードや設定ファイルに書くと、コピーされた瞬間から 「誰が持っているか」を制御できなくなります。
Gitの履歴、ビルド成果物、ログ、開発者のPC。秘密が複製される場所が増えるほど、 削除や更新は難しくなります。Secret Managerは値を一か所に集め、アプリには値ではなく 「取得する権限」を渡します。
02 — FOUR LAYERS
金庫を支える
4つの役割
暗号化だけでは、安全なSecret管理にはなりません。
暗号化して保管
保存時は暗号化され、API通信もTLSで保護されます。必要ならCloud KMSのCMEKも利用できます。
利用者の身元を確認
人間だけでなく、Cloud RunやCI/CDにもサービスアカウントなどのIDを割り当てます。
IAMで範囲を制限
Secret単位で読み取りを許可し、プロジェクト内のすべてのSecretへ広げないのが基本です。
操作を追跡
誰がVersionを追加・無効化・取得したかを監査します。値の取得はData Accessログの有効化も確認します。
03 — ACCESS FLOW
アプリが秘密を
受け取るまで
Secret Managerへ接続するための固定パスワードを、アプリへ埋め込まないことが重要です。
身元を示す
Cloud Runなどの実行環境が、サービスアカウントとして認証する。
→権限を確かめる
そのIDに対象Secretのpayloadを読む権限があるか判定する。
→値を取り出す
指定されたVersionを復号し、安全な通信経路で返す。
→操作を記録する
管理操作やデータアクセスをCloud Audit Logsで追跡できる。
production-api → database-password → secretAccessor固定キーを持たず、実行環境のIDを使って取得要求を認証します。
GitHub Actionsなどでは、長期サービスアカウントキーよりWorkload Identity Federationで短時間の認証情報を取得します。
04 — VERSION & ROTATION
値を上書きせず、
Versionを積む
Secretの値はVersionとして不変に保存し、更新時は新しいVersionを追加します。
外部サービス側で新しい認証情報を作る
Secret Managerへ新Versionを追加
アプリをVersion 7へ切り替えて確認
旧Versionを無効化してから破棄
05 — SECRET MANAGER vs KMS
秘密と暗号鍵は
役割が違う
どちらもセキュリティ製品ですが、管理する対象が異なります。
SECRET MANAGER
秘密そのもの
DBパスワードAPIキー
証明書アプリが値を取得して使う
CLOUD KMS
暗号処理の鍵
暗号化・復号署名
鍵の管理データを暗号処理する
Secret Managerの保存データも暗号化されています。追加の制御が必要な場合は、Cloud KMS上の顧客管理鍵（CMEK）を指定できます。
06 — IMPLEMENTATION
実行時にAPIから
取得する
クライアントライブラリは、実行環境に割り当てられたIDを使って認証します。
import { SecretManagerServiceClient }
from "@google-cloud/secret-manager";
const client = new SecretManagerServiceClient();
const [version] = await client.accessSecretVersion({
name: [
"projects/my-project",
"secrets/database-password",
"versions/7",
].join("/"),
});
const password = version.payload?.data?.toString();01AUTH 実行環境のIDを自動利用
02VERSION productionでは番号を固定
03MEMORY 取得後は平文として慎重に扱う
07 — SECURITY BOUNDARY
Secret Managerでも
守れないこと
取得を許可されたプロセス内では、秘密は利用可能な平文になります。
ログへの出力
値、環境変数、エラーオブジェクトを丸ごと出力すると、Cloud Loggingなどへ秘密が残ります。
過剰なIAM権限
プロジェクト全体にAccessorを与えると、そのIDはすべてのSecretを取得できます。Secret単位を基本にします。
侵害されたアプリ
アプリ自体が乗っ取られれば、そのアプリに許可されたSecretは取得される可能性があります。
latestへの無条件追従
新Versionの問題が全インスタンスへ即時波及します。本番ではVersion番号を固定して段階的に切り替えます。
08 — SAME PATTERN, DIFFERENT CLOUDS
クラウドが変わっても
考え方は同じ
名称は違っても、「Secret・Identity・Policy・Audit」の組み合わせで捉えられます。
IN ONE SENTENCE
Secret Managerとは？
秘密を暗号化して保管し、IDとIAMで必要な相手だけに渡し、その操作を追跡する仕組み。
SOURCES / GOOGLE CLOUD OFFICIAL