先に読むと理解しやすい記事:トークン・APIキー・Bearer認証 / 共通鍵暗号・公開鍵暗号
持っているだけで操作や復号ができる値を守る
秘密情報には、データベースのパスワード、秘密のAPIキー、トークン、署名用や復号用の秘密鍵などがあります。これらが漏れると、その値に与えた操作権限や復号能力を第三者が利用できるおそれがあります。
管理は保存する場所を決めるだけでは終わりません。誰が生成し、どの処理へ渡し、いつ更新し、不要になったらどう使えなくするかまでを含みます。公開鍵や公開前提の識別子とは、必要な保護が異なります。
参照:出典 s1
コードと秘密の保存先を分ける
アプリのコードへ秘密の値を直接書くと、ソースを読める人や配布先がその値を取得できます。サーバーのシークレット管理機能などへ保存し、必要な処理だけが読み出せるアクセス権を設定します。
環境変数は設定の受け渡し方法の一つで、自動的に暗号化や秘密保持を保証するものではありません。実行環境の診断出力や子プロセスへの継承で漏れる場合があります。.envをGitの対象外にすることも有効ですが、配布物やバックアップへの混入は別に確認します。
参照:出典 s1
ブラウザへ配る値は利用者から隠せない
サーバーのビルド時に秘密を環境変数から読み、ブラウザ用JavaScriptへ埋め込むと、配布されたファイルから値を取り出せます。環境変数へ入れていたという保存方法だけでは、配布後の秘密を守れません。
たとえば書き込み用APIキーを含む画面を公開すると、攻撃者はその値でAPIを呼び、キーの権限内でデータを書き換えられます。秘密を使う処理はサーバーへ置き、サーバーが呼び出し元の認証・認可も確認します。
参照:出典 s1
環境と処理ごとに権限を絞る
開発環境に本番データの削除キーを渡す必要がなければ、渡しません。読み取りだけの処理には読み取り専用の認証情報を使い、サービスや環境ごとに値を分けます。一つの漏えいで使われる権限の範囲を小さくします。
自動ビルドでも、外部投稿のコードを実行する段階と本番デプロイの認証情報を使う段階を設計します。同じ環境で前の処理が後の実行ファイルを書き換えられると、後の処理に渡した秘密を盗むコードが動くおそれがあります。単に最初の段階で秘密を渡さないだけでは足りない構成もあります。
参照:出典 s1
新しい秘密を配ることと旧値を止めることを分ける
ローテーションは認証情報や鍵を新しい値へ交換することです。正常な更新では、新しい値を準備し、利用する処理を切り替え、旧値を無効にして、切り替え漏れがないか確認します。新旧を同時に受け付ける期間を設ける場合もあります。
暗号化用の鍵では、古いデータの復号に旧鍵が必要な場合があります。署名鍵やAPIキーの失効と同じ手順で削除すると、データを読めなくするおそれがあります。鍵の用途と保存済みデータへの依存を確認します。
Gitから消すだけでは漏えい対応にならない
秘密を誤って公開したら、まず発行元で旧値を失効させ、新しい値へ差し替えます。ファイルの最新行から削除しても、Git履歴、取得済みのコピー、ログなどに残るため、古い秘密が使えないことが重要です。
その値で可能だった操作と利用履歴を調べます。資料やエラー通知に秘密が入っていた場合も、表示を消すだけで終わらせません。権限と公開範囲に応じて対応を判断します。
参照:出典 s1
秘密を読める人と処理を列挙する
確認問題:秘密の保存場所が暗号化されていれば、全開発者へ読み出し権限を与えてよいでしょうか。答えは違います。正規の読み出し権限を持つ相手からの漏えいもあり得ます。
各秘密について、用途、持つ権限、読む人と処理、期限、失効手順を確認します。監査記録には利用した事実を残し、秘密の実値は残さないようにします。
参照:出典 s1
出典・確認範囲
- [s1] Secrets Management Cheat SheetOWASP / 確認日 2026-11-03
- [s2] Cryptographic Storage Cheat SheetOWASP / 確認日 2026-11-03
通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。