Gitリポジトリに秘密情報が入ったとき：削除とキーの失効を区別

要点：リポジトリから秘密の値を消しても、発行済みキーの使用権限が自動的になくなるわけではありません。まず発行元で露出した資格情報を無効化し、使用サービスを更新してから、協力者と履歴整理の範囲を決めてください。

手順一覧

ファイル削除とアクセス権限の失効は別の作業

設定ファイルのAPIキーを削除して新しいコミットを作れば、現在のファイルには文字列が見えなくなる場合があります。しかし発行サービスのキーを失効させた意味ではありません。内容の保管場所と実際のアクセス権限を管理する場所を区別して、次の作業を決める必要があります。GitHubも露出した秘密情報はまず失効または交換するよう案内しています。

この記事は秘密情報を含むリポジトリを発見した際の対応記録と判断順序を提案します。実際のアカウントのキーやリポジトリを読んだり事故対応したりした報告ではありません。例に本物のトークンは入れず、担当者が発行元の案内と組織手順を照合して行う作業を説明します。一般原則をすべての供給者のボタン名に置き換えません。

秘密の値そのものの代わりに識別情報を書く

発見記録にはリポジトリ名、ファイルパス、該当コミットの識別情報、発見時刻とタイムゾーン、秘密情報の種類、発行元、担当者を書きます。公開説明や支援依頼に秘密の値全体をコピーしないでください。キーを区別する必要があれば発行元の名前や識別子を使い、不要に原文を別文書へ増やさない方法がよいでしょう。

似た文字列が複数なら本番用と開発用、発行サービスと権限範囲を区別します。どのキーか未確認という状態も記録できます。同じファイルにあるだけで同じキーとして扱ったり、短く見えるだけで試験用と推定したりしません。所有者を探すため伝える記録にも、アクセスできる人と必要範囲を決めてください。

最初の対応は発行元で確認する

発行サービスの管理画面と公式案内で、露出した資格情報の取消し・交換手順を確認します。新キーを作った事実と旧キーが無効になった事実は別の確認項目です。二キーが同時に有効になり得るサービスか、交換操作の効果は何かを読み、結果表示と時刻を残してください。

交換で正常なサービスが停止する危険があれば、サービス担当者と影響を調整する必要があります。露出を確認しても便宜上旧キーを残す決定を、ファイル削除で覆ってはいけません。緊急対応順序と復旧責任者を決めつつ、この記事の例の順序を特定本番環境の事故対応規程の代わりにはしません。

使用箇所を一覧にして新しい資格情報を適用する

キーを使う配備作業、自動化、サーバー設定、開発環境を一覧にします。実環境で読む設定名を確認しないと、名前だけ変わった新キーを入れ、別サービスまで更新したと誤解する可能性があります。正常動作の確認結果もサービス別に分け、未確認項目は未確認で残します。

架空のサービスAとBが同じ旧キーを使ったと仮定しましょう。Aに新キーを適用し正常なリクエストを確認しても、Bが変わったとはいえません。Bの担当者と設定場所、確認動作を別途書きます。この一覧は実際のサーバーアクセス結果ではなく、漏れを減らす説明用作業表です。

非公開リポジトリも対応範囲を検討する

GitHubは秘密情報がコミットされたら露出したと考えて対応するよう案内します。リポジトリが非公開だっただけでアクセス記録と複製を確認する必要がなくなるわけではありません。公開状況、実際にアクセスできた人、自動化、保管場所を区別して記録すると調査範囲を議論できます。

特定供給者の有効性確認機能がすべてのキー種類を検査するとは仮定しません。GitHub文書でも一部の確認・報告機能はGitHubトークンに限定されます。別サービスのキーなら発行元の手順に従ってください。検査機能がない状態を無効キーと解釈したり、外部サイトへ値を貼って試すことを一般解決策にしたりしません。

履歴整理は共同作業への影響を先に検討する

露出文字列を過去履歴から整理するか決める際は、目的と影響を先に書きます。GitHubは履歴書換えでコミットハッシュが変わり、署名へ影響し、協力者の作業消失や古い履歴の再混入の危険があると説明します。したがって現在のファイルを消す程度の変更と同様には扱いません。

ここでは強制プッシュや全参照を変更するコマンドをコピー実行させる形で提示しません。管理者と協力者が処理対象、作業停止の有無、影響作業、検証方法を合意してから公式手順を検討する必要があります。各利用者の複製やフォークまで自動整理できる期待も計画から除いてください。

整理済みの範囲と残る範囲を一緒に書く

現在ファイル、過去コミット、別ブランチ、レビュー依頼、複製など、値が残る可能性のある場所を調査表に分けます。一か所の結果を全除去完了へ拡張しないことが核心です。確認権限のない場所には、所有者へ必要な対応と結果を依頼する項目を残します。

例えば管理者が中央リポジトリの検討範囲を整理し、二人の協力者のうち一人だけの確認を受けたなら、状態は中央確認済みと複製の一部未確認です。人数が合うだけで全コピーが消えた証拠にはなりません。この架空例は記録方法を説明し、実際の事故や協力者の返答を主張しません。

ログは使用痕跡と確認の限界を一緒に読む

GitHubは供給者に応じセキュリティーログで不許可の活動を確認するよう案内します。確認可能期間、記録リクエスト種類、キー識別方法を先に決めてください。疑わしいリクエストの時刻と実行主体を残し、正常配備や担当者の試験と区別する根拠が必要です。ログが空という一文だけで事故なしと結論づけません。

ログ保持範囲が限られる、または過去記録へアクセスできなければ、その限界を調査記録に示します。実際の被害は確認資料と組織の調査結果で判断する必要があります。ここでは使用量やアクセス数を作らず、露出期間と確認期間も実記録なしで計算した事実のように書きません。

通知を閉じる前に技術対応を照合する

秘密情報スキャン通知の終了は通知管理作業です。GitHubはリポジトリからトークンを削除しても通知は自動終了しないと案内しています。対応が終わったら適切な終了理由と根拠を書いて通知を処理してください。逆に通知が閉じた事実をキー失効完了の証拠の代わりにしません。

処理記録は発行元での権限変更、各サービス更新、必要な履歴整理、ログ検討を別々につなげると読みやすくなります。担当者が完了と書いた時点と実際の確認資料の時刻が違う場合も区別できます。通知画面の項目は製品変更で変わるため、公開日に再確認する必要があります。

再発防止はコミット前の点検から始まる

GitHubは秘密情報をコードに直書きせず環境変数や秘密管理サービスを使い、コミットする変更内容を検討する方法を案内しています。実プロジェクトが値を受け取る場所を文書化し、設定例には本物の資格情報を使わないでください。新しい同僚がコピーする例まで確認すると、同じミスが繰り返される理由を減らせます。

特定ファイルを追跡しない設定と、すでに残る履歴の整理は目的が異なります。検査ツールを追加しても全秘密情報が見つかるとは保証できません。自動検査結果と人が検討した変更範囲を併記し、検査失敗時にどう止め、誰へ通知するか決めます。

新キー適用後にサービスが失敗しても旧キーを復活させない

サービスが認証エラーなら新キーの権限と使用箇所、設定名、適用環境を点検します。露出旧キーを再有効化して問題を隠す方法は対応完了に合いません。発行元の復旧案内と担当者手順で必要権限を再確認し、停止サービスと未検証サービスを一覧で区別してください。

結果は発見、無効化確認、正常サービスの検証、履歴整理範囲、残る調査項目の順に書けばよいでしょう。未対応項目を完了で埋めず、次の担当者が続ける根拠を残すことが目的です。本物のキーがなくても記録から欠けた作業と責任者を探せる必要があります。

公式情報源と確認範囲

• GitHub — リポジトリの機密データ削除と履歴書換えの影響
• GitHub — 秘密情報スキャン通知の解決

公式文書確認日：2026-10-07。公開日に再確認する項目：発行元の失効・交換動作、GitHub通知の対応範囲・メニュー、履歴整理の影響と対応ポリシー。実際のアカウント・キー・ログ状態は別途確認します。

AIによる執筆支援。本文の架空事例・数値・コマンドは説明用であり、直接実行したり試験したりした結果ではありません。実際の作業では該当環境と結果を確認してください。