MFAを入れていても、平文で共有・保存されたパスワードは消えません。Microsoft Purview / Sensitive Information Types / DLP の rollout で本当に変わるのは、漏えいを後から監査する運用ではなく、メール送信、Teams 投稿、ファイル共有、端末操作、Copilot 入力のその場で検知して止める運用に寄せられることです。2026年4月20日に Microsoft が公開した custom regex による平文パスワード露出検知の方法は、その変化を最も実務的に示す更新です。 (TECHCOMMUNITY.MICROSOFT.COM)
今回の価値は、「Purview でパスワードが初めて検知できるようになった」ことではありません。Purview にはもともと built-in の credential 系 Sensitive Information Types があり、今回の更新は、組織独自のパスワード基準やpassword の近くに出たときだけ検知したいといった人間の文脈まで反映した custom SIT の設計例を、Microsoft 公式の方法論として整理した点にあります。 (TECHCOMMUNITY.MICROSOFT.COM)
2026年4月20日の更新は「regex追加」ではなく「業務フロー変更のテンプレ」
Microsoft が公開した方法は、平文パスワードらしき文字列を 1 本の巨大な regex で無理やり当てるのではなく、候補文字列、複雑性、人間の意図を示すキーワードに分けて組み立てるものです。公開例では、10〜20文字・空白なしの候補文字列を主要素にし、英字・数字・記号の複雑性を補助要素で確認し、さらに password や pwd のようなキーワードが近接している場合だけ高信頼でマッチさせています。 (TECHCOMMUNITY.MICROSOFT.COM)
Primary:
\S{10,20}
Supporting 1:
[A-Z][a-z]
[0-9] [!@#$%&*+=] Supporting 2 (keywords): password pwd pswd credential
これは公開例を実務向けに簡略化したイメージです。ポイントは「長さ」「複雑性」「キーワード近接」を分けて扱うことにあります。 (TECHCOMMUNITY.MICROSOFT.COM)
重要なのは、10〜20文字という閾値そのものではなく、候補文字列 → 複雑性 → 文脈の3層で設計している点です。こうすると、API キー、ハッシュ、トークンのような「強そうな文字列」の誤検知を減らしつつ、同じ SIT を DLP、Endpoint DLP、Auto-labeling、メールやコラボレーション保護へ横展開しやすくなります。 (TECHCOMMUNITY.MICROSOFT.COM)
built-in SIT と custom regex SIT をどう使い分けるか
最初から全部を custom regex に寄せる必要はありません。実務では、built-in で足りるものは built-in、足りない条件だけ custom が保守しやすいです。 (Microsoft Learn)
- General password は、コード、スクリプト、XML、コマンドライン文脈を含む広めのパスワード検知の土台として向いています。まずベースラインを敷きたいときの第一候補です。 (Microsoft Learn)
- User login credentials / Microsoft Entra user credentials は、username と password の組み合わせや Entra 向けの平文資格情報に強く、認証情報の直書きが多い運用手順書や接続設定で効きます。 (Microsoft Learn)
- All credentials は Amazon、Azure、GitHub、Google、Microsoft general などをまたぐ広範な credential scan ですが、advanced classification が前提です。最初の rollout でいきなり広げると影響範囲が読みづらくなります。 (Microsoft Learn)
- custom regex SIT は、社内のパスワードポリシー、暫定パスワードの書式、
passwordや初期PWの近接条件など、組織独自ルールを反映したいときに向いています。 (TECHCOMMUNITY.MICROSOFT.COM) - EDM（Exact Data Match） は、既知の正確な値を基準データで照合したい場合に向いています。社員番号や顧客IDのような既知データには強い一方、都度変わるパスワードのような未知値には向きません。 (Microsoft Learn)
実装の順番としては、まず built-in SIT を試し、近いものがあれば copy and modify、それでも足りない条件だけ custom SIT で足すのが壊れにくい設計です。Purview は built-in SIT のコピー編集と、ゼロからの custom SIT 作成の両方をサポートしています。 (Microsoft Learn)
Microsoft Purview / Sensitive Information Types / DLP の rollout で現場のワークフローはどう変わるか
DLP は単なる文字列検索ではなく、regex、近接、補助要素、関数、機械学習を含む深いコンテンツ分析で判定し、中央管理されたポリシーを Exchange、OneDrive、SharePoint、Office アプリ、Teams、端末などへ同期します。だから設定変更は、そのまま日常の仕事の仕方を変えます。 (Microsoft Learn)
ヘルプデスクが初期パスワードをメールで送る
一番変わりやすいのが、アカウント発行時の「初期パスワードを本文で送る」運用です。Exchange を対象にした DLP で custom SIT を当てると、この行為は 警告 → block with override → block の順で段階的に制御できます。Microsoft の展開ガイドも、最初は simulation mode、次に policy tips を伴う pilot、最後に本番適用という順序を推奨しています。 (Microsoft Learn)
実務で変えるべきなのは「送るな」だけではありません。代わりに、ワンタイムパスワード、Secret Manager、期限付きリンク、別チャネル確認などを標準手順として先に用意することです。override を許す段階では、例外理由を集めて「本当に必要な例外」なのか「手順が用意されていないだけ」なのかを見分けると、rollout が止まりにくくなります。override 理由や DLP のイベントは Activity Explorer でも追えます。 (Microsoft Learn)
Teams や運用チャットで「とりあえず PW 送ります」ができなくなる
Teams chat / channel は、運用現場ほど「一時的に共有」が起きやすい場所です。Purview DLP は Teams chat and channel messages を対象にでき、センシティブ情報の共有をブロックできます。ここで custom SIT のキーワード近接が効くのは、運用チャットには強い文字列が多く、単純な強文字列検知だけだと誤検知しやすいからです。 (Microsoft Learn)
このシナリオでは、現場のワークフローは「チャットでそのまま送る」から「保管先の secret を参照させる」「閲覧権付きの担当者だけに渡す」に変わります。DLP rollout の成否は、ここで代替行動をどれだけ素早く提示できるかで決まります。
SharePoint / OneDrive の引継ぎファイルと認証情報台帳が残りにくくなる
Microsoft の公開例でも、平文パスワードはコラボレーションサイト上の文書、トラブルシュート用メモ、資格情報管理用スプレッドシートに出やすいとされています。SharePoint / OneDrive を対象にすると、DLP や auto-labeling で「残っている秘密」を見つけて是正しやすくなります。 (TECHCOMMUNITY.MICROSOFT.COM)
ただし、ここには典型的な落とし穴があります。新しい custom SIT を作っても、既存の SharePoint / OneDrive コンテンツは即座に全部検知されるわけではありません。 Microsoft は、既存コンテンツを識別するには search crawler による再クロールが必要で、必要なら site collection、list、library 単位で手動再インデックスを行うべきだと案内しています。 (Microsoft Learn)
もう一つの落とし穴は、Word / Excel / PowerPoint のデスクトップで policy tip が必ず見えると思い込むことです。Win32 クライアントの policy tips は、SharePoint / OneDrive 上の文書で、しかも DLP ポリシーが対応条件・対応アクションの範囲に収まっている場合に限って表示されます。ルールを盛りすぎると、管理側は「警告が出る想定」、現場は「何も出ない」というズレが起きます。 (Microsoft Learn)
Runbook、スクリプト、設定ファイルの扱いが変わる
インフラ運用や開発支援では、runbook、PowerShell、接続文字列、設定 XML に資格情報が残りやすいです。この領域では built-in の General password や User login credentials、Microsoft Entra user credentials がすでに有効な土台になります。コードや XML、username/password ペアの検知は、まず built-in の適用結果を見る価値があります。 (Microsoft Learn)
custom regex SIT が効くのは、「うちの暫定パスワードは 12〜16 文字」「password や credential の近くに出たときだけ止めたい」「API_KEY のような文字列は除外したい」といった運用ルール寄りの要件です。一方で、もっと広く多サービスの秘密を見たいなら All credentials もありますが、これは advanced classification 前提なので、最初の rollout を複雑にしすぎない判断が必要です。 (TECHCOMMUNITY.MICROSOFT.COM)
管理端末からのコピー、印刷、USB 持ち出しが監視・制御の対象になる
Endpoint DLP を入れると、Purview の対象はクラウド文書だけではなく、端末上でのコピー、クリップボード、印刷、ネットワーク共有へのコピー、許可されていないアプリからのアクセスにも広がります。Activity Explorer には、削除、作成、Copy to clipboard、Print、Copy to network share、Access by an unallowed app などの端末イベントが集約されます。 (Microsoft Learn)
ここで admins と power users が痛感しやすいのは、Endpoint DLP は tenant 内の全 SIT を基にファイル分類するという点です。Microsoft は、custom SIT がどの DLP ポリシーで使われているかに関係なく、端末側の分類対象になると明記しています。設計の甘い regex を量産すると、端末側の分類トラフィックとノイズが増えます。使っていない SIT を消し、広すぎる SIT を絞る運用が必要です。 (Microsoft Learn)
Copilot prompt に秘密を貼る行為を別レーンで止める
Copilot 利用が広がると、ユーザーは「メールに貼らない代わりに Copilot に貼る」方向へ流れがちです。Purview では、Microsoft 365 Copilot and Copilot Chat の専用 policy location で、Sensitive Information Types を条件に prompt 処理を止めることができます。ただしこれは 2026年4月時点で preview であり、tenant への rollout 状況確認が必要です。 (Microsoft Learn)
実務上の注意点は3つあります。第一に、この policy location は Custom policy template 専用で、他の場所と同じポリシーに混在できません。第二に、DLP が見るのはユーザーが入力した prompt テキストであり、prompt に直接アップロードしたファイルの中身は評価しません。第三に、ポリシー更新が Copilot に反映されるまで最大4時間程度かかることがあります。つまり、Copilot は email/file DLP の延長ではなく、別レーンで rollout 設計したほうが事故が少ないです。 (Microsoft Learn)
失敗しにくい rollout 手順
Microsoft のガイドラインに沿うなら、DLP rollout は「いきなり block」ではなく、simulation で観測し、policy tips 付き pilot で現場反応を見てから本番が基本です。SIT 自体も sample file をアップロードしてテストできます。 (Microsoft Learn)
| フェーズ | 設定 | 何を見るか |
|---|---|---|
| 棚卸し | built-in SIT と custom SIT をテスト | どの文面・どのファイルが本当にヒットするか |
| 検証 | Simulation mode | 誤検知、対象ユーザー、影響範囲 |
| パイロット | Simulation + policy tips | 現場の反応、override 理由、代替手段の不足 |
| 本番 | Block with override / Block | 例外の減少、アラート処理負荷、運用定着 |
順番としては、Exchange/Teams の送信・投稿系、SharePoint/OneDrive の残存データ系、Endpoint の端末操作系、Copilot の prompt 系を分けて考えると進めやすいです。全部を同時に on にすると、「何が効いて何が困っているのか」が見えません。
管理者向けの細かい注意点として、SIT の Test 機能は tenant に少なくとも 1 つの Exchange Online ライセンスがないとグレーアウトします。検証が始められないときは、regex より先にライセンス前提を確認したほうが早いです。 (Microsoft Learn)
設計時の判断基準と落とし穴
- 大きな1本の regex で終わらせない。 Purview の SIT は primary element、supporting elements、confidence、proximity で組み立てる前提です。公開例がうまくできているのも、候補文字列、複雑性、キーワード文脈を分離しているからです。さらに Purview には、特定マッチ除外、prefix/suffix の include/exclude、重複文字除外などの additional checks もあります。Microsoft 自身、custom classification や regex が要件を満たす保証まではしないと明記しているので、ここは「設定作業」ではなく「検知設計」と捉えるべきです。
^や$のような位置アンカーも custom SIT では避けたほうが安全です。 (Microsoft Learn) - 日本語と英語が混じる環境を前提に keyword を作る。 Microsoft は Japanese を含む double-byte 言語の custom SIT をサポートしており、日本語/英語混在キーワードはスペースあり・なしの両方を定義するよう案内しています。たとえば
初期PW、初期 PW、temporary password、パスワードを別バリアントで持つだけで、検知の取りこぼしがかなり減ります。 (Microsoft Learn) - policy tip の見え方を workload ごとに分けて考える。 Word / Excel / PowerPoint のデスクトップで出る tip には条件があり、エンドポイント側の tip サポートも一様ではありません。管理画面の設定だけ見て「ユーザーに同じ警告が出るはず」と考えると、rollout 後の説明が破綻します。 (Microsoft Learn)
- 既存データの再評価と tuning を甘く見ない。 SharePoint / OneDrive の既存コンテンツには再クロールが必要ですし、SIT は sample file でテストできます。運用開始後は Match / Not a match のフィードバックや Contextual Summary を使って false positive を潰すべきです。confidence についても、Microsoft は high confidence のほうが false positive が少なく、low/medium はマッチ数が増える代わりにノイズも増えやすいと説明しています。平文パスワード検知のように 1 件の重みが大きいケースでは、まず high confidence で始めるほうが現場の反発を抑えやすいです。 (Microsoft Learn)
- Copilot は email/file DLP のおまけではない。 Custom policy template、prompt テキストのみ評価、反映まで最大4時間という特性があるため、別の rollout wave として扱ったほうが設計も説明もしやすくなります。 (Microsoft Learn)
まず次にやること
Microsoft Purview / Sensitive Information Types / DLP の rollout の本質は、平文パスワードを「見つける」ことではなく、どの業務で、誰が、どんな近道で秘密を扱っているかを可視化し、その近道を安全な標準手順に置き換えることです。2026年4月20日の更新は、そのための検知パターンをかなり実務寄りに示してくれました。 (TECHCOMMUNITY.MICROSOFT.COM)
次の一手はシンプルです。
- まず、平文パスワードが流れやすい経路を メール、Teams、共有ファイル、端末、Copilot の5つで棚卸しする
- 次に、built-in の credential SIT を試し、足りない条件だけ custom regex SIT で補う
- そのうえで、Exchange か Teams のどちらか1系統から simulation を始め、Activity Explorer とアラートで誤検知を潰す
- SharePoint / OneDrive は再クロールを前提にし、Endpoint と Copilot は別 wave で展開する
この順番なら、現場を止めずに、それでも確実に「パスワードを平文で扱う仕事の仕方」そのものを変えていけます。
コメント