認証情報の漏えい検知は、アラートを見つけて終わりではありません。API キー、トークン、パスワード、共有アクセスキーがどこで見つかり、誰が関係し、どのワークロードに偏っていて、どれだけ早く無効化・ローテーションできたのかまで追えなければ、実際のインシデント対応にはつながりません。
2026年4月15日、Microsoft は Credential Exposure Risk & Response Workbook を公開しました。これは Microsoft 365 Defender、現在の Microsoft Defender XDR、および Microsoft Purview Information Protection / DLP の検知データを、SecOps チームや identity defenders が使える「対応ダッシュボード」に近づけるための Power BI ベースのワークブックです。単なる可視化ではなく、認証情報漏えいの検知、トリアージ、封じ込め、再発防止、監査説明までを運用に落とし込むことが狙いです。(TECHCOMMUNITY.MICROSOFT.COM)
Credential Exposure Risk & Response Workbook とは
Credential Exposure Risk & Response Workbook は、認証情報漏えいに関するイベントを横断的に集約し、リスクと対応状況を見える化するためのレポートテンプレートです。
Microsoft の説明では、このワークブックは認証情報漏えい検知を「技術的なアラートの流れ」から「測定可能なセキュリティ能力」へ変えるものと位置付けられています。ワークロード、部門、認証情報の種類、ユーザー単位でイベントを関連付け、メール、ファイル、URL などの元データまで掘り下げられる点が特徴です。(TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、ワークブック自体が魔法の検知エンジンになるわけではないことです。実務では、Microsoft Purview DLP、Sensitive Information Types、Endpoint DLP、Microsoft Defender XDR の advanced hunting などで取得したデータを、対応に使いやすい形へ整理する役割と考えると理解しやすくなります。
Microsoft 365 Defender は現在 Microsoft Defender XDR として提供されており、エンドポイント、ID、メール、コラボレーション、クラウドアプリなどを横断してインシデントレベルの可視性を提供する XDR プラットフォームです。(Microsoft)
なぜ認証情報漏えい対応は継続的な検索テーマなのか
「credential leak detection」「credential exposure remediation」「認証情報 漏えい 対応」が継続して検索される理由は明確です。認証情報漏えいは、発見した瞬間からインシデント対応の時間との戦いになるためです。
たとえば、次のようなケースは現場で起こりがちです。
- 開発者が API キーをテスト用ファイルに貼り付け、そのファイルが OneDrive に同期された
- サポート担当者が顧客環境の接続情報をメール本文で共有した
- チャットやドキュメントに一時パスワードが残った
- アプリケーションが一時ファイルやログにトークンを出力した
- 認証情報らしき文字列を検知したが、誤検知か本物か判断できない
これらは「漏えいしたかもしれない」だけでは終わりません。SOC や identity defender は、影響範囲を確認し、資格情報を無効化・ローテーションし、関連ユーザーや端末を調査し、再発防止策をチケットやポリシーに反映する必要があります。
ワークブックの価値は、ここにあります。個別アラートを見るだけでは分かりにくい 傾向、偏り、対応遅延、再発パターン を見える化し、検知から是正までを運用プロセスとして扱えるようにします。
ワークブックが解決する実務上の課題
認証情報漏えい対応で失敗しやすいのは、検知そのものよりも「検知後の整理」です。
| よくある課題 | 現場で起きる問題 | ワークブックで見たい観点 |
|---|---|---|
| アラートが多すぎる | 重要な漏えいとノイズが混ざる | 認証情報の種類、重大度、発生元ごとの優先度 |
| 影響範囲が分からない | どの部門・ユーザーから手を付けるべきか迷う | 部門、ユーザー、ワークロード別の集計 |
| 対応状況を説明できない | 経営層や監査向けに根拠を示せない | 作成件数、解決件数、対応時間、未解決件数 |
| 根本原因が残る | 同じチームやアプリで再発する | 発生元ファイル、アプリ、URL、端末の相関 |
| DLP ポリシーの調整が難しい | 誤検知を恐れて検知条件が甘くなる | 検知傾向と実害の比較 |
セキュリティ運用で最も避けたいのは、「検知はしているが、対応品質を測れていない」状態です。ワークブックは、このギャップを埋めるための運用レイヤーとして使えます。
主な機能と見るべきポイント
Microsoft のブログでは、ワークブックが提供するビューとして、検知トレンド、インシデントトレンド、コンテンツビュー、フォースディレクテッドグラフ、認証情報漏えいに関連するセキュリティインシデント、アプリ・ネットワーク相関などが紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
Detection trend：検知件数の増減を見る
Detection trend では、日別の検知件数、ワークロード別の内訳、認証情報タイプ別の傾向を確認できます。
実務では、単に「件数が多い日」を見るだけでは不十分です。次のように読むと、対応に直結します。
| 見るポイント | 判断の例 |
|---|---|
| 急なスパイク | 新しい共有ミス、設定変更、ポリシー変更、特定部署の作業イベントを疑う |
| 特定ワークロードへの偏り | Exchange ならメール共有、OneDrive / SharePoint ならファイル保存、Endpoint ならローカル生成ファイルを重点確認 |
| 特定の credential type の増加 | API key、token、password などに応じてローテーション手順を変える |
| 検知ソースの偏り | Defender、Sentinel、Cloud App Security などで監視カバレッジの抜けを確認 |
たとえば、Endpoint で token 検知が急増している場合、ユーザーの手作業ではなく、特定アプリケーションがログや一時ファイルに認証情報を書き出している可能性があります。Microsoft も、Endpoint のビューはシークレットを安全に扱っていないアプリケーションの発見に役立つと説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
Credential incident trends：対応の速さを測る
Credential incident trends は、アラートの作成と解決の推移を可視化します。ここで見るべきなのは、検知数だけではありません。
重要なのは 作成件数に対して解決件数が追いついているか です。
新規アラートが増えているのに解決件数が横ばいなら、SOC の処理能力、チケット連携、ローテーション手順、承認フローのどこかに詰まりがある可能性があります。逆に、解決件数が増えていても同じ部署や同じ認証情報タイプで再発しているなら、教育や開発プロセス、DLP ポリシー側の改善が必要です。
このビューは、社内 SLA の管理にも使えます。たとえば次のような基準を設けると、運用が曖昧になりません。
| 重要度 | 対応目標の例 | 対応内容 |
|---|---|---|
| 高 | 当日中 | 本番環境の API キー、管理者権限の認証情報、外部共有済みファイル |
| 中 | 1〜3営業日 | 内部共有ファイル、限定権限のキー、影響範囲が限定的なトークン |
| 低 | 定期レビュー | 誤検知候補、期限切れのサンプル、テストデータ |
実際の SLA は組織のリスク許容度に合わせて調整すべきですが、少なくとも「何を何時間以内に処理するか」を決めておかないと、ワークブックは単なるきれいなレポートで終わります。
Content view：どこに認証情報が残っているかを見る
Content view では、ワークロード、部門、認証情報タイプ、ユーザー、ドキュメントの関係を掘り下げられます。Microsoft の説明では、部門から認証情報タイプ、ユーザー、ドキュメントへドリルダウンし、根本原因分析に使えるとされています。(TECHCOMMUNITY.MICROSOFT.COM)
このビューは、特に Microsoft Information Protection / Microsoft Purview DLP の担当者に有用です。
たとえば、営業部門でパスワードらしき文字列が多い場合は、顧客対応のメールテンプレートや引き継ぎ文書に問題があるかもしれません。開発部門で API キーが多い場合は、CI/CD、サンプルコード、ローカル設定ファイル、ログ出力の見直しが必要です。
見るべき観点は次の通りです。
- どの部門で繰り返し発生しているか
- どのユーザーが複数回関与しているか
- どのファイル種別や保存場所に偏っているか
- 外部共有やメール送信など、流出経路につながる操作があるか
- 検知された文字列が本当に有効な認証情報か
ここで注意したいのは、検知結果に本物の認証情報が含まれる可能性があることです。閲覧権限は最小限にし、調査担当者、Microsoft Entra 管理者、DLP 管理者の役割分担を明確にする必要があります。
Force-directed graph：ユーザーとアラートの関係を俯瞰する
フォースディレクテッドグラフは、ユーザー、アラートカテゴリ、認証情報タイプ、部門などの関係を視覚的に把握するためのビューです。
一覧表では見逃しやすい「ハブ」を見つけるのに向いています。たとえば、特定ユーザーが複数種類の認証情報漏えいアラートに関係している場合、そのユーザー個人の問題とは限りません。役割上、多くのシステム接続情報を扱っている、チームの共有手順が属人化している、または端末上のツールが不適切にシークレットを保存している可能性があります。
このビューを使うときは、個人を責めるためではなく、構造的な問題を見つける姿勢が重要です。SecOps のダッシュボードは、懲罰ではなくリスク低減のために使うべきです。
Security incidents correlated to credential leakage：XDR インシデントと結び付ける
認証情報漏えいは、単独の DLP イベントとして終わる場合もあれば、実際の侵害インシデントの一部である場合もあります。
たとえば、漏えいしたトークンが不審なサインイン、異常なメール転送ルール、外部 IP からのアクセス、端末上の不審プロセスと結び付いていれば、優先度は一気に上がります。
Microsoft Defender XDR の advanced hunting は、構築したクエリで過去 30 日間のイベントデータを調査し、異常な活動や脅威の可能性を確認できる機能です。API を使えばイベントデータをプログラムで照会することもできます。(Microsoft Learn)
ワークブックを使う場合も、DLP の検知だけで完結させず、次のような XDR シグナルと組み合わせると実効性が高まります。
- 同じユーザーの不審なサインイン
- 同じ端末でのマルウェア検知
- 同じメールボックスでの転送ルール作成
- 同じ URL や IP への通信
- 同じアカウントによる大量アクセスや権限変更
認証情報漏えい対応では、「文字列が見つかった」ことよりも、「その認証情報が悪用され得る状態か、すでに悪用された兆候があるか」を判断することが重要です。
導入前に確認すべき前提条件
Microsoft のブログでは、ワークブック利用の前提として、適切なルールで credential data を取得できるようにしておくこと、Microsoft Purview Information Protection のライセンス要件を確認すること、Endpoint DLP を有効化して監査ログに含めること、Power BI Desktop をインストールすることが挙げられています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次の順で確認すると抜け漏れを防ぎやすくなります。
| 確認項目 | チェック内容 |
|---|---|
| ライセンス | Purview Information Protection、DLP、credential scanning SIT など、利用機能に必要なライセンスを確認 |
| 権限 | Power BI、Defender XDR、Purview、Advanced Hunting API へのアクセス権を最小権限で付与 |
| DLP ポリシー | 認証情報を検知する SIT やカスタム regex が設定されているか |
| Endpoint DLP | 対象デバイスが Purview にオンボードされ、必要な監査が取れているか |
| データ品質 | 空値、過剰な誤検知、古いテストデータがレポートを汚していないか |
| 対応プロセス | 検知後のローテーション、無効化、チケット化、完了確認の手順があるか |
Sensitive Information Types は、機密情報を検出するためのパターンベースの分類子です。Microsoft は多数の事前構成済み SIT を提供しており、組織独自のカスタム SIT も作成できます。なお、Microsoft Learn では credential scanning SIT の利用に E5 ライセンスが必要と説明されています。(Microsoft Learn)
Endpoint DLP は、Windows 10 / 11、macOS、対応する Windows Server などに DLP の監視・保護機能を拡張し、ユーザーが機密アイテムに対して行った操作を Activity Explorer で可視化できます。(Microsoft Learn)
セットアップの流れ
ワークブックの導入は、Power BI テンプレートを開くだけでは完了しません。先に「何を検知し、どう対応するか」を設計する必要があります。
まず検知対象を決める
最初に決めるべきなのは、どの認証情報を優先して検知するかです。
すべてを同じ重要度で扱うと、SOC はすぐにノイズに埋もれます。まずは事業影響が大きいものから始めるのが現実的です。
| 優先度 | 検知対象の例 | 理由 |
|---|---|---|
| 高 | 本番 API キー、クラウド管理者トークン、DB 接続文字列 | 悪用時の影響が大きい |
| 中 | 開発・検証環境のキー、共有アカウント情報 | 横展開や権限昇格の足掛かりになり得る |
| 低 | サンプル文字列、期限切れキー、教育用データ | 誤検知や運用改善の対象 |
「password=」や「token」のような単純な文字列だけで検知すると、誤検知が増えます。キーワード、正規表現、周辺語、長さ、形式、除外条件を組み合わせて、実際の環境に合わせて調整しましょう。
Microsoft Purview では、SIT のテスト機能を使って、作成した sensitive information type が意図通りに動作するか確認できます。Microsoft は、作成した各 SIT について、ポリシーで使用する前にシミュレーションを実行することを推奨しています。(Microsoft Learn)
DLP ポリシーを監査モードから始める
最初からブロックを強くかけると、業務影響が大きくなりがちです。特にグローバル組織では、地域、部門、業務プロセスによって認証情報の扱いが異なります。
初期段階では、次のような段階的アプローチが向いています。
| フェーズ | 目的 | 推奨アクション |
|---|---|---|
| 観測 | 実態を把握する | 監査モードで検知件数、発生元、誤検知を確認 |
| 調整 | ノイズを減らす | SIT、除外条件、対象ワークロード、重大度を調整 |
| 通知 | ユーザー行動を変える | ポリシーヒントや教育メッセージを出す |
| 制御 | 高リスク操作を止める | 外部共有、コピー、アップロードなどを条件付きで制限 |
| 定着 | 継続改善する | ワークブックで SLA、再発率、部門別傾向をレビュー |
DLP は、アイテムの作成、読み取り、変更、オンデマンド分類などで機密情報を評価し、条件に合うユーザー操作が行われた場合に Activity Explorer などにイベントが表示されます。(Microsoft Learn)
Power BI テンプレートを接続する
Microsoft のブログでは、Power BI Desktop をインストールし、レポートを開いたうえで https://api.security.microsoft.com と advanced hunting API に組織アカウントで認証する手順が紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
接続時に注意したいのは、表示できるデータが権限に依存する点です。管理者権限を広く配るのではなく、調査担当者、DLP 管理者、ID 管理者、経営報告閲覧者でアクセス範囲を分けるのが安全です。
また、Microsoft Defender XDR の advanced hunting API には権限やクォータがあります。Microsoft Learn では、Application 権限として AdvancedHunting.Read.All、Delegated 権限として AdvancedHunting.Read が示されています。(Microsoft Learn)
運用で使える対応フロー
ワークブックを導入したら、次は毎日の運用に組み込みます。おすすめは、次の 5 ステップです。
| ステップ | 担当 | 実施内容 | 完了条件 |
|---|---|---|---|
| 検知確認 | SOC / DLP analyst | 新規アラート、急増、重大度を確認 | 調査対象を分類 |
| 妥当性判断 | SOC / アプリ担当 | 本物の認証情報か、テスト値か、期限切れかを確認 | 誤検知・要対応を判定 |
| 封じ込め | Identity / Cloud admin | キーの無効化、パスワードリセット、トークン失効 | 悪用可能性を低減 |
| 影響調査 | SOC / IR team | XDR、Entra、端末、メール、クラウドログを確認 | 悪用有無を判断 |
| 再発防止 | DLP / 開発 / 業務部門 | ポリシー、教育、コード管理、シークレット管理を改善 | 同種イベントの減少を確認 |
ポイントは、検知とローテーションを分離しないことです。
「検知したが、誰がキーを無効化するか分からない」という状態では、対応時間だけが伸びます。ワークブックで見える化したら、必ずチケット管理や SOAR、手動手順書と結び付けましょう。
失敗しやすいポイントと対策
誤検知を放置してアラート疲れを起こす
認証情報検知は、正規表現を広くしすぎるとすぐに誤検知が増えます。たとえば、ランダム文字列、ハッシュ値、サンプルコード、ダミーパスワード、ログ ID などが大量に拾われることがあります。
対策は、最初から完璧な検知を狙わないことです。30日程度の観測期間を設け、次の観点でチューニングします。
- 本物の認証情報だった割合
- 部門別・ワークロード別の誤検知率
- 除外してよいファイルパスやリポジトリ
- サンプル値、教育用データ、既知のダミー文字列
- 高信頼度の検知条件と低信頼度の検知条件の分離
レポートを見る人と直す人が分かれている
ワークブックを SOC だけが見ていても、実際の修正は進みません。API キーなら開発チーム、ID なら Entra 管理者、共有ファイルなら情報管理部門や業務部門が関わります。
そのため、レポート設計では「誰が次のアクションを取るか」を列やフィルターに反映すると有効です。
たとえば、部門、所有者、アプリ名、端末、ファイル保存場所、チケット番号を紐付けられるようにすると、単なる分析から実際の是正に移しやすくなります。
認証情報の中身を不用意に共有する
認証情報漏えい対応では、調査そのものが二次漏えいにつながるリスクがあります。
ダッシュボードのスクリーンショットをチャットに貼る、検知されたトークンをチケット本文にそのまま記載する、調査用 Excel にエクスポートする、といった行為は避けるべきです。
安全に運用するには、次のルールを明文化します。
| ルール | 理由 |
|---|---|
| 認証情報の値そのものは原則マスクする | 二次漏えいを防ぐ |
| 閲覧権限を調査担当者に限定する | 不要なアクセスを減らす |
| チケットには種類・場所・所有者・対応状況を記録する | 値を共有せず対応を進める |
| ローテーション後に証跡を残す | 監査や再発防止に使う |
| エクスポートを制限する | レポート外への拡散を防ぐ |
対応完了の定義が曖昧
「確認済み」と「解決済み」は違います。
認証情報漏えい対応の完了条件は、最低でも次のように定義しておくべきです。
- 検知された認証情報が本物か判断した
- 有効な認証情報なら無効化またはローテーションした
- 悪用の兆候を確認した
- 影響範囲を記録した
- 元ファイル、メール、URL、ログなどを削除またはアクセス制御した
- 再発防止策を実施またはチケット化した
この完了条件がないと、ワークブック上の「解決」は実態を反映しません。
グローバル組織での使い方
Credential exposure remediation は、グローバル企業ほど難しくなります。拠点ごとに言語、業務ツール、法規制、開発文化、時差が異なるためです。
ワークブックをグローバルで使う場合は、最初から全社一律の基準を押し付けるより、共通指標とローカル運用を分けると定着しやすくなります。
| 項目 | グローバル共通にすべきもの | ローカル調整してよいもの |
|---|---|---|
| 重大度 | 本番キー、管理者資格情報、外部共有の扱い | 部門別の優先度 |
| SLA | 高リスク認証情報の初動時間 | 営業日、休日、時差対応 |
| レポート | 全社件数、未解決件数、平均対応時間 | 部門名、地域名、業務プロセス |
| ポリシー | 外部共有、公開場所への送信制御 | 通知文、教育コンテンツ |
| 権限 | 最小権限、監査証跡 | 地域ごとの調査担当者 |
特に多国籍企業では、認証情報の値そのものを国境を越えて共有してよいか、データ保護・雇用・監査の観点で事前に確認する必要があります。ワークブックは可視化の手段であり、法務・コンプライアンス上の判断を自動化するものではありません。
SecOps と identity defenders が見るべき KPI
ワークブックを経営層や監査向けにも使うなら、KPI は技術指標だけにしないことが重要です。
おすすめの指標は次の通りです。
| KPI | 目的 | 改善アクションの例 |
|---|---|---|
| 新規 credential exposure 件数 | 発生状況を把握 | 高頻度部署への教育、ポリシー強化 |
| 平均初動時間 | SOC の反応速度を測る | 通知・チケット連携の改善 |
| 平均解決時間 | ローテーションや削除の遅れを測る | 所有者情報、承認フローの整備 |
| 未解決の高リスク件数 | 組織の残存リスクを見る | 優先対応会議、エスカレーション |
| 再発率 | 根本原因の残存を測る | 開発プロセス、テンプレート、教育の見直し |
| 誤検知率 | 検知品質を測る | SIT、正規表現、除外条件の調整 |
| ワークロード別件数 | リスクの偏りを見る | Exchange、Endpoint、SharePoint などの個別対策 |
SecOps では「何件検知したか」よりも、「高リスクの認証情報をどれだけ早く安全な状態に戻せたか」を重視すべきです。identity defenders では、認証情報の無効化やパスワードリセットだけでなく、不審なサインイン、権限変更、条件付きアクセス、MFA 状態まで含めて見ると、対応精度が上がります。
すぐに始めるためのチェックリスト
最後に、Credential Exposure Risk & Response Workbook を使って認証情報漏えい対応を運用化するための初期チェックリストを整理します。
| チェック | 実施内容 |
|---|---|
| 検知対象を決めたか | API キー、トークン、パスワード、共有アクセスキーなどを優先度付きで定義 |
| SIT を検証したか | サンプルファイルで検知・非検知をテスト |
| DLP ポリシーを段階導入したか | 監査、通知、制御の順で展開 |
| Endpoint DLP を有効化したか | 対象端末のオンボードと監査範囲を確認 |
| Power BI 接続権限を整理したか | Defender XDR、Advanced Hunting API、Purview への最小権限を確認 |
| 対応フローを決めたか | 検知、判定、無効化、調査、再発防止の担当を明確化 |
| KPI を定義したか | 件数、初動時間、解決時間、未解決件数、再発率を追跡 |
| 二次漏えい対策をしたか | 認証情報の表示、エクスポート、チケット記載ルールを制限 |
Credential Exposure Risk & Response Workbook は、認証情報漏えいを「見つける」ためだけのツールではありません。Microsoft 365 Defender / Microsoft Defender XDR と Microsoft Information Protection / Microsoft Purview DLP のデータを、インシデント対応、リスク説明、ポリシー改善につなげるための運用基盤です。
まずは高リスクな認証情報に対象を絞り、監査モードで実態を把握し、ワークブックで傾向と対応遅延を見える化しましょう。そのうえで、ローテーション手順、チケット連携、部門別の再発防止策まで整えれば、認証情報漏えい対応は場当たり的な作業から、継続的に改善できるセキュリティ運用へ変えられます。
コメント