Microsoft Purviewで平文パスワードの漏えいを検知したい管理者にとって、2026年4月20日の更新でまず押さえるべき点は、新しい自動検知機能が一律に有効化されたわけではなく、カスタムSensitive Information Type（SIT）と正規表現を使って、組織のパスワードルールに合わせた検知設計を行う方法が示されたということです。対象はMicrosoft Purview、Sensitive Information Types、DLPを運用するPurview admins、data security teams、compliance architectsです。
特に確認すべき初動は、既存のDLPポリシーが平文パスワードをどこまで検知できているか、カスタムSITで「文字列の強度」と「password / pwd などの文脈」を組み合わせられるか、検知後に通知・ブロック・教育・インシデント対応までつなげられるかの3点です。
Microsoft Purviewの今回の更新で何が示されたのか
Microsoftは2026年4月20日、Microsoft Security Community Blogで「Detecting Plain‑Text Password Exposure Using Custom Regex in Microsoft Purview」を公開しました。内容は、Microsoft PurviewのカスタムSITで正規表現と補助要素を組み合わせ、メール、ドキュメント、共同作業領域、メモ、スプレッドシートなどに残った平文パスワードを検知する実装例です。(TECHCOMMUNITY.MICROSOFT.COM)
重要なのは、これは「Microsoftが新しい組み込みSITを追加した」という話ではなく、既存のPurviewの仕組みを使って、パスワード露出をより現実的に検知する設計パターンが共有されたという点です。
Microsoft PurviewのSensitive Information Typesは、クレジットカード番号や銀行口座番号などの機密情報をパターンで識別する分類機能です。Microsoft提供の組み込みSITを使うだけでなく、組織独自のカスタムSITを作成できます。(Microsoft Learn)
今回のテーマである平文パスワード検知では、単に「強そうな文字列」を見つけるだけでは不十分です。APIキー、ハッシュ値、ランダムな識別子、トークンなどを誤検知する可能性があるためです。そのため、Microsoftの例では、正規表現による候補文字列の抽出に加え、複雑性の確認とキーワード近接条件を組み合わせています。(TECHCOMMUNITY.MICROSOFT.COM)
最初に確認すべき変更点
今回の更新を実務で受け止める場合、次のように整理すると判断しやすくなります。
| 確認項目 | 実務上の意味 | 初動 |
|---|---|---|
| 新機能か、設計例か | 自動でテナント全体に適用される変更ではなく、カスタムSITの実装例として扱う | 既存のSIT/DLP設定に影響があるかを確認 |
| 検知対象 | 平文で保存・共有されたパスワードらしき文字列 | メール、SharePoint、OneDrive、Teams、エンドポイントなど対象範囲を棚卸し |
| 検知ロジック | 正規表現、複雑性、キーワード文脈を組み合わせる | 自社のパスワードポリシーに合わせて調整 |
| 誤検知対策 | 強いランダム文字列だけではなく、passwordやpwdなどの近接条件を見る | 監査モードで検証してから本番適用 |
| 対応アクション | DLP、Endpoint DLP、自動ラベル付けなどに展開可能 | 通知、ブロック、例外、インシデント連携を設計 |
この更新を読んで最初にやるべきことは、いきなりブロックルールを追加することではありません。まずは監査・検出専用のカスタムSITを作り、既存コンテンツやユーザー操作でどれだけヒットするかを確認することです。
なぜ平文パスワード検知が今も重要なのか
MFAや条件付きアクセスを導入していても、平文パスワード露出のリスクは残ります。Microsoftの記事でも、レガシーシステム、サードパーティツール、サービスアカウントなど、パスワードベースの認証が残る環境では、平文で共有・保存された認証情報が重大なリスクになると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
現場でよくある例は、次のようなものです。
- 障害対応中に「一時的に」Teamsチャットへパスワードを書き込む
- 共有Excelに検証環境のIDとパスワードをまとめる
- サービスアカウントの認証情報をOneNoteや社内Wikiに残す
- 外部ベンダーとのやり取りでメール本文にパスワードを記載する
- 移行作業の手順書に初期パスワードを含めたままSharePointに保存する
これらは、ユーザーの悪意よりも「早く作業を終わらせたい」「一時的だから問題ない」という運用上の妥協から発生します。だからこそ、DLPでは単に禁止するだけでなく、検知、警告、教育、例外管理を組み合わせる必要があります。
Microsoftが示した検知ロジックの考え方
Microsoftの例では、検知ロジックを大きく3つに分けています。1つの巨大な正規表現にすべてを詰め込むのではなく、Primary elementとSupporting elementに分割する設計です。これにより、読みやすさ、保守性、監査性を高めやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
Primary elementで候補文字列を拾う
Primary elementでは、まずパスワード候補となる文字列の長さと空白なしの条件を見ます。Microsoftの例では、次の正規表現が示されています。
\S{10,20}この正規表現は、空白を含まない10〜20文字の文字列を候補として拾います。ただし、これだけでは「パスワード」かどうかは判断できません。ファイル名、ID、トークン、ランダム文字列なども対象になり得るため、Supporting elementで絞り込みます。
Supporting elementで複雑性を確認する
次に、候補文字列がパスワードらしい複雑性を持つかを確認します。Microsoftの例では、大文字、小文字、数字、特殊文字、許可文字セットなどを複数のパターンとして分けています。(TECHCOMMUNITY.MICROSOFT.COM)
| 要件 | 例として使える考え方 |
|---|---|
| 大文字を含む | [A-Z] |
| 小文字を含む | [a-z] |
| 数字を含む | [0-9] |
| 特殊文字を含む | [!@#$%&*+=] |
| 許可文字セットを制限する | [A-Za-z0-9!@#$%^&*()_+\-=]{10,} |
ここで大切なのは、Microsoftの例をそのままコピーして終わりにしないことです。たとえば、自社のパスワードポリシーが「12文字以上」「記号は限定」「日本語や空白は不可」「20文字を超えるパスフレーズを許可」といった条件を持つ場合、正規表現もそれに合わせる必要があります。
キーワード近接で「人がパスワードとして書いた」文脈を見る
誤検知を減らすために重要なのが、キーワード近接です。Microsoftの例では、credential、password、pwd、pswdなどのキーワードを大文字小文字を区別せず扱い、候補文字列の近くにあるかを見ています。(TECHCOMMUNITY.MICROSOFT.COM)
たとえば、次のような文脈は検知対象として妥当です。
Password: P@ssw0rdDemo!
pwd -> Sample#2026
credential=AdminDemo#01一方で、次のような文字列は、パスワードではない可能性があります。
API_KEY = A9$kLmZpQw
RandomStrongString123!実務では、英語圏だけでなく日本語の表現も考慮します。たとえば、グローバル組織や日本法人では、キーワード候補として次のような語を検討できます。
| 言語・表現 | キーワード例 |
|---|---|
| 英語 | password, pwd, pswd, credential, passcode |
| 日本語 | パスワード, 認証情報, 資格情報, 初期パスワード |
| 略語・現場表現 | PW, 仮パス, 初期PW, login password |
ただし、日本語キーワードをカスタムSITに入れる場合は注意が必要です。Microsoft Learnでは、Purviewは日本語などのダブルバイト文字言語を含むカスタムSITをサポートする一方、単語間の扱いや特殊文字の処理に注意が必要だと説明されています。日本語と英数字が混在するキーワードでは、スペースあり・なしのバリエーションを用意するなど、実データに近いテストが欠かせません。(Microsoft Learn)
DLPに組み込む前に確認すべき影響範囲
カスタムSITを作成しただけでは、期待した保護がすべての場所で同じように働くとは限りません。DLPポリシーでは、Exchange、SharePoint、OneDrive、Teams、デバイスなど、対象ロケーションによって使える条件や挙動が異なります。Microsoft Learnでは、DLPポリシーがSIT、秘密度ラベル、保持ラベルなどを条件に機密アイテムを検出し、ロケーションごとに利用できる定義方法が異なると説明されています。(Microsoft Learn)
特に注意したいのは、複数ロケーションを1つのDLPポリシーにまとめる場合です。Microsoft Learnでは、複数の場所を選ぶと、あるロケーションでサポートされない定義方法が全体に影響する場合があると説明されています。(Microsoft Learn)
実務では、次のように段階的に切り分けると失敗しにくくなります。
| 対象 | 初期設定の考え方 | 注意点 |
|---|---|---|
| Exchange Online | まず監査・通知から開始 | メール本文と添付ファイルの検知結果を分けて見る |
| SharePoint / OneDrive | 既存ファイルの棚卸しに有効 | 新しいSITを既存コンテンツに反映するには再クロールの考慮が必要 |
| Teams | チャットでのうっかり共有対策 | 業務影響が大きいため、最初から強制ブロックしない |
| Endpoint DLP | ローカル保存やコピー操作の制御に有効 | 対象ユーザー・デバイスを限定して検証する |
| 自動ラベル付け | 検知後の分類・保護に展開可能 | 誤検知が多い状態で自動ラベルを適用しない |
Microsoft Learnでは、SharePointとOneDriveの既存コンテンツで新しいカスタムSITを識別するには、検索クローラーによる再クロールが必要になると説明されています。新規作成したSITをテストしても既存ファイルで期待通りに出ない場合、ロジックだけでなくクロール状況も確認してください。(Microsoft Learn)
実装時のおすすめ手順
平文パスワード検知用のカスタムSITは、次の流れで進めると安全です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | 既存のパスワード共有実態を確認 | メール、Teams、SharePoint、OneDrive、手順書のどこに多いか |
| 2 | パスワードポリシーを確認 | 文字数、使用可能記号、パスフレーズ可否、例外の有無 |
| 3 | カスタムSITを作成 | Primary element、複雑性、キーワード近接を分けて設計 |
| 4 | テストデータで検証 | 真陽性、偽陽性、偽陰性を記録 |
| 5 | 監査モードのDLPに組み込む | いきなりブロックせず検知件数と影響を確認 |
| 6 | 通知文と例外ルールを整備 | ユーザーが次に何をすべきか分かる文面にする |
| 7 | 高リスク領域から段階適用 | サービスアカウント、外部共有、管理者グループから優先 |
カスタムSITは、Microsoft Purviewポータルの「Information Protection > Classifiers > Sensitive info types」から作成できます。Primary elementには正規表現、キーワードリスト、キーワード辞書、事前定義関数などを指定でき、Supporting elementも追加できます。(Microsoft Learn)
ただし、正規表現を作るときに^や$のような位置アンカーを安易に使うのは避けるべきです。Microsoft Learnでは、カスタムSITで位置アンカーを使うと意図通りに動作しにくい可能性があると注意しています。(Microsoft Learn)
DLPポリシー設計で失敗しやすいポイント
いきなりブロックして業務を止める
平文パスワードは重大リスクですが、最初から全社ブロックにすると、障害対応、移行作業、検証環境の共有などで業務停止を招くことがあります。まずは監査、ユーザー通知、管理者アラートから始め、実際の検知内容を見てブロック条件を絞り込むのが現実的です。
正規表現を広くしすぎる
\S{10,20}のような候補抽出は便利ですが、単独では広すぎます。英数字と記号を含むファイル名、APIキー、トラッキングID、ハッシュ断片などを拾う可能性があります。キーワード近接、許可文字セット、除外条件、対象ロケーションを組み合わせて調整してください。
日本語の現場表現を見落とす
グローバル標準のpasswordやpwdだけでは、日本語環境の「初期PW」「仮パス」「認証情報」などを拾えません。逆に、日本語キーワードを追加しすぎると、手順書や教育資料を広く誤検知する場合があります。検知対象にしたい文脈と、除外したい文脈をセットで設計することが重要です。
検知後の対応フローがない
DLPで検知しても、誰が、どのSLAで、何をするかが決まっていなければ効果は限定的です。たとえば、平文パスワードを検知した場合は、次のような運用を用意します。
| 検知内容 | 推奨アクション |
|---|---|
| 社内メール本文にパスワード | 送信者へ通知し、対象パスワードの変更を依頼 |
| 外部宛メールにパスワード | ブロックまたは承認制にし、セキュリティチームへ通知 |
| SharePoint上の手順書にパスワード | ファイル所有者へ修正依頼し、必要なら秘密度ラベルを適用 |
| Teamsチャットで共有 | ユーザー教育を兼ねたポリシーヒントを表示 |
| サービスアカウントの認証情報 | 直ちにローテーションし、保管方法をKey Vaultなどに移行 |
管理者が今日確認すべきチェックリスト
今回のMicrosoft Purview更新を受けて、Purview adminsやdata security teamsは次の項目を確認するとよいでしょう。
| チェック項目 | 確認内容 |
|---|---|
| 既存DLPの対象 | 平文パスワードに近いSITやキーワード条件が既にあるか |
| カスタムSITの有無 | パスワード露出検知用のカスタムSITを作成済みか |
| 検知ロジック | 長さ、複雑性、キーワード近接を分けて設計しているか |
| 日本語対応 | passwordだけでなく、パスワード、認証情報、初期PWなどを考慮しているか |
| 対象ロケーション | Exchange、SharePoint、OneDrive、Teams、Endpointのどこに適用するか |
| 監査期間 | 本番ブロック前に検知件数と誤検知を確認する期間を設けているか |
| 通知文 | ユーザーが「何を直せばよいか」分かる文面になっているか |
| 例外管理 | 障害対応や検証環境など、正当な例外をどう扱うか |
| インシデント連携 | 検知後のパスワード変更、チケット化、証跡保管が決まっているか |
Microsoft Learnでは、カスタム分類や正規表現パターンの作成について、Microsoftサポートが要件充足を保証するものではないと説明しています。つまり、平文パスワード検知の精度は、各組織が自分たちのデータ、言語、業務フローで検証する必要があります。(Microsoft Learn)
まとめ：今回の更新は「検知設計を見直すきっかけ」として使う
2026年4月20日にMicrosoftが公開したPurviewの平文パスワード検知方法は、Microsoft Purview / Sensitive Information Types / DLPを運用する組織にとって、既存のデータ保護ポリシーを見直す良いきっかけです。
最初にやるべきことは、次の3つです。
- 平文パスワードが出やすい場所を洗い出す
- カスタムSITで、正規表現・複雑性・キーワード近接を組み合わせて検知する
- DLPでは監査から始め、通知、例外、ブロック、インシデント対応へ段階的に広げる
平文パスワード対策は、単なる正規表現の問題ではありません。検知精度、ユーザー体験、例外運用、パスワードローテーション、監査証跡まで含めて設計して初めて、実務で機能します。まずは小さなスコープでカスタムSITを作成し、実データに近いサンプルで検証するところから始めてください。
コメント