Microsoft Entra Global Secure AccessのUniversal tenant restrictionsは、社用端末や拠点ネットワークから、未承認の外部テナントや個人用Microsoftアカウントへ外部IDでサインインする動きを制限する機能です。
2026年6月11日の公式ドキュメント更新で重要なのは、Global Secure Access単独のデータプレーン保護はMicrosoft Graphに限られると明確化された点です。Forms、SharePoint Online、Teams会議の匿名アクセスまで一括で遮断する機能ではありません。(GitHub)
2026年6月11日の更新で何が変わったのか
今回の更新は、新機能の提供開始や設定の自動変更ではなく、Universal tenant restrictionsの保護範囲を正確にするためのドキュメント修正です。
| 確認項目 | 更新後の正しい理解 |
|---|---|
| 認証プレーン | Global Secure Access経由なら、OSやブラウザを問わず外部テナントへのサインインを制御できる |
| データプレーン | Global Secure Accessで保護されるのは現時点でMicrosoft Graphのみ |
| SharePoint・Exchangeのデータプレーン | Global Secure Access単独では保護対象にならない |
| Forms・SharePoint・Teamsの匿名アクセス | Global Secure Access単独では遮断できない |
| 必要な追加対策 | 対象によってWindowsのグループポリシーなどを併用する |
6月11日の公式差分では、従来の表から匿名アクセスに関する列が削除され、Global Secure Accessは「全プラットフォームの認証プレーン」と「Microsoft Graphのデータプレーン」を保護するという注記が追加されました。(GitHub)
Universal tenant restrictionsの仕組み
Universal tenant restrictionsは、次の2つを組み合わせて機能します。
- Tenant Restrictions v2で、許可する外部テナント、ユーザー、グループ、アプリを定義する
- Global Secure Accessが通信にポリシー情報を付加し、Microsoft Entra IDやMicrosoft Graphで制限を適用する
たとえば、社員が会社のPCから、私的に作成した別テナントのアカウントで外部アプリへサインインしようとした場合、そのテナントが許可されていなければ認証を拒否できます。
自宅のPCなどで取得したMicrosoft Graphのアクセストークンを社用端末へ持ち込み、認証処理を回避して利用しようとするケースも、Global Secure Accessを通過する通信であればデータプレーン側で遮断できます。(Microsoft Learn)
ただし、ポリシーが適用されるのは、Global Secure Accessクライアントまたはリモートネットワーク経由で取得された通信です。Global Secure Accessを通らない端末やネットワークに、自動的に制限が及ぶわけではありません。
何を防げて、何を防げないのか
| 利用シナリオ | Global Secure Accessによる保護 |
|---|---|
| 未承認の外部テナントへのサインイン | 対応 |
| 個人用Microsoftアカウントでのサインイン | Tenant Restrictions v2の設定により制御可能 |
| Microsoft Entra ID連携アプリへの外部IDサインイン | 対応 |
| Microsoft Graphへの持ち込みトークンの再利用 | 対応 |
| SharePoint OnlineやExchange Onlineのデータプレーン | Global Secure Access単独では非対応 |
| FormsやSharePointの匿名リンク | Global Secure Access単独では非対応 |
| 外部テナントが主催するTeams会議への匿名参加 | Global Secure Access単独では非対応 |
| Microsoft Entra IDを使用しない外部サービス | 原則として対象外 |
Microsoft Entra ID以外のアカウントで利用する外部サービスや、認証を必要としない匿名リンクは、認証プレーンの制御を通過しません。Universal tenant restrictionsを「すべてのアップロードやデータ送信を検査するDLP機能」と捉えないことが重要です。(Microsoft Learn)
誰に影響するのか
影響が大きい管理者
すでにUniversal tenant restrictionsを利用している組織では、次の担当者が設定を再確認する必要があります。
- Microsoft Entra IDのID・認証管理者
- Global Secure Accessの管理者
- Microsoft 365のセキュリティ管理者
- Windowsのグループポリシー管理者
- 外部テナントとの共同作業を管理する担当者
特に「Global Secure AccessだけでSharePoint、Exchange、Teams、Formsのデータプレーンまで保護できる」と想定していた場合は、セキュリティ設計の見直しが必要です。
影響を受ける一般ユーザー
一般ユーザーには、主に次の場面で影響があります。
- 会社の端末から取引先発行のアカウントを使う
- 個人用MicrosoftアカウントでMicrosoftサービスへサインインする
- 検証用や個人管理のMicrosoft Entraテナントへアクセスする
- 未登録の外部テナントで提供されるアプリを利用する
許可されていないテナントへのサインインでは、組織のポリシーによってアクセスが制限されている旨のエラーが表示されます。一方、自組織のテナントへの通常のサインインや、自組織内に作成されたゲストユーザーによるアクセスには、同じ形では適用されません。(Microsoft Learn)
Universal tenant restrictionsの設定手順
許可する外部テナントを先に整理する
最初に、現在利用している取引先テナント、外部アプリ、個人用Microsoftアカウントの用途を洗い出します。
データ持ち出し対策を目的とする場合は、次の設計が基本です。
- デフォルトでは外部ユーザーと外部アプリをブロックする
- 業務上必要な取引先テナントだけ個別に登録する
- 可能な場合は、許可するユーザーやアプリも限定する
- 個人用Microsoftアカウントを許可する場合も、対象アプリを絞る
例外を整理せずに全外部テナントをブロックすると、取引先の管理画面や研修サービスなど、正当な業務まで停止する可能性があります。
Tenant Restrictions v2ポリシーを作成する
Microsoft Entra管理センターで、次の順に開きます。
Entra ID > External Identities > Cross-tenant access settings > Default settings
Tenant restrictionsの編集画面で、外部ユーザーと外部アプリの既定動作を設定します。全ユーザーをブロックする場合は、外部アプリ側もブロック対象として設定する必要があります。
許可する取引先は、次の画面から追加します。
Entra ID > External Identities > Cross-tenant access settings > Organizational settings
対象組織をドメイン名またはテナントIDで登録し、継承設定をカスタマイズします。(Microsoft Learn)
Microsoft traffic profileを有効にする
Global Secure Access側では、次の画面でMicrosoft traffic profileを有効化します。
Global Secure Access > Connect > Traffic forwarding
Universal tenant restrictionsの対象となるFQDNやIPアドレスは、BypassではなくForwardにする必要があります。Bypassにした通信はGlobal Secure Accessで処理されないため、制限用のシグナルも適用されません。
本番展開前は、Microsoft traffic profileの割り当てをテスト用のユーザーやグループに限定すると、影響を確認しやすくなります。(Microsoft Learn)
クライアントまたはリモートネットワークを用意する
端末単位で適用する場合はGlobal Secure Accessクライアントを展開します。拠点全体の通信を対象にする場合は、リモートネットワーク接続を使用できます。
リモートネットワーク配下であれば、各端末へクライアントを導入せずにMicrosoft traffic profileを適用できます。ただし、社外へ持ち出すノートPCなども保護する場合は、クライアント方式が必要です。(Microsoft Learn)
Universal tenant restrictionsを有効化する
Tenant Restrictions v2と通信経路の準備が完了したら、次の画面を開きます。
Global Secure Access > Settings > Session Management > Universal Tenant Restrictions
「Microsoft Entra IDとMicrosoft GraphのTenant Restrictionsを有効にする」トグルをオンにします。
Tenant Restrictions v2ポリシーの設定にはSecurity Administrator、Global Secure Accessの設定にはGlobal Secure Access Administratorが必要です。最小権限で運用する場合は、担当者とロールの分担も事前に決めておきましょう。(Microsoft Learn)
設定後に確認する方法
認証プレーンを確認する
未許可の外部テナントに属するテストアカウントを用意し、Global Secure Accessクライアントが動作している端末からMy Appsへサインインします。
想定どおりであれば、外部テナントへの認証が拒否されます。既存のサインイン情報が残っていると正しく確認できないため、プライベートブラウズを使うか、ブラウザを再起動してテストします。
Microsoft Graphのデータプレーンを確認する
Graph Explorerへ未許可テナントのアカウントでサインインし、Universal tenant restrictionsの有効化前後で通信を比較します。
ブラウザの開発者ツールでは、遮断時にHTTPステータス302や、次のレスポンスヘッダーを確認できます。
Restrict-Access-Confirm: 1
本番環境全体でトグルを切り替えるのではなく、テストユーザーへMicrosoft traffic profileを割り当てた状態で検証するのが安全です。(Microsoft Learn)
SharePointやTeamsまで保護する場合の追加対策
SharePoint Online、Exchange Online、Forms、Teams会議などのデータプレーンや匿名アクセスを制御するには、WindowsのTenant Restrictions v2グループポリシーを検討します。
ただし、Windows側の方式にも制約があります。Microsoft EdgeなどWindowsのネットワークスタックを利用するアプリが中心で、Chrome、Firefox、PowerShellなどの.NETアプリは、そのままでは同等の保護を受けません。
これらを利用する環境では、App Control for BusinessやWindows Firewallを組み合わせ、保護されていないアプリからMicrosoftリソースへ接続できないようにする必要があります。(Microsoft Learn)
料金・ライセンスで確認すべきこと
Universal Tenant RestrictionsとMicrosoft traffic profileは、Microsoft Entra ID P1またはP2の対象機能です。この機能だけを利用するために、Microsoft Entra Internet AccessやMicrosoft Entra Private Accessのスタンドアロンライセンスが必要とは記載されていません。
ただし、ライセンスは原則としてユーザー単位です。また、Microsoft trafficをリモートネットワークで取得する場合は、Microsoft Entra ID P1とMicrosoft Entra Internet Accessを合わせて最低50ライセンスという条件があります。
2026年6月11日のドキュメント更新には、Universal tenant restrictionsの料金改定は含まれていません。実際の単価は、Microsoftとの契約、CSP、Enterprise Agreementなどの購入経路で確認してください。(Microsoft Learn)
既存環境の更新・移行は必要か
すでにUniversal tenant restrictionsを利用している場合
6月11日の更新に伴う強制的なクライアント更新や設定移行は示されていません。必要なのは、現在の設計書やテスト項目に「Global Secure Accessのデータプレーン保護はMicrosoft Graphのみ」と明記し、保護対象の認識を修正することです。
Tenant Restrictions v1を利用している場合
プロキシでTenant Restrictions v1のヘッダーを挿入している環境は、Tenant Restrictions v2への段階的な移行を検討します。
移行時は、既存の許可テナントをクラウドポリシーへ移し、プロキシを継続利用する場合は新しいsec-Restrict-Tenant-Access-Policyヘッダーへ変更します。旧方式のRestrict-Access-To-TenantsとRestrict-Access-Contextは削除します。
Microsoftは、一括切り替えではなく、テストユーザーやプロキシ単位で段階的に移行し、ロールバック用に旧設定を保存する方法を案内しています。(Microsoft Learn)
移行期限はあるか
2026年6月11日の更新では、Universal tenant restrictionsの適用期限やTenant Restrictions v1の強制終了日は示されていません。今回の更新だけを理由に、緊急の移行作業を実施する必要はありません。
ただし、Tenant Restrictions v2ではポリシーをクラウド側で管理でき、テナント、ユーザー、グループ、アプリ単位で細かく制御できます。新規導入ではv2を前提に設計したほうが管理しやすいでしょう。(Microsoft Learn)
設定時に失敗しやすいポイント
Microsoft trafficをBypassにしている
対象通信がBypassの場合、Global Secure Accessは通信を取得しません。Microsoft traffic profile内のFQDNとIPアドレスがForwardになっているか確認してください。
クライアント切断時の動作を考慮していない
Global Secure Accessクライアントがサービスへ接続できない場合、通信が直接インターネットへ送られることがあります。常にGlobal Secure Access経由を必須にする場合は、Conditional AccessのCompliant Network checkとの併用を検討します。(Microsoft Learn)
Cross-tenant access設定と混同している
Outbound設定は「自組織のIDで外部アプリへアクセスする動き」を制御します。一方、Tenant Restrictions v2は「外部IDを使って外部アプリへアクセスする動き」を制御します。
同じCross-tenant access settings内にありますが、目的と評価対象は異なります。(Microsoft Learn)
許可済みテナントの管理センターに入れない
Universal tenant restrictionsを有効にすると、許可リストに登録したテナントのMicrosoft Entra管理センターでも「Access denied」が表示される既知の制限があります。
この場合は、Microsoft Entra管理センターのURLに次の機能フラグを追加します。
?feature.msaljs=true&exp.msaljsexp=true
恒久的な例外設定を追加する前に、既知の制限に該当しないか確認しましょう。(Microsoft Learn)
まず確認すべき4つの項目
2026年6月11日の更新を受け、管理者は次の順番で確認すると効率的です。
- 現在の設計が、Global Secure AccessでMicrosoft 365全体のデータプレーンを保護できる前提になっていないか
- 業務で必要な外部テナント、外部アカウント、外部アプリを把握できているか
- My AppsとGraph Explorerで、認証プレーンとMicrosoft Graphの遮断をそれぞれ検証したか
- SharePoint、Exchange、Forms、Teamsの匿名アクセス対策として、Windowsポリシーなどの追加制御が必要か
Universal tenant restrictionsは、未承認テナントへのサインインとMicrosoft Graph経由のデータ持ち出しを抑える有効な仕組みです。ただし、保護範囲を過大評価せず、認証プレーン、Microsoft Graph、Microsoft 365の各データプレーンを分けて設計することが重要です。
コメント