Microsoft Entra Global Secure AccessのUniversal Tenant Restrictions（UTR）を使うと、Global Secure Access経由の端末や拠点ネットワークから、未承認の外部Microsoft Entraテナントへサインインする行為を制限できます。
ただし、UTRを有効にしただけでは、意図した外部テナントが自動的に遮断されるわけではありません。先にTenant Restrictions v2（TRv2）ポリシーで「原則拒否」と「許可する取引先テナント」を定義し、そのポリシーをGlobal Secure Access経由の通信へ適用する必要があります。
実務では、次の2つを分けて設計することが重要です。
- TRv2ポリシー：どの外部アカウント、テナント、アプリを許可・拒否するか
- Universal Tenant Restrictions：Global Secure Accessを通る通信へTRv2の制御情報を付加する仕組み
Microsoftが2026年7月29日に更新した公式情報でも、TRv2ポリシーを構成した後にUTRを有効化する手順が示されています。(Microsoft Learn)
Universal Tenant Restrictionsで未承認Entraテナントを遮断する方法
Universal Tenant Restrictionsは、Global Secure Accessクライアントが導入された端末、またはGlobal Secure Accessのリモートネットワークに接続された拠点からの通信に、TRv2ポリシーを適用する機能です。
従来のように企業プロキシでMicrosoft Entra IDへの通信を復号し、専用のHTTPヘッダーを挿入しなくても、Global Secure Accessを経由して制御情報を付加できます。対象となる通信では、Microsoft Entra IDがTRv2ポリシーを評価し、許可されていない外部テナントやアプリへのサインインを拒否します。(Microsoft Learn)
処理の流れを簡略化すると、次のようになります。
利用端末・拠点ネットワーク
↓
Global Secure Accessで通信を取得
↓
Tenant Restrictions v2の制御情報を付加
↓
Microsoft Entra ID／Microsoft Graph
↓
TRv2ポリシーに基づいて許可または拒否ここで重要なのは、Global Secure Accessが「許可するテナント」を判断するのではなく、Cross-tenant access settingsに作成したTRv2ポリシーを適用する経路を提供するという点です。
UTRが制限するのは「外部アカウントから外部アプリへのアクセス」
「外部テナントへのアクセス制限」と聞くと、自社アカウントによる取引先テナントへのアクセスをすべて制御する機能に見えます。しかし、Tenant Restrictionsが主に制御するのは、利用者が企業端末や企業ネットワーク上で外部テナントのアカウントを使用し、外部アプリへアクセスする場面です。
Microsoft Entraのクロステナント設定は、次のように役割が分かれています。(Microsoft Learn)
| 制御したいアクセス | 主に使用する設定 |
|---|---|
| 外部アカウントから自社アプリへのアクセス | Inbound access settings |
| 自社アカウントから外部アプリへのアクセス | Outbound access settings |
| 外部アカウントから外部アプリへのアクセス | Tenant Restrictions v2 |
| Global Secure Access経由でTRv2を適用 | Universal Tenant Restrictions |
例えば、従業員が自社PCで、個人的に作成した別テナントのMicrosoft 365アカウントへサインインし、そこへ社内データをアップロードするケースはUTRの代表的な制御対象です。
一方、自社アカウントのまま取引先テナントにB2Bアクセスする場合は、Outbound access settingsや取引先側のInbound access settingsも含めて設計する必要があります。
導入前に必要な条件
Universal Tenant Restrictionsを構成する前に、次の条件を確認します。
| 確認項目 | 必要な内容 |
|---|---|
| ライセンス | Microsoft Entra ID P1またはP2 |
| TRv2設定用ロール | Security Administrator以上 |
| UTR有効化用ロール | Global Secure Access AdministratorとSecurity Administrator |
| トラフィックプロファイル | Microsoft traffic profileを有効化 |
| 通信経路 | Global Secure Accessクライアントまたはリモートネットワーク |
| ポリシー | TRv2の既定設定と、必要に応じた組織別設定 |
現在のMicrosoft公式機能比較では、Universal Tenant RestrictionsはMicrosoft traffic profile側の機能として、Microsoft Entra ID P1/P2に含まれています。ライセンス条件は変更される可能性があるため、実際の契約内容と最新のMicrosoft Learnも併せて確認してください。(Microsoft Learn)
また、Global Secure Access側ではMicrosoft traffic profileを有効にし、Microsoft Entra IDサービスに必要なFQDNやIPアドレスをトンネル対象にする必要があります。端末から適切に通信を取得できなければ、UTRを有効にしても制御情報が付加されません。(Microsoft Learn)
最初に「既定拒否と例外許可」を設計する
実際に設定を始める前に、許可する外部テナント、外部アカウント、外部アプリを整理します。
推奨しやすい基本方針は、次のとおりです。
| 対象 | 基本方針 |
|---|---|
| 未登録の外部テナント | すべて拒否 |
| 正式な取引先テナント | 業務上必要な範囲だけ許可 |
| 取引先の外部アカウント | 必要なユーザーまたはグループだけ許可 |
| 外部アプリ | 必要なアプリだけ許可 |
| 個人用Microsoftアカウント | 原則拒否し、必要なアプリのみ例外許可 |
単に取引先テナント全体を許可すると、そのテナント内に存在する多数のアカウントやアプリまで利用できる可能性があります。
可能であれば、次のように段階的に絞り込みます。
許可テナント
└ 許可する外部ユーザー／グループ
└ 許可する外部アプリ例えば、「取引先A社のテナントは許可するが、対象は共同プロジェクト用グループだけ」「利用可能なアプリは共同作業に必要なものだけ」といった設計です。
TRv2の既定ポリシーを構成する
最初に、登録されていない外部テナントを原則として拒否する既定ポリシーを作成します。
Cross-tenant access settingsを開く
Security Administratorロールを持つアカウントでMicrosoft Entra管理センターへサインインし、次の順に移動します。
Entra ID
→ External Identities
→ Cross-tenant access settings
→ Default settings日本語表示では、「外部ID」「テナント間アクセス設定」などの名称で表示される場合があります。管理センターの言語や更新状況によって表記が異なることがあります。
Tenant Restrictionsの既定設定を編集する
Default settingsのTenant restrictionsセクションから、既定設定の編集を開始します。
ポリシーがまだ存在しない場合は、Create policyを選択して作成します。作成後はTenant IDとPolicy IDが表示されます。Global Secure AccessでUTRを使用する場合、通常は管理センター側がこれらの情報を利用して制御情報を付加します。(Microsoft Learn)
外部ユーザーと外部アプリを拒否する
External users and groupsタブでは、次のように設定します。
Access status：Block access
Applies to：All users and groups続いて、External applicationsタブを設定します。
Access status：Block access
Applies to：All external applications最後に設定を保存します。
既定設定で全ユーザーを拒否する場合は、外部アプリ側もすべて拒否する必要があります。どちらか一方だけをBlock accessにすると、管理者が意図した既定拒否にならない可能性があります。(Microsoft Learn)
許可する取引先テナントを例外登録する
既定ポリシーを拒否にした後、業務で必要な外部テナントを個別に追加します。
外部組織を追加する
Cross-tenant access settingsで、次の順に移動します。
Organizational settings
→ Add organization許可したい組織の完全修飾ドメイン名、またはMicrosoft EntraテナントIDを入力して組織を追加します。
ドメイン名が似ている別組織を誤登録しないように、可能であれば取引先から正式なテナントIDを入手し、組織名と照合してください。
既定設定の継承を解除する
組織を追加しただけでは、その組織は既定ポリシーを継承します。既定ポリシーがBlock accessであれば、追加した取引先も引き続き拒否されます。
追加した組織のTenant restrictions欄を開き、Customize settingsを選択します。(Microsoft Learn)
許可範囲を設定する
取引先ごとに、外部ユーザー・グループと外部アプリの許可範囲を設定します。
例として、取引先テナント内の特定グループだけに特定アプリの利用を認める場合は、次のように構成します。
External users and groups
Access status：Allow access
Applies to：選択した外部ユーザーまたはグループ
External applications
Access status：Allow access
Applies to：選択した外部アプリ外部ユーザーやグループを個別指定する場合、対象となる外部テナント側のオブジェクトIDが必要です。設定担当者だけで判断せず、取引先のMicrosoft Entra管理者と対象範囲を確認するのが安全です。
Microsoftアカウントにはユーザー単位の制限が使えない
個人用Microsoftアカウントを表すMicrosoft accountテナントについては、ユーザー単位の細かな指定がサポートされていません。ただし、アプリ単位の許可範囲は設定できます。
そのため、Microsoftアカウントを一律に許可するのではなく、必要な外部アプリだけを選択して許可する運用が適しています。Microsoftの公式手順では、Microsoft Learnなど特定アプリだけを許可する例が示されています。(Microsoft Learn)
Microsoft traffic profileと通信経路を構成する
TRv2ポリシーを作成しただけでは、端末や拠点から送信される通信にポリシー情報は付加されません。
次に、Global Secure AccessがMicrosoft Entra ID関連通信を取得できるようにします。
Microsoft traffic profileを有効化する
Global Secure AccessのTraffic forwardingからMicrosoft traffic profileを有効にします。
Microsoft traffic profileには、Microsoftサービスに必要なFQDN、IP範囲、ポートなどの転送ルールが事前定義されています。ルールをForwardまたはトンネル対象にすると、Global Secure Accessクライアントやリモートネットワークが該当通信を取得します。BypassにするとGlobal Secure Accessを通らないため、UTRの適用対象外になる可能性があります。(Microsoft Learn)
特に、Microsoft Entra IDの認証に必要な通信が意図せずBypassになっていないか確認してください。
端末にはGlobal Secure Accessクライアントを展開する
個々の端末から通信を取得する場合は、Global Secure Accessクライアントを導入します。
現在、MicrosoftはWindows、macOS、Android、iOS向けクライアントを提供しています。クライアントは、管理者が構成したトラフィック転送プロファイルに基づいて対象通信を取得します。(Microsoft Learn)
全社展開の前に、次のような対象から試験するのが安全です。
- 情報システム部門の検証端末
- 外部テナントを通常利用しない部門
- 許可済み取引先と未承認テナントの両方をテストできる利用者
- 業務影響を切り分けやすい少数端末
拠点全体へ適用する場合はリモートネットワークを使う
支店や工場など、拠点ネットワーク全体へ適用する場合は、Global Secure Accessのリモートネットワーク接続を構成します。
リモートネットワークでは、拠点側ルーターなどのCPEとGlobal Secure Accessのエンドポイント間にIPsecトンネルを作成し、指定した通信をGlobal Secure Accessへ転送します。端末ごとにクライアントを導入しなくても、拠点からの通信をまとめて制御できます。(Microsoft Learn)
ただし、拠点内のゲストWi-FiやBYODまで同じ経路へ送ると、想定外の利用者にも制限がかかる可能性があります。社内端末用ネットワークとゲスト用ネットワークを分離したうえで、適用範囲を決めることが重要です。
Universal Tenant Restrictionsを有効化する
TRv2ポリシーと通信経路の準備が完了したら、UTRを有効化します。
有効化を実行する管理者には、次の両方のロールが必要です。
- Global Secure Access Administrator
- Security Administrator
Microsoft Entra管理センターで、次の順に移動します。
Global Secure Access
→ Settings
→ Session Management
→ Universal Tenant Restrictions次のトグルをオンにします。
Enable Tenant Restrictions for Microsoft Entra ID and Microsoft Graphこの設定によって、Global Secure Accessを通る対象通信へTRv2の制御情報が付加され、Microsoft Entra IDとMicrosoft Graphでポリシーが評価されます。(Microsoft Learn)
UTRの有効化は、必ずTRv2ポリシーを確認してから行います。既定ポリシーが許可状態のままであれば、トグルをオンにしても未承認テナントを期待どおり遮断できません。反対に、例外登録が不十分な状態で既定拒否を適用すると、正規の取引先業務まで止まる可能性があります。
設定後に確認すべき4つのサインイン
Microsoftの公式例では、TRv2ポリシーを設定したテナント自身へのアクセスにはTenant Restrictionsが適用されず、異なるテナントのIDがサインインするときにポリシーが評価されます。(Microsoft Learn)
検証では、少なくとも次の4パターンを確認します。
| テストするアカウント | 想定結果 |
|---|---|
| 自社テナントのメンバーアカウント | TRv2は評価されず、アクセス可能 |
| 許可済み取引先テナントのアカウント | TRv2が評価され、許可範囲内ならアクセス可能 |
| 未承認テナントのアカウント | TRv2が評価され、アクセス拒否 |
| 自社テナントに作成されたB2Bゲストアカウント | 同一テナント側のアカウントとして扱われ、TRv2は評価されない |
最後のB2Bゲストは特に注意が必要です。
例えば、外部組織の利用者が自社テナント内にゲストオブジェクトとして登録され、そのゲストアカウントで自社リソースへアクセスする場合、Tenant Restrictionsによる外部テナント遮断とは異なる扱いになります。ゲスト利用者の制御には、Inbound access settingsや条件付きアクセスも併用します。
検証時のチェックポイント
サインインテストでは、次の点を確認します。
- Global Secure Accessクライアントが接続済みになっている
- Microsoft traffic profileが対象端末または拠点へ適用されている
- Entra ID関連の転送ルールがBypassになっていない
- 許可済みテナントでは必要なアプリだけ利用できる
- 未承認テナントでは認証段階で拒否される
- Global Secure Accessを通らない環境との結果の違いを確認する
- 既存セッションの影響を避けるため、別ブラウザープロファイルで試す
特に、すでに外部アカウントでサインインしているブラウザーをそのまま使うと、既存のCookieやトークンによって検証結果を判断しにくくなります。検証用プロファイルやプライベートブラウズを使い、各アカウントのセッションを分離してください。
UTRで遮断できない、または範囲が異なるアクセス
Universal Tenant Restrictionsは強力ですが、すべての外部サービス利用を制御する汎用Webフィルターではありません。
現在のMicrosoft公式情報では、Global Secure AccessによるUTRは、すべてのプラットフォームで認証プレーンを保護し、データプレーンについてはMicrosoft Graphを対象とします。Windowsのデバイス側シグナリングなど、別のTRv2適用方式とは保護範囲が異なります。(Microsoft Learn)
次のアクセスは、UTRだけでは十分に制御できない場合があります。
- Microsoft Entra IDを認証に使用しない外部サービス
- 非MicrosoftアカウントによるサードパーティーSaaSへのログイン
- 認証を必要としない匿名リンク
- 匿名参加できる外部サービス
- Global Secure Accessを経由しない通信
- 対象ルールがBypassに設定された通信
外部SaaS全般の利用制限が目的であれば、Microsoft Entra Internet AccessのWebカテゴリーフィルタリング、FQDNフィルタリング、Microsoft Defender for Cloud Apps、エンドポイント側の制御などを組み合わせる必要があります。
よくある設定ミスと対処方法
| 症状 | 主な原因 | 確認する設定 |
|---|---|---|
| 未承認テナントへアクセスできてしまう | TRv2の既定ポリシーがAllow access | Default settingsのTenant restrictions |
| 未承認テナントへアクセスできてしまう | UTRが無効 | Session ManagementのUTRトグル |
| 未承認テナントへアクセスできてしまう | 通信がGlobal Secure Accessを通っていない | クライアント、リモートネットワーク、転送プロファイル |
| 未承認テナントへアクセスできてしまう | Entra ID関連ルールがBypass | Microsoft traffic profile |
| 許可した取引先も遮断される | 組織別設定が既定値を継承している | Organizational settingsのCustomize settings |
| 一部の取引先ユーザーだけ遮断される | 外部ユーザーまたはグループの指定が不足 | External users and groups |
| 必要なアプリへアクセスできない | External applicationsの許可範囲が狭い | アプリ名またはアプリID |
| ゲストユーザーが遮断されない | 自社テナント内のB2Bゲストとしてアクセスしている | Inbound settingsと条件付きアクセス |
| 個人用Microsoftアカウントをユーザー別に制限できない | Microsoftアカウントはユーザー単位指定に非対応 | アプリ単位の許可へ変更 |
最も多いのは、取引先組織をOrganizational settingsへ追加しただけで、Tenant restrictionsをカスタマイズしていないケースです。組織を追加した直後は既定ポリシーが継承されるため、既定拒否であれば取引先も拒否されたままです。(Microsoft Learn)
許可済みテナントのEntra管理センターでAccess deniedになる場合
Universal Tenant Restrictionsを有効にした環境では、許可リストに登録した取引先テナントのMicrosoft Entra管理センターへアクセスした際に、Access deniedが表示される既知の制限があります。
Microsoftは回避策として、Entra管理センターのURLに次の機能フラグを追加する方法を案内しています。
?feature.msaljs=true&exp.msaljsexp=trueこの現象が発生した場合、すぐにTRv2ポリシーを解除するのではなく、既知の制限に該当するかを確認してください。仕様や回避策は更新される可能性があるため、適用時点のMicrosoft Learnも確認する必要があります。(Microsoft Learn)
外部テナント利用はB2Bコラボレーションへ寄せる
取引先との共同作業を許可する場合、取引先から発行された別アカウントを従業員が直接使う運用より、自社テナントへB2Bゲストとして招待する運用の方が管理しやすいケースがあります。
B2Bコラボレーションを使うと、次の制御を組み合わせられます。
- 条件付きアクセスによる多要素認証
- Inbound／Outbound access settings
- ゲストアカウントの無効化
- セッションや資格情報の管理
- サインインログによる追跡
Microsoftも、外部組織や外部アプリへのアクセスが必要な場合は、外部アカウントの直接利用をTenant Restrictionsで制限し、必要なアクセスをB2Bコラボレーションへ移す設計を案内しています。(Microsoft Learn)
ただし、取引先テナント内の管理作業など、外部アカウントを直接使用しなければならない業務もあります。その場合は、テナント全体を許可するのではなく、対象ユーザー、グループ、アプリを限定した例外ポリシーを作成します。
安全に展開するための実務チェックリスト
本番適用前に、次の項目を確認してください。
- 外部アカウントを利用している部門と業務を洗い出した
- 正規の取引先テナントIDを確認した
- 個人用Microsoftアカウントの利用目的を確認した
- 既定TRv2ポリシーを原則拒否にした
- 取引先ごとの例外ポリシーを作成した
- 外部ユーザー・グループ・アプリを必要最小限に絞った
- Microsoft traffic profileを有効化した
- Entra ID関連通信がGlobal Secure Accessを通ることを確認した
- UTRを有効化する管理者へ必要なロールを割り当てた
- 許可テナントと未承認テナントの両方でテストした
- 管理者が外部テナントを操作する手順を確認した
- 障害時に戻す設定と担当者を決めた
- 利用者向けに拒否時の問い合わせ先を案内した
Universal Tenant Restrictionsを導入するときは、最初から全端末・全拠点へ展開するのではなく、限定した端末でTRv2ポリシーと通信経路を検証するのが安全です。
まず外部テナントの利用実態を棚卸しし、既定拒否、取引先ごとの最小限の許可、Global Secure Accessによる適用の順に構成してください。UTRのトグルをオンにすることよりも、事前の例外設計と適用範囲の確認が、業務停止と情報持ち出しの両方を防ぐポイントです。
コメント