Microsoft Purviewは、MFAやパスワードレス認証へ移行しきれていない企業にとって、レガシーシステムのパスワードリスクを可視化・抑止する“橋渡しの統制”になりつつあります。ポイントは、認証そのものをPurviewで置き換えるのではなく、メール、SharePoint、OneDrive、Teams、端末、共同作業ファイルなどに残る平文パスワードの露出を検出し、DLPや秘密度ラベル、運用フローにつなげることです。
2026年4月20日にMicrosoft Security Community Blogで公開された更新では、Microsoft Purviewのカスタム正規表現を使い、パスワードらしい文字列だけでなく「password」「pwd」「credential」などの文脈キーワードとの近接条件を組み合わせて、平文パスワード露出を検出する考え方が示されました。これは、ハイブリッド環境、サードパーティ製品、サービスアカウント、古い業務アプリがまだ残る企業にとって、すぐに実装を検討できる実務的なアプローチです。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Purviewがレガシー環境の“橋渡し統制”になる理由
多くの企業では、Microsoft Entra ID、MFA、条件付きアクセス、パスワードレス認証の導入が進んでいます。しかし現実には、すべての認証フローを短期間でモダン化できるわけではありません。
特に次のような領域では、今もパスワード依存が残りやすいです。
- 古い業務アプリケーション
- サードパーティ製SaaSや業務ツール
- バッチ処理用のサービスアカウント
- 監視、連携、ETL、RPAなどの自動化アカウント
- 緊急用アカウントや一時的な共有アカウント
- 現場部門が独自に管理しているスプレッドシートや手順書
問題は、こうしたパスワードが「認証基盤の外側」で運用されることです。MFAを全社展開していても、例外的にMFAが使えないアカウントや、外部サービス側の制約でパスワード認証しか使えないワークフローが残ると、そこが攻撃者にとって狙いやすい入口になります。
Purviewが注目される理由は、この“残存リスク”をデータ保護の観点から管理できるためです。つまり、パスワードがどこに書かれ、誰が共有し、どのチャネルを通じて外に出ようとしているのかを検出し、ポリシーで制御できます。
2026年4月20日の更新で示されたポイント
Microsoftのブログでは、MFAのような強力な認証制御がアカウント侵害を大きく減らす一方で、パスワード露出リスクそのものはなくならないと説明されています。特に、レガシーシステム、サードパーティツール、サービスアカウントがパスワードのみの認証に依存している場合、平文で共有・保存された資格情報は重大なリスクになります。(TECHCOMMUNITY.MICROSOFT.COM)
更新の核心は、Microsoft PurviewのカスタムSensitive Information Type（SIT）を使って、組織固有のパスワード検出ロジックを作ることです。Microsoft PurviewのSITは、正規表現、キーワード、信頼度、近接条件などを組み合わせて機密情報を検出する分類機能であり、組み込みSITだけでなく独自のカスタムSITも作成できます。(Microsoft Learn)
このアプローチでは、単に「強そうな文字列」をすべて拾うのではありません。たとえば、次のような条件を組み合わせます。
| 検出要素 | 役割 | 実務上の意味 |
|---|---|---|
| 文字列の長さ | 10〜20文字など、候補となるパスワード形式を絞る | 短すぎる一般語や長すぎるトークンを除外しやすい |
| 複雑性 | 英字、数字、特殊文字を含むか確認する | 社内パスワードポリシーに近い値を検出できる |
| キーワード | password、pwd、credentialなどの近くにあるか確認する | APIキーやハッシュ値との誤検知を減らせる |
| 近接条件 | キーワードと文字列が同じ文脈にあるか確認する | 「Password: P@ss…」のような露出パターンを拾いやすい |
この設計が重要なのは、セキュリティ運用で問題になりがちな誤検知の多さを抑えやすい点です。APIキー、ランダムな識別子、ハッシュ、ログの断片まで大量に検出してしまうと、SOCや情報保護担当者は対応しきれません。キーワードや近接条件を使うことで、「本当に人がパスワードとして書いた可能性が高いもの」に焦点を当てられます。
Purviewは認証対策ではなく、データ流出対策として使う
ここで誤解してはいけないのは、PurviewがMFAの代替ではないという点です。Purviewは、ログイン時に本人確認を強化する製品ではありません。役割は、資格情報がデータとして露出する前後の動きを管理することです。
たとえば、以下のような場面で有効です。
| シーン | よくある問題 | Purviewでできること |
|---|---|---|
| メール | 「一時的にこのパスワードで入ってください」と送信される | DLPで検出し、警告・ブロック・監査につなげる |
| SharePoint / OneDrive | 手順書や台帳にパスワードが残る | カスタムSITで検出し、ラベル付けやレビュー対象にする |
| Teams | チャットでパスワードを共有する | DLPポリシーで外部共有や投稿を制御する |
| Windows端末 | メモ帳、Excel、ローカルファイルに資格情報が保存される | Endpoint DLPでコピー、印刷、アップロードなどを制御する |
| オンプレミスファイル共有 | 古い運用資料に認証情報が残る | 対象範囲に応じてDLPやスキャンの設計対象にする |
Microsoft Purview Information Protectionは、機密データの検出、保護、データ損失防止を支援する機能群として位置づけられており、DLPは機密情報の意図しない共有を防ぐために使われます。Endpoint DLP、Chrome拡張、オンプレミスリポジトリ向けDLPなど、利用シナリオに応じた拡張も用意されています。(Microsoft Learn)
なぜパスワード検出にはカスタムSITが向いているのか
パスワードは、クレジットカード番号やマイナンバーのように決まった形式を持ちません。組織によってルールが異なり、現場では表記もばらつきます。
たとえば、同じパスワード共有でも次のような書き方があります。
password: P@ssW0rd123!
pwd = Legacy#2026
credential / Admin@12345
初期パスワード：Temp#98765一方で、次のような文字列はパスワードに見えても、実際には別のものかもしれません。
API_KEY = A9$kLmZpQw
hash: e99a18c428cb38d5f260853678922e03
build-token: X7!abPq2026この違いを機械的に判断するには、文字列の強度だけでは不十分です。だからこそ、Microsoftが示したように、Primary element、Supporting element、Keyword、Character proximityを分けて設計する方法が有効です。カスタムSITでは、主要素、補助要素、信頼度、近接条件を組み合わせてパターンを定義できます。(Microsoft Learn)
実務では、いきなり広範囲にブロックするのではなく、まずは「検出」「可視化」「チューニング」から始めるのが安全です。
レガシー・サードパーティ環境で優先的に見るべき対象
Microsoft Purviewでパスワードリスクを管理する場合、最初から全社のすべてを対象にすると、誤検知や運用負荷が増えます。まずは、影響が大きく、かつパスワードが残りやすい領域に絞るべきです。
| 優先度 | 対象 | 理由 | 最初の施策 |
|---|---|---|---|
| 高 | サービスアカウント台帳 | 権限が強く、MFA適用が難しいことがある | SharePoint、Excel、手順書内の平文検出 |
| 高 | 運用手順書 | 障害対応や引き継ぎで資格情報が書かれやすい | password、pwd、credential近接のSITを適用 |
| 高 | メールとTeams | 一時共有が発生しやすく、外部送信リスクがある | DLPで警告・ブロックを段階導入 |
| 中 | RPA・ETL・バッチ処理資料 | 自動化アカウント情報が残りやすい | 関連サイトやチームを重点スキャン |
| 中 | ベンダー連携資料 | 外部委託先との共有で露出範囲が広がる | 外部共有ポリシーと組み合わせる |
| 低〜中 | 開発メモ、検証環境資料 | 本番情報でなければ影響は限定的だが習慣化しやすい | 教育と推奨ラベルから開始 |
特に注意したいのは、サービスアカウントです。ユーザーアカウントと違い、退職や異動で棚卸しされにくく、アプリ連携の都合で長期間同じ資格情報が使われることがあります。Purviewで平文パスワードの保存場所を可視化できれば、ローテーション、権限見直し、シークレット管理ツールへの移行を進めやすくなります。
カスタム検出ルールを設計する実務ステップ
Microsoft Purviewでパスワード露出検出を始める場合、次の順序で進めると失敗しにくくなります。
| ステップ | 実施内容 | 判断基準 |
|---|---|---|
| 1 | 検出対象を決める | サービスアカウント、レガシーアプリ、外部連携などリスクの高い領域から始める |
| 2 | パスワード表記を棚卸しする | password、pwd、pass、credential、日本語の「パスワード」など現場の表記を集める |
| 3 | 正規表現を作る | 長さ、文字種、特殊文字など社内ルールに近づける |
| 4 | キーワードと近接条件を追加する | 強い文字列だけでなく、文脈を見て誤検知を減らす |
| 5 | 監査モードでテストする | いきなりブロックせず、検出件数と誤検知を確認する |
| 6 | 対応フローを決める | 誰が確認し、誰が削除・ローテーション・教育を行うか決める |
| 7 | DLPやラベルに展開する | メール、端末、Teams、SharePointなど対象を段階的に広げる |
Microsoft Purviewポータルでは、Information Protection > Classifiers > Sensitive info typesからカスタムSITを作成し、名前、説明、パターン、信頼度、主要素、近接条件、補助要素などを設定できます。既存コンテンツで新しいカスタムSITを検出するには、SharePointやOneDriveのクロールタイミングも考慮する必要があります。(Microsoft Learn)
正規表現は“強くする”より“運用できる”ことを優先する
パスワード検出用の正規表現は、複雑にしすぎると保守が難しくなります。Microsoftの例でも、巨大な単一正規表現に頼るのではなく、長さ、複雑性、キーワード文脈を分けて設計する考え方が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次のような方針が扱いやすいです。
- まずは10〜20文字程度の非空白文字列を候補にする
- 英大文字、英小文字、数字、特殊文字の条件を補助要素で確認する
- password、pwd、credentialなどの近接キーワードを加える
- 日本語環境では「パスワード」「初期PW」「認証情報」なども候補に入れる
- APIキーやトークンの表記と混同しないよう、除外条件や別SITとの整理を検討する
なお、Microsoft Learnでは、カスタムSITの正規表現で ^ や $ のような位置指定アンカーを使うと意図通りに動作しない可能性があると注意されています。カスタムSITでは、ファイル全体のどの位置が開始・終了として扱われるか保証されないためです。(Microsoft Learn)
DLP、秘密度ラベル、Endpoint DLPへの展開方法
カスタムSITを作っただけでは、まだ統制としては不十分です。重要なのは、その検出結果をどのアクションにつなげるかです。
Microsoft PurviewのSITは、DLPポリシー、秘密度ラベル、保持ラベル、インサイダーリスク管理、コミュニケーションコンプライアンス、自動ラベル付けポリシーなどで利用できます。(Microsoft Learn)
特に、パスワードリスク管理では次の組み合わせが実用的です。
| 目的 | 推奨するPurview機能 | 実装例 |
|---|---|---|
| メールでのパスワード送信を防ぐ | DLP | 外部宛先への送信時に警告またはブロック |
| 手順書内の平文パスワードを見つける | カスタムSIT + コンテンツ確認 | SharePointやOneDrive上のファイルをレビュー対象にする |
| 機密度を明示する | 秘密度ラベル | 認証情報を含む可能性がある文書にラベルを推奨 |
| 端末からの持ち出しを防ぐ | Endpoint DLP | USBコピー、印刷、ブラウザアップロードを制御 |
| Teamsでの共有を抑止する | Teams向けDLP | チャットやチャネル投稿で警告・ブロック |
| 改善サイクルを回す | 監査・レポート | 検出件数、違反者、発生部門を分析する |
DLPポリシーは、SIT、秘密度ラベル、保持ラベルなどとの一致によって機密アイテムを検出します。ただし、対象場所によって使える定義方法が異なり、複数ロケーションを組み合わせた場合はサポート範囲が変わることがあります。ポリシー設計時には、Exchange、SharePoint、OneDrive、Teams、Devices、オンプレミスリポジトリなど、対象ごとの制約を確認する必要があります。(Microsoft Learn)
導入時に失敗しやすいポイント
Microsoft Purviewによるパスワード検出は有効ですが、設計を誤ると現場に嫌われる仕組みになります。特に避けたいのは、初期段階での過剰ブロックです。
誤検知が多すぎて運用が止まる
強い文字列を広く拾いすぎると、APIキー、ハッシュ、ログ、識別子、製品コードまで検出される可能性があります。最初は検出対象を狭くし、キーワード近接を必ず使うべきです。
悪い例は、特殊文字を含む10文字以上の文字列をすべてパスワード扱いすることです。これでは、開発・運用チームのログや構成ファイルが大量に引っかかるおそれがあります。
“検出後の処理”が決まっていない
検出できても、誰が対応するか決まっていないと意味がありません。特にパスワード露出は、ファイル削除だけでは不十分です。
検出時には、少なくとも次を決めておく必要があります。
- 該当パスワードが本物か確認する担当
- 影響するアカウントやシステムの特定方法
- パスワードローテーションの手順
- ファイル削除、修正、ラベル付けの判断基準
- 再発防止の教育対象
サービスアカウントの棚卸しと連動していない
Purviewは露出を見つける仕組みです。サービスアカウントの所有者、用途、権限、ローテーション周期が分からなければ、検出後の対応が遅れます。
理想は、Purviewの検出結果をサービスアカウント台帳と突き合わせることです。たとえば「このパスワードはどのシステムのものか」「所有部門はどこか」「緊急停止してよいか」を即座に判断できる状態を目指します。
例外を恒久化してしまう
レガシーシステムやサードパーティ製品の制約により、すぐにMFAへ移行できないことはあります。しかし、その例外を「仕方ない」で放置すると、Purviewは単なる検出ツールで終わります。
例外には必ず期限を設定します。たとえば、次のように管理すると実効性が高まります。
| 例外の種類 | 管理方法 |
|---|---|
| MFA非対応のサードパーティサービス | 契約更新時に認証方式の見直しを条件化 |
| レガシー業務アプリ | 更改計画にEntra ID連携やSSO対応を含める |
| サービスアカウント | 所有者、用途、権限、ローテーション日を台帳管理 |
| 一時共有パスワード | 有効期限と削除期限を明確化 |
セキュリティアーキテクト向けの判断基準
Security architectが見るべきポイントは、Purviewを「MFAの穴埋め」としてではなく、認証近代化までのリスク低減レイヤーとして設計することです。
判断基準は次の3つです。
| 判断軸 | 確認すべきこと |
|---|---|
| 攻撃影響 | そのパスワードが漏れた場合、どのシステムに入れるか |
| 露出経路 | メール、Teams、SharePoint、端末、外部共有のどこで露出しやすいか |
| 代替計画 | MFA、SSO、シークレット管理、アカウント廃止へ移行できるか |
特に、強い権限を持つサービスアカウントや、外部委託先と共有されるアカウントは優先的に扱うべきです。パスワードが1つ漏れただけで、バックアップ、監視、運用自動化、データ連携の広い範囲に影響する場合があります。
ガバナンス担当者向けの設計ポイント
Governance leadが重視すべきなのは、Purviewの検出結果をポリシーと教育に結び付けることです。平文パスワードの保存禁止を規程に書くだけでは、現場の行動は変わりません。
有効なのは、次のような運用です。
- パスワード共有禁止ルールを具体例付きで定義する
- 例外申請のルートを用意する
- 検出時の通知文を責める文面ではなく、修正行動が分かる文面にする
- 部門別の発生傾向を見て教育する
- 同じ部門で繰り返し発生する場合は業務プロセスを見直す
たとえば、DLP通知では「パスワードが含まれている可能性があります」だけでは不十分です。次のアクションまで示すべきです。
このメールまたはファイルには、平文パスワードが含まれている可能性があります。
パスワードを本文から削除し、承認済みのシークレット管理ツールまたは安全な共有手順を使用してください。
すでに送信・共有した場合は、対象アカウントのパスワード変更を依頼してください。現場が「何をすればよいか」を理解できるほど、DLPは反発されにくくなります。
ITモダナイゼーションチーム向けの活用シーン
IT modernization teamにとって、Purviewの検出結果は移行計画の優先順位付けに使えます。どのシステムが、どの部門で、どの程度パスワード共有に依存しているかを把握できるからです。
たとえば、次のような判断ができます。
| Purviewで見えた傾向 | モダナイゼーション施策 |
|---|---|
| 特定の業務アプリのパスワードが頻繁に共有される | SSO対応、Entra ID連携、アプリ更改を優先 |
| サービスアカウント情報がExcelで管理されている | シークレット管理ツールへ移行 |
| 外部ベンダーとのメールで資格情報共有が多い | ベンダー接続方式、契約、運用手順を見直す |
| 障害対応時だけパスワード共有が増える | 緊急アクセス手順、Privileged Access Managementを整備 |
| 開発・検証環境で平文保存が多い | DevSecOps教育とコード・文書レビューを強化 |
このように、Purviewは単なる防御策ではなく、技術的負債を可視化する材料にもなります。
まず実施すべき最小構成
最初から全機能を使う必要はありません。小さく始めるなら、次の構成が現実的です。
| 項目 | 推奨設定 |
|---|---|
| 対象範囲 | SharePoint、OneDrive、Exchangeから開始 |
| 検出条件 | パスワード形式 + password/pwd/credential/パスワードの近接条件 |
| アクション | 最初は監査・通知中心 |
| 対象部門 | IT運用、開発、情報システム、外部ベンダー連携部門 |
| レビュー頻度 | 週次または隔週で誤検知と実検知を確認 |
| 次の展開 | Teams、Endpoint DLP、外部共有制御へ拡張 |
Microsoftの軽量DLP展開ガイドでも、カスタムSITの作成、クライアント側自動ラベル付け、Teams・エンドポイント・メール向けDLPの展開を段階的に進める流れが示されています。初期導入では、自動適用よりも推奨ラベルから始めることで、ユーザーの確認機会を残し、摩擦を減らせます。(Microsoft Learn)
Purviewだけに頼らず、最終的には認証の近代化へつなげる
Microsoft Purviewによる平文パスワード検出は、レガシー環境に対する有効な橋渡しです。ただし、最終ゴールではありません。
最終的に目指すべき状態は、次のような構成です。
- ユーザー認証はMFAまたはパスワードレスへ移行する
- 業務アプリはSSOや条件付きアクセスに対応させる
- サービスアカウントは最小権限化し、所有者と用途を明確にする
- パスワードやシークレットは承認済みの管理基盤に集約する
- 平文パスワードの保存・共有はPurviewで検出し、DLPで抑止する
- 検出結果をモダナイゼーション計画に反映する
Purviewの価値は、完全なゼロトラスト環境に到達するまでの間、見えにくいパスワード露出を可視化し、現実的に制御できる点にあります。特に、サードパーティ製品、サービスアカウント、古い業務システムが混在する企業では、認証基盤だけでは拾いきれないリスクを補完できます。
まずは、パスワードが残りやすいSharePoint、OneDrive、メール、Teams、運用手順書から確認してください。カスタムSITで検出し、誤検知を調整し、DLPやラベルへ段階的に展開する。この順序で進めれば、レガシー環境を抱えたままでも、パスワードリスクを管理可能な状態へ近づけられます。
コメント