複数のテナント間で Azure ランディング ゾーンを自動化する
組織のそれぞれに Azure ランディング ゾーン (ALZ) を持つ複数の Microsoft Entra テナントがある場合、1 回または複数回、自動化が重要です。 自動化は、すべてのテナントで大規模な ALZ デプロイを正常に運用し、維持するのに役立ちます。 複数のテナントにまたがる ALZ デプロイを自動化する方法は多数あります。 実行する方法は、組織に複数の Microsoft Entra テナントがある理由によって異なります。
たとえば、独立系ソフトウェア ベンダーの場合、複数の Microsoft Entra テナントがあるとします。 企業と SaaS ソリューションの Microsoft Entra テナントを分離しておく必要がある可能性があります。 他のテナントに影響を与える操作やデプロイのリスクは、意図的または間違いによる場合でも軽減されます。
次のセクションでは、実行できる方法に関する図とガイダンスを示します。 複数の Microsoft Entra テナントを処理するときに、Azure ランディング ゾーンのデプロイを自動化するための要件、考慮事項、推奨事項に基づいて、最適な方法を選択します。
手記
Microsoft Entra テナントの概要については、まず次の記事を参照してください。
アプローチ
複数の Microsoft Entra テナントにまたがる Azure ランディング ゾーンのデプロイを自動化するには、2 つの方法があります。
アプローチ 1 – マルチテナント シナリオで最も一般的なアプローチは、完全な分離 です。 このアプローチにより、Microsoft Entra テナント間で必要な分離と分離が維持されます。これは、マルチテナント アプローチを使用する場合に最も一般的な要件です。
アプローチ 2 – 複数のサービス プリンシパルを持つ共有アプリケーション登録 (マルチテナント) は、マネージド サービス プロバイダー (MSP) のシナリオでよく使用されます。 このアプローチでは、デプロイ スタンプ パターン を使用して、大規模な複数のテナント間でほぼ同じアーキテクチャのデプロイを自動化できます。
これらのアプローチはどちらも、例とインスピレーションとして提供されています。 組織の要件に基づいて、デプロイのアプローチを組み合わせることができます。
重要
この記事では、組織が持つ各 Microsoft Entra テナントのプラットフォームとしての Azure ランディング ゾーンのデプロイと操作を自動化する方法について説明します。 この記事のアプローチ、推奨事項、および考慮事項は、 サービスやアプリケーションをランディングゾーン（サブスクリプション）にデプロイして運用するアプリケーションチームでは使用することを意図していません。 さまざまな種類のランディング ゾーンの詳細については、「プラットフォームとアプリケーションランディング ゾーンの」を参照してください。
アプローチ 1 – 完全な分離
このアプローチでは、主な目的は、次のようなすべての自動化コンポーネント間で各 Microsoft Entra テナントを相互に分離し続けることです。
- Git リポジトリ。
- GitHub Actions または Azure Pipelines (利用されている場合はセルフホステッド ランナーを含む)。
- セルフホステッド ランナーに割り当てられたマネージド ID、サービス プリンシパル名 (SPN)、ユーザー、管理者など、自動化からタスクを実行するために使用される ID。
この方法では、管理するコンポーネントが Microsoft Entra テナントごとに重複しています。 一部の組織では、この種の分離と分離を義務付ける規制コンプライアンス制御が適用されている場合があります。
手記
組織でプラットフォームの自動化にマネージド ID の使用のみを許可している場合は、このアプローチまたは各テナントに個別にログインするアプローチを使用する必要があります。 マネージド ID は、現在一般公開されている状態のテナント間シナリオをサポートしていません。 詳細については、この FAQ
ただし、これは、それ自体と Entra ID マルチテナント アプリケーションの間の信頼を構成することで、User-Assigned マネージド ID のパブリック プレビューで使用できるようになりました。 これを構成する方法の詳細については、「マネージド ID (プレビュー)を信頼するようにアプリケーションを構成する」を参照してください。 これにより、「アプローチ 2 - 複数のサービス プリンシパルを使用した共有アプリケーションの登録 (マルチテナント)」が、デプロイの実行可能なオプションとして使用できるようになりました。
プラットフォーム管理者と開発者の ID - アプローチ 1
この方法では、各 Microsoft Entra テナントで ID を分離する必要もあります。つまり、各プラットフォーム管理者または開発者は、そのテナント内で操作を実行するために、各テナント内で個別のユーザー アカウントを必要とします。 これらのアカウントは、テナントごとに、GitHub や Azure DevOps などの開発者ツールにアクセスするためにも使用されます。 このアプローチに従って、管理者と開発者の生産性の影響を慎重に検討してください。
Microsoft Entra B2B または Azure Lighthouse を使用できますが、このオプションでは、個別の Microsoft Entra テナントを持つ理由が疑問になります。
アプローチ 2 – 複数のサービス プリンシパルを使用した共有アプリケーションの登録 (マルチテナント)
この方法では、管理している Microsoft Entra テナントにアプリケーション登録が作成されます。 管理するすべての Microsoft Entra テナントでは、アプリケーションの登録に基づいて、そのテナントにサービス プリンシパル名 (SPN) が作成されます。 このアクションにより、パイプライン タスクとステップを実行しているワーカーは、1 つの資格情報セットを使用して任意の Microsoft Entra テナントにサインインできます。
ヒント
アプリケーションの登録とエンタープライズ アプリケーション (サービス プリンシパル) の関係については、「アプリケーションオブジェクトとサービス プリンシパル オブジェクト 」を参照してください。Microsoft Entra ID。
重要
この方法では、1 つのアプリケーション登録と関連するエンタープライズ アプリケーション (サービス プリンシパル) が、セキュリティ情報およびイベント管理 (SIEM) ツールの異常なアクティビティを監視する必要があります。これは高い特権を持つアカウントであるためです。 アラートを送信し、アラートの重大度に応じて自動的にアクションを実行する可能性があります。
前の例では、1 つのアプリ登録が Microsoft Entra テナント contoso.onmicrosoft.com にあり、エンタープライズ アプリケーションは、アプリ登録にリンクされている各 Microsoft Entra テナントにあります。 このセットアップにより、パイプラインは、1 つのアプリ登録を使用して、すべての Microsoft Entra テナントに対して認証と承認を行います。 詳細については、「アプリケーションのマルチテナント の作成」および「アプリケーションにテナント全体の管理者の同意を付与する」を参照してください。
ヒント
パブリック プレビューのユーザー割り当てマネージド ID では、それ自体と Entra ID マルチテナント アプリケーションの間の信頼を構成することで、マルチテナント シナリオをサポートできるようになりました。 これを構成する方法の詳細については、「マネージド ID (プレビュー)を信頼するようにアプリケーションを構成する」を参照してください。
一元化されたパイプラインを使用する場合は、Microsoft Entra テナントとその他のメタデータ (環境、関連付けられているサブスクリプション、組織名、認証と承認に使用される ID オブジェクト ID など) を関連付けるデータを含む小さなマッピング テーブルを作成することが必要になる場合があります。 パイプラインの実行中に、このデータは、いくつかのロジックと条件を使用して、どの Microsoft Entra テナントにデプロイし、どの ID で制御するかを決定する手順で呼び出すことができます。 データは、Azure Cosmos DB や Azure Table Storage などのサービスに格納できます。
開発、テスト、運用環境など、複数の環境を処理する場合は、パイプラインを使用して同じ、または個別のアプリケーション登録とエンタープライズ アプリケーションを使用して、同じ方法で制御できます。
Microsoft Entra テナントごとに個別のパイプラインを用意するか、1 つのパイプラインを使用するかを決定できます。 あなたの要件に基づいて選択してください。
手記
Azure Lighthouse はこの方法と同様に機能しますが、Azure Lighthouse では、DataActions アクセス許可を持つ RBAC 所有者、ユーザー アクセス管理者、ロールの割り当ては許可されません。 詳細については、Azure Lighthouseの
所有者とユーザーのアクセス ロールは、通常、すべての Azure ランディング ゾーンのデプロイ シナリオで必要です。 この要件により、Azure ランディング ゾーンのプラットフォーム自動化デプロイの側面全体のオプションとして Azure Lighthouse が削除されますが、一部のシナリオでは引き続き役立ちます。 詳細については、ALZ マルチテナントでの Azure Lighthouse の使用
プラットフォーム管理者と開発者の ID - アプローチ 2
このアプローチでは、プラットフォーム管理者と開発者は通常、管理している Microsoft Entra テナントにのみアクセスする必要があります。 このアクセスにより、すべてのテナントがデプロイおよび運用される開発者ツール (GitHub や Azure DevOps など) へのアクセス権が付与されます。
Microsoft Entra B2B または Azure Lighthouse を介して、他の Microsoft Entra テナントにアクセスできます。 管理テナントから同じアカウントを使用するか、最初のアプローチの例