Microsoft Purview / data protection for legacy systems を検討している組織にとって、2026年4月20日の Microsoft Security Community Blog 更新は見逃せません。結論から言うと、今回のポイントは「Purviewでレガシーシステムのパスワード運用を完全に解決する」ことではなく、パスワードのみで動く古い業務が残る間、平文パスワードの露出を検出・抑止・改善する運用をPurviewで作ることです。Microsoftは、MFAがあってもパスワード露出リスクは残り、特にレガシーシステム、サードパーティツール、サービスアカウントではパスワードのみのワークフローが残りやすいと説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
Product owners、IT decision-makers、technical strategists が読むべき論点は、単発の「正規表現でパスワードを検出する方法」ではありません。中期的には、Microsoft Purviewを「機密データの分類・DLP・自動ラベル付け・エンドポイント保護」をつなぐデータ保護基盤として使い、認証近代化が完了するまでのギャップを埋める方針が重要になります。
Microsoft Purview / data protection for legacy systems の最新動向をどう読むか
2026年4月20日の更新では、Microsoft PurviewのカスタムSensitive Information Type、いわゆるカスタムSITを使い、平文で保存・共有されたパスワードらしき文字列を検出する設計例が紹介されました。Microsoftの例では、主要素で10〜20文字の非空白文字列を拾い、補助要素で大文字・小文字・数字・記号などの複雑性を確認し、さらに password、pwd、credential などのキーワード近接条件で人間がパスワードとして扱っている文脈を判定します。(TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、カスタム検出が「パスワードそのものの有効性」を確認するわけではない点です。Purviewが見つけるのは、あくまでパスワードとして扱われている可能性が高い文字列です。だからこそ、検出後の運用として、当該コンテンツの削除・共有停止・資格情報のローテーション・該当システムの認証方式見直しまでをセットにする必要があります。
今回の更新は、次のように読むと実務に落とし込みやすくなります。
| 見方 | 表面的な理解 | 実務での読み方 |
|---|---|---|
| 機能面 | カスタム正規表現でパスワードを検出できる | 組織固有のパスワード規則や表記ゆれに合わせて検出ロジックを管理できる |
| セキュリティ面 | 平文パスワードを見つける | レガシーなpassword-only workflowsの残存リスクをDLP運用で可視化する |
| ロードマップ面 | Purviewの小さなTips | ID管理・DLP・エンドポイント・AI利用時のデータ保護を横断する方向性の一部 |
| 経営判断面 | 便利な検出ルール | 認証近代化までの暫定統制と、移行優先順位を決める材料 |
Microsoft PurviewのSITは、DLPポリシー、秘密度ラベル、自動ラベル付け、Insider Risk Management、Communication Complianceなど複数の機能で使われます。SITの構成要素は、主要素、補助要素、信頼度、近接条件で成り立つため、単なる文字列検索よりも「文脈」を加味した検出設計ができます。(Microsoft Learn)
なぜレガシーシステムのパスワード露出が今も問題になるのか
MFA、条件付きアクセス、SSO、PAMを導入していても、すべての業務システムが同じ水準で保護されているとは限りません。特に古い業務アプリ、ベンダーポータル、オンプレミスの管理画面、バッチ処理用のサービスアカウントでは、パスワードのみでの認証が残ることがあります。Microsoftの更新でも、メール、共同作業サイト上の文書、トラブルシューティング時のメモ、資格情報管理用のスプレッドシートなどにパスワードが現れる例が挙げられています。(TECHCOMMUNITY.MICROSOFT.COM)
この領域で失敗しやすいのは、「ID基盤を強化しているから大丈夫」と判断してしまうことです。実際には、ID基盤で守られていないレガシー領域ほど、パスワードがメールやExcelに退避されやすくなります。Product ownerの視点では、これは単なるセキュリティ問題ではなく、プロダクトや業務フローの設計負債です。
Purviewは何を補完し、何を補完しないのか
Microsoft Purviewは、レガシーシステムそのものを最新認証に置き換える製品ではありません。Purviewの役割は、機密情報がどこにあり、どのように共有され、どのタイミングで漏えいしそうかを見つけ、ポリシーで制御することです。DLPポリシーは、エンタープライズアプリ、デバイス、インラインWebトラフィックなどで機密データを識別・監視・保護するために使われます。(Microsoft Learn)
| 課題 | Purviewで対応しやすいこと | Purviewだけでは不足すること |
|---|---|---|
| メールにパスワードが書かれる | DLPで検出、警告、ブロック、監査 | そのパスワードが有効かどうかの検証 |
| SharePointやOneDriveに資格情報ファイルが置かれる | SIT、DLP、自動ラベル付け、監査で可視化 | 根本的な資格情報管理プロセスの再設計 |
| 端末からUSBや印刷で持ち出される | Endpoint DLPでコピー、印刷、ネットワーク共有などを制御 | 管理対象外端末や未オンボード端末の完全制御 |
| レガシーアプリがパスワード認証しか持たない | 露出したパスワードを検出して移行優先度を判断 | SSO、MFA、PAM、シークレット管理への移行 |
| 非Microsoft 365のデータ資産を分類したい | Data Mapで資産登録、スキャン、分類の検討 | 対応データソース、プレビュー機能、課金、カスタムSIT対応範囲の確認 |
Endpoint DLPは、オンボードされたWindows 10/11、macOSの直近主要バージョン、特定のWindows Server環境にDLPの監視・保護機能を拡張します。ユーザーが機密アイテムをコピー、印刷、USBへ移動、ネットワーク共有へコピーするような操作に対して、監査・警告・ブロックを設計できます。(Microsoft Learn)
中期ロードマップで見るべき3つの方向性
組織固有の検出ロジックが重要になる
Microsoftの組み込みSITは広範な保護の土台になりますが、レガシーシステムの資格情報は組織ごとの命名規則、パスワード規則、運用メモの書き方に強く依存します。そのため、カスタムSITを作り、パスワード長、複雑性、キーワード、近接条件を組み合わせる設計が現実的です。Microsoft Learnでも、事前定義済みSITが要件に合わない場合は、独自のカスタムSITを作成または既存SITをコピーして調整できると説明されています。(Microsoft Learn)
技術戦略としては、検出ルールを「一度作って終わり」にしないことが大切です。パスワード規則、社内用語、チケット管理ツールのテンプレート、運用担当者のメモ表現は変わります。カスタムSITは、ポリシー、例外、変更履歴、検出結果のレビュー手順まで含めて、管理対象のセキュリティ資産として扱うべきです。
Microsoft 365内の検出から、エンドポイントとネットワークへ広がる
今回のパスワード検出例は、メールや共同作業ワークロードでの露出に直結します。しかし、実際の漏えい経路はそれだけではありません。端末でコピーされる、ブラウザ経由で外部サービスへ貼り付けられる、AIサービスに送信される、といった経路もあります。Microsoft Purview Network Data Securityは、SASEや非Microsoftのセキュアブラウザ連携を通じてHTTP/HTTPSトラフィックを監視・分類し、既存のPurview分類器やDLPポリシーを使って保護を適用する方向に拡張されています。(Microsoft Learn)
この流れを見ると、Purviewのロードマップは「Microsoft 365の中だけを守る」から、「業務データが移動する場所に合わせて制御点を広げる」方向に進んでいると読めます。レガシーシステムのパスワード保護も、メール対策だけでなく、端末、ブラウザ、ネットワーク、AI利用まで含めたデータ流通設計として捉える必要があります。
休眠データとAI時代の露出リスクに備える
古いパスワードメモや資格情報一覧は、使われなくなったSharePointサイト、OneDrive、古いプロジェクトフォルダーに残りがちです。Microsoft Purviewのオンデマンド分類は、最新のSITや分類ポリシーを使って保存済みファイルをスキャンし、リアルタイム検出だけでは見逃しやすい休眠コンテンツを保護する手段として説明されています。Microsoftは、AIツールが未ラベル・未保護の情報を表面化させるリスクを減らす文脈でもこの機能を位置づけています。(Microsoft Learn)
AI活用を進める組織では、これは重要なポイントです。Copilotや社内AI検索の導入前に、過去の平文パスワード、認証情報メモ、旧システムの接続情報が検索対象に残っていないかを確認する必要があります。
カスタムSIT設計の実務ポイント
Microsoftの例では、検出ロジックを一つの巨大な正規表現に詰め込まず、主要素と補助要素に分けています。これは、可読性、保守性、監査性を高めるうえで重要です。(TECHCOMMUNITY.MICROSOFT.COM)
| 設計要素 | 例 | 実務での判断基準 |
|---|---|---|
| 主要素 | \S{10,20} のような長さ・非空白条件 | まず候補文字列を広く拾う。ただし広すぎると誤検出が増える |
| 複雑性の補助要素 | 大文字、小文字、数字、記号の有無 | 社内パスワードポリシーに合わせる。古いシステムでは記号制限がある場合も考慮する |
| キーワード補助要素 | password、pwd、credential など | 英語だけでなく、パスワード、PW、初期パス、認証情報 など社内表記を確認する |
| 近接条件 | キーワードと候補文字列を近くに限定 | 「ランダムな強い文字列」やAPIキー、ハッシュとの混同を減らす |
| 信頼度 | 高・中・低 | 最初は監査で検出傾向を見て、ブロック対象は高信頼度から始める |
Microsoft Learnでは、SITの信頼度が高いほど誤検出は少なくなる一方、見逃しが増える可能性があると説明されています。逆に低または中信頼度では検出範囲が広がるため、誤検出も増えやすくなります。(Microsoft Learn)
日本語環境では、キーワード設計にも注意が必要です。Microsoft Learnは、Sensitive Information Typesで日本語を含むダブルバイト文字セットのサポートに触れており、日本語と英数字が隣接する表現では、スペースあり・なしの両方を登録する例を示しています。たとえば社内で「パスワード ABC123!」と「パスワードABC123!」の両方が使われるなら、両方の表記を想定したテストが必要です。(Microsoft Learn)
推奨ロードマップ：90日で監査、半年で制御、1年で縮小
Microsoft 365 Roadmapの情報は予定であり、リリース日や内容は変更される可能性があります。そのため、製品ロードマップを読むときは、単一の機能リリース日よりも「どの方向に投資が進んでいるか」を見る方が現実的です。(Microsoft)
| 期間 | 実施内容 | 成果物 |
|---|---|---|
| 0〜30日 | レガシーシステム、サービスアカウント、共有パスワード運用を棚卸しする | 対象システム一覧、業務オーナー、認証方式、リスク優先度 |
| 30〜90日 | カスタムSITを作成し、DLPを監査モードで試す | 検出ルール、テストデータ、誤検出リスト、改善版SIT |
| 3〜6カ月 | Exchange、SharePoint、OneDrive、Teams、Endpoint DLPへ段階展開する | 警告・ブロック方針、例外申請、インシデント対応手順 |
| 6〜12カ月 | 検出結果をもとにpassword-only workflowsを削減する | SSO/MFA/PAM移行計画、資格情報ローテーション基準、廃止候補一覧 |
最初から全社ブロックを行うと、業務停止や大量の誤検出で失敗しやすくなります。まずは監査モードで「どの部署が、どの場所に、どの形式で資格情報を置いているか」を可視化し、影響の大きい業務から段階的に制御を強めるのが現実的です。
実装手順：Purviewで平文パスワード露出を管理する流れ
対象ワークフローを決める
最初に、すべてのパスワードを対象にするのではなく、リスクの高い業務を1つ選びます。たとえば、旧販売管理システムの共有アカウント、ベンダー管理ポータル、オンプレミス運用アカウント、緊急保守用アカウントなどです。
この段階では、次の情報を整理します。
| 確認項目 | 具体例 |
|---|---|
| 認証方式 | パスワードのみ、MFA不可、IP制限あり、共有アカウント |
| 情報の置き場所 | メール、Teams、SharePoint、OneDrive、Excel、チケット、ローカル端末 |
| 業務オーナー | プロダクト責任者、運用チーム、ベンダー管理者 |
| 代替策 | SSO対応予定、PAM導入予定、シークレット管理ツール移行予定 |
| 緊急度 | 外部接続あり、管理者権限あり、顧客データへアクセス可能 |
カスタムSITを作成する
Microsoft Purviewポータルでは、Information Protection > Classifiers > Sensitive info types からカスタムSITを作成できます。複数パターン、信頼度、正規表現、キーワード、キーワード辞書を組み合わせて定義できます。(Microsoft Learn)
実務では、最初から完璧な正規表現を目指すより、次の順番で作る方が安定します。
- 候補文字列を拾う主要素を作る
- パスワードポリシーに近い複雑性条件を補助要素にする
password、pwd、credential、パスワード、PWなどの文脈キーワードを追加する- 近接条件を設定し、同じ文や同じセル周辺に限定する
- テストファイルで一致・不一致を確認する
- 誤検出例をもとに除外条件やキーワードを調整する
Microsoft Learnは、カスタムSITでは近接条件、信頼度、除外条件を調整し、テスト機能やContent Explorerで検出結果を確認することを推奨しています。また、新しいカスタムSITで近接条件を無制限にすると誤検出が増えやすいため、近接制限を設定することが重要です。(Microsoft Learn)
DLPポリシーに組み込む
カスタムSITを作ったら、すぐにブロックするのではなく、まずDLPポリシーで監査またはユーザー通知から始めます。Microsoftの更新でも、カスタムSITはDLP、Endpoint DLP、自動ラベル付け、メールやコラボレーションワークロード保護で利用できると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
推奨される段階展開は次の通りです。
| フェーズ | ポリシー動作 | 目的 |
|---|---|---|
| 監査 | 管理者が検出状況を見る | 実態把握、誤検出確認 |
| 通知 | ユーザーにポリシーヒントを出す | 行動改善、教育 |
| 警告付き許可 | 理由を入力すれば続行可能 | 業務影響を抑えつつ抑止 |
| ブロック | 高リスク操作を停止 | 外部共有、USB持ち出し、AI送信などを制御 |
この順序にすることで、業務部門との摩擦を減らしながら、検出品質と運用ルールを育てられます。
失敗しやすいポイントと対策
正規表現を広くしすぎる
10文字以上で記号を含む文字列 のような条件だけでは、APIキー、ハッシュ、ランダムなID、テストデータまで拾う可能性があります。Microsoftの例がキーワード近接を使っているのは、こうした誤検出を減らすためです。(TECHCOMMUNITY.MICROSOFT.COM)
対策としては、候補文字列だけで判定せず、password、credential、初期パスワード、ログイン情報 などの近接キーワードを組み合わせます。さらに、社内で頻出する無害な形式があれば除外条件を検討します。
検出結果を資格情報ローテーションにつなげない
DLPで検出しても、該当パスワードを変えなければリスクは残ります。検出後は、少なくとも次の対応を標準手順にします。
| 検出後の対応 | 内容 |
|---|---|
| コンテンツ確認 | 誤検出か、実際の資格情報かを確認する |
| 共有範囲確認 | 外部共有、ゲストアクセス、広範な社内共有の有無を見る |
| 資格情報変更 | 対象システムのパスワードをローテーションする |
| 保存場所の是正 | 文書、メール、スプレッドシートから削除する |
| 再発防止 | シークレット管理、PAM、SSO移行、手順書修正を行う |
「検出して終わり」ではなく、「検出をきっかけにレガシー運用を減らす」ことが、data protection for legacy systems の本質です。
非Microsoft 365データにも同じことができると考える
Microsoft Purview Data Mapでは、データ資産の登録、スキャン、分類、ラベル適用を扱えますが、機能の対応範囲には注意が必要です。Data Mapでのラベル付けはプレビューであり、非Microsoft 365ワークロード向けの自動ラベル付けでは、記事執筆時点のMicrosoft Learn上でカスタムSIT、資格情報、Exact Data Match、trainable classifiersなどがサポートされないと説明されています。(Microsoft Learn)
つまり、Microsoft 365内で使えるカスタムSITの設計を、そのまま非Microsoft 365データ資産の自動ラベル付けに適用できるとは限りません。グローバル組織でAzure、オンプレミス、SaaS、外部ストレージを横断する場合は、対象データソース、ライセンス、プレビュー状態、課金モデルを個別に確認する必要があります。
カスタムSITを作りすぎる
カスタムSITは便利ですが、乱立すると管理不能になります。Microsoft Learnでも、Endpoint DLPはテナント内のカスタムSITを含むSITで分類するため、十分に調整されていないSITが多くのファイルに一致すると過剰な分類トラフィックを生む可能性があり、未使用SITの削除や再設計が推奨されています。(Microsoft Learn)
カスタムSITは、作成前に目的、オーナー、利用ポリシー、レビュー頻度、廃止条件を決めておきます。特に平文パスワード検出のSITは、セキュリティ部門だけでなく、ID管理、インフラ、業務システムオーナーと共同で管理するのが望ましいです。
役割別に見る次のアクション
| 役割 | 見るべきポイント | 次に取るべき行動 |
|---|---|---|
| Product owners | password-only workflowsがどの機能・顧客・運用に残っているか | 認証近代化のバックログを作り、移行できない期間の暫定統制を定義する |
| IT decision-makers | Purview、DLP、Endpoint DLP、ライセンス、課金、運用体制 | 監査モードのパイロットを承認し、例外申請とインシデント対応の責任分界を決める |
| Technical strategists | カスタムSIT、DLP、ラベル、エンドポイント、ネットワーク、AI利用の接続 | 検出ルールを標準化し、SIEM、チケット、資格情報ローテーション手順と連携する |
| Security operations | 検出後の調査、誤検出、ユーザー教育 | 検出イベントをトリアージし、再発パターンをポリシー改善へ戻す |
運用KPIは「検出数」だけで見ない
平文パスワード検出を導入すると、最初は検出件数が増えることがあります。これは必ずしも悪いことではありません。可視化されていなかったリスクが見え始めた状態だからです。ただし、KPIを検出数だけにすると、現場は「見つけない設定」に寄せたくなります。
見るべき指標は次のように分けます。
| KPI | 意味 | 改善の方向 |
|---|---|---|
| 真陽性率 | 実際の資格情報だった割合 | キーワード、近接条件、除外条件を調整する |
| 誤検出率 | 無害な文字列だった割合 | 正規表現を絞る、文脈条件を追加する |
| ローテーション完了時間 | 検出からパスワード変更までの時間 | チケット化、担当者明確化、自動通知を整備する |
| 再発率 | 同じ部署・同じシステムで繰り返す割合 | 業務手順、教育、認証方式を見直す |
| password-only workflows削減数 | レガシー認証が減った数 | SSO、MFA、PAM、シークレット管理へ移行する |
今後の運用方針：Purviewは移行までの保険ではなく、継続的なデータ保護基盤にする
今回のMicrosoft Purview更新は、レガシーシステムのパスワード運用に対する「現実的な折衷案」として有用です。ただし、Purviewで検出できるからといって、平文パスワード共有を許容してよいわけではありません。正しい方針は、短期ではPurviewで露出を見つけて止め、中期ではDLPとEndpoint DLPで行動を制御し、長期ではpassword-only workflowsそのものを減らすことです。
まず着手すべきことは、全社展開ではなく、1つの高リスクなレガシー業務を選び、カスタムSITを監査モードで試すことです。検出結果を見て、誤検出を減らし、実際に見つかった資格情報をローテーションし、同じ業務のSSO化・PAM化・シークレット管理への移行をロードマップに入れます。
Microsoft Purview / data protection for legacy systems の成否は、ツール導入だけでは決まりません。検出ルール、DLPポリシー、資格情報管理、業務オーナーの責任、移行計画を一体化できるかで決まります。今回の更新は、その一体化を始めるための実装例として読むのが最も実用的です。
コメント