Microsoft Entra Tenant Governanceの「関連テナント」機能は、B2BによるID連携、マルチテナントアプリケーション、共有課金アカウントを手掛かりに、自社と関係がある可能性のあるMicrosoft Entraテナントを自動検出します。
子会社や買収先、部門ごとに分散管理されているテナントだけでなく、従業員が検証目的で作成したシャドーITテナントを見つける入口としても活用できます。
ただし、検出された「関連テナント」は、自社が所有しているテナントの確定一覧ではありません。所有関係、信頼関係、危険性、管理権限の有無を自動的に判定する機能でもないため、ガバナンスを適用する前に、管理者がユーザー、アプリ、課金、契約、利用目的を照合する必要があります。(Microsoft Learn)
Entra Tenant Governanceの関連テナント自動検出とは
企業が利用するMicrosoft Entraテナントは、必ずしも一つとは限りません。
例えば、次のような理由でテナントが増加します。
- 子会社や海外拠点が独自にMicrosoft 365を導入した
- 買収した企業のテナントが残っている
- 開発部門がテスト用テナントを作成した
- セキュリティや法規制上の理由で環境を分離した
- SaaS事業者のマルチテナントアプリを利用している
- 部門が中央IT部門を通さずクラウドサービスを契約した
テナント名や契約台帳だけで管理しようとしても、中央IT部門が把握していない環境は一覧に入りません。
そこでEntra Tenant Governanceは、Microsoft EntraやAzure上で実際に観測された操作や構成を分析し、「現在のテナントと何らかの接点がある別テナント」を関連テナントとして表示します。関連テナントは管理者が手動登録するのではなく、検出シグナルに基づいて自動的に提示されます。(Microsoft Learn)
重要なのは、自動化されるのは検出までという点です。
| 段階 | Entra Tenant Governanceが行うこと | 管理者が行うこと |
|---|---|---|
| 検出 | 関連する可能性があるテナントを提示する | 検出結果の全体像を確認する |
| 理解 | シグナル、方向、規模、時期を表示する | ユーザーやアプリを調査する |
| 分類 | 判断材料を提供する | 許容、要管理、要隔離に分類する |
| ガバナンス | 管理関係を構築する機能を提供する | 権限と適用範囲を決定する |
検出された時点で、対象テナントが自動的に管理下へ入るわけではありません。また、アクセスが自動遮断されるわけでもありません。
Entraは関連テナントをどう見つける？identity・application・billingシグナル
関連テナントの自動検出には、大きく分けて次の3種類のシグナルが使われます。
| シグナル | 主な観測対象 | 見つかりやすいテナント |
|---|---|---|
| Identity | B2B登録、B2Bサインイン、管理アプリへのサインイン | 取引先、子会社、検証用テナント |
| Application | マルチテナントアプリの登録、同意、利用関係 | SaaS事業者、共通アプリを持つ社内テナント |
| Billing | 共有課金アカウント | 子会社、部門テナント、集中購買された環境 |
シグナルは「なぜ関連していると判断されたのか」を説明するものであり、所有関係や危険性を決めるものではありません。(Microsoft Learn)
IdentityシグナルはB2Bの登録と利用状況を見る
Identityシグナルでは、テナントをまたぐユーザーの登録やサインインが確認されます。
B2B registration
別テナントをホームテナントとするゲストユーザーや外部メンバーが、自社テナントに登録されている状態です。
B2B登録があることは、過去または現在にテナント間の接点が存在した証拠になります。しかし、ユーザーが登録されているだけで、現在も利用されているとは限りません。
例えば、数年前のプロジェクトで招待したゲストアカウントが削除されずに残っているケースがあります。
B2B sign-ins
ゲストユーザーや外部メンバーが、実際にテナントをまたいでサインインしたことを示します。
B2B登録だけのテナントより、直近のB2Bサインインがあるテナントの方が、現在の業務との関係性は高いと判断できます。
Admin app sign-ins
Microsoft Entra管理センター、Azure portal、Microsoft 365管理センターなど、Microsoftが定義した管理アプリへのクロステナントサインインです。
一般ユーザーによる共同作業だけでなく、別テナントのアカウントを使った管理操作が行われている可能性を示します。そのため、通常のB2Bサインインよりも優先して確認すべきシグナルです。(Microsoft Learn)
例えば、子会社の管理者が親会社アカウントを使って管理センターへサインインしている場合、組織的な管理関係が存在する可能性があります。
一方で、担当者が一時的な支援のためにアクセスしただけという場合もあるため、シグナルだけで恒常的な管理関係と決めつけないことが重要です。
Applicationシグナルはマルチテナントアプリの信頼関係を見る
マルチテナントアプリケーションのシグナルは、あるテナントで登録されたアプリが、別のテナントで同意またはインスタンス化されている関係を検出します。
例えば、次のような環境が対象になります。
- SaaS事業者が提供する業務アプリ
- 親会社が開発し、複数の子会社で使う社内アプリ
- 開発部門のテスト用テナントに登録された共通アプリ
- 買収先のテナントで継続利用されている旧システム
アプリの信頼関係は、ユーザー同士の共同作業が終了した後も残ることがあります。さらに、アプリには広いMicrosoft Graph権限や管理者同意が付与されている可能性があります。
そのため、Applicationシグナルを確認するときは、アプリ名だけで判断せず、サービスプリンシパル、所有元テナント、付与済み権限、最終利用状況まで確認することが重要です。(Microsoft Learn)
Billingシグナルは共有課金アカウントを見る
Billingシグナルは、複数のテナントが同じ課金アカウントに関連付けられている場合に検出されます。
共通の課金基盤を利用しているテナントは、次のような組織内環境である可能性があります。
- 親会社が費用を負担する子会社テナント
- 情報システム部門が集中購買した部門テナント
- 検証用として追加作成されたテナント
- 組織再編前の契約が残っているテナント
共有課金は組織的な関係を示す強い手掛かりですが、現在の所有関係を保証するものではありません。売却済み企業のテナントが課金構成に残っている可能性もあります。
また、公式情報では、Billingシグナルの対象はAzureのMicrosoft Customer Agreement、いわゆるMCAのエンタープライズ課金アカウントです。Enterprise Agreementや旧来のコマース契約は、現時点ではこのシグナルの対象外とされています。(Microsoft Learn)
したがって、Billingシグナルに表示されないことを理由に「同一組織のテナントではない」と判断してはいけません。
検出結果ではシグナルの数より中身を見る
一つの関連テナントに複数のシグナルが表示されることがあります。
例えば、次の3つが同時に見つかったとします。
- 共有課金アカウントがある
- 管理アプリへのサインインがある
- マルチテナントアプリを相互利用している
この場合、単一のB2B登録しかないテナントより、組織との結び付きが強い可能性があります。
ただし、「シグナルが3個あるから自社所有」と機械的に決めるのは適切ではありません。SaaS事業者やIT運用委託先でも、複数のシグナルが成立する可能性があるためです。
実務では、シグナル数だけでなく、次の要素を組み合わせて評価します。
| 確認項目 | 判断のポイント |
|---|---|
| シグナルの種類 | 共有課金や管理サインインを優先して確認する |
| 初回と直近 | 過去だけでなく現在も関係が続いているか |
| 方向 | 相手から自社、自社から相手のどちらか |
| 規模 | 関係するユーザーやアプリが少数か多数か |
| 利用目的 | 契約、プロジェクト、運用委託で説明できるか |
| 所有者 | 社内に責任者や管理部門が存在するか |
Initial・Recent・Inbound・Outboundの読み方
関連テナントの画面では、単に「関係がある」と表示されるだけではなく、関係の時期や方向を判断するためのメトリックも提示されます。
InitialとRecent
Initialは、対象となる構成や活動が最初に確認された時点を表します。
Recentは、その後の継続的または新しい活動を表します。
例えば、InitialにはB2B登録があるものの、Recentのサインインが確認できない場合、過去の共同プロジェクトで使われた休眠関係かもしれません。
一方、直近のB2Bサインインや管理アプリへのアクセスが増えている場合は、現在も利用されている関係として優先的に調査します。
InboundとOutbound
Inboundは、関連テナント側から現在のテナントに向かう活動や構成です。
Outboundは、現在のテナント側から関連テナントに向かう活動や構成です。
例えば、相手企業のユーザーが自社テナントへサインインしている場合と、自社従業員が相手テナントへサインインしている場合では、確認すべき管理責任が異なります。
なお、InboundとOutboundは主にB2Bおよびマルチテナントアプリのシグナルで使われ、共有課金には適用されません。(Microsoft Learn)
表示件数は正確な実数ではない
関連テナントのメトリックは、個々のユーザーを直接集計した正確な件数ではなく、桁単位に集約された値で表示されます。
例えば、表示値と実際の範囲は次のようになります。
| 表示値 | 実際の値の範囲 |
|---|---|
| 1 | 1～9 |
| 10 | 10～99 |
| 100 | 100～999 |
| 1,000 | 1,000～9,999 |
| 10,000 | 10,000～99,999 |
画面に「100」と表示されていても、実際には100件とは限らず、100～999件の範囲を示します。これは規模感を把握しながら、ユーザーのプライバシーを保護するための集約方法です。(Microsoft Learn)
正確な対象を確認するときは、対象メトリックを選択して詳細へドリルダウンします。
| シグナル | 詳細で確認できる主な対象 |
|---|---|
| B2B登録 | 関連テナントをホームとするゲストユーザー |
| B2Bサインイン | クロステナントでサインインしたユーザーやアプリ |
| 管理アプリサインイン | 管理アプリを利用したユーザーやアプリ |
| マルチテナントアプリ | 関連テナントが所有するサービスプリンシパル |
詳細画面は現在のテナントから取得した情報を表示するため、集約メトリックと件数が一致しない場合があります。サインイン情報については、ログの保持期間によって確認できる範囲も変わります。(Microsoft Learn)
関連テナントの実務的な判定例
検出結果は、次のように業務上の背景と組み合わせて判断します。
| 検出例 | 想定される関係 | 推奨する初動 |
|---|---|---|
| 共有課金と管理サインインがある | 子会社や社内部門 | 所有者と管理体制を確認する |
| マルチテナントアプリだけがある | SaaS事業者 | 契約中サービスか確認する |
| 社内に似た名前で直近のB2B利用がある | 従業員作成の検証用環境 | 作成者と利用目的を調査する |
| 古いB2B登録だけがある | 終了済みプロジェクト | ゲストアカウントの整理を検討する |
| Microsoft managedと表示される | Microsoftの基盤用テナント | 原則として調査対象から分ける |
| 身元不明で管理サインインがある | 未承認または危険な環境 | セキュリティ部門へ連携する |
Microsoftのクラウド運用に伴って検出されるMicrosoft所有の基盤テナントは、「Microsoft managed」として識別されます。通常はガバナンス対象にする必要がないため、最初に除外すると調査のノイズを減らせます。(Microsoft Learn)
関連テナントの検出を有効化する手順
関連テナントの検出を始める前に、ライセンス、管理者ロール、変更管理の3点を確認します。
必要な管理者ロール
検出機能を有効化するには、次のいずれかのMicrosoft Entraロールが必要です。
- Tenant Governance Administrator
- Global Administrator
日常運用では、必要以上にGlobal Administratorを使用せず、Tenant Governance Administratorの利用を検討します。(Microsoft Learn)
ライセンスを確認する
Microsoftの現行ライセンス表では、B2B、マルチテナントアプリ、共有課金アカウントを使った関連テナントの検出は、Microsoft Entra ID Governanceの対象機能として掲載されています。
Microsoft Entra ID Free、P1、P2のみの列には、この検出機能は含まれていません。Microsoft Entra SuiteにはEntra ID Governanceの機能が含まれますが、契約内容や提供条件は変更される可能性があるため、導入時点の公式ライセンス表を確認してください。(Microsoft Learn)
管理センターから有効化する
Microsoft Entra管理センターでは、次の流れで有効化します。
- Tenant Governance Administrator以上の権限でMicrosoft Entra管理センターへサインインします。
Tenant Governanceを開きます。Related tenantsを選択します。- 表示される説明と注意事項を確認します。
Discover related tenantsを選択します。
有効化後、Microsoft Entraが既存のアクティビティや構成からシグナルを集約します。検出結果が表示されるまでには時間がかかる場合があります。(Microsoft Learn)
管理センターの日本語表示では、メニュー名やボタン名が翻訳されている場合があります。見つからないときは、英語表記のTenant GovernanceやRelated tenantsも確認するとよいでしょう。
Microsoft Graphから有効化する
自動構築や運用スクリプトに組み込む場合は、Microsoft Graphの次のアクションを使用できます。
POST /directory/tenantGovernance/settings/enableRelatedTenantsこの操作を実行すると、isRelatedTenantsEnabledがtrueになります。(Microsoft Learn)
有効化後は無効に戻せない
関連テナントの検出設定は、一般的なオン・オフのトグルではありません。
公式情報では、一度有効化すると無効状態へ戻せないと説明されています。そのため、検証環境であっても、変更管理の承認、ライセンス、管理者権限、データを閲覧できる担当者を整理してから実行してください。(Microsoft Learn)
検出後に管理者が行う確認手順
関連テナントが表示されたら、いきなりガバナンス関係を設定するのではなく、次の順番で調査します。
Microsoft managedを分ける
最初にMicrosoft管理の基盤テナントを分けます。
これにより、子会社、外部事業者、シャドーITなど、実際に確認が必要な対象へ集中できます。
優先度の高いシグナルから確認する
次のようなテナントは優先的に調査します。
- 管理アプリへの直近のサインインがある
- 共有課金アカウントがある
- 複数のシグナルが重なっている
- アクティビティの規模が拡大している
- 社内に似た名称やドメインを使用している
- 所有者や利用目的を説明できない
- 広い権限を持つマルチテナントアプリがある
反対に、既知のSaaS事業者や取引先であり、利用目的と契約を説明できる場合は、緊急性を下げられます。
ユーザーとアプリへドリルダウンする
集約値だけで判断せず、シグナルの詳細を開きます。
B2Bであれば、対象ユーザーの所属、最終サインイン、招待元、アクセス先を確認します。
マルチテナントアプリであれば、次の情報を確認します。
- アプリケーション名
- アプリケーションID
- 所有元テナント
- 付与されたAPI権限
- 管理者同意の有無
- 利用しているユーザーや業務
- 契約中のサービスとの対応
管理アプリへのサインインがある場合は、誰がどの管理画面を使ったのかを確認します。
社内情報と照合する
Entra Tenant Governanceの結果だけでなく、次の情報と照合します。
- Microsoft 365やAzureの契約台帳
- グループ会社と買収先の一覧
- SaaS管理台帳
- クラウド課金アカウント
- アプリケーション台帳
- 委託先一覧
- プロジェクト管理資料
- 例外申請や検証環境の申請記録
確認結果は、少なくとも次の項目で台帳化すると継続運用しやすくなります。
| 記録項目 | 内容 |
|---|---|
| Tenant ID | テナントを一意に識別するID |
| 表示名・ドメイン | 画面上の名称と確認済みドメイン |
| 検出シグナル | B2B、アプリ、課金など |
| 直近の活動 | Recentメトリックや更新日時 |
| 所有者 | 部門、子会社、外部事業者 |
| 利用目的 | 本番、検証、委託、SaaSなど |
| 判定 | 許容、要管理、要隔離 |
| 対応 | 監視、整理、関係構築、制限 |
| 次回確認日 | 定期レビューの日付 |
検出したテナントは3種類に分類する
Microsoftの公式ガイダンスでは、関連テナントを実務上、次の3種類に分類する考え方が示されています。(Microsoft Learn)
既知で許容できるテナント
取引先、顧客、SaaS事業者など、関係性と利用目的を説明できるテナントです。
想定どおりのB2Bやアプリ利用であれば、管理対象へ取り込む必要はありません。
対応としては、次の内容を記録します。
- 相手組織の名称
- 契約やプロジェクト
- 利用中のユーザーやアプリ
- 社内責任者
- 次回レビュー日
「対応不要」とする場合でも、誰が何を根拠に判断したかは残しておきます。
ガバナンスの検討が必要なテナント
社内環境に見えるものの、中央IT部門が管理していないテナントです。
例えば、次のようなケースです。
- 子会社が独自に運用している
- 開発者が検証目的で作成した
- 買収後も別管理になっている
- 部門が直接契約している
- 管理者が退職して責任者が不明になっている
直ちに遮断するのではなく、所有者と業務上の必要性を確認します。正当な用途があれば、正式なガバナンス関係の構築を検討します。
ガバナンス関係は、検出しただけでは成立しません。管理する側と管理される側の間で、付与するロールや権限を設定し、原則として双方の管理者が合意する手続きが必要です。(Microsoft Learn)
未承認または危険性が疑われるテナント
所有者が不明で、想定外のサインインやアプリ利用が確認されたテナントです。
次のような場合は、セキュリティ部門と連携して調査します。
- 管理アプリへの不明なサインインがある
- 業務上説明できないマルチテナントアプリがある
- 社内ユーザーが多数アクセスしている
- 誰も作成や契約を把握していない
- 不要な権限や管理者同意が残っている
隔離やアクセス制限を検討する場合でも、関連テナントとして表示されたことだけを根拠に実施してはいけません。ユーザー、アプリ、サインインログ、契約情報を確認し、リスク評価を行ってから判断します。(Microsoft Learn)
関連テナント自動検出で失敗しやすいポイント
「関連」を「自社所有」と読み替える
最も避けたい誤解です。
関連テナントには、取引先、顧客、SaaS事業者、Microsoft管理テナントも含まれます。表示されたという理由だけで、自社の管理対象にしてはいけません。
B2B登録だけで現在も使われていると判断する
ゲストユーザーが登録されていても、現在利用されているとは限りません。
B2Bサインイン、Recentメトリック、最終サインイン、プロジェクトの終了状況を確認します。
集約値を正確な件数として報告する
表示値の100は、100件ちょうどではなく100～999件を意味します。
経営層や監査部門へ報告するときは、「集約された規模表示」であることを明記します。
検出直後にアクセスを遮断する
未承認テナントに見えても、重要なSaaSや委託先である可能性があります。
遮断前に、利用ユーザー、アプリ所有者、契約部門、業務影響を確認します。
Billingシグナルだけに頼る
MCA以外の課金契約では、組織的に関連するテナントであってもBillingシグナルに現れない可能性があります。
契約台帳、Azureの管理グループ、Microsoft 365契約、子会社一覧などを併用します。
有効化を通常の設定変更として扱う
関連テナントの検出は、有効化後に無効へ戻せません。
本番テナントで実行する前に、変更承認、閲覧権限、運用担当者、調査フローまで決めておく必要があります。
まずは検出結果を「候補一覧」として運用する
Entra Tenant Governanceの関連テナント自動検出は、これまで中央IT部門から見えなかった子会社、買収先、検証環境、シャドーITを見つける有効な手段です。
一方、identity、application、billingの各シグナルが示すのは、あくまで観測された接点です。自社所有、信頼済み、危険、管理対象といった結論を自動的に出すものではありません。
導入時は、次の順番で進めると安全です。
- ライセンスと管理者ロールを確認する
- 無効化できないことを理解して検出を有効化する
- Microsoft managedテナントを分ける
- シグナル、直近の活動、方向、規模を確認する
- ユーザーやアプリへドリルダウンする
- 契約台帳や子会社一覧と照合する
- 許容、要管理、要隔離に分類する
- 確認済みのテナントだけに必要な対応を行う
最初の目標は、すべての検出対象を直ちに統制することではありません。まずは説明できない関連テナントを減らし、誰が所有し、何のために使われ、どのような接点があるのかを明確にすることが、マルチテナントガバナンスの第一歩です。
コメント