シークレット管理

シークレットとは何か、なぜ管理が要るのか

シークレット（secret）とは、システムが他のサービスへアクセスしたり、自分自身を証明したりするために使う機密の認証情報の総称です。具体的には次のようなものを指します。

• API キー / アクセストークン：外部サービス（決済・クラウド・SaaS）を呼ぶための鍵。
• データベースの認証情報：接続ユーザー名とパスワード。
• 暗号鍵・署名鍵 / 証明書の秘密鍵：暗号化や電子署名に使う鍵。

これらが漏れると、そのシステムになりすまして外部サービスを操作されたり、データベースを丸ごと読まれたりします。つまりシークレットは「鍵束」であり、1本漏れただけで被害が連鎖し得ます。だからこそ、保管・配布・更新を体系立てて管理する必要があります。

最大のアンチパターン：コードへの直書き

シークレット管理で最初に避けるべきは、**ソースコードに値を直接書き込む（ハードコーディング）**ことです。手軽ゆえに最も頻発し、最も被害が大きい失敗です。

// 危険な例：API キーをコードに直書きしている
const apiKey = "sk_live_51H8xY2eZvK...";   // ❌ リポジトリに残り続ける

なぜ致命的かというと、コードはバージョン管理（Git）に記録されるからです。

• 公開リポジトリで即流出：GitHub 等に push した瞬間、世界中の自動スキャナに拾われます。漏洩キーは数分で悪用され始めることもあります。
• 履歴に永久に残る：後からコードを直しても、過去のコミットには値が残ったままです。git log を遡れば誰でも読めます。
• 広く共有される：fork・クローン・CI のログなど、コードが届く範囲すべてに鍵も一緒に広がります。

どこに置くか：外出しの選択肢

コードから分離したシークレットは、どこかに安全に保管する必要があります。代表的な方式を、堅牢さの順に整理します。

方式	概要	向き不向き
環境変数	プロセスの環境に値を渡す	手軽。小規模・コンテナ向け。ログ流出に注意
設定ファイル（非追跡）	.env 等をリポジトリ管理外に	環境変数の供給源。誤コミット防止が前提
シークレットマネージャ	専用サービスで集中管理	中〜大規模の本命。監査・ローテーション対応

環境変数は最も手軽な外出し先で、コンテナ環境とも相性が良い方法です。コードは process.env.API_KEY のように参照するだけで、値はコードに残りません。ただし、エラーログやデバッグ出力に環境変数を丸ごと吐く事故があるため、ログへの混入には注意が要ります。

.env ファイルを使う場合は、必ず .gitignore に追加してリポジトリ管理外にします。代わりに、値を空にした .env.example を置いて「どんなキーが必要か」だけを共有するのが定石です。

# .gitignore に必ず追加（誤コミット防止）
.env
.env.local

Vault と専用マネージャ：本命の集中管理

規模が大きくなると、環境変数だけでは「誰がどの鍵にアクセスできるか」「いつ差し替えるか」の管理が破綻します。そこで使うのが、シークレットマネージャ（HashiCorp Vault や各クラウドの Secrets Manager / Key Vault など）です。

これらは、シークレットを暗号化して一元保管し、アプリには「必要なときに」「必要な分だけ」配布します。コード側に値を埋め込む必要がなくなるのが利点です。主な機能は次のとおりです。

• アクセス制御と監査：どのアプリ・人がどの鍵を読めるかを最小権限で絞り、アクセス履歴を記録します。漏洩時の追跡に効きます。
• 動的シークレット：要求のたびに短命の認証情報を発行し、使い終われば自動で失効させる方式。長期間有効な鍵を持ち歩かずに済みます。
• 集中ローテーション：鍵の差し替えを一箇所で実行でき、各アプリへ反映されます。

ローテーションを前提に設計する

どれだけ厳重に保管しても、シークレットは「いつか漏れる」前提で扱うのが現代的な考え方です。そこで重要になるのが**ローテーション（定期的な差し替え）**です。

鍵を定期的に・自動的に更新しておけば、仮に古い鍵が漏れても有効期間が短いため被害を抑えられます。逆に「一度発行したきり何年も同じ鍵」だと、いつ漏れたかも分からないまま無期限で悪用され続けます。先述の動的シークレットは、このローテーションを極限まで進めた形です。

まとめ

シークレット管理の原則は明快で、(1) コードに直書きしない（分離する）、(2) 環境変数や Vault 等で安全に保管し、アクセスを最小権限に絞る、(3) ローテーションを前提に、漏洩しても被害を抑える設計にする——この3点に集約されます。

特に「一度コミットした鍵は無効化が必須」という点は、事故対応の鉄則として覚えておく価値があります。シークレットそのものの保護に使う暗号技術は暗号の基礎、アクセスを絞る考え方は最小権限の原則、内部資源への到達を狙う関連リスクはSSRFで深掘りできます。