Microsoft Purview / data protection for legacy systems を使う組織がまず行うべきことは、平文パスワードを見つける正規表現を作ることだけではありません。優先すべきは、MFAやパスワードレスに移行できていないレガシー業務を特定し、平文パスワードの露出検出、共有制御、資格情報のローテーション、認証方式の近代化を一つのリスク低減計画として進めることです。
2026年4月20日に Microsoft Security Community Blog が公開した更新は、Microsoft Purview のカスタム検出を使い、メール、文書、スプレッドシート、トラブルシューティング用メモなどに残る平文パスワードを検出する考え方を示しています。特に、レガシーシステム、サードパーティーツール、サービスアカウントなど、パスワードだけに依存しがちな業務が残る組織では、この更新を「検出ルールの小技」ではなく、認証を近代化しきるまでの補完的な安全対策として読むべきです。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Purview の更新を安全対策の文脈でどう読むべきか
今回のポイントは、Microsoft Purview が平文パスワード検出に使える、という単純な話ではありません。重要なのは、パスワード-only ワークフローが残る現実を前提に、データ保護側で露出を早く見つけ、被害を小さくするという考え方です。
Microsoft の投稿では、MFAのような強い認証があっても、レガシーシステム、サードパーティーツール、サービスアカウントなどではパスワードのみの認証が残りやすく、資格情報がメール、共同作業サイト、メモ、スプレッドシートなどに平文で保存・共有されるリスクがあると説明されています。さらに、Microsoft Purview の Sensitive Information Types、つまり SIT をカスタム正規表現で拡張し、パスワードらしい文字列をコンテキスト付きで検出する方法が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
ここで誤解してはいけないのは、Purview のカスタム検出は認証強化の代替ではないという点です。MFA、条件付きアクセス、パスワードレス、アプリケーションのモダン認証対応が本筋です。Purview は、そこに至るまでの間に「漏れているパスワードを見つける」「不用意な共有を抑止する」「監査証跡を残す」ための補完策として使うべきです。
Microsoft Entra ID の公式ドキュメントでも、パスキー、FIDO2 セキュリティキー、Windows Hello for Business、証明書ベース認証などのフィッシング耐性のある認証方法が推奨されています。つまり、Purview で平文パスワードを検出しながら、最終的にはパスワード依存を減らすロードマップを同時に進めるのが現実的な落としどころです。(Microsoft Learn)
なぜレガシーの password-only ワークフローが危険なのか
レガシーシステムのリスクは、「古いシステムだから危ない」という単純なものではありません。実務上の問題は、パスワードが人間の作業フローに入り込みやすいことです。
たとえば、次のような場面は多くの組織で起こり得ます。
| ワークフロー例 | 平文パスワードが残りやすい場所 | 主なリスク |
|---|---|---|
| 障害対応時に管理者パスワードを共有する | Teams チャット、メール、作業メモ | 一時共有のつもりが検索可能な履歴として残る |
| ベンダーに初期パスワードを渡す | メール添付、SharePoint、Excel | 委託先・外部共有経由で露出範囲が広がる |
| サービスアカウントの認証情報を台帳管理する | Excel、CSV、オンプレファイルサーバー | 複数人が同じ認証情報を使い、責任追跡が難しくなる |
| 古い業務アプリがMFAに対応していない | 手順書、運用ノート、ナレッジベース | 1つのパスワード漏えいが直接侵入につながる |
| 拠点や工場の端末で共通IDを使う | 紙の手順を電子化した文書、ローカル共有 | 退職者・異動者のアクセス制御が残りやすい |
セキュリティチームが見るべきなのは、「パスワードが強いか」だけではありません。むしろ、どこに保存され、誰が閲覧でき、漏れた場合に何へアクセスできるかが重要です。
Microsoft は、MFAをサポートしないレガシープロトコルのブロックを推奨しており、同社の分析では credential stuffing 攻撃の97%超、password spray 攻撃の99%超がレガシー認証プロトコルを使っていると説明しています。これは、古い認証方式が残る環境では、資格情報の露出が攻撃成功率を大きく押し上げることを示す重要な判断材料です。(Microsoft Learn)
Microsoft Purview でできることと限界
Microsoft Purview は、平文パスワードの露出対策において「発見」「分類」「制御」「監査」を担えます。Microsoft Purview の DLP は単純なテキストスキャンではなく、キーワード、正規表現、内部関数、近接する補助情報などを組み合わせてコンテンツを分析します。(Microsoft Learn)
ただし、Purview は万能ではありません。パスワードそのものを安全に管理する製品ではなく、レガシー認証をモダン認証に変える機能でもありません。役割を正しく分けることが、導入失敗を避ける第一歩です。
| 目的 | 使う機能 | 向いている場面 | 注意点 |
|---|---|---|---|
| 平文パスワードらしい文字列を検出する | カスタム Sensitive Information Type | 組織固有の表記、初期PW、運用メモ、台帳の検出 | 広すぎる正規表現は誤検知を増やす |
| 既知の資格情報パターンを広く検出する | 組み込みの credential scanning SIT / All credentials SIT | Azure、GitHub、Google、Slack など多様な資格情報の検出 | credential scanning SIT は高度な分類の有効化が必要な場合がある |
| メールやファイル共有を制御する | Microsoft Purview DLP | Exchange、SharePoint、OneDrive、Teams、デバイスなどの制御 | 最初からブロックすると業務影響が大きい |
| 端末上の持ち出しを監視・制御する | Endpoint DLP | USB、ローカルコピー、ブラウザー経由のアップロードなどの抑止 | 対象デバイスのオンボードとポリシー調整が必要 |
| オンプレのファイル共有を対象にする | DLP on-premises repositories / Information Protection scanner | SMB/NFS共有、SharePoint Server 上の手順書・台帳 | スキャナーはリアルタイム検出ではなく巡回型 |
| 検出したファイルを分類する | 感度ラベル、自動ラベル付け | 「認証情報を含むファイル」を高機密として扱う | ラベルだけでは資格情報の失効・変更はできない |
Microsoft Purview の組み込み SIT には「All credentials」や「General password」などがあり、資格情報検出の土台として使えます。一方で、組織独自の「初期PW」「仮パス」「保守ID」「ベンダー用」などの表記は、カスタム SIT で補う必要があります。(Microsoft Learn)
優先順位は「露出確率 × 悪用時の影響 × 対処しやすさ」で決める
Microsoft Purview / data protection for legacy systems の取り組みで失敗しやすいのは、すべてのレガシーシステムを同じ優先度で扱うことです。現実には、限られたセキュリティ人員で対応するため、リスクを分解して優先順位を決める必要があります。
おすすめは、次の3つで評価する方法です。
- 露出確率：メール、チャット、共有フォルダー、Excel台帳に残りやすいか
- 悪用時の影響：管理者権限、外部公開システム、本番データ、個人情報にアクセスできるか
- 対処しやすさ：パスワード変更、アカウント無効化、共有解除、DLP設定がすぐできるか
| 優先度 | 該当する状態 | 最初にやる対策 |
|---|---|---|
| P0 | 管理者・サービスアカウント・外部接続用の平文パスワードが、メールや共有フォルダーに存在する | ファイル削除や共有解除だけでなく、必ず資格情報をローテーションする。関連ログを確認し、同じ表記を検出するDLPルールを作る |
| P1 | 現役のレガシー業務でパスワード共有が常態化している | 業務オーナーを決め、カスタムSITとDLPをシミュレーションで展開する。並行して保管先をパスワード管理基盤やPAMへ移す |
| P2 | 古い手順書、Excel、CSVに過去の資格情報が残っている可能性がある | PurviewスキャナーやDLPで棚卸しし、使われていない認証情報を失効する。不要な文書は削除または保護する |
| P3 | 誤検知が多く、アラートが運用に乗らない | キーワード、近接距離、除外条件、信頼度を調整する。検出件数だけでなく真陽性率を見る |
特にP0で重要なのは、平文パスワードを見つけたら、ファイルを消すだけで終わらせないことです。すでに閲覧・転送・同期されている可能性があるため、資格情報のローテーション、関連アカウントのサインイン履歴確認、外部共有の確認までを1つの標準手順にしてください。
カスタム SIT を設計するときの実務ポイント
Microsoft の投稿では、パスワードらしい文字列を検出するために、主要素、補助要素、キーワード、近接条件を組み合わせる設計が紹介されています。たとえば、10〜20文字の非空白文字列を候補として検出し、大文字・小文字・数字・特殊文字などの複雑性を補助要素で確認し、さらに password、pwd、credential などのキーワードが近くにある場合に信頼度を高める構成です。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Purview の SIT は、主要素、補助要素、信頼度、近接条件でパターンを構成します。補助要素は、検出した文字列が本当に対象の機密情報である可能性を高める証拠として機能します。(Microsoft Learn)
実務では、次のように設計すると運用に乗りやすくなります。
| 設計項目 | 推奨する考え方 | 失敗しやすい例 |
|---|---|---|
| 主要素 | パスワード候補の長さや文字種を絞る | \S+ のように広すぎる条件で大量検出する |
| 補助要素 | 大文字、小文字、数字、特殊文字などを分けて確認する | 1本の巨大な正規表現に詰め込み、監査・修正が難しくなる |
| キーワード | password、pwd、credential、パスワード、初期PW、仮パスなど業務表記を入れる | 英語キーワードだけで日本語の運用文書を見逃す |
| 近接条件 | キーワードと候補文字列が同じ文脈にある範囲に絞る | 文書内のどこかにキーワードがあれば一致、という広すぎる条件にする |
| 除外条件 | dummy、sample、example、redacted、ハッシュ値、APIキーらしい文字列などを除外する | 誤検知を現場任せにして、アラート疲れを起こす |
| 信頼度 | ブロック用途は高信頼度、調査用途は中〜低信頼度から始める | 低信頼度の検出をいきなり全社ブロックに使う |
日本語環境では、キーワード設計が特に重要です。Microsoft のドキュメントでは、日本語などのダブルバイト文字を含むパターンを扱う場合、英数字と日本語が混在する表記ではスペースあり・なしの両方を考慮する例が示されています。たとえば「初期 password」と「初期password」のように、実際の文書で使われる表記揺れをテストデータに入れておくと見逃しを減らせます。(Microsoft Learn)
また、カスタム SIT で正規表現を作る際は、^ や $ のような位置アンカーを安易に使わないことも重要です。Microsoft は、カスタム SIT で位置アンカーを使うと、スキャン時に意図どおり動作する保証がないと注意しています。(Microsoft Learn)
検出ルールのたたき台
本番投入前の検証では、次のような構成をたたき台にできます。実際には、自社のパスワードポリシー、禁止文字、業務表記、対象ファイル形式に合わせて調整してください。
主要素:
- 空白を含まない10〜20文字程度の文字列
補助要素:
- 大文字を含む
- 小文字を含む
- 数字を含む
- 特殊文字を含む
キーワード例:
- password
- pwd
- passcode
- credential
- パスワード
- 初期PW
- 仮パス
- 保守ID
近接条件:
- まずは20〜50文字程度で検証
- 誤検知が多ければ短くする
- 見逃しが多ければ対象文書の実例を確認して調整ここで大切なのは、検出ルールを強くしすぎないことです。初期段階では「現場に迷惑をかけない検出」よりも、「どの業務で平文パスワードが発生しているかを把握する検出」を優先します。その後、真陽性が多いパターンだけをDLPのブロックや警告に昇格させると、業務影響を抑えられます。
導入は「検出 → 調査 → 制御 → 近代化」の順で進める
Microsoft Purview のDLPは、メール、ファイル、端末、オンプレミスリポジトリなど複数の場所に展開できます。しかし、最初から全社ブロックを行うと、運用チームや業務部門の反発を招きやすくなります。段階導入が現実的です。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 検出 | 組み込みの credential SIT とカスタムSITを作成し、限定範囲でテストする | 検出パターン、誤検知一覧、対象ワークロード |
| 調査 | 検出結果を業務オーナーと確認し、現役・廃止済み・不明に分類する | リスク台帳、資格情報オーナー、ローテーション対象 |
| 制御 | DLPをシミュレーションから開始し、外部共有、メール送信、端末持ち出しに警告やブロックを適用する | DLPポリシー、例外申請フロー、通知文面 |
| 対応 | 検出時の削除、共有解除、パスワード変更、ログ確認を標準化する | インシデント対応手順、SLA、証跡 |
| 近代化 | MFA、条件付きアクセス、パスワードレス、アプリ移行、PAMを進める | レガシー認証廃止計画、移行ロードマップ |
Microsoft Entra のMFA展開ガイドでは、条件付きアクセスによるMFA適用、パイロット展開、ユーザー登録計画、オンプレミスやレガシーアプリとの統合が重要な検討事項として示されています。オンプレミスのレガシーアプリでは、Microsoft Entra application proxy や NPS extension などを使う選択肢もあります。(Microsoft Learn)
つまり、Purview 側の検出は「レガシーを残すための言い訳」ではなく、レガシーを安全に減らすための可視化手段として位置づけるべきです。
オンプレミスやファイルサーバーも対象に含める
レガシーシステムのパスワードが残りやすい場所は、Microsoft 365 だけではありません。古い手順書、運用台帳、共有フォルダー、SharePoint Server のドキュメントライブラリなどに残っているケースもあります。
Microsoft Purview DLP の on-premises repositories location では、オンプレミスのファイル共有や SharePoint のドキュメントライブラリ・フォルダーに対して、DLPの保護アクションを適用できます。検出には組み込みまたはカスタムのSIT、感度ラベル、ファイルプロパティなどを利用できます。(Microsoft Learn)
一方で、Microsoft Purview Information Protection scanner は、指定したデータストアを巡回して検出・分類する仕組みであり、リアルタイムにすべてのファイル変更を検出するわけではありません。スキャン周期、対象リポジトリ、除外ファイル、IFilterで検査可能なファイル形式を考慮して設計する必要があります。(Microsoft Learn)
実務では、最初に次の場所を優先すると成果が出やすくなります。
- 情報システム部門や運用部門の共有フォルダー
- 障害対応手順書、復旧手順書、構築手順書
- ベンダー連携用のファイル置き場
- 古いExcel台帳やCSV
- 退職者・異動者が作成した運用メモ
- 工場、拠点、店舗、コールセンターの共通手順書
「クラウドだけ守っているが、オンプレ共有に古いパスワード台帳が残っている」という状態は、data protection for legacy systems の典型的な抜け穴です。
ロール別に見るべきポイント
このテーマは、セキュリティチームだけで完結しません。Security teams、compliance leads、platform architects が同じ検出結果を見ても、取るべき行動は異なります。
Security teams が見るべきこと
Security teams は、検出結果をインシデント候補として扱います。特に、管理者アカウント、サービスアカウント、VPN、RDP、データベース、クラウド管理ポータルに関係する資格情報は優先度を上げます。
見るべき指標は次の通りです。
- 真陽性の件数
- 資格情報ローテーションまでの時間
- 外部共有されていた検出ファイル数
- 同じ部署・同じシステムでの再発件数
- 検出からDLPポリシー改善までのリードタイム
Compliance leads が見るべきこと
Compliance leads は、検出そのものよりも、ルール、例外、証跡を重視します。平文パスワードが検出された場合に、誰が、いつ、どの判断で、どの対応をしたのかを説明できる状態にする必要があります。
特に重要なのは、例外運用です。「このレガシー業務だけは仕方ない」という例外は現実に発生します。しかし、例外には必ず期限、業務オーナー、代替統制、見直し日を設定してください。期限のない例外は、実質的に恒久的なリスク受容になります。
Platform architects が見るべきこと
Platform architects は、Purview の検出結果をアーキテクチャ改善の材料にします。何度も検出されるシステムは、単なる利用者教育の問題ではなく、設計上パスワード共有を要求している可能性があります。
たとえば、次のような改善を検討します。
- SAML、OpenID Connect、OAuth などのモダン認証への移行
- Microsoft Entra ID との統合
- 条件付きアクセスによるMFA適用
- RADIUS系アプリのNPS extension利用またはSAML移行
- サービスアカウントの棚卸しと権限最小化
- PAMやシークレット管理基盤への移行
- 共通IDの廃止と個人単位の追跡性確保
Microsoft は、特権ロールを持つ人間のIDには FIDO セキュリティキーや Windows Hello for Business などのパスワードレス認証情報を推奨しています。特権アカウントから優先的にパスワード依存を減らすのは、費用対効果の高い対策です。(Microsoft Learn)
DLPポリシーは最初からブロックしない
平文パスワードの検出は緊急性が高いテーマですが、DLPポリシーを最初から厳しくしすぎると失敗します。理由は簡単で、初期の検出ルールには必ず誤検知が含まれるからです。
推奨される展開順は次の通りです。
| 段階 | 設定方針 | 目的 |
|---|---|---|
| テスト | サンプルファイルと限定データでカスタムSITを検証する | ルールが意図通り動くか確認する |
| シミュレーション | 本番データに対して監視のみ行う | 誤検知、業務影響、検出傾向を把握する |
| 警告 | ユーザーにポリシーヒントや通知を表示する | 自己修正を促し、反発を減らす |
| 限定ブロック | 外部共有、外部送信、特定部署などに絞って制御する | 高リスク経路から止める |
| 全社展開 | 例外フローと対応SLAを整えたうえで拡大する | 継続運用に乗せる |
Microsoft のドキュメントでも、SITの精度を高めるには、補助要素、近接条件、信頼度、除外条件、テストを使って誤検知を減らすことが推奨されています。特に、近接条件を無制限にすると誤検知が増えやすいため、適切な範囲に絞る必要があります。(Microsoft Learn)
よくある失敗と回避策
Microsoft Purview を使った平文パスワード対策では、次の失敗がよく起こります。
| 失敗 | 何が問題か | 回避策 |
|---|---|---|
| 正規表現だけで検出しようとする | ランダム文字列、APIキー、ハッシュ、製品コードまで拾う | キーワード、近接条件、除外条件を組み合わせる |
| 検出したファイルを削除して終わる | すでに閲覧・転送・同期されている可能性がある | 必ず資格情報を変更し、関連ログを確認する |
| いきなり全社ブロックする | 業務停止や例外申請の急増を招く | シミュレーション、警告、限定ブロックの順で進める |
| 日本語キーワードを入れない | 「初期PW」「仮パス」「保守用」などを見逃す | 日本語・英語・略語・表記揺れを業務文書から抽出する |
| オンプレ共有を対象外にする | 古い手順書や台帳が残り続ける | Information Protection scanner や on-premises repositories を検討する |
| 例外に期限を付けない | レガシー業務が恒久化する | 例外には期限、オーナー、代替統制、見直し日を設定する |
| 誤検知率を測らない | アラート疲れで運用が形骸化する | 真陽性率、再発率、対応時間をKPIにする |
特に注意したいのは、Endpoint DLP とカスタムSITの関係です。Microsoft のドキュメントでは、Endpoint DLP がテナント内で利用可能なすべてのSIT、カスタムSITを含む、を基にファイルを分類するため、調整不足のSITが多くのファイルに一致すると分類トラフィックが増える可能性があると説明されています。カスタムSITは作ったら終わりではなく、使われていないものの削除や、広すぎるパターンの見直しが必要です。(Microsoft Learn)
30日・60日・90日で進める実行計画
最初の30日でやること
最初の30日は、全社制御よりも可視化を優先します。
- パスワード-only のレガシー業務を棚卸しする
- 組み込みの credential SIT を確認する
- 自社表記に合わせたカスタムSITを作る
- セキュリティ部門、情シス、運用部門の共有フォルダーから検証する
- P0相当の検出時に使うローテーション手順を作る
- DLPはシミュレーションまたは監査から開始する
この時点でのゴールは、「どこに平文パスワードがあるか」ではなく、どの業務が平文パスワードを生み出しているかを特定することです。
60日までにやること
60日目までに、検出結果を運用に接続します。
- 真陽性が多いルールを高信頼度パターンに調整する
- 外部共有や外部メール送信に警告を出す
- P0/P1の資格情報をローテーションする
- オンプレファイルサーバーやSharePoint Serverの対象化を検討する
- 例外申請フローを作る
- 再発が多い部署やシステムを特定する
ここでは、ユーザー教育だけに頼らないことが重要です。何度も同じ形式で検出される場合、その業務はパスワード共有を前提に設計されています。業務設計や認証方式を見直す必要があります。
90日までにやること
90日目までに、レガシー業務の縮小計画に接続します。
- 高リスクのレガシーシステムに移行期限を設定する
- 特権アカウントからパスワードレスやフィッシング耐性MFAを展開する
- サービスアカウントの権限を最小化する
- パスワード管理基盤やPAMへの移行を進める
- DLPポリシーを限定ブロックへ移行する
- 四半期ごとに検出ルールと例外を見直す
90日後に目指すべき状態は、「平文パスワードがゼロ」と言い切ることではありません。実務上は、ゼロを断言するのは難しい場合があります。目指すべきは、検出できる、対応できる、再発を減らせる、そしてレガシー依存を縮小できる状態です。
この記事の結論
Microsoft positions Purview custom detection as a way to cover legacy password-only workflows という更新は、Microsoft Purview のカスタム正規表現で平文パスワードを検出できる、という技術紹介にとどまりません。セキュリティチーム、コンプライアンス責任者、プラットフォームアーキテクトにとっては、レガシーシステムが残る現実を前提に、データ保護でリスクを下げるための実務的なヒントです。
ただし、Purview の検出は最終防衛線ではありません。平文パスワードを検出したら、削除、共有解除、資格情報ローテーション、ログ確認、DLP改善、認証方式の近代化までを一連のプロセスにしてください。
次に取るべき行動は明確です。まず、パスワード-only のレガシー業務を3つ選び、Microsoft Purview の組み込み credential SIT とカスタムSITで検出を始めます。その結果をもとに、P0/P1の資格情報をローテーションし、DLPをシミュレーションから展開し、最終的にはMFA・パスワードレス・モダン認証への移行計画に接続します。
コメント