複数のテナントにまたがる Azure ランディング ゾーンを自動化する

組織に複数の Microsoft Entra テナントがあり、それぞれに 1 つまたは複数の Azure ランディング ゾーン (ALZ) がある場合は、自動化が鍵となります。 自動化は、すべてのテナントにまたがる大規模な ALZ デプロイを正常に運用および維持するのに役立ちます。 複数のテナントにまたがる ALZ デプロイを自動化するには、多くのアプローチがあります。 使用するアプローチは、組織に複数の Microsoft Entra テナントがある理由によって異なります。

たとえば、独立系ソフトウェア ベンダーの場合は、複数の Microsoft Entra テナントを持っている可能性があります。 企業と SaaS のソリューションで、Microsoft Entra テナントを分けておきたい場合があります。 意図したものか誤ったものかに関係なく、操作またはデプロイが他のテナントに影響を与えるリスクが軽減されます。

次のセクションでは、実行可能なアプローチに関する図とガイダンスを示します。 複数の Microsoft Entra テナントを扱うときは、Azure ランディング ゾーンのデプロイの自動化に関する要件、考慮事項、推奨事項に基づいて、最適な方法を選んでください。

アプローチ

複数の Microsoft Entra テナントにまたがる Azure ランディング ゾーンのデプロイを自動化するには、2 つの方法があります。

アプローチ 1 – 完全な分離は、マルチテナント シナリオで最も一般的なアプローチです。 この方法では、Microsoft Entra テナント間で必要な分離と隔離が維持されます。これは、マルチテナント アプローチを使うときの最も一般的な要件です。

アプローチ 2 – 複数のサービス プリンシパルを持つ共有アプリケーションの登録 (マルチテナント) は、マネージド サービス プロバイダー (MSP) のシナリオでよく使用されます。 このアプローチでは、デプロイ スタンプ パターンを使用して、大規模な複数のテナント間でほぼ同じアーキテクチャのデプロイを自動化できます。

これらのアプローチはどちらも、例およびインスピレーションとして提供されています。 組織の要件に基づいて、デプロイのアプローチを組み合わせることができます。

重要

この記事では、組織が持つ各 Microsoft Entra テナントでのプラットフォームとしての Azure ランディング ゾーンのデプロイと操作の自動化について説明します。 この記事のアプローチ、推奨事項、および考慮事項は、サービスとアプリケーションをランディング ゾーン (サブスクリプション) にデプロイして運用するアプリケーション チームが使用することを意図したものではありません。 さまざまな種類のランディング ゾーンの詳細については、「プラットフォームとアプリケーションのランディング ゾーン」を参照してください。

アプローチ 1 – 完全な分離

この方法の主な目的は、次のようなすべての自動化コンポーネントで、各 Microsoft Entra テナントの相互の分離を維持することです。

  • Git リポジトリ:
  • GitHub Actions または Azure Pipelines (利用されている場合はセルフホステッド ランナーを含む)。
  • セルフホステッド ランナーに割り当てられたマネージド ID、サービス プリンシパル名 (SPN)、ユーザー、管理者など、自動化からのタスクの実行に使用される ID。

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed using the complete isolation automation approach.

この方法では、Microsoft Entra テナントごとに重複する管理すべきコンポーネントが増えます。 一部の組織では、この種の分離と隔離を義務付ける規制コンプライアンス コントロールが適用されている場合があります。

注意

組織でプラットフォームの自動化にマネージド ID の使用のみを許可している場合は、このアプローチまたは各テナントに個別にログインするアプローチを使用する必要があります。 マネージド ID では、テナント間シナリオはサポートされていません。 詳細については、この FAQ を参照してください。

プラットフォームの管理者と開発者向けの ID - アプローチ 1

この方法では、ID も各 Microsoft Entra テナントで分離する必要があります。つまり、各プラットフォームの管理者または開発者は、テナント内で操作を実行するために、各テナント内で個別のユーザー アカウントが必要となります。 これらのアカウントは、テナントごとに GitHub や Azure DevOps などの開発者ツールにアクセスするためにも使用されます。 このアプローチに従って、管理者と開発者の生産性への影響を慎重に検討してください。

Microsoft Entra B2B と Azure Lighthouse のどちらかまたは両方を使うことができますが、このオプションでは、個別の Microsoft Entra テナントを使用する根拠が問われます。

アプローチ 2 – 複数のサービス プリンシパルを持つ共有アプリケーションの登録 (マルチテナント)

この方法では、管理している Microsoft Entra テナントにアプリケーションの登録が作成されます。 管理対象のすべての Microsoft Entra テナントで、アプリケーションの登録に基づいて、そのテナントにサービス プリンシパル名 (SPN) が作成されます。 このアクションにより、パイプライン タスクとステップを実行している worker は、1 つの資格情報セットを使って任意の Microsoft Entra テナントにサインインできます。

ヒント

アプリケーションの登録とエンタープライズ アプリケーション (サービス プリンシパル) の間の関係については、「Microsoft Entra ID のアプリケーションとサービス プリンシパル オブジェクト」をご覧ください。

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed using the shared application registration (multi-tenant) with multiple service principals automation approach.

重要

このアプローチでは、1 つのアプリケーションの登録と、関連するエンタープライズ アプリケーション (サービス プリンシパル) は高い特権を持つアカウントであるため、セキュリティ情報およびイベント管理 (SIEM) ツールで異常なアクティビティを監視する必要があります。 アラートを送信し、アラートの重大度に応じて自動的にアクションを実行する必要があります。

前の例では、1 つのアプリ登録が contoso.onmicrosoft.com Microsoft Entra テナントにあり、そのアプリ登録にリンクされた Microsoft Entra テナントごとにエンタープライズ アプリケーションがあります。 このセットアップにより、パイプラインで、1 つのアプリ登録を使って、すべての Microsoft Entra テナントに対する認証と認可を行うことができます。 詳しくは、「アプリケーションのマルチテナント化」を参照してください。

一元化されたパイプラインを使用する場合は、Microsoft Entra テナントとその他のメタデータ (環境、関連付けられているサブスクリプション、組織名、認証と認可に使用される ID オブジェクト ID など) を関連付けるデータを含む小さなマッピング テーブルの作成が必要になる場合があります。 このデータは、パイプラインの実行中に、何らかのロジックと条件を使ってデプロイ先の Microsoft Entra テナントと ID を制御するステップで、呼び出すことができます。 このデータは、Azure Cosmos DB や Azure Table Storage などのサービスに格納できます。

開発、テスト、運用など、複数の環境を処理する場合は、パイプラインで同じまたは個別のアプリケーションの登録とエンタープライズ アプリケーションを使用することで、同じ方法で制御できます。

Microsoft Entra テナントごとに個別のパイプラインを用意するか、1 つのパイプラインを使用するかを決める場合があります。 この選択は、要件に基づいて行います。

注意

Azure Lighthouse はこのアプローチと同様に機能しますが、Azure Lighthouse では、RBAC 所有者、ユーザー アクセス管理者、および DataActions アクセス許可を持つロールの割り当ては許可されません。 詳細については、「Azure Lighthouse 用のロールのサポート」を参照してください。

通常、すべての Azure ランディング ゾーンのデプロイ シナリオで、所有者とユーザーのアクセス ロールが必要になります。 この要件により、Azure Lighthouse は、プラットフォームへの Azure ランディング ゾーンの全体的なデプロイの自動化という側面では選択肢から外れますが、一部のシナリオでは引き続き役立ちます。 詳細については、ALZ マルチテナントでの Azure Lighthouse の使用に関する記事を参照してください。

プラットフォームの管理者と開発者向けの ID - アプローチ 2

この方法では、プラットフォーム管理者と開発者は、通常、管理している Microsoft Entra テナントにのみアクセスする必要があります。 このアクセスにより、すべてのテナントをデプロイおよび操作する開発者ツール (GitHub や Azure DevOps など) へのアクセス権が付与されます。

Microsoft Entra B2B または Azure Lighthouse を介して、他の Microsoft Entra テナントにアクセスできる場合があります。 管理テナントと同じアカウントを使用するか、最初のアプローチの例のように個別のアカウントを持つ場合があります。

次のステップ