Conditional Access app controlは、Microsoft Defender for Cloud Appsでクラウドアプリのアクセスとセッション操作をリアルタイムに制御する機能です。特に今回確認すべき結論は、セッション制御は主にブラウザベースの対話型セッションに適用され、Microsoft TeamsデスクトップアプリにはBlock downloadなどのセッション制御が適用されないという点です。2026年5月8日に更新された公式情報では、適用範囲、Teamsデスクトップアプリ、アプリ単位でのポリシー適用、検証手順がより明確になっています。(Microsoft Learn)
管理者は「ポリシーを作ったから安全」と考えるのではなく、どのアプリ、どのクライアント、どのブラウザ、どのファイル操作に制御が効くのかを確認する必要があります。開発者やアプリ担当者は、SSO方式、カスタムドメイン、関連アプリ、非対話型トークン、ファイルアップロード・ダウンロードの挙動まで含めて検証しましょう。
Conditional Access app controlとは何か
Conditional Access app controlは、Microsoft Entra Conditional AccessとMicrosoft Defender for Cloud Appsを組み合わせ、クラウドアプリへのアクセスやセッション中の操作を制御する仕組みです。Microsoft Defender for Cloud Appsでは、主にaccess policyとsession policyを使って、ユーザー、デバイス、場所、アプリ、セッション中の操作を条件に制御できます。(Microsoft Learn)
たとえば、未管理デバイスからSalesforceへのアクセスをブロックしたり、OneDriveから機密ファイルをダウンロードできないようにしたり、SharePointへのマルウェア疑いファイルのアップロードを止めたりできます。Microsoft Edgeではブラウザ内保護が利用され、他のブラウザでは通常、Defender for Cloud Appsのリバースプロキシ経由で保護されます。(Microsoft Learn)
| 種類 | 何を制御するか | 代表的な用途 |
|---|---|---|
| Access policy | アプリへのアクセスそのもの | 未管理デバイス、特定地域、ネイティブクライアント、リスクの高い条件からのアクセスをブロック |
| Session policy | アプリ利用中の操作 | ダウンロード、アップロード、印刷、コピー、切り取り、貼り付け、マルウェア疑いファイル、機密情報を含む操作の監視・制御 |
| Microsoft Entra Conditional Access | Defender for Cloud Appsへセッションをルーティング | 対象ユーザー、対象アプリ、条件、セッション制御の起点を定義 |
重要なのは、Conditional Access app controlが「すべての通信を万能に制御する機能」ではないことです。ブラウザセッション、クライアントアプリ、Teamsデスクトップアプリ、関連するSharePointやOneDriveなどで、効き方が変わります。
2026年5月8日更新で押さえるべき変更点
今回の更新は、単純な新機能追加というより、管理者が誤解しやすい適用範囲の明確化が中心です。公式ドキュメントの履歴では、2026年3月から5月にかけて、ブラウザベースのセッション制御、アプリ単位でのポリシー適用、Teamsデスクトップアプリでの制限、検証手順に関する記述が追加・整理されています。(GitHub)
| 確認ポイント | 管理者への影響 | 取るべき対応 |
|---|---|---|
| セッション制御はブラウザベースの対話型セッションに適用 | デスクトップアプリや非対話型フローでは想定どおり効かない場合がある | ブラウザ、モバイル、デスクトップアプリを分けて検証する |
| Microsoft Teamsデスクトップアプリはセッション制御の対象外 | Block downloadなどを設定してもTeamsデスクトップアプリには適用されない | 必要に応じてデスクトップアプリのサインインをアクセス制御で制限し、ブラウザ利用へ誘導する |
| Conditional Accessポリシーはアプリ単位で適用 | 個別ファイルだけをポリシーから除外する設計はできない | ファイル単位の例外ではなく、アプリ、ユーザー、グループ、ラベル、操作条件で設計する |
| Edgeはブラウザ内保護、他ブラウザはリバースプロキシ経由 | EdgeとChromeなどでURL表示やユーザー体験が異なる | Edgeのロックアイコン、他ブラウザの.mcas.msサフィックスを確認する |
| TLS 1.2以上が必要 | 古いブラウザやクライアントではアクセスできない可能性がある | 古いOS、古いブラウザ、レガシークライアントの利用状況を棚卸しする |
特に注意すべきなのはTeamsです。Teamsのブラウザアクセスにはセッション制御を適用できますが、TeamsデスクトップアプリにはConditional Access App Controlのセッション制御が適用されません。デスクトップアプリのアクセスを許可したままにすると、ブラウザ側でダウンロード制限を設定していても、デスクトップアプリ経由でコンテンツを取得できる可能性があります。(Microsoft Learn)
影響範囲は「Defenderの設定」だけではない
Conditional Access app controlの影響範囲は、Microsoft Defender for Cloud Appsのポリシー画面だけに閉じません。Microsoft Entra ID、Microsoft 365、Teams、SharePoint、OneDrive、Edge、ネットワーク、SSO設定、カスタムアプリのドメイン設定まで関係します。
| 関係者 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | access policy、session policy、監査ログ、アラート、既存DLPとの整合性 |
| Entra ID管理者 | Conditional Accessポリシー、Report-only、対象ユーザー、除外アカウント、セッション制御 |
| Microsoft 365管理者 | Teams、SharePoint、OneDrive、Exchangeなど関連アプリの使われ方 |
| ネットワーク管理者 | TLS 1.2以上、プロキシ、ファイアウォール、443番ポート、遅延やリダイレクト |
| 開発者・アプリ担当者 | SAML/OIDC、カスタムドメイン、SSO後の画面遷移、ファイル操作、非対話型トークン |
| ヘルプデスク | ブロック時のユーザー通知、アクセス不可時の切り分け、ブラウザ別の案内 |
Microsoft Entra IDアプリでは、SAML 2.0やOpenID Connectを使う対話型SSO、Microsoft Entraアプリケーションプロキシで構成されたオンプレミスアプリなどにアクセス制御やセッション制御を適用できます。一方、Microsoft Entra IDアプリは自動オンボードされますが、他のIdPを使うアプリは手動オンボードが必要です。(Microsoft Learn)
また、Teams、Exchange、Gmailのようなホストアプリに作成したポリシーは、SharePoint、OneDrive、Google Driveなどの関連リソースアプリに自動でつながるわけではありません。必要な場合は、リソースアプリ側にも別のポリシーを作成する必要があります。(Microsoft Learn)
管理者が最初に確認すべき設定
Microsoft Entra Conditional AccessでセッションをDefenderへ渡しているか
Conditional Access app controlを使うには、Microsoft Entra Conditional Accessポリシー側で、セッション制御としてUse Conditional Access App Controlを選択する必要があります。公式手順では、まずReport-onlyで作成し、影響を確認してからOnへ切り替える流れが示されています。(Microsoft Learn)
確認すべき項目は次の通りです。
| 確認項目 | 失敗しやすいポイント |
|---|---|
| 対象ユーザー | 全ユーザー適用時に緊急アクセス用アカウントを除外していない |
| 対象リソース | Teamsだけを指定し、SharePointやOneDrive側の制御を忘れる |
| セッション制御 | Use Conditional Access App Controlを選んでいない |
| 有効化状態 | いきなりOnにして業務影響を確認していない |
| 除外設定 | Microsoft Defender for Cloud Apps – Session Controlsアプリを意図せずブロックしている |
特に、Enterprise ApplicationsにあるMicrosoft Defender for Cloud Apps – Session ControlsがConditional Accessポリシーで意図せずブロックされていると、保護対象アプリへアクセスできなくなる可能性があります。全アプリや特定アプリを広くブロックするポリシーを使っている場合は、このアプリを例外にするか、ブロックが意図したものか確認してください。(Microsoft Learn)
Access policyとSession policyを使い分ける
Access policyは「入れるか、入れないか」を決めるポリシーです。たとえば、未管理デバイス、特定の地域、古いブラウザ、モバイル・デスクトップクライアントからのアクセスをブロックする用途に向いています。Session policyは「入った後に何を許すか」を決めるポリシーです。たとえば、機密ファイルのダウンロード禁止、アップロード時のマルウェア検査、コピー・貼り付け・印刷の制御に使います。(Microsoft Learn)
実務では、次のように使い分けると設計しやすくなります。
| シナリオ | 推奨される考え方 |
|---|---|
| 未管理デバイスからTeamsデスクトップアプリを使わせたくない | Access policyでモバイル・デスクトップクライアントを制限 |
| ブラウザでは閲覧だけ許可し、機密ファイルのダウンロードを止めたい | Session policyでControl file downloadを設定 |
| ファイルの中身に機密情報がある場合だけ制御したい | Session policyでコンテンツ検査や感度ラベルを条件にする |
| 高リスク操作時に追加認証させたい | Session policyのstep-up authenticationを検討 |
| まず影響を見たい | Monitor onlyまたはAuditでログを確認してからブロックへ移行 |
「Teamsのダウンロードを止めたい」という要件では、Teamsアプリそのものだけでなく、SharePointやOneDriveに保存されたファイルの取得経路を確認する必要があります。Teamsのチャットやチャネルから見えているファイルでも、実体はSharePointやOneDriveにあることが多いためです。
Teamsデスクトップアプリを許可したままにしない
今回の更新で最も見落としやすいポイントは、Microsoft Teamsデスクトップアプリです。公式情報では、TeamsデスクトップアプリはConditional Access App Controlのセッション制御に対応しておらず、Block downloadなどのセッション制御は適用されないと明記されています。(Microsoft Learn)
そのため、機密情報を扱うユーザーに対して「ブラウザではダウンロードをブロックしているから安全」と判断するのは危険です。デスクトップアプリを許可する場合は、その経路でもコンテンツを取得できるかを必ず検証してください。
対応方針は主に3つです。
| 方針 | 向いているケース | 注意点 |
|---|---|---|
| Teamsブラウザ利用へ寄せる | 未管理デバイスや外部委託先など、セッション制御を確実に効かせたい | ユーザー体験が変わるため事前周知が必要 |
| Teamsデスクトップアプリをアクセス制御で制限 | ダウンロード制御を優先する高リスク部門 | 既存業務フローへの影響をテストする |
| デスクトップアプリを許可し、別の制御で補完 | 管理デバイスのみ利用、Endpoint DLPや端末管理が整っている | Conditional Access app controlだけで守れていると誤解しない |
Edgeのブラウザ内保護とリバースプロキシの違いを確認する
Microsoft Edge for Businessでは、条件を満たす場合にブラウザ内保護が利用されます。これにより、リバースプロキシを使わず、ブラウザ内で直接保護されます。ユーザーはアドレスバーのロックアイコンで保護状態を確認できます。一方、Chrome、Firefox、Safariなどでは通常、リバースプロキシ経由となり、URLに.mcas.msが表示されます。(Microsoft Learn)
Edgeのブラウザ内保護を使う場合は、次の条件を確認してください。
| 確認項目 | 内容 |
|---|---|
| ブラウザプロファイル | ユーザーがEdgeの仕事用プロファイルでサインインしているか |
| OS | Windows 10、Windows 11、macOSなど対応環境か |
| Edgeバージョン | 安定版の直近バージョン要件を満たしているか |
| 対象ポリシー | Edgeブラウザ内保護でサポートされるセッションポリシーか |
| 例外条件 | InPrivate、古いEdge、Android、B2Bゲスト、一部ポリシーではリバースプロキシになる可能性があるか |
Edge for Business protectionは、Microsoft DefenderポータルのCloud Apps設定から構成できます。必要に応じて、Edge利用を強制する、または可能な場合にEdgeへ誘導する設定を検討します。ただし、いきなり全社強制すると業務影響が大きいため、未管理デバイスや高リスク部門から段階的に展開するのが現実的です。(Microsoft Learn)
ファイルサイズとコンテンツ検査の制限を把握する
Session policyにはファイルサイズや検査条件の制限があります。公式情報では、セッションポリシーを適用できるファイルサイズは最大50MB、コンテンツ検査に基づくアップロード・ダウンロード制御では30MB未満かつ100万文字未満のファイルが検査対象とされています。これを超えるファイルは、ポリシーの「データをスキャンできない場合でも選択したアクションを常に適用する」設定などに従って扱われます。(Microsoft Learn)
| 条件 | 管理上の注意 |
|---|---|
| 50MBを超えるファイル | セッションポリシーだけで期待どおり制御できると考えない |
| 30MB以上または100万文字超のファイル | コンテンツ検査の対象外になる可能性がある |
| 暗号化された感度ラベル付きファイル | スキャン不能時の動作設定によってブロックされる場合がある |
| 大容量ファイルの多い部門 | 既定動作を「許可」か「ブロック」か事前に合意する |
| Edgeブラウザ内保護 | スキャン不能時に常にアクション適用する設定では、大容量ファイルがブロックされる可能性がある |
大容量ファイルを扱う設計、営業資料、CAD、動画、ログ、バックアップファイルなどが多い部門では、セキュリティ部門だけで判断せず、業務部門と「ブロックされると困るファイル」と「漏えい時の影響が大きいファイル」を整理してから展開しましょう。
展開前に行うべき検証手順
Conditional Access app controlは、設定画面でポリシーを作るだけでは不十分です。実際の業務経路でテストし、想定した制御が効いているかを確認する必要があります。Microsoftの公式手順でも、対象ユーザーで再認証し、ブラウザ、モバイル、デスクトップアプリ、管理デバイス、未管理デバイスで挙動を確認することが推奨されています。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 現状把握 | 対象アプリ、対象ユーザー、クライアント種類を棚卸し | Teamsデスクトップ、SharePoint、OneDrive、外部ユーザーを含める |
| CAポリシー作成 | Entra Conditional AccessでUse Conditional Access App Controlを設定 | 最初はReport-onlyで開始 |
| Defenderポリシー作成 | access policyまたはsession policyを作成 | 目的に合う制御種別を選ぶ |
| ブラウザテスト | Edge、Chrome、Firefox、Safariなどで確認 | Edgeはロックアイコン、他ブラウザは.mcas.msを確認 |
| クライアントテスト | Teamsデスクトップ、モバイル、Officeアプリなどで確認 | セッション制御が効かない経路を洗い出す |
| 操作テスト | ダウンロード、アップロード、印刷、コピー、共有を実行 | 期待どおりブロック・監査されるか |
| ログ確認 | Cloud AppsのActivity logやポリシーレポートを見る | Access control由来のイベントやセッションポリシー一致を確認 |
| 段階展開 | テストユーザー、部門、全社へ広げる | ヘルプデスク向けの案内と例外申請ルールを用意 |
テスト時は、既存セッションの影響を避けるため、すべてのセッションからサインアウトしてから再認証します。セッションポリシーでは、ロックアイコンや.mcasサフィックス、対象ページの表示、ファイル操作、ポリシーレポートを確認します。問題が出た場合は、管理者ツールバーで.harファイルや記録セッションを収集し、切り分けに使えます。(Microsoft Learn)
開発者・アプリ担当者が確認すべきポイント
開発者やアプリ担当者は、「Defenderのポリシーだから管理者だけの作業」と考えない方がよいです。Conditional Access app controlはSSO、リダイレクト、ドメイン、アップロード・ダウンロード、ブラウザ互換性に影響するため、アプリ側の実装や構成によってユーザー体験が変わります。
SSO方式とアプリオンボードを確認する
対象アプリがMicrosoft Entra IDのSAML 2.0またはOpenID Connectの対話型SSOに対応しているか確認します。非Microsoft IdPのアプリは手動オンボードが必要です。カスタムアプリやプラグインで独自ドメインを使っている場合は、クラウドアプリカタログ上の該当アプリに関連カスタムドメインを追加する必要があります。(Microsoft Learn)
よくある失敗は、ログイン画面だけ正常に動くものの、SSO後に別ドメインへ遷移するページ、ファイルプレビュー、ダウンロードURL、APIサブドメインが登録されていないケースです。ユーザーの主要業務フローをすべて通して検証しましょう。
非対話型トークンと関連アプリの抜け道を確認する
一部のアプリは、同じスイート内の別アプリへ移動する際に非対話型アクセストークンを使います。公式情報では、片方のアプリだけをConditional Access App Controlへオンボードしている場合、セッション制御が期待どおり適用されない場合があると説明されています。たとえばTeamsクライアントがSharePointの非対話型トークンを取得し、再認証なしにSharePoint Onlineセッションを開始するようなケースです。(Microsoft Learn)
このため、Teamsだけ、SharePointだけ、OneDriveだけを個別に見るのではなく、次のような組み合わせで検証する必要があります。
| 業務フロー | 確認すべき経路 |
|---|---|
| Teamsチャネルからファイルを開く | Teams、SharePoint、OneDrive |
| OutlookやTeamsから共有リンクを開く | リンク先アプリ、ファイル保存先、ブラウザ・デスクトップアプリ |
| SlackやServiceNowから外部SaaSへ遷移 | SSO後のドメイン、リダイレクト、深いリンク |
| カスタムアプリから帳票をダウンロード | 帳票生成ドメイン、CDN、API、ファイル拡張子 |
| ブラウザで閲覧後にOfficeアプリで開く | ブラウザセッションとローカルアプリの境界 |
リバースプロキシで壊れやすい画面を事前に見る
リバースプロキシ経由のセッションでは、アプリコードやリンクが変換されるため、まれに画面表示、深いリンク、ファイルアップロード、ブラウザ拡張、組み込みアプリに影響が出る場合があります。既知の制限として、組み込みアプリやブラウザ拡張は現在サポートされないこと、特定アプリでリンクの完全なパスが失われホーム画面へ遷移する可能性があること、ドラッグ＆ドロップでのフォルダーアップロード制御に注意が必要なことが示されています。(Microsoft Learn)
開発者は、次の操作をテストケースに入れてください。
| テスト項目 | 見るべき結果 |
|---|---|
| SSOログイン | 認証後に正しい画面へ遷移する |
| 深いリンク | 一覧画面ではなく対象ページ・対象ファイルが開く |
| ファイルダウンロード | ブロック、保護、監査がポリシーどおり動く |
| ファイルアップロード | ドラッグ＆ドロップとファイル選択の両方を確認する |
| コピー・貼り付け・印刷 | ブラウザごとの挙動差を確認する |
| 大容量ファイル | スキャン不能時の既定動作が業務要件に合う |
| エラー時の情報収集 | HAR、記録セッション、ユーザー操作手順を残す |
よくある誤解と正しい判断基準
| 誤解 | 実際 | 対応 |
|---|---|---|
| TeamsにBlock downloadを設定すればTeamsデスクトップアプリも制御できる | Teamsデスクトップアプリはセッション制御の対象外 | デスクトップアプリのアクセス制御やブラウザ利用誘導を検討 |
| Conditional Access app controlはファイル単位で例外設定できる | Conditional Accessポリシーはアプリ単位で適用され、個別ファイル除外はできない | 感度ラベル、アプリ、ユーザー、操作条件で設計する |
| EdgeとChromeで同じ見え方になる | Edgeはブラウザ内保護、他ブラウザはリバースプロキシになる場合がある | ブラウザ別に保護状態を確認する |
| 大きなファイルもすべて内容検査される | コンテンツ検査にはサイズや文字数の制限がある | 大容量ファイルの既定動作を決めておく |
| IP条件はIPv6にも効く | Access policyとSession policyのIPベースルールはIPv4のみ対応 | IPv6環境では別の条件や制御方法を検討する |
| Microsoft Entra IDアプリ以外も自動で使える | 非Microsoft IdPアプリは手動オンボードが必要 | 事前にオンボード状況とドメインを確認する |
この機能の設計では、「何をブロックするか」より先に「どの経路なら制御が効かないか」を洗い出すことが重要です。特にTeamsデスクトップ、モバイルアプリ、Officeクライアント、外部B2Bユーザー、関連するSharePointやOneDriveは、実際の業務で使われる頻度が高いため、初期段階で検証対象に入れてください。(Microsoft Learn)
トラブル時の切り分けポイント
アクセス不可、表示崩れ、遅延、ポリシー未適用が発生した場合は、次の順番で切り分けると原因を特定しやすくなります。
| 症状 | 最初に確認すること |
|---|---|
| Conditional Access App Controlの選択肢が見えない | Microsoft Entra ID P1とDefender for Cloud Appsのライセンス |
| アプリがポリシー対象に出てこない | アプリのオンボード状況、非Microsoft IdPかどうか |
| ネットワークエラーが出る | Defender for Cloud Appsデータセンターへの通信、443番ポート、TLS 1.2 |
| Edgeなのにリバースプロキシになる | Edge仕事用プロファイル、対象ポリシー、OS、Edgeバージョン、InPrivate利用 |
| サインインが遅い | プロキシチェーン、nonce処理、外部プロキシやゲートウェイ |
| デスクトップアプリで制御されない | Session policyではなくAccess policyで制御すべき経路か |
| ファイル制御が効かない | ファイルサイズ、文字数、暗号化ラベル、スキャン不能時の設定 |
公式トラブルシューティングでは、ブラウザベースの最新Edge、Chrome、Firefox、Safariがセッション制御の対象として示され、リバースプロキシ関連の問題ではネットワーク、TLS 1.2、プロキシチェーン、アプリオンボード、ポリシー作成時の権限やライセンスを確認する流れが整理されています。(Microsoft Learn)
展開時の実務チェックリスト
本番展開前に、少なくとも次の項目を確認してください。
- テストユーザーでReport-onlyから開始している
- 緊急アクセス用アカウントを除外している
- Microsoft Defender for Cloud Apps – Session Controlsアプリを意図せずブロックしていない
- Teamsブラウザ版とTeamsデスクトップアプリを別々に検証している
- SharePoint、OneDriveなど関連リソースアプリも確認している
- Edgeではロックアイコン、他ブラウザでは
.mcas.ms表示を確認している - モバイル・デスクトップクライアントの扱いをaccess policyで整理している
- 大容量ファイルとスキャン不能時の既定動作を決めている
- カスタムアプリのドメイン、リダイレクト、深いリンクをテストしている
- Activity log、ポリシーレポート、アラート通知を確認している
- ブロック時のユーザー向けメッセージとヘルプデスク手順を用意している
展開の順序は、最初に高リスクアプリを1つ選び、テストユーザーでReport-only、次に限定部門で監査、最後にブロックへ移行するのが安全です。最初から全社一括でブロックすると、TeamsやSharePointのような関連アプリ、デスクトップクライアント、大容量ファイルで想定外の業務影響が出やすくなります。
まず取るべき対応
2026年5月8日更新のポイントを踏まえると、管理者が最初に行うべきことは、既存ポリシーの棚卸しです。特に、Teamsデスクトップアプリを許可したまま「ブラウザ側のセッション制御で保護できている」と判断していないかを確認してください。次に、Microsoft Entra Conditional AccessでUse Conditional Access App Controlが正しく設定されているか、Defender for Cloud Apps側のaccess policyとsession policyが目的に合っているかを見直します。
開発者やアプリ担当者は、カスタムドメイン、SSO後のリダイレクト、非対話型トークン、関連アプリ、ファイル操作を含めた実利用シナリオで検証しましょう。Conditional Access app controlは強力な機能ですが、効果を最大化するには「どこに効くか」だけでなく「どこに効かないか」を設計に入れることが不可欠です。
最初の一歩として、対象アプリ、対象ユーザー、利用クライアントを一覧化し、Teamsデスクトップアプリ、SharePoint、OneDrive、Edge以外のブラウザ、大容量ファイルを含む検証計画を作成してください。そのうえでReport-onlyから始めれば、業務影響を抑えながらMicrosoft Defender for Cloud AppsのConditional Access app controlを安全に展開できます。
コメント