2026年10月8日に、GitHubの機密データ削除ガイドとpush protectionの現行資料を再読しました。secretが漏れた場合は履歴を書き換える前にrevokeまたはrotateを優先し、履歴書換えではclone・fork・キャッシュ・commit hash・共同作業への影響を管理します。push protectionはCLI、GitHub UI、ファイル upload、REST APIなどのpushを検査して止められますが、設定、プラン、検出パターン、bypassの扱いに依存します。削除やpush protectionだけで鍵の利用停止や漏えいゼロを保証するものではありません。
動作確認のために発行したAPIキーを、コードへ直接書く。そのまま共同作業や自動テストへ広がり、どのファイルに残っているか分からなくなる。シークレット管理は、こうした作業の流れの中で、秘密が必要な場所と不要な場所を分ける仕事です。
注意する人を増やすだけでは、ログ、ビルド成果物、Gitの履歴まで毎回見渡すのは難しくなります。この記事では、値を分離する、流出を検出する、漏れたときの利用を止めるという3つの備えを組み合わせます。この分け方は本記事の整理であり、OWASPが命名した「3層構造」ではありません。
30秒で要点
- キーをコードから外しても、環境変数、ログ、配信用JavaScriptへ漏れる経路は残る。
- スキャンの対象・設定・例外を確認し、「導入した」ことと「検出できた」ことを分ける。
- 漏洩時は失効・更新を優先する。通常の更新手順と、疑わしい鍵を止める対応は分けて用意する。
守る値と、公開を前提とする値を区別する
APIはシステム同士が機能やデータをやり取りするための窓口で、すべてのAPIがキーによる認証を要求するわけではありません。APIキーなどの認証情報は、その窓口で許された操作を行うための資格として扱います。
この記事で守る対象は、秘密として扱うAPIキー、アクセストークン、パスワードを含むDB接続情報、秘密鍵・署名鍵、Webhookの検証用シークレットです。一方、発行元が公開可能と定義している識別子や設定値を、名前にkeyがあるだけで一律に秘密とは判定しません。値の名称より、発行元の仕様と、その値だけで何ができるかを確認します。
備え1：コードと秘密の値を分ける
ソースコードには設定名や参照方法を置き、秘密の値は別の管理経路から渡します。小さなローカル開発でも、サンプル設定には架空の値だけを置き、実際の値を含むファイルと分けます。チームや本番環境では、アクセス制御や利用記録を含め、秘密管理サービスなどの運用方法を選びます。
ただし、.envは暗号化保管庫ではありません。環境変数も、プロセス、ログ、例外情報、ダンプなどを通じて露出する可能性があります。OWASPも環境変数による注入の限界を挙げています。必要なプロセスだけへ渡し、値そのものをログやエラー応答へ出さない設計と組み合わせます。
gitignoreは、すでに追跡しているファイルを守らない
.gitignoreは、追跡していないファイルをGitの通常の追加対象から外す指定です。Git公式マニュアルにも、追跡済みファイルには影響しないと明記されています。過去に追加した秘密、履歴、強制追加、別名ファイル、チャットやログへの転記まで防ぐものではありません。
そのため、「除外ルールがあるか」と「秘密入りファイルを追跡していないか」は別々に確認します。設定ファイルを削除するだけでは過去のコピーの利用を止められないので、実際の漏洩が疑われる場合は後述の失効対応を先に考えます。
ブラウザへ渡す設定と、サーバーの秘密を分ける
Next.jsでは、process.env.NEXT_PUBLIC_変数名のように静的に参照する公開変数は、ビルド時にブラウザへ配るJavaScriptへ展開されます。変数名を動的に組み立てる参照などは同じ展開になりません。公開してよい設定用であり、秘密のAPIキーを置く場所ではありません。Next.jsの環境変数の説明
公開接頭辞が付いていなくても、アプリが値をレスポンスへ含めたりログへ出したりすれば漏れます。サーバーで代理呼出しする場合も、呼出し元の認証・権限、許可した操作、利用量の制御が必要です。「サーバーに置いた」だけで、誰でも使える中継窓口を安全にはできません。APIの認証と操作境界はAPI設計のベストプラクティスも参照してください。
備え2：どの段階で、何を検出するかを決める
コミット前の確認、push時の保護、リポジトリの履歴スキャンには、それぞれ異なる対象があります。新しい差分だけを見るものと、過去の内容まで見るものは同じではありません。検出ルールにない形式や、例外として扱われた値が通る場合もあります。
GitHubのpush protectionにも、対象となる経路、個人向けとリポジトリ向けの設定、例外や回避の扱いがあります。自分の契約・リポジトリでどの保護が有効かを確認し、サービス名を導入しただけで全経路が守られるとは判断しません。
表が収まらない場合は、横にスクロールできます
| 確認する境界 | 知りたいこと | 合格に読み替えないこと |
|---|---|---|
| 作業ディレクトリ | 値を直接書いた箇所がないか | 文字列検索で見つからないから秘密がない |
| コミット対象 | 追加する差分を検出できるか | 未追加ファイルや過去履歴も確認した |
| push・共有 | 検出時に停止し、担当へ通知されるか | 別の共有経路も防いでいる |
| 履歴・成果物 | 過去の漏れや配布物が対象か | 他人のコピーまで消せる |
検出を試すときは、ツールが提供する安全なテスト用素材や、秘密として機能しない固定のダミー文字列を使います。実キーを検出試験のために公開したり、結果をチャットへ貼ったりしません。単なるダミー値が検出されなかったことから、実キーも通るとは結論できない点にも注意します。
備え3：権限と有効期間を狭め、止められるようにする
読み取りだけで足りる用途に、書込みや削除まで許す必要はありません。可能なら環境や用途ごとに分け、共有された一つのキーで全作業を行う状態を避けます。発行元が短い有効期間や細かい権限を提供していない場合は、その限界も含めて利用範囲を考えます。
秘密の値を列挙する台帳は不要です。代わりに、発行元、用途、管理責任者、使用する環境、権限、失効方法、更新担当、最終確認日など、値そのものを含まない管理情報を持ちます。担当者の異動や障害時にも、どこで止めるかが分かるようにするためです。
通常の更新は、切替えと確認まで設計する
通常のローテーションは、古いキーを新しいキーへ切り替える運用です。発行元が新旧の併存を許すなら、新キーを発行し、必要な利用先へ配り、動作を確認し、旧キーを失効させる順序を計画できます。併存できないサービスなら、停止の影響や切替え手順を別に設計します。
一律に何日ごとと決めるより、秘密の種類、有効期間、権限、発行元の仕様に合わせます。暗号化鍵では、旧データの復号に古い鍵が必要な場合もあり、APIキーと同じ感覚で削除してはいけません。秘密管理サービス自体が止まったときの連絡先や復旧手順も用意します。
漏れたときは、利用を止める判断を先にする
漏洩が疑われる場合、通常の更新完了を待つだけでは、不正利用が続く可能性があります。責任者へ知らせ、影響とサービス停止のリスクを踏まえつつ、該当資格を失効・更新する対応を優先します。新キーを用意しただけで旧キーが無効になるとは限らないため、発行元で利用不能を確認します。
GitHubも、秘密を履歴から除去する前の第一歩として失効・更新を説明しています。機密データをリポジトリから除去する際の注意
同時に、値を複製しない形で発見時刻、対象の識別情報、利用状況、対応を記録します。必要なログを保全し、請求や操作の不審点を確認します。履歴の書換えには共同作業者やコピーへの影響があるため、失効とは別の作業として調整します。履歴変更は共同作業者と調整し、ほかの変更や参照を壊さないように進めます。
最小の確認は、値を見せずに一つの用途を追う
対象を一つの開発用連携に絞り、次の項目を確認します。調査に使える権限がない項目は未確認と記録し、安全と推定しません。15分で始める整理にはできますが、環境の監査を15分で終えられるという意味ではありません。
- 発行元が秘密と定義する値か、何の操作を許すかを確認する。
- 保管先からアプリへ渡る経路を、設定名だけで図にする。
- Gitの追跡状態、配布物、ログ出力の確認担当を決める。
- スキャナーの対象と例外、検出時の通知先を確認する。
- 通常更新と漏洩時の失効について、担当者と手順の場所を確認する。
検出機構を導入する人、コードを書く人、発行元でキーを止められる人が違う場合、受け渡しも一度確認します。個人開発でも、読み取りに限定できるか、使わない資格が残っていないか、失効手順を自分で実行できるかは判断材料になります。
注意を怠らないことと、ミスが起きても広がりにくい設計は両立できます。認証と認可の基礎とつなぎ、値を隠すだけでなく、利用できる操作と止める責任までを管理してください。