Microsoft Purviewで平文パスワードを見つけるなら、単純な「password」という文字列検索では不十分です。実務では、強いパスワードらしい文字列と、それがパスワードとして書かれている文脈を組み合わせて検出する必要があります。
2026年4月20日、MicrosoftはMicrosoft Purviewでカスタム正規表現を使い、平文パスワードの露出を検出する方法を公開しました。ポイントは、Sensitive Information Types（SIT）をカスタマイズし、文字列の長さ・複雑性・キーワード近接を分けて設計することです。これにより、メール、SharePoint、OneDrive、Teams関連のコラボレーション領域、Endpoint DLPなどで、インシデント化する前のパスワード漏えい候補を見つけやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、Purview管理者、データセキュリティ担当者、コンプライアンス設計者向けに、Microsoft Purview / Sensitive Information Types / DLPで平文パスワード検出を実装するための実践プレイブックをまとめます。
Microsoft Purviewで平文パスワードを検出すべき理由
MFAや条件付きアクセスを導入していても、平文パスワードの露出リスクは残ります。特に問題になりやすいのは、次のようなケースです。
- レガシーシステムや外部サービスがパスワード認証に依存している
- サービスアカウントの資格情報がExcelやメモに残っている
- トラブルシューティング時に一時的なパスワードをメールで共有している
- ベンダーや委託先とのやり取りで認証情報が文書化されている
- MFA対象外の管理外システムが残っている
Microsoftの記事でも、パスワードがメール、コラボレーションサイト上の文書、トラブルシューティング用メモ、資格情報管理用スプレッドシートなどに残る例が挙げられています。平文パスワードは、漏えいした瞬間に「機密情報」から「侵害の材料」に変わるため、DLPで早期検出する価値があります。(TECHCOMMUNITY.MICROSOFT.COM)
重要なのは、パスワードらしい強い文字列をすべて止めることではなく、パスワードとして保存・共有されている可能性が高いものを高精度で見つけることです。ランダムなAPIキー、ハッシュ値、トークン、ファイル名まで大量に検出すると、運用担当者がアラート疲れを起こします。
Microsoftが示した検出アプローチの要点
Microsoftが公開した方法は、Microsoft PurviewのカスタムSITで、平文パスワード検出ロジックを3つの要素に分ける設計です。
| 要素 | 役割 | 例 |
|---|---|---|
| Primary element | パスワード候補の文字列を拾う | \S{10,20} |
| Supporting element：複雑性 | 大文字・小文字・数字・記号などの条件を確認する | [A-Z]、[a-z]、[0-9]、[!@#$%&*+=] |
| Supporting element：キーワード | 人間が「これはパスワード」と書いた文脈を確認する | password、pwd、credential、pswd |
この設計の利点は、1本の巨大な正規表現にすべてを詰め込まないことです。Microsoft PurviewのSITは、Primary element、Supporting element、信頼度、近接条件で構成されます。Supporting elementは、検出対象の周辺証拠として使われ、検出の信頼度を高めるために利用されます。(Microsoft Learn)
つまり、次のような単純検索ではありません。
passwordまた、次のような「強そうな文字列なら何でも拾う」設計でもありません。
[A-Za-z0-9!@#$%^&*()_+\-=]{10,20}実務で使いやすいのは、次のように段階的に判定する設計です。
Password: P@ssW0rd123!
credential=Adm1n#Secure
pwd -> Qwerty@2024!一方で、次のような文字列は、強い文字列に見えてもパスワード共有とは限りません。
RandomStrongString123!
API_KEY = A9$kLmZpQwDLPの目的は「疑わしいものを全部拾う」ではなく、対応すべき漏えい候補を現実的な件数で拾うことです。
カスタムSITで平文パスワードを検出する基本設計
Microsoftの記事で示された例では、検出対象となるパスワードの条件は次のように整理されています。
| 条件 | 設定例 | 実務上の意味 |
|---|---|---|
| 最小文字数 | 10文字 | 短すぎる一般語やコード片を除外しやすい |
| 最大文字数 | 20文字 | 長いトークンやハッシュ値との混同を減らしやすい |
| 英字 | 必須 | パスワードポリシーに沿った文字列を拾う |
| 数字 | 必須 | 複雑性要件に合わせる |
| 記号 | 必須 | 強いパスワード候補に絞る |
| キーワード近接 | 必須 | 「password」「pwd」などの文脈を確認する |
Primary elementは「候補を拾う」だけにする
Primary elementの例は次のとおりです。
\S{10,20}これは、空白を含まない10〜20文字の文字列を候補として拾うためのパターンです。
この時点では、まだ「パスワードである」とは判断しません。Primary elementの役割は、あくまで候補抽出です。ここに複雑性、キーワード、除外条件を詰め込みすぎると、後から調整しにくくなります。
Microsoftの例では、Primary elementとSupporting elementの距離を近く設定し、複雑性チェックが同じ候補文字列に対して評価されるようにしています。(TECHCOMMUNITY.MICROSOFT.COM)
複雑性チェックはSupporting elementで分ける
複雑性の確認には、次のような正規表現をSupporting elementとして使います。
| 要件 | Regex例 |
|---|---|
| 大文字を1文字以上含む | [A-Z] |
| 小文字を1文字以上含む | [a-z] |
| 数字を1文字以上含む | [0-9] |
| 記号を1文字以上含む | [!@#$%&*+=] |
| 許可文字セットと長さ | [A-Za-z0-9!@#$%^&*()_+\-=]{10,} |
この分割設計は、監査やレビューでも説明しやすいのが利点です。
たとえば、セキュリティ委員会や内部監査で「なぜこの文字列をパスワード候補と判定したのか」と聞かれた場合、次のように説明できます。
10〜20文字の非空白文字列であり、
大文字・小文字・数字・記号を含み、
近くに password / pwd / credential などのキーワードがあるため、
平文パスワード共有の可能性が高いと判定した。一方、1本の巨大な正規表現にすると、検出理由の説明や部分修正が難しくなります。
キーワード近接で誤検知を減らす
平文パスワード検出で最も重要なのは、キーワード近接です。
強い文字列だけを拾うと、APIキー、ランダムID、ハッシュ、製品コード、チケット番号、ファイル名などが混ざります。そこで、パスワード候補の近くに、人間が認証情報として書いたことを示すキーワードがあるかを確認します。
Microsoftの例では、次のようなキーワードが使われています。
credential
password
pwd
pswdこれらは大文字・小文字を区別しない設定にすることで、次のような表記揺れにも対応できます。
Password
PASSWORD
Pwd
PWD
PswdMicrosoftの例では、キーワードとパスワード候補の近接値として30文字が示されています。これは、最大10文字程度のキーワードと最大20文字のパスワードを同じ文脈内で検出する考え方です。(TECHCOMMUNITY.MICROSOFT.COM)
日本語環境ではキーワードを追加する
グローバル企業や日本語環境では、英語キーワードだけでは検出漏れが起きます。実務では、次のような日本語キーワードも検討してください。
| 用途 | キーワード例 |
|---|---|
| 一般的なパスワード表記 | パスワード、ぱすわーど、PW、pwd |
| 認証情報 | 資格情報、認証情報、ログイン情報 |
| 一時利用 | 一時パスワード、初期パスワード、仮パスワード |
| 運用メモ | 管理者パスワード、共有アカウント、サービスアカウント |
ただし、日本語キーワードを追加する場合は、Microsoft Purviewにおける日本語などのダブルバイト文字の扱いに注意が必要です。Microsoft Learnでは、カスタムSITが日本語などのダブルバイト文字をサポートする一方、日本語と英数字が混在するパターンでは、スペース有無のバリエーションを考慮する必要があると説明されています。(Microsoft Learn)
たとえば、次の両方をテスト対象に入れると安全です。
パスワード:P@ssW0rd123!
パスワード: P@ssW0rd123!初期パスワード=P@ssW0rd123!
初期パスワード = P@ssW0rd123!Purview管理者向けの実装手順
Microsoft Purviewポータルでは、Information Protection配下のClassifiersからSensitive info typesを作成できます。カスタムSITでは、Primary elementに正規表現、Supporting elementに正規表現・キーワードリスト・キーワード辞書などを設定できます。(Microsoft Learn)
実務では、いきなり本番DLPでブロックせず、次の順番で進めるのが安全です。
| フェーズ | 実施内容 | 目的 |
|---|---|---|
| 設計 | 検出条件、対象ワークロード、対応フローを決める | 誤検知と過検知を防ぐ |
| SIT作成 | カスタムSensitive Information Typeを作る | 検出ロジックを定義する |
| テスト | サンプル文書・メールで検証する | 検出漏れと誤検知を確認する |
| 監査モード運用 | DLPを通知・監査中心で動かす | 実データで件数と傾向を見る |
| 段階的強化 | 外部共有ブロック、管理者通知などを追加する | リスクの高い経路から制御する |
手順：カスタムSITを作成する
Microsoft Purviewポータルでの大まかな流れは次のとおりです。
- Microsoft Purviewポータルにサインインする
- Information Protection → Classifiers → Sensitive info types を開く
- Create sensitive info type を選択する
- 名前と説明を入力する
- パターンを作成する
- Primary elementにパスワード候補のRegexを設定する
- Supporting elementに複雑性チェック用Regexを追加する
- Supporting elementにキーワードリストを追加する
- Character proximityを設定する
- 信頼度を設定する
- サンプルデータでテストする
- 保存後、DLPポリシーや自動ラベル付けなどで利用する
名前は、後から運用者が目的を理解できるようにします。
Plaintext Strong Password Candidate - High Confidence日本語名にする場合も、対象と信頼度が分かる名前にします。
平文パスワード候補_高信頼度説明欄には、検出条件を短く残しておくとレビューしやすくなります。
10〜20文字の非空白文字列で、大文字・小文字・数字・記号を含み、password/pwd/credential等のキーワード近接がある平文パスワード候補を検出する。Regex設計で失敗しやすいポイント
PurviewのRegexは、一般的なテキストエディタやRegexテストサイトで期待どおりに動いても、DLP上では同じ結果にならないことがあります。Microsoft Learnでは、DLPのRegexはコンテンツそのものではなく抽出されたテキストに対して評価されるため、見た目どおりに一致しない場合があると説明されています。(Microsoft Learn)
先頭・末尾アンカーに頼りすぎない
カスタムSITでは、^ や $ のような位置アンカーを安易に使うと、抽出テキストの構造によって想定外の結果になることがあります。Microsoft Learnでも、カスタムSITで位置アンカーを使うと意図どおりに動かない可能性があると注意されています。(Microsoft Learn)
避けたい例です。
^password:\s*\S{10,20}$メール本文では自然に見えても、DLPの抽出テキストでは件名や他の文字列が先に連結されることがあります。より実務向きなのは、Primary elementとSupporting element、近接条件で文脈を判定する設計です。
強すぎる正規表現を1本で書かない
次のような正規表現は、見た目は便利ですが、運用では扱いにくくなります。
(?=.*[A-Z])(?=.*[a-z])(?=.*[0-9])(?=.*[!@#$%&*+=])\S{10,20}問題は、どの条件で一致したのか、どこで外れたのかを説明しにくいことです。SITのSupporting elementを使えば、条件を分けて監査しやすくできます。
APIキーやトークンとの混同を防ぐ
パスワード検出では、次のような文字列が誤検知になりやすいです。
| 誤検知候補 | なぜ混ざるか | 対策 |
|---|---|---|
| APIキー | 英数字と記号を含む長い文字列が多い | api_key、token周辺を別SITで扱う、または除外設計を検討する |
| ハッシュ値 | ランダム文字列に見える | 長さ上限を設定し、キーワード近接を必須にする |
| UUID | 規則的だが長い | ハイフン形式や長さで除外しやすい |
| 製品コード | 大文字・数字・記号を含む | license、serialなど別文脈を分ける |
| テストデータ | P@ssW0rd123!のような例が多い | テスト用キーワードや検証環境を区別する |
「強い文字列」だけで止めるのではなく、「password」「credential」「初期パスワード」などの近接キーワードを必須にすることが、実運用での精度を左右します。
DLPポリシーに組み込むときの判断基準
カスタムSITを作ったら、次はDLPポリシーでどう扱うかを決めます。最初から全社でブロックすると業務影響が大きくなりやすいため、段階的に進めるのが現実的です。
| レベル | 推奨アクション | 向いている状況 |
|---|---|---|
| 低 | 監査ログ記録のみ | 初期導入、検出件数の把握 |
| 中 | 管理者通知、ユーザー通知 | 業務影響を抑えながら改善したい |
| 高 | 外部共有の警告、正当化理由の入力 | 誤検知が一定以下に下がった段階 |
| 重大 | 外部送信・外部共有をブロック | 管理者権限、サービスアカウント、顧客環境に関わる認証情報 |
おすすめは、次の順番です。
監査のみ
↓
管理者通知
↓
ユーザーへのポリシーヒント表示
↓
外部共有時の警告・正当化理由
↓
高リスク条件のみブロック特に外部共有や外部メール送信は、平文パスワードが侵害材料になりやすい経路です。まずは外部宛てのメール、社外共有リンク、個人デバイスへのコピーなど、リスクの高い出口から制御すると効果が出やすくなります。
対象ワークロード別の使い方
Microsoft PurviewのSensitive Information Typesは、DLPポリシー、感度ラベル、自動ラベル付け、Insider Risk Management、Communication Complianceなどで利用できます。(Microsoft Learn)
平文パスワード検出では、特に次の領域で効果があります。
| 対象 | 検出したい例 | 初期対応 |
|---|---|---|
| Exchange / メール | Password: P@ssW0rd123!を外部宛てに送信 | 警告、管理者通知、外部送信ブロック |
| SharePoint | 手順書や台帳に管理者パスワードを記載 | 所有者通知、ラベル付け、共有制限 |
| OneDrive | 個人領域に認証情報メモを保存 | ユーザー通知、教育、削除依頼 |
| Teams関連コンテンツ | チャットや共有ファイルに一時パスワードを記載 | ポリシーヒント、監査 |
| Endpoint DLP | ローカルファイルやUSBコピー | コピー制御、監査、例外申請 |
ここで大切なのは、DLPを単なる「禁止ルール」にしないことです。ユーザーがパスワードを共有している背景には、代替手段がないこともあります。検出と同時に、パスワードマネージャー、シークレット管理、Privileged Access Management、Just-In-Timeアクセスなどの安全な手段に誘導する必要があります。
サンプルテストデータで検証する
SITを作成したら、必ずサンプルデータでテストします。Microsoft Learnでは、SITはサンプルファイルをアップロードして検出結果を確認できると説明されています。(Microsoft Learn)
テストでは、検出されるべきデータと、検出されるべきでないデータの両方を用意します。
検出されるべき例
Password: P@ssW0rd123!
pwd -> Qwerty@2024!
credential=Adm1n#Secure
初期パスワード: Secur3#Temp
管理者パスワード = Admin@2026!検出されないことを確認したい例
RandomStrongString123!
API_KEY = A9$kLmZpQw
token = XyZ123456789
serial = ABCD-1234-EFGH
sample text onlyテスト観点は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| 検出漏れ | password、pwd、日本語キーワードで拾えるか |
| 誤検知 | APIキーやハッシュを拾いすぎないか |
| 近接条件 | キーワードと候補文字列が離れた場合に検出しないか |
| 文字種 | 大文字・小文字・数字・記号の条件が効いているか |
| 長さ | 9文字以下、21文字以上を想定どおり扱うか |
| 日本語 | パスワード:値とパスワード: 値の両方を検証したか |
テスト時は、実在するパスワードを使わないでください。検証用のダミー文字列だけを使い、テスト文書そのものが新たな漏えいリスクにならないようにします。
運用で見るべきKPI
平文パスワード検出は、作って終わりではありません。導入後は、検出件数だけでなく、対応の質を見ます。
| KPI | 見る理由 |
|---|---|
| 検出件数 | ルールが広すぎるか、実際に問題が多いかを判断する |
| 誤検知率 | 運用負荷とユーザー体験に直結する |
| 外部共有・外部送信の件数 | 侵害リスクの高い経路を把握する |
| 対応完了までの時間 | 漏えい候補を放置していないか確認する |
| 再発ユーザー・部門 | 教育や業務プロセス改善の対象を特定する |
| 例外申請件数 | ルールが業務を阻害していないか判断する |
特に重要なのは、検出結果を責めるために使わないことです。パスワードが平文保存される背景には、属人化した運用、古いシステム、共有アカウント、ベンダーとの慣習があります。DLPのアラートは、業務プロセスを改善するためのシグナルとして扱うべきです。
例外設計とエスカレーション
DLPで平文パスワード候補を検出した場合、すべてを同じ重大度で扱うと運用が破綻します。次のようにリスク別に対応を分けます。
| リスク | 例 | 対応 |
|---|---|---|
| 低 | 社内限定の古いテスト文書 | 所有者に削除・修正依頼 |
| 中 | OneDrive上の個人メモ | ユーザー通知、管理者レビュー |
| 高 | 社外共有された手順書 | 共有停止、パスワード変更 |
| 重大 | 管理者アカウントやサービスアカウントの平文記載 | 即時無効化、ローテーション、インシデント対応 |
特に、次の条件に該当する場合は、単なるDLPイベントではなくセキュリティインシデント候補として扱うべきです。
- 外部ユーザーに共有されている
- 管理者権限を持つアカウントの可能性がある
- サービスアカウントや共有アカウントに見える
- 複数文書に同じ認証情報が記載されている
- 過去にも同じユーザーまたは部門で検出されている
- パスワード変更や失効の記録が確認できない
検出後の対応手順も、あらかじめ決めておきます。
検出
↓
所有者・場所・共有範囲を確認
↓
実在する認証情報かを安全に確認
↓
共有停止または削除
↓
該当アカウントのパスワード変更・失効
↓
必要に応じて監査ログ確認
↓
再発防止策を実施導入時の注意点
既存コンテンツの再クロールを考慮する
SharePointやOneDrive上の既存コンテンツを検出したい場合、すぐにすべての既存ファイルが分類されるとは限りません。Microsoft Learnでは、SharePointとOneDriveの既存コンテンツで新しいカスタムSITを識別するには、コンテンツの再クロールが必要になる場合があると説明されています。(Microsoft Learn)
導入直後に検出件数が少なくても、ルールが効いていないとは限りません。テストファイル、新規作成ファイル、既存ファイルの再評価タイミングを分けて確認してください。
高信頼度から始める
最初は高信頼度の条件に絞るのがおすすめです。
強い文字列
+ 複雑性条件
+ password/pwd/credential等の近接キーワード
+ 外部共有または外部送信この組み合わせなら、運用担当者が確認すべきイベントに絞りやすくなります。
低信頼度まで広げるのは、運用が安定してからで十分です。Microsoft Learnでも、高信頼度は誤検知が少ない一方で検出漏れが増える可能性があり、低信頼度はその逆になりやすいと説明されています。(Microsoft Learn)
検出ルールと教育をセットにする
DLPでブロックするだけでは、ユーザーは別の抜け道を探します。
たとえば、メール送信を止めても、チャット、個人メモ、スクリーンショット、外部ストレージに移る可能性があります。ルール導入時には、次のような代替手段を明示してください。
- パスワードはチャットやメールで送らない
- 共有が必要な場合は承認済みのパスワード管理ツールを使う
- 一時パスワードは初回ログイン後に変更させる
- サービスアカウントは所有者、用途、ローテーション周期を管理する
- ベンダー連携では認証情報の受け渡し方法を契約・手順に明記する
ユーザーにとって「何が禁止か」だけでなく、「どうすればよいか」が分かる状態にすることが、DLP運用の成功条件です。
実務で使える設計テンプレート
最後に、Purview管理者がそのまま検討に使える設計テンプレートをまとめます。
| 項目 | 推奨設定例 |
|---|---|
| SIT名 | Plaintext Strong Password Candidate |
| 検出目的 | 強いパスワード候補が平文で保存・共有されている状態を検出する |
| Primary element | \S{10,20} |
| 複雑性Supporting element | 大文字、小文字、数字、記号、許可文字セット |
| キーワードSupporting element | password、pwd、pswd、credential、パスワード、資格情報、初期パスワード |
| 近接値 | 英語中心なら30文字を起点に調整 |
| 初期信頼度 | High confidence |
| 初期DLPアクション | 監査、管理者通知、ユーザー通知 |
| 強化対象 | 外部メール、外部共有、Endpointコピー |
| 除外検討 | APIキー、トークン、ハッシュ、シリアル番号、テストデータ |
| レビュー頻度 | 導入初期は週次、安定後は月次 |
Microsoft Purviewで平文パスワードを検出する次の一手
Microsoft Purviewで平文パスワードを検出する実務上の結論は、強い文字列だけを見るのではなく、SITのPrimary element、Supporting element、キーワード近接を組み合わせることです。
まずは、次の3点から始めてください。
- 自社のパスワード表記に合わせてキーワードを洗い出す
- Microsoftの例をベースにカスタムSITを作成し、サンプルデータで検証する
- DLPは監査モードから始め、外部共有・外部送信など高リスク経路から段階的に強化する
平文パスワードは、見つけた時点で終わりではありません。検出後に、共有停止、削除、パスワード変更、再発防止までつなげて初めて、DLPの価値が出ます。
Microsoft Purview / Sensitive Information Types / DLPを使えば、パスワード漏えいを「事故が起きてから探す」運用から、「侵害材料になる前に見つけて止める」運用へ移行できます。
コメント