>
>
公開日
社員のパスワード漏洩が分かった情報システム部門向けに、流出の確認方法と当日の初動を解説します。使い回し型とインフォスティーラー型を切り分け、端末隔離、セッション・トークン失効、OAuth連携の解除まで整理。SSO外の業務アカウントや委託先も含めた影響範囲の調査と再発防止に役立ちます。
パスワード漏洩とは
パスワード漏洩とは、秘密に管理すべきパスワードが第三者に知られたり、外部に流出したりすることです。対象は、会社の業務アカウントを管理する情報システム部門の担当者・管理者です。本記事では、パスワードが第三者に知られた事実を「漏洩」、データが外部に出た経路や状態を「流出」と書き分け、パスワードに加えてCookieやトークンを含む総称を「認証情報」と呼びます。社員のパスワード流出や認証情報の漏洩への対応は、本人への変更案内だけで終えず、利用サービスと認証後のアクセスまで含めて進めます。個人情報全般の流出対応や個人利用アカウントの対処ではなく、業務で使うアカウントの調査とアクセス管理を扱います。
本記事のポイント
漏洩確認と利用サービスの調査を並行して進めます
パスワード変更だけでなくセッションや連携認証も対処対象です
端末感染が疑われる場合は隔離を先行します
SSO外と委託先のアカウントも調査対象です
セッションはログイン後の認証状態を維持する仕組みで、連携認証は別の認証基盤を使ってサービスにログインする仕組みです。SSOは、一度の認証で複数のサービスを利用するシングルサインオンを指します。漏洩の疑いがあれば、認証の入口だけでなく、すでに成立したアクセスも調査対象に含めます。パスワードを変更した事実だけで対応完了と判断しないことが、調査の出発点です。会社で把握しているサービスに加え、SSOに接続していないサービスや、委託先が業務で利用するアカウントも対象に整理します。
パスワード漏洩による被害と侵入経路
パスワード漏洩への対応は、使い回しによる不正ログインと、端末からの認証情報窃取を分けて進めます。盗まれた対象がパスワードなのか、ログイン済み状態を示す情報まで含むのかによって、調査の起点と初動が変わります。
使い回しによる業務アカウントへの侵入
使い回し型では、他サービスから流出したIDとパスワードが、業務サービスへのログインに悪用されます。流出元が社外のサービスでも、同じ組み合わせを業務で使っていれば、業務アカウントへの侵入につながります。
デジタル庁は、本人確認ガイドラインの検討資料（本人確認ガイドライン改定の有識者会議の2024年12月5日付資料）で、他サービスから漏洩したID・パスワードによるログイン試行を攻撃の例に挙げ、使い回しにくいIDや知識以外の認証要素といった対策例を示しています。該当する場合は、流出元だけでなく使い回し先も対応対象にします。攻撃手口の詳細はパスワードリスト攻撃の解説に譲ります。
インフォスティーラーによる認証済み状態の窃取
インフォスティーラーとは、端末内の情報を盗むマルウェアです。パスワードだけでなく、ログイン済み状態の維持に使われるCookieや、認証・アクセスに使われるトークンも窃取対象になり得ます。
盗まれたCookieやトークンが悪用されると、利用者が多要素認証であるMFAを済ませた後でも、その認証済み状態を使ってアクセスされる場合があります。これはMFA全般が無意味という意味ではなく、認証後の状態も保護対象になるという違いです。感染が疑われる場合は、パスワード変更だけで対応完了とせず、端末への対処と既存セッションの失効を扱います。
比較軸 | 使い回し型 | インフォスティーラー型 |
|---|---|---|
主な流出対象 | ID・パスワード | 端末内のパスワード、Cookie、トークン |
調査の起点 | 流出した認証情報の使い回し先 | 感染が疑われる端末と利用アカウント |
最初の対応 | 使い回し先を含むパスワード変更 | 疑わしい端末の隔離とセッション失効 |
変更後も残る確認事項 | 不審なログインと変更漏れ | 感染の残存と既存セッションの有効性 |
端末感染の疑いがあるなら、パスワード変更とは別に端末対応を進めます。次の初動では、この違いを基にアカウント側と端末側の対応を切り分けます。
▲ パスワード使い回し型とインフォスティーラー型における流出対象と初動対応の比較。
自社のパスワード流出の確認方法と検知の限界
自社のパスワード流出は複数の手段で確認しますが、検知がないことだけでは安全と判断できません。認証基盤、ドメイン検索、保存済みパスワード、商用監視の結果を分けて読み、各手段の管理範囲外を調査課題として残します。
確認手段 | 確認対象 | 結果の意味 | 見えない範囲 | 検知後の対応 |
|---|---|---|---|---|
IdPの漏えい検知 | 認証基盤の管理対象 | その基盤の検知条件に該当したことを示します | 基盤に連携していない認証情報です | 対象者と検知内容を調べます |
ドメイン検索 | 検索対象ドメインのメールアドレス | 収録された漏洩情報との関連を示します | 別ドメインや未収録の情報です | 対象者と登録先サービスを調べます |
パスワードマネージャーのレポート | 管理対象に保存された情報 | 保存情報に対する警告を示します | 保存されていない認証情報です | 警告の種類と該当サービスを調べます |
商用監視 | 契約・設定で指定した監視対象 | 監視先で対象情報を検知したことを示します | 監視対象外や未収集の情報です | 通知の対象者とサービスを調べます |
IdPの漏えい検知
IdPとは、複数のサービスで使う認証を集約する基盤です。ここでの確認は、集約した認証情報を調べる経路として位置付け、連携していないサービスまで確認済みにしない運用にします。
運用上は漏洩の検知と自動修復を別の確認項目として扱い、自動修復の適用を確認できなければ、検知後の対応を担当者に割り当てます。
ドメイン単位と保存済みパスワードの確認
ドメイン検索とパスワードマネージャーのレポートは、確認対象が異なる補助手段として使い分けます。メールアドレスが漏洩情報に含まれるという結果を、現在使っているパスワードの流出確定と同一視してはいけません。
Have I Been Pwnedを使う場合、調査記録では、実際に確認したメールアドレスと検索結果の範囲を分けて残します。
IPAが公開するSCS評価制度の「★3・★4 要求事項・評価基準 解説書」（2026年10月28日）は、漏えいを早く把握する方法の例として、パスワード管理アプリの漏えいチェック機能と、Have I Been Pwnedなどの検索サイトでの定期的な確認を挙げています。レポートを使う場合も、調査対象は管理下に保存された情報とし、未保存の業務アカウントまで点検できたとは判断しません。
商用監視と管理範囲外の調査
商用監視は追加の検知経路として利用し、すべての流出を把握できる手段とは扱いません。契約上の監視対象と、実際の業務利用の範囲を切り分けます。
SSOの外にあるSaaS、個人メールで登録した業務利用、委託先ドメインは、同じ手段で一括把握できるとは限りません。これらは「検知なし」ではなく「当該手段では未確認」と記録し、利用アカウントの洗い出しは最終章の台帳調査に集約します。
漏洩を検知した場合は、対象者とサービスの調査へ進み、認証情報の変更などの初動対応につなげます。
検知がなくても、不審なログインや端末感染の兆候があれば、初動対応を継続します。
検知も兆候もない場合は、確認した範囲と管理範囲外を分けて記録し、安全確認の完了とは扱いません。
兆候がある場合は検索結果を待たず、初動対応へ進みます。
漏洩が分かった日の初動と感染疑いの分岐
漏洩判明時は利用サービスを特定してアクセスを遮断し、端末感染が疑われる場合は隔離を先行します。情シスが対応を取りまとめ、対象者とサービス管理者で作業を分担します。
検知直後の記録と連絡
検知直後は、通知内容と判明時刻を記録し、対応窓口を一本化します。対象者だけでパスワード変更を進めず、情シスとサービス管理者が対応状況を共有する運用にします。
記録する項目は、検知通知の原文、対象者、判明時刻、身に覚えのないログインや設定変更などの侵害兆候です。情シス、対象者、サービス管理者の連絡先をまとめ、必要に応じて社内インシデント対応担当も加えます。作業者・実施時刻・結果を残し、担当間の引き継ぎに使います。
フェーズ | 実施内容 | 担当 | 完了の判断 |
|---|---|---|---|
検知・連絡 | 通知・対象者・時刻・兆候の記録と連絡 | 対象者・情シス | 対応窓口と記録先を共有済み |
原因の切り分け | 使い回し先の特定、感染疑いなら端末隔離 | 情シス・対象者 | 変更に使う安全な端末を確保済み |
アクセス遮断 | セッション失効、認証情報・設定への対処 | 情シス・サービス管理者 | 対象ごとの実施結果と未対応を記録済み |
調査・再開 | ログ・端末の調査と残る制約の整理 | 情シス・サービス管理者・必要に応じた社内対応担当 | 再開範囲と継続調査の担当を決定済み |
使い回し型と感染疑いの分岐
使い回しだけが確認された場合と、端末感染が疑われる場合では、パスワード変更前の対応を分けます。原因を判別できない段階では感染疑いを除外せず、端末調査を並行する運用にします。
使い回しだけが確認され、感染の兆候がない場合は、漏洩したパスワードと同じものを使うサービスを洗い出し、それぞれ異なるパスワードへ変更します。
感染が疑われる場合は、対象端末をネットワークから隔離し、安全な別端末で認証情報を変更します。対象端末で変更を続ける運用は避け、再窃取の防止とサービス側のアクセス遮断を並行して進めます。
原因不明なら、安全な別端末でサービスへの対処を進め、疑わしい端末の隔離・調査も並行します。アクセス遮断は原因の確定を待たずに進めます。
認証手段と利用サービスへの対処
サービス側の共通対応は、利用先の特定からアクセス遮断、連携認証の整理へ進めます。感染疑いがある場合は、端末隔離と安全な別端末の確保を先行させます。
SCS評価制度の★3の評価基準（No.4-1-6-2）は、パスワードの漏えいが判明した場合、又はその疑いがある場合に、速やかに変更するための手順を定めることを求めています（IPAの解説書）。実務では、変更作業に加えて次の順で対応状況を管理します。
対象者の利用SaaSを特定します。クラウド経由で使う業務サービスを、対象者への聞き取りと管理情報から洗い出します。
セッションを失効させ、パスワードを再設定します。ログイン状態の失効をサービスごとに実施し、変更作業と分けて記録します。
OAuth連携、アプリ専用のパスワード、APIキーに対処します。OAuthは外部アプリにアクセス権を委任する仕組みです。不審な連携は解除し、漏洩が疑われるアプリパスワードは失効させます。
対象者に身に覚えのないMFA手段や転送ルールが追加されていないかを調べます。MFAは複数の要素を組み合わせる認証で、対象者が登録した覚えのない認証手段も点検対象です。
SSO外のSaaSを個別にリセットします。SSOに接続していないサービスは、個別にログイン情報をリセットし、実施結果を台帳に記録します。
ログを確認し、身に覚えのない操作や設定変更の有無を調べます。
ログ調査と利用再開の判断
利用再開は、アクセス遮断の結果、端末の調査結果、ログで把握できた範囲をそろえて判断します。ログを取得できない場合は「異常なし」と扱わず、調査上の制約として残します。
ログを取得できるサービスは操作履歴と設定変更を調べます。取得できないサービスは、取得できない理由と調査できない範囲を記録し、サービス管理者への照会に進みます。次の欄をサービスごとに複製すれば、未対応箇所の引き継ぎに使えます。
対象サービス：＿＿／対象アカウント：＿＿／担当：＿＿
セッション：失効済・未実施・実施不可／実施時刻・理由：＿＿
連携認証：OAuth・アプリパスワード・APIキー・MFA・転送ルールの対応結果：＿＿／利用先更新：＿＿
端末：感染兆候なし・隔離中・調査中／調査結果：＿＿
ログ：取得済・取得不可／調査結果・制約・照会先：＿＿
アクセス遮断と端末の安全性を確認できた範囲から再開し、未対応のサービスや調査中の端末は再開対象から外します。再開の判断者と継続調査の担当も記録します。被害把握や社内外への連絡を含む全般的な対応は、不正アクセス対応の優先順位と併せて整理します。
▲ パスワード漏洩が判明した日に情報システム部門が進める初動対応の4フェーズ。
▲ 漏洩原因と端末感染の疑いに応じた初動対応の切り分け判断フロー。
認証基盤ごとのセッション失効の対応対象と確認観点
認証基盤でセッションを失効しても、アプリ側のセッションや連携権限には別の対処が残る場合があります。パスワード漏洩への対応では、「全端末からログアウト」という表現だけで完了にせず、何を無効にしたのかを分けて記録します。
Microsoft Entraの失効範囲
Microsoft Entraでの対応は、トークンの更新停止と、すでに成立しているアクセスの終了を分けて管理します。
リフレッシュトークンとは、利用者がパスワードを再入力せずに、新しいアクセストークンを取得するための情報です。一方、アクセストークンは、アプリやデータへのアクセス権を示す情報です。更新用の情報を無効にすることと、発行済みのアクセス権が使えなくなることは、同じ処理として扱いません。
さらに、アプリ独自セッションとは、アプリ側が保持するログイン状態です。SSOは一度の認証で複数のサービスにサインインする仕組みですが、認証の入口をまとめることと、各サービスのログイン状態を終了することは区別します。
失効操作を行う際は、リフレッシュトークンと発行済みアクセストークンのどちらが対象かを記録します。
アプリ独自のログイン状態が残る場合は、サービス側でもセッション終了処理を行います。
終了を確認できていないアクセスがある場合は、認証基盤の操作済みという理由だけで対応完了にしません。
Google Workspaceの侵害アカウント対応
Google Workspaceでは、アカウントの利用停止、認証情報の変更、ログイン状態の終了、アプリ連携の解除を別々の対応項目として整理します。
サインインCookieは、ブラウザがログイン状態を維持するために使う情報です。
OAuthで付与した権限の取り消しは、ログイン状態の終了とは別の対応として扱います。
不正利用の継続が疑われる場合は、アカウント停止とパスワード再設定を対応項目に入れます。
ブラウザのログイン状態を終了する場合は、実施した操作と、残存セッションの有無を分けて記録します。
不審な接続アプリや不要なOAuth権限が残る場合は、連携解除を別途実施します。アプリパスワードも取り消し対象として切り分けます。
認証基盤の操作履歴だけでなく、サービス側のセッション終了と連携権限の取り消しまで対応表に残すと、未処理の対象を見分けられます。
再発防止に向けた認証とアカウント運用の整備
再発防止は、管理者と委託先の認証強化を起点に、認証の集約と不要アカウントの整理を進めます。全社員への注意喚起だけで終わらせず、権限の強い接続経路、集約から外れたアカウント、端末内の保存データを改善対象にします。
管理者・委託先経路の認証強化
管理者と委託先が使う接続経路から、多要素認証の適用状況と権限の必要性を点検します。多要素認証とは、パスワードなどの知識と、所持する機器など異なる種類の要素を組み合わせる認証です。
委託先がVPN・リモートデスクトップ・保守用回線を使う場合は、接続先ごとに利用者、認証方式、利用期限を整理します。管理画面だけを強化して完了とせず、別の入口から接続できる構成なら、その経路も改善計画に含めます。
管理者・委託先の接続経路を洗い出し、多要素認証の未適用箇所を改修対象にします。
作業完了時は委託先アカウントを見直し、継続利用が不要なら無効化します。管理者権限を常時付与する業務上の理由がなければ、必要な作業時だけ付与する運用に切り替えます。
認証を強化した場合も、ログイン状態を保持するCookieの窃取に備えた端末対策は別に計画します。認証方式の変更を端末保護の代替にせず、業務用端末の更新や不審なソフトウェアへの対処を併せて進めます。経路単位の点検には、多要素認証の適用漏れを調べる点検方法を利用できます。
SSO集約と不要アカウントの整理
認証の集約は、SSOの対象外に残るアカウントの整理とセットで進めます。SSOの対象外にあるサービスは、個別ログインの可否と管理責任者を確認します。
SSOを導入した場合も、各サービスに直接ログインするアカウントが残っていないかを点検対象にします。直接ログインを停止できるなら入口を集約し、保守などの理由で残すなら、管理責任者と利用目的を記録して個別に認証を強化します。「SSO導入済み」を、すべての認証経路の対策完了と扱わない運用にします。
退職者・異動者・長期間使っていないアカウントは、業務上の利用要否で判断します。利用が不要なら無効化し、データの引き継ぎや保持の要否を整理したうえで削除する運用案にします。利用が必要なら担当者と権限を更新し、従来の権限をそのまま残さない扱いにします。退職時の作業は退職者のSaaSアカウント削除チェックにつなげると、サービスごとの対応を整理できます。
パスワード規則と保存方法の整備
パスワード漏洩の再発防止では、変更の契機と保存先を社内ルールに落とし込みます。認証の集約と併せて、残るパスワードの管理方法を決めます。
社内ルールの項目は、SCS評価制度の★3の評価基準が参考になります。IPAの解説書では、パスワード管理アプリの利用などでパスワードを安全に保管する社内ルール（No.4-1-6-1）と、情報機器やサービスの間でパスワードを使い回さない社内ルール（No.4-1-5-4）を定めることを求めています。同じ認証基盤（SSOなど）を使う場合は、使い回しに当たらないとも説明しています。この制度は、取引契約などで委託元が委託先に求める段階（★）を示す使い方を想定しています。
定期的なパスワード変更については、米国立標準技術研究所（NIST）のSP 800-63B-4が、定期変更を求めず、侵害の証拠がある場合に変更させる考え方を示しています。
社内規則を見直す場合は、使い回しを避ける方針と、パスワード流出が判明した際の変更担当者・対象範囲を明文化します。注意喚起と未確定の制度内容も分けて扱い、資料の説明をそのまま新たな義務化と読み替えないようにします。関連する論点は個人情報保護委員会の不正アクセス注意喚起の解説で整理できます。
SSOに集約できるサービスは認証基盤で管理し、個別のパスワードが残る場合は会社管理のパスワードマネージャーで保管する役割分担にします。ブラウザ保存を禁止する場合も、設定変更だけで完了とせず、既存の保存分と同期先を点検し、移行・削除まで作業に含めます。保存先を切り替える際の判断材料は、パスワードマネージャーによる保存方法で確認できます。
漏洩対応で起きやすい失敗と未完了の判断基準
パスワード変更や検知結果だけで対応を終えると、残ったセッションや業務アカウントを見落とします。対応終了は、実施した作業の数ではなく、アクセス経路に未処理項目がないかで判断します。
失敗パターン | 残る問題 | 対応を継続する条件 |
|---|---|---|
パスワードだけを変更する | ログイン状態を維持するセッションや連携先へのアクセス権限が未処理です。 | セッションの失効や不要な連携権限の解除を確認できなければ継続します。 |
感染が疑われる同じ端末で再設定する | 変更後の認証情報も再び盗まれる懸念が残ります。 | 端末の安全性を確認できなければ利用再開を保留し、安全な別端末で対応します。 |
SSOの失効だけで終了する | SSOを経由しない業務アカウントが確認対象から漏れます。 | 個別ログインできるアカウントに未処理項目があれば継続します。 |
監視結果が空なら安全と判断する | 検知対象外の情報や、侵害の有無が未確認のまま残ります。 | 端末やアクセス履歴の調査が未完了なら、検知なしでも継続します。 |
ブラウザ保存の禁止だけで既存分も消えたと判断する | 既存の保存情報が削除されたかは未確認です。 | 既存分の削除状況と、保存されていた認証情報への対応を確認できなければ継続します。 |
サービス側の仕様で即時失効できない場合も、処理済みにはしません。サービスごとに即時失効できない理由と仕様上の制約を対応記録に転記し、代替手段としてアカウント停止やアクセス制限が使えるなら適用します。使えない場合は未遮断として管理し、制約、代替措置の実施結果、担当者、再確認時点を記録に残します。
漏洩通知は、認証情報への対処を始める材料として扱い、自社システムからの流出を確定する証拠とは区別します。Entra Password Protectionの禁止リストも、漏えいパスワード検知と同じ判定として扱わない運用にします。
まとめ
漏洩後の影響範囲調査では、検知された社員と利用サービスを結び付ける業務アカウント台帳を使います。パスワード漏洩の対象者について、サービスごとの登録情報と対応状況を同じ台帳に記録します。
台帳は表計算ソフトでも作成でき、次の項目を設ければ専用ツールがなくても運用を始められます。
項目 | 記録内容 |
|---|---|
対象者 | 社員名・所属 |
サービス | 業務で利用するサービス名 |
登録メール | アカウントに登録したメールアドレス |
SSO利用有無 | 利用あり・なし・未確認 |
管理者 | 対応を割り当てる担当者 |
失効状況 | 未着手・対応中・完了 |
端末対応 | 対応内容と進捗 |
最終確認結果 | 確認日時・確認者・結果 |
Adminaを利用する場合は、漏洩検知とは切り分け、検知後の利用サービス調査を支える台帳として位置付けます。台帳だけでは全サービスや個人メール登録まで網羅できないため、対象者への聞き取りで補います。
台帳でサービスを特定できれば管理者へ失効対応を割り当て、特定できない業務利用が残る場合は対象者への聞き取りで補完します。
最初の一歩は、対象者1人について利用サービスと対応状況を1枚に整理することです。
業務アカウント台帳の整備を検討する方は、Adminaの資料をご請求ください。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
