Microsoft Purview / Sensitive Information Types / DLPを使っている組織が今回まず取るべき行動は、平文パスワードを検出するCustom SITを作って、いきなりブロックすることではありません。最初にやるべきなのは、パスワードが出やすい場所を棚卸しし、Custom regexの検出精度をシミュレーションで確認し、外部共有・非管理AIアプリ・広範囲共有などリスクの高い経路から段階的にDLP制御を強めることです。
Microsoftは2026年4月20日、Microsoft PurviewのSensitive Information Typesでカスタム正規表現を使い、平文パスワード露出を検出する方法を公開しました。ポイントは、単純に「強そうな文字列」を拾うのではなく、長さ・複雑性・passwordやpwdのような文脈キーワードを組み合わせ、誤検知を抑えながら実際のパスワード共有に近いパターンを検出する設計にあります。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Purviewの平文パスワード検出は「検出ルール」ではなく「リスク低減策」として読むべき
今回のMicrosoft PurviewのCustom regexによる平文パスワード検出は、セキュリティチームにとって「新しい正規表現のサンプル」として読むだけでは不十分です。より重要なのは、パスワードがメール、Teams、SharePoint、OneDrive、端末、ブラウザ経由のクラウドアプリ利用など、複数の経路で漏えいし得ることを前提に、DLPポリシーの優先順位を見直すきっかけにすることです。
Microsoftの投稿では、MFAのような強力な認証制御があっても、レガシーシステム、サードパーティツール、サービスアカウントなどではパスワードだけに依存する場面が残り、平文で共有・保存された認証情報が重大なリスクになると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
つまり、今回の更新を読むときの実務上の結論は次の3つです。
- Custom SITは、平文パスワードを早期発見するための検出レイヤーとして使う
- DLPは、検出後に外部送信・アップロード・共有・印刷・コピーなどの危険な行動を抑制するために使う
- 検出されたパスワードは、DLPで止めるだけでなく、必ず失効・ローテーション・共有経路の是正まで行う
DLPは「漏れたものを見つける仕組み」であって、「漏れたパスワードを無害化する仕組み」ではありません。検出後のインシデント対応まで設計して初めて、安全対策として機能します。
Microsoftが示したCustom regex検出設計の要点
Microsoftの例では、平文パスワード検出を1本の巨大な正規表現に詰め込まず、Sensitive Information Typeのパターンを複数の要素に分けて設計しています。Microsoft PurviewのSITは、主要素、補助要素、信頼度、近接条件などで構成されるパターンベースの分類器です。(Microsoft Learn)
| 検出要素 | 役割 | 実務上の読み解き |
|---|---|---|
| Primary element | パスワード候補となる文字列を拾う | 文字列の長さや空白の有無で候補を絞る |
| Supporting element | 大文字・小文字・数字・記号などの複雑性を確認する | 単なる長い単語やIDを除外しやすくする |
| Keyword context | password、pwd、credentialなどの周辺語を確認する | APIキー、ハッシュ、ランダム文字列との誤検知を減らす |
| Proximity | 候補文字列と補助要素・キーワードの距離を制御する | 同じ文脈にある文字列だけを検出しやすくする |
Microsoftの投稿では、候補文字列の長さを10〜20文字とし、英字・数字・特殊文字の存在を確認し、さらにcredential、password、pwd、pswdなどのキーワードを近接条件で組み合わせる例が示されています。これにより、単なるランダム文字列ではなく、人が「パスワード」として書いた可能性が高い文字列を検出しやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
そのままコピーするのではなく、自社のパスワード実態に合わせる
Microsoftの例は有用ですが、そのまま本番環境へ適用するのは危険です。たとえば、自社のパスワードポリシーが「最小14文字」「パスフレーズ推奨」「記号必須ではない」場合、10〜20文字・記号必須の設計では見逃しが増える可能性があります。
見直すべき項目は、少なくとも次の通りです。
| 確認項目 | 設計に反映する内容 |
|---|---|
| 最小・最大文字数 | 10〜20文字に固定せず、自社ポリシーや実態に合わせる |
| 使用可能な文字 | 日本語入力、全角記号、スペースを含むパスフレーズを許可しているか確認する |
| キーワード | passwordだけでなく、パスワード、PW、仮パス、初期パスワード、認証情報などを検討する |
| 対象ワークロード | Exchange、SharePoint、OneDrive、Teams、Endpoint DLP、Edge for Businessなどの優先順位を決める |
| 誤検知除外 | テストデータ、手順書、教育資料、APIキー、ハッシュ、GUIDなどをどう扱うか決める |
日本語環境では、英語キーワードだけに依存すると検出漏れが起きます。Microsoft Learnでは、日本語や中国語などのダブルバイト文字と英数字が混在するキーワードを扱う場合、スペースあり・なしの両方のバリエーションを用意する考え方が示されています。たとえば「初期パスワード ABC123」のような表記と「初期パスワードABC123」のような表記は、別パターンとして考える必要があります。(Microsoft Learn)
優先すべきリスク低減策は「どこで検出するか」から決める
平文パスワード対策で失敗しやすいのは、検出ルールの精度だけに集中し、DLPポリシーの適用場所とアクション設計を後回しにすることです。Microsoft Purview DLPは、Microsoft 365の場所だけでなく、端末、オンプレミスのファイル共有、非Microsoftクラウドアプリなど、複数の場所や利用行動を対象にできます。DLPは単純なテキスト検索ではなく、正規表現、キーワード、近接する二次一致、内部関数、機械学習などを使ったコンテンツ分析を行います。(Microsoft Learn)
優先順位は、次のように「影響の大きさ」と「止めやすさ」で決めると実務に落とし込みやすくなります。
| 優先度 | 対象 | 推奨アクション |
|---|---|---|
| 最優先 | 外部宛てメール、外部共有リンク、非管理AIアプリへの貼り付け・アップロード | シミュレーション後、ブロックまたは強い警告。検出時は即時ローテーション |
| 高 | SharePoint / OneDrive上の広範囲共有ファイル、共有フォルダー内の資格情報一覧 | 共有範囲の縮小、所有者通知、必要に応じて隔離 |
| 高 | サービスアカウント、管理者アカウント、MFA未対応システムのパスワード | 検出時にHigh severityでアラート化し、認証情報を失効 |
| 中 | 社内メール、Teams、トラブルシューティングメモ、運用手順書 | ポリシーヒントで教育し、例外申請や正規の保管場所へ誘導 |
| 中 | 開発・運用部門のスクリプト、設定ファイル、台帳 | DevSecOpsやプラットフォームチームと連携し、VaultやマネージドIDへ移行 |
| 低 | 研修資料、検証用のダミーデータ、パスワードポリシー文書 | 除外条件やキーワード調整でノイズを抑える |
特に優先すべきなのは、外に出る経路です。平文パスワードが社内文書に残っているだけでも危険ですが、外部メール、外部共有、非管理クラウドアプリ、生成AIサービスへの貼り付けに乗ると、回収が難しくなります。Edge for Businessを制御点として非管理AIアプリへの共有をブロックするDLPシナリオもMicrosoft Learnで示されており、ブラウザ経由のデータ流出対策は優先度が上がっています。(Microsoft Learn)
Custom SITを作るときの実務設計
Custom SITは、検出精度を上げるための部品です。DLPポリシーで強いアクションをかける前に、SIT自体を読みやすく、保守しやすく、監査しやすい形にしておく必要があります。
Microsoft Purviewポータルでは、Information ProtectionのClassifiersからSensitive info typesを開き、Custom SITを作成できます。パターンにはPrimary element、Supporting elements、信頼度、Character proximityなどを設定できます。(Microsoft Learn)
推奨するSIT構成例
| 項目 | 設定例 | 判断基準 |
|---|---|---|
| SIT名 | Plaintext Password Exposure - High Confidence | 目的と信頼度が分かる名前にする |
| 説明 | 平文パスワードらしい文字列と周辺キーワードを検出 | 監査時に意図が分かるように書く |
| Primary element | 空白を含まない一定長の文字列 | 自社のパスワード長に合わせる |
| Supporting element 1 | 英字、数字、特殊文字などの複雑性条件 | 自社ポリシーと実態を優先する |
| Supporting element 2 | password、pwd、credential、パスワード、仮パスなど | 英語・日本語・略語を含める |
| Proximity | キーワードと候補文字列が同じ文脈にある距離 | 近すぎると漏れ、広すぎると誤検知が増える |
| Confidence level | Highを基本に、必要ならMediumを別パターン化 | ブロック用途では高信頼を優先する |
Microsoftの例では、候補文字列を拾うPrimary elementと、複雑性を確認するSupporting element、文脈を確認するキーワード要素を分離しています。これは、1本の複雑な正規表現よりも、保守・説明・監査がしやすい設計です。(TECHCOMMUNITY.MICROSOFT.COM)
Primary elementの例
\S{10,20}この例は「空白を含まない10〜20文字」を候補にします。ただし、実務では次のような調整が必要です。
- パスフレーズを使う組織では、空白を含むパターンも検討する
- 20文字を超える管理者用パスワードやランダム生成パスワードがある場合、最大長を広げる
- 記号の種類を制限しすぎると、実際のパスワードを見逃す
- 広げすぎると、APIキー、トークン、ハッシュ、GUIDとの誤検知が増える
なお、Microsoft Learnでは、Custom SIT内の正規表現で^や$のような位置アンカーを使うと、スキャン時に意図通り動作しない可能性があるため避けるよう案内されています。正規表現を作る際は、通常のアプリケーション開発での動作とPurview上での動作を同一視しないことが重要です。(Microsoft Learn)
キーワードは「英語だけ」では足りない
グローバル組織や日本法人を含む組織では、キーワードを言語別に設計する必要があります。英語圏のpassword、pwd、credentialだけでは、日本語の運用文書やチャットに出てくる平文パスワードを拾いにくくなります。
日本語環境で検討したいキーワード例は次の通りです。
| 種別 | キーワード例 |
|---|---|
| 一般表現 | パスワード、PW、pwd、password、passcode |
| 運用表現 | 初期パスワード、仮パス、暫定パスワード、認証情報 |
| 台帳表現 | ID、ユーザーID、ログイン情報、接続情報 |
| 注意が必要な表現 | シークレット、secret、token、APIキー |
ただし、secretやtokenまで広げると、パスワード以外の認証情報も大量に検出する可能性があります。パスワード専用SITと、APIキー・トークン検出用SITを分けると、アラートの優先順位付けがしやすくなります。
DLPポリシーはシミュレーションから段階的に展開する
Custom SITを作った後にやってはいけないのは、全社・全ワークロード・即時ブロックで展開することです。平文パスワード検出は、誤検知でも業務影響が大きく、逆に検出漏れでもリスクが残ります。最初は影響を測るためにシミュレーションを使うべきです。
Microsoft Learnでは、影響の大きいDLPポリシーは、まずシミュレーションモードでポリシーヒントなしに実行し、DLPレポートやインシデントレポートで件数・場所・種類・重大度を確認し、その後ポリシーヒント付きのシミュレーション、最後に本番適用へ進む段階的展開が推奨されています。(Microsoft Learn)
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| SIT単体テスト | 一致するサンプル、一致しないサンプルを用意してSITをテスト | 想定通りの一致・不一致が確認できる |
| シミュレーション | DLPポリシーをブロックなしで実行 | 影響範囲、誤検知、検出場所が把握できる |
| 通知付きシミュレーション | ポリシーヒントやメール通知を表示 | ユーザー教育と例外申請の導線が機能する |
| 部分適用 | 外部共有、非管理AIアプリ、特定部門などから制御 | 高リスク経路で過剰ブロックが起きない |
| 全体適用 | 必要な場所へ段階的に拡大 | アラート対応、ローテーション、監査が回る |
SITは、Purviewポータル上でサンプルファイルを使ってテストできます。テスト結果では、信頼度ごとの一致数を確認できます。(Microsoft Learn)
DLPシミュレーションモードでは、ポリシー作成時または作成後にシミュレーションを有効化でき、シミュレーション中にポリシーヒントを表示する選択肢もあります。なお、シミュレーション結果は長期間実行しても表示対象が直近30日分に限られるため、レビューのタイミングを決めて運用する必要があります。(Microsoft Learn)
DLPアクションは「検出件数」ではなく「流出経路」で分ける
平文パスワードのDLPポリシーでは、検出件数だけでSeverityを決めるのは適切ではありません。パスワードは1件でも重大です。特に、管理者アカウント、サービスアカウント、MFA未対応システム、外部接続用アカウントの認証情報であれば、1件でもインシデント扱いにすべきです。
DLPポリシーのアクションは、次のように使い分けると実務に向いています。
| シナリオ | 推奨アクション | 補足 |
|---|---|---|
| 外部宛てメールに平文パスワード | ブロック、または承認付き例外 | 送信者教育だけでなく、該当パスワードの失効が必要 |
| SharePoint / OneDriveで外部共有 | 共有停止、アクセス制限、必要に応じて隔離 | ファイル所有者とシステム管理者へ通知 |
| Teamsや社内メールで共有 | 通知、ポリシーヒント、再発防止案内 | まず運用改善と教育に使う |
| 非管理AIアプリへの貼り付け | ブロックまたは強い警告 | 入力後の回収が難しいため優先度が高い |
| 端末からUSB、印刷、クリップボード | Endpoint DLPで監視・制御 | 高リスク部門から段階導入する |
Endpoint DLPでは、オンボードされたWindows 10/11、macOSの近年の主要バージョンなどを対象に、機密アイテムに対するユーザー行動を可視化し、DLPポリシーで保護アクションを適用できます。(Microsoft Learn)
SharePointやOneDrive上のファイルについては、条件に一致したファイルを隔離するDLPポリシーも利用できます。Microsoft Learnでは、隔離アクションを有効化する前にシミュレーションモードで影響を評価し、Activity ExplorerやDLPアラートダッシュボードで対象ファイルが期待通りか確認する手順が示されています。(Microsoft Learn)
アラート対応は「検出」ではなく「資格情報の無効化」までを1つの流れにする
平文パスワード検出のDLPアラートが上がったとき、セキュリティチームが見るべきポイントは「どの文字列が検出されたか」だけではありません。むしろ重要なのは、その文字列がどのアカウントに紐づく可能性があるか、どこへ共有されたか、すでに使われた可能性があるかです。
DLPアラートは、Microsoft PurviewポータルやMicrosoft Defender XDRで調査・管理できます。Microsoftは、DLPポリシーの作成・編集はPurviewポータル、アラートの調査・管理はMicrosoft Defender XDRを推奨しています。(Microsoft Learn)
平文パスワード検出時の対応プレイブック
| ステップ | 確認・対応内容 |
|---|---|
| トリアージ | 送信者、所有者、共有先、外部公開有無、対象ワークロードを確認 |
| 影響評価 | 文字列が実在する認証情報か、どのシステムに関係するかを確認 |
| 封じ込め | 外部共有リンク停止、メール回収可否の確認、ファイル隔離、アクセス制限 |
| 資格情報対応 | パスワード変更、トークン失効、セッション失効、サービスアカウントのローテーション |
| 監査 | サインインログ、異常アクセス、権限変更、データアクセス履歴を確認 |
| 再発防止 | パスワードマネージャー、Secrets Vault、PAM、Managed Identityなどへ移行 |
| ルール改善 | 誤検知・見逃しをSIT、キーワード、除外条件へ反映 |
ここで注意すべきなのは、PurviewのSITが検出するのは「パスワードらしい文字列」であり、その文字列が本当に有効なパスワードかどうかまでは保証しない点です。逆に、実在するパスワードであっても、ルールの長さ、文字種、キーワード、スキャン対象外の場所によって検出されない可能性があります。したがって、DLPアラートは自動判定の完了ではなく、調査開始のトリガーとして扱うべきです。
誤検知を減らすには「広く拾って人が見る」より「文脈で絞る」
平文パスワード検出で最も多い失敗は、広すぎる正規表現で大量のランダム文字列を拾い、SOCやセキュリティチームがアラート疲れを起こすことです。特に、ハッシュ値、APIキー、GUID、チケット番号、サンプルコード、教育資料はノイズになりやすい領域です。
Microsoft Learnでは、SITの追加チェックとして、特定キーワードの除外、開始文字・終了文字の条件、プレフィックスやサフィックスの包含・除外などを設定できることが説明されています。これらは、パスワード検出でも誤検知削減に役立ちます。(Microsoft Learn)
| 誤検知パターン | 原因 | 対策 |
|---|---|---|
| APIキーやトークンをパスワードとして検出 | 強い文字列パターンが似ている | API_KEY、token、Bearerなどを別SITまたは除外条件で扱う |
| ハッシュ値を検出 | 英数字の長い文字列を拾っている | 長さ、文字種、周辺キーワードで分離する |
| パスワードポリシー文書を検出 | 「Password」とサンプル文字列が近い | 教育資料や規程ページを別スコープにする |
| テストデータを検出 | ダミー認証情報が本物の形式に近い | テスト用プレフィックス、保管場所、サイト単位の除外を検討する |
| 日本語文書で見逃す | 英語キーワードしか入れていない | 日本語キーワード、スペースあり・なしの表記揺れを追加する |
| 長いパスフレーズを見逃す | 最大長が短すぎる | パスフレーズ用の別パターンを作る |
また、Endpoint DLPではテナント内の利用可能なSITに基づき分類が行われるため、未調整のCustom SITが多くのファイルに一致すると分類トラフィックが増える可能性があります。Microsoft Learnでも、未使用のSITの削除や、ほとんどのファイルに一致するSITの再設計が推奨されています。(Microsoft Learn)
ポリシーヒントとユーザー通知は「教育」と「例外処理」のために使う
平文パスワードの共有は、悪意よりも「急ぎの作業」「一時対応」「引き継ぎ」「障害対応」で起きることが多いものです。したがって、DLPをいきなり罰則的に運用すると、ユーザーは別の抜け道を探し始めます。重要なのは、ポリシーヒントで「なぜ危険なのか」と「代わりに何を使うべきか」を短く伝えることです。
Microsoft Purview DLPでは、ルールごとに通知やユーザーオーバーライドを設定できます。ただし、複数のルールに一致した場合は、最も制限の強い優先度の高いルールのポリシーヒントが表示される仕組みです。(Microsoft Learn)
ポリシーヒントには、次のような実務的な文言を入れると効果的です。
平文パスワードの共有が検出されました。パスワードはメール・チャット・共有ファイルに記載せず、承認済みのパスワード管理ツールまたはSecrets Vaultを使用してください。すでに共有した場合は、対象パスワードを変更し、セキュリティチームへ連絡してください。
ただし、ポリシーヒントにはクライアントや条件による制約があります。たとえばOutlook for Microsoft 365のポリシーヒントでは、メッセージ本文や添付ファイルの処理サイズに制限があるため、ユーザー通知だけを過信しない設計が必要です。(Microsoft Learn)
Security teams、compliance leads、platform architectsの役割分担
平文パスワード対策は、セキュリティチームだけで完結しません。Microsoft Purview / Sensitive Information Types / DLPを安全対策として機能させるには、役割ごとに責任を分ける必要があります。
| 役割 | 主な責任 |
|---|---|
| Security teams | 検出ルール、アラート対応、資格情報のローテーション、インシデント調査 |
| Compliance leads | ポリシー文言、監査証跡、例外承認、規程との整合性 |
| Platform architects | 対象ワークロード、Endpoint DLP、Edge for Business、Intune、Secrets管理基盤の設計 |
| IT operations | サービスアカウント管理、パスワード変更手順、障害対応時の代替運用 |
| Business owners | 業務影響の評価、例外要件、現場への周知 |
特にPlatform architectsは、DLPを「最後の砦」として扱うだけでなく、パスワードを平文で扱わなくても済む構造へ変える責任があります。たとえば、クラウド環境ではManaged IdentityやKey Vault、オンプレミスではPAMや特権ID管理、運用部門では承認済みのパスワードマネージャーを整備する、といった設計が必要です。
導入前に確認すべきチェックリスト
本番展開前には、次のチェックリストを使って抜け漏れを確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 検出目的 | 平文パスワードだけを検出するのか、APIキーやトークンも含めるのか |
| 対象範囲 | Exchange、SharePoint、OneDrive、Teams、Endpoint、Edge for Businessの優先順位 |
| 言語対応 | 英語・日本語・略語・部門固有の表現を含めたか |
| 正規表現 | 自社のパスワード長、文字種、パスフレーズ方針に合っているか |
| 誤検知対策 | テストデータ、手順書、教育資料、APIキー、ハッシュの扱いを決めたか |
| シミュレーション | ブロックなしで影響範囲を確認したか |
| アラート | 重要度、通知先、単発アラート・集約アラートの使い分けを決めたか |
| 対応手順 | 検出後のパスワード変更、共有停止、監査確認の手順があるか |
| ユーザー案内 | ポリシーヒントに代替手段と問い合わせ先を書いたか |
| 継続改善 | 誤検知・見逃しをルールへ反映する運用があるか |
DLPアラートは、ルール一致のたびに発報する単発アラートと、一定期間内の複数イベントをまとめる集約アラートを使い分けられます。平文パスワードのように1件でも重要度が高い事象では、単発アラートを使う場面が多くなりますが、部門やワークロードによっては集約設計も検討すべきです。(Microsoft Learn)
まとめ：Custom regexは入口、優先すべきは検出後のリスク低減
Microsoft PurviewのCustom regexによる平文パスワード検出は、Sensitive Information TypesとDLPを使う組織にとって有用な実装パターンです。ただし、正規表現を追加するだけでは安全対策として不十分です。
最初に取り組むべきことは、次の順番です。
- パスワードが出やすい業務経路を洗い出す
- 自社のパスワード実態に合わせてCustom SITを設計する
- 英語・日本語のキーワードと近接条件で誤検知を抑える
- DLPポリシーをシミュレーションで検証する
- 外部共有、非管理AIアプリ、広範囲共有など高リスク経路から制御する
- 検出後は必ず資格情報の失効・ローテーション・再発防止まで行う
次に取るべき具体的な行動は、全社展開ではなく、高リスクな1つの経路を選んで小さく検証することです。たとえば、外部宛てメール、SharePointの外部共有、非管理AIアプリへの送信のいずれかを対象に、Custom SITを作成し、シミュレーションで検出結果を確認します。その結果をもとに、キーワード、正規表現、除外条件、通知文言、アラート対応手順を整えてから、段階的に範囲を広げていくのが安全です。
コメント