Microsoft Purview Insider Risk Management（IRM）で、Microsoft Fabric、Box、Dropbox、Google Drive、Azure、Amazon Web Servicesの活動を、「データ リーク」ポリシーのトリガーとして利用できるようになりました。
結論として、対象サービスに機密情報や個人情報を保存している組織は、早めに設定内容を確認すべきアップデートです。特に、Power BIレポートのダウンロード、Lakehouseデータの外部共有、外部クラウドからのデータ持ち出しをリスク検知の起点にしたい場合は効果があります。
一方、機能が追加されただけで既存ポリシーが自動的に変更されるわけではありません。対象サービスを利用していない組織や、監視対象に含める予定がない組織では、緊急の設定変更は不要です。本稿では、保護対象、管理者設定、監査・検知への影響、対応要否の判断基準を具体的に整理します。
Microsoft Purview Insider Risk Managementの新トリガーとは
Microsoft 365 Roadmap ID 560399の正式名称は、「Microsoft Purview: Insider Risk Management – Microsoft Fabric, Cloud storage, cloud service activities as triggers」です。
公式ロードマップAPIでは、2026年7月7日23時1分（UTC）に更新されています。日本時間では2026年7月8日です。ステータスは「Launched」、プレビュー提供は2026年6月、一般提供は2026年7月とされています。
ただし、Microsoft 365ロードマップの日付や内容は変更される可能性があります。また、一般提供月に入っていても、すべてのテナントへ同時に機能が反映されるとは限りません。実際に利用できるかは、自社テナントのMicrosoft Purviewポータルで確認する必要があります。(Microsoft)
今回の変更で重要なのは、Microsoft Fabricや外部クラウドの活動が、単なる「インジケーター」だけでなく、ユーザーをポリシーの評価対象に入れる「トリガー」としても利用できるようになった点です。
トリガー、インジケーター、アラートの違い
Insider Risk Managementを正しく運用するには、次の3つを区別する必要があります。
| 用語 | 役割 | 今回のアップデートとの関係 |
|---|---|---|
| トリガー | ユーザーをポリシーのアクティブな評価対象に入れる | Fabricや外部クラウドの活動を選択可能になった |
| インジケーター | 対象ユーザーの活動を評価し、リスクスコアを計算する | ダウンロード、共有、保護変更などの活動をスコアリングする |
| アラート | リスクスコアなどがポリシー条件を満たした場合に生成される | トリガーが発生しただけでは必ずしも生成されない |
例えば、Power BIレポートのダウンロードをトリガーに指定した場合、その活動によってユーザーがポリシーの評価対象に入ります。その後、ポリシーの時間枠やインジケーター設定に基づいて関連活動が評価され、条件を満たした場合にアラートが生成されます。
トリガーイベントは「調査を開始する入口」であり、違反や情報漏洩が確定したことを意味するものではありません。トリガーだけが発生し、アラート生成に必要なリスクスコアへ達していないユーザーも、ユーザーダッシュボードには表示されます。(Microsoft)
対象となるサービスと保護範囲
今回のアップデートでトリガーとして利用できるのは、Microsoft Fabric、クラウドストレージ、クラウドサービスに属するインジケーターです。
ここでいう「保護」とは、ファイルを暗号化したり、ユーザーの操作を即座に遮断したりすることではありません。対象サービス上のユーザー活動を検知し、Insider Risk Managementの評価を開始できる範囲が広がったと理解するのが適切です。
| 分類 | 対象サービス・ワークロード | 主な検知対象の例 | 主な前提条件 |
|---|---|---|---|
| Microsoft Fabric | Power BI、Lakehouse | レポートやダッシュボードの閲覧、Power BIレポートのダウンロード、秘密度ラベルのダウングレード・削除、Lakehouseデータの組織外共有 | Microsoft Purviewの従量課金設定 |
| クラウドストレージ | Box、Dropbox、Google Drive | 環境の把握、データの収集・持ち出し、可用性の中断、システム整合性への影響につながる活動 | 従量課金設定、Microsoft Defenderでのアプリ接続 |
| クラウドサービス | Amazon S3、Azure SQL Server、Azure Storage | トレースログの無効化、SQL Serverファイアウォール規則の変更・削除、データの持ち出し、権限昇格、可用性や整合性への影響 | 従量課金設定、Microsoft Defenderでのソースサービス接続 |
Microsoft Learnでは、Microsoft Fabricの対象としてPower BIとLakehouse、クラウドサービスの対象としてAmazon S3、Azure SQL Server、Azure Storageが具体的に示されています。(Microsoft Learn)
したがって、ロードマップに「AWS」「Azure」「Microsoft Fabric」と書かれていても、すべてのAWSサービス、Azureサービス、Fabricワークロードの全活動が自動的に対象になるわけではありません。最終的な対応範囲は、自社テナントの「ポリシー インジケーター」および「このポリシーのトリガー」に表示される選択肢で判断してください。
対応が必要な組織を判断する基準
すべての組織が直ちに新トリガーを有効化する必要はありません。次の基準で優先度を判断すると、不要なアラートや従量課金を抑えられます。
| 優先度 | 該当する組織 | 推奨する対応 |
|---|---|---|
| 高 | Fabricや対象クラウドに機密情報、顧客データ、設計情報、ソースデータを保存している | テナントへの反映、従量課金、コネクタ、ポリシー設定を早期に確認する |
| 高 | すでにInsider Risk Managementのデータ リーク ポリシーを運用している | 既存ポリシーへ追加すべきトリガーを評価し、小規模な対象者でテストする |
| 高 | 退職予定者、特権ユーザー、委託先などによる外部クラウド利用を重点的に監視したい | 優先ユーザーや限定グループから段階的に適用する |
| 中 | 対象サービスは利用しているが、機密データの保管状況を把握できていない | 先にデータ配置、利用者、通常のダウンロード量を棚卸しする |
| 中 | IRMを利用していないが、マルチクラウドの持ち出しリスクが課題になっている | ライセンスと従量課金を含め、IRM導入の費用対効果を評価する |
| 低 | 対象サービスを利用していない、または監視対象から明示的に除外している | 緊急の設定変更は不要。今後のサービス導入時に再評価する |
特に注意したいのは、対象サービスを利用していること自体ではなく、重要データが置かれているか、通常業務として大量操作が発生するか、誰を重点的に監視するかです。
例えば、Google Driveを少人数のマーケティング部門だけが使っている企業と、全社の顧客データを保存している企業では、同じトリガーでも重要度が大きく異なります。
管理者が行う設定手順
新しいトリガーは、複数の設定がそろわなければ利用できません。外部クラウドをMicrosoft Defenderへ接続しただけ、またはPurviewでインジケーターを有効にしただけでは不十分です。
テナントへの機能反映と課金条件を確認する
最初に、Microsoft Purviewポータルで対象のトリガーが表示されるか確認します。
併せて、次の項目を確認してください。
- Insider Risk Managementを利用できるライセンスが割り当てられているか
- Microsoft Purviewの従量課金が有効になっているか
- Azureサブスクリプションや請求先が正しく設定されているか
- Usage centerで利用状況を確認できるか
- 社内の予算管理者やクラウド管理者が従量課金の利用を承認しているか
Microsoft Fabric、クラウドストレージ、クラウドサービスのインジケーターには、従量課金の有効化が必要です。Insider Risk Managementでは、ライセンスと従量課金の両方が関係する場合があるため、機能の表示だけで利用可否を判断しないでください。(Microsoft Learn)
管理権限と監査ログを確認する
ポリシーの設定担当者には、Insider Risk Managementの適切なロールグループを割り当てます。
実務では、少なくとも次の担当を分離すると安全です。
- ポリシーを作成・変更する管理者
- アラートを一次確認するアナリスト
- ケースを詳しく調査する調査担当者
- 監査や法務判断を行う責任者
また、Microsoft 365の監査が有効になっていることも確認してください。Insider Risk Managementのポリシーや分析は、Microsoft 365の監査ログを利用してリスク活動を検知します。(Microsoft Learn)
権限を広く付与しすぎると、従業員の活動情報へ不必要にアクセスできる状態になります。日常的なMicrosoft 365管理者全員へIRMの調査権限を付与するのではなく、職務に応じた最小権限を設定してください。
外部クラウドをMicrosoft Defenderへ接続する
Box、Dropbox、Google Drive、AWS、Azureの活動を利用するには、対象アプリやソースサービスをMicrosoft Defenderへ接続する必要があります。
基本的な操作経路は次のとおりです。
- Microsoft Defenderポータルへサインインする
Cloud AppsからConnected appsを開くConnect an appまたはAdd a new connectorを選択する- 接続するクラウドサービスを選択する
- サービスごとのAPI権限と認証設定を完了する
必要な権限や認証方法はサービスごとに異なります。接続時は、BoxやGoogle Driveなどの管理者権限だけでなく、監査ログの取得権限、APIの利用制限、接続対象となるクラウドインスタンスも確認してください。(Microsoft Learn)
外部クラウドの活動は、クラウド事業者が提供するAPIを通じて収集されます。そのため、APIのスロットリング、取得可能期間、テナント規模などの影響を受けます。初回スキャンや大量ファイルの処理には、数時間から数日かかる場合があります。接続直後に活動が表示されないからといって、すぐに設定ミスと判断しないことが大切です。(Microsoft Learn)
必要なポリシー インジケーターを有効にする
Microsoft Purviewポータルで、次のように移動します。
設定 → Insider Risk Management → ポリシー インジケーター
利用したいサービスに応じて、次のインジケーターを有効にします。
- Microsoft Fabricインジケーター
- クラウド ストレージ インジケーター
- クラウド サービス インジケーター
対象外のアプリや活動まで一括で有効にする必要はありません。
例えば、Google DriveとBoxは利用しているがDropboxを利用していない場合、Dropbox関連のインジケーターを無効にできます。監視対象を絞ることで、アラートのノイズと不要な従量課金を抑えやすくなります。(Microsoft Learn)
データ リーク ポリシーへトリガーを追加する
新規ポリシーを作成する場合は、Microsoft Purviewポータルから次のように進みます。
Insider Risk Managementを開くポリシーを選択するポリシーの作成を選択するデータ リークまたは優先度の高いユーザーによるデータ リークテンプレートを選択する- 対象ユーザー、グループ、除外対象を設定する
- 必要に応じて優先コンテンツを設定する
このポリシーのトリガーで、流出アクティビティをトリガーにする選択肢を選ぶ- Microsoft Fabric、クラウドストレージ、クラウドサービスから必要なトリガーを選択する
- 既定またはカスタムのトリガーしきい値を設定する
- リスクスコアの計算に使用するポリシー インジケーターを選択する
- 設定内容を確認してポリシーを有効にする
画面上でインジケーターを選択できない場合は、グローバル設定でそのインジケーターが有効になっているか確認します。
重要なのは、トリガーとして選ぶ活動と、リスクスコアの計算に使うインジケーターを分けて設計することです。トリガーだけを追加し、スコアリング対象を適切に設定していないと、期待したアラートが生成されない可能性があります。(Microsoft Learn)
最初から全ユーザーへ適用しない
導入時は、次のような小規模な対象から始めるのが安全です。
- 承認済みのテストアカウント
- 対象クラウドを日常的に利用する一部門
- 機密データを扱う優先ユーザー
- 退職者対応を担当する人事・法務部門と合意した限定グループ
テストでは、実際の機密データではなく、識別可能なテストファイルやテストレポートを使います。
確認すべき項目は、トリガーイベントが記録されることだけではありません。
- ユーザーがポリシーの評価対象に入ったか
- ユーザーダッシュボードに表示されたか
- 関連活動へリスクスコアが付いたか
- どの条件でアラートが生成されたか
- 外部クラウドの活動が欠落していないか
- 正常業務が大量に検知されていないか
- 従量課金の使用量が想定内か
1件のテストイベントだけで判断せず、月次処理や定期バックアップなど、通常業務が一巡する期間を観察してから対象範囲を広げてください。
監査・検知への影響
ポリシーの評価対象となるユーザーが増える
これまでは別のトリガーが発生しなければ評価対象にならなかったユーザーでも、Fabricや外部クラウド上の活動をきっかけに、データ リーク ポリシーのスコープへ入る可能性があります。
その結果、次の変化が想定されます。
- ユーザーダッシュボードに表示される人数が増える
- Fabricや外部クラウドを起点とする調査が増える
- アラートのリスク要因にマルチクラウドの活動が含まれる
- 従来はMicrosoft 365内だけで完結していた調査に、外部クラウド側の業務背景確認が必要になる
ただし、トリガーイベントが発生したユーザー全員にアラートが生成されるわけではありません。アラートには、トリガーに加えて、ポリシー条件を満たす活動リスクスコアが必要です。(Microsoft Learn)
トリガーの前後にある活動も調査対象になり得る
Insider Risk Managementには、トリガー発生後の活動を評価する「アクティブ化期間」と、トリガー前の活動を確認する「過去のアクティビティの検出」があります。
現在のMicrosoft Learnでは、次の範囲で設定できます。
- アクティブ化期間：トリガー発生後1～30日
- 過去のアクティビティの検出：監査ログ上の活動についてトリガー発生前0～90日
そのため、1回のPower BIレポートダウンロードや外部クラウド活動を起点として、その前後に発生した関連活動を広く確認できる場合があります。(Microsoft Learn)
期間を長くすれば調査範囲は広がりますが、スコアリング対象や確認すべきイベントも増えます。すべてのポリシーで一律に最大期間を設定するのではなく、退職者、特権ユーザー、一般ユーザーなど、シナリオごとに期間を設計してください。
監査ログやコネクタの保持設定は自動変更されない
今回のアップデートは、Insider Risk Managementで利用できるトリガーの追加です。
次の設定が自動的に変更されるわけではありません。
- Microsoft 365監査ログの設定
- 各クラウドサービスの監査ログ保持期間
- APIコネクタの権限
- DLPポリシーによる操作のブロック
- AzureやAWSのアクセス権
- ファイルの暗号化や秘密度ラベル
- SIEM側の検知ルール
「IRMで検知できるようになったため、外部クラウド側の監査設定は不要」と考えるのは危険です。IRMは複数のシグナルを関連付けて潜在的なリスクを発見する仕組みであり、元となるログやコネクタが取得できなければ、十分な検知はできません。(Microsoft Learn)
SIEM連携ではトリガーだけのユーザーを見落とさない
Insider Risk Managementのアラート情報は、SIEMやSOARへエクスポートできます。Microsoft Sentinelを利用している場合は、Insider Risk Management用のデータコネクタも利用できます。(Microsoft Learn)
ただし、SIEMへ連携される中心的な情報は「アラート」です。
トリガーイベントが発生していても、リスクスコアがアラート生成条件へ達していないユーザーは、IRMのユーザーダッシュボードには表示される一方、アラートフィードでは確認できない可能性があります。
運用では次の2つを分けて確認してください。
- アラートキュー：優先的な調査が必要な高リスク活動
- ユーザーダッシュボード：トリガーは発生したがアラートへ達していないユーザー
SIEMだけを見てIRMを運用すると、ポリシーへ入ったもののアラートになっていないユーザーの傾向を把握しにくくなります。
誤検知や運用負荷を増やしやすい活動
Fabricや外部クラウドでは、大量ダウンロードや外部共有が正規業務として行われることがあります。
例えば、次のような活動です。
- 月次報告のためにPower BIレポートを一括でダウンロードする
- Google DriveからMicrosoft 365へデータを移行する
- BoxやDropboxの契約終了に伴いファイルを一括回収する
- データ分析担当者がAmazon S3から大量データを取得する
- 運用担当者がAzure SQL Serverのファイアウォール規則を変更する
- データ管理者が分類見直しのため秘密度ラベルを変更する
- バックアップや災害対策のためデータを別環境へ複製する
これらを業務背景なしに評価すると、正常な作業をインサイダーリスクとして大量に検知する可能性があります。
ノイズを抑える具体策
アラートのノイズを抑えるには、次の順序で調整します。
- 対象サービスを実際に利用しているものだけに絞る
- 全ユーザーではなく、対象部署や優先ユーザーから開始する
- 機密度の高いコンテンツにスコアリング対象を絞る
- 通常業務のイベント数を確認してからしきい値を設定する
- データ移行やシステム更改で使用する専用アカウントを整理する
- 定期作業について、変更申請や作業チケットを調査時に参照できるようにする
- トリガーだけのユーザーと、アラートが生成されたユーザーを分けて分析する
- Usage centerで従量課金の増加を確認する
「多く検知するほど安全」とは限りません。確認できない件数のアラートを生成すると、本当に重要な活動が埋もれます。
一方で、除外対象を広げすぎるのも危険です。管理者やデータ移行担当者は、大量データへ正当にアクセスできるからこそ、侵害時の影響が大きくなります。恒久的に除外するのではなく、しきい値、優先コンテンツ、対象期間、調査手順を組み合わせて調整してください。
設定時に失敗しやすいポイント
| よくある誤解 | 実際の仕様・対策 |
|---|---|
| 一般提供になれば自動的に監視される | 管理者による従量課金、接続、インジケーター、ポリシートリガーの設定が必要 |
| トリガーが発生すれば必ずアラートになる | 活動リスクスコアなどが条件を満たした場合にアラートが生成される |
| AWSやAzureの全サービスが対象になる | 現行ドキュメントではAmazon S3、Azure SQL Server、Azure Storageなど具体的な範囲が示されている |
| Defenderへアプリを接続すれば設定完了 | Purview側でもインジケーターとポリシーの設定が必要 |
| トリガーとポリシー インジケーターは同じ設定 | ユーザーを評価対象へ入れる条件と、リスクスコアの計算対象は別に設計する |
| 接続直後からすべての活動が表示される | 初回スキャンやAPI制限により反映に時間がかかることがある |
| 全サービスと全ユーザーを有効にした方が安全 | ノイズ、調査負荷、従量課金が増えるため、段階導入が適切 |
| アラートは不正行為の証拠になる | 潜在的なリスクを示すシグナルであり、業務背景を含む追加調査が必要 |
プライバシーと社内手続きも見直す
Insider Risk Managementは、プライバシーを考慮して設計されており、既定ではユーザー情報が仮名化されます。また、ロールベースのアクセス制御と監査ログによって、ユーザーレベルの情報へのアクセスを管理できます。(Microsoft Learn)
ただし、監視対象がMicrosoft 365内からFabricや外部クラウドへ広がることで、社内で処理する従業員活動データの範囲も広がります。
導入前に、次の項目を確認してください。
- 就業規則や情報セキュリティ規程で監視範囲が説明されているか
- 外部クラウドの活動をIRMへ取り込むことが社内方針と整合するか
- アラートを閲覧できる担当者が限定されているか
- 人事、法務、コンプライアンス部門の関与条件が決まっているか
- 調査開始、ケース化、本人確認、証拠保全の手順が定義されているか
- アラートだけを根拠に懲戒やアカウント停止を行わない運用になっているか
- SIEMや外部システムへエクスポートする際の個人情報の扱いを確認したか
IRMのアラートは、潜在的なリスクを優先順位付けするための情報です。人事上、法務上の判断を行う場合は、業務上の正当性、申請記録、アクセス権、本人の役割などを含めて調査する必要があります。
管理者が優先すべき対応
対応に迷う場合は、次の順番で進めてください。
| タイミング | 優先する作業 | 完了条件 |
|---|---|---|
| 最初に行う | Fabric、Box、Dropbox、Google Drive、Amazon S3、Azureの利用状況を棚卸しする | 利用部門、データ種別、管理者、通常の大量操作を把握できている |
| 次に行う | テナントへの機能反映、ライセンス、従量課金を確認する | 対象インジケーターとトリガーを選択でき、費用負担者が明確になっている |
| 有効化前 | Defenderのアプリ接続、監査ログ、ロールを確認する | 必要な活動が取得でき、アクセス権が最小化されている |
| ポリシー設計時 | トリガー、スコアリング対象、しきい値、対象者を分けて設計する | 何をきっかけに、何を評価し、誰が調査するか説明できる |
| 導入初期 | テストユーザーや限定部門で運用する | トリガー、リスクスコア、アラートの一連の動作を確認できている |
| 導入後 | アラート件数、トリガーのみのユーザー、コネクタ状態、課金を確認する | 正常業務のノイズを抑えながら重要な活動を検知できている |
今回のアップデートは、Microsoft 365の外側で発生するデータ持ち出しリスクを、Insider Risk Managementのポリシーへ取り込める重要な拡張です。
対象サービスを利用している組織は、まず機密データの配置と通常業務を棚卸しし、従量課金とコネクタを確認してください。そのうえで、少人数のテスト範囲からデータ リーク ポリシーへ新トリガーを追加するのが安全です。
対象サービスを利用していない場合は、現時点で設定を変える必要はありません。ただし、今後Fabricや外部クラウドへ重要データを移行する際に見落とさないよう、ロードマップ項目と対応判断を変更管理記録へ残しておくとよいでしょう。
コメント