注
この記事は、Microsoft Azure にのみ適用され、他の Microsoft Cloud オファリング (Microsoft 365 や Microsoft Dynamics 365 など) には適用されません。
一部の組織では、Azure ランディング ゾーン プラットフォーム デプロイの Azure Policy の定義と割り当て、ロールベースのアクセス制御 (RBAC) カスタム ロールと割り当てをテストしたい場合があります。 テストは、Azure Resource Manager テンプレート (ARM テンプレート)、Terraform、Bicepなどを使用して自動化で完了するか、あるいは Azure portal を利用して手動で完了できます。 このガイダンスでは、Azure ランディング ゾーン プラットフォームのデプロイに対する変更とその影響をテストするために使用できるアプローチを提供します。
この記事は、PlatformOps および中心的な機能を担当するチームとそのタスクに関連しているため、プラットフォームの自動化と DevOps の重要な設計領域に関するガイダンスと共に使用することもできます。 さらに、Azure ランディング ゾーンのデプロイに対するポリシー変更のロールアウトに関する手法については、「 ポリシー駆動型ガードレールの導入 」のガイダンスと組み合わせることができます。
このガイダンスは、運用管理グループ階層への変更を管理する堅牢な変更管理プロセスを持つ組織に最も適しています。 "カナリア" 管理グループ階層は、運用環境にデプロイする前に、そのデプロイを別個に作成およびテストするために使用できます。
注
"カナリア" という用語は、開発環境やテスト環境との混同を避けるために使用されます。 この名前は説明の目的でのみ使用されています。 Azure ランディング ゾーンのカナリア環境に適していると思われる任意の名前を定義できます。
同様に、運用環境 /階層 という用語は、ワークロードの Azure サブスクリプションとリソースを含む組織の Azure ランディング ゾーン管理グループ階層を指すために、このガイダンス全体で使用されます。
プラットフォームの定義
重要
このガイダンスは、ランディング ゾーン、ワークロード、アプリケーション、またはサービスと呼ばれるアプリケーションまたはサービス所有者が使用する開発環境またはテスト環境向けではありません。 これらは、運用環境の Azure ランディング ゾーン管理グループ階層および関連するガバナンス (RBAC と Azure Policy) 内に配置され、処理されます。
アプリケーション ワークロードとチームの開発、テスト、ユーザー受け入れテスト (UAT)、運用環境に関するガイダンスについては、 Azure ランディング ゾーンでのアプリケーション開発環境の管理に関するページを参照してください。
このガイダンスは、Azure ランディング ゾーンのコンテキストにおけるプラットフォーム レベルのテストと変更にのみ対応しています。
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 テナント内で一意である必要があります。
注
カナリア管理グループの表示名は、運用管理グループの表示名と同じにすることができます。 これは、ユーザーの混乱を招くおそれがあります。 このため、表示名とその ID に "canary" という名前を追加することをお勧めします。
カナリア管理グループ階層は、次のリソースの種類のテストを簡略化するために使用されます。
- 管理グループ
- サブスクリプションの配置
- RBAC
- 組み込みロールとカスタムロール
- 課題
- Azure Policy
- 定義 (組み込みとカスタム)
- イニシアチブ (セット定義とも呼ばれます)
- 課題
カナリア管理グループ階層をデプロイしない場合
カナリア管理グループ階層をデプロイしない場合は、図に示すように サンドボックス サブスクリプション を使用して、運用環境階層内のプラットフォーム リソースをテストできます。
図 2: サンドボックスを強調表示する Azure ランディング ゾーン管理グループ階層。
このシナリオで Azure ポリシーと RBAC をテストするには、ユーザー アカウント、サービス プリンシパル、マネージド サービス ID などとして、テストを完了する ID に対して所有者 RBAC ロールが割り当てられた単一の Azure サブスクリプションが必要です。 この構成では、サンドボックス サブスクリプションのスコープ内でのみ、Azure Policy の定義と割り当てを作成、割り当て、修復できます。
このサンドボックス アプローチは、サブスクリプション内の RBAC のテストにも使用できます。たとえば、新しいカスタム RBAC ロールを作成して、特定のユース ケースにアクセス許可を付与する場合などです。 このテストはすべて、サンドボックス サブスクリプション内で実行し、階層でより上位のロールを作成および割り当てる前にテストすることができます。
このアプローチの利点は、サンドボックスのサブスクリプションを必要な期間だけ使用したら、後は環境から削除できることです。
ただし、このアプローチでは、管理グループ階層から RBAC と Azure ポリシーを継承してテストすることはできません。
実装ガイダンス
以下は、運用環境の Azure ランディング ゾーン管理グループ階層と共に、Azure ランディング ゾーンのカナリア管理グループ階層を実装して使用する方法に関するガイダンスです。
警告
ポータルを使用して Azure ランディング ゾーン環境を現在デプロイおよび管理している場合、運用環境とカナリア環境の両方が頻繁に同期されなくなるため、レプリカのような階層と運用環境が提供されないため、カナリア アプローチを効率的に導入して使用することは困難な場合があります。
このシナリオの場合は、上記のように、Azure ランディング ゾーンのコードとしてのインフラストラクチャ (IaC) デプロイ アプローチに移行することを検討してください。 または、カナリアと運用環境の間の構成誤差の潜在的なリスクに注意し、注意を払って進めます。 詳細については、「 IaC を使用して Azure ランディング ゾーンを更新する」を参照してください。
- 関連する運用環境またはカナリア環境の Azure ランディング ゾーン管理グループ階層に対するアクセス許可が付与されている個別の Microsoft Entra サービス プリンシパル (SPN) またはマネージド ID (MIs) を使用します。
- このガイダンスは、最小特権の原則 (PoLP) に従っています
- Git リポジトリ、ブランチ、またはリポジトリ内の個別のフォルダーを使用して、運用環境とカナリア環境の Azure ランディング ゾーンデプロイ用の IaC を保持します。
- デプロイする階層に応じて、CI/CD パイプラインの一部として、関連する Microsoft Entra サービス プリンシパル (SPN) またはマネージド ID (MIs) を使用します。
- 運用環境に合わせて、カナリア環境の Git ブランチ ポリシーまたはセキュリティを実装します。
- カナリア環境がフェイルファストとなるように、承認者とチェックの数を減らすことを検討します。
- どちらの階層をデプロイするかを変更するために環境変数を使用する、同じ Azure Pipelines または GitHub Actions を使用します。 別の方法として、パイプラインを複製し、ハードコーディングされた設定を修正して、デプロイする階層を定義することもできます。
- Azure Pipelines DevOps テンプレートまたは GitHub Actions ワークフロー テンプレートを使用すると、Don't Repeat Yourself (DRY) の原則に従うのに役立ちます。
- 必要に応じてカナリア管理グループ階層を移動できる、Enterprise Agreement (EA) アカウントや Microsoft 顧客契約 (MCA) 請求書セクションなど、別の課金アカウントの下にカナリア サブスクリプションのセットを用意します。
- カナリア環境に対する変更のテストと検証を高速化するために、一連のリソースをカナリア環境サブスクリプションに常にデプロイすると便利な場合があります。
- 一連のサンプル アプリケーション ワークロード アーキテクチャがあり、カナリア環境のカナリア サブスクリプションにデプロイして、Azure Policy と RBAC の変更をテストできます。 これにより、変更をデプロイして運用環境に昇格させる前に、変更を検証できます。
- これらのワークロード例は、運用アプリケーション ワークロードのデプロイに使用されるのと同じ IaC テンプレートを使用してデプロイできます。 これは、カナリア環境が運用環境と同期していること、およびテストする変更が有効であり、運用環境に適用できることを確認するのに役立ちます。
- ワークロードの例を継続的に確認して更新し、組織内の最新のアーキテクチャと設計パターンに関連し、最新であることを確認する必要があります。
- 参照アーキテクチャをアプリケーション チームに提供する場合は、カナリア環境にもデプロイすることを検討してください。 これは、参照アーキテクチャに対する変更を検証し、それらが運用環境に適用されることを確認するのに役立ちます。
-
Azure ランディング ゾーンの設計に関する推奨事項に従って、カナリア環境サブスクリプションを含むすべての Azure サブスクリプションのすべての Azure アクティビティ ログを、運用環境の Azure Log Analytics ワークスペースに送信します。
- これにより、セキュリティチームと運用チームは、運用環境に対する Azure Policy と RBAC の変更のテストによって発生する可能性のある変更や問題についてカナリア環境を監視できます。
ヒント
既に Azure ランディング ゾーンが運用環境にデプロイされていて、今後カナリア環境の追加を検討している場合。 運用環境階層の現在のデプロイを複製し、リソース名にカナリア用命名規則のプレフィックスを付けることを検討してください。
これは、カナリア環境を有効にするためにデプロイしているものが、最初から運用環境と同期していることを確認するためです。 これは、Git リポジトリと共に IaC ツールを使用する場合に簡単に実現できます。
Microsoft Entra のシングルテナントを使用
単一の Microsoft Entra テナントを使用する場合の考慮事項を次に示します。
- 1 つのテナントを使用すると、Microsoft Entra テナントの Azure ランディング ゾーンの設計に関する推奨事項 に従います。
- 単一の Microsoft Entra テナントでは、同じユーザーが関連する管理グループ階層に割り当てられている運用環境とカナリア Azure ランディング ゾーンの両方の環境に異なる 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 Policy と RBAC の変更のテストを開始できます。
カナリア環境で Azure Policies の変更をテストしたら、 ポリシー駆動型ガードレールの導入 ガイダンスに記載されているのと同じアプローチに従って、それらを運用環境に昇格させることができます。 これは、 ポリシー割り当ての適用モード機能を使用して行われます。 このガイダンスに記載されているアプローチを使用すると、運用環境で Azure Policy を適用する前に追加のテスト フェーズを進めることができます。これにより、行っている Azure Policy の変更に対する信頼度を高めるのに役立ちます。
また、アプリケーション チームがワークロードの開発とテストに使用するサンドボックス環境を確認することもできます。 これはカナリア環境とは別の概念であり、運用環境にデプロイする前に、アプリケーション チームがワークロードを開発してテストするための安全な環境を提供するために使用されます。