次の方法で共有

エンタープライズ シナリオにおける Azure Lighthouse

  • [アーティクル]

Azure Lighthouse の一般的なシナリオには、顧客の Microsoft Entra テナント内のリソースを管理するサービス プロバイダーが含まれます。 Azure Lighthouse の機能を使うと、複数の Microsoft Entra テナントを使用する企業内のテナント間の管理を簡略化することもできます。

シングル テナントと複数テナント

ほとんどの組織では、1 つの Microsoft Entra テナントの方が管理が簡単です。 1 つのテナント内にすべてのリソースを配置することで、そのテナント内の指定されたユーザー、ユーザー グループ、またはサービス プリンシパルによる管理タスクを一元化できます。 可能な場合は、組織で 1 つのテナントを使用することをお勧めします。

組織によっては、複数の Microsoft Entra テナントを使う必要がある場合があります。 これは一時的な状況の場合があります。買収が行われ、長期的なテナント統合戦略がまだ定義されていない場合などです。 また、場合によっては、組織が複数のテナントを継続的に管理する必要があります (完全に独立した子会社、地理的または法的な要件や、その他の考慮事項のため)。

マルチテナント アーキテクチャが必要な場合は、Azure Lighthouse を利用することで管理操作の一元化と合理化が容易になります。 Azure Lighthouse を使用すると、ある管理テナント内のユーザーが、一元管理されたスケーラブルな方法でテナントにまたがる管理機能を実行できます。

テナント管理のアーキテクチャ

エンタープライズで Azure Lighthouse を使用するには、他のテナントに対する管理操作を実行するユーザーをどのテナントに含めるかを決定する必要があります。 言い換えると、1 つのテナントを他のテナントの管理テナントとして指定する必要があります。

たとえば、組織に 1 つのテナントがあるとします。ここでは、Tenant A と呼びます。その後、その組織は Tenant B と Tenant C を取得します。これらを個別のテナントとして維持する必要があるビジネス上の理由があります。 ただし、それらのすべてに同じポリシー定義、バックアップ プラクティス、セキュリティ プロセスを使用し、管理タスクを同じ一連のユーザーで実行する必要があります。

テナント A にはテナント A のそれらのタスクを実行している組織内のユーザーが既に含まれているため、テナント B とテナント C 内のサブスクリプションをオンボードすることができます。これにより、テナント A の同じユーザーがすべてのテナントでそれらのタスクを実行できるようになります。

テナント B とテナント C のリソースを管理するテナント A のユーザーを示す図。

セキュリティとアクセスに関する考慮事項

ほとんどのエンタープライズ シナリオでは、Azure Lighthouse に完全なサブスクリプションを委任することをお勧めします。 サブスクリプション内の特定のリソース グループだけを委任することもできます。

いずれの場合も、委任されたリソースにアクセスできるユーザーを定義する際には、必ず最小限の特権の原則に従ってください。 こうすることで、ユーザーが必要なタスクを実行するために必要なアクセス許可のみを持ち、不注意によるエラーが発生する可能性を減らすことができます。

Azure Lighthouse では、データやリソースを物理的に移動するのではなく、管理側テナントと管理対象テナントの間に論理的なリンクのみを提供します。 さらに、アクセスは、常に管理側テナントから管理対象テナントへの一方向のみです。 マネージド テナントのリソースに対して管理操作を実行する場合、管理側テナントのユーザーとグループは多要素認証を使用する必要があります。

内部または外部のガバナンスとコンプライアンスのガードレールを持つ企業の場合、Azure アクティビティ ログを使用して透過性の要件を満たすことができます。 エンタープライズのテナントが管理側と管理対象のテナントのリレーションシップを確立すると、各テナントのユーザーは、ログに記録されたアクティビティを表示することで、管理側テナントのユーザーが実行したアクションを確認できます。

オンボードの考慮事項

サブスクリプション (またはサブスクリプション内のリソース グループ) を Azure Lighthouse にオンボードするには、Azure Resource Manager テンプレートをデプロイするか、Azure Marketplace に発行されたマネージド サービス オファーを使用します。

通常、エンタープライズ ユーザーはエンタープライズのテナントに直接アクセスでき、管理オファリングを市場に投入したり宣伝したりする必要がないので、通常は、Azure Resource Manager テンプレートをデプロイする方がより高速で簡単です。 オンボード ガイダンスではサービス プロバイダーと顧客の場合について説明していますが、エンタープライズは同じプロセスを使用してテナントをオンボードできます。

必要に応じて、マネージド サービス オファーを Azure Marketplace に公開して、企業内のテナントをオンボーディングすることもできます。 オファーが適切なテナントでのみ利用できるようにするには、必ずプランを非公開とマークします。 非公開プランの場合、オンボードする予定の各テナントのサブスクリプション ID を指定します。また、他のユーザーはあなたのプランを取得できなくなります。

Azure AD B2C

Azure Active Directory B2C (Azure AD B2C) は、サービスとしての企業-消費者間 (B2C) ID が提供されます。 Azure Lighthouse を使用してリソース グループを委任すると、Azure Monitor を使用して、Azure Active Directory B2C (Azure AD B2C) のサインインと監査ログをさまざまな監視ソリューションにルーティングできます。 そのログを、長期的な使用のために保持したり、サードパーティのセキュリティ情報およびイベント管理 (SIEM) ツールと統合して環境の分析情報を取得したりすることができます。

詳細については、「Azure Monitor で Azure AD B2C を監視する」を参照してください。

用語に関する注意事項

エンタープライズ内でのクロステナント管理の場合、Azure Lighthouse ドキュメント内のサービス プロバイダーに関する説明を理解すると、エンタープライズ内の管理側テナト (つまり、Azure Lighthouse を使用して、他のテナント内のリソースを管理するユーザーを含むテナント) に適用することができます。 同様に、顧客に関する説明を理解すると、管理側テナントのユーザーによって管理されるリソースを委任するテナントに適用することができます。

たとえば、上記の例では、テナント A はサービス プロバイダー テナント (管理側テナント)、テナント B とテナント C は顧客テナントと考えることができます。

またこの例では、適切なアクセス許可を持つテナント A のユーザーは、Azure portal の [マイ カスタマー] ページで、委任されたリソースを表示および管理できます。 同様に、適切なアクセス許可を持つテナント B とテナント C のユーザーは、Azure portal の [サービス プロバイダー] ページで、テナント A に委任されたリソースを表示および管理できます。

次のステップ