リポジトリに秘密鍵が露出したら、削除だけで終えてよいか

課題と判断基準

本番APIキーを含む設定ファイルをリポジトリへ上げてしまったらどうすべきでしょうか。ファイルを削除してコミットし、非公開に変えれば対応完了でしょうか。

いいえ。ファイルを見えなくすることと、コピーされたキーでアクセスできなくすることは別です。 GitHubも機密履歴を整理する前にシークレットを失効・交換するよう案内します。整理しても他者の複製までは回収できません。^[1]

まず露出認証情報の権限行使を止めます。次に正規の利用先を交換し、発行済みセッションと露出期間の使用を確認します。事故時の緊急遮断と通常ローテーションは別作業で、可用性のため旧キーを短時間残せるかは別判断です。^[3][6]

キーの所有者と影響する作業を特定する

通知を受けたら対応記録を作りますが、キー原文を課題・チャット・スクリーンショットへ再掲載しません。 発行者・アカウント、安全に管理する識別子、最初の露出可能時刻、発見位置、権限、実利用先を残し、確定時刻と推定を分けます。OWASPも担当者、交換方法、切断される依存関係の文書化を推奨します。^[3]

次の質問で記録を埋めます。

• 何が露出したか。 APIキー、OAuthトークン、JWT署名秘密鍵、TLS秘密鍵のどれかを発行者と用途で確認し、拡張子だけで判断しません。
• 何ができるか。 限定操作、データ参照・変更、追加認証発行まで可能か確認し、本番・開発と接続アカウントも分けます。
• どこまで広がり、どこで使うか。 公開・非公開リポジトリのアクセス範囲を分け、アプリ・worker・定期処理・CI・外部連携の担当を特定します。

責任者は調査完了まで遮断を待ちません。有効な露出認証情報は侵害された可能性があるものとして、遮断と利用先調査を並行します。^[2]

失効が先か、新キー配布が先か

OWASPの原則は迅速な失効と交換です。以下は依存関係へ適用する編集上の判断基準で、一定時間露出キーを使ってよい猶予規則ではありません。^[3]

公開本番キー、強い権限、説明できない使用がある場合は遮断が先です。 正常作業が止まっても、発行者の無効化・削除とアクセス遮断を実施する十分な根拠があります。悪用未観測だけで残しません。AWS IAMは無効化と永久削除を分けるため、効力を止めてから依存関係・削除を整理できます。^[5]

遮断方法に選択肢があり停止影響が大きい場合、限定移行期間を検討できます。新旧同時利用への対応と、移行中も露出キーの危険な経路を実際に止められるかを先に確認します。検証済み制御があり悪用兆候がない場合だけ、責任者・終了時刻・中止条件を定めて新値配布を先行します。制御が不確実、移行失敗なら旧キー使用を止めます。非公開化や監視だけでは条件を満たしません。

発行者が期限切れ・失効済みと確認した値に不要な再発行は要りません。ただし有効期間中の使用と残存セッションの調査は必要です。新キー作成自体は旧キー無効の証拠ではありません。

交換完了はリポジトリでなく実利用先で確認する

露出経路を閉じてから信頼できる管理経路で新値を配布します。保存システムだけ変えて利用先を確認しなければ記録に空白が残ります。完了証拠を次のように分けます。

新値適用の証拠には、どの版がどのサービスへ入り、再起動・再配備を行い、実業務が成功したかを記します。Web画面だけでなくworker、定期バッチ、CIなど時期の異なる経路も確認します。本番検証は所有・明示許可範囲で非破壊的に行います。

旧値遮断の証拠には発行者の管理画面・APIで確認した無効・失効状態、時刻、範囲を残します。露出キーを第三者システムに再入力して試しません。GitHub警告の終了や文字列削除は証拠の代わりになりません。^[2][5]

権限縮小は別作業です。AWS IAMではユーザー・ロールの権限を確認し、新文字列発行だけで縮小したとしません。必要操作へ方針を絞り、利用先を分けるなら身元・権限境界も設計します。^[6]

復旧も同じです。新配備の障害で露出旧キーを再有効化しません。旧コードを新認証で動かすか機能を一時停止する経路を用意します。再露出する設定・イメージへの復帰を完了と記録しません。

APIキー・トークン・署名鍵・証明書では終了条件が異なる

AWS長期キーを止めても一時セッションは別確認する

長期キーでAWS STS一時認証を発行した可能性は別調査します。AWSは一時認証の権限遮断とIAMロールセッション失効手順を提供します。ロール失効は指定時刻以前に発行したセッションを拒否し、同ロールの正常利用者・作業にも影響します。^[7][8]

元キー状態に加え、影響ロール、発行時刻、遮断ポリシーを残します。伝播遅延や他ロールへ続いたアクセスも考慮します。サービスリンクロール、IAM Identity Center管理セッションは制約・手順が違うため一律適用しません。^[7][8]

OAuthは再発行経路と発行済みトークンを分ける

Auth0は新トークン取得用refresh tokenを失効できます。ただしAPIとテナント設定により対象トークンだけか関連grantまでかが異なります。API用access tokenと本人情報のID tokenは、サーバー保存のセッションcookieと同じ方法では失効できないと案内します。^[11][12]

refresh token失効だけで既存access token、アプリ独自セッション、外部トークンまで終了と判断しません。発行者ごとに再発行遮断と既存アクセス遮断の範囲を確認し、残る有効期間と追加制御を記録します。

署名鍵のローテーションと旧鍵の信頼取消は別

Auth0の署名鍵交換は旧鍵署名トークンを直ちに無効化する処理ではなく、旧鍵失効は別段階です。アプリやAPI GatewayがJWKSを定期取得するか、証明書を手動固定するかでも作業が異なります。^[13][14]

露出署名鍵は新鍵発行だけでなく、各検証点が旧鍵を信頼しないかも確認します。正常トークン拒否や再ログインが必要になる範囲も定めます。

TLS公開証明書と秘密鍵を混同しない

公開証明書と秘密鍵は別です。Let's Encryptは発行証明書をCertificate Transparencyへ記録し、秘密鍵侵害時は証明書失効を案内します。疑われる場合の理由はkeyCompromiseです。^[15]

秘密鍵露出なら同じ鍵での再発行を解決策にせず、新鍵ペア・証明書配布・旧証明書失効を合わせて計画します。失効情報を確認するブラウザーには限りがあるため、一要求で全クライアントを即座に遮断できるとは約束しません。^[15]

Git履歴の外にも整理範囲を広げる

効力を止めた後で残る露出経路を整理します。現ブランチに加え他ブランチ・タグ・過去コミット、PR参照、fork、協力者の複製も確認します。GitHubは履歴書換えがハッシュ・署名・PR審査・他者作業に影響すると説明します。無条件のforce pushから始める作業ではありません。^[1]

CIログ、ビルドキャッシュ・イメージ、配備成果物、設定、試験データ、出力資料も対象です。Dockerはbuild引数・環境変数のシークレットが最終イメージに残り得るためsecret mount等を推奨します。現ソースが清潔でも配備済みイメージまで清潔とは言えません。^[16]

.gitignore追加も事後整理の代わりになりません。Git公式文書では追跡済みファイルに影響しないと説明されています。^[4]

除去箇所、アクセス制限箇所、直接回収不能な複製を分けて残し、外部の全コピーを削除したとは保証しません。

証拠を保全してもシークレットを再拡散しない

緊急遮断を遅らせない範囲で証拠保全を並行します。ログ整理前に制限場所へ証拠を保存し、通常チケットへ原文を貼らず位置とIDを結びます。露出ログ整理と証拠完全性を一緒に設計します。^[3]

AWS CloudTrailで要求主体と一時認証セッションを確認できますが、accessKeyIdは常に提供されるとは限りません。ロール要求には元長期キーでなく一時キーIDが残ります。一キー検索だけで調査を終えない理由です。^[9]

記録不在の理由も確認します。Event historyは地域別の直近90日管理イベントで、データイベントは含みません。画面に異常なしだけでデータ参照・流出なしとは言えません。実際に有効だったデータイベントとサービスログ保存範囲を別確認します。^[10]

影響は露出確認、説明不能使用、実被害確認、ログ不足で未確定を分けます。不審使用があれば作成認証・資源、変更権限まで調査対象にします。交換後の正常動作は過去変更を戻した証拠ではありません。

対応記録：復旧と調査終了を分ける例

以下は設計例で、IXC顧客・対応実績ではありません。公開リポジトリでアップロード用IAMキーが発見され、Web・worker・CIとアクセス可能ロールがあると仮定します。完了状態、観測結果、EV証拠IDも架空です。キー原文は使いません。

この例はサービス復旧済み、影響調査未終了です。表を全緑にするため未知を異常なしへ変えません。

次の露出が同じ障害につながらないようにする

長期キー保有の理由を減らします。AWSアプリはロールによる一時認証を優先検討し、長期キーが必要な経路には最小権限を付けます。^[6]

残るシークレットに担当・利用先・寿命・交換・失効確認方法を付けます。保存庫、最小権限、コード・ログ審査、commit・push検出を組み合わせ、警告件数削減より誰が変え何で完了を確認するかを定めます。^[3]

発行者管理権限と利用先が明確なら内部担当が公開指針で対応できます。権限が複数アカウントに及ぶ、署名鍵・派生セッション境界が不明、悪用兆候・ログ欠落で影響不明なら、セキュリティと発行者支援を早期に参加させます。新ツール購入が遮断より先である必要はありません。

最後の答えはファイル削除ではありません。何のアクセスを止め、どの利用先を復旧し、どの影響を確認し、何が未確定かを証拠とともに説明できる必要があります。