Azure ランディング ゾーンのテスト方針

注

この記事は、Microsoft Azure にのみ適用され、他の Microsoft Cloud オファリング (Microsoft 365 や Microsoft Dynamics 365 など) には適用されません。

一部の組織では、プラットフォーム ランディング ゾーン アクセラレータによるAzure Policyの定義と割り当て、ロールベースのアクセス制御 (RBAC) カスタム ロールと割り当てのデプロイなどをテストできます。 テストは、Azure Resource Manager テンプレート (ARM テンプレート)、Terraform、Bicepなどを使用して自動化で完了するか、あるいは Azure portal を利用して手動で完了できます。 このガイダンスでは、プラットフォーム ランディング ゾーン アクセラレータのデプロイに対する変更とその影響をテストするために使用できるアプローチを提供します。

この記事は、PlatformOps および中心的な機能を担当するチームとそのタスクに関連しているため、プラットフォームの自動化と DevOps の重要な設計領域に関するガイダンスと共に使用することもできます。 さらに、プラットフォーム ランディング ゾーンのデプロイに対するポリシー変更の展開に関する手法については、「 ポリシー駆動型ガードレールを採用 する」のガイダンスと組み合わせることができます。

このガイダンスは、運用管理グループ階層への変更を管理する堅牢な変更管理プロセスを持つ組織に最も適しています。 "カナリア" 管理グループ階層は、運用環境にデプロイする前に、そのデプロイを別個に作成およびテストするために使用できます。

注

"カナリア" という用語は、開発環境やテスト環境との混同を避けるために使用されます。 この名前は説明の目的でのみ使用されています。 カナリア Azure ランディング ゾーン環境には、適切だと考える任意の名前を付けてもかまいません。

同様に、運用環境/階層という用語は、このガイダンス全体を通じて、ワークロードのAzureサブスクリプションとリソースを含む組織のプラットフォーム ランディング ゾーン管理グループ階層を指します。

プラットフォームの定義

重要

このガイダンスは、ランディング ゾーン、ワークロード、アプリケーション、またはサービスと呼ばれるアプリケーションまたはサービス所有者が使用する開発環境またはテスト環境向けではありません。 これらは、ランディング ゾーン管理グループ階層と関連するガバナンス (RBAC とAzure Policy) Azure運用環境内に配置および処理されます。

ワークロードとチームの開発、テスト、ユーザー受け入れテスト (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 グループのメンバーシップの変更も挙げられます。 このケースでは、運用環境で変更を行う前に、ある種のテストが必要になる場合があります。

重要

これは、ほとんどのお客様にとって一般的なデプロイ アプローチまたはパターンではありません。 プラットフォーム ランディング ゾーン アクセラレータのデプロイに必須ではありません。

カナリア環境のテスト アプローチを使用した管理グループ階層の図。

"図 1: カナリア管理グループ階層。 "

図に示すように、ランディング ゾーン運用管理グループ階層Azure全体が、Tenant Root Groupの下に複製されています。 "カナリア" という名前が、管理グループの表示名と ID の後ろに追加されています。 管理グループ ID は、1 つのMicrosoft Entra テナント内で一意である必要があります。 テナントは管理グループ ID を権限のある識別子として扱うので、テナント間で区別する必要があります。 管理グループの 表示名 は、運用管理グループ階層に合わせて維持できます。 ユーザーが管理グループ ツリー内を移動するときにカナリア階層と運用環境を視覚的に区別できるように、表示名にも名前付けの区別を追加します。

カナリア管理グループ階層は、次のリソースの種類のテストを簡略化するために使用されます。

  • 管理グループ
    • サブスクリプションの配置
  • RBAC
    • 組み込みロールとカスタムロール
    • 課題
  • Azure Policy
    • 定義 (組み込みとカスタム)
    • イニシアチブ (セット定義とも呼ばれます)
    • 課題

カナリア管理グループ階層をデプロイしない場合

カナリア管理グループ階層をデプロイしない場合は、図に示すように サンドボックス サブスクリプション を使用して、運用環境階層内のプラットフォーム リソースをテストできます。

サンドボックスを使用するテスト アプローチの図。

図 2: サンドボックスを強調表示した Azure ランディング ゾーンの管理グループ階層。

このシナリオで Azure ポリシーと RBAC をテストするには、ユーザー アカウント、サービス プリンシパル、マネージド サービス ID などとして、テストを完了する ID に対して所有者 RBAC ロールが割り当てられた単一の Azure サブスクリプションが必要です。 この構成では、サンドボックス サブスクリプションのスコープ内でのみ、Azure Policy の定義と割り当てを作成、割り当て、修復できます。

このサンドボックス アプローチは、サブスクリプション内の RBAC のテストにも使用できます。たとえば、新しいカスタム RBAC ロールを作成して、特定のユース ケースにアクセス許可を付与する場合などです。 このテストはすべて、サンドボックス サブスクリプション内で実行し、階層でより上位のロールを作成および割り当てる前にテストすることができます。

このアプローチの利点は、サンドボックスのサブスクリプションを必要な期間だけ使用したら、後は環境から削除できることです。

ただし、このアプローチでは、管理グループ階層から RBAC と Azure ポリシーを継承してテストすることはできません。

実装ガイダンス

以下は、運用環境向け Azure ランディング ゾーン管理グループ階層と併せて、Azure ランディング ゾーン用のカナリア管理グループ階層を実装および使用する方法に関するガイダンスです。

警告

ポータルを使用してプラットフォーム ランディング ゾーン アクセラレータ環境を現在デプロイおよび管理している場合、運用環境とカナリア環境の両方が頻繁に同期されなくなるため、レプリカのような階層と運用環境が提供されないため、カナリア アプローチを効率的に導入して使用することは困難な場合があります。

このシナリオの場合は、上記のように、プラットフォーム ランディング ゾーン アクセラレータをデプロイするための Infrastructure as Code (IaC) デプロイ アプローチに移行することを検討してください。 または、カナリアと運用環境の間の構成誤差の潜在的なリスクに注意し、注意を払って進めます。 詳細については、「IaC を使用してAzureランディング ゾーンを更新する」を参照してください。

  1. 関連する運用環境またはカナリア環境の Azure ランディング ゾーンの管理グループ階層に対するアクセス許可が付与された、個別の Microsoft Entra サービス プリンシパル (SPN) またはマネージド ID (MI) を使用します。
    • このガイダンスは、最小特権の原則 (PoLP) に従っています
  2. Git リポジトリ、ブランチ、またはリポジトリ内の個別のフォルダーを使用して、運用環境とカナリア環境Azureランディング ゾーンデプロイ用の IaC を保持します。
    • デプロイする階層に応じて、CI/CD パイプラインの一部として、関連する Microsoft Entra サービス プリンシパル (SPN) またはマネージド ID (MIs) を使用します。
  3. 運用環境に合わせて、カナリア環境の Git ブランチ ポリシーまたはセキュリティを実装します。
    • カナリア環境がフェイルファストとなるように、承認者とチェックの数を減らすことを検討します。
  4. どちらの階層をデプロイするかを変更するために環境変数を使用する、同じ Azure Pipelines または GitHub Actions を使用します。 別の方法として、パイプラインを複製し、ハードコーディングされた設定を修正して、デプロイする階層を定義することもできます。
  5. 必要に応じてカナリア管理グループ階層を移動できる、Enterprise Agreement (EA) アカウントや Microsoft 顧客契約 (MCA) 請求書セクションなど、別の課金アカウントの下にカナリア サブスクリプションのセットを用意します。
    • カナリア環境に対する変更のテストと検証を高速化するために、一連のリソースをカナリア環境サブスクリプションに常にデプロイすると便利な場合があります。
  6. カナリア環境のカナリア サブスクリプションにデプロイして、Azure Policyと RBAC の変更をテストできる一連のワークロード アーキテクチャの例を用意します。 これにより、変更をデプロイして運用環境に昇格させる前に、変更を検証できます。
    • これらのワークロード例は、運用ワークロードのデプロイに使用されるのと同じ IaC テンプレートを使用してデプロイできます。 これは、カナリア環境が運用環境と同期していること、およびテストする変更が有効であり、運用環境に適用できることを確認するのに役立ちます。
    • ワークロードの例を継続的に確認して更新し、組織内の最新のアーキテクチャと設計パターンに関連し、最新であることを確認する必要があります。
    • ワークロード チームに参照アーキテクチャを提供する場合は、カナリア環境にもデプロイすることを検討してください。 これは、参照アーキテクチャに対する変更を検証し、それらが運用環境に適用されることを確認するのに役立ちます。
  7. Azure ランディング ゾーンの設計に関する推奨事項に従って、カナリア環境のサブスクリプションを含むすべての Azure サブスクリプションの Azure アクティビティ ログを、運用環境の Azure Log Analytics ワークスペースに送信します。
    • これにより、セキュリティチームと運用チームは、運用環境に対する Azure Policy と RBAC の変更のテストによって発生する可能性のある変更や問題についてカナリア環境を監視できます。

ヒント

既にAzureランディング ゾーンが運用環境にデプロイされていて、カナリア環境の追加を検討している場合は、運用環境階層の現在のデプロイを複製し、リソースの名前を修正してカナリアの名前付けスキームの前に付けるかどうかを検討してください。

これは、カナリア環境を有効にするためにデプロイしているものが、最初から運用環境と同期していることを確認するためです。 これは、Git リポジトリと共に IaC ツールを使用する場合に簡単に実現できます。

Microsoft Entra のシングルテナントを使用

単一の Microsoft Entra テナントを使用する場合の考慮事項を次に示します。

  • 単一テナントを使用することは、Microsoft Entra テナント向けのAzure ランディング ゾーンの設計に関する推奨事項に従っています。
    • 1 つの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 の変更に対する信頼度を高めるのに役立ちます。

ワークロード チームがワークロードの開発とテストに使用するサンドボックス環境を確認することもできます。 これはカナリア環境とは別の概念であり、ワークロード チームが運用環境にデプロイされる前にワークロードを開発およびテストするための安全な環境を提供するために使用されます。

ランディング ゾーン サンドボックス環境を実装する

  • 最終更新: