SharePoint Online への機密情報アップロードをブロックする方法

先日、Microsoft Defender for Cloud Apps (MDCA, MDA) セッションポリシーを使って**機密情報の SharePoint Online アップロードをブロックする検証**をしました。
(以下箇条書きのシナリオ)

- **対象操作**：ファイルアップロード
- **対象領域**：SharePoint Online
- **対象ファイル**：機密情報を含むが、秘密度ラベルが設定されていないファイル
- **制御**：ファイルアップロードのブロック、管理者への通知

調査の第一歩として多少ざっくりしたシナリオで検証をしていますが、無事に基本的動作と制約事項を確認することができました！

備忘を兼ねて、動作と設定を本記事にまとめます。

:::note
**Copilot による記事内容のサマリ[^0]**
- この記事では、Microsoft Defender for Cloud Apps セッションポリシーを使用して、機密情報の SharePoint Online へのアップロードをブロックする方法について解説しています。
- 具体的な設定手順や動作例を通じて、ブラウザ起点のファイル操作を制御する方法を詳しく説明しています。
- また、検証中に見えてきた制約や課題についても触れ、実際の運用に向けた考察を行っています。
:::

[^0]: Copilot による記事内容のサマリ：記事本文を Markdown 形式で Copilot (商用データ保護あり) に連携して、サマリを生成してもらいました！

# 目次
本記事は以下の構成です：

| # | 章題 | 概要 |
|:-:|:-:|:-:|
|1   |**[実装イメージ](https://qiita.com/shokolate/items/d98905aed908104f2813#1-%E5%AE%9F%E8%A3%85%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8)**   | システム側の製品連携と、ユーザーエクスペリエンスを簡易に図示します  |
|2   |**[動作例](https://qiita.com/shokolate/items/d98905aed908104f2813#2-%E5%8B%95%E4%BD%9C%E4%BE%8B)**   | ユーザーに表示される実際のブロック画面と、管理者向けのアラート画面を掲載します  |
|3   |**[制約と課題](https://qiita.com/shokolate/items/d98905aed908104f2813#3-%E5%88%B6%E7%B4%84%E3%81%A8%E8%AA%B2%E9%A1%8C)**   | 製品仕様による制約と、本番実装に向け検討が必要と思われる課題について軽く触れます  |
|4   |**[検証ステップ](https://qiita.com/shokolate/items/d98905aed908104f2813#4-%E6%A4%9C%E8%A8%BC%E3%82%B9%E3%83%86%E3%83%83%E3%83%97)**   | 今回検証した際に実施したことを、構築フェーズとテストフェーズに分けてステップごとにまとめます  |

:::note
少し長めの記事になってしまったので、飛ばし読み推奨です🚀
PC で開いていただけると、Qiita 標準機能の目次が常に表示されますので、ご活用ください！ 
:::

# 1. 実装イメージ
- **参考**：
  - [チュートリアル: organizationで機密情報を検出して保護する - フェーズ 2: 機密情報の分類](https://learn.microsoft.com/ja-jp/defender-cloud-apps/tutorial-dlp#phase-2-classify-sensitive-information)
  - [Microsoft Defender for Cloud Apps セッション ポリシーを作成する - 機密ファイルのアップロードを保護する](https://learn.microsoft.com/ja-jp/defender-cloud-apps/session-policy-aad#protect-uploads-of-sensitive-files)

今回は、試しに SharePoint Online へのアップロードブロックを検証しました。
下図 (↓) は、**検証時の構成**を簡易にまとめてみたものです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/d1fa7f22-b8b2-4b11-8116-3008e7a2d4b0.png)

- ユーザー (上図：Test User) が、Purview で定義された**機密情報を含むコンテンツ** (上図：script.sh) をアップロードしようとする
- セッションポリシーと条件付きアクセスポリシーの連携による**アクセス制御(セッション制御)が適用され、アップロードがブロックされる**

なお、今回は**機密情報の種類を指定**したうえで、さらに**秘密度ラベルのついていないファイルに限定してアップロードをブロック**する制御にしました。
下フローのイメージです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/65f1922b-a0c6-407d-a3bd-28c31ec39bf9.png)



今回は検証のため多少大雑把にシナリオを組んで実装しましたが、ポリシーの構成によって**例えば以下のシナリオに応用することも可能**です。
- ダウンロードのブロック
- OneDrive for Business 領域の保護
- デバイス管理状態に応じた制御の分岐

ただし、後ほど「[3. 制約と課題](https://qiita.com/shokolate/items/d98905aed908104f2813#3-%E5%88%B6%E7%B4%84%E3%81%A8%E8%AA%B2%E9%A1%8C)」セクションにも記載しますが、**MDCA セッションポリシーが制御できるのはブラウザのみ**のため、ある程度シナリオは限定される印象です。
(参考：[Conditional Access app control in Microsoft Defender for Cloud Apps - Scope of support for session control](https://learn.microsoft.com/en-gb/defender-cloud-apps/proxy-intro-aad#scope-of-support-for-session-control)

# 2. 動作例
今回私が実施した検証では、以下の動作を確認することができました。
1. ユーザーが機密情報をアップロードしようとする
1. アクセス制御(セッション制御)が適用され、アップロードがブロックされる
1. アップロードブロックされたことがアラートされる (Defender 管理センター および メール)

なお、公開情報にもあるように、リンクの URL に `*.mcas.ms`[^3] サフィックスが表示されています。

:::note
**`*.mcas.ms`[^3] サフィックス**
セッションポリシーを使うと、リバースプロキシ経由でセッションが MDCA にリダイレクトされるそうです。
その結果、リンクの URL に `*.mcas.ms`[^3] サフィックスが表示されるとのこと。
(「Edge for Businessによるブラウザー内保護 (プレビュー)」を有効にしていない場合は、Edge でもこの URL 書き換えが起こります。)
- **参考**：
  - [Microsoft Defender for Cloud Appsでのアプリの条件付きアクセス制御](https://learn.microsoft.com/ja-jp/defender-cloud-apps/proxy-intro-aad)
  - [Microsoft Edge for Businessによるブラウザー内保護 (プレビュー)](https://learn.microsoft.com/ja-jp/defender-cloud-apps/in-browser-protection)
  - [Troubleshooting - What is *.mcas.ms, *.mcas-gov.us, or *.mcas-gov.ms?](https://learn.microsoft.com/en-us/defender-cloud-apps/troubleshooting-proxy-url)
:::

以下、検証時の画面ショットです。

![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/a21877c9-1fa0-4eea-95b7-ee875038c750.png)

![2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/e33c6c4b-43e7-48bd-aaaf-262cb298add9.png)

![4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/f7242a07-553d-446b-8ac3-45c873ed45a2.png)

![3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/095c53dc-7b8e-4336-b2ec-287469967a16.png)


:::note
写真はすべて検証環境のものです。
UPN などドメイン名が含まれるものは万が一のためマスクしました。
また、自分用に付けているポリシープレフィックスなど、センス皆無がバレそうなものもマスクしています。
:::

[^3]: `*.mcas.ms` サフィックスの「MCAS」について：Microsoft Defender for Cloud Apps の旧称、Microsoft Cloud App Security を省略して「MCAS」です。個人的には、Microsoft の CASB (Cloud Access Security Broker) 製品であると分かりやすいこの略称が好きでした。こんなところに「MCAS」表記が残っているとは！ 

# 3. 制約と課題
- **参考**：
  - [Microsoft Defender for Cloud Appsでのアプリの条件付きアクセス制御](https://learn.microsoft.com/ja-jp/defender-cloud-apps/proxy-intro-aad)
  - [条件付きアクセス アプリ制御の既知の制限事項](https://learn.microsoft.com/ja-jp/defender-cloud-apps/caac-known-issues)
  - [Microsoft Defender for Cloud Apps セッション ポリシーを作成する](https://learn.microsoft.com/ja-jp/defender-cloud-apps/session-policy-aad)
  - [管理者ユーザーのアクセスとセッション制御のトラブルシューティング](https://learn.microsoft.com/ja-jp/defender-cloud-apps/troubleshooting-proxy)
  - [エンド ユーザーのアクセスとセッション制御のトラブルシューティング](https://learn.microsoft.com/ja-jp/defender-cloud-apps/troubleshooting-proxy-end-users)
  - [Troubleshooting - What is *.mcas.ms, *.mcas-gov.us, or *.mcas-gov.ms?](https://learn.microsoft.com/en-us/defender-cloud-apps/troubleshooting-proxy-url)

検証をするなかで、制約と課題についても見えてきました。
壁打ちを兼ねて... **個人的に特に気になった点を以下にまとめます**。

一般的な**既知の制約**についてはすでに**公開情報もあります**ので、ご興味のある方はぜひ上リンクを順にご参考ください！

## 制約
今回検証をしていて、以下の制約が特に目について気になりました。
どれも仕様によるもので、乗り越えることのできない壁です。(製品フィードバックのチャンス？)

| # | 仕様 (制約) | 備考 |
|:-:|:-:|:-:|
|1   | **[サポート範囲がブラウザ限定](https://qiita.com/shokolate/items/d98905aed908104f2813#1-%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E7%AF%84%E5%9B%B2%E3%81%8C%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6%E9%99%90%E5%AE%9A)** | クライアントアプリからアップロードされたコンテンツは条件に合致してもブロックできない  |
|2   | **[制御対象領域の指定はアプリ 単位](https://qiita.com/shokolate/items/d98905aed908104f2813#2-%E5%88%B6%E5%BE%A1%E5%AF%BE%E8%B1%A1%E9%A0%98%E5%9F%9F%E3%81%AE%E6%8C%87%E5%AE%9A%E3%81%AF%E3%82%A2%E3%83%97%E3%83%AA3%E5%8D%98%E4%BD%8D)**[^1]  | SharePoint Online 下の特定領域 / 特定フォルダに限定してアップロードブロックを実装することはできない  |

上記は MDCA セッションポリシーの仕様のため、実装できないのはアップロードに限らず、ダウンロードなどセッションポリシーがサポートするその他の動作についても同様です。

### 1) サポート範囲がブラウザ限定
MDCA セッションポリシーではブラウザのみサポートされており、**クライアントアプリはサポート外**です。
これにより、制御できるのはブラウザ起点のファイルのアップロード/ダウンロード動作に限定されます。


ブラウザから条件に合致するファイル (機密情報を含むファイル) をアップロードしようとするとブロックされますが、**クライアントアプリからはブロックされずにアップロード可能**です。

::: note warn
**クライアントアプリの「サポート外」挙動**
製品/機能によっては、たまにサポート外とはいえ実質制御されるようなものもありますが、MDCAのセッションポリシーに関してはサポート外＝**スルーされる (制御がかからない)** という結果になりました。
:::

条件付きアクセスポリシーで「モバイルアプリとデスクトップクライアント」を含めた (明示的に除外しない) としても、挙動は変わりませんでした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/b23ec878-f5f2-4a1f-913d-e076df63f902.png)

:::note
**クライアントアプリの制御**
Entra ID の条件付きアクセスポリシー または MDCA アクセスポリシーを使い、**クライアントアプリ経由のアクセス自体をブロック**すると**すり抜けを防ぐ**ことができます。

個人的には、条件付きアクセスポリシーを 2個セットで用意するのが分かりやすいのではと思いました。
- ブラウザを対象にアクセス許可、MDCA セッションポリシー (アプリの条件付きアクセス制御) を使う
- クライアントアプリ (モバイルアプリとデスクトップクライアント) を対象に**アクセスブロック**
:::

### 2) 制御対象領域の指定はアプリ単位

SharePoint Online (これがひとつのアプリという扱い[^1]) 全体に対するアップロードブロックは可能です。
ただし、このフォルダ / この領域だけ... といった、**SPO 全体よりも狭い特定の領域を指定することはできません**。

(MDCA のファイルポリシーでは特定の SPO フォルダに限定した構成が可能なので、同じ MDCA のポリシーでもセッションポリシーはできないのか、と新鮮な驚きを感じました。)

[^1]: 制御対象領域の指定はアプリ単位：ここでいうアプリは、MDCA の「Conditional Access App Control apps」にオンボードされているアプリを指します。例を挙げると、「SharePoint Online」や、「OneDrive for Business」などです。

## 課題
以上の制約を踏まえると、一旦検証の範囲ではいい感じに動いているように見えますが、これが**本番環境・実在の組織での運用に使えるのか**は、**慎重に考える必要がある**だろうと思いました。

| # | 課題例 | 備考|
|:-:|:-:|:-:|
|1   | **[ユースケース](https://qiita.com/shokolate/items/d98905aed908104f2813#1-%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9)**  | 想定するユースケースに実装するとして、制御に穴はないか？意図した動作になるのか？  |
|2   | **[チューニング](https://qiita.com/shokolate/items/d98905aed908104f2813#2-%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0)**  | 誤検知 / 過検知はないか？　実運用に耐えられるのか？  |

### 1) ユースケース
どういったシナリオで使いたいのか、検討にあたって**ユースケースは明確であった方がいい**ですね。
MDCA セッションポリシーがブラウザ制御のみを対象にしている時点で、**クライアントアプリを使うケースには無力**です。
←とはいえ抑止力になるからいいと考えるのか、ユーザーエクスペリエンスの揺れは忌避されるか、組織によっても考え方が違うのではないでしょうか。

個人的には、**ブラウザに限定して BYOD 利用を許可しているような組織に適応が高い機能なのでは**と思いました。
このようなケースだと、ブラウザに限定してアップロード/ダウンロードを制御することも理にかなっています。
(ポリシーの構成次第で、組織所有デバイスは除外して BYOD のみを適用対象にすることが可能です。) 

:::note
**ユースケース例 (公開情報より)**
公開情報にも、組織によって管理されていないデバイス (アンマネージド デバイス) に対する制御がユースケース例として掲載されていました。

>セッション ポリシーを使用して、次の手順を実行します。
>- OneDrive からアンマネージド デバイスへの機密ファイルのダウンロードをブロックします。
>- SharePoint Online へのマルウェア ファイルのアップロードをブロックします。
> ―― *[Microsoft Defender for Cloud Appsでのアプリの条件付きアクセス制御](https://learn.microsoft.com/ja-jp/defender-cloud-apps/proxy-intro-aad) より (2025年3月3日閲覧)*
- **参考**：
  - [Microsoft Defender for Cloud Appsでのアプリの条件付きアクセス制御](https://learn.microsoft.com/ja-jp/defender-cloud-apps/proxy-intro-aad)
  - [Identity-managed devices with Conditional Access app control](https://learn.microsoft.com/en-us/defender-cloud-apps/conditional-access-app-control-identity)
:::

### 2) チューニング
また、**誤検知 / 過検知**の観点でのチューニングが必要になるかもしれません。
- 機密情報検知が運用に耐えうるか？
- ブロック制御が業務を疎外しないか？

**範囲 (ユーザー) を限定してパイロット実装する評価フェーズを設ける**のが一番確実な選択肢かと思いました。(可能であれば...)

今回は実業務データの無い検証環境で動作検証したため、検知動作観点で実運用に耐えうるのかは残念ながら評価できませんでした。


:::note
以上、壁打ちできる範囲でのまとめになってしまいましたが、みなさまはどう思いますか？
よければぜひコメント欄で教えてください。
:::

# 4. 検証ステップ

構築とテストは、それぞれ以下図のステップで実施しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/9f951dab-b348-4f06-8913-d9b6ab1ba7d2.png)

:::note warn
**Microsoft Purview 側設定について**
今回実装する制御が「秘密度ラベルがついていないが機密情報を含むファイルのSPOアップロードをブロックする」のため、すでに実装環境で**以下が済んでいる状態を前提**としています。

- **機密情報の定義**
- **秘密度ラベルの作成、発行、運用**

Purview 側の設定については**本記事では深入りしていません**。

なお簡易な動作確認目的であれば、特に何もせずとも**プリセットの機密情報定義を利用**したり、**デフォルトの秘密度ラベルとラベルポリシーを利用**したりし、本記事と**同じ内容の検証をこなすことが可能**です。
(ラベル有無や機密情報云々の条件分岐フィルター自体を使わないことも可能です。)

- **参考**：
  - [Learn about trainable classifiers](https://learn.microsoft.com/en-us/purview/trainable-classifiers-learn-about) 
  ("Pretrained classifiers" というすぐに使える分類子があります)
  - [Default sensitivity labels and policies to protect your data](https://learn.microsoft.com/en-us/purview/mip-easy-trials)
:::

:::note warn
**クライアントアプリの制御について**
MDCA セッションポリシーのサポート外となるクライアントアプリについては、制御のすり抜けを防ぐために以下いずれかを追加構成して手当てすることがおすすめです。
- Entra ID の条件付きアクセスポリシー
- MDCA アクセスポリシー

なお、これらの設定については**本記事では深入りしていません**。

個人的には、いかのよ条件付きアクセスポリシーを 2個セットで用意するのが分かりやすいのではと思いました。
- ブラウザを対象にアクセス許可、MDCA セッションポリシー (アプリの条件付きアクセス制御) を使う
- クライアントアプリ (モバイルアプリとデスクトップクライアント) を対象に**アクセスブロック**
:::

以降、各段階で実施したこと (特にパラメータ) を軽くまとめます。

## 構築フェーズ
- **参考**：[Use Defender for Cloud Apps Conditional Access app control](https://learn.microsoft.com/en-us/defender-cloud-apps/conditional-access-app-control-how-to-overview)

| # | 操作対象 | 実施概要 |備考|
|:-:|:-:|:-:|:-:|
|1   |**Entra ID**   |**[条件付きアクセスポリシー作成](https://qiita.com/shokolate/items/d98905aed908104f2813#1-entra-id-%E6%9D%A1%E4%BB%B6%E4%BB%98%E3%81%8D%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E4%BD%9C%E6%88%90)** |アプリオンボードの入り口になる条件付きアクセスポリシーを作成します   |
|2   |**Defender for Cloud Apps (MDCA)**   |**[App onboarding/maintenance ユーザー設定](https://qiita.com/shokolate/items/d98905aed908104f2813#2-mdca-app-onboardingmaintenance-%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E8%A8%AD%E5%AE%9A)** | SharePoint Online (SPO) と MDCA を接続するため、アプリオンボードに使用するユーザーを設定します  |
|3   |**SharePoint Online (SPO)**   |**[サービスアクセス (アプリオンボード)](https://qiita.com/shokolate/items/d98905aed908104f2813#3-spo-%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9-%E3%82%A2%E3%83%97%E3%83%AA%E3%82%AA%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%89)**|前項で設定したユーザーで SPO にサインインします (すると、SPO の MDCA オンボード (接続) が完了します)   |
|4   |**MDCA**   | **[Conditional Access App Control apps 確認](https://qiita.com/shokolate/items/d98905aed908104f2813#4-mdca-conditional-access-app-control-apps-%E7%A2%BA%E8%AA%8D)** | Defender 管理センター上で、SPO 接続が正常であることを確認します  |
|5   |**MDCA**  | **[セッションポリシー作成](https://qiita.com/shokolate/items/d98905aed908104f2813#5-mdca-%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E4%BD%9C%E6%88%90)** | セッションポリシーを作成します  |



### 1) Entra ID: 条件付きアクセスポリシー作成
- **参考**：
  - **[TechCommunity QA]** [How to get Sharepoint online into Conditional Access app Control](https://techcommunity.microsoft.com/discussions/microsoftdefendercloudapps/how-to-get-sharepoint-online-into-conditional-access-app-control/2529738)
  - **[YouTube]** [How to setup Defender for Cloud Apps Session Control](https://www.youtube.com/watch?v=L-EKqbse2cs&t=257s)

まずはじめに、入り口となる**条件付きアクセスポリシーを作成**します。

ここら辺は検証時初見でかなりまごつき、上リンクの TechCommunity QA と YouTube を全面的に参考にしました。

以下が当検証環境で利用したパラメータ例です。

<details><summary> 条件付きアクセスポリシー（長いので折りたたみました。左端の ▶ をクリックして展開）</summary>

| # | 大項目 | 中項目 |小項目|既定値|設定値 (例)|備考|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|1   | 名前  | -  | -  | (空白)  | {prefix} Require MDCA Session Policy Control | 直観的にわかりやすい名前 (主観) を設定。  |
|2   | 割り当て  | ユーザー  | 対象  | なし  | {検証ユーザーを選択}  | 検証に使うユーザーアカウント (App onboarding/mmaintenance ユーザー含む) を選択。|
|3   | 割り当て  | ターゲットリソース  | 対象  | なし  | すべてのリソース  | 検証目的のため広めに設定。  |
|4   | 割り当て  | ネットワーク  | -  | 未構成  | 未構成  | -   |
|5   | 割り当て  | 条件  |  -  | 未構成  | 未構成  |  -  |
|6   | アクセス制御  | 許可  | -  | ●アクセス権の付与、●選択したコントロールすべてが必要  | ●アクセス権の付与、●選択したコントロールすべてが必要  | チェックボックスはすべて空白のまま残す。 (特に構成しない)  |
| 7  | アクセス制御  | **セッション**  | -  | (選択なし)  | **■アプリの条件付きアクセス制御を使う、監視のみ (プレビュー)**  | 「アプリの条件付きアクセス制御を使う」を選択。  |
| 8  | ポリシーの有効化  | -  | -  | レポート専用  | オン  | ポリシーを有効にする。  |

</details>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/46d1d121-1e78-4404-9771-d49ce396c787.png)

:::note alert
今回は基本的動作の確認を優先したため「ターゲットリソース」は「すべて」、「条件」は「未構成」でポリシーを作成しました。
本番設計の参考にならずすみません...
本番実装に向けて設計検討される場合は、意図せぬすり抜けが起こらないようにご注意ください。
:::
:::note warn
**[再掲]クライアントアプリの制御について**
MDCA セッションポリシーのサポート外となるクライアントアプリについては、制御のすり抜けを防ぐために以下いずれかを追加構成して手当てすることがおすすめです。
- Entra ID の条件付きアクセスポリシー
- MDCA アクセスポリシー

なお、これらの設定については**本記事では深入りしていません**。

個人的には、条件付きアクセスポリシーを 2個セットで用意するのが分かりやすいのではと思いました。
- ブラウザを対象にアクセス許可、MDCA セッションポリシー (アプリの条件付きアクセス制御) を使う
- クライアントアプリ (モバイルアプリとデスクトップクライアント) を対象に**アクセスブロック**
:::


### 2) MDCA: App onboarding/maintenance ユーザー設定
- **参考**：
  - [How to get Sharepoint online into Conditional Access app Control](https://techcommunity.microsoft.com/discussions/microsoftdefendercloudapps/how-to-get-sharepoint-online-into-conditional-access-app-control/2529738)
  - [How to setup Defender for Cloud Apps Session Control](https://www.youtube.com/watch?v=L-EKqbse2cs&t=257s)
  - [Manual Onboarding of Apps using Microsoft Entra ID - Add admins to the app onboarding/maintenance list](https://learn.microsoft.com/en-us/defender-cloud-apps/apps-manual-onboarding-with-microsoft-entra-id#add-admins-to-the-app-onboardingmaintenance-list)

:::note warn
本工程と[次の工程](https://qiita.com/shokolate/items/d98905aed908104f2813#3-spo-%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9-%E3%82%A2%E3%83%97%E3%83%AA%E3%82%AA%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%89)は、「Conditional Access App Control apps」配下に**何もアプリが登録されていない場合に実施**します。
(「Conditional Access App Control apps」配下に何もアプリが登録されていないと、セッションポリシーを作成できません。)

- **確認事項**：「Conditional Access App Control apps」配下にアプリが登録されているか？
- **確認方法**：本記事「[4) MDCA: Conditional Access App Control apps 確認](https://qiita.com/shokolate/items/d98905aed908104f2813#4-mdca-conditional-access-app-control-apps-%E7%A2%BA%E8%AA%8D)」ご参照
:::

アプリをオンボードするための**作業用アカウントを設定**します。

![構築-2-MDCA.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/ae4e87be-be6a-4488-a5a5-757ee8088424.png)


:::note 
**ここで使ったユーザー アカウントについて**
「App onboarding/maintenance」の included users アカウントには、先ほど作成した条件付きアクセスポリシーの適用対象のアカウントを利用しました。
:::


### 3) SPO: サービスアクセス (アプリオンボード)
- **参考**：
  - [How to get Sharepoint online into Conditional Access app Control](https://techcommunity.microsoft.com/discussions/microsoftdefendercloudapps/how-to-get-sharepoint-online-into-conditional-access-app-control/2529738)
  - [How to setup Defender for Cloud Apps Session Control](https://www.youtube.com/watch?v=L-EKqbse2cs&t=257s)
:::note warn
[前工程](https://qiita.com/shokolate/items/d98905aed908104f2813#2-mdca-app-onboardingmaintenance-%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E8%A8%AD%E5%AE%9A)と本工程は、「Conditional Access App Control apps」配下に**何もアプリが登録されていない場合に実施**します。
(「Conditional Access App Control apps」配下に何もアプリが登録されていないと、セッションポリシーを作成できません。)

- **確認事項**：「Conditional Access App Control apps」配下にアプリが登録されているか？
- **確認方法**：本記事「[4) MDCA: Conditional Access App Control apps 確認](https://qiita.com/shokolate/items/d98905aed908104f2813#4-mdca-conditional-access-app-control-apps-%E7%A2%BA%E8%AA%8D)」ご参照
:::

前工程で「App onboarding/maintenance」の included users として設定したアカウントで、**MDCA にオンボードしたいアプリサービスにサインイン**していきます。
(今回は SharePoint Online と、ついでにそのほかいくつかのアプリにサインインしました。)

すると、「**{アプリ/サービス名} へのアクセスは監視されています**」という画面が表示されるので、「**{アプリ/サービス名} を続行する**」を押下します。
(この後、通常のサインイン後の画面が表示されます。)

![スクリーンショット 2025-02-03 170256 - コピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/4826c342-859b-48b3-8cb5-b479b45d0b0a.png)


### 4) MDCA: Conditional Access App Control apps 確認
- **参考**：
  - [How to get Sharepoint online into Conditional Access app Control](https://techcommunity.microsoft.com/discussions/microsoftdefendercloudapps/how-to-get-sharepoint-online-into-conditional-access-app-control/2529738)
  - [How to setup Defender for Cloud Apps Session Control](https://www.youtube.com/watch?v=L-EKqbse2cs&t=257s)

Defender 管理センター (`security.microsoft.com`) で**オンボードされたアプリを確認**します。

[Settings] > [Cloud Apps] > [Conditional Access App Control apps] を開いたときに、以下写真の例のように何もリスト表示されないと、何もオンボードされていない状態です。
![構築-4-MDCA1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/51bfec35-af23-4f74-a07e-a0d2c6abbecc.png)

今回検証時は、3) の工程まで実施すると以下写真のように**アプリがオンボードされた状態**になりました。
![構築-4-MDCA2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/b2b75851-2940-4cfd-bcba-efeeb050bfb5.png)
上写真のように「Available controls」欄に「Session control」と表示されていると、セッションポリシーの編集画面でアプリを指定できるそうです。
(参考：[How to setup Defender for Cloud Apps Session Control](https://www.youtube.com/watch?v=L-EKqbse2cs&t=257s))

:::note warn
**アプリをオンボードせずにセッションポリシーを作成しようとすると...**
何もアプリがオンボードされていない状態 (テナント初期状態) だと、以下警告が出てセッションポリシーを作成・保存することができません。
![構築-4-MDCA0.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/072481cc-ecd7-425c-9646-a95cdb133b99.png)

:::

:::note warn
**アプリコネクタでアプリ接続済みの場合も...**
「Conditional Access App Control apps」画面上にアプリが無い場合は、オンボードが必要です。

当環境でも、別途ファイルポリシーで使うために Microsoft 365 や Microsoft Azure を「App Connectors (アプリコネクタ)」画面で接続済み (下写真) でしたが、ここの設定はセッションポリシーに関係ありませんでした。
![構築-4-MDCA3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/a4f03916-3c5a-40f1-b797-40a661cab0d5.png)
:::

### 5) MDCA: セッションポリシー作成
- **参考**：[Create Microsoft Defender for Cloud Apps session policies](https://learn.microsoft.com/en-us/defender-cloud-apps/session-policy-aad)

満を持して**セッションポリシーを作成**します。
以下が当検証環境で利用したパラメータ例です。
<details><summary> セッションポリシー（長いので折りたたみました。左端の ▶ をクリックして展開）</summary>

| # | 項目 |既定値  | 設定値 (例)| 備考  |
|:-:|:-:|:-:|:-:|:-:|
|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 管理センターにアラート発砲 + 指定の管理者メールアドレスにアラートする。(メールアラートを追加)  |

</details>

![スクリーンショット 2025-02-25 161618.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/0147f928-7df2-466e-9f0a-bbfabd370e8d.png)

なお、本記事「[1. 実装イメージ](https://qiita.com/shokolate/items/d98905aed908104f2813#1-%E5%AE%9F%E8%A3%85%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8)」セクションに掲載した制御のフローをここであらためてみると、**セッションポリシーの構成次第で分岐条件の設定が可能**ということが分かりやすいかと思います！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/6e351e6b-94ef-4ba9-9641-369385d2a100.png)

以上で、必要な設定がひととおり揃いました。

## テストフェーズ
- **参考**：[Microsoft Defender for Cloud Appsでのアプリの条件付きアクセス制御](https://learn.microsoft.com/ja-jp/defender-cloud-apps/proxy-intro-aad)

| # | 操作対象 | 実施概要 |備考|
|:-:|:-:|:-:|:-:|
|1   |**Entra ID**   | **[条件付きアクセスポリシー編集](https://qiita.com/shokolate/items/d98905aed908104f2813#1-entra-id-%E6%9D%A1%E4%BB%B6%E4%BB%98%E3%81%8D%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E7%B7%A8%E9%9B%86)** |セッションポリシーの入り口になるよう、条件付きアクセスポリシーを既定値に更新します |
|2   |**GitHub**   | **[テストファイル用意](https://qiita.com/shokolate/items/d98905aed908104f2813#2-github-%E3%83%86%E3%82%B9%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E7%94%A8%E6%84%8F)**  | 機密情報 (Source code) を含む適当なファイルを用意します|
|3   |**Purview**   | **[テストファイル検証](https://qiita.com/shokolate/items/d98905aed908104f2813#3-purview-%E3%83%86%E3%82%B9%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E6%A4%9C%E8%A8%BC)**  | 用意したテストファイルが、Purview でプリセットされた「Source code」機密情報定義に合致するか (機密情報を含むファイルとみなされるか) 検証します|
|4   |**SharePoint Online (SPO)**  | **[アップロード検証](https://qiita.com/shokolate/items/d98905aed908104f2813#4-spo-%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%83%BC%E3%83%89%E6%A4%9C%E8%A8%BC)**  | 機密情報を含むテストファイルを SPO にアップロードし、意図した制御が適用されるか確認します (秘密度ラベルがついていないとき / ついているとき を比較確認します)|
|5   |**Defender for Cloud Apps (MDCA)**   | **[アラート確認](https://qiita.com/shokolate/items/d98905aed908104f2813#5-mdca-%E3%82%A2%E3%83%A9%E3%83%BC%E3%83%88%E7%A2%BA%E8%AA%8D)**  | 制御が適用された場合のアラート動作を確認します|



### 1) Entra ID: 条件付きアクセスポリシー編集
- **参考**：[Create Microsoft Defender for Cloud Apps session policies](https://learn.microsoft.com/en-us/defender-cloud-apps/session-policy-aad)

構築フェーズ冒頭にてアプリオンボード用に作成した条件付きアクセスポリシーを編集して、セッション制御下のドロップダウンメニュー選択を既定値に戻しておきます。

:::note warn
公開情報上にはここのドロップダウンメニューで何を選択すべきか特に指定されていなかったので、安全第一の精神で既定値にして検証しました🥺
:::

- **BEFORE**：監視のみ (プレビュー)
- **AFTER**：カスタム ポリシーを使用する

<details><summary> 条件付きアクセスポリシー（長いので折りたたみました。左端の ▶ をクリックして展開）</summary>

| # | 大項目 | 中項目 |小項目|既定値|設定値 (例)|備考|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|1   | 名前  | -  | -  | (空白)  | {prefix} Require MDCA Session Policy Control | 直観的にわかりやすい名前 (主観) を設定。  |
|2   | 割り当て  | ユーザー  | 対象  | なし  | {検証ユーザーを選択}  | 検証に使うユーザーアカウント (App onboarding/mmaintenance ユーザー含む) を選択。|
|3   | 割り当て  | ターゲットリソース  | 対象  | なし  | すべてのリソース  |  -  |
|4   | 割り当て  | ネットワーク  | -  | 未構成  | 未構成  | -   |
|5   | 割り当て  | 条件  |  -  | 未構成  | 未構成  |  -  |
|6   | アクセス制御  | 許可  | -  | ●アクセス権の付与、●選択したコントロールすべてが必要  | ●アクセス権の付与、●選択したコントロールすべてが必要  | チェックボックスはすべて空白のまま残す。 (特に構成しない)  |
| 7  | アクセス制御  | **セッション**  | -  | (選択なし)  | **■アプリの条件付きアクセス制御を使う、カスタム ポリシーを使用する**  | 「アプリの条件付きアクセス制御を使う」を選択。  |
| 8  | ポリシーの有効化  | -  | -  | レポート専用  | オン  | ポリシーを有効にする。  |

</details>

![テスト-1-CApolicy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/cb1428e5-c51e-4aa3-b860-14a312f96f85.png)


:::note alert
今回は基本的動作の確認を優先したため「ターゲットリソース」は「すべて」、「条件」は「未構成」でポリシーを作成しました。
本番設計の参考にならずすみません...
本番実装に向けて設計検討される場合は、意図せぬすり抜けが起こらないようにご注意ください。
:::
:::note warn
**[再掲]クライアントアプリの制御について**
MDCA セッションポリシーのサポート外となるクライアントアプリについては、制御のすり抜けを防ぐために以下いずれかを追加構成して手当てすることがおすすめです。
- Entra ID の条件付きアクセスポリシー
- MDCA アクセスポリシー

なお、これらの設定については**本記事では深入りしていません**。

個人的には、条件付きアクセスポリシーを 2個セットで用意するのが分かりやすいのではと思いました。
- ブラウザを対象にアクセス許可、MDCA セッションポリシー (アプリの条件付きアクセス制御) を使う
- クライアントアプリ (モバイルアプリとデスクトップクライアント) を対象に**アクセスブロック**
:::



### 2) GitHub: テストファイル用意
- **参考**：[Trainable classifiers definitions - Source code](https://learn.microsoft.com/en-us/purview/trainable-classifiers-definitions#source-code)

今回 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](https://learn.microsoft.com/en-us/purview/trainable-classifiers-definitions#source-code) より (2025年2月3日閲覧)*

今回は **Shell スクリプト**を使うことにしました。
GitHub 上に神々が公開されているスクリプトから Shell スクリプトを見繕ってダウンロードしています。
(こちらのスクリプトをお借りしました：[getProcessorType.sh](https://github.com/microsoft/shell-intune-samples/blob/master/macOS/Custom%20Attributes/CPU%20Architecture/getProcessorType.sh))

https://github.com/microsoft/shell-intune-samples/blob/master/macOS/Custom%20Attributes/CPU%20Architecture/getProcessorType.sh

![テスト-2-GitHub.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/41c4aeea-4773-44e2-a00d-87c129f40f76.png)


### 3) Purview: テストファイル検証
念のため、用意したファイルが狙い通り **「Source code」と認識されるのか、事前に Purview ポータル上でテスト**します。

Trainable classifiers テスト方法について、以下に少し詳しめに記載します。
(長くなったので折りたたみました。)

<details><summary>Trainable classifiers テスト方法（左端の ▶ をクリックして展開）</summary>

- 「Trainable classifiers」画面上のリストにて、「Source code」を探す：
  - Purview ポータル (`purview.microsoft.com`) > [Data Loss Prevention] > [Classifiers] > [Trainable classifiers] を開く
  - 「Source code」を探す (フィルターを使うと簡単です！)
![テスト-3-Purview0.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/7f5728b8-8e87-4027-9618-7a3213d3ac5b.png)

- 「Source code」を開く (「Open in new windows」ボタンをクリック)
![テスト-3-Purview1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/c87eb59c-963a-45eb-bbfa-d6a3053e7abf.png)

- 「Source code」ページにて、「Test」をクリック
![テスト-3-Purview2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/982f9e9b-97fb-413a-80ff-6e4f15001dfa.png)

- 「Upload file to test "Source code"」にて「Upload file」をクリック
  - エクスプローラーが開くので、テストしたいファイルを選択して開く
![テスト-3-Purview3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/3aec5da8-d6f8-4260-8d16-7b3e1fe7ced8.png)

- 「Uploaded file: {ファイル名}」が表示されているのを確認して、「Test」ボタンをクリック
![テスト-3-Purview4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/01fd59ee-5344-42c6-9540-b0dee75b8e89.png)

- 「Result」欄より結果を確認する
  - 「{ファイル名} contains "Source code".」と表示されていればOK！
![テスト-3-Purview5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/90ac09dd-25b0-48c9-85b7-326171fcf848.png)
</details>

これで、動作検証にぴったりなファイルを用意できていることが確認できました。

### 4) SPO: アップロード検証
アクションが実行される場合と実行されない場合をそれぞれ確認するため、以下のシナリオで動作を確認しました。

- **[a) 秘密度ラベルがついていないとき](https://qiita.com/shokolate/items/d98905aed908104f2813#a-%E7%A7%98%E5%AF%86%E5%BA%A6%E3%83%A9%E3%83%99%E3%83%AB%E3%81%8C%E3%81%A4%E3%81%84%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%81%A8%E3%81%8D)**
前工程で用意したテストファイルをそのまま使い、SPO へのアップロードを試行します。
- **[b) 秘密度ラベルがついているとき](https://qiita.com/shokolate/items/d98905aed908104f2813#b-%E7%A7%98%E5%AF%86%E5%BA%A6%E3%83%A9%E3%83%99%E3%83%AB%E3%81%8C%E3%81%A4%E3%81%84%E3%81%A6%E3%81%84%E3%82%8B%E3%81%A8%E3%81%8D)**
前工程で用意したテストファイルに秘密度ラベルを付けてから、SPO へのアップロードを試行します。

:::note 
**ここで使ったユーザー アカウントについて**
動作検証 (テスト) には、条件付きアクセスポリシーの適用対象のアカウントを利用しました。
:::

#### a) 秘密度ラベルがついていないとき
条件付きアクセスポリシー適用対象のユーザーが、**秘密度ラベルのついていない機密情報を含むテストファイルを SPO にアップロード**しようとするケースです。

以下の動作を確認することができました：
- ユーザーが**ブラウザから SPO にアクセス**し、ファイルをアップロードしようとする
- アクセス制御(セッション制御)が適用され、**アップロードがブロックされる**
- アップロードブロックされたことがアラートされる (Defender 管理センター および メール)

写真は本記事「[2. 動作例](https://qiita.com/shokolate/items/d98905aed908104f2813#2-%E5%8B%95%E4%BD%9C%E4%BE%8B)」セクションに掲載したものと同じため割愛し、ブロック画面だけ再掲します。

> **アップロードがブロックされました**
> {ファイル名} のアップロードは、組織のセキュリティポリシーによってブロックされています。
> Microsoft Defender for Coud Apps

![スクリーンショット 2025-02-03 171554 - コピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/5c07b739-4db6-44fd-9ae5-3004beee7ca6.png)


:::note warn
**クライアントアプリを使う場合**
くどいようですが、MDCA セッションポリシーの仕様として、**制御できるのはブラウザ起点**の操作に限定されます。

今回の「a) 秘密度ラベルがついていないとき」と同じテストファイルを使うパターンで、ただし **Teams クライアントアプリから SPO にアクセスする場合**も検証したところ、**ブロックされることなくアップロードできてしまう**結果になりました。
- **参考**：[Conditional Access app control in Microsoft Defender for Cloud Apps - Scope of support for session control](https://learn.microsoft.com/en-gb/defender-cloud-apps/proxy-intro-aad#scope-of-support-for-session-control)
:::

#### b) 秘密度ラベルがついているとき
条件付きアクセスポリシー適用対象のユーザーが、**秘密度ラベルのついている機密情報を含むテストファイルを SPO にアップロード**しようとするケースです。

先ほどと同じファイルを使って、ただし今度は秘密度ラベル付与のステップを最初に挟みます。

:::note
**ユーザー操作による秘密度ラベル付与**
基本的にユーザー操作による秘密度ラベル付与は、以下のいずれかの方法で実施可能です。
- Microsoft 365 Apps に組み込みの秘密度ラベルクライアントを使う
- Microsoft Purview Information Protection (MPIP) クライアント[^2]を使う

今回の検証では、ラベルを付与したい対象のファイルが Office ファイルではなく Shell スクリプトファイルのため、MPIP クライアント[^2]を使いました。

- **参考**：
  - [Office アプリで秘密度ラベルを管理する](https://learn.microsoft.com/ja-jp/purview/sensitivity-labels-office-apps)
  - [Windows で秘密度ラベル付けを拡張する](https://learn.microsoft.com/ja-jp/purview/information-protection-client?tabs=devices%2Cinstall-client-exe%2Cclassification-file-types%2Cexcluded-folders)
:::

以下の動作を確認することができました：
- ユーザーがファイルに秘密度ラベルを付ける
(ラベルを付けた後、ファイルの拡張子が「.pfile」になりました)
![テスト-4-SPO1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/138bbc51-e317-42a8-afbe-f27e8a2f9743.png)
![テスト-4-SPO2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/761a4133-b9a6-4ef5-b6ab-c245e686ac59.png)
![テスト-4-SPO3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/82cc95d4-dee4-44d4-a3b2-9438ed86abea.png)

- ユーザーが**ブラウザから SPO にアクセス**し、ファイルをアップロードしようとする
![テスト-4-SPO4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/3ec2c966-705b-43fd-a0ae-31cbaa977ef0.png)

- ブロックされずに**アップロードが完了**する
![テスト-4-SPO5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/f55964b3-82e8-4666-acab-c106192cf09e.png)


[^2]: Microsoft Purview Information Protection (MPIP) クライアント：Azure Information Protection 統合ラベル付けクライアントの後継です (参考：[Azure Information Protection (AIP) 統合ラベル付けクライアント](https://learn.microsoft.com/ja-jp/azure/information-protection/about-aip-client))。ダウンロードはこちらから → [Download Microsoft Purview Information Protection client from Official Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=53018&lc=1033&msockid=17b64d732b12641e2e0158ec2af865c2)

### 5) MDCA: アラート確認
先ほどエンドユーザー側の動作を確認した際、「[a) 秘密度ラベルがついていないとき](https://qiita.com/shokolate/items/d98905aed908104f2813#a-%E7%A7%98%E5%AF%86%E5%BA%A6%E3%83%A9%E3%83%99%E3%83%AB%E3%81%8C%E3%81%A4%E3%81%84%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%81%A8%E3%81%8D)」のシナリオでアクション (アップロードブロック) が実行されました。

MDCA セッションポリシー上で、条件がマッチしてアクションが実行された場合にはアラートするよう構成していたため、最後に**アラートがどう出ているか確認**します。

- **[Defender 管理センター](https://qiita.com/shokolate/items/d98905aed908104f2813#defender-%E7%AE%A1%E7%90%86%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC)**
- **[メール](https://qiita.com/shokolate/items/d98905aed908104f2813#%E3%83%A1%E3%83%BC%E3%83%AB)**

:::note
**Defender XDR のアラート通知設定**
今回検証時は実施していませんでしたが、Microsoft Defender ポータル上でアラートのメール通知を構成することも可能です。
- **参考**：[Get incident notifications by email](https://learn.microsoft.com/en-us/defender-xdr/m365d-notifications-incidents)
:::

#### Defender 管理センター
- **参考**：
  - [Investigate incidents in the Microsoft Defender portal](https://learn.microsoft.com/en-us/defender-xdr/investigate-incidents)
  - [Investigate alerts in Microsoft Defender XDR](https://learn.microsoft.com/en-us/defender-xdr/investigate-alerts?tabs=settings)

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

![テスト-5-incident1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/be864881-81a8-4940-b362-9cc34db7fbd0.png)

インシデントとアラートの詳細ページは、以下に掲載します。
(長くなったので折りたたみました。)

<details><summary>インシデント詳細画面の写真（左端の ▶ をクリックして展開）</summary>

- **Attack Story**：
![テスト-5-incident2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/0b126867-9bd6-4476-b489-2aa65fd75339.png)

- **Alerts**：
![テスト-5-incident3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/a4b8f144-3c39-4929-802f-320ccc6fa630.png)

- **Assets**：
![テスト-5-incident4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/7c30019f-59e0-464a-93c9-9594c9916df3.png)
![テスト-5-incident5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/334c8de1-ede0-4f85-a089-680b2c9ddf38.png)

- **Evidence and Response**
![テスト-5-incident6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/2e154094-2614-4505-bdf2-416d6ca6c829.png)
![テスト-5-incident7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/5b4b57ee-183b-4fa6-8661-2ae8fa27985b.png)

:::note
**IP details** (上写真)
ウチの Internet Service Provider (ISP) が Softbank だということがバレています！

(ほかの情報はウチの賃貸物件とは合致しませんでしたが、大事を取ってマスクしました。もし Softbank の電波塔とかの情報なら勝手に晒せないし...)
:::

- **Summary**：
![テスト-5-incident8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/8d3982d7-4caa-4253-86f0-8ca74309edd3.png)

</details>


<details><summary>アラート詳細画面の写真（左端の ▶ をクリックして展開）</summary>

![テスト-5-アラート11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/1f61a175-f0bf-4035-813c-2f54cba53582.png)
![テスト-5-アラート12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/405d09b4-c916-41c9-a087-4494c2f6cc60.png)

</details>

:::note warn
**SPO のどこでインシデントが起きたの...？**
検証時、Defender 管理センター上でインシデント詳細画面とアラート詳細画面をひととおり見ました。
すると、「SharePoint Online上で{ユーザー}による{ファイル名}アップロードをブロックした」ということは分かるのですが、**SPO のどこ** (どのサイト？ どのフォルダ？) でアップロードが施行されたのか、という情報は見つけられませんでした。
ハイパーリンクはすべてクリックしたのですが。

ちなみに、インシデントやアラートの詳細画面上の [Microsoft SharePoint Online] ハイパーリンクをクリックすると、以下のページに飛びます。
(MDCA が持っているクラウドアプリの情報ページ)
![テスト-5-アラート15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/cdb380cc-7c25-4b2a-8ca9-01324cf27023.png)

:::


#### メール
本記事内「[2. 動作例](https://qiita.com/shokolate/items/d98905aed908104f2813#2-%E5%8B%95%E4%BD%9C%E4%BE%8B)」セクションにも掲載しましたが、MDCA セッションポリシー上で「Send alert as email」を有効に構成していると、設定した管理者のメールアドレス宛に以下の通知メールが届きます。

- **件名**：Defender for Cloud Apps alert: {MDCA セッションポリシーのポリシー名}
- **送り主**：Microsoft Cloud App security (no-reply@cloudappsecurity.com)

![スクリーンショット 2025-02-26 145503.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/1ffc92fe-ec54-4cba-a996-af2774d1d4b9.png)

「M365D portal report」ボタンには、Defender 管理センター上のアラートページに直接飛べるリンクが埋め込まれていました。
- `https://security.microsoft.com/alerts/{alert id}`
クリックすると下のページが開きます↓
![テスト-5-アラート11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/aa13bfbc-5b5a-4a19-8d0a-c80976b102a7.png)

ということは、メール上の「M365D portal report」ボタンを入り口にしたアラート確認運用をしたい場合は、管理センターにアクセスできるよう、**組織内部かつ必要権限を持つユーザーのメールアドレスなどを宛先に設定しておくのが無難**ということになりますね。
(セッションポリシー編集画面上は外部のメールアドレスを登録することも可能そうなので一応覚書。)

# さいごに
以上で、**機密情報の SharePoint Online アップロードをブロックする**ことができました。

あんなこといいな♪ できたらいいな♪ の気持ちではじめた検証だったので、動いたこと自体に感動がありました。

ただし、利用している機能に**仕様があるからには制約もある**ため、あまり「万能で素敵な機能！礼賛！」のようなトーンの記事にならないよう気を付けたつもりです。
(反動で制約を強調する記事ができあがってしまった気も...)

また今回あらためて、セキュリティは奥が深いなぁと思いました。
みなさまの深淵覗きエピソードも、よければぜひコメント欄で教えてください！

:::note
**Microsoft Defender for Cloud Apps の略称**
みなさんは「MDCA」派ですか？　それとも「MDA」派ですか？
私はどちらも聞いたことがあり、揺らいでいます。何が正しいのかおしえて～～ (切実)

Copilot によると MDCA が一番多いみたいですが、どうなんでしょうか。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/c540f059-d45b-4418-a3cd-438f538078f8.png)
:::