パスワード漏洩時の初動対応｜変更順序・確認チェックリスト

冒頭要約

パスワード漏洩の通知を受けた、偽のログイン画面に入力した、同じパスワードの使い回しに気づいた場合は、通知内のリンクを使わず、公式アプリや保存済みブックマークから事実を確認することが最初の一歩です。漏洩通知だけでアカウント侵害が確定するわけではありませんが、放置せずに影響範囲を切り分けます。

変更は、主要メール、IdP、パスワードマネージャーなど、ほかのアカウントの回復に使えるものから進めます。その後、使い回していたアカウントを洗い出し、ログイン履歴、セッション、MFA、回復先、連携アプリ、メール転送を確認します。

この記事では、個人、情シス、開発者、SaaS管理者が安全に初動対応するための変更順序、確認方法、記録項目、エスカレーション条件を整理します。漏洩パスワードの入手方法やアカウントへの試行手順は扱いません。

現在のパスワードを外部サイトへ入力しない

漏洩確認をうたう見慣れないサイトやチャットへ、現在使用中のパスワードを入力しないでください。CyberLensのパスワード強度チェッカーを使う場合も、現在のパスワードではなく、同じ長さ・文字種の架空例だけを使用してください。

パスワード漏洩とは：通知と侵害確定の違い

「パスワード漏洩が疑われる状態」には、複数の段階があります。通知の文面だけで被害を断定せず、どの段階かを公式画面とログで確認します。

状況	現時点で言えること	最初の確認
サービスから漏洩・侵害の通知が届いた	対象データや利用者範囲に自分が含まれる可能性がある	公式サイトのお知らせ、対象期間、変更案内を確認する
ブラウザやパスワードマネージャーが漏洩候補を警告した	保存中の組み合わせが既知の漏洩データと一致した可能性がある	対象サービスと使い回し範囲を確認する
フィッシング画面に入力した	入力した情報が第三者へ渡った可能性がある	信頼できる端末へ切り替え、対象アカウントを優先対応する
身に覚えのない成功ログインや設定変更がある	アカウントが実際に操作された可能性が高い	セッション失効、ログ保全、管理者・CSIRTへの連絡を急ぐ

漏洩通知が本物か分からない場合は、メールのボタンを押さず、身に覚えのないパスワードリセットメールの確認方法と同じ考え方で公式画面へ移動します。ログイン成功の通知がある場合は、身に覚えのないログイン通知の初動対応で成功・失敗・ブロックを切り分けます。

読者別の影響：誰が何を守るか

読者	優先して守るもの	主な確認範囲
個人・社員	主要メール、金融、SNS、クラウドストレージ	使い回し、ログイン履歴、端末、回復先、MFA
情シス・CSIRT	IdP、メール、管理者アカウント、業務継続	対象者、認証ログ、セッション、権限、端末、報告範囲
開発者・DevOps	GitHub、クラウド、CI/CD、シークレット管理	リポジトリ操作、トークン、SSH鍵、クラウド監査ログ
SaaS管理者	管理者権限、共有、連携アプリ、請求・顧客情報	サインイン、OAuth同意、権限変更、転送・エクスポート

メールとIdPは、ほかのサービスのパスワードリセットやSSOに使われます。認証の起点が侵害されると影響が広がるため、単純な「利用頻度」ではなく、回復手段と権限の大きさで優先順位を決めます。

まず確認すること：パスワード漏洩の初動チェックリスト

1. 通知の出所を公式画面で確認する

通知の受信時刻、差出人、対象サービス、対象アカウントを記録する。
通知内のリンクや電話番号を使わず、公式アプリ、ブックマーク、組織のポータルから開く。
公式のお知らせ、管理画面、サポート情報に同じ案内があるか確認する。
パスワードそのものをメール、チャット、チケットへ貼り付けない。

2. 使い回しの範囲を洗い出す

同じパスワードを使ったサービスを、記憶だけでなくパスワードマネージャーや組織の台帳で確認する。
一部だけ変えた派生パスワードも同じグループとして扱う。
主要メール、IdP、金融、管理者、開発基盤、顧客情報を扱うSaaSを先に印付けする。
退会済み・休眠中でも、同じ認証情報を使っていたアカウントを確認する。

3. 成功ログインと設定変更を確認する

通知の前後を含むログイン履歴で、成功・失敗、時刻、端末、場所、アプリを確認する。
未知の端末、ブラウザ、セッション、MFA方法、回復先が追加されていないか確認する。
メール転送、受信ルール、代理アクセス、外部共有、OAuth連携に見覚えがあるか確認する。
GitHubなど監査ログがあるサービスでは、鍵・トークン・権限・リポジトリ操作の変更を確認する。

4. 端末侵害の兆候を切り分ける

偽サイトへの入力、不審なアプリや拡張機能、マルウェア警告がなかったか確認する。
端末侵害が疑われる場合は、その端末で新しいパスワードやMFAを登録せず、信頼できる別端末を使う。
組織端末は勝手に初期化せず、マルウェア感染が疑われるときの初動対応に沿って隔離・報告・証拠保全を進める。

変更順序：どのパスワードから変えるか

一度にすべてを変更できない場合は、次の順序を目安にします。組織の手順や実際の権限関係がある場合は、そちらを優先してください。

優先度	対象	先に対応する理由
1	主要メール、IdP、パスワードマネージャー	他サービスの回復、SSO、保存済み認証情報へ影響する
2	金融、決済、管理者、クラウド、GitHub、業務中核SaaS	金銭、顧客情報、システム変更への影響が大きい
3	同じ・派生パスワードを使ったサービス	クレデンシャルスタッフィングによる横展開を防ぐ
4	低影響・休眠アカウント	残存リスクを解消し、不要なら退会も検討する

新しいパスワードはサービスごとに固有にし、予測しやすい末尾変更や年号追加を避けます。NISTは、侵害の証拠がなければ定期的な変更を一律に求めず、侵害の証拠がある場合には変更を求める考え方を示しています。今回のように漏洩が疑われる場面では変更し、その後はパスワード管理の基礎に沿って固有化します。

変更後は、MFAを有効化し、可能ならパスキーなどフィッシング耐性を高めやすい方式を検討します。ただし、MFAやパスキーを追加しただけで、既存の不審なセッションや回復先が自動的に消えるとは限りません。

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

やること

信頼できる経路で公式画面を開く。 通知内リンクではなく、公式アプリやブックマークを使う。
高影響アカウントから固有のパスワードへ変更する。 主要メール、IdP、パスワードマネージャーを優先する。
全セッションを確認・失効する。 「全端末からログアウト」など、サービス公式の管理機能を使う。
回復情報とMFAを確認する。 見覚えのないメール、電話番号、認証器、バックアップコードを無効化する。
連携と後続操作を確認する。 OAuthアプリ、メール転送、共有、APIトークン、権限変更を確認する。
証拠と対応時刻を残す。 通知、ログ、変更内容、未確認事項を記録する。

パスワード変更後もセッションが残る可能性は、セッションハイジャックが疑われるときの初動対応で詳しく整理しています。サービスごとに失効範囲が異なるため、公式のセッション管理手順を確認してください。

やってはいけないこと

漏洩確認サイト、検索、AIチャットへ現在のパスワードを入力しない。
通知メールの返信先へパスワード、MFAコード、バックアップコードを送らない。
末尾の数字だけを変えたパスワードを複数サービスで再利用しない。
パスワード変更だけで、すべての端末・アプリ・トークンが失効したと決めつけない。
組織で影響範囲が不明なまま、全利用者へ無差別なリセットを実施しない。
被疑端末を初期化してから情シス・CSIRTへ報告しない。

記録テンプレート

検知・通知の日時:
通知元・確認した公式情報:
対象サービス・アカウント:
漏洩が疑われる理由:
同じ・派生パスワードを使った範囲:
不審な成功ログイン・設定変更:
パスワード変更の実施時刻:
セッション失効の実施時刻:
MFA・回復先・連携アプリの確認結果:
端末確認・隔離の状況:
保全したログ・通知:
未確認事項・次の担当者:

組織内の報告や引き継ぎには、漏えい疑い初動テンプレートを使うと、検知、封じ込め、影響確認、報告を同じ形式で管理できます。

情シス・SaaS管理者の対応

利用者から報告を受けた側は、個人のパスワード変更だけで完了にしません。

対象アカウント、権限、利用サービス、使い回しの可能性、端末を特定する。
IdPとSaaSのサインイン・監査ログを保全し、時刻をそろえて確認する。
リスクに応じてサインイン制限、パスワードリセット、セッション・トークン失効を実施する。
管理者権限、OAuth同意、外部共有、メール転送、APIトークン、回復情報を確認する。
同じ通知や不審な認証が複数利用者にないか横断確認する。
対応対象、実施者、承認者、時刻、残存リスクを記録する。

Microsoft Entra IDなどでは、パスワード変更とトークン・アプリセッションの失効範囲が同一とは限りません。製品の最新公式手順で反映範囲を確認し、必要なSaaSを個別に失効します。権限の広がりはSaaS権限棚卸しチェックリストで確認できます。

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

優先度	条件	推奨する次の行動
緊急	主要メール、IdP、パスワードマネージャー、管理者、金融アカウントが対象	信頼できる端末から変更・失効し、情シス・CSIRT・サービス窓口へ連絡する
緊急	身に覚えのない成功ログイン、MFA・回復先・権限の変更、送金やデータ操作がある	侵害疑いとしてログ保全、封じ込め、影響調査を開始する
高	フィッシング画面へ入力した、端末侵害が疑われる	被疑端末を使わず、端末対応とアカウント対応を並行する
高	複数利用者、共通パスワード、共有アカウント、高権限SaaSへ波及する	組織インシデントとして対象範囲と報告先を拡大する
中	使い回しはあるが、不審な成功ログインや設定変更は確認されていない	高影響順に固有化し、セッション・回復情報・MFAを確認する
低	警告が誤検知と公式情報・ログで説明でき、使い回しもない	根拠を記録し、監視と再通知時の報告方法を確認する

影響が読み切れない場合は、「権限が大きい」「ほかのアカウントを回復できる」「顧客・決済・ソースコードへアクセスできる」のいずれかを満たすアカウントを高優先度として扱います。

よくある誤解

「漏洩通知が来たので、すでに乗っ取られている」

通知だけでは、成功ログインや後続操作まで確定しません。一方で、通知が本物なら変更と確認を先延ばしにする理由にもなりません。公式画面とログで「漏洩の可能性」と「実際の操作」を分けます。

「強いパスワードなら使い回してもよい」

長く複雑でも、同じパスワードが1か所から漏れれば、別サービスへ横展開される可能性があります。強度と固有性は別の要件です。パスワードマネージャーを使い、サービスごとに固有化します。

「MFAを有効にしているので、漏洩したパスワードは変えなくてよい」

MFAは重要な追加防御ですが、漏洩したパスワードを使い続ける理由にはなりません。NISTが示すように、侵害の証拠がある場合は認証情報を変更し、MFA・セッション・回復情報も確認します。MFAの基礎とパスキーとパスワードの違いも参照してください。

「パスワードを変えれば、すべての端末から自動でログアウトする」

サービスやトークンの種類によって挙動が異なります。公式の端末・セッション一覧、連携アプリ、トークン管理画面で失効を確認します。

公式情報・参考情報

NIST SP 800-63B: Authentication and Authenticator Management - 侵害の証拠がある場合の認証器変更、パスワードのブロックリスト、定期変更を一律に求めない考え方を確認した。
NIST SP 800-63B: Passwords - 長さ、パスワードマネージャー、既知の漏洩パスワードを避ける設計上の考え方を確認した。
IPA: 不正ログイン被害の原因となるパスワードの漏えいに注意 - フィッシング入力や使い回しがある場合の変更、多要素認証・パスキーの利用に関する国内向け注意事項を確認した。
Google Account Help: Secure a hacked or compromised Google Account - セキュリティイベント、端末、回復情報、アプリ、メール設定を確認するGoogle公式手順。
Microsoft Support: How to recover a hacked or compromised Microsoft account - 端末侵害が疑われる場合の確認と、アカウント回復後に見る設定を確認した。
Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID - パスワード変更とセッション・トークン失効の範囲が同一とは限らないことを確認した。
GitHub Docs: Reviewing your security log - アカウント操作を公式監査ログで確認する方法を確認した。

この記事は2026年8月3日時点の公式情報を基に、製品に依存しない初動判断へ要約しています。管理画面の名称、セッション失効の範囲、回復手順は変更される場合があるため、実施時は各サービスの最新公式手順と組織の承認済み手順を確認してください。

パスワード漏洩が疑われるときの初動対応：変更順序・確認方法・使い回しチェックリスト

冒頭要約

パスワード漏洩とは：通知と侵害確定の違い

読者別の影響：誰が何を守るか