Microsoft Entraのテナント制限で最初に押さえるべき結論は、SaaSアプリを「許可アプリか禁止アプリか」だけで管理するのではなく、どのMicrosoft EntraテナントのIDでアクセスしてよいかを制御できる点です。たとえば、社内ネットワークからMicrosoft 365は使わせたいが、個人用アカウントや未承認の外部テナントにあるOutlook、SharePoint、Teams、その他SaaSにはアクセスさせたくない、という場面で役立ちます。
管理者が確認すべきポイントは大きく3つです。既存のテナント制限v1を使っている場合は許可テナントの棚卸しとv2移行計画、これから導入する場合はGlobal Secure Access・プロキシ・Windows管理デバイスのどれで適用するかの判断、そして展開前のテストとサインインログ監視です。Microsoft Learnで確認できる対象情報では、従来の「Use tenant restrictions to manage access to SaaS apps」はテナント許可リストとプロキシによるヘッダー挿入を中心に説明され、関連するtenant restrictions v2ではクロステナントアクセス設定、認証プレーン保護、データプレーン保護、Global Secure Accessとの連携が整理されています。(Microsoft Learn)
なお、Microsoft Learn上で確認できる対象ページの最終更新日はページごとに異なります。旧来の「Use tenant restrictions to manage access to SaaS apps」は2024年11月29日、tenant restrictions v2構成ページは2026年3月20日、Universal Tenant Restrictions関連ページは2026年4月4日と表示されています。公開・更新日だけで判断せず、自社が利用している方式がv1なのかv2なのか、また一部機能がプレビュー扱いかどうかを確認してから展開することが重要です。(Microsoft Learn)
Microsoft Entraのテナント制限とは
Microsoft Entraのテナント制限は、ユーザーが社内ネットワークや管理対象デバイスからSaaSクラウドアプリへアクセスする際、Microsoft Entra IDのテナント情報をもとにアクセス先を制御する仕組みです。
従来のネットワーク制御では、ドメイン名やIPアドレスをブロックする方法がよく使われます。しかしMicrosoft 365のようなSaaSでは、outlook.office.comやlogin.microsoftonline.comのような共通ドメインが使われます。そのため、ドメイン単位で遮断すると業務で必要なOutlook on the webまで使えなくなる一方、「自社テナントは許可し、未承認テナントだけ拒否する」といった細かな制御は難しくなります。(Microsoft Learn)
テナント制限は、この問題を「アクセス先のテナント」で解決します。自社が許可したMicrosoft Entraテナントだけにトークン発行やアクセスを許可し、それ以外のテナントはブロックします。ユーザーがその外部テナントのゲストであっても、許可リストに含まれていなければ制限対象になります。(Microsoft Learn)
よくある利用シーン
テナント制限が特に有効なのは、次のようなケースです。
| 利用シーン | 具体例 | テナント制限で防ぎたいこと |
|---|---|---|
| 個人アカウント利用の抑止 | 個人用OneDriveや個人のMicrosoftアカウントで業務端末からサインインする | 業務データの個人領域への持ち出し |
| 未承認テナントへのアクセス制御 | 社員が外部企業から付与された別テナントのアカウントでSaaSを使う | IT部門が把握していない外部環境へのデータ移動 |
| Microsoft 365のテナント分離 | 自社Microsoft 365は許可し、他社Microsoft 365は拒否する | 同じアプリ名でも別テナントへのアクセスを制限 |
| B2B連携の整理 | 取引先テナントだけ許可し、それ以外は拒否する | コラボレーション先の無秩序な拡大 |
単純なURLブロックでは「Microsoft 365を使わせるか、使わせないか」になりがちです。テナント制限を使うと、同じMicrosoft 365でも「自社テナントは許可、個人や未承認の外部テナントは拒否」という現実的な制御ができます。
Microsoft Entraのセキュリティ更新で管理者が見るべき変更点
管理者が特に注意すべき変更点は、従来のtenant restrictions v1からtenant restrictions v2へ、管理の中心がネットワークプロキシ上の許可リストからMicrosoft Entra側のクラウドポリシーへ移っている点です。v1では、プロキシがRestrict-Access-To-TenantsなどのHTTPヘッダーを挿入し、許可されたテナントだけを通す仕組みでした。一方v2では、クロステナントアクセス設定にテナント制限ポリシーを作成し、sec-Restrict-Tenant-Access-PolicyヘッダーなどでポリシーIDを伝える形になります。(Microsoft Learn)
| 比較項目 | tenant restrictions v1 | tenant restrictions v2 |
|---|---|---|
| ポリシー管理 | プロキシ側のヘッダーに許可テナント一覧を記述 | Microsoft Entraのクロステナントアクセス設定でクラウドポリシーを管理 |
| 制御単位 | 主にテナント単位、Microsoftアカウント単位 | テナント、ユーザー、グループ、アプリ単位でより細かく制御 |
| 管理UI | Microsoft Entra管理センター上のポリシーUIは限定的 | Microsoft Entra管理センターで設定可能 |
| プロキシ依存 | 基本的にプロキシによるTLS検査とヘッダー挿入が必要 | Global Secure Access、プロキシ、Windows管理デバイスなど複数の適用方法 |
| 保護範囲 | 主に認証プレーン | 認証プレーンに加え、一部シナリオでデータプレーン保護も提供 |
| 匿名アクセス対策 | Teams会議や匿名共有リンクは残りやすい | Teams、Forms、SharePoint、OneDriveなどで匿名アクセス保護が拡張。ただし一部はプレビュー |
| 移行時の注意 | 許可リストがプロキシヘッダー長に依存 | 許可テナントごとにパートナーポリシーを作成し、旧ヘッダーを整理 |
v2の重要な改善点は、「許可テナントをまとめてヘッダーに詰め込む」方式から、「Microsoft Entra側にポリシーを持たせ、ネットワークや端末からそのポリシーを参照させる」方式へ変わることです。これにより、許可テナントが増えたときのヘッダー長の問題を避けやすくなり、特定ユーザーや特定アプリだけを許可するような運用もしやすくなります。(Microsoft Learn)
影響範囲：どのユーザー、アプリ、端末が確認対象になるか
テナント制限は、Microsoft Entra IDでシングルサインオンするSaaSアプリ全般に関係します。公式ドキュメントではMicrosoft 365を中心に説明されていますが、Microsoft Entra IDへ認証をリダイレクトするSaaSアプリも対象になり得ます。自社のMicrosoft 365とは別のMicrosoft Entraテナントで運用されているSaaSや、B2Bコラボレーションで利用している外部テナントがある場合は、許可対象として漏れなく整理する必要があります。(Microsoft Learn)
| 確認対象 | 影響の見方 | 管理者が確認すべきこと |
|---|---|---|
| 社員ユーザー | 外部テナントや個人アカウントでのサインインが制限される | 業務上必要な外部テナントを洗い出す |
| ゲスト・委託先 | 自社ネットワーク上で外部IDを使う場面が影響を受ける | B2B Collaborationで代替できるか確認する |
| Microsoft 365 | Outlook、SharePoint、Teams、OneDriveなどが影響を受ける | 自社テナント以外へのアクセス要件を確認する |
| Microsoftアカウント | 個人用OneDrive、Hotmail、Xbox.comなどの利用抑止に関係する | 個人アカウントで許可するアプリを最小限にする |
| Teams会議 | 外部主催会議や匿名参加に影響が出る可能性がある | Teamsのフェデレーション制御と合わせて検証する |
| SharePoint・OneDrive匿名リンク | v2のデータプレーン保護でブロック対象になる場合がある | 匿名共有リンクを業務で使っていないか確認する |
| サービスプリンシパル | v2でブロックされるケースがある | 自動化・連携処理のテナントとログを確認する |
| macOS・モバイル | TLS検査や証明書信頼の制約を受けやすい | Platform SSO、Global Secure Access、プロキシ方式の相性を確認する |
v2では、認証時のブロックだけでなく、盗まれたトークンや匿名アクセスを使った回避にも対処する方向へ広がっています。ただし、すべてのアプリ・すべての端末・すべてのアクセス形態を完全にカバーするわけではありません。たとえば、コンシューマー向けOneDriveの一部URL、Microsoft Entra ID以外のアカウントで使うサードパーティアプリ、別端末から取得したトークンをサードパーティアプリで使うケースなどは、別の対策が必要になる場合があります。(Microsoft Learn)
管理者が最初に確認すべき設定
Microsoft Entraのテナント制限を導入・見直しする前に、まず「誰に、どのテナントを、どのアプリで、どの経路から許可するか」を整理します。ここを曖昧にしたまま全社展開すると、取引先との共有、外部研修、委託先作業、管理ポータルへのアクセスが突然失敗する可能性があります。
前提条件と権限
tenant restrictions v1を使う場合、プロキシにはTLS検査、HTTPヘッダー挿入、FQDNまたはURLによる宛先フィルタリングが必要です。また、クライアントはプロキシが提示する証明書チェーンを信頼している必要があります。v1の利用にはMicrosoft Entra ID P1またはP2ライセンスが必要とされています。(Microsoft Learn)
tenant restrictions v2では、Microsoft Entra ID P1またはP2、テナント制限ポリシーを構成できるSecurity Administrator以上のロール、Windows GPOを使う場合は最新更新が適用されたWindows 10またはWindows 11デバイスが前提として示されています。(Microsoft Learn)
| 確認項目 | v1中心の環境 | v2中心の環境 |
|---|---|---|
| ライセンス | Microsoft Entra ID P1/P2 | Microsoft Entra ID P1/P2 |
| 主な管理場所 | プロキシ設定 | Microsoft Entra管理センターのクロステナントアクセス設定 |
| 必要なネットワーク機能 | TLS検査、ヘッダー挿入、宛先フィルタリング | 適用方式によりGlobal Secure Access、プロキシ、Windows GPO |
| 主な管理ロール | Entra管理とプロキシ管理の両方 | Security Administrator、必要に応じてGlobal Secure Access Administrator |
| ログ確認 | Microsoft Entraサインインログ、テナント制限レポート | サインインログ、監査ログ、クロステナントアクセス関連の監視 |
v1で使う主なヘッダー
tenant restrictions v1では、プロキシがMicrosoft Entra IDへの認証トラフィックに次のようなヘッダーを挿入します。
Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee
Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffffRestrict-Access-To-Tenantsには許可するテナントのドメイン名またはディレクトリIDをカンマ区切りで指定します。空白を入れない点に注意が必要です。Restrict-Access-Contextには、制限ポリシーを設定している自社テナントのディレクトリIDを指定します。誤ったディレクトリIDを使うと、サインインログが自社テナントに期待通り表示されない可能性があります。(Microsoft Learn)
Microsoftコンシューマーアプリをブロックする場合は、login.live.comへの通信に次のヘッダーを使います。
sec-Restrict-Tenant-Access-Policy: restrict-msaただし、v2へ移行する場合、このv1用のrestrict-msaヘッダーは新しい設定と競合する可能性があるため、プロキシ側から削除する必要があります。(Microsoft Learn)
v2で使う主なヘッダー
tenant restrictions v2をプロキシ経由で適用する場合、ヘッダーは許可テナント一覧ではなく、自社テナントIDとクロステナントアクセスポリシーIDを指定します。
sec-Restrict-Tenant-Access-Policy: <TenantId>:<PolicyGuid>この方式では、ポリシーの実体はMicrosoft Entra側にあります。プロキシは「どのポリシーを適用するか」を示す信号を送る役割になります。プロキシから送信する対象のサインインドメインとして、login.live.com、login.microsoft.com、login.microsoftonline.com、login.windows.netが示されています。(Microsoft Learn)
v1を使っている管理者向け：v2移行の進め方
既存のtenant restrictions v1を運用している場合、いきなり全社でv2へ切り替えるのは避けるべきです。v2への移行は一回限りの作業として計画できますが、ネットワークチームとID管理チームの連携が必須です。公式の移行ガイダンスでも、現在プロキシが挿入しているヘッダー文字列を取得し、不要なテナントIDや許可先を評価したうえで、新しいポリシーへ反映する流れが示されています。(GitHub)
移行手順の実務チェック
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | v1のRestrict-Access-To-Tenantsに含まれるテナントを一覧化する | 古い取引先、検証用テナント、退職者向け例外が残っている |
| 要件整理 | 外部テナントごとに、許可するユーザー・グループ・アプリを決める | テナント単位で広く許可しすぎる |
| v2ポリシー作成 | クロステナントアクセス設定で既定ポリシーとパートナーポリシーを作る | 既定ブロックとパートナー許可の関係を誤る |
| Microsoftアカウント対応 | 必要なMicrosoftアカウント利用だけアプリ単位で許可する | Microsoft Learnなど業務上必要な個人アカウント利用まで止める |
| プロキシ更新 | v2用ヘッダーへ切り替え、v1ヘッダーを削除する | restrict-msaを残して競合させる |
| 段階展開 | テストユーザー、テストプロキシ、部署単位で順次展開する | 全社一括で切り替え、原因切り分けが難しくなる |
| 監視 | サインインログ、監査ログ、クロステナントアクセス状況を確認する | ブロックが正常なのか障害なのか判断できない |
移行時に特に重要なのは、v1の許可リストをそのままv2へ機械的に移さないことです。v2ではユーザー、グループ、アプリ単位で絞れるため、「全社員が取引先テナントの全アプリを使える」状態を見直すよい機会になります。たとえば、営業部だけが取引先のSharePointにアクセスできればよい場合、全ユーザー・全アプリ許可ではなく、対象グループと必要なアプリに限定します。
また、v2ポリシーを構成しても、プロキシやGlobal Secure Access、Windows GPOなどで信号を送らなければ期待通りに適用されません。ポリシー作成と適用経路の有効化は別作業として管理してください。(Microsoft Learn)
新規導入時はどの適用方式を選ぶべきか
tenant restrictions v2には、主に3つの適用方式があります。どれが最適かは、端末管理の状況、既存プロキシの有無、リモートワーク比率、Microsoft Entra Global Secure Accessの導入状況で変わります。
| 適用方式 | 向いている環境 | 主なメリット | 注意点 |
|---|---|---|---|
| Universal Tenant Restrictions with Global Secure Access | リモートワーク、複数OS、拠点ネットワークをまとめて制御したい環境 | OS、ブラウザ、デバイス形態に依存しにくく、プロキシ運用を軽くできる | Global Secure Accessのライセンス、クライアント、リモートネットワーク設定が必要 |
| Corporate proxy | 既にTLS検査対応プロキシを運用している環境 | 既存ネットワーク境界で認証プレーン保護を適用しやすい | データプレーン保護は限定的。証明書信頼、除外設定、TLS検査の影響に注意 |
| Windows managed devices | Windows中心で端末管理が整っている環境 | プロキシなしでWindowsデバイスにポリシー信号を持たせられる | Microsoft Edge中心の保護になりやすく、Chrome、Firefox、.NETアプリには追加対策が必要 |
Universal Tenant Restrictionsは、Global Secure Accessを使ってMicrosoft Entra IDやMicrosoft Graphなどの通信にtenant restrictions v2のポリシー情報を付与する方式です。管理者がプロキシ設定を細かく管理しなくても、Global Secure Accessクライアントやリモートネットワーク経由で適用できる点が特徴です。(Microsoft Learn)
Global Secure Accessを利用する場合は、Microsoftトラフィックプロファイルの有効化、Global Secure Accessクライアントまたはリモートネットワーク接続の展開、必要ロールとライセンスの確認が前提になります。Microsoft Entra Internet Access for Microsoft servicesにはUniversal Tenant Restrictionsが含まれることも、ライセンス検討時に確認しておきたい点です。(Microsoft Learn)
展開前に確認したい注意点
テナント制限はセキュリティ効果が高い一方、認証経路に関わるため、設定ミスの影響が大きい機能です。特に次の点は展開前に必ず確認してください。
プロキシ設定でサブドメインを広く含めすぎない
v1のプロキシ設定では、*.login.microsoftonline.comのように広くサブドメインを含めると、device.login.microsoftonline.comが巻き込まれ、デバイス登録やデバイスベースの条件付きアクセスで使われるクライアント証明書認証に影響する可能性があります。公式ドキュメントでは、device.login.microsoftonline.comとenterpriseregistration.windows.netをTLS break-and-inspectおよびヘッダー挿入から除外するよう注意が示されています。(Microsoft Learn)
モダン認証とレガシー認証の状態を確認する
Microsoft 365でテナント制限を十分に機能させるには、クライアントがモダン認証をサポートし、クラウドサービス側でもモダン認証が既定になっている必要があります。OutlookやSkype for Businessなどのクライアントがレガシープロトコルを使える状態だと、テナント制限を回避する経路が残る可能性があります。(Microsoft Learn)
実務では、テナント制限だけでなく、レガシー認証のブロック、条件付きアクセス、アプリ保護ポリシー、監査ログを組み合わせて確認します。「テナント制限を入れたから外部アクセスは完全に止まる」と考えるのではなく、認証方式ごとに抜け道が残っていないかを見るべきです。
Apple Platform SSOや証明書信頼の制約を確認する
macOS、iOS、iPadOSでMicrosoft Enterprise SSO plug-inやPlatform SSOを使っている環境では、プロキシによるヘッダー挿入と証明書信頼チェーンの相性に注意が必要です。公式情報では、企業プロキシがAppleシステムルート証明書以外の証明書チェーンを使う場合、macOS Platform SSOとtenant restrictions v2のクライアントシグナリングが動作しない制約が示されています。この場合は、Global Secure AccessによるUniversal Tenant Restrictionsの利用が選択肢になります。(Microsoft Learn)
Teams、SharePoint、OneDriveの匿名アクセスをテストする
tenant restrictions v2では、Teams会議、SharePoint、OneDrive、Formsなどの匿名アクセスやデータプレーン保護が重要な論点になります。ただし、Teamsではフェデレーション制御との組み合わせが必要な場面があり、OneDriveのコンシューマーアカウント向けURLはv2のスコープ外となるケースがあります。公式ドキュメントでは、コンシューマーOneDriveについてはネットワーク側でonedrive.live.comをブロックする回避策が示されています。(Microsoft Learn)
特に注意したいのは、業務部門が「誰でもリンク」を日常的に使っている場合です。セキュリティ上は望ましくないことが多いものの、現場では外部共有の暫定手段として使われていることがあります。テナント制限の展開前に、匿名共有リンクの利用状況をSharePoint管理センターや監査ログで確認しておくと、問い合わせを減らせます。
開発者・アプリ担当者が確認すべきポイント
Microsoft Entraのテナント制限は、インフラ管理者だけの機能ではありません。SaaS連携、社内アプリ、Microsoft Graph連携、自動化スクリプトを扱う開発者にも影響します。
マルチテナントアプリのサインイン先を確認する
自社アプリがMicrosoft Entra IDを使って外部テナントのユーザーを受け入れている場合、テナント制限によって外部アカウントのサインインがブロックされることがあります。開発者は、次の観点で確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| アプリ登録 | シングルテナントかマルチテナントか |
| サインインエンドポイント | common、organizations、特定テナントIDのどれを使っているか |
| 利用者 | 社員、ゲスト、取引先、委託先、個人Microsoftアカウントのどれが対象か |
| 必要な外部テナント | 許可ポリシーに含める必要があるか |
| エラー処理 | アクセス拒否時にユーザーへ適切な案内を出せるか |
テナント制限でブロックされた場合、ユーザーには「IT部門によってアクセスできる組織が制限されている」趣旨のエラーが表示されることがあります。アプリ側で独自のエラー処理をしている場合は、Microsoft Entra IDから返るエラーを握りつぶさず、管理者に必要な情報が残るようにしてください。(Microsoft Learn)
サービスプリンシパルや自動化処理を見落とさない
tenant restrictions v2はサービスプリンシパルのアクセスにも影響する場合があります。公式ドキュメントでは、サービスプリンシパルによるMicrosoft Graph接続がテナント制限ポリシーで拒否される例が示されています。また、サービスプリンシパルのサインインがブロックされた場合、ログの出方が通常のユーザーサインインと異なる点にも注意が必要です。(Microsoft Learn)
開発・運用チームは、次のような処理を棚卸ししてください。
| 対象 | 例 | 確認ポイント |
|---|---|---|
| Microsoft Graph連携 | ユーザー一覧取得、監査ログ取得、Teams連携 | どのテナントIDへ接続しているか |
| CI/CD | デプロイスクリプト、管理API呼び出し | サービスプリンシパルのホームテナントとリソーステナント |
| RPA・自動化 | PowerShell、管理スクリプト | Chromeや.NETアプリ制限、Windows Firewall設定の影響 |
| 外部SaaS連携 | SSO、SCIM、API連携 | 外部テナントを許可ポリシーに含める必要があるか |
Microsoft Graph APIを使ってクロステナントアクセスポリシー情報を取得・更新する方法も公式に示されていますが、該当APIはbetaエンドポイントとして記載されている箇所があります。運用自動化に組み込む場合は、APIバージョン、権限、変更影響を確認してから利用してください。(Microsoft Learn)
テスト計画：本番展開前に試すべきシナリオ
テナント制限のテストは、「許可されるべきものが通るか」と「拒否されるべきものが止まるか」の両方を確認します。片方だけ確認しても、本番展開後に業務停止や抜け道が発生します。
| テスト項目 | 期待結果 | 確認方法 |
|---|---|---|
| 自社テナントのMicrosoft 365へアクセス | 許可される | 通常ブラウザ、Officeクライアント、モバイルで確認 |
| 許可済み取引先テナントへアクセス | 許可される | 対象ユーザー・対象アプリだけ通るか確認 |
| 未承認外部テナントへアクセス | ブロックされる | InPrivate/シークレットウィンドウで外部IDサインインを試す |
| 個人Microsoftアカウントでアクセス | 方針どおり許可または拒否 | Microsoft Learnなど例外アプリがある場合は個別確認 |
| Teams外部会議へ匿名参加 | 方針どおり制御される | Teamsフェデレーション制御と組み合わせて確認 |
| SharePoint/OneDrive匿名リンク | 方針どおり制御される | 自社テナントと外部テナントのリンクで比較 |
| Microsoft Graphトークン利用 | 不正な外部テナント利用がブロックされる | Graph Explorerや検証用スクリプトで確認 |
| サインインログ・監査ログ | ブロック理由が追える | Microsoft Entra管理センターでログを確認 |
Universal Tenant Restrictionsでは、Global Secure Accessのシグナリングをオフにした状態とオンにした状態を比較し、未承認外部テナントでのMy AppsポータルやGraph Explorerへのアクセスがブロックされるかを検証する手順が示されています。応答ヘッダーや302ステータス、診断ヘッダーを確認することで、ポリシーが適用されたかを技術的に確認できます。(Microsoft Learn)
本番展開では、最初から全社適用するのではなく、テストユーザー、テスト部署、特定プロキシ、特定拠点の順に範囲を広げます。公式移行ガイダンスでも、プロキシ単位またはユーザー・グループ単位で段階的にヘッダーを更新し、問題がないことを確認しながら展開する方法が推奨されています。(GitHub)
条件付きアクセスやB2B Collaborationとの使い分け
テナント制限は、条件付きアクセスやクロステナントアクセス設定の送信・受信制御と役割が異なります。ここを混同すると、ポリシーを重複させたり、逆に抜け道を残したりします。
公式ドキュメントでは、受信設定は外部アカウントが自社アプリへアクセスする制御、送信設定は自社アカウントが外部アプリへアクセスする制御、テナント制限は外部アカウントが外部アプリへアクセスする制御、と整理されています。つまり、テナント制限は「社員が外部から付与された別アカウントを使い、自社管理下の端末やネットワークから外部テナントへデータを出す」ようなシナリオに効きます。(Microsoft Learn)
| 機能 | 主に制御するもの | 使うべき場面 |
|---|---|---|
| 条件付きアクセス | 誰が、どの条件で、自社リソースへアクセスできるか | MFA、準拠デバイス、場所、リスクで制御したい |
| クロステナント受信設定 | 外部ユーザーが自社テナントへ入る条件 | 取引先やゲストの受け入れを管理したい |
| クロステナント送信設定 | 自社ユーザーが外部テナントへ行く条件 | 社員の外部B2Bアクセスを制御したい |
| テナント制限 | 外部アカウントで外部アプリへアクセスする行為 | 個人・未承認外部テナントへのデータ持ち出しを防ぎたい |
| B2B Collaboration | 外部ユーザーを自社管理下で招待・制御する仕組み | 外部組織との正規コラボレーションを管理したい |
外部組織との業務連携が必要な場合は、ユーザーに外部テナントのアカウントを使わせるより、B2B Collaborationで自社側の管理下に招待する方が監査や条件付きアクセスを適用しやすくなります。テナント制限は、正規のB2B連携へ誘導するためのガードレールとして考えると運用しやすくなります。(Microsoft Learn)
失敗しやすいポイントと対策
許可テナントを広げすぎる
「業務で必要かもしれない」という理由で外部テナント全体を許可すると、テナント制限の効果が弱くなります。v2ではアプリ単位・ユーザー単位で絞れるため、原則は「必要なユーザーが、必要なアプリだけ使える」設計にします。
例外管理を台帳化しない
テナント制限の例外は、後から増えやすい設定です。例外を追加するたびに、申請者、業務理由、対象テナントID、対象アプリ、対象グループ、有効期限、承認者を記録してください。期限のない例外は、数か月後には誰も理由を説明できない穴になります。
ブロックされた問い合わせに備えない
展開直後は、「取引先のTeams会議に入れない」「個人アカウントでMicrosoft Learnにアクセスできない」「外部SharePointのリンクが開けない」といった問い合わせが発生しやすくなります。ヘルプデスクには、エラー画面、サインインログの確認手順、例外申請フローを事前に共有しておきます。
テストをブラウザだけで終える
Outlook、Teams、Officeデスクトップアプリ、PowerShell、Graph連携、モバイルアプリでは挙動が異なる場合があります。特にv1環境ではモダン認証とレガシー認証の状態、v2のWindows GPO環境ではChrome、Firefox、.NETアプリの扱いを必ず確認します。v2のWindows管理デバイス方式では、保護されないアプリへの対策としてApp Control for BusinessやWindows Firewallの利用が示されています。(Microsoft Learn)
管理者が次に取るべき行動
Microsoft Entraのテナント制限を検討している管理者は、まず次の順番で確認してください。
| 優先度 | やること | 成果物 |
|---|---|---|
| 高 | 現在の外部テナント利用を棚卸しする | 許可テナント・禁止テナント一覧 |
| 高 | v1利用中か、v2利用中か、未導入かを判定する | 現行構成図、プロキシヘッダー一覧 |
| 高 | 業務上必要な外部連携をB2B Collaborationへ寄せられるか確認する | 例外削減方針 |
| 中 | Global Secure Access、プロキシ、Windows GPOの適用方式を選ぶ | 展開方式の比較表 |
| 中 | テストユーザーと検証シナリオを決める | テスト計画書 |
| 中 | サインインログ、監査ログ、問い合わせフローを整備する | 運用手順書 |
| 低 | 不要な例外、古い取引先、検証用テナントを削除する | 定期レビュー台帳 |
テナント制限は、設定すれば終わりの機能ではありません。SaaS利用、取引先連携、Microsoft 365の共有設定、端末管理、Global Secure Accessの導入状況に合わせて定期的に見直す必要があります。まずは現行の許可テナントと外部アカウント利用を洗い出し、v1環境であればv2移行を段階展開で計画しましょう。新規導入の場合は、プロキシ方式だけでなくGlobal Secure AccessやWindows管理デバイス方式も比較し、自社の働き方に合う適用方法を選ぶことが重要です。
コメント