テナントへのアクセスを制限する

[アーティクル]
12/19/2023

セキュリティを重視する大規模な組織は、Microsoft 365 などのクラウドサービスへの移行を望んでいますが、ユーザーが承認済みリソースにしかアクセスできないことを認識しておく必要があります。従来より、企業ではアクセスを管理するときにドメイン名や IP アドレスを制限しています。このアプローチは、パブリッククラウドでホストされ、outlook.office.com や login.microsoftonline.com などのドメイン名で実行される、サービスとしてのソフトウェア (SaaS) アプリの場合はうまくいきません。これらのアドレスをブロックすると、ユーザーを承認済みの ID やリソースに単に制限するのではなく、ユーザーは Web 上の Outlook にまったくアクセスできなくなります。

この課題を解決する Microsoft Entra ソリューションが、テナント制限と呼ばれる機能です。テナント制限を使用すると、組織は、アプリケーションがシングルサインオンに使用する Microsoft Entra テナントに基づいて SaaS クラウドアプリケーションへのアクセスをコントロールできます。たとえば、自分の組織の Microsoft 365 アプリケーションへのアクセスは許可し、これらの同じアプリケーションの他の組織のインスタンスにはアクセスできないようにすることが可能です。

テナント制限では、組織はネットワーク上のユーザーがアクセスを許可されているテナントの一覧を指定できます。その後、Microsoft Entra ID は、これらの許可されたテナントへのアクセスのみを許可します。他のテナントは、組織のユーザーがゲストである可能性があるものも含めて、すべてブロックされます。

この記事では Microsoft 365 のテナント制限に重点を置いて取り上げますが、この機能は、シングルサインオンのためにユーザーを Microsoft Entra ID に送信するすべてのアプリを保護するものです。 Microsoft 365 で使用されるテナントとは異なる Microsoft Entra テナントで SaaS アプリを使用する場合は、必要なすべてのテナントのアクセスが許可されていることをご確認ください。 (たとえば、B2B Collaboration のシナリオ)。 SaaS クラウドアプリの詳細については、Active Directory Marketplace をご覧ください。

テナント制限機能では、OneDrive、Hotmail、Xbox.com など、すべての Microsoft コンシューマーアプリケーション (MSA アプリ) の使用をブロックすることもできます。この機能は、login.live.com エンドポイントに対して別のヘッダーを使用します。これについては、当アーティクルの最後で詳細に説明します。

しくみ

全体的なソリューションは、次のコンポーネントで構成されます。

Microsoft Entra ID: Restrict-Access-To-Tenants: <permitted tenant list> ヘッダーが存在する場合、Microsoft Entra は許可されたテナントに対してのみセキュリティトークンを発行します。
オンプレミスのプロキシサーバーインフラストラクチャ: このインフラストラクチャは、トランスポート層セキュリティ (TLS) 検査に対応したプロキシデバイスです。このプロキシは、許可されているテナントのリストを含むヘッダーを Microsoft Entra ID 宛てのトラフィックに挿入するように構成する必要があります。
クライアントソフトウェア: テナント制限をサポートするには、プロキシインフラストラクチャがトラフィックをインターセプトできるように、クライアントソフトウェアはトークンを直接 Microsoft Entra ID に要求する必要があります。先進認証 (OAuth 2.0 など) を使用する Office クライアントと同様に、ブラウザーベースの Microsoft 365 アプリケーションは現在、テナント制限をサポートしています。
先進認証: テナント制限を使用し、許可されていないすべてのテナントへのアクセスをブロックするには、クラウドサービスは先進認証を使用する必要があります。既定で先進認証プロトコルを使用するように Microsoft 365 クラウドサービスを構成する必要があります。 Microsoft 365 による最新の認証のサポートに関する最新情報については、Office 365 の最新の認証の更新に関するページをご覧ください。

次の図は、おおまかなトラフィックフローを示しています。テナント制限では、TLS インスペクションは Microsoft 365 クラウドサービスへのトラフィックではなく、Microsoft Entra ID へのトラフィックでのみ必要です。 Microsoft Entra ID への認証のためのトラフィック量は一般に、Exchange Online や SharePoint Online などの SaaS アプリケーションへのトラフィック量よりはるかに少ないため、この特質は重要です。

テナント制限のトラフィックフロー図。

テナント制限を設定する

テナント制限の使用を開始するための手順は 2 つあります。最初に、クライアントが適切なアドレスに接続できることを確認します。 2 つ目に、プロキシインフラストラクチャを構成します。

URL と IP アドレス

テナント制限を使用するには、認証のために、クライアントは次の Microsoft Entra URL に接続できる必要があります。

さらに、Office 365 にアクセスするために、クライアントは「Office 365 の URL と IP アドレスの範囲」で定義されている完全修飾ドメイン名 (FQDN)、URL、および IP アドレスにも接続できる必要があります。

プロキシの構成と要件

プロキシインフラストラクチャを使用したテナント制限を有効にするには、次の構成が必要です。このガイダンスは一般的なものであるため、具体的な実装手順については、プロキシベンダーのドキュメントを参照してください。

前提条件

プロキシは、TLS インターセプト、HTTP ヘッダーの挿入、FQDN/URL を使用した送信先のフィルター処理を実行できる必要があります。
クライアントは、TLS 通信でプロキシによって提示される証明書チェーンを信頼する必要があります。たとえば、内部公開キーインフラストラクチャ (PKI) からの証明書が使用されている場合は、内部発行のルート証明機関証明書を信頼する必要があります。
テナント制限の使用には、Microsoft Entra ID の P1 または P2 のライセンスが必要です。

構成

login.microsoftonline.com、login.microsoft.com、login.windows.net へのそれぞれの送信要求に対して、Restrict-Access-To-Tenants と Restrict-Access-Context の 2 つの HTTP ヘッダーが挿入されます。

注意

*.login.microsoftonline.com の下のサブドメインをプロキシの構成に含めないでください。すると、device.login.microsoftonline.com が含まれ、デバイス登録とデバイスベースの条件付きアクセスで使用されるクライアント証明書の認証が妨げられます。 device.login.microsoftonline.com と enterpriseregistration.windows.net を TLS の中断と検査、およびヘッダーの挿入から除外するようにプロキシサーバーを構成します。

これらのヘッダーには、次の要素を含める必要があります。

Restrict-Access-To-Tenants には、ユーザーにアクセスを許可するテナントのコンマ区切りリストである、<許可されているテナントのリスト>の値を使用します。テナントに登録されているドメインを使用して、このリストのテナントとディレクトリ ID 自体を識別できます。テナントを記述する 3 つのすべての方法の例として、Contoso、Fabrikam、および Microsoft を許可する名前と値のペアは、Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee のようになります。
Restrict-Access-Context には、どのテナントでテナント制限を設定するかを宣言している、1 つのディレクトリ ID の値を使用します。たとえば、テナント制限ポリシーを設定するテナントとして Contoso を宣言するには、名前と値のペアは Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff のようになります。これらの認証のログを取得するには、ここで独自のディレクトリ ID を使用する必要があります。独自のディレクトリ ID 以外の ID を使用する場合、サインインログは他のユーザーのテナントに表示 "され"、すべての個人情報が削除されます。詳細については、管理者向けエクスペリエンスに関する記事を参照してください。

ディレクトリ ID を見つけるには:

Microsoft Entra 管理センターにグローバル閲覧者以上としてサインインします。
[ID]>[概要]>[概要] を参照します。
[テナント ID] 値をコピーします。

ディレクトリ ID またはドメイン名が同じテナントを参照していることを検証するには、URL https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration で <tenant> の代わりにその ID またはドメインを使用します。ドメインと ID の結果が同じであれば、同じテナントを参照しています。

未承認のテナントを含む独自の HTTP ヘッダーをユーザーが挿入できないようにするため、受信要求に Restrict-Access-To-Tenants ヘッダーが既に存在する場合、プロキシはそのヘッダーを置き換える必要があります。

login.microsoftonline.com、login.microsoft.com、login.windows.net へのすべての要求にプロキシを使用するよう、クライアントに強制する必要があります。たとえば、クライアントにプロキシの使用を指示するために PAC ファイルが使用されている場合は、エンドユーザーがその PAC ファイルを編集したり無効にしたりできないようにする必要があります。

ユーザーエクスペリエンス

このセクションでは、エンドユーザーと管理者の両方のエクスペリエンスについて説明します。

エンドユーザーエクスペリエンス

たとえば、Contoso ネットワーク上のユーザーが、Outlook Online などの共有 SaaS アプリケーションの Fabrikam インスタンスにアクセスしようとしているとします。 Fabrikam が Contoso インスタンスに対して許可されていないテナントである場合、ユーザーにはアクセス拒否メッセージが表示されます。拒否メッセージには、IT 部門によって承認されていない組織に属するリソースにアクセスしようとしていることが表示されています。

テナント制限エラーメッセージ (2021 年 4 月以降) のスクリーンショット。

管理者エクスペリエンス

テナント制限の構成は企業プロキシインフラストラクチャで行われますが、管理者は、Microsoft Entra 管理センターで直接テナント制限レポートにアクセスできます。レポートを表示するには、次の操作を行います。

Microsoft Entra 管理センターにグローバル閲覧者以上としてサインインします。
[ID]>[概要]>[テナント制限] を参照します。

Restricted-Access-Context テナントとして指定されたテナントの管理者は、このレポートを使用して、テナント制限ポリシーのためにブロックされたサインイン (使用された ID やターゲットディレクトリ ID を含む) を確認できます。制限を設定するテナントがサインインのユーザーテナントまたはリソーステナントのいずれかである場合は、サインインが含まれます。

Restricted-Access-Context テナント以外のテナントに属するユーザーがサインインする場合、ターゲットディレクトリ ID などの限られた情報がレポートに含まれる可能性があります。この場合、名前やユーザープリンシパル名などのユーザー識別情報はマスクされ、他のテナントのユーザーデータは保護されます (例: 必要に応じて、ユーザー名とオブジェクト ID の代わりに "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000)。

Microsoft Entra 管理センターの他のレポートと同様に、フィルターを使用してレポートの範囲を指定できます。特定の時間間隔、ユーザー、アプリケーション、クライアント、または状態についてフィルター処理できます。 [列] ボタンを選択すると、次のフィールドの任意の組み合わせでデータを表示することを選択できます。

ユーザー - このフィールドでは、個人データを削除して値を 00000000-0000-0000-0000-000000000000 を設定できます。
Application
状態
日付
日付 (UTC) - UTC は協定世界時
IP アドレス
クライアント
ユーザー名 - このフィールドでは、個人データを削除して値を {PII Removed}@domain.com を設定できます
場所
ターゲットテナント ID

Microsoft 365 サポート

テナント制限を完全にサポートするには、Microsoft 365 アプリケーションは次の 2 つの条件を満たす必要があります。

使用されるクライアントが先進認証をサポートしている。
クラウドサービスの既定の認証プロトコルとして最新の認証が有効になっている。

先進認証を現在サポートしている Office クライアントの最新情報については、「Office 365 先進認証の更新」をご覧ください。このページには、特定の Exchange Online テナントと Skype for Business Online テナントで最新の認証を有効にする手順へのリンクも含まれています。 SharePoint Online では、先進認証が既定で有効になっています。 Teams は先進認証のみをサポートしており、レガシ認証はサポートされないため、このバイパスの問題は Teams には当てはまりません。

Microsoft 365 ブラウザーベースのアプリケーション (Office ポータル、Yammer、SharePoint サイト、Outlook on the Web など) は現在、テナント制限をサポートしています。シッククライアント (Outlook、Skype for Business、Word、Excel、PowerPoint など) は、先進認証を使用している場合にのみテナント制限を適用できます。

先進認証をサポートする Outlook と Skype for Business のクライアントは、先進認証が有効ではないテナントに対してレガシプロトコルを引き続き使用できる場合があるため、テナント制限を実質的に迂回します。テナント制限では、レガシプロトコルを使用するアプリケーションが認証中に login.microsoftonline.com、login.microsoft.com、login.windows.net へ接続すると、ブロックされる場合があります。

Windows 上の Outlook の場合、エンドユーザーが未承認の電子メールアカウントをプロファイルに追加できないようにする制限を実装することもできます。例については、「既定以外の Exchange アカウントを追加できないようにする」グループポリシー設定に関するページをご覧ください。

Azure RMS と Office メッセージ暗号化の非互換性

Azure Rights Management Service (Azure RMS) と Office メッセージ暗号化機能は、テナント制限との互換性がありません。これらの機能は、暗号化されたドキュメントの暗号化解除キーを取得するために、ユーザーを他のテナントにサインインする必要があります。テナント制限は他のテナントへのアクセスをブロックするため、信頼されていないテナントからユーザーに送信された暗号化メールとドキュメントにはアクセスできません。

テスト

テナント制限を組織全体で実装する前にテストする必要がある場合は、Fiddler などのツールを使用したホストベースのアプローチと、プロキシ設定の段階的なロールアウトの 2 つのオプションがあります。

Fiddler を使用したホストベースのアプローチ

Fiddler は無料の Web デバッグプロキシで、HTTP/HTTPS トラフィックをキャプチャして変更できます (HTTP ヘッダーの挿入など)。 Fiddler を構成してテナント制限をテストするには、次の手順を実行します。

Fiddler をダウンロードしてインストールします。
Fiddler のヘルプドキュメントに従って、HTTPS トラフィックを復号化するように Fiddler を構成します。
カスタムルールを使用して、Restrict-Access-To-Tenants と Restrict-Access-Context の各ヘッダーを挿入するように Fiddler を構成します。
1. Fiddler Web Debugger ツールで、[Rules] メニューを選択し、[Customize Rules…] を選択して CustomRules ファイルを開きます。
2. OnBeforeRequest 関数に次の行を追加します。 <List of tenant identifiers> を、テナントに登録されているドメイン (contoso.onmicrosoft.com など) に置き換えます。 <directory ID> を、テナントの Microsoft Entra GUID 識別子に置き換えます。テナントでログ表示するには、正しい GUID 識別子を含める必要があります。
```
 // Allows access to the listed tenants.
   if (
       oSession.HostnameIs("login.microsoftonline.com") ||
       oSession.HostnameIs("login.microsoft.com") ||
       oSession.HostnameIs("login.windows.net")
   )
   {
       oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
       oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
   }

 // Blocks access to consumer apps
   if (
       oSession.HostnameIs("login.live.com")
   )
   {
       oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
   }
```
複数のテナントを許可する必要がある場合は、テナント名をコンマで区切ります。次に例を示します。

oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";
CustomRules ファイルを保存して閉じます。

Fiddler を構成したら、 [File] メニューに移動し、 [Capture Traffic] を選択することでトラフィックをキャプチャできます。

プロキシ設定の段階的なロールアウト

プロキシインフラストラクチャの機能によっては、設定をユーザーに段階的にロールアウトできる場合があります。考慮事項については、次の大まかなオプションをご覧ください:

PAC ファイルを使用して、テストユーザーがテスト用プロキシインフラストラクチャを使用するようにし、通常のユーザーは運用環境のプロキシインフラストラクチャを引き続き使用します。
場合によっては、一部のプロキシサーバーでグループを使用して別の構成をサポートします。

具体的な詳細については、ご使用のプロキシサーバーのドキュメントを参照してください。

顧客のアプリケーションをブロックする

OneDrive などの、コンシューマーアカウントと組織アカウントの両方をサポートする Microsoft のアプリケーションは、同じ URL でホストされる場合があります。これは、仕事目的でその URL にアクセスする必要があるユーザーが、個人使用でもその URL にアクセスできることを意味します。このオプションは、運用ガイドラインでは許可されない場合があります。

一部の組織では、個人用アカウントの認証をブロックするために login.live.com をブロックして、この問題を解決しようとします。この修正には、いくつかの欠点があります。

login.live.com をブロックすると、B2B ゲストシナリオでの個人アカウントの使用がブロックされ、訪問者やコラボレーションに侵入する場合があります。
展開するには、オートパイロットで login.live.com を使用する必要があります。 login.live.com がブロックされると、Intune およびオートパイロットのシナリオは失敗するおそれがあります。
デバイス ID を login.live.com サービスに依存する組織のテレメトリと Windows 更新プログラムは機能しなくなります。

コンシューマーアプリの構成

Restrict-Access-To-Tenants ヘッダーは許可リストとして機能しますが、Microsoft アカウント (MSA) ブロックは拒否シグナルとして機能し、コンシューマーアプリケーションにサインインすることをユーザーに許可しないように Microsoft アカウントプラットフォームに指示します。この信号を送信するために、この記事の「プロキシの構成と要件」のセクションで説明したのと同じ企業プロキシまたはファイアウォールを使用して、sec-Restrict-Tenant-Access-Policy ヘッダーが login.live.com を訪問するトラフィックに挿入されます。ヘッダーの値は、restrict-msa である必要があります。ヘッダーが存在し、コンシューマアプリがユーザーを直接サインインしようとすると、そのサインインはブロックされます。

現時点では、login.live.com は Microsoft Entra ID とは別にホストされているため、コンシューマーアプリケーションへの認証は管理者ログには表示されません。

ヘッダーでブロックされるものとされないもの

restrict-msa ポリシーにより、コンシューマーアプリケーションの使用はブロックされますが、他の一部の種類のトラフィックおよび認証を通じて許可されます。

デバイスのユーザーレストラフィック。このオプションには、オートパイロット、Windows Update、組織のテレメトリのトラフィックが含まれます。
コンシューマーアカウントの B2B 認証。 Microsoft アカウントを持ち、テナントでのコラボレーションの招待を受けたユーザーは、リソーステナントにアクセスするために login.live.com に対して認証を行います。
1. そのリソーステナントへのアクセスを許可または拒否するために、このアクセスは Restrict-Access-To-Tenants ヘッダーを使用して制御されます。
多くの Azure アプリと Office.com で使用されている「パススルー」認証では、アプリはコンシューマーコンテキストでのコンシューマーユーザーのサインインに Microsoft Entra ID を使用します。
1. 特別な "パススルー" テナントへのアクセスを許可または拒否するために、このアクセスも、Restrict-Access-To-Tenants ヘッダーを使用して制御されます (f8cdef31-a31e-4b4a-93e4-5f571e91255a)。このテナントが許可されたドメインの Restrict-Access-To-Tenants リストに掲載されていない場合、Microsoft Entra ID は一般ユーザーのアカウントによるこれらのアプリへのサインインをブロックします。

TLS の中断と検査をサポートしていないプラットフォーム

テナントの制限は、HTTPS ヘッダーで許可されているテナントの一覧を挿入するかどうかによって異なります。この依存関係では、トラフィックを中断して検査するためにトランスポート層セキュリティ検査 (TLSI) が必要です。クライアント側でトラフィックの中断と検査、ヘッダーの追加ができない環境では、テナント制限は機能しません。

Android 7.0 以降の例を見てみましょう。 Android では、セキュリティで保護されたアプリトラフィックでより安全な既定値を提供するため、信頼された証明機関 (CA) の処理方法が変更されました。詳細については、「Changes to Trusted Certificate Authorities in Android Nougat」 (Android Nougat における認証局の変更) をご覧ください。

Microsoft クライアントアプリは、Google からの推奨事項に従って、既定でユーザー証明書を無視します。このポリシーにより、ネットワークプロキシによって使用される証明書がユーザー証明書ストアにインストールされ、クライアントアプリが信頼しないため、このようなアプリはテナント制限で動作できなくなります。

テナント制限パラメーターをヘッダーに追加するために、トラフィックを中断して検査することができないような環境では、Microsoft Entra ID は他の機能による保護を提供できます。そのような Microsoft Entra 機能の詳細情報については、以下のリストを参照してください。

条件付きアクセス: マネージド/準拠デバイスの使用のみを許可します
条件付きアクセス: ゲスト/外部ユーザーのアクセスを管理します
B2B Collaboration: "Restrict-Access-To-Tenants" パラメーターの内容と一致したテナントへのテナント間アクセスによって、送信規則を制限します
B2B Collaboration: B2B ユーザーへの招待を、"Restrict-Access-To-Tenants" パラメーターの内容と一致したドメインに制限します
アプリケーション管理: ユーザーがアプリケーションに同意する方法を制限します
Intune: Intune を介してアプリポリシーを適用することで、管理対象アプリの使用を、デバイスを登録したアカウントの UPN のみに制限します - 小見出し「アプリで構成済みの組織アカウントのみを許可する」のセクションをご確認ください。

ただし、一部の特定のシナリオでは、テナント制限を使用する必要があります。

次のステップ

Office 365 の最新の認証の更新について確認する
Office 365 URL および IP アドレス範囲を確認する

次の方法で共有

テナントへのアクセスを制限する

しくみ

テナント制限を設定する

URL と IP アドレス

プロキシの構成と要件

前提条件

構成

ユーザーエクスペリエンス

エンドユーザーエクスペリエンス

管理者エクスペリエンス

Microsoft 365 サポート

Azure RMS と Office メッセージ暗号化の非互換性

テスト

Fiddler を使用したホストベースのアプローチ

プロキシ設定の段階的なロールアウト

顧客のアプリケーションをブロックする

コンシューマーアプリの構成

ヘッダーでブロックされるものとされないもの

TLS の中断と検査をサポートしていないプラットフォーム

次のステップ

フィードバック

その他のリソース

次の方法で共有

テナントへのアクセスを制限する

しくみ

テナント制限を設定する

URL と IP アドレス

プロキシの構成と要件

前提条件

構成

ユーザー エクスペリエンス

エンド ユーザー エクスペリエンス

管理者エクスペリエンス

Microsoft 365 サポート

Azure RMS と Office メッセージ暗号化の非互換性

テスト

Fiddler を使用したホスト ベースのアプローチ

プロキシ設定の段階的なロールアウト

顧客のアプリケーションをブロックする

コンシューマー アプリの構成

ヘッダーでブロックされるものとされないもの

TLS の中断と検査をサポートしていないプラットフォーム

次のステップ

フィードバック

その他のリソース

ユーザーエクスペリエンス

エンドユーザーエクスペリエンス

Fiddler を使用したホストベースのアプローチ

コンシューマーアプリの構成