要件を満たすように Azure ランディング ゾーンのアーキテクチャを調整する

  • [アーティクル]

Azure ランディング ゾーンのガイダンスの一部として、いくつかの参照実装オプションを使用できます。

  • Azure Virtual WAN を使用した Azure ランディング ゾーン
  • 従来のハブ アンド スポークを使用した Azure ランディング ゾーン
  • Azure ランディング ゾーンの基礎
  • 小規模企業向けの Azure ランディング ゾーン

これらのオプションは、Azure ランディング ゾーンの概念アーキテクチャと設計領域のベスト プラクティスを提供する構成を使用して、組織がすぐに開始するのに役立つ場合があります。

参照実装は、Microsoft のチームがお客様やパートナーとのエンゲージメントから得たベスト プラクティスと学習に基づくものです。 この知識は、80/20 の法則の "80" の側を表しています。 さまざまな実装では、アーキテクチャ設計プロセスの一部である技術的な決定での立場が示されています。

すべてのユース ケースは同じではないので、すべての組織が実装アプローチをその意図のとおりに使用できるわけではありません。 調整の要件を明らかにするときの考慮事項を理解する必要があります。

Azure ランディング ゾーンにおけるランディング ゾーンのアーキタイプとは

"ランディング ゾーンのアーキタイプ" では、ランディング ゾーン (Azure サブスクリプション) が特定のスコープで想定される環境とコンプライアンスの要件を満たすために必要なことが記述されています。 たとえば、次のようになります。

  • Azure Policy の割り当て。
  • ロールベースのアクセス制御 (RBAC) の割り当て。
  • 一元管理されたリソース (ネットワークなど)。

Azure でのポリシー継承の仕組みのため、ランディング ゾーンのアーキタイプの最終的な出力は、リソース階層内の各管理グループから影響を受けるものと考えられます。 下位レベルを設計するときは、リソース階層の上位のレベルで適用されているものについて考えます。

管理グループとランディング ゾーンのアーキタイプの間には密接な関係がありますが、管理グループだけがランディング ゾーンのアーキタイプではありません。 そうではなく、それは環境内の各ランディング ゾーン アーキタイプを実装するために使われるフレームワークの一部を形成します。

この関係は、Azure ランディング ゾーンの概念アーキテクチャで確認できます。 設定をすべてのワークロードに適用する必要があるポリシーの割り当ては、中間ルート管理グループに作成されます (Contoso など)。 要件がより具体的なさらに多くのポリシー割り当ては、階層の下位レベルで作成されます。

管理グループ階層内のサブスクリプションの配置によって、その特定のランディング ゾーン (Azure サブスクリプション) に継承、適用、強制される Azure Policy とアクセス制御 (IAM) の割り当ての結果セットが決まります。

ランディング ゾーンに必要な一元管理リソースがあることを確実にするには、プロセスとツールがさらに必要になる場合があります。 次に例をいくつか示します。

  • アクティビティ ログ データを Log Analytics ワークスペースに送信するための診断設定。
  • Microsoft Defender for Cloud 用の連続エクスポート設定。
  • アプリケーション ワークロード用のマネージド IP アドレス空間を持つ仮想ネットワーク。
  • 仮想ネットワークと分散型サービス拒否 (DDoS) ネットワーク保護とのリンク。

注意

Azure ランディング ゾーンの参照実装では、上記のリソースのデプロイを実現するために、DeployIfNotExists と Modify効果がある Azure ポリシーが使われます。 これは、ポリシー主導型ガバナンスの設計原則に従います。

詳しくは、「ポリシー主導のガードレールの採用」をご覧ください。

Azure ランディング ゾーンの概念アーキテクチャのための組み込みアーキタイプ

概念アーキテクチャには、corp や online など、アプリケーション ワークロード用のランディング ゾーン アーキタイプの例が含まれています。 これらのアーキタイプは、ユーザーの組織に適用され、ユーザーの要件を満たしている可能性があります。 ユーザーは、これらのアーキタイプを変更したり、新しく作成したりできます。 決定は、組織のニーズと要件によって異なります。

ヒント

Azure ランディング ゾーン アクセラレータでのランディング ゾーン アーキタイプを確認するには、「Azure ランディング ゾーン アクセラレータの管理グループ」をご覧ください。

また、リソース階層内の他の場所で変更を作成することもできます。 お客様の組織用の Azure ランディング ゾーンの実装のための階層を計画するときは、設計領域のガイドラインに従ってください。

次に示す概念アーキテクチャのランディング ゾーンのアーキタイプの例は、その目的と用途を理解するのに役立ちます。

ランディング ゾーン アーキタイプ (管理グループ) 目的または用途
Corp 企業ランディング ゾーン用の専用管理グループです。 このグループは、接続サブスクリプションのハブ経由で企業ネットワークとの接続またはハイブリッド接続を必要とするワークロード用です。
オンライン オンライン ランディング ゾーン用の専用管理グループです。 このグループは、直接的なインターネットの受信または送信接続を必要とする可能性があるワークロード、または仮想ネットワークを必要としない可能性があるワークロード用です。
サンドボックス 組織によるテストと探索にのみ使用されるサブスクリプションの専用管理グループです。 これらのサブスクリプションは、企業およびオンライン ランディング ゾーンから安全に切断されます。 また、サンドボックスには、Azure サービスのテスト、探索、構成を有効にするために割り当てられる、制限の少ない一連のポリシーもあります。

調整が必要になる可能性があるシナリオ

説明したように、Azure ランディング ゾーンの概念アーキテクチャでは、一般的なランディング ゾーン アーキタイプが提供されています。 corp と online がそれです。 これらのアーキタイプは固定的なものではなく、アプリケーション ワークロードに使用できるランディング ゾーン アーキタイプはこれらだけではありません。 実際のニーズと要件に合わせてランディング ゾーンのアーキタイプを調整することが必要な場合があります。

ランディング ゾーンのアーキタイプを調整する前に、概念を理解し、カスタマイズすることをお勧めする階層の領域を視覚化することも重要です。 次の図は、Azure ランディング ゾーンの概念アーキテクチャの既定の階層を示したものです。

Diagram that shows Azure landing zone default hierarchy with tailoring areas highlighted.

階層の 2 つの領域が強調されています。 1 つはランディング ゾーンの下にあり、もう 1 つはプラットフォームの下にあります。

アプリケーション ランディング ゾーンのアーキタイプを調整する

ランディング ゾーン管理グループの下の青で強調されている領域に注目してください。 これは、既存の階層を使って既存のアーキタイプへのポリシー割り当てとして追加することができない、新しい要件または追加要件を満たすアーキタイプを追加するための、階層内で "最も一般的で安全な場所" です。

たとえば、支払いカード業界 (PCI) のコンプライアンス要件を満たす必要がある一連のアプリケーション ワークロードをホストするための新しい要件があるとします。 ただし、この新しい要件は、資産全体のすべてのワークロードに適用する必要はありません。

この新しい要件を満たすための簡単で安全な方法があります。 階層のランディング ゾーン管理グループの下に、PCI という名前の新しい管理グループを作成します。 PCI v3.2.1:2018 用の Microsoft Defender for Cloud 規制コンプライアンス ポリシー イニシアティブのような追加ポリシーを、新しい PCI 管理グループに割り当てることができます。 このアクションは、新しいアーキタイプを形成します。

これで、新しい PCI 管理グループに新しい Azure サブスクリプションを配置したり、既存のものを移動したりして、必要なポリシーを継承させ、新しいアーキタイプを形成することができます。

もう 1 つの例として 、Microsoft Cloud for Sovereignty があります。これは、機密コンピューティング用の管理グループを追加し、規制対象の業界で使用に合わせて調整されています。 Microsoft Cloud for Sovereignty には、適切なソブリン制御を使用してパブリック クラウドを導入するためのツール、ガイダンス、ガードレールが用意されています。

ヒント

RBAC と Azure Policy に関連して管理グループ間で Azure サブスクリプションを移動するときは、考慮すべき事と、何が起きるかについて、知っておく必要があります。 詳しくは、「既存の Azure 環境を Azure ランディング ゾーンの概念アーキテクチャに移行する」をご覧ください。

プラットフォーム ランディング ゾーンのアーキタイプを調整する

プラットフォーム管理グループの下にあるオレンジ色で強調された領域の調整も必要になる場合があります。 この領域のゾーンは、"プラットフォーム ランディングゾーン" と呼ばれます。

たとえば、ワークロードをホストするために独自のアーキタイプを必要とする専用の SOC チームがあるとします。 これらのワークロードは、管理管理グループとは異なる Azure Policy と RBAC の割り当ての要件を満たす必要があります。

階層のプラットフォーム管理グループの下に、新しくセキュリティ管理グループを作成します。 必要な Azure Policy と RBAC の割り当てを、それに割り当てることができます。

これで、新しいセキュリティ 管理グループに新しい Azure サブスクリプションを配置したり、既存のものを移動したりして、必要なポリシーを継承させ、新しいアーキタイプを形成することができます。

調整された Azure ランディング ゾーン階層の例

次の図は、調整後の Azure ランディング ゾーンの階層を示したものです。 前の図の例を使用しています。

Diagram that shows a tailored Azure landing zone hierarchy.

考慮すべき点

階層内の Azure ランディング ゾーンのアーキタイプの実装を調整する場合は、次の点を考慮してください。

  • 階層の調整は必須ではありません。 提供されている既定のアーキタイプと階層は、ほとんどのシナリオに適しています。

  • アーキタイプの組織階層、チーム、または部署を作成し直さないでください。

  • 常に、既存のアーキタイプと階層を基にして新しい要件を満たすことを試みてください。

  • どうしても必要な場合にのみ、新しいアーキタイプを作成してください。

    たとえば、PCI のような新しいコンプライアンス要件は、アプリケーション ワークロードのサブセットにのみ必要であり、すべてのワークロードに適用する必要はありません。

  • 前の図で示されている強調された領域にのみ、新しいアーキタイプを作成してください

  • 複雑さと不要な除外を避けるため、階層の深さが 4 層を超えないようにしてください。 アーキタイプは、階層内で垂直方向ではなく、水平方向に拡大します。

  • 開発、テスト、運用のような、環境のためのアーキタイプは作成しないでください。

    詳しくは、Azure ランディング ゾーンの概念アーキテクチャで開発、テスト、運用ワークロードのランディング ゾーンを処理する方法に関するページを参照してください

  • ブラウンフィールド環境から来ている場合、またはランディング ゾーン管理グループで "監査のみ" 適用モードのポリシーを使用してサブスクリプションをホストする方法を探している場合は、「シナリオ: ランディング ゾーン管理グループを複製して環境を移行する」を参照してください。