先日、Microsoft Defender for Cloud Apps (MDCA, MDA) セッションポリシーを使って機密情報の SharePoint Online アップロードをブロックする検証をしました。
(以下箇条書きのシナリオ)
- 対象操作：ファイルアップロード
- 対象領域：SharePoint Online
- 対象ファイル：機密情報を含むが、秘密度ラベルが設定されていないファイル
- 制御：ファイルアップロードのブロック、管理者への通知
調査の第一歩として多少ざっくりしたシナリオで検証をしていますが、無事に基本的動作と制約事項を確認することができました！
備忘を兼ねて、動作と設定を本記事にまとめます。
Copilot による記事内容のサマリ1
- この記事では、Microsoft Defender for Cloud Apps セッションポリシーを使用して、機密情報の SharePoint Online へのアップロードをブロックする方法について解説しています。
- 具体的な設定手順や動作例を通じて、ブラウザ起点のファイル操作を制御する方法を詳しく説明しています。
- また、検証中に見えてきた制約や課題についても触れ、実際の運用に向けた考察を行っています。
目次
本記事は以下の構成です：
| # | 章題 | 概要 |
|---|---|---|
| 1 | 実装イメージ | システム側の製品連携と、ユーザーエクスペリエンスを簡易に図示します |
| 2 | 動作例 | ユーザーに表示される実際のブロック画面と、管理者向けのアラート画面を掲載します |
| 3 | 制約と課題 | 製品仕様による制約と、本番実装に向け検討が必要と思われる課題について軽く触れます |
| 4 | 検証ステップ | 今回検証した際に実施したことを、構築フェーズとテストフェーズに分けてステップごとにまとめます |
少し長めの記事になってしまったので、飛ばし読み推奨です🚀
PC で開いていただけると、Qiita 標準機能の目次が常に表示されますので、ご活用ください！
1. 実装イメージ
- 参考：
今回は、試しに SharePoint Online へのアップロードブロックを検証しました。
下図 (↓) は、検証時の構成を簡易にまとめてみたものです。
- ユーザー (上図：Test User) が、Purview で定義された機密情報を含むコンテンツ (上図：script.sh) をアップロードしようとする
- セッションポリシーと条件付きアクセスポリシーの連携によるアクセス制御(セッション制御)が適用され、アップロードがブロックされる
なお、今回は機密情報の種類を指定したうえで、さらに秘密度ラベルのついていないファイルに限定してアップロードをブロックする制御にしました。
下フローのイメージです。
今回は検証のため多少大雑把にシナリオを組んで実装しましたが、ポリシーの構成によって例えば以下のシナリオに応用することも可能です。
- ダウンロードのブロック
- OneDrive for Business 領域の保護
- デバイス管理状態に応じた制御の分岐
ただし、後ほど「3. 制約と課題」セクションにも記載しますが、MDCA セッションポリシーが制御できるのはブラウザのみのため、ある程度シナリオは限定される印象です。
(参考：Conditional Access app control in Microsoft Defender for Cloud Apps - Scope of support for session control
2. 動作例
今回私が実施した検証では、以下の動作を確認することができました。
- ユーザーが機密情報をアップロードしようとする
- アクセス制御(セッション制御)が適用され、アップロードがブロックされる
- アップロードブロックされたことがアラートされる (Defender 管理センター および メール)
なお、公開情報にもあるように、リンクの URL に *.mcas.ms2 サフィックスが表示されています。
以下、検証時の画面ショットです。
写真はすべて検証環境のものです。
UPN などドメイン名が含まれるものは万が一のためマスクしました。
また、自分用に付けているポリシープレフィックスなど、センス皆無がバレそうなものもマスクしています。
3. 制約と課題
- 参考：
検証をするなかで、制約と課題についても見えてきました。
壁打ちを兼ねて... 個人的に特に気になった点を以下にまとめます。
一般的な既知の制約についてはすでに公開情報もありますので、ご興味のある方はぜひ上リンクを順にご参考ください！
制約
今回検証をしていて、以下の制約が特に目について気になりました。
どれも仕様によるもので、乗り越えることのできない壁です。(製品フィードバックのチャンス？)
| # | 仕様 (制約) | 備考 |
|---|---|---|
| 1 | サポート範囲がブラウザ限定 | クライアントアプリからアップロードされたコンテンツは条件に合致してもブロックできない |
| 2 | 制御対象領域の指定はアプリ 単位3 | SharePoint Online 下の特定領域 / 特定フォルダに限定してアップロードブロックを実装することはできない |
上記は MDCA ファイルポリシーの仕様のため、実装できないのはアップロードに限らず、ダウンロードなどセッションポリシーがサポートするその他の動作についても同様です。
1) サポート範囲がブラウザ限定
MDCA セッションポリシーではブラウザのみサポートされており、クライアントアプリはサポート外です。
これにより、制御できるのはブラウザ起点のファイルのアップロード/ダウンロード動作に限定されます。
ブラウザから条件に合致するファイル (機密情報を含むファイル) をアップロードしようとするとブロックされますが、クライアントアプリからはブロックされずにアップロード可能です。
クライアントアプリの「サポート外」挙動
製品/機能によっては、たまにサポート外とはいえ実質制御されるようなものもありますが、MDCAのセッションポリシーに関してはサポート外＝スルーされる (制御がかからない) という結果になりました。
条件付きアクセスポリシーで「モバイルアプリとデスクトップクライアント」を含めた (明示的に除外しない) としても、挙動は変わりませんでした。
クライアントアプリの制御
Entra ID の条件付きアクセスポリシー または MDCA アクセスポリシーを使い、クライアントアプリ経由のアクセス自体をブロックするとすり抜けを防ぐことができます。
個人的には、条件付きアクセスポリシーを 2個セットで用意するのが分かりやすいのではと思いました。
- ブラウザを対象にアクセス許可、MDCA セッションポリシー (アプリの条件付きアクセス制御) を使う
- クライアントアプリ (モバイルアプリとデスクトップクライアント) を対象にアクセスブロック
2) 制御対象領域の指定はアプリ単位
SharePoint Online (これがひとつのアプリという扱い3) 全体に対するアップロードブロックは可能です。
ただし、このフォルダ / この領域だけ... といった、SPO 全体よりも狭い特定の領域を指定することはできません。
(MDCA のファイルポリシーでは特定の SPO フォルダに限定した構成が可能なので、同じ MDCA のポリシーでもセッションポリシーはできないのか、と新鮮な驚きを感じました。)
課題
以上の制約を踏まえると、一旦検証の範囲ではいい感じに動いているように見えますが、これが本番環境・実在の組織での運用に使えるのかは、慎重に考える必要があるだろうと思いました。
| # | 課題例 | 備考 |
|---|---|---|
| 1 | ユースケース | 想定するユースケースに実装するとして、制御に穴はないか？意図した動作になるのか？ |
| 2 | チューニング | 誤検知 / 過検知はないか？ 実運用に耐えられるのか？ |
1) ユースケース
どういったシナリオで使いたいのか、検討にあたってユースケースは明確であった方がいいですね。
MDCA セッションポリシーがブラウザ制御のみを対象にしている時点で、クライアントアプリを使うケースには無力です。
←とはいえ抑止力になるからいいと考えるのか、ユーザーエクスペリエンスの揺れは忌避されるか、組織によっても考え方が違うのではないでしょうか。
個人的には、ブラウザに限定して BYOD 利用を許可しているような組織に適応が高い機能なのではと思いました。
このようなケースだと、ブラウザに限定してアップロード/ダウンロードを制御することも理にかなっています。
(ポリシーの構成次第で、組織所有デバイスは除外して BYOD のみを適用対象にすることが可能です。)
ユースケース例 (公開情報より)
公開情報にも、組織によって管理されていないデバイス (アンマネージド デバイス) に対する制御がユースケース例として掲載されていました。
セッション ポリシーを使用して、次の手順を実行します。
- OneDrive からアンマネージド デバイスへの機密ファイルのダウンロードをブロックします。
- SharePoint Online へのマルウェア ファイルのアップロードをブロックします。
―― Microsoft Defender for Cloud Appsでのアプリの条件付きアクセス制御 より (2025年3月3日閲覧)
2) チューニング
また、誤検知 / 過検知の観点でのチューニングが必要になるかもしれません。
- 機密情報検知が運用に耐えうるか？
- ブロック制御が業務を疎外しないか？
範囲 (ユーザー) を限定してパイロット実装する評価フェーズを設けるのが一番確実な選択肢かと思いました。(可能であれば...)
今回は実業務データの無い検証環境で動作検証したため、検知動作観点で実運用に耐えうるのかは残念ながら評価できませんでした。
以上、壁打ちできる範囲でのまとめになってしまいましたが、みなさまはどう思いますか？
よければぜひコメント欄で教えてください。
4. 検証ステップ
構築とテストは、それぞれ以下図のステップで実施しました。
Microsoft Purview 側設定について
今回実装する制御が「秘密度ラベルがついていないが機密情報を含むファイルのSPOアップロードをブロックする」のため、すでに実装環境で以下が済んでいる状態を前提としています。
- 機密情報の定義
- 秘密度ラベルの作成、発行、運用
Purview 側の設定については本記事では深入りしていません。
なお簡易な動作確認目的であれば、特に何もせずともプリセットの機密情報定義を利用したり、デフォルトの秘密度ラベルとラベルポリシーを利用したりし、本記事と同じ内容の検証をこなすことが可能です。
(ｍラベル有無や機密情報云々の条件分岐フィルター自体を使わないことも可能です。)
-
参考：
-
Learn about trainable classifiers
("Pretrained classifiers" というすぐに使える分類子があります) - Default sensitivity labels and policies to protect your data
-
Learn about trainable classifiers
クライアントアプリの制御について
MDCA セッションポリシーのサポート外となるクライアントアプリについては、制御のすり抜けを防ぐために以下いずれかを追加構成して手当てすることがおすすめです。
- Entra ID の条件付きアクセスポリシー
- MDCA アクセスポリシー
なお、これらの設定については本記事では深入りしていません。
個人的には、いかのよ条件付きアクセスポリシーを 2個セットで用意するのが分かりやすいのではと思いました。
- ブラウザを対象にアクセス許可、MDCA セッションポリシー (アプリの条件付きアクセス制御) を使う
- クライアントアプリ (モバイルアプリとデスクトップクライアント) を対象にアクセスブロック
以降、各段階で実施したこと (特にパラメータ) を軽くまとめます。
構築フェーズ
| # | 操作対象 | 実施概要 | 備考 |
|---|---|---|---|
| 1 | Entra ID | 条件付きアクセスポリシー作成 | アプリオンボードの入り口になる条件付きアクセスポリシーを作成します |
| 2 | Defender for Cloud Apps (MDCA) | App onboarding/maintenance ユーザー設定 | SharePoint Online (SPO) と MDCA を接続するため、アプリオンボードに使用するユーザーを設定します |
| 3 | SharePoint Online (SPO) | サービスアクセス (アプリオンボード) | 前項で設定したユーザーで SPO にサインインします (すると、SPO の MDCA オンボード (接続) が完了します) |
| 4 | MDCA | Conditional Access App Control apps 確認 | Defender 管理センター上で、SPO 接続が正常であることを確認します |
| 5 | MDCA | セッションポリシー作成 | セッションポリシーを作成します |
1) Entra ID: 条件付きアクセスポリシー作成
-
参考：
- [TechCommunity QA] How to get Sharepoint online into Conditional Access app Control
- [YouTube] How to setup Defender for Cloud Apps Session Control
まずはじめに、入り口となる条件付きアクセスポリシーを作成します。
ここら辺は検証時初見でかなりまごつき、上リンクの TechCommunity QA と YouTube を全面的に参考にしました。
以下が当検証環境で利用したパラメータ例です。
条件付きアクセスポリシー（長いので折りたたみました。左端の ▶ をクリックして展開）
| # | 大項目 | 中項目 | 小項目 | 既定値 | 設定値 (例) | 備考 |
|---|---|---|---|---|---|---|
| 1 | 名前 | - | - | (空白) | {prefix} Require MDCA Session Policy Control | 直観的にわかりやすい名前 (主観) を設定。 |
| 2 | 割り当て | ユーザー | 対象 | なし | {検証ユーザーを選択} | 検証に使うユーザーアカウント (App onboarding/mmaintenance ユーザー含む) を選択。 |
| 3 | 割り当て | ターゲットリソース | 対象 | なし | すべてのリソース | 検証目的のため広めに設定。 |
| 4 | 割り当て | ネットワーク | - | 未構成 | 未構成 | - |
| 5 | 割り当て | 条件 | - | 未構成 | 未構成 | - |
| 6 | アクセス制御 | 許可 | - | ●アクセス権の付与、●選択したコントロールすべてが必要 | ●アクセス権の付与、●選択したコントロールすべてが必要 | チェックボックスはすべて空白のまま残す。 (特に構成しない) |
| 7 | アクセス制御 | セッション | - | (選択なし) | ■アプリの条件付きアクセス制御を使う、監視のみ (プレビュー) | 「アプリの条件付きアクセス制御を使う」を選択。 |
| 8 | ポリシーの有効化 | - | - | レポート専用 | オン | ポリシーを有効にする。 |
今回は基本的動作の確認を優先したため「ターゲットリソース」は「すべて」、「条件」は「未構成」でポリシーを作成しました。
本番設計の参考にならずすみません...
本番実装に向けて設計検討される場合は、意図せぬすり抜けが起こらないようにご注意ください。
[再掲]クライアントアプリの制御について
MDCA セッションポリシーのサポート外となるクライアントアプリについては、制御のすり抜けを防ぐために以下いずれかを追加構成して手当てすることがおすすめです。
- Entra ID の条件付きアクセスポリシー
- MDCA アクセスポリシー
なお、これらの設定については本記事では深入りしていません。
個人的には、条件付きアクセスポリシーを 2個セットで用意するのが分かりやすいのではと思いました。
- ブラウザを対象にアクセス許可、MDCA セッションポリシー (アプリの条件付きアクセス制御) を使う
- クライアントアプリ (モバイルアプリとデスクトップクライアント) を対象にアクセスブロック
2) MDCA: App onboarding/maintenance ユーザー設定
- 参考：
本工程と次の工程は、「Conditional Access App Control apps」配下に何もアプリが登録されていない場合に実施します。
(「Conditional Access App Control apps」配下に何もアプリが登録されていないと、セッションポリシーを作成できません。)
- 確認事項：「Conditional Access App Control apps」配下にアプリが登録されているか？
- 確認方法：本記事「4) MDCA: Conditional Access App Control apps 確認」ご参照
アプリをオンボードするための作業用アカウントを設定します。
ここで使ったユーザー アカウントについて
「App onboarding/maintenance」の included users アカウントには、先ほど作成した条件付きアクセスポリシーの適用対象のアカウントを利用しました。
3) SPO: サービスアクセス (アプリオンボード)
- 参考：
前工程と本工程は、「Conditional Access App Control apps」配下に何もアプリが登録されていない場合に実施します。
(「Conditional Access App Control apps」配下に何もアプリが登録されていないと、セッションポリシーを作成できません。)
- 確認事項：「Conditional Access App Control apps」配下にアプリが登録されているか？
- 確認方法：本記事「4) MDCA: Conditional Access App Control apps 確認」ご参照
前工程で「App onboarding/maintenance」の included users として設定したアカウントで、MDCA にオンボードしたいアプリサービスにサインインしていきます。
(今回は SharePoint Online と、ついでにそのほかいくつかのアプリにサインインしました。)
すると、「{アプリ/サービス名} へのアクセスは監視されています」という画面が表示されるので、「{アプリ/サービス名} を続行する」を押下します。
(この後、通常のサインイン後の画面が表示されます。)
4) MDCA: Conditional Access App Control apps 確認
- 参考：
Defender 管理センター (security.microsoft.com) でオンボードされたアプリを確認します。
[Settings] > [Cloud Apps] > [Conditional Access App Control apps] を開いたときに、以下写真の例のように何もリスト表示されないと、何もオンボードされていない状態です。
今回検証時は、3) の工程まで実施すると以下写真のようにアプリがオンボードされた状態になりました。
上写真のように「Available controls」欄に「Session control」と表示されていると、セッションポリシーの編集画面でアプリを指定できるそうです。
(参考：How to setup Defender for Cloud Apps Session Control)
アプリをオンボードせずにセッションポリシーを作成しようとすると...
何もアプリがオンボードされていない状態 (テナント初期状態) だと、以下警告が出てセッションポリシーを作成・保存することができません。
アプリコネクタでアプリ接続済みの場合も...
「Conditional Access App Control apps」画面上にアプリが無い場合は、オンボードが必要です。
当環境でも、別途ファイルポリシーで使うために Microsoft 365 や Microsoft Azure を「App Connectors (アプリコネクタ)」画面で接続済み (下写真) でしたが、ここの設定はセッションポリシーに関係ありませんでした。
5) MDCA: セッションポリシー作成
満を持してセッションポリシーを作成します。
以下が当検証環境で利用したパラメータ例です。
セッションポリシー（長いので折りたたみました。左端の ▶ をクリックして展開）
| # | 項目 | 既定値 | 設定値 (例) | 備考 |
|---|---|---|---|---|
| 1 | Policy template | - | Block upload based on real-time content inspection | リアルタイムにコンテンツを検知してアップロードをブロックするテンプレートを利用。 |
| 2 | Policy name | Block upload based on real-time content inspection | {prefix} Block upload based on real-time content inspection | テンプレート名がそのまま既定のポリシー名に (編集可能)。今回は編集してプリフィックスを追加。 |
| 3 | Policy severity | Medium | Medium | - |
| 4 | Category | DLP | DLP | - |
| 5 | Description | {記載割愛} | {記載割愛} | テンプレート既定の説明分をそのまま利用。 |
| 6 | Session control type | Control file upload (with inspection) | Control file upload (with inspection) | アップロード制御 (テンプレート既定値) を実装する。 |
| 7 | Activities matching all of the following | [Device]+[Tag]+[does not equal]+[Intune compliant, Microsoft Entra Hybrid joined] | [App]+[equals]+[Microsoft SharePoint Online] | 今回はデバイス管理状態に応じた分岐は実施しないため既定のフィルターを削除。代わりの条件として、「Microsoft SharePoint Online」アプリを指定。 |
| 8 | Files matching all of the following | (フィルターなし) | [Sensitivity label]+[does not equal]+[{テナント上に存在する秘密度ラベルを選択}] | フィルターを追加し、「選択した秘密度ラベルの付与されていないファイル」条件を設定。 |
| 9 | Inspection method | [Data Classification Service]+Match if [Any]+{Choose inspection type} | [Data Classification Service]+Match if [Any]+[Source code] | 「指定の機密情報を含む」条件を設定。 (今回は試しにPurview上にプリセットで存在している「Source code」を機密情報の定義として利用) |
| 10 | Actions | Block | Block | アップロードをブロックする。 |
| 11 | Alerts | ■ Create an alert for each matching event with the policy's severity | ■ Create an alert for each matching event with the policy's severity、■ Send alert as email | Defender 管理センターにアラート発砲 + 指定の管理者メールアドレスにアラートする。(メールアラートを追加) |
なお、本記事「1. 実装イメージ」セクションに掲載した制御のフローをここであらためてみると、セッションポリシーの構成次第で分岐条件の設定が可能ということが分かりやすいかと思います！
以上で、必要な設定がひととおり揃いました。
テストフェーズ
| # | 操作対象 | 実施概要 | 備考 |
|---|---|---|---|
| 1 | Entra ID | 条件付きアクセスポリシー編集 | セッションポリシーの入り口になるよう、条件付きアクセスポリシーを既定値に更新します |
| 2 | GitHub | テストファイル用意 | 機密情報 (Source code) を含む適当なファイルを用意します |
| 3 | Purview | テストファイル検証 | 用意したテストファイルが、Purview でプリセットされた「Source code」機密情報定義に合致するか (機密情報を含むファイルとみなされるか) 検証します |
| 4 | SharePoint Online (SPO) | アップロード検証 | 機密情報を含むテストファイルを SPO にアップロードし、意図した制御が適用されるか確認します (秘密度ラベルがついていないとき / ついているとき を比較確認します) |
| 5 | Defender for Cloud Apps (MDCA) | アラート確認 | 制御が適用された場合のアラート動作を確認します |
1) Entra ID: 条件付きアクセスポリシー編集
構築フェーズ冒頭にてアプリオンボード用に作成した条件付きアクセスポリシーを編集して、セッション制御下のドロップダウンメニュー選択を既定値に戻しておきます。
公開情報上にはここのドロップダウンメニューで何を選択すべきか特に指定されていなかったので、安全第一の精神で既定値にして検証しました🥺
- BEFORE：監視のみ (プレビュー)
- AFTER：カスタム ポリシーを使用する
条件付きアクセスポリシー（長いので折りたたみました。左端の ▶ をクリックして展開）
| # | 大項目 | 中項目 | 小項目 | 既定値 | 設定値 (例) | 備考 |
|---|---|---|---|---|---|---|
| 1 | 名前 | - | - | (空白) | {prefix} Require MDCA Session Policy Control | 直観的にわかりやすい名前 (主観) を設定。 |
| 2 | 割り当て | ユーザー | 対象 | なし | {検証ユーザーを選択} | 検証に使うユーザーアカウント (App onboarding/mmaintenance ユーザー含む) を選択。 |
| 3 | 割り当て | ターゲットリソース | 対象 | なし | すべてのリソース | - |
| 4 | 割り当て | ネットワーク | - | 未構成 | 未構成 | - |
| 5 | 割り当て | 条件 | - | 未構成 | 未構成 | - |
| 6 | アクセス制御 | 許可 | - | ●アクセス権の付与、●選択したコントロールすべてが必要 | ●アクセス権の付与、●選択したコントロールすべてが必要 | チェックボックスはすべて空白のまま残す。 (特に構成しない) |
| 7 | アクセス制御 | セッション | - | (選択なし) | ■アプリの条件付きアクセス制御を使う、カスタム ポリシーを使用する | 「アプリの条件付きアクセス制御を使う」を選択。 |
| 8 | ポリシーの有効化 | - | - | レポート専用 | オン | ポリシーを有効にする。 |
今回は基本的動作の確認を優先したため「ターゲットリソース」は「すべて」、「条件」は「未構成」でポリシーを作成しました。
本番設計の参考にならずすみません...
本番実装に向けて設計検討される場合は、意図せぬすり抜けが起こらないようにご注意ください。
[再掲]クライアントアプリの制御について
MDCA セッションポリシーのサポート外となるクライアントアプリについては、制御のすり抜けを防ぐために以下いずれかを追加構成して手当てすることがおすすめです。
- Entra ID の条件付きアクセスポリシー
- MDCA アクセスポリシー
なお、これらの設定については本記事では深入りしていません。
個人的には、条件付きアクセスポリシーを 2個セットで用意するのが分かりやすいのではと思いました。
- ブラウザを対象にアクセス許可、MDCA セッションポリシー (アプリの条件付きアクセス制御) を使う
- クライアントアプリ (モバイルアプリとデスクトップクライアント) を対象にアクセスブロック
2) GitHub: テストファイル用意
今回 MDCA セッションポリシーで、以下を機密情報として参照しています。
[Data Classification Service]+Match if [Any]+[Source code]
Purview が「Source code」と認識するのはどんなファイルか、公開情報を参考に条件を満たせそうなテストファイルを用意します。
Detects items that contain a set of instructions and statements written computer programming languages on GitHub: ActionScript, C, C#, C++, Clojure, CoffeeScript, Go, Haskell, Java, JavaScript, Lua, MATLAB, Objective-C, Perl, PHP, Python, R, Ruby, Scala, Shell, Swift, TeX, Vim Script.
―― Trainable classifiers definitions - Source code より (2025年2月3日閲覧)
今回は Shell スクリプトを使うことにしました。
GitHub 上に神々が公開されているスクリプトから Shell スクリプトを見繕ってダウンロードしています。
(こちらのスクリプトをお借りしました：getProcessorType.sh)
3) Purview: テストファイル検証
念のため、用意したファイルが狙い通り 「Source code」と認識されるのか、事前に Purview ポータル上でテストします。
Trainable classifiers テスト方法について、以下に少し詳しめに記載します。
(長くなったので折りたたみました。)
Trainable classifiers テスト方法（左端の ▶ をクリックして展開）
-
「Trainable classifiers」画面上のリストにて、「Source code」を探す：
- Purview ポータル (
purview.microsoft.com) > [Data Loss Prevention] > [Classifiers] > [Trainable classifiers] を開く - 「Source code」を探す (フィルターを使うと簡単です！)
- Purview ポータル (
-
「Source code」を開く (「Open in new windows」ボタンをクリック)
-
「Source code」ページにて、「Test」をクリック
-
「Upload file to test "Source code"」にて「Upload file」をクリック
- エクスプローラーが開くので、テストしたいファイルを選択して開く
- エクスプローラーが開くので、テストしたいファイルを選択して開く
-
「Uploaded file: {ファイル名}」が表示されているのを確認して、「Test」ボタンをクリック
-
「Result」欄より結果を確認する
- 「{ファイル名} contains "Source code".」と表示されていればOK！
- 「{ファイル名} contains "Source code".」と表示されていればOK！
これで、動作検証にぴったりなファイルを用意できていることが確認できました。
4) SPO: アップロード検証
アクションが実行される場合と実行されない場合をそれぞれ確認するため、以下のシナリオで動作を確認しました。
-
a) 秘密度ラベルがついていないとき
前工程で用意したテストファイルをそのまま使い、SPO へのアップロードを試行します。 -
b) 秘密度ラベルがついているとき
前工程で用意したテストファイルに秘密度ラベルを付けてから、SPO へのアップロードを試行します。
ここで使ったユーザー アカウントについて
動作検証 (テスト) には、条件付きアクセスポリシーの適用対象のアカウントを利用しました。
a) 秘密度ラベルがついていないとき
条件付きアクセスポリシー適用対象のユーザーが、秘密度ラベルのついていない機密情報を含むテストファイルを SPO にアップロードしようとするケースです。
以下の動作を確認することができました：
- ユーザーがブラウザから SPO にアクセスし、ファイルをアップロードしようとする
- アクセス制御(セッション制御)が適用され、アップロードがブロックされる
- アップロードブロックされたことがアラートされる (Defender 管理センター および メール)
写真は本記事「2. 動作例」セクションに掲載したものと同じため割愛し、ブロック画面だけ再掲します。
アップロードがブロックされました
{ファイル名} のアップロードは、組織のセキュリティポリシーによってブロックされています。
Microsoft Defender for Coud Apps
クライアントアプリを使う場合
くどいようですが、MDCA セッションポリシーの仕様として、制御できるのはブラウザ起点の操作に限定されます。
今回の「a) 秘密度ラベルがついていないとき」と同じテストファイルを使うパターンで、ただし Teams クライアントアプリから SPO にアクセスする場合も検証したところ、ブロックされることなくアップロードできてしまう結果になりました。
b) 秘密度ラベルがついているとき
条件付きアクセスポリシー適用対象のユーザーが、秘密度ラベルのついている機密情報を含むテストファイルを SPO にアップロードしようとするケースです。
先ほどと同じファイルを使って、ただし今度は秘密度ラベル付与のステップを最初に挟みます。
以下の動作を確認することができました：
-
ユーザーがファイルに秘密度ラベルを付ける
(ラベルを付けた後、ファイルの拡張子が「.pfile」になりました)
-
ユーザーがブラウザから SPO にアクセスし、ファイルをアップロードしようとする
-
ブロックされずにアップロードが完了する
5) MDCA: アラート確認
先ほどエンドユーザー側の動作を確認した際、「a) 秘密度ラベルがついていないとき」のシナリオでアクション (アップロードブロック) が実行されました。
MDCA セッションポリシー上で、条件がマッチしてアクションが実行された場合にはアラートするよう構成していたため、最後にアラートがどう出ているか確認します。
Defender XDR のアラート通知設定
今回検証時は実施していませんでしたが、Microsoft Defender ポータル上でアラートのメール通知を構成することも可能です。
Defender 管理センター
- 参考：
MDCA セッションポリシー上で「Create an alert for each matching event with the policy's severity」を有効に構成していると、以下のインシデント / アラートが Microsoft Defender ポータルに表示されました。
- Incident name: {MDCA セッションポリシーのポリシー名}
- Severity: {MDCA セッションポリシーで設定した severity}
- Categories: Suspicious activity
- Impacted assets: {ユーザー}、Microsoft SharePoint Online
- Service sources: Microsoft Defender for Cloud Apps
- Detection sources: Microsoft Defender for Cloud Apps
インシデントとアラートの詳細ページは、以下に掲載します。
(長くなったので折りたたみました。)
インシデント詳細画面の写真（左端の ▶ をクリックして展開）
-
Attack Story：
-
Alerts：
-
Assets：
-
Evidence and Response
IP details (上写真)
ウチの Internet Service Provider (ISP) が Softbank だということがバレています！
(ほかの情報はウチの賃貸物件とは合致しませんでしたが、大事を取ってマスクしました。もし Softbank の電波塔とかの情報なら勝手に晒せないし...)
-
Summary：
アラート詳細画面の写真（左端の ▶ をクリックして展開）
SPO のどこでインシデントが起きたの...？
検証時、Defender 管理センター上でインシデント詳細画面とアラート詳細画面をひととおり見ました。
すると、「SharePoint Online上で{ユーザー}による{ファイル名}アップロードをブロックした」ということは分かるのですが、SPO のどこ (どのサイト？ どのフォルダ？) でアップロードが施行されたのか、という情報は見つけられませんでした。
ハイパーリンクはすべてクリックしたのですが。
ちなみに、インシデントやアラートの詳細画面上の [Microsoft SharePoint Online] ハイパーリンクをクリックすると、以下のページに飛びます。
(MDCA が持っているクラウドアプリの情報ページ)
メール
本記事内「2. 動作例」セクションにも掲載しましたが、MDCA セッションポリシー上で「Send alert as email」を有効に構成していると、設定した管理者のメールアドレス宛に以下の通知メールが届きます。
- 件名：Defender for Cloud Apps alert: {MDCA セッションポリシーのポリシー名}
- 送り主：Microsoft Cloud App security (no-reply@cloudappsecurity.com)
「M365D portal report」ボタンには、Defender 管理センター上のアラートページに直接飛べるリンクが埋め込まれていました。
-
https://security.microsoft.com/alerts/{alert id}
クリックすると下のページが開きます↓
ということは、メール上の「M365D portal report」ボタンを入り口にしたアラート確認運用をしたい場合は、管理センターにアクセスできるよう、組織内部かつ必要権限を持つユーザーのメールアドレスなどを宛先に設定しておくのが無難ということになりますね。
(セッションポリシー編集画面上は外部のメールアドレスを登録することも可能そうなので一応覚書。)
さいごに
以上で、機密情報の SharePoint Online アップロードをブロックすることができました。
あんなこといいな♪ できたらいいな♪ の気持ちではじめた検証だったので、動いたこと自体に感動がありました。
ただし、利用している機能に仕様があるからには制約もあるため、あまり「万能で素敵な機能！礼賛！」のようなトーンの記事にならないよう気を付けたつもりです。
(反動で制約を強調する記事ができあがってしまった気も...)
また今回あらためて、セキュリティは奥が深いなぁと思いました。
みなさまの深淵覗きエピソードも、よければぜひコメント欄で教えてください！
Microsoft Defender for Cloud Apps の略称
みなさんは「MDCA」派ですか？ それとも「MDA」派ですか？
私はどちらも聞いたことがあり、揺らいでいます。何が正しいのかおしえて～～ (切実)
Copilot によると MDCA が一番多いみたいですが、どうなんでしょうか。
-
Copilot による記事内容のサマリ：記事本文を Markdown 形式で Copilot (商用データ保護あり) に連携して、サマリを生成してもらいました！ ↩
-
*.mcas.msサフィックスの「MCAS」について：Microsoft Defender for Cloud Apps の旧称、Microsoft Cloud App Security を省略して「MCAS」です。個人的には、Microsoft の CASB (Cloud Access Security Broker) 製品であると分かりやすいこの略称が好きでした。こんなところに「MCAS」表記が残っているとは！ ↩ ↩2 ↩3 -
制御対象領域の指定はアプリ単位：ここでいうアプリは、MDCA の「Conditional Access App Control apps」にオンボードされているアプリを指します。例を挙げると、「SharePoint Online」や、「OneDrive for Business」などです。 ↩ ↩2
-
Microsoft Purview Information Protection (MPIP) クライアント：Azure Information Protection 統合ラベル付けクライアントの後継です (参考：Azure Information Protection (AIP) 統合ラベル付けクライアント)。ダウンロードはこちらから → Download Microsoft Purview Information Protection client from Official Microsoft Download Center ↩ ↩2