SSH秘密鍵漏えい時の初動対応

冒頭要約

SSH秘密鍵がGitリポジトリ、共有ストレージ、CI/CDログ、バックアップ、退職者端末などへ露出した疑いがある場合、秘密鍵ファイルを削除しただけでは接続権限は無効になりません。対応する公開鍵がサーバーやサービスに残っていれば、コピー済みの秘密鍵から認証される可能性が残ります。

最初に、鍵のフィンガープリント、所有者、露出場所、利用アカウント、接続先、権限を記録します。次に、その公開鍵を受け入れる場所を特定し、authorized_keys、Gitホスティング、クラウドのOS Login・メタデータ、踏み台、CI/CD、ネットワーク機器などから無効化します。

この記事では、開発者・SRE、情シス、SaaS管理者、CSIRTが、検知後の最初の15分、鍵の無効化、影響確認、新しい鍵への交換、エスカレーションへ進む順番を整理します。漏えい鍵で接続を試す方法や、認証を悪用する手順は扱いません。

SSH秘密鍵をチケットや解析サービスへ貼らない

鍵の種類や有効性を確認する目的でも、秘密鍵をチャット、メール、チケット、AIサービス、オンライン変換・解析サイトへ貼り付けないでください。識別と共有には、公開して差し支えない公開鍵のフィンガープリント、鍵タイトル、所有者、登録先を使います。

SSH秘密鍵の漏えいとは

SSHの公開鍵認証では、利用者側が秘密鍵を保管し、接続を許可する側が対応する公開鍵を登録します。OpenSSHでは、一般的にサーバー上のauthorized_keysが公開鍵の受け入れ先になります。GitHubのユーザーSSH鍵やDeploy Key、クラウドのOS Login・メタデータ鍵も、役割は異なりますが「どの公開鍵を受け入れるか」を管理する場所です。

対象	主な役割	漏えい疑い時の考え方
ユーザー秘密鍵	人がサーバーやGitサービスへ接続するための認証情報	対応する公開鍵を全接続先から無効化し、新しい鍵へ交換する
Deploy Key・自動化用秘密鍵	CI/CDや配布サーバーが特定リポジトリ・ホストへ接続する	読み取り・書き込み権限、利用ジョブ、共有範囲を確認して登録先で無効化する
サーバーのホスト秘密鍵	接続先サーバーが正しい相手であることを利用者へ示す	ユーザー鍵とは対応が異なる。ホスト鍵交換と利用者側の信頼情報更新を計画する
SSH証明書の秘密鍵	SSH認証局や証明書利用者が署名・認証に使う	静的公開鍵とは失効方式が異なる。SSH CA、証明書期限、失効リストの運用に従う
公開鍵・フィンガープリント	接続許可の登録と鍵の識別に使う	公開される前提。単独で見つかっても秘密鍵漏えいとは限らない

この記事の中心は、利用者または自動化が持つSSH秘密鍵です。サーバーのホスト秘密鍵やSSH CA秘密鍵が漏えいした場合は、信頼する側への影響が広くなるため、通常のユーザー鍵より高い優先度で専門担当へエスカレーションします。

暗号技術の基礎と共通鍵暗号と公開鍵暗号の違いを先に読むと、公開鍵を共有できても秘密鍵を守る必要がある理由を整理できます。

読者別の影響：誰が何を確認するか

読者	最初に確認すること	主な責任範囲
開発者・SRE	鍵のフィンガープリント、Gitホスティング、踏み台、サーバー、CI/CD	公開鍵の無効化、新しい鍵への交換、認証・操作ログの確認
情シス	所有者、端末、退職・異動、サーバー台帳、委託先	接続先の全量把握、端末隔離、アカウント・権限の見直し
SaaS・Git管理者	ユーザーSSH鍵、Deploy Key、監査ログ、Organization・リポジトリ権限	登録鍵の削除、書き込み権限確認、想定外の鍵追加・操作確認
クラウド管理者	OS Login、IAM、プロジェクト・インスタンスメタデータ、踏み台	認可経路ごとの無効化、sudo相当権限、クラウド監査ログの確認
CSIRT・SOC	露出期間、取得可能性、接続・操作・権限変更の証跡	優先度判断、証拠保全、調査範囲、経営・法務・委託先への連携

同じ秘密鍵を人とCI/CDで共有している場合や、複数環境へ登録している場合は、所有者の個人アカウントだけを見ても影響範囲を確定できません。鍵そのものを起点に、受け入れ先と権限を追跡します。

まず確認すること：最初の15分チェックリスト

1. 発見した事実を記録する

発見日時、発見者、通知元、インシデント番号。
秘密鍵が見つかった場所、公開範囲、閲覧できた人・システム。
露出開始の候補時刻と、最後に安全を確認できた時刻。
ファイル削除、リポジトリ非公開化、端末隔離など、すでに実施した操作。
秘密鍵そのものではなく、ファイル名、保管場所、公開鍵のフィンガープリント、鍵タイトル。

Publicリポジトリや不特定多数が閲覧できる場所に露出した場合は、取得履歴が見つからなくても、第三者がコピーした可能性を前提に優先度を上げます。

2. 鍵の種類・所有者・権限を特定する

人が使うユーザー鍵か、CI/CD・デプロイ・バックアップが使う自動化用鍵か。
公開鍵のフィンガープリント、鍵タイトル、作成時期、所有者。
root、sudo、管理者、書き込み、デプロイ、本番アクセスを持つか。
接続元IP、強制コマンド、利用時間、対象ホストなどの制限があるか。
同じ秘密鍵を複数人、複数端末、複数環境で共有していないか。
鍵と同じ場所にAPIキー、トークン、クラウド認証情報もなかったか。

フィンガープリントは鍵の照合に使う識別情報です。ファイル名やコメントは変更できるため、それだけで同じ鍵と判断しません。

3. 公開鍵を受け入れる場所を洗い出す

Linux・Unixサーバーのユーザー別authorized_keysと、集中管理される公開鍵設定。
GitHubなどのユーザーSSH鍵、Organization、リポジトリのDeploy Key。
Google CloudのOS Login、プロジェクトメタデータ、インスタンスメタデータ。
踏み台・Bastion、VPN装置、ネットワーク機器、ストレージ、バックアップ装置。
CI/CD、構成管理、デプロイサーバー、ホスティング・委託先。
開発、検証、本番、災害復旧、旧環境、停止中のサーバー。

静的SSH鍵には、公開TLS証明書のようにどの接続先にも共通する一つの失効手続きがありません。公開鍵を受け入れる各場所で、対応する鍵またはアクセス権を無効化する必要があります。

4. 端末・保管場所の侵害可能性を判断する

鍵が平文で公開されたのか、端末のマルウェア・情報窃取が疑われるのか。
秘密鍵のパスフレーズが設定されていたか、同時に漏れた可能性があるか。
SSH Agent、開発ツール、パスワード保管庫、バックアップへ鍵が複製されていないか。
端末で不審なプロセス、EDRアラート、ブラウザセッション、認証情報流出がないか。
紛失端末や退職者端末から回収できていない鍵ではないか。

端末侵害が疑われる場合、新しい鍵を同じ端末で作ると再び取得されるおそれがあります。ネットワーク隔離と証拠保全を判断し、信頼できる端末で交換作業を行います。

5. 認証・監査ログを保全する

SSH認証の成功・失敗、接続時刻、送信元、利用ユーザー。
踏み台、VPN、クラウド、ネットワーク機器の接続・監査ログ。
GitHubのSSH鍵・Deploy Keyの追加と削除、リポジトリ操作、権限変更。
sudo相当の操作、新規ユーザー、新しい公開鍵、スケジュール処理、サービス変更。
ログ保存期間、タイムゾーン、時刻同期、欠損、転送先。

Audit Logに記録がないことだけで、不正利用なしとは判断できません。該当期間を保持していたか、すべての接続経路を確認したか、「異常なし」と「確認できない」を分けて記録します。

初動対応：やること、やらないこと、記録すること

やること

鍵のフィンガープリント、所有者、露出範囲、接続先、権限を特定する。
対応する公開鍵を受け入れる全場所で、鍵またはアクセス権を無効化する。
端末侵害が疑われる場合は隔離し、信頼できる端末から管理作業を行う。
SSH認証、踏み台、クラウド、Git、CI/CD、権限変更のログを保全する。
信頼できる環境で新しい鍵ペアを作成し、必要最小限の接続先へ登録する。
正規の利用者・ジョブが新しい鍵へ移行したことを確認し、旧鍵が残っていないか再点検する。
漏えい経路、共有運用、長期鍵、過剰権限を是正し、所有者と期限を記録する。

封じ込めを急ぐ一方で、共有鍵を無計画に削除すると復旧作業や監視を止める可能性があります。高権限・公開露出・不審接続がある場合は無効化を優先し、業務影響と代替経路を責任者と並行判断します。

やってはいけないこと

漏えいした秘密鍵でサーバーやGitサービスへ接続し、有効性を試さない。
秘密鍵をチケット、チャット、メール、AIサービス、オンライン解析サイトへ貼らない。
ローカルの秘密鍵ファイルだけを削除し、接続先の公開鍵を残さない。
パスフレーズを変更すれば、第三者が持つ秘密鍵コピーも無効になると考えない。
同じ秘密鍵や、侵害が疑われる端末で作った新しい鍵を再利用しない。
ユーザーアカウントを停止しただけで、メタデータ鍵やローカル鍵もすべて失効したと判断しない。
記録を残さずにログ、リポジトリ履歴、端末、ユーザーを削除・初期化しない。
不審なログインが見つからないことを、秘密鍵が取得されていない証明にしない。

記録すること

公開鍵のフィンガープリント、鍵種別、鍵タイトル、所有者、利用目的。
秘密鍵の保管場所、露出場所、共有先、作成・配布方法。
接続先、アカウント、環境、付与権限、公開鍵の登録場所。
発見、隔離、無効化、ログ保全、新鍵登録、旧鍵削除、復旧の各時刻。
認証・監査ログの確認期間、タイムゾーン、確認者、結果、未確認事項。
顧客・業務への影響、委託先、エスカレーション先、次の判断期限。

接続先別：SSH鍵をどこで無効化するか

接続先・方式	無効化する対象	追加で確認すること
OpenSSHサーバー	対応するユーザーの公開鍵登録、集中管理された鍵情報、必要に応じてアカウント	root・sudo権限、同じ鍵の別ユーザー登録、新しい鍵・ユーザー・永続化設定
GitHubユーザーSSH鍵	アカウントのSSH鍵登録	Organization・リポジトリ操作、想定外の鍵追加、トークン・OAuthアプリ
GitHub Deploy Key	対象リポジトリのDeploy Key登録	書き込み権限、同じ鍵を使うリポジトリ、CI/CDジョブ、秘密情報
Google Cloud OS Login	OS Loginプロフィールの公開鍵またはIAMによるログイン権限	OS Login Admin権限、外部IdPとCloud Identity双方のアカウント状態
Google Cloudメタデータ鍵	プロジェクトまたはインスタンスのSSH公開鍵メタデータ	アカウント停止では鍵が残る点、プロジェクト全体への影響、root相当権限
踏み台・管理サービス	サービス内の公開鍵、ユーザー、接続ポリシー	下流サーバーへの到達範囲、セッション記録、承認・時間制限
SSH証明書	証明書、プリンシパル、CA・失効リストの運用	証明書の期限、署名CAの侵害有無、信頼先全体への影響

GitHubはユーザーSSH鍵とDeploy Keyを別々に管理します。Google Cloudも、OS Loginとメタデータ鍵で認可と無効化の仕組みが異なります。製品名だけで一括判断せず、実際の登録方式を確認してください。

アカウント停止だけでは残る鍵がある

Google Cloudの公式資料では、メタデータ鍵は削除されるまで有効で、ユーザーアカウントの停止・削除だけでは無効にならないと説明されています。一方、OS Loginは接続のたびにIAMを評価します。自組織の方式を確認し、鍵とアカウントの両方を点検してください。

影響確認：どこまで調べるか

1. 認証された可能性

漏えい期間中のSSH認証成功・失敗と、通常と異なる送信元・時間帯。
踏み台、VPN、IAP相当の中継経路と、直接接続の両方。
Gitサービスのclone、push、設定変更、Deploy Key・Webhook・Secret変更。
ログ欠損、時刻ずれ、監査設定の無効化、保存期間外の空白。

秘密鍵がパスフレーズで保護されていても、安全と断定はできません。パスフレーズの強度、同時露出、端末侵害、SSH Agentの利用状況を含めて判断します。

2. 接続後に行われた可能性

sudo・root相当の操作、設定変更、サービス再起動、ソフトウェア追加。
新規アカウント、公開鍵追加、権限昇格、定期実行、永続化設定。
ソースコード、設定、環境変数、顧客データ、バックアップへのアクセス。
APIキー、トークン、秘密鍵、クラウド認証情報など二次的なsecretの取得。
ログ削除、監視停止、転送先変更、想定外の外部通信。

SSH認証の成功は「接続できた」ことを示しますが、その後の操作は別のログや証跡に分かれる場合があります。認証ログだけで調査を終えず、OS、クラウド、Git、CI/CD、アプリケーションの証跡をつなげます。

3. 鍵の再利用と共有範囲

同じ公開鍵のフィンガープリントが別サーバー、別ユーザー、別リポジトリにないか。
本番・検証・開発、委託先、災害復旧環境で同じ秘密鍵を使っていないか。
個人鍵を共有アカウントや自動化へ流用していないか。
退職・異動後も鍵が残っていないか。
バックアップ、VMイメージ、コンテナ、設定管理に古い鍵が残っていないか。

接続先が不明な場合は、「使われていない」と結論づけず、高優先度の未確認事項として扱います。

判断基準：危険度とエスカレーション条件

優先度	条件	推奨する判断
緊急	公開場所へ露出、第三者取得の痕跡、不審なSSH認証・push・権限変更がある	直ちに全接続先で無効化し、端末隔離・証拠保全・CSIRT招集を進める
緊急	root・sudo・本番・顧客データ・署名CAへ到達できる鍵である	サーバー侵害を含む調査へ広げ、経営・法務・サービス責任者と影響を判断する
高	書き込み可能なDeploy Key、共有鍵、複数環境・委託先で使う鍵である	全登録先を棚卸しし、二次secretとサプライチェーンへの影響を確認する
高	所有者、接続先、露出期間、ログのいずれかが不明	不明点を安全の根拠にせず、無効化と調査範囲の拡大を優先する
中	閲覧範囲が限定され、全接続先を特定でき、不審な証跡がない	鍵交換・ログ確認・記録を完了し、長期鍵と共有運用を改善する
低	ダミー鍵・未登録鍵で、実環境に一度も認可されていないことを複数の情報で確認できた	判断根拠を記録し、誤配置・検知・廃棄手順を改善する

次のいずれかに当てはまれば、開発者やサーバー担当だけで閉じずにエスカレーションします。

顧客・従業員情報、決済、契約上の機密、本番デプロイに関係する。
root・sudo・管理者、書き込み、署名、秘密情報の取得が可能である。
端末マルウェア、情報窃取、退職者・委託先アカウントの侵害が疑われる。
同じ場所からAPIキー、トークン、クラウド認証情報、別の秘密鍵も見つかった。
接続先、所有者、露出期間、ログ保存状況を確定できない。
不審な認証、鍵追加、ユーザー作成、権限変更、push、ログ欠損がある。
複数組織、委託先、顧客環境へ影響する可能性がある。

復旧確認と記録テンプレート

復旧は「新しい鍵で接続できた」だけでは完了しません。接続先ごとに次を確認します。

旧公開鍵または旧アクセス権が、全接続先で無効になっている。
正規の利用者・ジョブだけが、新しい鍵で必要な範囲へ接続できる。
新しい鍵の所有者、用途、登録先、権限、期限が台帳へ記録されている。
SSH認証、踏み台、クラウド、Git、CI/CD、OS操作のログ確認結果が残っている。
不審な公開鍵、ユーザー、権限、定期実行、サービス変更がない。
端末・保管庫・CI/CD・バックアップから旧秘密鍵の複製が除去または隔離されている。
未確認事項、顧客・業務影響、再発防止、次回確認日が責任者に引き継がれている。

インシデント番号:
発見日時・発見者:
検知元・露出場所:
閲覧可能だった範囲:
鍵種別・利用目的:
公開鍵フィンガープリント:
鍵タイトル・所有者:
利用アカウント・権限:
接続先・公開鍵の登録場所:
端末侵害の確認結果:
旧鍵の無効化先・時刻・実施者:
新しい鍵の作成環境:
新しい鍵の登録先・権限:
認証・監査ログの確認期間:
不審な認証・操作・変更:
旧秘密鍵の削除 / 隔離結果:
顧客・業務への影響:
未確認事項:
エスカレーション先・判断者:
次回確認日時:

よくある誤解

「秘密鍵ファイルを削除すれば失効する」

誤りです。第三者がすでにコピーしていれば、そのコピーは残ります。対応する公開鍵を受け入れるサーバー、Gitサービス、クラウド、踏み台などで認可を無効化します。

「パスフレーズを変更すれば、漏えいした秘密鍵も使えなくなる」

第三者が持つ秘密鍵コピーには反映されません。パスフレーズは秘密鍵ファイルを保護する重要な対策ですが、漏えい疑いでは新しい鍵ペアへ交換し、旧公開鍵を無効化します。

「ユーザーアカウントを停止すれば、SSH鍵もすべて失効する」

方式によります。Google CloudのOS Loginのように接続時にIAMを評価する仕組みもあれば、メタデータやローカルのauthorized_keysに登録された静的鍵のように、別途削除が必要な仕組みもあります。

「GitHubからSSH鍵を削除すれば、サーバーへのSSH接続も止まる」

GitHubの登録と自組織サーバーの登録は別です。同じ公開鍵を複数の場所へ登録している場合、それぞれの受け入れ先で無効化します。

「公開鍵が見つかったので、秘密鍵漏えいである」

公開鍵は共有される前提の情報です。公開鍵だけの発見は、直ちに秘密鍵漏えいを意味しません。ただし、所有者不明の公開鍵が接続先へ登録されている場合は、不正なアクセス経路の可能性として確認します。

「認証ログに異常がなければ不正利用されていない」

ログ保存期間、接続経路、時刻同期、監査設定によって確認できる範囲が変わります。「異常なし」と「ログがなく確認できない」を分け、権限変更やGit操作など周辺ログも確認します。

再発防止：長期鍵と共有鍵を減らす

人の鍵と自動化用鍵を分け、所有者と用途を一つに限定する。
最小権限で、対象ホスト、リポジトリ、読み書き、sudo相当権限を絞る。
使い終わった鍵を定期的に棚卸しし、退職・異動・委託終了時に接続先から削除する。
可能な環境では、短命な鍵、SSH証明書、OS Login、JITアクセス、ハードウェア保護鍵を検討する。
秘密鍵をリポジトリ、コンテナイメージ、共有ドライブ、CI/CDログへ残さない。
Secrets Managementの台帳に、所有者、登録先、権限、期限、交換手順を記録する。
認証・監査ログの保存期間と時刻同期を確認し、鍵追加・削除・高権限接続を検知できるようにする。

新しい仕組みの導入だけでなく、「どの鍵が、どこへ、何の権限で接続できるか」を説明できる状態を維持することが再発防止の中心です。

目的	ページ
用語を確認する	Secrets Management、最小権限、Audit Log、Evidence Preservation
初動対応を実務へ落とす	情報漏えい疑い初動テンプレート、GitHub Secret漏えいチェックリスト
鍵の違いを整理する	共通鍵暗号と公開鍵暗号の違い、暗号技術の基礎
関連する初動対応を読む	TLS証明書の秘密鍵漏えい時の初動対応、サービスアカウントキー漏えい時の初動対応、紛失した会社PC・スマホの初動対応、インシデント時の証拠保全
知識を確認する	セキュリティクイズ

公式情報・参考情報

OpenBSD Manual Pages: sshd(8) - OpenSSHサーバーが公開鍵認証に使うauthorized_keysの形式、鍵ごとの制限、ホスト鍵の扱いを確認できる。
GitHub Docs: Reviewing your SSH keys - ユーザーアカウントへ登録されたSSH鍵を監査し、不明または侵害疑いの鍵を削除する公式手順。
GitHub Docs: Reviewing your deploy keys - リポジトリへ登録されたDeploy Keyを監査し、不明または侵害疑いの鍵を削除する公式手順。
GitHub Docs: Audit log events for your organization - SSH鍵・Deploy Keyの追加や削除を含むOrganization監査ログイベントを確認できる。
Google Cloud: Restrict SSH keys from VMs - OS Login、プロジェクトメタデータ、インスタンスメタデータに登録された公開鍵を削除する方法を確認できる。
Google Cloud: Best practices for controlling SSH login access - OS Loginとメタデータ鍵で、認可評価とアカウント停止時の挙動が異なることを確認できる。
NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management - 暗号鍵の保護、ライフサイクル、侵害を含む鍵管理全般の指針。
NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - 検知、対応、復旧を組織のサイバーセキュリティリスク管理へ組み込むための指針。

まとめ

SSH秘密鍵が漏えいした疑いがある場合は、ローカルの鍵ファイルではなく、対応する公開鍵を受け入れる場所を起点に対応します。鍵のフィンガープリント、所有者、接続先、権限、露出範囲を記録し、サーバー、Gitホスティング、クラウド、踏み台、CI/CDごとに旧鍵を無効化します。

そのうえで、認証・監査・操作ログを保全し、信頼できる端末で新しい鍵を作成します。「パスフレーズを変えた」「ユーザーを停止した」「GitHubから削除した」の一つだけで、すべての接続先が失効したとは限りません。

実作業を始める場合は、情報漏えい疑い初動テンプレートへ時系列を記録し、リポジトリやCI/CDでの露出確認にはGitHub Secret漏えいチェックリストを併用してください。

SSH秘密鍵が漏えいした時の初動対応：鍵の無効化・接続先確認・ログ調査

冒頭要約

SSH秘密鍵の漏えいとは

読者別の影響：誰が何を確認するか