MENU

Microsoft Entra Private AccessでB2Bゲストと複数テナントからオンプレに安全アクセスする設計ポイント

Microsoft

複数テナントを運用している企業で、「オンプレの業務システムにだけ安全に入れたい」「VPN はこれ以上増やしたくない」というニーズは急増しています。この記事では、Microsoft Entra Private Access と Global Secure Access を使って、B2B ゲスト／外部ユーザーや Cross‑Tenant Sync、MTO を前提にしたマルチテナント設計のポイントを整理します。

目次

Microsoft Entra Private Access と Global Secure Access の全体像

まず、今回の主役である Microsoft Entra Private Access と、それを包含する Global Secure Access（GSA） の関係をざっくり整理しておきます。

  • Global Secure Access：
    • Microsoft Entra Internet Access と Private Access を統合した SSE（Security Service Edge）ソリューション。
    • 「ID ベース／ゼロトラスト前提でネットワークを守る」ための統合ハブ。
  • Microsoft Entra Private Access：
    • オンプレ／IaaS／プライベート IP のアプリケーションに対して、VPN なしでゼロトラスト接続を提供。
    • アプリ単位・FQDN 単位・ポート単位でセグメントを定義して、必要な宛先だけをトンネル。
    • トラフィックは Global Secure Access クライアントから Microsoft のエッジへ、そこから Private Network Connector 経由で社内へ戻る構成。
  • Private Network Connector：
    • オンプレの Windows Server 上にインストールするエージェント。
    • 内側からクラウドに向けてアウトバウンド接続を張り、アプリケーション プロキシ／Private Access の入口となる。

Microsoft の公式説明でも、Private Access は「従来 VPN の代替」「プライベート アプリへのゼロトラスト アクセス」「ゲスト ユーザーへの拡張」といったキーワードで紹介されています。

観点従来 VPNEntra Private Access
L3/L4 アクセスサブネット単位で広く到達可能基本はアプリ／FQDN／ポート単位
アイデンティティVPN 認証とアプリ認証が分離しがちMicrosoft Entra ID ベース、SSO・条件付きアクセスと一体
最小権限「社内 LAN に入れるか／入れないか」の二択になりがちアプリごと・ユーザーごとにアクセス制御可能
ゲスト対応追加 VPN アカウントや FW 設定が必要B2B ゲストをそのまま割り当て可能（後述）

B2B ゲスト／外部ユーザーは Private Access を使えるか

結論：Private Access は B2B ゲスト対応「可」

結論から言うと、Microsoft Entra Private Access は B2B ゲスト／外部ユーザーをサポートしています。

  • Microsoft の公式 Q&A でも、「Private Access は外部ゲスト アカウントへのアクセス付与をサポートしており、Azure AD B2B 招待で作成したユーザーを Private Access アプリに割り当てられる」と明言されています。
  • 製品紹介ページでも、機能一覧に「Extend private access to guest users（ゲスト ユーザーにまでプライベート アクセスを拡張）」と記載されています。
  • Entra External ID / B2B コラボレーションの仕組み上、ゲスト ユーザーも通常ユーザーと同様にアプリ割り当て・条件付きアクセス対象にできます。

つまり、「リソース側テナントに B2B 招待 → Private Access のエンタープライズ アプリにユーザー／グループを割り当て → 条件付きアクセス／MFA で保護」という通常のパターンを、ゲストにもそのまま適用可能です。

B2B ゲストに Private Access を使わせる基本フロー

  1. リソース側テナントで B2B 招待
    • Entra 管理センターの 外部 ID > 外部コラボレーション から、相手組織のユーザーを招待。
    • Cross‑Tenant Access 設定で、相互の MFA やデバイス準拠を信頼するかを定義。
  2. Private Access アプリ（Quick Access / Per-App）に割り当て
    • Global Secure Access > アプリケーション から Quick Access または個別アプリを作成。
    • アプリの「ユーザーとグループ」に、ゲストを含むグループを割り当て。
  3. 条件付きアクセス（CA）ポリシーをアプリに紐付け
    • CA は「トラフィック プロファイル」に直接ではなく、エンタープライズ アプリ単位で適用します。
    • Quick Access／Private Access アプリをターゲットに、「MFA 必須」「場所条件」「サインイン リスク」などを定義。
  4. GSA クライアントを経由した接続
    • ユーザー端末に Global Secure Access クライアントをインストールし、リソース テナントのアカウントでサインイン。
    • Private Access プロファイルが有効な状態で、セグメントで定義した FQDN/IP にアクセス。

内部ユーザーと B2B ゲストの違いと設計ポイント

項目社内ユーザー（メンバー）B2B ゲスト
アカウントの所属リソース テナントホーム テナントに所属、リソース テナントには B2B オブジェクト
認証通常の Entra ID 認証ホーム テナントで認証し、トークンがリソース テナントに信頼される
条件付きアクセス通常の CA を適用CA は同様に適用されるが、MFA やデバイス準拠は「どのテナントを信頼するか」の設計が重要
デバイス管理自組織の Intune などで管理可能原則として相手組織が管理。
リソース テナントからは直接管理できない。
ライフサイクル管理人事システム等と連携しやすいCross‑Tenant Sync や ID ガバナンス（Entitlement Management／アクセス レビュー）で補完

特に注意したいのは Conditional Access とデバイス準拠です。ゲストのデバイスは通常、リソース テナントでは管理されないため、CA で「準拠デバイス必須」としてしまうとアクセスがブロックされます。

回避策としては、

  • ゲスト向けポリシーでは MFA のみ必須とし、デバイス準拠条件は除外する。
  • 信頼する相手テナントに対して Cross-Tenant Access の「準拠デバイス／ハイブリッド参加デバイスの信頼」を有効化して、相手側の Intune 準拠を尊重する。

Cross‑Tenant Sync / MTO と Private Access の組み合わせ

Cross‑Tenant Sync の役割

Cross‑Tenant Sync は、複数の Entra テナント間で B2B ユーザーを自動的に作成・更新・削除する同期機能です。

  • ソース テナントのユーザーを、ターゲット テナントに B2B コラボレーション ユーザーとして自動作成。
  • 属性やグループ メンバーシップもマッピングして同期可能（制御は構成次第）。
  • 退職・異動時には、自動削除／無効化でライフサイクル管理を簡素化。

Private Access から見ると、「B2B ゲストが自動的に生えてくる仕組み」として働きます。同期された B2B ユーザーを、Private Access アプリにグループ単位で割り当てれば、社員・ゲスト問わず 自動プロビジョニングされた最小権限アクセスを実現できます。

MTO（Multi‑Tenant Organization）の位置づけ

Multi‑Tenant Organization（MTO） は、同一企業内の複数テナントを「1 つの組織」として扱うための枠組みです。Teams や Microsoft 365 でのコラボレーション体験を統合するのが主目的ですが、その基盤として B2B／Cross‑Tenant Sync を活用します。

Private Access 自体は MTO 専用機能を持っているわけではありませんが、

  • MTO で整理された テナント境界と信頼関係 に乗ることで、
  • 「ハブ テナントにまとめて Private Access を集約し、各テナントからのユーザーは B2B＋Cross‑Tenant Sync 経由で連携」

といったアーキテクチャを取りやすくなります。

よくあるマルチテナント構成パターン

パターン概要Private Access の位置づけ
パターン A：ハブ＆スポーク本社テナントをハブに、各地域／子会社テナントからユーザーを B2B 連携オンプレや共通システムを本社テナントから Private Access で公開。
パターン B：部門ごとにリソース テナント分割事業会社ごとにそれぞれの Private Access を持ち、必要に応じて相互 B2B特定事業会社のオンプレ リソースにだけ入りたい外部委託先などに向いている。
パターン C：グループ共通 IaaS ハブAzure サブスクリプションとオンプレ接続を 1 テナントに集約し、他テナントから B2B で利用「IaaS ハブ」テナントで Private Access を構成し、全グループ会社がそこにぶら下がる。

Global Secure Access クライアントのマルチテナント運用

前提：GSA クライアントは「テナント単位」の設計

Global Secure Access クライアントは、次のような前提で動作します。

  • GSA にオンボードされた 1 つの Microsoft Entra テナント を前提に構成される。
  • クライアントが有効になるには、そのテナントに参加済み（Entra 参加またはハイブリッド参加）のデバイスである必要がある。
    • Entra 登録のみのデバイスはサポート対象外。

さらに、Global Secure Access FAQ では次のように明記されています。

  • B2B ログインは「リソース テナントに Entra 参加しているマネージド デバイス」からのみサポートされる。
  • クライアントは、そのデバイスが参加しているテナントの Global Secure Access に接続する。

Microsoft の Q&A でも、「Global Secure Access クライアントは 1 テナントで動作するよう設計されており、複数テナントで使う場合はデバイスごとに別々に構成する必要がある」と回答されています。

つまり、1 台の物理端末に常時同時接続できるのは基本的に 1 テナントだけ、という前提で設計する必要があります。

B2B ログインとデバイス参加の制約

ここでやや分かりづらいのが、

  • 「ゲスト ユーザーは Entra 参加デバイスにサインインできない」というデバイス管理 FAQ
  • 「B2B ログインは Entra 参加デバイスからサポートされる」という Global Secure Access FAQ

の関係です。整理すると次のようになります。

  • OS ログオン：ゲスト アカウントで Windows にサインインすることはできない。
  • アプリ（GSA クライアント）へのサインイン：
    • デバイス自体はリソース テナント（例：Contoso）に Entra 参加している。
    • そのうえで、GSA クライアントに [email protected] などの B2B ユーザーでサインインし、Private Access を利用できる。

したがって、「相手組織に貸与したデバイス（リソース テナント参加済み）」に GSA クライアントを入れ、その上で B2B アカウントを使わせるというのが、現時点で公式にサポートされた B2B ログイン パターンになります。

外部ユーザーに「自社 PC + GSA」で直接 Private Access させるのは難しい

多くの方がイメージするであろう

  • 外部監査人や委託先が、自社の PC に GSA クライアントをインストールし、そのままこちらの Private Access に接続する

という使い方は、次の理由でストレートには実現できません。

  • GSA クライアントは「リソース テナントに参加しているデバイス」を前提にしており、外部組織の Intune 管理端末をこちらのテナントに参加させるのは現実的でない。
  • デバイス管理は基本的に 1 組織のみが行うべきであり、複数組織で同じ端末を管理することは推奨されていない。

結果として外部ユーザー向けには、次のような代替パターンが現実解になります。

パターン 1：Windows 365 / AVD + GSA クライアント

Microsoft は Global Secure Access の B2B ゲスト アクセスとして、Azure Virtual Desktop（AVD）や Windows 365 と組み合わせるパターンを公式に案内しています。

  1. リソース テナントで AVD / Windows 365 の VM を用意し、その VM をリソース テナントに Entra 参加させる。
  2. VM に Global Secure Access クライアントをインストールし、Private Access プロファイルを構成。
  3. VM 側で 外部 ID リンクを設定し、B2B ユーザーが自分のアカウントでその VM にリモート接続できるようにする。
  4. 外部ユーザーは、自社 PC から AVD/Windows 365 にリモート接続し、VM 内から Private Access 経由でオンプレ リソースへアクセス。

この方式なら、

  • デバイス管理はリソース テナント（VM 側）のみで完結し、
  • 外部ユーザーの物理 PC はあくまで「リモート デスクトップ クライアント」でしかない

という、きれいな責任分界を作れます。

パターン 2：テナントごとに専用デバイス／VDI を割り当て

MSP や親会社 IT 部門のように、複数テナントの Private Access に自分たちがアクセスしたい（≒管理したい）ケースでは、

  • テナント A 用の管理用 PC（A テナントに Entra 参加）
  • テナント B 用の管理用 PC（B テナントに Entra 参加）

といった設計にせざるを得ない場面もあります。あるいは、

  • ホストする VDI 基盤にテナントごとに VM を用意し、管理者はその VM にリモートで入り GSA クライアントを利用する

といった構成も考えられます。

いずれにしても、現行仕様では 「1 クライアント端末で複数テナントの Private Access に常時同時接続」という使い方は想定されていない点に注意が必要です。

Universal Tenant Restrictions とマルチテナント

Global Secure Access は、ユニバーサル テナント制限（Tenant Restrictions v2）のシグナリングにも対応しており、GSA クライアント経由のトラフィックに「許可された外部テナント」の情報を付与できます。

これにより、

  • 社内ネットワークや GSA クライアント利用時に、許可したテナント以外へのアクセスをブロックし、データ持ち出しリスクを減らす

といったコントロールが可能ですが、マルチテナント運用では次のような罠があります。

  • 本社テナントで Universal Tenant Restrictions を有効化した結果、本来許可したい子会社テナント／パートナー テナントへのサインインまでブロックしてしまう。

したがって、

  • Private Access を利用する 各テナントを Allow リストに追加しておくこと
  • GSA クライアント＋テナント制限を有効化する順番と影響範囲を、PoC 環境で必ず検証してから本番適用すること

が重要になります。

Private Access 導入ステップの詳細

Step 1：Private Network Connector の設計と配置

オンプレ環境から Private Access を利用するには、まず Microsoft Entra private network connector を構成します。

  • 対応 OS：Windows Server 2016 以降。
  • 配置場所：
    • 守りたいアプリケーションに到達できるネットワーク（LAN/DMZ）。
    • インターネットへのアウトバウンド HTTPS（443/TCP）が可能なセグメント。
  • 高可用性：
    • 同一コネクタ グループ内に 2 台以上のコネクタを配置して負荷分散＆冗長化。

マルチリージョン展開する場合は、リージョンごとにコネクタ グループを分ける Multi-Geo 構成も検討できます。

Step 2：アプリケーション セグメント（Quick Access / Per‑App）の設計

次に、どのリソースにどの程度の粒度でアクセスさせるかを定義します。

  • Quick Access：
    • 広い IP 範囲や *.contoso.local のようなワイルドカード FQDN を一括で公開。
    • 「まずは VPN 代替としてざっくり社内に入れる」ためのオンボード用途に向く。
  • Per‑App Access（個別アプリ）：
    • RDP サーバー（FQDN＋ポート 3389）、SMB ファイルサーバー（445）、業務 Web アプリ（443）といった単位でセグメントを定義。
    • アプリごとにユーザー／グループ割り当て・条件付きアクセスを個別に制御可能。

ゼロトラスト的には、

  1. PoC では Quick Access で広めに公開して利用状況を把握。
  2. トラフィック ログをもとに主要なアプリを洗い出し、個別アプリに切り出して CA を厳格化。

という「VPN 的に広く → 徐々に絞り込む」アプローチが現実的です。

Step 3：ID / アクセス制御（B2B・Cross‑Tenant Sync・MTO）

次に、誰にどのアプリへのアクセス権を与えるかを設計します。

  • グループ設計
    • 「社内ユーザー用」「B2B ゲスト用」を分ける。
    • MTO／Cross‑Tenant Sync で同期される属性（部門・役割・地域）を元に、動的グループを使うのも有効。
  • エンタープライズ アプリへの割り当て
    • Quick Access / 個別アプリごとに、該当するグループのみを割り当て。
    • ゲストは必ず グループ経由で割り当て、直接ユーザー追加を避ける。
  • 条件付きアクセス ポリシー
    • Quick Access / Private Access アプリをターゲットに CA を作成し、
      • 社内ユーザー：デバイス準拠 + MFA
      • ゲスト：MFA 必須（デバイス準拠は信頼する相手テナントのみ）
    • ゲスト向けの推奨ポリシー（常時 MFA 要求／リスクベース MFA からの除外など）は Microsoft のガイドにもまとまっています。

Step 4：GSA クライアント配布とプロファイル割り当て

ユーザー端末側では、次のような流れでクライアントを展開します。

  1. Entra 管理センターの Global Secure Access > 接続 > クライアントのダウンロード から最新クライアントを取得。
  2. Intune などの MDM からサイレント インストール。
  3. Private Access トラフィック フォワーディング プロファイルを有効化し、対象ユーザー／グループを割り当て。
  4. 必要に応じて、レジストリやスクリプトで
    • ユーザーによる無効化を制限
    • 社内 LAN 接続時に Private Access を自動停止（ローカルブレイクアウト）
    などの細かい挙動を制御します。

マルチテナント環境で、「端末によってサインイン先テナントを変えたい」場合は、クライアントの配布スコープと Entra 参加テナントをしっかり整理しておくことが重要です。

Step 5：テスト・監査・運用

構成ができたら、必ず次のポイントを確認します。

  • 名前解決とルーティング
    • クライアント端末から、セグメントで定義した FQDN に対する DNS 解決が想定通り行われているか。
    • Private Access がトンネルするのは「プロファイルにマッチした宛先のみ」であることに注意。
  • ログと監査
    • Global Secure Access の トラフィック ログで、誰がどの Private Access 宛先にアクセスしているかを確認。
    • Entra のサインイン ログで CA の評価結果（MFA 要求／デバイス準拠条件など）を確認。
    • 必要に応じて、ログを Defender／SIEM に転送し、長期保管・相関分析を行う。
  • アクセス レビュー
    • B2B ゲストを含むグループに対して、Entra ID Governance のアクセス レビューを実施し、不要な権限を定期棚卸し。

VPN と Private Access の使い分け

Private Access は強力ですが、すべての VPN を即日置き換える魔法ツールではありません。用途ごとに得意／不得意を整理しておくと、現実的なロードマップが描きやすくなります。

ユースケースPrivate Access 向きVPN 向き
外部監査人・委託先からの特定アプリ利用◎：対象アプリだけを FQDN/ポート単位で公開し、MFA＋ログを厳格化△：VPN だと社内ネットワーク全体が見えてしまいがち
運用保守でのサーバー管理（RDP/SSH など）○：対象サーバーだけをセグメント化すれば利用可能○：広範囲な L3/L4 アクセスが必要なら既存 VPN がシンプル
大容量ファイル共有・NAS へのフルアクセス△：ポート 445 を公開すれば可能だが、設計とテストが必須◎：L3 VPN でサブネットごとマウントする方がわかりやすい
社内からインターネットへの制御付きアクセス◎：Entra Internet Access + Universal CA でトラフィック制御△：プロキシ＋VPN でも可能だが構成が複雑化しやすい

現実的なアプローチとしては、

  • フェーズ 1：外部監査・委託先など、「外部からの限定アプリアクセス」を Private Access に乗せる。
  • フェーズ 2：社内ユーザーの一部（テレワーク／出張者）を Private Access + Internet Access に移行し、既存 VPN の用途を徐々に絞る。
  • フェーズ 3：どうしても L3 VPN が必要なケースだけを残し、その他はゼロトラスト前提のネットワークに刷新。

よくあるハマりどころと対策

症状主な原因対策
誰がどのアプリに割り当てられているか把握できないユーザーを個別にアプリへ割り当ててしまっているグループ経由割り当てに統一し、Entra ID Governance のアクセス レビューで棚卸し。
接続は張れているようだが、FQDN で名前解決できないアプリ セグメントに登録した FQDN と、実際のアクセス先 FQDN が一致していない／DNS 設定不足Quick Access / 個別アプリに設定した FQDN を再確認し、社内 DNS で正しく解決できるかテスト。
GSA クライアント有効時、別テナントにサインインできないUniversal Tenant Restrictions で外部テナントがブロックされているTrusted テナントのリストに必要な外部テナントを追加し、許可ポリシーを調整。
外部ゲストの GSA クライアントに Private Access プロファイルが降りてこないゲストの端末がリソース テナントに Entra 参加していない／B2B ログイン要件を満たしていないリソース テナントに参加した管理デバイス or AVD/Windows 365 VM 上で GSA クライアントを動かす設計に変更。
CA で Private Access 宛のトラフィックを制御できていないように見えるトラフィック プロファイルを直接ターゲットにしている（現状非サポート）Quick Access / Private Access のエンタープライズ アプリに対して CA ポリシーを適用する。
トラフィック ログの保持期間が足りないEntra ポータルのトラフィック ログは一定期間でローテーションされるログをエクスポートし、Log Analytics/Defender/SIEM に蓄積する設計にする。

最低限チェックしておきたいポイント（チェックリスト）

  • Private Network Connector を必要なネットワークに配置し、対象アプリの FQDN / IP / ポートをセグメントとして定義したか。
  • B2B ゲスト／外部ユーザーをリソース テナントに招待し、グループ経由で Private Access アプリに割り当てたか。
  • 社内ユーザーとゲストで CA ポリシーを分け、
    • 社内：準拠デバイス＋MFA
    • ゲスト：常時 MFA（必要に応じて相手テナントの MFA／デバイス準拠を信頼）
    の設計になっているか。
  • GSA クライアントを配布する端末は、対象テナントに Entra 参加／ハイブリッド参加しているか。
  • Universal Tenant Restrictions を有効にする場合、必要な外部テナントを Allow リストに登録してあるか。
  • トラフィック ログ／監査ログの出力先と保持ポリシーを決め、規程どおりの期間ログを保存できるようにしているか。

設計パターン別のおすすめ構成イメージ

ケース 1：複数テナントを持つ企業グループで、共通オンプレ業務システムにアクセスさせたい

  • 本社テナントを「ハブ」とし、オンプレと Azure IaaS を一元管理。
  • 本社テナントに Private Access を構成し、共通業務アプリ（経理／人事／基幹など）を公開。
  • 各子会社テナントから社員を Cross‑Tenant Sync で本社テナントに B2B 作成し、部門・役割ごとにグループ割り当て。
  • GSA クライアントは原則として各子会社テナント側の端末で、本社への Private Access と子会社側の Internet Access を併用。

ケース 2：外部監査人・ベンダーにオンプレシステムだけ見せたい

  • リソース テナントに監査人／ベンダーを B2B 招待。
  • RDP 専用サーバーや Web ベースの画面表示専用サーバーを用意し、それを Private Access 経由で公開。
  • 監査人の物理 PC を直接管理できない場合は、
    • Windows 365 / AVD の VM をリソース テナントで用意し、
    • VM 上に GSA クライアントを導入して Private Access に接続、
    • 監査人は自社 PC から VM へリモート接続して利用、という構成にする。

ケース 3：MSP が複数顧客テナントの Private Access を管理したい

  • 各顧客テナントごとに、MSP 用 ID（例：[email protected]）を発行。
  • MSP 側は、顧客ごとに
    • 専用の管理用 VDI / 物理 PC を用意して、対象テナントに Entra 参加。
    • その上で GSA クライアントを利用し、Private Access 設定やトラフィック ログを管理。
  • Universal Tenant Restrictions を MSP 自身のテナントで有効にする場合は、「管理対象テナント」を Allow リストに登録し、予期せぬブロックを防ぐ。

まとめ

Microsoft Entra Private Access は、「オンプレやプライベート環境のアプリを、ID 中心のゼロトラスト アプローチで公開する」ための強力な選択肢です。公式情報や Q&A を踏まえると、

  • B2B ゲスト／外部ユーザーへのアクセス付与はサポートされており、Azure AD B2B（Entra External ID）で招待して Private Access アプリに割り当てることで利用可能。
  • Cross‑Tenant Sync / MTO とも併用可能で、マルチテナント企業におけるユーザー同期・ライフサイクル管理を大幅に簡素化できる。
  • Global Secure Access クライアントは基本的に「1 デバイス＝1 テナント」であり、B2B ログインには「リソース テナントに参加したデバイス」か、AVD/Windows 365 のようなホスト側で管理された VM を使う設計が必要。

VPN を一気に廃止するのではなく、「外部ゲストからの限定アクセス」→「社内ユーザーの主要アプリ」→「それ以外のトラフィック」という順番で段階的に Private Access / Internet Access へ移行していくのが、現実的かつ安全な進め方です。

最後に、Entra／GSA 周りは機能追加と仕様変更のペースが速いため、実際の設計・導入時には必ず最新の公式ドキュメントとライセンス条件を確認しながら進めることをおすすめします。

Microsoft
マルチテナント Microsoft Entra B2B ゼロトラスト Private Access Global Secure Access VPN代替

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次