委託先の侵害：最初の通知から再保証の確認まで、36の判断ポイント。

相手の侵害が、自社のインシデントになる

当サイトで取り上げた漏えいの多くは、公表した企業ではなく委託先で起きています。問い合わせ対応の委託先、ホスティング事業者の販売管理システム、ストレージサービスの管理者アクセスなどです。委託元は多くの場合メールで知らされ、それが自社のデータ、アカウント、連携にとって何を意味するかを短時間で判断しなければなりません。

この再利用可能な委託先侵害プレイブックには36の判断ポイントがあり、はい・いいえの処置、証拠、担当者を示します。新たな侵害の報道ではなく、SecOpsNomad独自の手順です。委託先、SaaS事業者、個人データの委託先、マネージドサービス事業者、業務委託先がセキュリティインシデントを報告した場合、または報じられた場合に使います。委託先のアクセスで自社システムに直接入られた場合は、アカウント侵害プレイブックを並行して実施します。

2つの時系列が同時に進みます。 委託先は自社環境を、こちらは自社の環境を調べます。委託先の調査結果は、何を求めるかを決める材料です。委託先のアクセス、委託先が持つ自社の情報、共有している認証情報が自社に対して使われたかは、自社のログで判断します。自社で管理できる範囲の封じ込めを、委託先の最終報告まで待たないでください。

全体図：関係の把握 → 委託先の証拠 → 自社データ → 接続経路 → ハンティング → 二次被害 → 報告・通知。初動を最初に行い、復旧は判定を経て進めます。図と同じ判断を直後の表で確認できます。

まずここから：最初の1時間

初めて対応する方は、この順番で進めてください。詳しい対応は、このあとの各段階で行います。この時点で、委託先で攻撃者が何をしたかを知っている必要はありません。

1. 0〜10分：通知が本物か確かめる。 通知に書かれた番号ではなく、手元にある番号（契約書、過去の請求書、取引先管理システム）で委託先に電話します。「この通知はそちらからのものですか。インシデントの窓口はどなたですか」と確認します。偽の侵害通知は、よく知られたフィッシングの手口です。
2. 10分：知った時刻を記録する。 自社がインシデントを確かな情報として最初に知った時刻を書き留めます。法令や契約の期限は、こうした時点から数えます。
3. 10〜15分：案件を作る。 インシデント責任者、委託先との取引の担当者、法務・個人情報の窓口を決めます。
4. 15〜25分：委託先が持っているもの、つながっているものを一覧にする。 委託先にある自社のデータ、自社システム内の委託先のアカウント・管理権限・ツール、共有しているキーとパスワード。明日の完璧な一覧より、今の大まかな一覧が役に立ちます。探す場所は段階1にあります。
5. 25分：一時的な制限を決める。 インシデントが続いている可能性がある場合や、委託先が自社環境で管理者権限やリモートツールを持つ場合は、そのアクセスを今止めます（段階4）。削除ではなく無効化にします。削除したアカウントは履歴も一緒に失われます。
6. 30分：証拠の提供を依頼する。 このページ末尾のテンプレートを使います。
7. 35分：経理（支払担当）に注意喚起する。 この委託先の振込先変更や至急の支払いは、既知の番号への折り返し確認なしに行わないようにします。
8. 40分：ログの検索を始める。 委託先のアカウントとドメインについて、委託先が示した期間に余裕を持たせた期間で検索します（段階5）。
9. 50分：法務・個人情報の担当に説明する。 委託先が持つデータを伝えます。日本では、漏えいが委託先で起きた場合でも、委託元が個人情報保護委員会への報告義務を負うのが通常です。
10. 60分：社内向けの最初の状況報告を送る。 次の報告時刻も決めます。

やってはいけないこと： 確認前に、通知に書かれた連絡先へ返信すること。委託先とすり合わせる前に公表すること。「アクセスの証拠はない」を「アクセスはなかった」と読むこと。委託先の最終報告を待ってから自社へのアクセスを制限すること。

事前準備と判断ルール

平常時から、重要な委託先ごとに次を一覧にしておきます。共有しているデータ（種類、件数、再委託先）、自社環境に持たせているID、双方向の連携と認証情報、提供を受けるソフトウェアや更新、通知・協力・監査に関する契約条項、確認済みのセキュリティ連絡先。委託先からのメールを起点にした机上演習で手順を確認してください。

• はい： 処置を行い、他の該当する確認もすべて実施します。
• いいえ： 回答を裏付ける証拠、範囲、時間帯を記録します。アラートなしだけでは不十分です。
• 不明： 未解決の作業として担当と再確認時刻を決め、調査中もリスクに応じて封じ込めます。
• 対象外： 理由と確認者を記録し、ログ不足の代わりに使いません。

案件ID、委託先とサービス、契約番号、委託先が示す影響期間、自社のUTC確認期間、回答・根拠、証拠保管先、処置・結果、実担当、再確認時刻を残します。委託先とのやりとりと自社のメモは制限された案件領域に保管し、認証情報、個人データ、委託先の機密報告書を公開ツールに貼り付けないでください。

日本語の判断台帳をダウンロード（CSV）。空欄は非公開の案件記録用です。表計算ソフトへ追記する文字列は信頼できない入力として扱ってください。

担当： 委託先リスクは委託先との関係と証拠の要求、調達・契約担当は契約上の義務、法務／プライバシーは報告・通知の判断を担当します。IAMとクラウド／ITはIDと連携の封じ込め、SOC／SIEMは自社ログのハンティング、メールセキュリティはなりすましや振込先変更のメール、経理は支払い変更の確認、広報は公表内容の調整を担当します。責任者が再開と終結を承認します。

この手順で使う言葉

用語	意味
委託先・取引先	自社のデータを持つ、自社システムにつながる、またはソフトウェアやサービスを提供する外部の会社です。
委託元・委託先（個人情報保護法）	個人データの取扱いを任せる会社（自社）と、その代わりに取り扱う会社（委託先）です。
再委託先（第四者）	委託先がさらに使う会社です。委託先のクラウド事業者やコールセンターの協力会社などです。
ゲストアカウント	他の組織の人のために、自社のMicrosoft Entraテナントに作るアカウントです。相手は自分の組織のアカウントでサインインします。
パートナー関係	Microsoft 365で、販売店や運用委託先に自社テナントの管理者権限を与えられるつながりです。
リモート管理ツール（RMM）	委託先が自社のPCを遠隔で操作するためのソフトウェアです。強力で、悪用されることもよくあります。
APIキー／Webhook／OAuthアプリ	システム同士を自動でつなぐ仕組みです。どれも、盗まれうるシークレットや権限に依存しています。
痕跡情報（IOC）	IPアドレス、ドメイン、ファイルのハッシュ値など、攻撃者の手がかりです。自社のログで検索できます。
露出期間	攻撃者が自社のデータやアクセスに届きえた期間です。最初の発表より前から始まっていることがよくあります。
個人情報保護委員会（PPC）	個人情報保護法にもとづく漏えい等の報告を受け付ける国の機関です。
速報・確報	委員会への2つの報告です。知ってから概ね3〜5日以内の速報と、30日以内（攻撃などの不正な目的による場合は60日以内）の確報です。
残存リスク	案件を閉じる時点でなお否定できないことです。権限のある人が書面で受け入れます。

セキュリティ担当がいない場合の役割分担

表に出てくる担当は「役割」であり、肩書きではありません。小さな会社では1人が複数の役割を持つのが普通です。それでも「委託先のアクセスを止めた人だけが、止まったことを確認する」状態は避けてください。

この手順での役割	小規模な会社での担当例	事前に用意しておくもの
インシデント責任者	代表者または総務・管理部門の責任者	委託先のサービスを止める判断と、外部支援を承認する権限
契約・取引先の担当	委託契約を結んだ人、または管理している人	契約書、個人データの取扱いに関する条項、委託先の連絡先
IAM／IT管理者	社内のIT担当、またはITの委託先	Microsoft 365／Entra、VPN、ファイアウォール、リモートツールの管理者権限
SOC／SIEM	IT管理者、または監視サービスの事業者	サインイン、監査、メールのログへのアクセス
経理・支払担当	経理部門	振込先変更には折り返し確認を必須とするルール
法務・個人情報	顧問弁護士、または個人情報保護管理者	データの一覧と確認済みの事実
広報	代表者または営業責任者	公表前に委託先と合意した文面
外部の支援	ITの委託先、インシデント対応会社。国内では、インシデント対応の調整を行うJPCERT/CCと、警察のサイバー事案の相談窓口	案件の概要と時系列

画面の項目名は英語表示の名称で書いています。日本語表示では訳語が異なる場合があります。

0. 初動：通知を確認し、主導権を確保

1. 通知メールの返信先や記載の電話番号ではなく、既に把握している連絡先で確認します。偽の侵害通知も送られます。
2. 案件を起票して責任者を決め、委託先、サービス、契約、自社が最初に知った時刻を記録します。この時刻は報告期限の起算に関わります。
3. 委託先の管理台帳を取り出します。なければ今作ります。双方向のデータ、ID、連携、認証情報、ソフトウェアです。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S01. 通知は本物で、既に把握している連絡先で確認できたか？	案件を起票し、最初に知った時刻を記録。委託先の続報を追跡する。	フィッシングの可能性として扱い、クリック・返信の前に別経路で確認する。	通知の原本、ヘッダー解析、既知の連絡先での確認、委託先の公表ページ。	委託先リスク＋メールセキュリティ
S02. 委託先は自社のデータを持つ、自社システムに接続する、またはソフトウェアを提供しているか？	本件では重要委託先として扱い、すべての段階を実施する。	根拠（台帳、契約）を記録し、新しい情報を引き続き監視する。	委託先台帳、契約書、データフローの記録、連携一覧。	委託先リスク＋責任者
S03. インシデントは継続中か、攻撃者が委託先のアクセスを使える状態か？	事実確認と並行して、委託先の接続経路を直ちに制限する（段階4）。	委託先の封じ込め説明を書面で受け取り、検証を続ける。	委託先の説明、封じ込めの日時、自社のサインイン・連携ログ。	IAM＋委託先リスク
S04. 責任者、契約担当、法務／プライバシー、委託先の窓口が決まっているか？	報告の頻度を決め、判断をUTCで記録する。	経営層へエスカレーションする。担当不在の委託先案件は止まる。	体制表、委託先窓口、契約担当、会議の頻度。	責任者

具体的な操作手順

1. 信頼できる連絡先を探します。 契約書、取引先管理システム、過去の請求書にある電話番号です。通知の中にしかない番号、リンク、アドレスは使いません。
2. 電話で確認します。 通知が本物であること、委託先のインシデント窓口の氏名、続報の送り方。インシデントの管理番号を決めておきます。
3. 委託先自身の発信を確認します。 Webサイト、ステータスページ、プレスリリース。公表内容と、聞いた内容が一致しているかを記録します。
4. 案件記録を作ります。 項目は、委託先、サービス、契約ID、取引の担当者、最初に知った時刻（UTCと日本時間）、確認方法、委託先の窓口、次回報告時刻です。
5. 契約書と個人データの取扱いに関する条項を取り出します。 通知、協力、監査、再委託の条項に印を付けます（段階2で使います）。

確認： S01に「はい」と答え、電話した相手の氏名と使った番号を記録していること。

1. 関係の把握：委託先が持つもの、つながる先

1. 委託先に渡したデータを一覧にします。種類、件数、保存期間、データを渡した再委託先です。
2. 委託先が自社環境に入る経路を一覧にします。ゲストアカウント、パートナー管理者アクセス、VPN、遠隔管理ツール、API連携、サービスアカウントです。
3. 双方向の認証情報を一覧にします。自社が委託先に発行した鍵・パスワードと、委託先が自社に発行したものです。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S05. 委託先と再委託先に共有したデータの最新の一覧があるか？	影響範囲の特定に使い、データ担当と内容を確認する。	契約、データ転送、システム担当から再構成し、不足を記録する。	データ台帳、契約の別紙、転送記録、再委託先の一覧。	委託先リスク＋データ担当
S06. 委託先は自社環境にIDを持っているか（ゲスト、パートナー管理者、VPN、サービスアカウント）？	各IDの所有者、権限、最終利用を一覧にし、制限の準備をする。	ディレクトリ、VPN、SaaSの利用者一覧と照合する。「なし」にも証拠が必要。	ゲスト一覧、パートナー関係の画面、VPNアカウント、SaaS利用者の出力。	IAM
S07. 共有している認証情報（APIキー、SFTPアカウント、Webhook、OAuthアプリ、トークン）があるか？	発行元、権限範囲、変更担当を一覧にする（段階4）。	結論の前に、連携設定、秘密情報の保管庫、コードリポジトリを確認する。	保管庫の登録内容、連携設定、エンタープライズアプリ、リポジトリの検査結果。	クラウド／IT＋アプリ担当
S08. 委託先はコード、更新、エージェント、運用サービスを自社環境に提供しているか？	ソフトウェアサプライチェーンのリスクとして扱い、更新を保留または検証する（段階4）。	コードの経路がないことを記録して次へ進む。	ソフトウェア台帳、更新経路、導入済みエージェント、MSPのツール。	IT運用＋EDR

具体的な操作手順

1. Microsoft Entraのゲストアカウント： Entra管理センター →「Entra ID」→「Users」→「All users」→ ユーザーの種類「Guest」で絞り込み、委託先のドメインで検索します。Microsoft Graph PowerShellなら次のとおりです（ドメインは置き換えます）。

   Connect-MgGraph -Scopes "User.Read.All"
   Get-MgUser -Filter "userType eq 'Guest'" -All -Property DisplayName,Mail,UserPrincipalName,Id,CreatedDateTime |
     Where-Object { $_.Mail -like '*@supplier.example' -or $_.UserPrincipalName -like '*_supplier.example#EXT#*' } |
     Select-Object DisplayName,Mail,Id,CreatedDateTime
   

2. パートナーの管理者権限： Microsoft 365管理センター →「Settings」→「Partner relationships」。委託先との関係と、付与されているロールを記録します。

3. アプリケーション： Entra ID →「Enterprise apps」→「All applications」で、委託先の社名や製品名を検索します。それぞれ開いて権限を記録します。

4. Microsoft以外のすべて： 委託先用のVPNやファイアウォールのアカウントと許可ルール、リモート管理ツール、SFTPのアカウント、シークレット管理にあるAPIキーやWebhook、委託先がインストール・更新するソフトウェアやエージェント。

5. データ： 事業部門の担当者に聞き、契約書でも確認します。どのデータか、件数、項目、委託先での保存場所、受け取っている再委託先。

確認： すべてのデータ、ID、連携、認証情報を1つの表にまとめ、それぞれに担当者がいること（S05〜S08）。

2. 委託先の証拠：何を求め、何を確かめるか

1. 書面で照会します。影響を受けたシステム、データ、顧客、影響期間、攻撃者の行動、指標、封じ込めの状況、調査機関です。
2. 各回答を証拠と結び付けて管理します。「アクセスの証拠はない」は、ログが残っていなかったという意味の場合もあります。
3. 契約の通知、協力、監査、再委託に関する条項を確認し、法令上の期限と並べて期限を管理します。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S09. 委託先は影響を受けたシステム、データ、期間、行動を書面で示したか？	説明を自社の台帳と突き合わせ、未解決事項を記録する。	契約に基づき正式に求め、関係の責任者からエスカレーションする。	書面の説明、質問票への回答、日付入りの会議メモ。	委託先リスク
S10. 委託先は日付と確度付きで指標や攻撃インフラを共有したか？	出典と有効期限を付けて、範囲を絞ったハンティングに使う（段階5）。	共有を求め、IOCがなくてもIDと連携でハンティングを続ける。	IOC一覧、観測期間、確度、共有の制限。	SOC＋脅威インテリジェンス
S11. 委託先の説明は「アクセスを確認」と「証拠なし」を区別しているか？	各説明を証拠の強さとともに記録し、更新時に見直す。	利用できたログとその期間を確認し、不足は「不明」として扱う。	調査機関の所見、ログ保持の説明、フォレンジックの範囲。	委託先リスク＋DFIR
S12. 契約上の通知、協力、監査の条項に該当するか？	書面で行使し、法令上の期限と並べて期限を管理する。	理由を記録する。契約の不足は改善事項に入れる。	契約条項、通知日、やりとりの記録。	調達・契約担当＋法務／プライバシー

具体的な操作手順

1. 証拠の提供を依頼します（下のテンプレート）。確認済みの経路で送り、書面での回答と次回の連絡日を求めます。
2. 回答を表で管理します。 質問、委託先の回答、示された証拠、受領日、確度（確認済み／証拠なしの説明／不明）。
3. 「証拠はない」を慎重に読みます。 「どのログを、どの期間について確認しましたか。保存期間はどれだけですか」と追加で質問します。保存期間が短ければ、それは「分からない」という意味です。
4. 痕跡情報を使える形で求めます。 IPアドレス、ドメイン、ファイルのハッシュ値、アカウント名を、最初と最後に確認された日時と、委託先の確度とあわせて求めます。
5. 期限を並べます。 契約上の通知・協力義務と、法令上の期限を、日付付きで1つの一覧にします。

確認： S09〜S12の主要な質問すべてに、日付付きの回答か、担当者付きの追加確認があること。

3. 委託先にある自社データ：影響範囲を絞り込む

1. 委託先の影響システムと、そこに置いた自社データを突き合わせます。露出確認、露出の可能性、関係なしを分けて記録します。
2. 個人データ、認証情報、決済情報、機密の業務データを分けて特定します。それぞれ義務と処置が異なります。
3. 過去の出力データ、バックアップ、再委託先の複製について確認します。削除済みと思っていたデータが残っていることはよくあります。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S13. 委託した個人データが関係している、またはその可能性があるか？	直ちに法務／プライバシーへ連絡し、人数、項目、機微性を特定する（段階7）。	関係しない証拠を記録し、委託先の範囲が変わったら見直す。	影響レコードの一覧、データ項目、人数、機微性。	法務／プライバシー＋データ担当
S14. 自社に関する認証情報、パスワードハッシュ、鍵、トークンが露出したか？	発行元で変更し（段階4）、利用の有無をハンティングする（段階5）。	委託先のシステムが保存していた秘密情報を委託先に確認する。	保存していた秘密情報に関する委託先の説明、自社の秘密情報台帳。	IAM＋クラウド／IT
S15. 委託先は不要になったデータ（過去の出力、バックアップなど）をまだ保有しているか？	調査後に削除を求め、書面で確認を受ける。	保存の根拠と確認内容を記録する。	保存期間の定め、削除証明、出力の履歴。	委託先リスク＋データ担当
S16. 再委託先など、さらに先の事業者がインシデントに関係しているか？	委託先を通じて証拠の要求を広げ、範囲を更新する。	委託先の確認内容と根拠を記録する。	再委託先の一覧、委託先の確認、データフローの記録。	委託先リスク＋法務／プライバシー

具体的な操作手順

1. データの表を作ります。 データの種類、項目、人数または件数、委託先での保存場所、状態（漏えい確認済み／漏えいの可能性あり／関係なし）。それぞれの状態を、委託先の説明か証拠に結びつけておきます。
2. 義務が変わる区分に印を付けます。 要配慮個人情報、不正に使われると財産的被害が生じうるデータ（決済機能のあるサービスのログインIDとパスワードなど）、認証情報とキー、社外秘の業務データ。
3. ファイルではなく人数を数えます。 日本では、本人が1,000人を超えること自体が報告の基準の1つです。
4. 残っているデータを確認します。 古いエクスポート、テスト用のコピー、バックアップ、再委託先にあるコピー。証拠を保全したうえで、不要なものの削除を求めます。

確認： 法務・個人情報の担当が表を読み、どの行がどの義務につながるかを判断できること（S13〜S16）。

4. 接続経路：自社につながるものを封じ込める

1. 経路ごとに停止、制限、監視を決めます。業務とリスクを比較し、残るリスクを誰が受け入れたかを記録します。
2. 双方向の認証情報を発行元で変更します。新しい秘密情報が侵害されたシステムに渡らないよう、委託先と調整します。
3. パートナー管理者の関係、遠隔管理ツール、ソフトウェア更新の経路を確認します。これらは最も広い権限を持ちます。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S17. 委託先のアカウントや連携を今すぐ停止または制限すべきか？	制限を実施して委託先に連絡し、業務影響を記録する。	監視を強化し、リスク受容と責任者を記録する。	経路の一覧、リスク判断、変更記録、委託先への連絡。	IAM＋責任者
S18. 共有している秘密情報を、委託先と双方向で変更したか？	旧情報が失敗し新情報が機能することを確認し、変更ごとに記録する。	担当者と変更日程を決め、その間は旧情報の利用を監視する。	変更記録、認証失敗の試験、保管庫のバージョン。	クラウド／IT＋アプリ担当
S19. 委託先はパートナー管理者権限、遠隔管理ツール、広いAPI権限を持っているか？	削除または縮小し、後で期限付き・最小権限で再付与する。	存在しない証拠を記録する。	パートナー関係、GDAPロール、RMMの一覧、アプリの権限。	IAM＋IT運用
S20. 委託先のビルドや更新の経路がインシデントに関係しているか？	更新を保留し、署名とハッシュを検証して、導入済みの版をハンティングする。	通常の更新検証を続け、委託先の続報を監視する。	委託先の説明、更新の版、署名、EDRの資産情報。	IT運用＋EDR

Microsoft 365では、パートナーの管理者アクセスは管理センターの設定 > パートナーとの関係に表示されます。ここでロールを削除しても関係そのものは終了せず、パートナーが購入権限を外すまでは代理で購入できる場合があります。Microsoft：パートナーの管理者権限の確認。

具体的な操作手順

1. ゲストアカウント： Entra ID →「Users」→ ゲストを開く →「Account status」→「Edit」→「Account enabled」のチェックを外す →「Save」。続けて「Overview」ページで「Revoke sessions」を選びます。PowerShellでは、段階1で調べた各ゲストのIDについて実行します。

   Connect-MgGraph -Scopes "User.ReadWrite.All","User.RevokeSessions.All"
   Update-MgUser -UserId <guest-object-id> -AccountEnabled:$false
   Revoke-MgUserSignInSession -UserId <guest-object-id>
   

2. パートナーの管理者ロール： Microsoft 365管理センター →「Settings」→「Partner relationships」→ パートナーを選ぶ → ロールを削除します。

3. 委託先のアプリケーション： Entra ID →「Enterprise apps」→ アプリ →「Properties」→「Enabled for users to sign-in?」を「No」→「Save」。自社テナントでそのアプリへの新しいトークン発行が止まります。

4. 共有シークレット： 自社が発行したAPIキー、SFTPのパスワード、Webhookのシークレットを交換し、委託先が発行したものの交換も依頼します。新しいシークレットは電話か安全なポータルで渡し、侵害されているかもしれないメールボックスには送りません。

5. ネットワークとツール： 委託先のVPNアカウントを無効化し、ファイアウォールの許可ルールを削除し、委託先のリモート管理エージェントを停止またはアンインストールします。委託先のソフトウェア更新の経路が関係している場合（S20）は、そこからの自動更新を止めます。

確認： 無効化したゲストのサインインがサインインログで失敗している。パートナー関係にロールが残っていない。古いAPIキーで認証エラーが返る（S17〜S20）。Microsoft：ユーザーアクセスの取り消し

5. ハンティング：自社環境での不正利用を探す

1. 委託先が示した影響期間に、前後の余裕を加えて自社ログを検索します。開始日は後から早まることが多くあります。
2. 委託先のID、アプリケーションID、IP範囲、ドメインで検索し、その後に共有された指標で検索します。
3. 該当なしの結果も、範囲と保持期間の制約とともに保存します。「見つからない」の強さは、検索したログ次第です。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S21. 委託先のIDに、通常と異なるサインインや操作があるか？	侵害の可能性として扱い、該当IDにアカウント侵害プレイブックを実施する。	期間、テーブル、比較に使った基準を記録する。	サインインログ、資源の監査ログ、委託先の通常の活動。	SOC／SIEM＋IAM
S22. 委託先アプリの同意、認証情報、権限が変更されたか？	イベントを保全し、不正な変更を戻して範囲を広げる。	確認したオブジェクトIDと監査の範囲を記録する。	AuditLogsのイベント、変更記録、アプリ権限の履歴。	IAM＋クラウド／IT
S23. 影響期間に、委託先ドメインからのメールにリンク、添付、振込先変更があったか？	メール、クリック、支払い依頼を確認する（段階6）。	メッセージ追跡の範囲を記録し、なりすましの監視を続ける。	メッセージ追跡、クリックログ、振込先変更の依頼。	メールセキュリティ＋経理
S24. 委託先の指標が、自社のネットワーク、DNS、端末のログと一致するか？	一致ごとに文脈を確認し、影響を受けた端末を封じ込める。	検索した指標、日付、データソースを記録する。	IOCの一致、DNS・プロキシログ、EDRイベント、観測日。	SOC＋EDR

具体的な操作手順

1. 期間を決めます。 委託先が示した最も早い日付から余裕（例：30日）を引いた日から今日まで。委託先の時系列は、後から前倒しで修正されることがよくあります。
2. 下のハンティングクエリを実行します。 Microsoft SentinelかDefenderの高度な追求（Advanced hunting）にKQLを貼り付け、時間範囲を設定し、例として入っているテナントID、ドメイン、アプリIDを置き換えます。Splunkでは「Search & Reporting」を開いてSPLを貼り付け、タイムピッカーを設定します。
3. 委託先からのメール： Exchange管理センター →「Mail flow」→「Message trace」→「Start a trace」→ 送信者に*@supplier.example→ 時間範囲は最大90日。新しいリンク、添付ファイル、支払いの指示を探します。
4. 痕跡情報： 委託先が示したIPアドレスとドメインを、ファイアウォール、プロキシ、DNS、EDRのログで検索します。
5. 「見つからなかった」結果を正しく書きます。 「ゲストアカウント14件のサインインログを2026-08-01〜2026-10-06の範囲で検索し、委託先のアドレス範囲外からのサインインはなかった」は役に立ちます。「何も見つからなかった」は役に立ちません。

確認： 委託先のIDと痕跡情報のすべてに、時間範囲とデータの出どころ付きの結果があること（S21〜S24）。

6. 二次被害：自社のデータが悪用される前提で備える

1. 攻撃者は奪った情報を使うと考えます。実名、注文内容、契約番号、やりとりがあると、フィッシングは本物らしくなります。
2. 狙われやすいチームに注意喚起します。支払担当、カスタマーサポート、委託先のデータに名前がある社員です。
3. 経路ごとに適切なプレイブックを使います。振込先変更、顧客アカウントの乗っ取り、鍵の漏えい、アカウント侵害です。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S25. 漏えいしたデータで、顧客や社員へのフィッシングが本物らしくなるか？	具体例と確認済みの報告窓口を添えて注意喚起する。	そのデータが誘導文に使えない理由を記録する。	漏えいした項目、過去の誘導文、報告窓口。	メールセキュリティ＋広報
S26. 侵害された委託先のメールで、請求書や振込先が変更されるおそれがあるか？	振込先変更を一時停止し、既知の番号への電話で確認する。	通常の確認手順を維持し、経理に注意喚起する。	振込先変更の依頼、折り返し確認の記録、取引先マスタの変更。	経理＋メールセキュリティ
S27. 漏えいした顧客の認証情報で、自社サービスのアカウント乗っ取りが起こり得るか？	顧客アカウント乗っ取りプレイブックを実施し、必要に応じて再設定を求める。	関係しなかった顧客データを記録する。	漏えいした項目、ログインログ、不正検知のアラート。	プロダクト担当＋不正対策チーム
S28. 漏えいしたAPIキーやクラウドの認証情報が、自社システムに使われるおそれがあるか？	クラウド鍵漏えいプレイブックを実施し、失効と利用の調査を行う。	確認した秘密情報と、露出していない理由を記録する。	秘密情報の台帳、クラウドの監査ログ、事業者からの通知。	クラウド／IT＋SOC

具体的な操作手順

1. 経理： この委託先に折り返し確認のルールを直ちに適用し、理由もチームに伝えます。期間中に受け取った振込先変更や不審な請求書を見直します。
2. 顧客対応窓口と従業員： 実際の注文内容、氏名、契約番号を使ったフィッシングが続く可能性を伝えます。短い対応スクリプトとエスカレーション先を渡します。
3. 似たドメインを止めます。 攻撃者が委託先に似たドメインを使う場合は、Defenderポータル →「Email & collaboration」→「Policies & rules」→「Threat policies」→「Tenant Allow/Block Lists」に追加します。ブロックには期限（既定は30日）があるため、見直し日を決めます。
4. 適切なプレイブックにつなぎます。 振込先変更の試み → 経理の手順、顧客のパスワード漏えい → 顧客アカウント乗っ取り、キーの漏えい → クラウドの認証キー漏えい、従業員の不審なサインイン → アカウント侵害。

確認： 想定される詐欺の経路（S25〜S28）それぞれに、担当者と期限付きの対応があること。

7. 報告・通知：報告、本人通知、公表

1. 法域ごとの報告義務は法務／プライバシーが判断します。日本では、委託先で起きた個人データの事案は、通常は委託元が自ら報告します。
2. 確認できた事実から、本人、顧客、規制当局への通知を準備し、続報の計画を立てます。
3. 自社の公表内容を委託先の公表と合わせ、内容が食い違わないようにします。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S29. 規制当局への報告、例えば委託元としての個人情報保護委員会への報告が必要か？	把握済みの事実で速報を行い、期限までに確報を行う。	法務／プライバシーの判断根拠を記録し、範囲が変われば見直す。	法的評価、報告フォーム、最初に知った日。	法務／プライバシー
S30. 影響を受けた本人への通知が必要か？	経緯、対象データ、本人が取るべき行動を通知する。	通知が不要、またはまだできない理由を記録する。	通知文、連絡先一覧、送付記録。	法務／プライバシー＋広報
S31. 自社の顧客、取引先、他の規制当局への連絡が必要か？	契約と業界の規則に従って連絡する。	確認した契約と規則を記録する。	顧客との契約、業界規制、連絡記録。	法務／プライバシー＋営業担当
S32. 自社の公表内容は委託先の公表と一致しているか？	公表前に、事実と時期を委託先と合わせる。	相違を解消するか、自社の公表で明確に説明する。	双方の公表文、承認記録、想定問答。	広報＋法務／プライバシー

日本の個人情報保護法（参考）： 個人情報保護委員会の通則編ガイドラインは、報告対象事態として、要配慮個人情報、不正に利用されると財産的被害が生じるおそれがあるデータ、不正アクセスなど不正の目的をもって行われたおそれがある行為による漏えい等、本人の数が1,000人を超える場合の4つを挙げています。不正の目的による行為には、委託先に対する行為や、利用している第三者のサービスに対する行為も含まれます。速報は知った時点から概ね3〜5日以内、確報は30日以内（不正の目的による場合は60日以内）です。委託先は委託元に速やかに通知すれば報告義務を免除され、委託元は通常、遅くともその通知を受けた時点で事態を知ったことになります。適用は法務／プライバシーが判断します。他の法域や業界規則は異なります。個人情報保護委員会 通則編ガイドライン 3-5。

具体的な操作手順

1. 日本（個人情報保護法）： 法務・個人情報の担当が、報告対象となる4つの事態を確認します。要配慮個人情報、不正に使われると財産的被害が生じうるもの、不正の目的をもって行われたおそれがあるもの（委託先への攻撃を含む）、1,000人を超えるもの。いずれかに当たれば、委託元が個人情報保護委員会に報告します。知ってから概ね3〜5日以内の速報と、30日以内（不正の目的による場合は60日以内）の確報です。報告は委員会の漏えい等の対応のページから行います。
2. 本人への通知： 報告が必要な場合は、本人にも状況に応じて速やかに通知します。下の本人向け通知のテンプレートを下書きに使います。
3. そのほか： 業界の監督官庁、契約にもとづいてデータを預かっている取引先、海外の制度（たとえばEUのGDPRでは、管理者は認識してから72時間以内の通知が求められます）。
4. 発信を1つにそろえます。 公表前に下書きを委託先と共有し、事実や日付の食い違いを解消します。

確認： 各報告・通知について、誰が判断し、いつ送ったかを日付付きで一覧にしていること（S29〜S32）。

8. 復旧：証拠にもとづいて信頼を戻す

1. 是正の証拠を求めます。根本原因、対策、第三者調査の結果、現在の監視体制です。
2. 新しい認証情報と最小権限で連携を段階的に再開し、当初は重点的に監視します。
3. 契約、台帳、受け入れ時の確認を更新し、次の通知に早く答えられるようにします。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
S33. 委託先は根本原因が是正された証拠を示したか？	証拠と出典を記録し、追跡確認の日程を決める。	制限を維持し、契約に基づいてエスカレーションする。	是正報告、第三者の所見、証明書。	委託先リスク＋責任者
S34. 新しい認証情報と最小権限で連携を再開したか？	段階的に再開し、異常を監視する。	変更と権限の見直しが終わるまで停止を続ける。	再開後の設定、新しい秘密情報、権限の見直し、監視。	クラウド／IT＋アプリ担当
S35. 契約と監視の改善について委託先と合意したか？	変更内容（通知期限、監査権、データの最小化）を記録する。	担当と期日を付けて、更新時の計画に入れる。	契約の変更、監視計画、委託先の約束事項。	調達・契約担当＋委託先リスク
S36. 残る不確実性を明示的に受け入れたうえで、責任者が終結できるか？	終結、委託先の未完了の約束、その確認日を記録する。	未解決の分岐ごとに担当を付け、案件を継続する。	最終時系列、範囲、通知、委託先の再保証、承認。	責任者＋法務／プライバシー

具体的な操作手順

1. 改善の証拠を求めます。 根本原因、修正内容、外部調査会社の報告の要約、現在の監視体制。「セキュリティを強化しました」は証拠ではありません。
2. 段階的に戻します。 MFA付きの新しいゲストアカウント、権限を最小にした新しいAPIキー、必要な場合だけ期限付きのパートナーロール。最初の2週間の動きをよく見ます。
3. 契約を見直します。 決まった時間内の通知、疑問に答えられるだけのログ保存期間、協力・監査の権利、最新の再委託先一覧、サービス終了時のデータ削除。
4. 一覧と委託前の確認項目を更新します。 次の通知に数分で答えられるようにします。

確認： 再開したそれぞれの連携に、担当者、新しい認証情報、見直し日がある。契約の変更が書面で合意されている（S33〜S36）。

ハンティング：委託先に限定したKQLとSplunk

実際のIOCは掲載していません。 汎用の対応ガイドです。案件記録にある委託先のテナントID、アプリケーションID、ドメイン、委託先が示した影響期間を使います。3例とも読み取り専用で、文書・スキーマを照合したものです。実環境では実行していません。

KQLの対象は、Microsoft Entra IDのログを接続したMicrosoft Sentinel／Azure Monitor Log Analyticsです。テーブルへの取り込み、委託先の影響開始時点まで遡れる保持期間、閲覧権限を確認してください。各例の表示上限は500件です。上限に達したら期間を分け、すべての結果を保存します。

1. 自社テナントへの委託先IDのサインイン： SigninLogsとAADNonInteractiveUserSignInLogsの両方が必要です。HomeTenantIdで、B2Bゲストやパートナー管理者など委託先のEntraテナントに属するIDを特定します。パートナーの管理アクセスではCrossTenantAccessTypeがserviceProviderになります。自社テナント内に委託先の担当者用に作成したアカウントは自社テナントに属するため、アカウント侵害プレイブックのサインイン検索でオブジェクトIDごとに確認してください。VPN、SaaS独自のアカウント、遠隔管理ツールによるアクセスはEntraのログに残りません。

2. 委託先アプリケーションへのディレクトリ変更： 委託先のエンタープライズアプリケーションやサービスプリンシパルを対象とするAuditLogsのイベント（同意、認証情報の追加、ロール・権限の変更）を確認します。オブジェクトIDはエンタープライズアプリケーションの一覧から取得します。記録があるだけでは不正ではありません。変更記録と委託先の説明と照合してください。

3. Splunkで委託先ドメインからのメールを確認： Splunk Add-on for Microsoft Office 365のメッセージ追跡入力（sourcetype o365:reporting:messagetrace）のSenderAddress、RecipientAddress、Subjectを使います。分かるのは委託先からのメールの受信者で、リンクのクリックは分かりません。検索期間は影響期間に合わせます。新しいGraphベースの入力（o365:graph:messagetrace）はフィールド名が異なる可能性があるため、先に1件確認してください。

KQL：委託先テナントに属するIDのサインイン

supplier-signin-review.kqlをダウンロード

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
// Sign-ins to your tenant by identities homed in the supplier's Entra tenant.
let SupplierTenantId = "REPLACE_WITH_SUPPLIER_TENANT_ID";
let WindowStart = datetime(2026-01-01T00:00:00Z);  // REPLACE: exposure start, UTC
union withsource=LogTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated between (WindowStart .. now())
| where HomeTenantId =~ SupplierTenantId
| project TimeGenerated, LogTable, UserPrincipalName, UserId, CrossTenantAccessType,
    HomeTenantId, ResourceTenantId, IPAddress, AppDisplayName, ResourceDisplayName,
    ResultType, ConditionalAccessStatus, CorrelationId
| order by TimeGenerated asc
| take 500

KQL：委託先アプリケーションへのディレクトリ変更

supplier-app-changes.kqlをダウンロード

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
// Directory events that name the supplier's apps or service principals as targets.
let SupplierObjectIds = dynamic(["REPLACE_WITH_APP_OR_SERVICE_PRINCIPAL_OBJECT_ID"]);
let WindowStart = datetime(2026-01-01T00:00:00Z);  // REPLACE: exposure start, UTC
AuditLogs
| where TimeGenerated between (WindowStart .. now())
| mv-expand Target = TargetResources
| where tostring(Target.id) in~ (SupplierObjectIds)
| summarize arg_max(TimeGenerated, *) by Id
| project TimeGenerated, Id, OperationName, Result, InitiatedBy,
    TargetResources, CorrelationId
| order by TimeGenerated asc
| take 500

Splunk：委託先ドメインから受信したメール

supplier-inbound-mail.splをダウンロード

index="REPLACE_WITH_O365_INDEX" sourcetype="o365:reporting:messagetrace" earliest=-30d latest=now
| eval sender_domain=lower(mvindex(split(SenderAddress, "@"), 1))
| search sender_domain IN ("REPLACE_WITH_SUPPLIER_DOMAIN")
| stats count AS messages dc(RecipientAddress) AS recipients min(_time) AS first_seen max(_time) AS last_seen values(Subject) AS subjects BY SenderAddress
| convert ctime(first_seen) ctime(last_seen)
| sort - recipients
| head 500

コピーして使えるテンプレート

［角かっこ］の部分をすべて置き換えてください。パスワードやキーは書かないでください。社外に出す文面は、法務または個人情報の担当者が確認します。

委託先への情報提供の依頼

段階2で、確認済みの経路から送ります。

件名：貴社のセキュリティインシデントに関する情報提供のお願い（貴社管理番号：［番号］）

［会社名］
［氏名］様

［日付］にご連絡をいただき、ありがとうございました。当社としての義務を果たすため、次の事項を［日時］までに書面でご提供ください。
1. 影響を受けたシステムとサービス。当社のデータを保存・処理する、または当社環境に接続するシステムが含まれるか。
2. 関係する当社のデータ：データの種類、項目、件数または人数、漏えいが確認済みか可能性にとどまるか。
3. 期間：攻撃者の活動が確認された最も早い時点、封じ込めた時点、それぞれの根拠。
4. 攻撃者の行為：アクセス、複製、暗号化、削除の有無。当社に関係する認証情報、キー、トークンが漏えいしたか。
5. 痕跡情報：IPアドレス、ドメイン、ファイルのハッシュ値、アカウント名と、その日時・確度。
6. 関係する再委託先と、当社データのコピーを保有しているか。
7. 封じ込めの状況と、調査会社の名称（ある場合）。
8. 確認したログの種類、対象期間、保存期間。
9. 当局と本人への通知の予定（双方の説明をそろえるため）。
関係する証拠は保全をお願いいたします。当社の窓口は［氏名、電話、メール］です。新しい認証情報は［電話／安全なポータル］でのみお渡しします。
何卒よろしくお願い申し上げます。
［会社名・部署・氏名］

経理・顧客対応窓口への注意喚起

最初の1時間と、段階6で使います。

件名：【要対応】［委託先名］のセキュリティインシデント：支払いと依頼の確認について

［委託先名］からセキュリティインシデントの報告がありました。犯罪者がそこで得た実際の情報（氏名、注文番号、請求書など）を使い、不正な依頼を本物らしく見せる可能性があります。
当面の間、次のとおり対応してください。
・［委託先名］の振込先変更や至急の請求への支払いは、［契約書／取引先管理システム］にある番号へ折り返し確認するまで行わない。
・［委託先名］を名乗り、パスワード、支払い、ファイルのダウンロードを求めるメールは、既存のやり取りの続きであっても不審なものとして扱う。
・お客様から、注文内容を使った不審な連絡があったと聞いた場合は、記録して［連絡先］に伝える。
不審な点は［連絡先・チャンネル］に報告してください。ご協力をお願いします。

本人への通知（法務確認用の下書き）

段階7で使います。確認済みの事実に合わせて修正し、リンクは入れないでください。

件名：業務委託先におけるセキュリティインシデントについてのお知らせ

［お客様名］様

［日付］、当社が［業務内容］を委託している［委託先名］から、同社でセキュリティインシデントが発生したとの報告を受けました。お客様の情報が［含まれていました／含まれていた可能性があります］ので、お知らせいたします。
対象となる情報：［例：氏名、住所、電話番号、注文履歴］。［クレジットカード番号とパスワードは含まれていません／含まれています：詳細］
当社の対応：［例：委託先から当社システムへのアクセスを停止し、調査を求めるとともに、個人情報保護委員会に報告いたしました］
お客様へのお願い：ご注文に触れて支払いや個人情報を求める連絡には、十分にご注意ください。当社がメールや電話でパスワードをお尋ねすることはありません。
お問い合わせ先：［専用電話番号と受付時間］。メッセージ内のリンクではなく、当社のアプリをお使いいただくか、ウェブサイトのアドレスを直接入力してアクセスしてください。
ご心配とご迷惑をおかけしますことを、深くお詫び申し上げます。
［会社名］

経営層向けの要約（5行）

1. 何が起きたか：［当社の顧客データを預けている／当社システムにアクセスできる］［委託先名］が、［日付］にセキュリティインシデントを報告しました。
2. 当社への影響：［データの種類］［件数］件が［漏えい確認済み／漏えいの可能性あり］。当社システムへの委託先のアクセスは［○時に停止済み／次の理由で継続中］。
3. 当社環境の状況：［○○を対象とした検索では不正利用なし／不審なサインイン1件を調査中］
4. 必要な判断：［例：○日までの個人情報保護委員会への報告の承認、本人通知の承認、改善の証拠が出るまでのサービス停止の継続］
5. 次回報告：［時刻］。責任者：［氏名］

具体例：顧客対応の委託先がランサムウェア被害に

架空の事例です。会社、人物、時刻、数値はすべて創作で、判断のつながりを示すためのものです。

状況： 従業員120人のネット通販会社が、顧客対応を外部に委託しています。委託先の担当者は通販会社のMicrosoft 365にゲストアカウントを持ち、APIキーでCRMを使い、毎週の顧客ファイルをSFTPで受け取っています。金曜の17:40（日本時間）、委託先の代表アドレスから、ランサムウェアの被害を受けたというメールが届きます。

1. 金曜17:55 確認。 インシデント責任者が契約書の番号で営業担当に電話し、通知が本物で、攻撃者は水曜から活動していたと確認します（S01、S03）。責任者は17:55を「知った時刻」として記録します。
2. 金曜18:10 把握。 一覧から、ゲストアカウント12件、CRMのAPIキー、SFTPのアカウント、そして4万8千人分の氏名・住所・電話番号を含む毎週のファイルが判明します（S02、S05〜S07）。
3. 金曜18:30 制限。 攻撃が続いている可能性があるため、12件のゲストを無効化してセッションを取り消し、CRMのキーを失効させ、SFTPのアカウントを停止します。週末の顧客対応は社内の担当者が引き受けます（S17、S18）。
4. 金曜19:00 依頼と注意喚起。 情報提供の依頼を送り、経理には折り返し確認の注意喚起を出します（S09、S26）。
5. 土曜10:00 ハンティング。 サインインログから、1件のゲストアカウントが木曜2:14に委託先のネットワークではないホスティング事業者からサインインし、CRMのレポートを3件エクスポートしていたことが分かります（S21）。このアカウントは、アカウント侵害のプレイブックで別の案件として扱います。
6. 月曜 範囲の確定。 委託先が、毎週の顧客ファイルを置いたフォルダーが暗号化の前に複製されていたと確認します（S13）。4万8千人分で、犯罪による攻撃のため、法務は火曜に個人情報保護委員会へ速報を出し、委託先と合意した文面で本人への通知を準備します（S29、S30、S32）。
7. 10日目 復旧。 委託先が調査会社の報告の要約と修正内容を共有します（S33）。アクセスは段階的に戻します。MFA付きの新しいゲストアカウント、読み取り専用のCRMキー、SFTPに代わる安全な受け渡しサービスです（S34）。契約には24時間以内の通知とログ保存の条項が加わります（S35）。
8. 45日目 終結。 攻撃による事案に適用される60日以内の期限内に確報を出します。責任者は、水曜より前の委託先のログが不完全だったことを受け入れて案件を閉じます（S36）。

分かれ目になったこと： 15分以内に電話で通知を確認したこと。不便でも当日の夜にアクセスを止めたこと。自社のログを検索し、委託先からは見えなかった不正利用を見つけたこと。

未解決事項と事後の改善

委託先のインシデントには、自社だけでは解消できない不確実性が残ります。委託先のログ、再委託先の全体、攻撃者の行動の全容を見られることはまれです。委託先が書面で確認したこと、確認できなかったこと、自社のログで確認できない範囲を記録します。すべての行を埋めても、網羅の保証にはなりません。

終結時は、「この委託先は何を持ち、どこにつながっているか」にどれだけ早く答えられたか、契約で必要な情報と協力を得られたか、本来存在すべきでなかった認証情報や連携はどれかを振り返ります。結果は委託先の受け入れ手順、契約のひな形、他の重要な委託先の一覧に反映してください。

参考資料と更新履歴

以下は2026-10-06に確認した資料です。製品・ライセンス・ログ構成が変わるため、実行前に自環境の仕様を確認してください。

• Personal Information Protection Commission: APPI general guidelines, 3-5 data breach reporting (Japanese)
• Microsoft: review partner administrative privileges
• Microsoft: sign-in log details, cross-tenant access type
• SigninLogs schema
• AADNonInteractiveUserSignInLogs schema
• AuditLogs schema
• Splunk: Office 365 message trace data source

2026-10-06：初版。 EN／日本語の判断IDとクエリを一致させて公開。