マルチテナント防衛組織のゼロ トラスト構成
この記事では、マルチテナント組織が Microsoft Entra ID の構成を適用し、ゼロ トラストによる防御の一般的な要件を満たす方法を示しています。 次の推奨事項に従って、適切なマルチテナント アイデンティティ アーキテクチャを確立し、環境にゼロ トラストを実装します。
図 1: ゼロ トラスト構成を使用したサンプルのマルチテナントの防衛アーキテクチャ。
ID アーキテクチャを決定する
Microsoft Entra テナントは ID アーキテクチャの基盤です。 テナントは Microsoft Entra ID の ID 境界です。 1 つの Microsoft Entra テナントを使う組織には、シングル テナント アーキテクチャがあります。 複数の Microsoft Entra テナントを使う組織には、マルチテナント アーキテクチャがあります。
シングル テナントの利点。 シングル テナントの方が、管理が容易で、運用効率により、コストも低くなります。 また、ゼロ トラスト環境もより簡単に構成できます。 シングル テナントでは、複数のサインイン資格情報によるユーザー エクスペリエンスの断片化が回避されます。 さらに、ソリューションのサイロ化を防ぐのに役立ち、これらを後で統合する必要がありません。 データ、Microsoft 365、Azure クラウド サービスをシングル テナントに含めるよう努める必要があります。 既に複数の Microsoft Entra テナントがある場合、環境を統合してシングル テナントを使うことを検討することをお勧めします。 テナントを統合するには、Azure サブスクリプションをセカンダリ テナントからプライマリ テナントに移転します。 詳細については、「Azure サブスクリプションを別の Microsoft Entra ディレクトリに移転する」を参照してください。
マルチテナントのユース ケース。 防衛組織がマルチテナント アーキテクチャを採用するの理由は様々です。 大規模で複雑な防衛組織には、セキュリティ、コンプライアンス、コラボレーションのための複数の Microsoft Entra テナントが必要な場合があります ("表 1 を参照")。
表 1 複数のテナントを持つ、または作成する理由。
| 理由 | 例 |
|---|---|
| プライバシーまたはセキュリティのためにデータをより細かく分離する必要がある | 監察総監室組織は独立している必要があります。 |
| 管理の委任とセグメント化 | ある組織が別の組織を管理することはできません。 |
| データの主権または所有権 | ある組織には、別の組織のデータを管理する法的権限がありません。 |
| ネットワークと IT 組織 | 複数の大企業のエンタープライズ IT アーキテクチャを 1 つのエンタープライズ アーキテクチャに統合することは不可能であり、好ましいことではありません。 |
| SOC の監視とインシデントへの対応 | SOC には、役割と責任を管理するための個別のテナントが必要です。 |
複数の Microsoft Entra テナントが必要な場合は、Microsoft Entra External ID (B2B) と Azure Lighthouse を使う必要があります。 これらの機能は、マルチテナントの防衛環境のサポートするのに役立ちます。 詳細については、「マルチテナント ソリューションのテナント モデル」を参照してください。
テナントの種類を特定する
マルチテナントの防衛組織は、使用するMicrosoft Entraのインスタンスをプライマリまたはセカンダリのいずれかに分類できます。 各組織は、1 つのテナントを特定し、プライマリ テナントとして指定する必要があります。 他のテナントはすべてセカンダリです。 "図 1" は、プライマリ テナントと "n" 個のセカンダリ テナント (図では 2 つのセカンダリ テナント) を含む防衛組織を示しています。
プライマリ テナントの特定。 ほとんどの防衛組織は、Microsoft 365 にサインアップする際にプライマリ テナントを作成します。 プライマリ テナントには、(1) すべてのユーザー ID と Microsoft 365 ライセンス、(2) デバイス、(3) アプリケーションが含まれます ("図 1 を参照")。 多くの場合、防衛組織は、Microsoft Entra Connect を使って、オンプレミスの Active Directory の ID をプライマリ Microsoft Entra テナントと同期します。
一部の防衛組織は、外部機関で所有および運用されている共有テナント内の Microsoft 365 を使用しています。 この機関は、Microsoft 365 の共有サービス プロバイダーとして機能します。 共有テナントは、組織で管理または制御されない場合もありますが、ユーザーが Office 365 やその他のアプリケーションに使用する可能性が高い、ライセンスされた Microsoft Entra ID が含まれています。 このシナリオでは、共有サービス プロバイダー テナントがプライマリ テナントです。
すべてのセカンダリ テナントの特定 (マルチテナントの場合)。 組織が管理する他のテナントはすべてセカンダリ テナントです。 エンタープライズ規模のランディング ゾーンを立ち上げる前にアプリケーションをクラウドに移行した場合、セカンダリ テナントが存在する可能性があります。 通常、セカンダリ テナントは、(4) 外部ユーザー (B2B ゲスト) のアカウントまたは (5) クラウド専用アカウントを管理するために使用されます ("図 1 を参照")。
デシジョン ツリーの使用。 最も簡単にプライマリ テナントを見つけるには、Microsoft Entra ID 内にある ID ライセンスを調べます。
Microsoft 365 ライセンスを持つテナントがプライマリ テナントです ("図 2 を参照")。 プライマリ テナントは、組織によって作成された最初のテナントではない可能性がありますが、すべてのユーザーと Microsoft 365 ライセンスを持つメイン テナントであるべきです。
組織が Microsoft 365 を使っていない場合、Enterprise Mobility + Security (EMS) ライセンスを持つ Microsoft Entra テナントがプライマリ テナントです。 このテナントは、組織のドメイン名を追加して検証したところです。 多くの場合、テナントは、ハイブリッド ID を使用するか、人事 (HR) システムと統合されます ("図 2 を参照")。
図 2. Microsoft Entra プライマリ テナントとセカンダリ テナントを決定するためのデシジョン ツリー。
Microsoft Entra ID をゼロ トラスト プラットフォームとして確立するには、ユーザー ID が設定され、ユーザーおよびデバイス ベースのアクセス ポリシーのライセンスが付与されたテナントが必要です。 Microsoft 365 ライセンスでは、これらのゼロ トラスト機能と Office 365 がバンドルされています。 Microsoft 365 を使用しない場合は、ゼロ トラストのためのクラウドベースの ID プロバイダーを確立するために、Enterprise Mobility + Security E5 を検討してください。 詳細については、「ID 機関の選択」を参照してください。
ゼロ トラストを構成する
Microsoft Entra ID で ID を管理する場合、テナントの種類ごとに次の推奨事項を考慮する必要があります。 最初に採用する必要があるすべてのテナントの種類について、一般的な推奨事項があります。 これらの一般的な推奨事項を実装した後、テナントの特定の種類 (プライマリまたはセカンダリ) に関する推奨事項を見つけ、それらの推奨事項を適用します。
ゼロ トラストで Microsoft Entra テナントをセキュリティで保護する方法の詳細については、「ゼロ トラストの迅速な近代化計画」および「セキュリティの迅速な近代化計画」を参照してください。
すべてのテナント
次の推奨事項は、すべての Microsoft Entra テナントに実装する必要があります。
緊急用のアクセス アカウントと手順を確立する。 Microsoft Entra テナントからロックアウトされないように、2 つ以上の緊急アクセス アカウントを作成します。 これらのアカウントには、グローバル管理者ロールを割り当てる必要があります。 アカウントは、クラウド専用アカウントである必要があります。 クラウド専用アカウントでは、*.onmicrosoft.com ドメインが使用されます。 詳細については、緊急アクセス用管理者アカウントの管理に関する記事を参照してください。
重要
Microsoft は、アクセス許可が最も少ないロールを使用することを推奨しています。 これにより、組織のセキュリティが向上します。 グローバル管理者は高い特権を持つロールであり、既存のロールを使用できない場合の緊急シナリオに限定する必要があります。
オンプレミスの攻撃から Microsoft Entra ID を保護します。 「特権アクセスの保護」で説明されているベスト プラクティスに従います。 ハードウェア パスキーや証明書ベースの認証などのフィッシングに強い資格情報を持つクラウド専用ユーザー アカウントにのみ Microsoft Entra のアクセス許可を割り当てます。 管理目的でフェデレーション ID を使用しないでください。 詳細については、「オンプレミスの攻撃から Microsoft 365 を保護する」を参照してください。
Privileged Identity Management を使用する。 Microsoft Entra ID と Azure のロールのロール割り当てを管理するには、Microsoft Entra Privileged Identity Management (PIM) を使います。 また、特権セキュリティ グループの適格なグループ メンバーシップの管理にも PIM を使用する必要があります。 臨時管理者および外部ユーザー (B2B ゲスト) に関する定期的なアクセス レビューを確立します。
すべてのユーザーに対してクラウドベースの認証を有効にする。 クラウドベースの認証方法は、フェデレーション認証よりも安全です。 この方法を Microsoft Entra 参加済みデバイスと組み合わせると、より優れたシングル サインオン エクスペリエンスが提供されます。 フェデレーション認証では、Microsoft Entra ID がオンプレミスの Active Directory の侵害にさらされます。
Microsoft Entra 証明書ベースの認証 (CBA) により、Microsoft Entra ドメインをフェデレーションする必要はなくなります。 Microsoft Entra 認証は、次のパスワードレス認証方法をサポートしています。
- パスキー (FIDO2 セキュリティ キー)
- 証明書ベースの認証
- Microsoft Authenticator
- Windows Hello for Business
条件付きアクセス ベースライン ポリシーを確立する。 条件付きアクセス ベースラインは、組織と要件によって異なります。 すべての Microsoft Entra テナント用の条件付きアクセス ポリシーのコア セットを確立します。 ポリシー設定内で、アイデンティティ、デバイス、アプリケーション、およびリスク条件を使用します。 条件付きアクセス ポリシーから緊急アクセス アカウントを除外します。
Microsoft Entra ID 保護は、組織が ID ベースのリスクを検出、調査、修復するのに役立ちます。 危険なサインインとユーザーを保護するには、リスク条件を含む条件付きアクセス ポリシーを作成します。 危険なサインインとユーザーには個別のポリシーを使用し、リスクの種類ごとにリスク レベルで適用されるコントロールを増やします。 ユーザーの生産性とセキュリティのバランスを取るため、リスクベースのポリシーでブロック コントロールは使用しないでください。
Note
ユーザーは、MFA を使用することでサインイン リスクを自己修復できます。 ユーザーがサインイン リスクを自己修復できるようにするには、サインイン リスクベースの条件付きアクセス ポリシーで認証強度付与コントロールを構成するか、MFA を構成します。
ユーザーは、パスワードを変更することでユーザー リスクを自己修復できます。 ユーザーがユーザー リスクを自己修復できるようにするには、パスワード変更の要求許可コントロールを含むユーザー リスクベースの条件付きアクセス ポリシーを構成します。
注意事項
Entra 証明書ベースの認証、パスキー、Windows Hello for Business などのパスワードなしの方法でのみサインインするパスワードレス ユーザーは、Microsoft Entra ID でパスワードをリセットできない場合、パスワード変更の要求許可コントロールによってブロックされる可能性があります。
条件付きアクセス ポリシーの例のチェックリストを使用して、組織の条件付きアクセス ポリシーを設計します (表 2 を参照)。 レポート専用モードを使用して、運用環境にデプロイする前に条件付きアクセス ポリシーをテストします。
表 2: 条件付きアクセス ポリシーのチェックリスト。
| ポリシー名 | ユーザー | アプリケーション | 条件 | 付与の制御 |
|---|---|---|---|---|
| すべてのユーザーに対する MFA | すべてのユーザー | すべてのアプリ | なし | - フィッシングに強い MFA |
| マネージド デバイスを必須にする | すべてのユーザー | すべてのアプリ | なし | - Microsoft Entra ハイブリッド参加済みまたは準拠デバイスが必要 |
| 中程度のサインインリスクを保護する | すべてのユーザー | すべてのアプリ | 中程度のサインインリスク | - フィッシングに強い MFA - 準拠しているデバイスを要求する - サインイン頻度: 1 時間 (組織のリスク許容度に応じて調整) |
| リスクの高いサインインを保護する | すべてのユーザー | すべてのアプリ | 高いサインインリスク | - フィッシングに強い MFA - 準拠しているデバイスを要求する - サインインの頻度: 毎回 |
| リスクの高いユーザーを保護する | すべてのユーザー | すべてのアプリ | 高いユーザー リスク | - フィッシングに強い MFA - 準拠しているデバイスを要求する - サインインの頻度: 毎回 |
| Microsoft Entra 管理をセキュリティで保護する | Microsoft Entra ロール | すべてのアプリ | なし | - フィッシングに強い MFA - デバイス フィルターを使用する準拠特権アクセス ワークステーション (PAW) が必要 |
| クラウド管理をセキュリティで保護する | すべてのユーザー | Azure の管理 Google Cloud Platform アマゾン ウェブ サービス |
なし | - フィッシングに強い MFA - デバイス フィルターを使用する準拠特権アクセス ワークステーション (PAW) が必要 |
表 2 に設定されているポリシーの例は、すべてのユーザーがマネージド デバイスからフィッシングに強い MFA のみを使用するパスワードレスの組織向けです。 特権ユーザーは、Intune で管理される特権アクセス ワークステーション (PAW) を使用します。 リスクの高いユーザーにパスワードの変更を要求する代わりに、危険なユーザー ポリシーにより認証強度とサインイン頻度制御が適用されます。 これらのコントロールにより一部が保護されますが、Microsoft Entra ID 保護でユーザーのリスク レベルを修復することはありません。 セキュリティ運用チームがリスクの高いユーザーを調査して、修復を行う必要があります。
条件付きアクセスのデプロイについての詳細は、「条件付きアクセスのデプロイを計画する」を参照してください。
すべてのアプリケーションへのアクセスにプライマリ テナント ID を使用する。 ユーザーは、プライマリ テナント内の ID を使用してアプリケーションにアクセスできる必要があります。 このため、アプリケーションをプライマリ テナントに登録する必要があります。 アプリケーション インストラクチャをホストしている場所に関係なく、プライマリ テナントにアプリケーションを登録するためのポリシーを確立します。
最新の認証プロトコルをサポートしないレガシ アプリケーションの場合は、プライマリ テナントで Microsoft Entra アプリケーション プロキシ サービスを使います。 Microsoft Entra アプリケーション プロキシを使うと、コードを変更することなく、既存のレガシ アプリケーションで Microsoft Entra のゼロ トラスト機能を実現できます。
共有サービス プロバイダーまたは外部機関がプライマリ テナントを制御する場合、アプリケーション登録のアクセス許可を委任する必要があります。 サービス プロバイダーからこの委任が提供されない場合は代わりに、組織が制御するセカンダリ テナントにアプリケーションを登録する必要があります。 ただし、ユーザーは、セカンダリ テナントに新しい ID を作成せずに、これらのアプリケーションに引き続きアクセスする必要があります。 このセットアップでは、プライマリ テナント内のユーザーの外部 ID (B2B ゲスト) を使用してユーザー アクセスを割り当てます。 詳細については、「ゼロ トラストによるアプリケーションのセキュリティ保護」を参照してください。
Microsoft Entra ID を使って他のクラウド環境を管理する。 Microsoft Entra ID は、単に Azure と Microsoft 365 用の ID プラットフォームではありません。 Microsoft Entra ID を使って他のクラウド環境にアクセスできるようにしてください。 これらの環境には、一般的なサービスとしてのソフトウェア (SaaS) 製品と、アマゾン ウェブ サービス (AWS) や Google Cloud Platform (GCP) などのクラウド プラットフォームが含まれます。 詳細については、Microsoft Entra アプリケーション ギャラリーに関する記事を参照してください。
Secure Cloud Computing Architecture (SCCA) を使用する。 各防衛組織は、SCCA 準拠のランディング ゾーン アーキテクチャをデプロイする必要があります。 ランディング ゾーンは、プライマリ テナントにアタッチされている Azure サブスクリプションに存在する必要があります。
シングル テナント内で Azure リソース管理をセグメント化する。 エンタープライズ規模の Azure ランディング ゾーン内でのサブスクリプションのリソースおよび管理の分離には、Azure ローズを使用する必要があります。 セカンダリ テナントからプライマリ テナントへのサブスクリプションの移転を検討します。
Microsoft Entra Permissions Management を使用する。 Microsoft Entra Permissions Management は、Microsoft のクラウド インフラストラクチャ エンタイトルメント管理 (CIEM) ソリューションです。 すべての ID に割り当てられているアクセス許可の表示には、Microsoft Entra Permissions Management を使う必要があります。 また、組織のマルチクラウド環境全体でのアクセス許可クリープの追跡にも、これを使用する必要があります。
Microsoft Entra ID Governance を使う。 Microsoft Entra ID Governance を使って、ユーザーおよびゲストのアクセス割り当てのライフサイクルを自動化します。 アクセス レビューを実施して、不要になったユーザーによるクラウド環境へのアクセスを削除します。
ワークロード ID のセキュリティ保護。 Microsoft Entra Workload ID 機能を使って、Microsoft Entra ID 内のアプリケーション ID (サービス プリンシパル) の適応型ゼロ トラスト ポリシーを管理および適用します。
エンタープライズに対して Defender for Cloud を有効にする。 マルチクラウド環境用の Defender for Cloud を使用します。 必ず、強化されたセキュリティ機能をオンにして、Azure リソースを監視し、構成リスクを修復します。 Defender for Cloud 保護は Azure を超えて拡張されており、ハイブリッドおよびマルチクラウドの環境をセキュリティで保護するのに役立ちます。
Sentinel をデプロイし、すべての使用可能なデータ ソースを接続します。 Microsoft Sentinel などの SIEM でセキュリティシグナルを集約します。 Sentinel をデプロイし、データ コネクタを構成して、すべてのセキュリティ シグナル データ ソースを接続します。
プライマリ テナント
次の推奨事項は、プライマリ テナントにのみ実装する必要があります。
エンド ユーザーは Entra ID に 1 つの ID しか持っていない。 オンプレミスの Active Directory Domain Services をプライマリ Microsoft Entra テナントと同期します。 この同期により、組織のユーザー、グループ、デバイスが Microsoft Entra ID に設定されます。 外部 B2B ゲストはセカンダリ テナントに存在する場合がありますが、ユーザーは、すべてのアプリケーションおよびサービスに対して 1 つのユーザー名のみを覚えておくだけで済みます。 Windows サインインとアプリケーション アクセスにプライマリ テナントの ID を使用すると、ユーザー エクスペリエンスとゼロトラストの結果が最適になります。
プライマリ テナントでデバイスを参加させ管理する。 プライマリ Microsoft Entra テナントには、組織内のすべてのユーザーとデバイスが含まれます。 Microsoft Entra Join (または Hybrid Microsoft Entra Join) Windows デバイスをプライマリ テナントに参加させ、Microsoft Intune で管理します。 Intune ポリシーを使用して Microsoft Defender for Endpoint をデプロイし、拡張検出と応答 (XDR) 機能を有効にします。
アプリケーション登録のアクセス許可を委任する。 Azure サブスクリプションで実行されているアプリケーション コードを含むエンタープライズ アプリでは、ユーザー ID にプライマリ Microsoft Entra ID が使われます。 Privileged Identity Management を使って、開発者にアプリケーション開発者 Microsoft Entra ロールまたはカスタム アプリ登録ロールの資格を付与します。 この構成により、セカンダリ テナントでアプリケーションを構築する開発者は、ID のためにプライマリ テナントに登録できます。
エンド ユーザー ID を必要とするサービスとしてのプラットフォーム (PaaS) サービスをアタッチする。 Azure Files や Azure Virtual Desktop などの一部の PaaS サービスは、ハイブリッド ID 構成またはライセンス エンタイトルメントに依存します。 これらのサービスをプライマリ テナント内の Azure サブスクリプションにデプロイする必要があります。
セカンダリ テナント
セカンダリ テナントには、次の推奨事項を実装する必要があります。
Microsoft Entra 管理に必要なライセンスを調達します。 セカンダリ テナントで高度なセキュリティ機能を有効にするには、ライセンスが必要です。 ユーザー、ワークロード、デバイスに必要なライセンスを検討します。
ユーザー ID。 テナント管理者および緊急アクセス用アカウントには、Microsoft Entra ID Premium P2 ライセンスが必要です。 外部 ID (B2B ゲスト) 管理モデルを使用する場合は、テナント内のローカル ユーザーに少なくとも 1 つの Microsoft Entra ID Premium P2 ライセンスを割り当てる必要があります。 このセットアップにより、条件付きアクセスやIdentity Protection などの Premium 機能を有効にすることができます。 詳細については、「マルチテナントのユーザー管理に関する一般的な考慮事項」を参照してください。
ワークロード ID。 ワークロード ID Premium を使用して、プライマリ テナント内のリソース (MS Graph API など) へのアクセス権を持つワークロード ID をセキュリティで保護する必要があります。
デバイスの管理。 セカンダリ テナントで Microsoft Intune を使用して、デバイスを管理する必要がある場合があります。 その場合、Enterprise Mobility + Security (EMS) ライセンスを調達する必要があります。
テナント間アクセス ポリシー (XTAP) を構成する。 Microsoft Entra 外部 ID (Microsoft Entra B2Bコラボレーション) のテナント間アクセス設定により、セカンダリ テナントでは、ホーム プライマリ テナントからの特定のクレームを信頼することができます。 プライマリ Microsoft Entra テナントを組織として追加し、受信信頼設定を更新して次のものを含めます。
- Microsoft Entra テナントからの多要素認証 (MFA) を信頼する
- 準拠デバイスを信頼する
- Microsoft Entra ハイブリッド参加済みデバイスを信頼する
- 省略可能: テナントで招待を自動的に引き換える
セカンダリ テナントをプライマリ テナントの ID で管理する。 プライマリ テナントの外部ユーザー (B2B ゲスト) を使用してセカンダリ テナントと Azure リソースを管理することにより、管理のオーバーヘッドとコストを削減します。 Microsoft Entra Privileged Identity Management を使って、タスクによる最小特権の Microsoft Entra ロールに従って Microsoft Entra ロールを割り当てます。 エンドユーザー開始アクセスまたはテナント間同期を使用して、セカンダリ テナントの外部 ID をオンボードする管理オーバーヘッドを軽減します。
Azure Lighthouse を使用して、プライマリ テナントからの Sentinel アクセスを容易にする。 Azure Lighthouse では、テナント間で Azure を管理する別の方法が用意されています。 Azure Lighthouse では、Azure Resource Manager (ARM) テンプレートを使用して、外部テナントの ID に Azure ロールを割り当てます。 このアプローチではB2Bゲストユーザーオブジェクトは使用しません。 管理者がポータルにサインインして Azure を管理すると、すべてのテナントのすべてのリソースを見ることができます。 この統合されたビューには、Azure Lighthouse によって割り当てられたアクセス許可を持つサブスクリプションが含まれます。 B2B ゲスト オブジェクトがないため、管理者はディレクトリを切り替える必要はありません。 Azure Lighthouse を使用して、テナント間での Microsoft Sentinel の管理を容易にします。