Microsoft Purview / data protection for legacy systems の今回のポイントは、レガシーシステムに残りがちな「パスワードだけで動く業務」を、平文パスワード検出・DLP・ラベル付けのワークフローに組み込めることです。
2026年4月20日に Microsoft は、Microsoft Purview のカスタム正規表現を使い、メール、ドキュメント、トラブルシューティングメモ、スプレッドシートなどに書かれた平文パスワードを検出する方法を紹介しました。特に注目すべきなのは、MFA や SSO に移行しきれていないレガシーシステム、サードパーティツール、サービスアカウントのような「パスワードのみ」の業務フローを、Purview のカスタム検出でカバーするという実務的な位置づけです。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、単なる機能紹介ではなく、Power users、管理者、ソリューションオーナーが実際にどの業務フローを変えるべきかを、具体的な利用シナリオ中心に解説します。
Microsoft Purview / data protection for legacy systems の最新動向
Microsoft の発表で示された考え方は、シンプルです。
レガシーシステムでは、次のような運用が今でも残りがちです。
- 障害対応のために一時パスワードをメールで共有する
- ベンダー連携用の認証情報を Excel に残す
- サービスアカウントのパスワードを SharePoint の手順書に書く
- チャットで「pwd」「password」と一緒に認証情報を送る
- 移行プロジェクト中に旧システムのログイン情報をメモ化する
これらは、現場では「早く作業を進めるための一時対応」として発生します。しかし、平文パスワードが Microsoft 365 上のコンテンツや端末上のファイルに残ると、後から誰が見たのか、どこへ共有されたのか、いつ削除されたのかを追いにくくなります。
Microsoft Purview では、Sensitive Information Types、つまり機密情報の種類を使って、組織固有のパターンを検出できます。今回の Microsoft の例では、組織のパスワードルールに合わせたカスタム regex、複雑性条件、password や pwd などのキーワード近接条件を組み合わせ、単なる強い文字列ではなく「人がパスワードとして共有している可能性が高い文字列」を検出する設計が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
重要なのは、これは「パスワード管理ツールの代替」ではないことです。役割は、レガシーなパスワード運用が残っている期間に、危険な共有・保存・持ち出しを見つけ、止め、改善につなげることです。
現場のワークフローは「注意喚起」から「検出される前提」に変わる
これまでのレガシーシステム対策は、管理者が「パスワードをメールに書かないでください」と周知し、違反が起きたら後から注意する形になりがちでした。
Microsoft Purview / data protection for legacy systems の rollout では、この流れが変わります。現場の作業を止めることが目的ではなく、危険な操作が起きた瞬間に検知し、ユーザーに代替手段を示し、管理者が再発防止まで追える形にすることがポイントです。
| 業務場面 | 従来の流れ | Purview 導入後の流れ |
|---|---|---|
| 障害対応 | 一時パスワードをメールや Teams で共有 | DLP が検出し、警告・ブロック・例外申請へ誘導 |
| 手順書作成 | SharePoint の運用手順書に認証情報が残る | カスタム SIT で検出し、機密ラベルや共有制限を適用 |
| ベンダー連携 | 認証情報を Excel にまとめて引き継ぐ | 外部共有前に検出し、パスワード保管庫や一時リンクへ切り替え |
| 端末作業 | ローカルメモやログにパスワードが残る | Endpoint DLP で機密ファイルの操作を監視・制御 |
| 管理者対応 | 通報や監査で後から気づく | DLP アラートを起点に、サービスオーナーへ修正依頼 |
Purview DLP は、キーワード、正規表現、内部検証、近接する補助情報などを使ったコンテンツ分析により、機密情報の検出と保護を行います。対象は Exchange、SharePoint、OneDrive、Teams、Office アプリ、Windows / macOS 端末、オンプレミスファイル共有など、複数の業務チャネルに広がります。(Microsoft Learn)
シナリオ: ヘルプデスクが一時パスワードをメールで送ってしまう
最も分かりやすいシナリオは、ヘルプデスクです。
たとえば、旧システムの管理画面に MFA がなく、利用者の初期パスワードを担当者が発行しているとします。忙しい時間帯には、次のようなメールが発生しがちです。
旧勤怠システムの初期 password は P@ssw0rdExample! です。
ログイン後に変更してください。このような運用では、送信者も受信者も「一時的だから問題ない」と考えます。しかし、メールは転送され、検索され、アーカイブされます。退職者のメールボックスや共有メールボックスに残る可能性もあります。
Microsoft Purview でカスタム SIT を作成し、DLP ポリシーに組み込むと、次のような流れに変えられます。
| ステップ | 現場で起きること | 管理側の狙い |
|---|---|---|
| 検出 | password、pwd、credential などの近くに強い文字列があるメールを検出 | 誤検知を抑えつつ、実際のパスワード共有を拾う |
| 通知 | 送信者に「平文パスワードを送信しないでください」と表示 | ユーザー教育を作業中に行う |
| 代替手段 | パスワード保管庫、期限付きリンク、初回変更フローへ誘導 | 単なる禁止ではなく業務を継続させる |
| アラート | 繰り返し発生する部署・システムを管理者が確認 | レガシー運用の改善対象を特定する |
| 是正 | パスワードをローテーションし、手順書を修正 | 漏えい後の被害を小さくする |
最初からブロックだけを有効にすると、現場は別の抜け道を探します。導入初期は「監査のみ」または「警告＋上書き理由の記録」から始め、誤検知と業務影響を確認してからブロックへ進めるのが現実的です。
シナリオ: SharePoint や OneDrive に残る「認証情報一覧」を減らす
レガシーシステムの移行プロジェクトでは、棚卸し用の Excel が作られます。
そこに次のような列が含まれている場合があります。
| システム名 | URL | 管理者ID | パスワード | 備考 |
|---|---|---|---|---|
| 旧販売管理 | example | admin01 | 伏せ字なしの文字列 | ベンダー確認用 |
| 旧勤怠 | example | svc_batch | 伏せ字なしの文字列 | 夜間処理 |
このファイルが SharePoint や OneDrive に置かれ、外部共有や広範囲の社内共有が許可されていると、移行作業の便利さがそのままリスクになります。
Purview を使うと、次のような運用に変えられます。
- 認証情報らしい文字列を含むファイルを検出する
- 自動または推奨の秘密度ラベルを適用する
- 外部共有や匿名リンク共有を制限する
- DLP アラートでシステムオーナーに確認を促す
- 認証情報をパスワード保管庫へ移し、ファイルには参照先だけを残す
Microsoft Purview の自動ラベル付けでは、条件に一致するファイルやメールに秘密度ラベルを自動適用または推奨できます。ユーザーが分類判断をすべて覚える必要を減らせる点が、移行プロジェクトや部門管理ファイルでは特に有効です。(Microsoft Learn)
ただし、既存の SharePoint / OneDrive コンテンツは、検索クロールや再クロールのタイミングに影響されます。カスタム SIT を作成した直後に、過去の全ファイルが即座に再評価されると考えないほうが安全です。Microsoft Learn でも、既存コンテンツで新しいカスタム SIT を識別するには再クロールが必要になることがあると説明されています。(Microsoft Learn)
シナリオ: トラブルシューティングメモやログの持ち出しを抑止する
管理者やサポート担当者は、障害対応中に一時メモを作ります。
たとえば、次のような内容です。
検証用アカウント: test-admin
pwd: ExampleOnly@123
旧DB接続確認済みこのメモがローカル PC に保存され、USB メモリ、個人クラウド、外部チャット、メール添付などで移動すると、社内の監査ログだけでは追跡が難しくなります。
Endpoint DLP を使うと、機密と判断されたファイルに対するユーザー操作を監視し、ポリシーに応じた保護アクションを適用できます。Microsoft Learn では、Endpoint DLP が Windows 10/11、macOS の直近メジャーバージョン、特定の Windows Server に DLP の監視・保護機能を拡張すると説明されています。(Microsoft Learn)
このシナリオでは、最初から全端末・全ユーザーへ強い制限をかけるのではなく、次のように段階化すると失敗しにくくなります。
| フェーズ | 対象 | 設定の考え方 |
|---|---|---|
| 観測 | 情シス、ヘルプデスク、移行チーム | 検出件数、ファイル種別、発生業務を確認 |
| 警告 | 高リスク部署 | ユーザー通知で代替手段を案内 |
| 制御 | 外部共有や持ち出しが多い操作 | ブロック、上書き理由、管理者承認を検討 |
| 定着 | 全社または標準端末 | 例外を最小化し、標準運用に組み込む |
ここで大切なのは、DLP を「犯人探し」に使わないことです。目的は、現場が平文パスワードを残さなくても作業できるワークフローへ変えることです。
シナリオ: ベンダーや海外拠点とのパスワード共有を置き換える
グローバル企業では、海外拠点や外部ベンダーが旧システムを保守していることがあります。
この場合、パスワード共有の言い回しは日本語だけではありません。
passwordpwdpasscodecredentialinitial passwordtemporary passwordパスワード初期PW仮パス認証情報
Microsoft の例では、password や pwd などのキーワードを大文字小文字を区別せずに扱い、パスワード候補との近接条件で検出精度を高める考え方が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
日本語圏や多言語環境で rollout する場合は、英語キーワードだけで設計しないことが重要です。特に日本語では、「仮パス」「初期PW」「管理者パス」「認証情報」など、現場固有の略語が使われます。
また、Microsoft Purview は日本語・中国語・韓国語などの 2 バイト文字言語を使うカスタム SIT 作成をサポートしていますが、言語処理では単語間の扱いや特殊文字の除去が行われます。日本語キーワードを使う場合は、実際のメール、手順書、Excel、Teams メッセージに近いサンプルで必ずテストするべきです。(Microsoft Learn)
カスタム検出ロジックは「強い文字列」ではなく「パスワード共有の文脈」を見る
平文パスワード検出で失敗しやすいのは、正規表現だけで「複雑な文字列」を拾おうとする設計です。
たとえば、英数字と記号を含む 10 文字以上の文字列をすべて検出すると、次のようなものも大量に引っかかります。
- API キー
- ハッシュ値
- ランダムなファイル名
- 生成されたトークン
- 製品シリアル
- テストデータ
- ログ内の識別子
Microsoft の例では、検出ロジックを複数の要素に分けています。一次要素で候補文字列を見つけ、補助要素で複雑性を確認し、さらにキーワード近接で「これはパスワードとして書かれている」という人間の文脈を確認する設計です。(TECHCOMMUNITY.MICROSOFT.COM)
| 要素 | 役割 | 例 |
|---|---|---|
| 一次要素 | パスワード候補の長さや非空白文字を検出 | \S{10,20} |
| 補助要素 | 大文字、小文字、数字、記号などの複雑性を確認 | [A-Z]、[a-z]、[0-9] など |
| キーワード | 人がパスワードとして書いた文脈を確認 | password、pwd、credential など |
| 近接条件 | 候補文字列とキーワードが同じ文脈にあるか確認 | 例: 30文字以内 |
この考え方をそのまま現場に適用する場合は、自社のパスワードポリシーと実際の文書文化に合わせます。
たとえば、パスワード長が 14 文字以上の組織なら、10〜20 文字の例をそのまま使わず、社内ルールに合わせて調整します。日本語の手順書が多い組織なら、password だけでなく パスワード、初期パスワード、仮パス などを含めます。
一方で、キーワードを広げすぎると誤検知が増えます。key や token のような語は、API キーや設定値でも頻出します。最初は高信頼のキーワードから始め、検出結果を見ながら増やすのが安全です。
rollout の実務手順
Microsoft Purview / data protection for legacy systems の rollout は、機能を有効化するだけでは成功しません。業務フロー、例外処理、代替手段を同時に決める必要があります。
| 手順 | やること | 成果物 |
|---|---|---|
| 対象業務を洗い出す | レガシー認証が残るシステム、部署、共有経路を確認 | 対象システム一覧、関係者一覧 |
| 検出パターンを設計する | パスワード長、複雑性、キーワード、言語を決める | カスタム SIT 設計書 |
| サンプルでテストする | 一致すべき例、一致すべきでない例を用意 | テスト結果、誤検知メモ |
| 監査モードで開始する | まずは通知やブロックを弱め、発生状況を見る | 検出件数、発生部署、発生チャネル |
| 代替手段を案内する | パスワード保管庫、期限付きリンク、SSO 化の手順を提示 | ユーザー通知文、運用手順 |
| 制御を強める | 高リスク操作を警告、ブロック、例外申請へ移行 | DLP ポリシー、例外ルール |
| 改善サイクルを回す | 誤検知、見逃し、業務影響を定期レビュー | 月次レポート、改善 backlog |
カスタム SIT の作成では、Microsoft Purview ポータルの Information Protection > Classifiers > Sensitive info types から作成し、一次要素、補助要素、近接条件、信頼度などを設定します。Microsoft Learn では、一次要素として regex、キーワードリスト、キーワード辞書、事前構成された関数を使えると説明されています。(Microsoft Learn)
注意点として、カスタム SIT の regex では ^ や $ のような位置アンカーを使うと、想定どおりに動かない可能性があります。コンテンツ全体がどのようにスキャンされるかを前提に、単純なテキストエディタ上の正規表現テストだけで判断しないことが重要です。(Microsoft Learn)
Power users、admins、solution owners の役割分担
この rollout は、セキュリティ管理者だけでは進みません。現場を知る Power users と、システム責任を持つ solution owners が関与して初めて、実用的なポリシーになります。
| 役割 | 主な責任 | 具体的な行動 |
|---|---|---|
| Power users | 実際の業務フローを説明する | どこでパスワード共有が起きるか、どの言い回しが使われるかを共有 |
| Microsoft 365 admins | Purview の設定と監視を行う | カスタム SIT、DLP、Endpoint DLP、ラベル設定を構成 |
| Security admins | インシデント対応を設計する | アラートの優先度、調査手順、ローテーション基準を決める |
| Solution owners | レガシー運用の代替策を用意する | SSO 化、MFA 化、パスワード保管庫、サービスアカウント整理を進める |
| Helpdesk / Support | ユーザーへの案内を担う | DLP 通知時の問い合わせ対応、正しい手順の案内 |
特に重要なのは solution owners です。Purview が平文パスワードを検出しても、代替手段がなければ現場は困ります。パスワード共有を禁止する前に、次のどれを使うのかを決めておく必要があります。
- パスワード保管庫
- 一時アクセスリンク
- 初回ログイン時の強制変更
- SSO / MFA への移行計画
- サービスアカウントの棚卸し
- ベンダー用アカウントの期限管理
- break-glass アカウントの保管・承認フロー
Purview は「検出と抑止」の仕組みです。レガシー認証そのものを安全な認証方式へ置き換える責任は、システムオーナー側に残ります。
DLP ポリシー設計で決めるべき判断基準
DLP ポリシーは、強くすれば安全になるとは限りません。業務影響と検出精度のバランスを取る必要があります。
まずは「どこで検出するか」を絞る
対象を広げすぎると、誤検知の調査だけで運用が破綻します。
初期 rollout では、次のような高リスク領域から始めると効果が見えやすくなります。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | ヘルプデスク、情シス、運用保守チーム | 認証情報を扱う頻度が高い |
| 高 | レガシー移行プロジェクトの SharePoint サイト | 一時的な棚卸し資料にパスワードが残りやすい |
| 中 | ベンダー連携用メールボックス | 外部共有リスクがある |
| 中 | 開発・検証環境 | テスト用認証情報が文書化されやすい |
| 低 | 全社一般ユーザー | 初期段階ではノイズが多くなりやすい |
Microsoft Purview の DLP では、場所によって SIT、秘密度ラベル、保持ラベルなどの使い方が異なります。また、複数の場所を 1 つのポリシーで組み合わせると、サポートされない条件が優先される場合があります。ポリシーを大きく作りすぎず、場所ごとに分けて設計するほうが管理しやすくなります。(Microsoft Learn)
誤検知を減らすには「近接条件」と「除外条件」を使う
平文パスワード検出では、強い文字列だけを見るとノイズが増えます。
実務では、次の条件を組み合わせます。
- パスワード長
- 大文字、小文字、数字、記号の有無
password、pwd、パスワードなどの近接キーワードAPI_KEY、hash、tokenなどを除外または別分類する条件- ファイル種別や場所
- 検出件数
- 送信先が社外か社内か
- ユーザーが例外理由を入力したか
Microsoft Learn でも、カスタム SIT の精度を高めるには、補助要素、近接条件、信頼度、除外条件を使って false positives を減らす考え方が示されています。(Microsoft Learn)
ブロック条件は「業務停止リスク」で分ける
すべての検出を即ブロックすると、障害対応や緊急復旧が止まる可能性があります。
おすすめは、次のように段階を分けることです。
| 条件 | 推奨アクション |
|---|---|
| 社内メールで 1 件検出 | 警告、送信者教育、必要に応じて上書き理由 |
| 社外メールで 1 件検出 | 警告＋上書き理由、またはブロック |
| 複数件のパスワードらしき文字列 | ブロック、アラート |
| SharePoint で外部共有中のファイルに検出 | 共有制限、所有者通知 |
| 同一ユーザーが短期間に繰り返す | 管理者レビュー、追加教育 |
| サービスアカウントらしき情報 | 即時ローテーション検討 |
DLP の目的は、ユーザーを罰することではありません。危険な共有を止め、代替手段に誘導し、レガシー運用を減らすことです。
失敗しやすいポイント
正規表現を広くしすぎる
英数字記号を含む10文字以上 のような条件だけでは、API キー、ハッシュ、トークン、ランダム ID まで拾います。
対策は、キーワード近接と除外条件を入れることです。Microsoft の例のように、一次要素と補助要素を分け、さらに人間の文脈を表すキーワードを使うと、監査しやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
英語キーワードだけで運用する
グローバル企業でも、日本語の手順書やチャットでは「仮パス」「初期PW」「認証情報」のような語が使われます。
英語だけで設計すると、日本語圏の現場で見逃しが増えます。逆に日本語だけで設計すると、海外拠点やベンダーとのやり取りを見逃します。多言語キーワードは、部署・地域・システムごとに確認する必要があります。
ブロックだけ先に入れる
代替手段がない状態でブロックすると、現場は個人チャット、外部メモ、スクリーンショットなど、より追跡しにくい方法へ移ります。
先に用意すべきものは、ポリシーではなく業務手順です。
- どこに認証情報を保管するか
- 誰がアクセス権を承認するか
- 一時パスワードはどう発行するか
- 共有後にいつローテーションするか
- 緊急時の例外は誰が承認するか
検出したパスワードをそのまま調査メモに貼る
DLP アラート対応で、検出された文字列をチケットやチャットにコピーすると、二次漏えいになります。
対応チケットには、原則として次のように記録します。
SharePoint 上の移行資料に平文認証情報の可能性あり。
対象ファイル: 旧勤怠移行メモ.xlsx
対応: 所有者へ確認依頼、外部共有停止、該当アカウントのローテーション依頼実際のパスワード文字列は、必要最小限の権限を持つ担当者だけが確認し、確認後はローテーションを前提に扱います。
検出を「移行完了」と誤解する
Purview で平文パスワードを検出できても、レガシーシステムが安全になったわけではありません。
本来のゴールは、次の順番です。
- 平文パスワードの共有・保存を見つける
- 危険な共有を止める
- パスワードをローテーションする
- 保管・共有フローを正式化する
- レガシー認証を SSO / MFA / モダン認証へ移行する
Purview は、このうち 1〜3 を現実的に進めるための強力な仕組みです。しかし、5 を不要にするものではありません。
まず取り組むべき最小構成
全社 rollout の前に、次の小さな構成から始めると効果を確認しやすくなります。
| 項目 | 推奨する初期設定 |
|---|---|
| 対象部署 | ヘルプデスク、情シス、レガシー移行チーム |
| 対象チャネル | Exchange、SharePoint、OneDrive、Teams のうち高リスクなもの |
| 検出条件 | パスワード候補文字列＋複雑性＋キーワード近接 |
| キーワード | password、pwd、credential、パスワード、仮パス、初期PW |
| アクション | 監査、ユーザー通知、管理者アラート |
| 例外 | 緊急対応のみ、理由入力必須 |
| レポート | 件数、発生場所、真陽性率、再発部署、是正完了率 |
この最小構成で 2〜4 週間ほど実データを確認すると、次の判断がしやすくなります。
- 誤検知が多いキーワードはどれか
- 本当に危険な共有はどの部署で起きているか
- ブロックしても業務に支障が少ない操作はどれか
- 代替手段が不足しているシステムはどれか
- レガシー認証の廃止優先度を上げるべきシステムはどれか
Microsoft Purview をレガシー運用改善の入口にする
Microsoft Purview / data protection for legacy systems の rollout で最も価値があるのは、平文パスワードを「たまたま見つける」状態から、「業務フロー上で継続的に検出し、改善につなげる」状態へ変えられることです。
今回の Microsoft の更新は、レガシーシステムやパスワードのみのワークフローがまだ残る組織にとって、実務的なヒントになります。カスタム regex、補助要素、キーワード近接を組み合わせれば、単なる強い文字列ではなく、実際のパスワード共有に近い文脈を検出できます。(TECHCOMMUNITY.MICROSOFT.COM)
次に取るべき行動は、全社展開ではありません。まず、平文パスワード共有が起きやすい 1 つの業務を選び、検出のみで開始します。検出結果を見ながら、キーワード、近接条件、通知文、例外フローを調整します。
そのうえで、パスワード保管庫、SSO / MFA 化、サービスアカウント整理とつなげていくことが、レガシーシステムを抱える組織にとって現実的なデータ保護の進め方です。
コメント