テナント制限 v1 からテナント制限 v2 への移行を計画する
適用対象: 従業員テナント 外部テナント (詳細情報)
管理者は、テナント制限 v1 を使用して、ネットワーク上の外部テナントへのユーザー アクセスを制御します。 しかし、テナント間アクセス設定を使用するテナント制限 v2 では、テナントレベルの制限が追加され、個々のユーザー、グループ、アプリケーションの制御などの細分性が高くなります。 テナント制限 v2 は、ポリシー管理をネットワーク プロキシからクラウドベースのポータルに移動します。 組織は、プロキシ ヘッダー サイズの制限が原因でターゲット テナントの最大数に達することがなくなります。
テナント制限 v1 からテナント制限 v2 への移行は、その他のライセンス要件のない 1 回限りのプロセスです。 移行を計画する際には、ネットワーク チームと ID チームの関係者を関与させてください。
前提条件
次の前提条件が満たされていることを確認してください。
- テナント制限 v1 ヘッダーを挿入しているプロキシへの管理者アクセス
- プロキシが、オンプレミスまたはクラウドベースのサービスを使用できること
- Microsoft Entra ID P1 または P2 ライセンス
- 移行の実現可能性: テナント制限 v2 でサポートされていないシナリオ
必須のロール
このセクションでは、デプロイに必要な最小特権ロールを示します。 セキュリティ管理者ロール、または少なくとも以下のアクセス許可を持つカスタム ロールを使用します。
Microsoft.directory/crossTenantAccessPolicy/
- Standard/read
- Partners/standard/read
- Default/standard/read
- Basic/update
- Default/tenantRestrictions/update
- Partners/tenantRestrictions/update
- Partners/create
- Partners/b2bCollaboration/update
- Default/b2bCollaboration/update
新しいテナント制限ポリシーを作成して設定する
プロキシが挿入している現在のヘッダー文字列を取得します。 現在のポリシーを評価し、不要なテナント ID または許可されている宛先を削除します。 評価後、外部テナント ID または外部ドメイン、あるいはその両方の一覧を作成します。
移行用のテナント間アクセス設定とテナント制限 v2 ポリシーを構成します。 テナント間アクセスの送信設定では、内部 ID がアクセスするテナントを定義します。 テナント間アクセス設定において、テナント制限 v2 は、その他の外部 ID がマネージド ネットワーク上にいる間にどのテナントにアクセスするかを定義します。
技術的な考慮事項
テナント間アクセスの送信設定を構成すると、ポリシーは 1 時間以内に有効になり、テナント制限 v1 ポリシーに加えて評価されます。 テナント間アクセス設定とテナント制限 v1 が評価され、最も制限の厳しい方が適用されます。 このアクションはユーザーに影響を与える可能性があるため、ユーザーに悪影響が出るのを防ぐために、新しいポリシーにテナント制限 v1 ポリシーを可能な限り反映させます。 テナント間アクセス設定で構成するテナント制限 v2 ポリシーは、プロキシを新しいヘッダーに更新した後に有効になります。
Note
次のセクションでは、一般的なシナリオ向けの移行と構成管理について説明します。 組織が必要とするポリシーを作成するために、このガイダンスを利用してください。
特定の外部テナントへのアクセスを内部 ID だけに許可する
従業員などの内部 ID がマネージド ネットワーク上の特定の外部テナントにアクセスすることを許可します。 内部 ID による許可リストにないテナントへのアクセスをブロックします。 請負業者やベンダーなどの外部 ID による外部テナントへのアクセスをすべてブロックします。
[テナント間アクセス設定] の [組織設定] で各ドメイン/テナントを組織として追加します。
すべてのユーザーとグループ、およびすべてのアプリケーションを許可するには、追加された組織ごとに、B2B コラボレーション用の送信アクセスを構成します。
B2B コラボレーションに関して、すべてのユーザーとグループ、およびすべてのアプリケーションをブロックするには、既定のテナント間アクセス送信設定を構成します。 このアクションは、手順 1 で追加されていないテナントにのみ適用されます。
テナント制限の既定値では、ポリシー ID を作成し (作成されていない場合)、すべてのユーザー、グループ、および外部アプリケーションをブロックするようにポリシーを構成します。 このアクションは、手順 1 で追加されていないテナントにのみ適用されます。
特定の外部テナントへのアクセスを内部 ID と外部 ID に許可する
従業員などの内部 ID と、請負業者やベンダーなどの外部 ID がマネージド ネットワーク上の特定の外部テナントにアクセスすることを許可します。 すべての ID について、許可リストにないテナントへのアクセスをブロックします。
[テナント間アクセス設定] の [組織設定] で各ドメイン/テナント ID を組織として追加します。
追加された各組織で内部 ID を有効にするには、すべてのユーザー、グループ、およびアプリケーションを許可するように B2B コラボレーション用の送信アクセスを構成します。
追加された各組織で外部 ID を有効にするには、すべてのユーザー、グループ、およびアプリケーションを許可するように組織のテナント制限を構成します。
B2B コラボレーションに関して、すべてのユーザー、グループ、およびアプリケーションをブロックするには、既定のテナント間アクセスの送信アクセス設定を構成します。 このアクションは、手順 1 で追加されていないテナントにのみ適用されます。
テナント制限の既定値では、ポリシー ID を作成し (作成されていない場合)、すべてのユーザー、グループ、および外部アプリケーションをブロックするようにポリシーを構成します。 このアクションは、手順 1 で追加されていないテナントにのみ適用されます。
Note
コンシューマー Microsoft アカウント (MSA) を対象にするには、テナント ID が 9188040d-6c67-4c5b-b112-36a304b66dad の組織を追加します。
ヒント
テナント制限 v2 ポリシーは作成されますが、有効ではありません。
テナント制限 v2 を有効にする
テナント ID とポリシー ID の値を使用して新しいヘッダーを作成します。 ネットワーク プロキシを更新して、新しいヘッダーを挿入します。
Note
ネットワーク プロキシを更新して新しい sec-Restrict-Tenant-Access-Policy ヘッダーを挿入する際には、2 つのテナント制限 v1 ヘッダー (Restrict-Access-To-Tenants と Restrict-Access-Context) を削除します。
ヒント
フェーズ ロールアウトでネットワーク プロキシを更新します。 現在のテナント制限 v1 のヘッダーと値を保存します。
重要
起こり得る問題に対処するのに役立つロールバック計画を作成します。
以下のいずれかのパターンを使用して、プロキシ構成を移行します。 選択したパターンがご利用のプロキシでサポートされていることを確認します。
- テナント制限 v2 ヘッダーを使用して一度に 1 つのプロキシをアップグレードする - このプロキシを経由してエグレスを行うユーザーは更新されたヘッダーを受け取り、新しいポリシーが適用されます。 問題がないか監視します。 問題が発生しない場合は、次のプロキシを更新し、すべてのプロキシを更新するまでこれを続けます。
- ユーザーに基づいてヘッダー挿入を更新する - 一部のプロキシでは認証されたユーザーが必要であり、ユーザーとグループに基づいてどのヘッダーを挿入するかを選択している場合があります。 新しいテナント制限 v2 ヘッダーをテスト グループのユーザーにロールアウトします。 問題がないか監視します。 問題が発生しない場合は、100% のトラフィックがスコープ内になるまで、フェーズに分けてさらにユーザーを追加していきます。
- 新しいテナント制限 v2 ヘッダーを適用するようにサービスを一度にすべて更新する - この選択肢は推奨されません。
新しいヘッダーの更新をロールアウトする際には、ユーザーが経験しているのが期待される動作であることをテストして検証します。
モニター
テナント制限 v2 とテナント間アクセスの送信設定がデプロイされたら、サインイン ログを監視し、テナント間アクティビティ ブックを使用して、ユーザーが承認されていないテナントにアクセスしていないことを確認します。 これらのツールは、誰がどの外部アプリケーションにアクセスしているかを特定するのに役立ちます。 グループ メンバーシップや特定のアプリケーションに基づいて送信アクセスを制限するように、テナント間アクセスの送信設定とテナント制限を構成することができます。
次のステップ
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示