Microsoft Purviewでレガシーシステムのパスワード漏えい対策を進めるなら、最初に見るべきポイントは「MFAで守れないパスワードのみの業務」を、Custom Sensitive Information Type（カスタムSIT）とDLPポリシーでどこまで検知・抑止できるかです。
2026年4月20日、MicrosoftはMicrosoft Purviewのカスタム正規表現を使い、平文パスワードの露出を検知する方法を紹介しました。特に、レガシーシステム、サードパーティーツール、サービスアカウントなど、パスワードのみで運用されがちなワークフローを補完する文脈で重要です。Microsoftの例では、パスワードらしい文字列だけでなく、password、pwd、credentialなどのキーワードとの近接条件を組み合わせ、誤検知を減らしながら平文パスワードの共有・保存を検出する設計が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、IT管理者、運用責任者、展開計画担当者が発表直後に確認すべき「設定差分」「展開順序」「ユーザー周知」「運用時の注意点」を、実務で使えるチェックリストとして整理します。
Microsoft Purviewのカスタム検出が注目される理由
MFAや条件付きアクセスを導入していても、すべての業務が最新の認証方式に移行できているとは限りません。現場には、次のようなレガシーな運用が残りがちです。
- 古い業務アプリがID連携やMFAに対応していない
- ベンダー保守用アカウントが共通パスワードで管理されている
- 障害対応時に一時パスワードをメールやTeamsで共有している
- ExcelやメモにシステムIDとパスワードを保存している
- サービスアカウントの資格情報を手順書に残している
このような運用では、認証基盤側の強化だけでは不十分です。パスワードがメール、ファイル、チャット、端末上のドキュメントに平文で残ると、アカウント侵害や横展開の起点になります。
Microsoft PurviewのSensitive Information Type（SIT）は、機密情報を検出するための分類ルールです。Microsoftのドキュメントでは、SITのパターンは主要素、補助要素、信頼度、近接条件などで構成され、カスタムSITでは組織独自の正規表現やキーワードを定義できます。(Microsoft Learn)
今回のポイントは、「パスワードらしい強い文字列」を単体で検出するのではなく、「パスワードを示す文脈」と一緒に検出することです。これにより、APIキー、ハッシュ、ランダムな識別子などを誤って拾うリスクを抑えやすくなります。
2026年4月20日の更新で押さえるべき要点
Microsoftのブログで示された設計は、平文パスワードの検出を次の3層で考えるものです。(TECHCOMMUNITY.MICROSOFT.COM)
| 検出要素 | 役割 | 管理者が確認すべきこと |
|---|---|---|
| Primary element | パスワード候補となる文字列を検出 | 長さ、空白の有無、対象文字種が自社ルールに合うか |
| Supporting element：複雑性 | 大文字、小文字、数字、記号などの条件を確認 | 自社のパスワードポリシーと一致するか |
| Supporting element：キーワード | password、pwd、credentialなどの文脈を確認 | 実際の業務文書で使われる表記を含めるか |
| Proximity | 候補文字列とキーワードの距離を制御 | 誤検知を抑えつつ、実際の記載形式を拾える距離か |
Microsoftの例では、候補文字列の長さを10〜20文字とし、キーワードとパスワード候補が近い位置にあることを条件にしています。たとえば、Password: P@ssW0rd123!のような記載は検出対象になり得ますが、文脈のないランダムな強い文字列は拾いにくくする意図があります。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、この例をそのまま本番環境へ入れるのは避けるべきです。組織によって、パスワード長、許容記号、表記ゆれ、言語、業務システム名、例外ファイルが異なるためです。特にグローバル企業では、passwordだけでなく、passwort、mot de passe、contraseña、パスワード、資格情報など、利用地域に応じたキーワード設計が必要になります。
導入前チェックリスト：まず保護対象を決める
カスタム検出を作る前に、対象を広げすぎないことが重要です。最初から全社・全ワークロード・強制ブロックで始めると、誤検知や業務停止のリスクが高くなります。
| 確認項目 | 判断基準 | 完了の目安 |
|---|---|---|
| 対象システム | MFA非対応、共有ID、サービスアカウント、外部ベンダー利用がある | システム名と責任部門が一覧化されている |
| 対象データ | メール、SharePoint、OneDrive、Teams、端末上のファイルなど | パスワードが残りやすい場所を優先順位化している |
| 対象ユーザー | 運用担当、ヘルプデスク、開発、外部委託先など | 初期展開グループを決めている |
| リスクの高い記載形式 | password=...、pwd: ...、手順書内の認証情報など | 実例を安全なサンプルとして抽出している |
| 例外扱い | パスワード管理ツール、暗号化された保管庫、承認済み手順 | DLP対象外にする理由が文書化されている |
最初の対象は、「レガシーシステムの管理者」「サービスデスク」「外部接続作業を行う運用チーム」など、平文パスワードを扱う可能性が高いチームに絞ると現実的です。
対象を決めるときの優先順位
優先度は、次の順で考えると整理しやすくなります。
| 優先度 | 対象例 | 理由 |
|---|---|---|
| 高 | MFA非対応の業務システム、特権ID、サービスアカウント | 侵害時の影響が大きい |
| 中 | ベンダー保守アカウント、共有メールボックス用の資格情報 | 利用者が多く、管理責任が曖昧になりやすい |
| 低 | 検証環境、期限付きの一時アカウント | 影響は限定的だが、放置すると本番に波及する可能性がある |
「どこにあるか分からないから全体を対象にする」よりも、「最も危険な業務から可視化する」ほうが成功しやすいです。
設定差分チェックリスト：カスタムSITで確認する項目
Microsoft PurviewでカスタムSITを作成する場合、Microsoft PurviewポータルのInformation Protection配下からSensitive info typesを作成できます。Microsoftのドキュメントでは、Custom SITの主要素として正規表現、キーワードリスト、キーワード辞書、事前定義関数などを使い、補助要素や近接条件を追加できると説明されています。(Microsoft Learn)
設定時は、次の項目を差分確認してください。
| 設定項目 | 推奨確認内容 | 失敗しやすいポイント |
|---|---|---|
| SIT名 | 用途、対象、バージョンが分かる名前にする | Password Detectionだけでは管理不能になる |
| 説明文 | 対象システム、検出意図、例外方針を書く | 後任者が意図を理解できない |
| Primary element | パスワード候補の長さと文字種を定義 | 広すぎる正規表現で誤検知が増える |
| Supporting element | 複雑性条件を分割して設定 | 1本の巨大な正規表現にして監査しにくくなる |
| キーワード | 英語、日本語、略語、現場用語を含める | passwordだけでは日本語文書を拾えない |
| 近接条件 | キーワードと候補文字列の距離を制御 | 距離が広すぎると無関係な文字列を拾う |
| 信頼度 | 検出条件の厳しさに応じて設定 | 低信頼度の一致をすぐブロック対象にする |
| テストデータ | 実運用に近いサンプルで検証 | 成功例だけでテストして誤検知を見逃す |
正規表現は「広く拾う」より「説明できる」ことを優先する
パスワード検出では、強い文字列を広く拾うほど誤検知が増えます。たとえば、ランダムなファイル名、APIトークンの一部、ビルド番号、ハッシュ値、テストデータなどが検出される可能性があります。
管理者が重視すべきなのは、検出ルールを監査や問い合わせ対応で説明できることです。
悪い例は、複雑な正規表現を1つに詰め込み、誰も変更できない状態にすることです。良い例は、次のように役割を分けることです。
| 要素 | 例 | 狙い |
|---|---|---|
| 長さ条件 | 10〜20文字程度の非空白文字列 | 候補を絞る |
| 複雑性条件 | 大文字、小文字、数字、記号 | パスワードらしさを確認する |
| 文脈条件 | password、pwd、パスワード、資格情報 | 人がパスワードとして記載した可能性を高める |
| 除外条件 | API_KEY、token、hashなど | パスワード以外の強い文字列を減らす |
MicrosoftのSITテストに関するドキュメントでは、SITのライフサイクル中にテストを実行でき、サンプルファイルをアップロードして検出結果を確認できると説明されています。また、Microsoft Customer Service & Supportはカスタム分類や正規表現パターンの作成を保証する立場ではないため、組織側で要件適合性を検証する必要があります。(Microsoft Learn)
DLPポリシーへの組み込みチェックリスト
カスタムSITを作っただけでは、実際の保護にはつながりません。DLPポリシーに組み込み、対象場所、条件、アクション、通知、例外を設計する必要があります。
Microsoft Purview DLPは、機密情報を識別、監視、自動保護するためのポリシーを定義して適用する仕組みです。DLPポリシーは、SIT、秘密度ラベル、保持ラベルなどを条件として利用できます。(Microsoft Learn)
| 設定項目 | 初期展開でのおすすめ | 本番強制前の確認 |
|---|---|---|
| 対象場所 | Exchange、SharePoint、OneDrive、Teams、Endpoint DLPなどからリスク順に選ぶ | 対象範囲が広すぎないか |
| 条件 | カスタムSITの中〜高信頼度一致を中心にする | 低信頼度一致を強制ブロックに使っていないか |
| アクション | 初期は監査、通知、ポリシーヒントを優先 | いきなり送信ブロックにしていないか |
| 例外 | 承認済みパスワード管理ツールや特定グループを整理 | 例外が広すぎないか |
| アラート | 高リスク一致をセキュリティ運用に通知 | 通知疲れが起きない件数か |
| レポート | Activity explorer、アラート、シミュレーション結果を見る | 誤検知・見逃しの両方を確認したか |
Endpoint DLPを使う場合、端末上の操作監視や保護にも展開できます。Microsoftの説明では、Endpoint DLPはDLPの監視・保護機能をWindows、macOS、特定のWindows Server環境などに拡張し、ユーザーが機密アイテムに対して行う操作をActivity explorerで可視化し、DLPポリシーで保護アクションを適用できます。(Microsoft Learn)
展開順序チェックリスト：いきなりブロックしない
平文パスワード検出は、業務影響が出やすい領域です。発見した瞬間にブロックするのではなく、段階的に展開してください。
| フェーズ | 目的 | 実施内容 | 判断基準 |
|---|---|---|---|
| 準備 | リスクと対象の整理 | レガシーシステム、関係者、保存場所を棚卸し | 初期対象が明確になっている |
| 検出設計 | カスタムSITを作成 | 正規表現、キーワード、近接条件を設定 | サンプルで意図通り検出できる |
| シミュレーション | 業務影響を確認 | DLPポリシーをシミュレーションモードで実行 | 誤検知率と対象件数が許容範囲 |
| 限定通知 | ユーザー教育 | 一部部門でポリシーヒントや通知を表示 | 問い合わせ内容が整理できている |
| 限定制御 | 高リスク操作を抑止 | 外部共有、外部送信などから制御 | 業務停止が起きていない |
| 本番展開 | 全体運用へ移行 | 監査、通知、ブロック、例外処理を標準化 | 運用手順と責任者が決まっている |
Microsoft Purview DLPのシミュレーションモードは、実際に強制アクションを適用せずに、ポリシーがどのアイテムに一致するかを確認するための機能です。新規ポリシーや既存ポリシーの変更時は、シミュレーションで影響を確認してから本番適用するのが安全です。(Microsoft Learn)
初期展開でおすすめのアクション
最初の1〜2サイクルでは、次の順で進めると失敗しにくくなります。
| 順序 | アクション | 狙い |
|---|---|---|
| 1 | 監査のみ | 実際にどこでパスワードが露出しているか把握する |
| 2 | 管理者向けアラート | 高リスク部門や高リスクファイルを確認する |
| 3 | ユーザー通知 | 平文保存・共有が検知されたことを本人に伝える |
| 4 | ポリシーヒント | 送信・共有前に気づかせる |
| 5 | 外部共有の制限 | 社外流出リスクを先に抑える |
| 6 | 高リスク操作のブロック | 本番制御へ移行する |
重要なのは、「検知したら罰する」ではなく、「安全な代替手段へ誘導する」ことです。パスワード管理ツール、Privileged Access Management、承認済みの秘密情報保管庫など、代わりに使う手段がないままブロックすると、ユーザーは別の非公式な方法に逃げてしまいます。
周知チェックリスト：ユーザーに何を伝えるべきか
平文パスワード検出を展開する際は、技術設定と同じくらい周知が重要です。特に運用部門やヘルプデスクは、「急ぎの対応だから仕方ない」と考えてメールやチャットにパスワードを書きがちです。
周知文では、次の内容を明確に伝えてください。
| 周知項目 | 伝える内容 | 例文 |
|---|---|---|
| 目的 | 個人の監視ではなく、アカウント侵害防止が目的 | 「レガシーシステムの認証情報を保護するため、平文パスワードの共有・保存を検知します」 |
| 禁止事項 | メール、Teams、Excel、手順書への平文記載 | 「password: xxxxのような形式で資格情報を記載しないでください」 |
| 代替手段 | 承認済みのパスワード管理ツールや申請フロー | 「共有が必要な場合は、指定の保管庫または一時共有機能を使ってください」 |
| 検知時の対応 | 通知を受けたら削除、移動、再共有方法の変更 | 「通知を受けた場合は、該当ファイルから資格情報を削除してください」 |
| 問い合わせ先 | セキュリティ部門、ITヘルプデスク、運用責任者 | 「業務上必要な例外は、運用責任者経由で申請してください」 |
周知で避けたい表現
次のような表現は、現場の反発や誤解を招きやすいため避けましょう。
| 避けたい表現 | 問題点 | 改善例 |
|---|---|---|
| 「違反者を検出します」 | 監視・懲罰の印象が強い | 「認証情報の露出を早期に検知します」 |
| 「パスワードを書かないでください」だけ | 代替手段がない | 「共有が必要な場合は承認済みの保管庫を使ってください」 |
| 「すべてブロックします」 | 業務影響への不安が大きい | 「段階的に通知・制御を強化します」 |
| 「例外は認めません」 | 現実の運用に合わない | 「例外は責任者承認のうえ期限付きで管理します」 |
周知は一度で終わらせず、検出結果を見ながら部門別に改善してください。たとえば、ヘルプデスクで検出が多い場合は、問い合わせテンプレートや障害対応手順そのものを見直す必要があります。
グローバル展開で追加すべき観点
グローバル組織では、日本語・英語だけを前提にすると検出漏れが起きます。各地域の言語、業務システム名、略語、監査要件を考慮してください。
| 観点 | 確認内容 | 実務上のポイント |
|---|---|---|
| 言語 | パスワードを意味する現地語を含める | 英語圏以外の運用手順書を確認する |
| タイムゾーン | アラート対応の時間帯 | 24時間運用か地域別対応かを決める |
| 法務・プライバシー | ユーザー通知、ログ閲覧、監査証跡 | 地域ごとの社内規程と整合させる |
| 例外承認 | 地域IT、中央IT、セキュリティ部門の役割 | 例外が恒久化しないよう期限を設定する |
| 翻訳 | ポリシーヒントや教育資料 | 機械翻訳だけでなく現場用語を反映する |
特にキーワード設計では、単語だけでなく実際の記載形式を見ることが重要です。たとえば、日本語環境では次のような表現があり得ます。
パスワード：仮パス初期PW資格情報ログイン情報ID/PW管理者パスワード保守用パスワード
一方で、PWのような短い語は誤検知も増えやすいため、近接条件や追加キーワードと組み合わせて慎重に使います。
運用チェックリスト：検知後の対応を決めておく
平文パスワードを検知した後の対応が曖昧だと、アラートが蓄積するだけで改善につながりません。検知後のフローを事前に決めておきます。
| 検知レベル | 例 | 初動対応 | 最終対応 |
|---|---|---|---|
| 高 | 特権ID、外部共有ファイル、本番システムの資格情報 | 即時確認、共有停止、責任者へ連絡 | パスワード変更、インシデント記録 |
| 中 | 社内限定の運用手順書、サービスアカウント情報 | 所有者へ通知、削除・移動依頼 | 保管場所を承認済みツールへ変更 |
| 低 | テスト環境、一時パスワード、サンプルデータ | 誤検知確認、必要に応じて除外 | ルール調整または教育対応 |
検知後に必ず確認すること
検知した文字列が本物のパスワードである可能性がある場合、単にファイルから削除するだけでは不十分です。次の確認が必要です。
- そのパスワードが現在も有効か
- どのシステム・アカウントに紐づくか
- 共有範囲が社内限定か、外部共有か
- すでにアクセスログ上の異常がないか
- パスワード変更またはアカウント無効化が必要か
- 同じ資格情報が別のファイルやメールにも残っていないか
特権アカウントや本番システムの資格情報が含まれる場合は、通常のDLPイベントではなくセキュリティインシデントとして扱う判断も必要です。
誤検知を減らすための調整ポイント
平文パスワード検出でよくある失敗は、「検出条件を強くしたのにアラートが多すぎる」ことです。原因の多くは、パスワード以外の強い文字列を拾っていることにあります。
| 誤検知の原因 | 例 | 調整方法 |
|---|---|---|
| APIキーやトークン | API_KEY = A9$kLm... | api_key、token付近を除外候補にする |
| ハッシュ値 | 長い英数字列 | 長さ条件や許容記号を見直す |
| サンプルコード | テスト用の文字列 | 開発フォルダや特定リポジトリを別扱いにする |
| ランダムなファイル名 | 強い文字列に見える識別子 | キーワード近接を必須にする |
| 多言語表記の不足 | mot de passeなど | 地域別キーワードを追加する |
| 近接距離が広すぎる | 同じ文書内の無関係な文字列 | 距離を短くし、文脈一致を厳しくする |
Microsoftのデプロイメントガイダンスでも、カスタムSITでは補助要素を追加し、近接制限や信頼度、除外条件を調整して誤検知を減らすことが推奨されています。(Microsoft Learn)
管理者が本番前に確認すべき最終チェックリスト
本番適用前には、設定、運用、周知、例外の4つを同時に確認してください。
| 分類 | チェック項目 | 完了 |
|---|---|---|
| 設定 | カスタムSITの目的、対象、バージョンが明記されている | □ |
| 設定 | 正規表現、キーワード、近接条件を個別に説明できる | □ |
| 設定 | 日本語・英語・主要地域の表記ゆれを反映している | □ |
| 設定 | SITテストで成功例・失敗例・誤検知例を確認した | □ |
| DLP | シミュレーションモードで対象件数と影響を確認した | □ |
| DLP | 初期展開では監査・通知を中心にしている | □ |
| DLP | 外部共有や外部送信など高リスク操作の制御方針を決めた | □ |
| 運用 | アラート対応者、一次判断者、エスカレーション先が決まっている | □ |
| 運用 | パスワード変更やアカウント停止の判断基準がある | □ |
| 周知 | ユーザー向け説明文、FAQ、問い合わせ先を用意した | □ |
| 周知 | 承認済みの代替手段を案内している | □ |
| 例外 | 例外申請、期限、承認者、レビュー頻度が決まっている | □ |
このチェックリストで空欄が多い場合は、まだ強制ブロックに進むべきではありません。まずはシミュレーションと限定通知で、検出精度と業務影響を確認してください。
よくある疑問
Microsoft Purviewだけでレガシーシステムのパスワード問題は解決できるか
完全には解決できません。Microsoft Purviewのカスタム検出は、メールやファイルなどに残った平文パスワードを見つけ、共有や保存のリスクを下げるための仕組みです。
根本対策としては、レガシーシステムの認証方式改善、MFA対応、ID統合、特権アクセス管理、パスワード管理ツールの導入も並行して進める必要があります。
すぐにブロック設定を入れてよいか
原則として、最初から強制ブロックは避けるべきです。平文パスワード検出は誤検知が起きやすく、障害対応や保守業務に影響する可能性があります。
まずはシミュレーション、監査、管理者アラート、ユーザー通知の順に進め、検出結果を見ながら外部共有や外部送信などリスクの高い操作から制御するのが現実的です。
どのキーワードを入れるべきか
最初は、英語と日本語の基本語を入れます。
passwordpwdpswdcredentialcredentialsパスワード仮パス初期パスワード資格情報ログイン情報ID/PW
ただし、短いキーワードは誤検知を増やす可能性があります。PWやpassのような語は、対象文書での使われ方を確認してから採用してください。
カスタムSITの検出条件はどれくらい細かくすべきか
最初から完璧を目指すより、説明しやすい条件で始め、検出結果を見ながら調整します。
実務では、次の順で改善すると扱いやすくなります。
| 改善順 | 内容 |
|---|---|
| 1 | 長さと文字種で候補を絞る |
| 2 | キーワード近接で文脈を追加する |
| 3 | 誤検知しやすい語を除外する |
| 4 | 地域別・部門別の表記ゆれを追加する |
| 5 | 高リスク対象だけ制御を強める |
既存のDLPポリシーに追加するべきか、新規作成するべきか
初期検証では、新規の専用ポリシーを作るほうが管理しやすいです。既存ポリシーに追加すると、どの変更がどのアラートや業務影響を生んだのか分かりにくくなります。
おすすめは、Plain-text password exposure - simulationのような専用ポリシーを作り、検証後に本番ポリシーへ統合する方法です。
まず実行すべき次のアクション
Microsoft Purviewのカスタム検出は、レガシーシステムのパスワードのみのワークフローを補完する有効な手段です。ただし、目的は「強い正規表現を作ること」ではありません。平文パスワードが残る業務を可視化し、安全な保管・共有方法へ移行させることです。
最初にやるべきことは、次の3つです。
- MFA非対応・共有ID・サービスアカウントを使う業務を棚卸しする
- Microsoft PurviewでカスタムSITを作り、パスワード候補とキーワード近接をテストする
- DLPポリシーをシミュレーションモードで実行し、検出件数、誤検知、影響部門を確認する
その結果をもとに、通知、教育、外部共有制御、強制ブロックへ段階的に進めます。レガシーシステムが残っている環境ほど、パスワードを「使わせない」だけでなく、「平文で残させない」仕組みを運用に組み込むことが重要です。
コメント