Azure ランディング ゾーンのテスト アプローチ
Note
この記事は、Microsoft Azure にのみ適用され、他の Microsoft Cloud オファリング (Microsoft 365 や Microsoft Dynamics 365 など) には適用されません。
組織によっては、Azure ランディング ゾーン プラットフォームをデプロイする際に、Azure Policy の定義と割り当てや、ロールベースのアクセス制御 (RBAC) のカスタム ロールと割り当てなどをテストすることが必要になる場合があります。 テストは、Azure Resource Manager テンプレート (ARM テンプレート)、Terraform、Bicepなどを使用して自動化で完了するか、あるいは Azure portal を利用して手動で完了できます。 このガイダンスでは、Azure ランディング ゾーン プラットフォームのデプロイにおける変更とその影響をテストするために使用できるアプローチについて説明します。
この記事は、PlatformOps および中心的な機能を担当するチームとそのタスクに関連しているため、プラットフォームの自動化と DevOps の重要な設計領域に関するガイダンスと共に使用することもできます。
このガイダンスは、運用環境の管理グループ階層への変更を管理する、堅牢な変更管理プロセスを備えた組織に最も適しています。 "カナリア" 管理グループ階層は、運用環境にデプロイする前に、そのデプロイを別個に作成およびテストするために使用できます。
Note
"カナリア" という用語は、開発環境やテスト環境との混同を避けるために使用されます。 この名前は説明の目的でのみ使用されています。 Azure ランディング ゾーンのカナリア環境に適していると思われる任意の名前を定義できます。
同様に、このガイダンス全体で使用される "運用環境" という用語は、自分の組織で整備している管理グループ階層を指すものです。この階層には、それぞれのワークロードに対応した Azure サブスクリプションやリソースが含まれます。
プラットフォームの定義
重要
このガイダンスは、ランディング ゾーン、ワークロード、アプリケーション、またはサービスと呼ばれる、アプリケーション所有者またはサービス所有者によって使用される開発環境やテスト環境向けではありません。 これらは、運用環境の管理グループ階層および関連するガバナンス (RBAC および Azure Policy) 内に配置され、処理されます。
このガイダンスは、Azure ランディング ゾーンのコンテキストにおけるプラットフォーム レベルのテストと変更にのみ対応しています。
ランディング ゾーンを大規模に構築して運用化するために、必要な Azure プラットフォームのコンポーネントを設計およびデプロイしやすいのが、エンタープライズ規模です。
この記事とこのテスト アプローチの対象範囲に含まれるプラットフォーム リソースは次のとおりです。
| 製品またはサービス | リソース プロバイダーと種類 |
|---|---|
| 管理グループ | Microsoft.Management/managementGroups |
| 管理グループのサブスクリプションの関連付け | Microsoft.Management/managementGroups/subscriptions |
| ポリシーの定義 | Microsoft.Authorization/policyDefinitions |
| ポリシー イニシアチブの定義またはポリシー セットの定義 | Microsoft.Authorization/policySetDefinitions |
| ポリシーの割り当て | Microsoft.Authorization/policyAssignments |
| RBAC ロールの定義 | Microsoft.Authorization/roleDefinitions |
| RBAC ロールの割り当て | Microsoft.Authorization/roleAssignments |
| サブスクリプション | Microsoft.Subscription/aliases |
シナリオと結果の例
このシナリオの例として、組織がポリシー主導型のガバナンス設計原則に従って、すべてのランディング ゾーン内のリソースと設定を管理する新しい Azure ポリシーの影響と結果をテストするケースを挙げることができます。 この組織では、運用環境への影響を懸念して、このような変更を運用環境に直接加えることは避けたいと考えています。
カナリア環境を使用してこのプラットフォームの変更をテストすることで、組織は Azure ポリシーの変更を実装し、その影響と結果を確認できるようになります。 このプロセスを使用すると、運用環境に Azure ポリシーを実装する前に、ポリシーが組織の要件を満たしていることを確認できます。
同様のシナリオとして、Azure RBAC ロールの割り当てと Microsoft Entra グループのメンバーシップの変更も挙げられます。 このケースでは、運用環境で変更を行う前に、ある種のテストが必要になる場合があります。
重要
これは大部分のお客様にとって、一般的なデプロイ アプローチおよびパターンではありません。 Azure ランディング ゾーンのデプロイでは必須ではありません。
"図 1: カナリア管理グループ階層。 "
図に示すように、Azure ランディング ゾーンの運用環境の管理グループ階層全体が、Tenant Root Group の下に複製されています。 "カナリア" という名前が、管理グループの表示名と ID の後ろに追加されています。 ID は、1 つの Microsoft Entra テナント内で一意である必要があります。
Note
カナリア環境の管理グループの表示名は、運用環境の管理グループの表示名と同じにすることができます。 これは、ユーザーの混乱を招くおそれがあります。 このため、ID だけでなく表示名の後ろにも "カナリア" という名前を付けることをお勧めします。
さらに、カナリア環境の管理グループ階層は、次のリソースの種類のテストを簡略化するために使用されます。
- 管理グループ
- サブスクリプションの配置
- RBAC
- ロール (組み込みとカスタム)
- 代入
- Azure Policy
- 定義 (組み込みとカスタム)
- イニシアチブ (セット定義とも呼ばれます)
- 代入
カナリア環境の管理グループ階層全体をデプロイしない場合
カナリア環境の管理グループ階層全体のデプロイを望まない場合は、図に示すようにサンドボックス サブスクリプションを使用して、運用環境の階層内のプラットフォーム リソースをテストできます。
"図 2: サンドボックスが強調表示されたエンタープライズ規模の管理グループ階層。 "
このシナリオで Azure ポリシーと RBAC をテストするには、ユーザー アカウント、サービス プリンシパル、マネージド サービス ID などとして、テストを完了する ID に対して所有者 RBAC ロールが割り当てられた単一の Azure サブスクリプションが必要です。 この構成を使用すると、サンドボックス サブスクリプションのスコープ内でのみ、Azure Policy の定義と割り当てを作成、割り当て、および修正できます。
このサンドボックス アプローチは、サブスクリプション内の RBAC のテストにも使用できます。たとえば、新しいカスタム RBAC ロールを作成して、特定のユース ケースにアクセス許可を付与する場合などです。 このテストはすべて、サンドボックス サブスクリプション内で実行してから、階層内で上位のロールを作成して割り当てることができます。
このアプローチの利点は、サンドボックスのサブスクリプションを必要な期間だけ使用したら、後は環境から削除できることです。
ただし、このアプローチでは、管理グループ階層から RBAC と Azure ポリシーを継承してテストすることはできません。
シングル Microsoft Entra テナントの使用
単一の Microsoft Entra テナントを使用する場合の考慮事項を次に示します。
- 複数の Microsoft Entra テナントの場合のエンタープライズ規模の設計に関する推奨事項に従います。
- 単一の Microsoft Entra テナントでは、運用環境と Azure ランディング ゾーンのカナリア環境の両方で、異なる Microsoft Entra グループを使用できます。同じ Microsoft Entra テナント内の関連する管理グループ階層に同じユーザーが割り当てられます。
- 異なる Microsoft Entra テナント間には複数の ID が存在するため、Microsoft Entra ID のライセンス コストが増加または重複します。
- この点は特に、Microsoft Entra ID P1 または P2 機能を使用するお客様にとって重要です。
- 両方の Microsoft Entra テナント間でユーザーとグループが同一ではない可能性があるため、カナリア環境と運用環境の両方で RBAC の変更がいっそう複雑になります。
- さらに、ユーザー ID とグループ ID は、グローバルに一意であるため、Microsoft Entra テナント間で同じになることはありません。
- 複数のMicrosoft Entra テナントを管理することによって生じる複雑さと管理のオーバーヘッドが軽減されます。
- 別々のテナントへのアクセス権を維持し、サインインしてテストを実行する必要のある特権ユーザーは、カナリア環境に変更を加えるのではなく、誤って運用環境 (あるいは、その逆) に変更を加えてしまうことがあります。
- 構成のずれやデプロイの失敗が発生する可能性を低減します。
- 追加のセキュリティや緊急アクセスのプロセスを作成する必要はありません。
- Azure ランディング ゾーンのデプロイに変更を実装するために必要な手間と時間が削減されます。
実装ガイダンス
以下に、運用環境の管理グループ階層と共に、Azure ランディング ゾーンのカナリア管理グループ階層を実装して使用する方法に関するガイダンスを示します。
警告
ポータルを使用して Azure ランディング ゾーン環境を現在デプロイおよび管理している場合は、運用環境とカナリア環境の両方が頻繁に同期されなくなるため、レプリカのような階層と運用環境が提供されないというリスクが高く、カナリア アプローチを効率的に導入して使用することが困難な場合があります。
このシナリオの場合は、上記のように、Azure ランディング ゾーンのコードとしてのインフラストラクチャ デプロイ アプローチに移行することを検討してください。 または、カナリアと運用環境の間の構成誤差の潜在的なリスクに注意し、注意を払って進めます。
- 関連する運用環境またはカナリア環境の管理グループ階層に対するアクセス許可が付与されている個別の Microsoft Entra サービス プリンシパル (SPN) または管理サービス ID (MSI) を使用します。
- このガイダンスは、最小特権の原則 (PoLP) に従っています
- Git リポジトリ内の個別のフォルダー、ブランチ、またはリポジトリを使用して、運用環境およびカナリア環境の Azure ランディング ゾーンのデプロイ用のコードとしてのインフラストラクチャを保持します。
- デプロイされている階層に応じて、関連する Microsoft Entra サービス プリンシパル (SPN) または管理サービス ID (MSI) を CI/CD パイプラインの一部として使用します。
- 運用環境に合わせて、カナリア環境の Git ブランチ ポリシーまたはセキュリティを実装します。
- カナリア環境がフェイルファストとなるように、承認者とチェックの数を減らすことを検討します。
- どちらの階層をデプロイするかを変更するために環境変数を使用する、同じ Azure Pipelines または GitHub Actions を使用します。 別の方法として、パイプラインを複製し、ハードコーディングされた設定を修正して、デプロイする階層を定義することもできます。
- Azure Pipelines DevOps テンプレートまたは GitHub Actions のワークフロー テンプレートを使用すると、"DRY (don't repeat yourself: 繰り返しを避ける) " 原則からの逸脱を防ぐことができます。
- 必要に応じてカナリア管理グループ階層内を移動できる別個の EA 部門とアカウントの下に、一連のカナリア サブスクリプションを用意します。
- 常に一連のリソースをカナリア環境のサブスクリプションにデプロイすると便利な場合があります。
- カナリア環境での変更を検証できるようにする一連のリソースを作成する、コードとしてのインフラストラクチャ テンプレート (ARM テンプレート、Bicep、Terraform など) を使用すると便利な場合があります。
- Azure ランディング ゾーンの設計に関する推奨事項に従って、カナリア環境サブスクリプションを含むすべての Azure サブスクリプションのすべての Azure アクティビティ ログを、運用環境の Azure Log Analytics ワークスペースに送信します。
ヒント
既に Azure ランディング ゾーンが運用環境にデプロイされていて、今後カナリア環境の追加を検討している場合。 運用環境階層の現在のデプロイを複製し、リソースの名前の前にカナリアの名前付けスキームのプレフィックスを付けて変更することを検討してください。
これは、カナリア環境の運用環境との同期を最初から実現するために、デプロイ対象を確実にするのが目的です。 これは、コードとしてのインフラストラクチャ ツールを Git リポジトリと共に使用する場合に簡単に実現できます。
次のステップ
ランディング ゾーン サンドボックス環境を実装する方法について学習します。