Azure ランディング ゾーンでの Azure Virtual Machines ベースライン アーキテクチャ

Azure Bastion

Azure Firewall

Azure Log Analytics

Azure Virtual Machines

Azure Virtual Network

この記事のアーキテクチャは、仮想マシン (VM) ベースライン アーキテクチャ を拡張して、Azure ランディング ゾーンにデプロイするときの変更と期待に対応します。

この記事の例では、組織は、プラットフォーム チームが一元的に管理するフェデレーション リソースを VM ベースのワークロードで使用することを望んでいます。 これらのリソースには、クロスプレミス接続、ID アクセス管理、ポリシー用のネットワーク リソースが含まれます。 この例では、組織が Azure ランディング ゾーンを採用して、複数のワークロードにわたって一貫したガバナンスとコスト効率を適用することを前提としています。

ワークロード所有者は、共有リソースの管理を中央チームにオフロードできるため、ワークロード開発作業に集中できます。 この記事では、ワークロード チームの視点について説明します。 プラットフォーム チーム向けの推奨事項が指定されています。

大事な

Azure ランディング ゾーンとは Azure ランディング ゾーンは、組織のクラウド フットプリントの 2 つの観点を示します。 アプリケーション ランディング ゾーン は、ワークロードが実行される Azure サブスクリプションです。 組織の共有リソースに接続されています。 その接続を通じて、ネットワーク、ID アクセス管理、ポリシー、監視など、ワークロードを実行する基本的なインフラストラクチャにアクセスできます。 プラットフォーム ランディング ゾーン は、それぞれが特定の機能を持つさまざまなサブスクリプションのコレクションです。 たとえば、接続サブスクリプションでは、一元化されたドメイン ネーム システム (DNS) の解決、クロスプレミス接続、およびアプリケーション チームが使用できるネットワーク仮想アプライアンス (NVA) が提供されます。

このアーキテクチャの実装の準備に役立つ azure ランディング ゾーン 概念を理解することをお勧めします。

記事のレイアウト

建築	設計上の決定	Azure Well-Architected Framework のアプローチ
▪ アーキテクチャ図の ▪ ワークロード リソース を する ▪ フェデレーション リソース の	▪ サブスクリプションのセットアップ ▪ ネットワーク要件 ▪ ベースライン からのネットワーク設計の変更 ▪ 監視 ▪ Patch コンプライアンス ▪ 組織のガバナンス ▪ 変更管理	▪ 信頼性 ▪ セキュリティ ▪ コストの最適化の

先端

GitHub ロゴを この リファレンス実装 は、この記事で説明するベスト プラクティスを示しています。

リポジトリ成果物は、環境に合わせてカスタマイズ可能な基盤を提供します。 この実装では、デモンストレーション用に Azure Firewall などの共有リソースを使用してハブ ネットワークを設定します。 このセットアップは、個別のワークロードとプラットフォームの機能に対して個別のアプリケーション ランディング ゾーン サブスクリプションに適用できます。

建築

このアーキテクチャの Visio ファイル をダウンロードします。

コンポーネント

すべての Azure ランディング ゾーン アーキテクチャでは、プラットフォーム チームとワークロード チームの間で所有権が分離されています。 アプリケーション アーキテクトと DevOps チームは、直接的な影響や制御の下にあるものとそうでないものを理解するために、この責任分割について強く理解する必要があります。

ワークロード チーム所有のリソース

次のリソースは、ベースライン アーキテクチャのとほとんど変わりません。

• Azure Virtual Machines はアプリケーション プラットフォームです。 コンピューティング リソースは、可用性ゾーン間で分散されます。

• azure Load Balancer は、フロントエンド VM からバックエンド VM へのトラフィックをプライベートに負荷分散するために使用されます。 ロード バランサーは、ゾーン間で VM にトラフィックを分散します。

• Azure Application Gateway は、ユーザー要求をフロントエンド VM にルーティングするためのリバース プロキシとして使用されます。 選択した SKU は、悪意のある可能性のあるトラフィックからフロントエンド VM を保護するために、Azure Web アプリケーション ファイアウォールをホストするためにも使用されます。

• Azure Key Vault は、アプリケーション シークレットと証明書を格納するために使用されます。

• Azure Monitor、Log Analytics、および Application Insights は、監視データの収集、格納、視覚化に使用されます。

• Azure Policy は、ワークロードに固有のポリシーを適用するために使用されます。

ワークロード チームは、次のリソースと責任を維持し、実行します。

• スポーク仮想ネットワーク サブネットと、セグメント化を維持し、トラフィック フローを制御するためにそれらのサブネットに配置されるネットワーク セキュリティ グループ (NSG)。

• プライベート エンドポイント、サービスとしてのプラットフォーム (PaaS) ソリューションへの接続をセキュリティで保護し、それらのエンドポイントに必要な プライベート DNS ゾーン。

• Azure Managed Disks はバックエンド サーバーにログ ファイルを格納し、VM が再起動してもデータは保持されます。 フロントエンド サーバーには、ステートレス アプリケーションのデプロイに使用できるディスクが接続されています。

チーム所有のプラットフォーム リソース

プラットフォーム チームは、これらの一元化されたリソースを所有し、維持します。 このアーキテクチャでは、これらのリソースが事前にプロビジョニングされていることを前提とし、依存関係を考慮します。

• ハブ ネットワーク内 Azure Firewall は、エグレス トラフィックの検査と制限に使用されます。 このコンポーネントは、インターネットへの送信トラフィックに制限を提供しないベースライン アーキテクチャの標準ロード バランサーを置き換えます。

• ハブ ネットワークに Azure Bastion を 、ワークロード VM への安全な運用アクセスを提供します。 ベースライン アーキテクチャでは、ワークロード チームがこのコンポーネントを所有しています。

• スポーク仮想ネットワーク は、ワークロードがデプロイされる場所です。

• ユーザー定義ルート (UDR) は、ハブ ネットワークへのトンネリングを強制するために使用されます。

• Azure Policy ベースのガバナンス制約 と DeployIfNotExists (DINE) ポリシーは、ワークロード サブスクリプションの一部です。

大事な

Azure ランディング ゾーンは、プラットフォーム ランディング ゾーン サブスクリプションの一部として上記のリソースの一部を提供し、ワークロード サブスクリプションは他のリソースを提供します。 多くのリソースは接続サブスクリプションの一部であり、Azure ExpressRoute、Azure VPN Gateway、Azure DNS などの追加リソースがあります。 これらの追加リソースは、クロスプレミス アクセスと名前解決を提供します。 これらのリソースの管理は、この記事の範囲外です。

サブスクリプションのセットアップ

ランディング ゾーンのコンテキストでは、ワークロード チームはプラットフォーム チームに固有の要件を通知する必要があります。

ワークロード チーム には、プラットフォーム チームが必要なリソースを割り当てることができるように、ワークロードに必要なネットワーク領域に関する詳細情報が含まれている必要があります。 チームが要件を決定し、プラットフォーム チームは、仮想ネットワーク内で割り当てる IP アドレスと、サブスクリプションが割り当てられている管理グループを決定します。

プラットフォーム チーム は、ワークロードがインターネットに公開されている場合など、ワークロードのビジネスの重要度と技術的要件に基づいて適切な管理グループを割り当てます。 組織はこれらの管理グループの構成を決定し、プラットフォーム チームがそれらを実装します。

たとえば、ベースライン アーキテクチャ のアプリケーション シナリオの管理グループは、次の内容と見なされます。

• プライベート アプリケーション(社内の基幹業務アプリケーションや商用の既製 (COTS) ソリューションなど)、多くの場合、Azure ランディング ゾーンの Corp 管理グループの下にあります。

• パブリック アプリケーションは、インターネットに接続するアプリケーションと同様に。多くの場合、Corp または Online 管理グループの下にあります。

プラットフォーム チームは、ワークロードのデプロイ用にサブスクリプションまたはサブスクリプションのグループを設定する役割も担います。

次のセクションでは、サブスクリプションの初期セットアップに関するガイダンスを提供します。 ただし、プラットフォーム チームは通常、一元化されたサービスに変更を加えて、見落とされた要件や変更された要件に対処します。 プラットフォームの変更は、すべてのワークロード チームに広範な影響を与えます。

そのため、プラットフォーム チームは、すべての VM ワークロードが変更に対して準備されていることを確認し、VM ベースのソリューションのライフ サイクルとテスト サイクルを認識する必要があります。 詳細については、「時間経過に伴う変更の管理」を参照してください。

ワークロードの要件とフルフィルメント

ワークロード チームとプラットフォーム チームは、管理グループの割り当てとネットワークのセットアップという 2 つの主な責任を共有します。 このアーキテクチャでは、プラットフォーム チームと通信する必要がある次のネットワーク要件を検討してください。 これらのポイントを例として使用して、同様のアーキテクチャを実装するときに 2 つのチーム間のディスカッションとネゴシエーションを理解します。

• スポーク仮想ネットワークの数: このアーキテクチャでは、専用スポークが 1 つだけ必要です。 デプロイされたリソースは複数のネットワークにまたがる必要がなく、単一の仮想ネットワーク内に併置されます。

• スポーク ネットワークののサイズ: 運用要件とワークロードの予想される増加を考慮します。 たとえば、青/緑またはカナリアの更新プログラムを実装する予定の場合は、サイド バイ サイドデプロイで必要な領域を最大サイズで考慮する必要があります。

  今後の変更では、より多くの IP 領域が必要になる可能性があり、現在の割り当てとずれる可能性があります。 これらのスペースを統合すると、複雑さが増す可能性があります。 事前に準備し、割り当てられた領域が将来の拡張に対応できるように十分なネットワーク リソースを事前に要求します。

• デプロイ リージョン: ワークロードをデプロイするリージョンを指定することが重要です。 プラットフォーム チームは、この情報を使用して、スポークとハブの仮想ネットワークが同じリージョンに確実にプロビジョニングされるようにすることができます。 異なるリージョン間のネットワークでは、リージョン境界を越えるトラフィックが原因で待機時間の問題が発生する可能性があり、帯域幅の追加コストが発生する可能性もあります。

• ワークロードの特性と設計の選択: 設計の選択、コンポーネント、特性をプラットフォーム チームに伝えます。 たとえば、ワークロードがインターネットへの多数の同時接続 (チャット) を生成することが予想される場合、プラットフォーム チームは、枯渇を防ぐために十分なポートが使用可能であることを確認する必要があります。 トラフィックをサポートするために一元化されたファイアウォールに IP アドレスを追加したり、代替パスを介してトラフィックをルーティングするネットワーク アドレス変換 (NAT) ゲートウェイを設定したりできます。

  逆に、ワークロードが最小限のネットワーク トラフィック (バックグラウンド ノイズ) を生成することが予想される場合、プラットフォーム チームは組織全体でリソースを効率的に使用する必要があります。

  プラットフォーム チームは、依存関係を明確に理解する必要があります。 たとえば、ワークロードが別のチームが所有するデータベースへのアクセスが必要な場合や、ワークロードにクロスプレミス トラフィックがある場合があります。 ワークロードには Azure の外部に依存関係がありますか? このような情報は、プラットフォーム チームが知るために重要です。

• ファイアウォール構成: プラットフォーム チームは、スポーク ネットワークを離れ、ハブ ネットワークにトンネリングされるトラフィックを認識している必要があります。 ハブ内のファイアウォールでは、そのトラフィックをブロックできません。

  たとえば、ワークロードが Windows 更新プログラムにアクセスして修正プログラムを適用し続ける必要がある場合、ファイアウォールはこれらの更新プログラムをブロックしないようにする必要があります。 同様に、特定のエンドポイントにアクセスするモニター エージェントがある場合は、ワークロードの監視データが中断される可能性があるため、ファイアウォールでそのトラフィックをブロックしないでください。 アプリケーションでは、サード パーティのエンドポイントへのアクセスが必要になる場合があります。 いずれの場合も、一元化されたファイアウォールを使用して、予想されるトラフィックと警告されていないトラフィックを区別します。

• オペレーターアクセス: オペレーターが Azure Bastion 経由で VM にアクセスするために使用する Microsoft Entra ID セキュリティ グループがある場合は、プラットフォーム チームに通知します。 通常、Azure Bastion は中央リソースです。 セキュリティ グループと VM がセキュリティで保護されたプロトコルをサポートしていることを確認することが重要です。

  さらに、VM を含む IP 範囲についてプラットフォーム チームに通知します。 この情報は、ハブ ネットワークで Azure Bastion 周辺の NSG を構成するために必要です。

• パブリック IP: 予想されるパブリック IP アドレスを含め、イングレス トラフィック プロファイルについてプラットフォーム チームに通知します。 このアーキテクチャでは、インターネットソースのトラフィックのみが Application Gateway のパブリック IP を対象としています。 プラットフォーム チームは、これらの IP が Azure DDoS Protection プランの下にある場合、またはそれがワークロード チームの責任である場合は、ワークロード チームに通知する必要があります。

  このアーキテクチャでは、Azure Bastion 経由で運用アクセスするための別のパブリック IP があります。 プラットフォーム チームはこのパブリック IP を所有し、プラットフォーム チームが管理する DDoS Protection などのサービスに登録されます。

大事な

ワークロード チームからの情報をキャプチャするように設計された一連の質問を含むプラットフォーム チームには、サブスクリプションの自販ワークストリームをお勧めします。 これらの質問は組織によって異なる場合がありますが、サブスクリプションを実装するための要件を収集することが目的です。 詳細については、「サブスクリプションの自動販売機」を参照してください。

VM の設計の選択肢

VM SKU とディスクの選択は、ベースライン アーキテクチャと同じです。

組織は、特定の VM イメージの使用を義務付けるコンプライアンス要件をワークロード チームに課す場合があります。 このような要件を考えると、プラットフォーム チームは、組織全体で使用するために作成される、ゴールデン イメージと呼ばれる一連の標準化されたイメージを管理する場合があります。

プラットフォーム チームは、Azure コンピューティング ギャラリーやプライベート リポジトリなどのマネージド オファリングを使用して、承認された OS イメージまたはワークロード成果物を格納する場合があります。 VM の OS イメージを選択する場合は、イメージ ソース、更新頻度、および使用の期待についてプラットフォーム チームに問い合わせてください。 また、イメージがワークロードで満たす必要なビジネス要件を満たすことができることを確認します。

大事な

プラットフォーム チームの: コンピューティング ギャラリーを使用する場合、ワークロードにはプライベート ギャラリーに対するネットワークの可視性が必要です。 ワークロード チームと共同作業して、セキュリティで保護された接続を確立します。

ネットワーキング

ベースライン アーキテクチャでは、ワークロードは 1 つの仮想ネットワークにプロビジョニングされます。 ワークロード チームが仮想ネットワークを管理します。

このアーキテクチャでは、プラットフォーム チームがネットワーク トポロジを決定します。 このアーキテクチャでは、ハブスポーク トポロジが想定されています。

このアーキテクチャの Visio ファイル をダウンロードします。

• ハブ仮想ネットワーク: リージョン ハブには、同じリージョン内のワークロード リソースと通信する一元化されたサービスが含まれています。 詳細については、「プラットフォームのチーム所有リソース」を参照してください。 接続サブスクリプションにハブを配置することをお勧めします。

• スポーク仮想ネットワーク: このアーキテクチャでは、ベースライン アーキテクチャの単一の仮想ネットワークがスポーク ネットワークです。 一元化されたサービスを含むハブ ネットワークにピアリングされます。 プラットフォーム チームは、このスポーク ネットワークを所有し、管理します。 このネットワークには、ワークロード リソースが含まれています。 ワークロード チームは、サブネットを含め、このネットワーク内のリソースを所有しています。

プラットフォーム チームに ワークロード要件を伝え、定期的に確認。

大事な

プラットフォーム チームの: ワークロードで特に必要な場合を除き、スポーク ネットワークを別のスポーク仮想ネットワークに直接ピアリングしないでください。 この方法では、ワークロードのセグメント化目標を保護します。 チームは、推移的な仮想ネットワーク接続をすべて容易にする必要があります。

仮想ネットワーク サブネット

スポーク仮想ネットワークでは、ワークロード チームがサブネットを作成して割り当てます。 サブネットとの間でトラフィックを制限するコントロールを配置すると、セグメント化を実現するのに役立ちます。 このアーキテクチャでは、ベースライン アーキテクチャと同じサブネット トポロジが使用されます。このアーキテクチャには、Application Gateway、フロントエンド VM、ロード バランサー、バックエンド VM、プライベート エンドポイント用の専用サブネットがあります。

Azure ランディング ゾーンにワークロードをデプロイする場合でも、ネットワーク制御を実装する必要があります。 組織は、データ流出から保護し、中央セキュリティ オペレーション センター (SOC) と IT ネットワーク チームの可視性を確保するために制限を課す場合があります。

このアプローチにより、プラットフォーム チームは、組織全体のワークロードごとに冗長なセキュリティ制御をデプロイするのではなく、一元化されたサービスを使用して組織全体の支出を最適化できます。 このアーキテクチャでは、Azure Firewall が中央サービスの例です。 各ワークロード チームが独自のファイアウォール インスタンスを管理することは、コスト効率が高く、実用的ではありません。 ファイアウォール管理の一元化されたアプローチをお勧めします。

イングレス トラフィック

イングレス トラフィック フローは、ベースライン アーキテクチャと同じです。

ワークロード所有者は、ワークロードへのパブリック インターネットイングレスに関連するすべてのリソースを担当します。 たとえば、このアーキテクチャでは、Application Gateway とそのパブリック IP はハブ ネットワークではなくスポーク ネットワークに配置されます。 一部の組織では、一元化された非武装地帯 (DMZ) の実装を使用して、イングレス トラフィックを含むリソースを接続サブスクリプションに配置する場合があります。 この記事では、その特定のトポロジとの統合は範囲外です。

エグレス トラフィック

ベースライン アーキテクチャでは、ワークロード仮想マシン スケール セットは Azure Load Balancer を介してパブリック インターネットにアクセスしますが、そのトラフィックは制限されません。

このアーキテクチャでは、その設計が異なります。 スポーク仮想ネットワークを離れるすべてのトラフィックは、エグレス ファイアウォール経由でピアリングされたハブ ネットワーク経由でルーティングされます。 ルートは、ローカル仮想ネットワーク (0.0.0.0/0) に見つからない IP のすべてのトラフィックをハブの Azure Firewall に転送する、スポーク ネットワーク内のすべての可能なサブネットに接続されます。

このアーキテクチャの Visio ファイル をダウンロードします。

Key Vault アクセス用のプライベート エンドポイントへのワークロード通信は、ベースライン アーキテクチャと同じです。 このパスは、簡潔にするために前の図から省略されています。

ワークロード チームは、インフラストラクチャとワークロードの運用に必要なすべての送信トラフィック フローを特定し、文書化し、通信する必要があります。 プラットフォーム チームは必要なトラフィックを許可し、すべての非コミットエグレス トラフィックが拒否される可能性があります。

エグレス トラフィックの制御は、予想されるトラフィックが許可されることを確認するだけではありません。 また、予想されるトラフィックのみを許可 確認することも必要です。 非コミットのエグレス トラフィックは既定で拒否される可能性がありますが、トラフィックが適切にルーティングされるようにするのは、ワークロードのセキュリティ上の最善の目的です。

先端

Azure Firewall で IP グループを使用するようプラットフォーム チームに勧める。 この方法により、ワークロードのエグレス トラフィックのニーズが、ソース サブネットのみに厳密なスコープで正確に表現されるようになります。 たとえば、ワークロード VM が api.example.org に到達できるようにする規則は、同じ仮想ネットワーク内のサポート リソースが同じエンドポイントにアクセスできることを必ずしも意味するとは限りません。 このレベルの細かい制御により、ネットワークのセキュリティ体制を強化できます。

プラットフォーム チームに固有のエグレス トラフィック要件を伝えます。 たとえば、ワークロードで外部ネットワーク エンドポイントへの多数の同時接続が確立されている場合は、プラットフォーム チームに通知します。 その後、プラットフォーム チームは、適切な Azure NAT ゲートウェイ実装をプロビジョニングするか、軽減策のためにリージョン ファイアウォールにパブリック IP を追加できます。

組織には、ワークロード所有のパブリック IP をエグレスに使用するアーキテクチャ パターンの使用を推奨しない要件がある場合があります。 その場合は、Azure Policy を使用して、VM ネットワーク インターフェイス カード (NIC) とその他のパブリック IP (既知のイングレス ポイント以外) のパブリック IP を拒否できます。

プライベート DNS ゾーン

プライベート エンドポイントを使用するアーキテクチャでは、DNS プロバイダーと連携するためにプライベート DNS ゾーンが必要です。 ワークロード チームは、プラットフォーム チームが提供するサブスクリプションのプライベート DNS ゾーンの要件と管理を明確に理解している必要があります。 プライベート DNS ゾーンは通常、DINE ポリシーを使用して大規模に管理されます。これにより、Azure Firewall は信頼性の高い DNS プロキシとして機能し、完全修飾ドメイン名 (FQDN) ネットワーク規則をサポートできます。

このアーキテクチャでは、プラットフォーム チームは、プライベート リンク エンドポイントの信頼性の高いプライベート DNS 解決を保証します。 プラットフォーム チームと共同作業して、期待を理解します。

接続テスト

VM ベースのアーキテクチャの場合、ネットワークの見通し、ルーティング、DNS の問題を特定するのに役立つテスト ツールがいくつかあります。 netstat、nslookup、tcpingなどの従来のトラブルシューティング ツールを使用できます。 さらに、ネットワーク アダプターの動的ホスト構成プロトコル (DHCP) と DNS の設定を調べることができます。 NIC がある場合は、Azure Network Watcher を使用して接続チェックを実行できる、より多くのトラブルシューティング機能があります。

オペレーター アクセス

ベースライン アーキテクチャと同様に、このアーキテクチャでは Azure Bastion を介した運用アクセスがサポートされています。

ただし、ベースライン アーキテクチャでは、ワークロードの一部として Azure Bastion がデプロイされます。 Azure ランディング ゾーンを採用する一般的な組織では、各リージョンの中央リソースとして Azure Bastion をデプロイします。 プラットフォーム チームは Azure Bastion を所有し、維持し、組織内のすべてのワークロードで共有します。 このアーキテクチャのユース ケースを示すために、Azure Bastion は接続サブスクリプションのハブ ネットワークにあります。

オペレーター ID

このアーキテクチャでは、ベースライン アーキテクチャと同じ認証拡張機能が使用されます。

手記

オペレーターは VM にログインするときに、Microsoft Entra ID テナントで会社の ID を使用する必要があり、機能間でサービス プリンシパルを共有する必要はありません。

常に、長期的なアクセスではなく、最小限の特権と詳細なアクセスの原則から始めます。 ランディング ゾーンコンテキストでは、プラットフォーム チームが管理する Just-In-Time (JIT) サポートを利用します。

パッチのコンプライアンスと OS のアップグレード

ベースライン アーキテクチャ では、修正プログラムの適用とアップグレードに対する自律的なアプローチについて説明します。 ワークロードがランディング ゾーンと統合されると、そのアプローチが変わる可能性があります。 プラットフォーム チームは、すべてのワークロードが組織の要件に準拠するように修正プログラムの適用操作を指示する場合があります。

パッチ適用プロセスに、アーキテクチャに追加するすべてのコンポーネントが含まれていることを確認します。 たとえば、アプリケーションのデプロイ、スケーリング、管理を自動化するためにビルド エージェント VM を追加する場合、それらの VM はプラットフォームの要件に準拠している必要があります。

モニタリング

Azure ランディング ゾーン プラットフォームは、管理サブスクリプションの一部として共有可観測性リソースを提供します。 ただし、ワークロードの所有権の責任を容易にするために、独自の監視リソースをプロビジョニングすることをお勧めします。 このアプローチは、ベースライン アーキテクチャのと一致します。

ワークロード チームは、次のような監視リソースをプロビジョニングします。

• ワークロード チームのアプリケーション パフォーマンス監視 (APM) サービスとしての Application Insights。

• Log Analytics ワークスペースは、ワークロード所有の Azure リソースとアプリケーション コードから収集されるすべてのログとメトリックの統合シンクです。

このアーキテクチャの Visio ファイル をダウンロードします。

ベースラインと同様に、すべてのリソースは、ワークロード チームがリソースのコードとしてのインフラストラクチャ (IaC) デプロイの一部としてプロビジョニングする Log Analytics ワークスペースに Azure Diagnostics ログを送信するように構成されます。 また、中央の Log Analytics ワークスペースにログを送信する必要がある場合もあります。 Azure ランディング ゾーンでは、そのワークスペースは管理サブスクリプションにあります。

プラットフォーム チームには、集中管理サブスクリプションにログを送信するように診断を構成するために使用できる DINE ポリシーもあります。 実装で追加のログ フローが制限されないようにすることが重要です。

複数のシンクからのデータを関連付ける

ワークロードのログとメトリックとそのインフラストラクチャ コンポーネントは、ワークロードの Log Analytics ワークスペースに格納されます。 ただし、Azure Firewall、Microsoft Entra ID、Azure Bastion などの一元化されたサービスが生成するログとメトリックは、中央の Log Analytics ワークスペースに格納されます。 複数のシンクからのデータの関連付けは、複雑なタスクになる可能性があります。

相関データは、インシデント対応時によく使用されます。 複数のシンクからのデータの関連付けに問題がある場合は、このアーキテクチャのトリアージ Runbook がそれに対処し、問題がワークロード リソースを超える場合は、組織の連絡先が含まれていることを確認してください。 ワークロード管理者は、エンタープライズ ネットワーク、セキュリティ、またはその他のプラットフォーム サービスからのログ エントリを関連付けるために、プラットフォーム管理者の支援を必要とする場合があります。

大事な

プラットフォーム チームの場合: 可能な場合は、ロールベースのアクセス制御 (RBAC) を付与して、関連するプラットフォーム リソースのログ シンクのクエリと読み取りを行います。 アプリケーション チームはトラブルシューティング タスク中にこの情報を使用できるため、ネットワークとアプリケーション ルールの評価と DNS プロキシのファイアウォール ログを有効にします。

Azure Policy

プラットフォーム チームは、ワークロードのデプロイに影響を与えるポリシーを適用する可能性があります。 多くの場合、DINE ポリシーを適用して、アプリケーション ランディング ゾーン サブスクリプションへの自動デプロイを処理します。 DINE ポリシーを使用すると、ワークロード リソースを変更したり、デプロイにリソースを追加したりできます。これにより、ワークロード テンプレートを通じて宣言的にデプロイされるリソースと、処理要求が実際に使用するリソースとの間に不一致が生じる可能性があります。 一般的な解決策は、命令型アプローチを使用してこれらの変更を修正することです。これは理想的ではありません。

この不一致を回避するには、プラットフォームによって開始された変更を先取りして IaC テンプレートに組み込んでテストします。 プラットフォーム チームがアプリケーションの要件と競合する Azure ポリシーを使用している場合は、プラットフォーム チームと解決策をネゴシエートできます。

大事な

Azure ランディング ゾーンでは、プライベート エンドポイントを大規模に管理するポリシーなど、さまざまな DINE ポリシーが使用されます。 このポリシーは、プライベート エンドポイントのデプロイを監視し、プラットフォームで管理されるサブスクリプションの一部であるハブ ネットワーク内の Azure DNS を更新します。 ワークロード チームには、ハブ内のポリシーを変更するアクセス許可がありません。また、プラットフォーム チームは、DNS を自動的に更新するためにワークロード チームのデプロイを監視しません。 DINE ポリシーは、この接続を提供するために使用されます。

その他のポリシーは、次のようなポリシーを含め、このアーキテクチャに影響する可能性があります。

• Active Directory ドメインに参加するには、Windows VM が必要です。 このポリシーにより、JoinADDomainExtension VM 拡張機能がインストールおよび構成されます。 詳細については、「Windows VM を適用して Active Directory ドメインに参加させる」を参照してください。
• ネットワーク インターフェイスでの IP 転送を禁止します。

時間の経過に伴う変更の管理

プラットフォームによって提供されるサービスと操作は、このアーキテクチャでは外部の依存関係と見なされます。 プラットフォーム チームは引き続き変更の適用、ユーザーのオンボード、コスト管理の適用を行います。 組織にサービスを提供するプラットフォーム チームは、個々のワークロードに優先順位を付けられない可能性があります。 これらの依存関係に対する変更は、ゴールデン イメージの変更、ファイアウォールの変更、自動修正、ルールの変更のいずれであっても、複数のワークロードに影響を与える可能性があります。

そのため、ワークロードチームとプラットフォームチームは、すべての外部依存関係を管理するために効率的かつタイムリーに通信する必要があります。 ワークロードに悪影響を及ぼさないように、変更をテストすることが重要です。

ワークロードに影響するプラットフォームの変更

このアーキテクチャでは、プラットフォーム チームが次のリソースを管理します。 これらのリソースに対する変更は、ワークロードの信頼性、セキュリティ、運用、およびパフォーマンスのターゲットに影響する可能性があります。 これらの変更は、プラットフォーム チームがそれらを有効にしてワークロードに与える影響を判断する前に評価することが重要です。

• Azure ポリシー: Azure ポリシーの変更は、ワークロード リソースとその依存関係に影響する可能性があります。 たとえば、直接ポリシーが変更されたり、ランディング ゾーンが新しい管理グループ階層に移動されたりすることがあります。 これらの変更は、新しいデプロイが行われるまで気付かない可能性があるため、十分にテストすることが重要です。

• ファイアウォール規則: ファイアウォール規則の変更は、ワークロードの仮想ネットワークまたはすべてのトラフィックに広く適用される規則に影響を与える可能性があります。 これらの変更により、トラフィックがブロックされ、OS パッチの適用が失敗したなどのサイレント プロセスエラーが発生する可能性があります。 これらの潜在的な問題は、エグレス Azure ファイアウォールと Azure Virtual Network Manager によって適用される NSG 規則の両方に適用されます。

• 共有リソース: 共有リソースの SKU または機能の変更がワークロードに影響する可能性があります。

• ハブ ネットワークのルーティング: ハブ内のルーティングの推移的な性質の変化は、ワークロードが他の仮想ネットワークへのルーティングに依存している場合に、ワークロードの機能に影響する可能性があります。

• Azure Bastion ホスト : Azure Bastion ホストの可用性または構成の変更は、ワークロード操作に影響する可能性があります。 ジャンプ ボックス アクセス パターンの変更に、効果的なルーチン、アドホック、緊急アクセスがあることを確認します。

• 所有権の変更: ワークロードの管理要求とサポート要求に影響を与える可能性があるため、所有権と連絡先の変更をワークロード チームに伝えます。

プラットフォームに影響するワークロードの変更

次の例は、プラットフォーム チームに伝える必要がある、このアーキテクチャでのワークロードの変更です。 プラットフォーム チームが、新しいワークロード チームの変更に対してプラットフォーム サービスの信頼性、セキュリティ、運用、およびパフォーマンスのターゲットを検証してから有効にすることが重要です。

• ネットワーク エグレス: ネットワーク エグレスの大幅な増加を監視して、ネットワーク デバイスでワークロードがノイズの多いネイバーにならないようにします。 この問題は、他のワークロードのパフォーマンスまたは信頼性のターゲットに影響する可能性があります。

• パブリック アクセス: ワークロード コンポーネントへのパブリック アクセスの変更には、さらにテストが必要になる場合があります。 プラットフォーム チームは、ワークロードを別の管理グループに再配置する場合があります。

• ビジネスの重要度評価: ワークロードのサービス レベル アグリーメント (SLA) に変更がある場合は、プラットフォームチームとワークロード チームの間で新しいコラボレーション アプローチが必要になる場合があります。

• 所有権の変更: 所有権と連絡先の変更をプラットフォーム チームに伝えます。

ワークロードビジネス要件の変更

ワークロードのサービス レベル目標 (SLO) を維持するには、プラットフォーム チームがワークロード アーキテクチャの変更に関与する必要がある場合があります。 これらの変更には、プラットフォーム チームからの変更管理や、既存のガバナンスが変更された要件をサポートしていることを検証することが必要な場合があります。

たとえば、プラットフォーム チームがファイアウォール、Virtual Network Manager、またはその他のコンポーネントにそのフローを追加して必要なトラフィックをサポートできるように、以前に禁止されていたエグレス フローに変更を伝達します。 逆に、以前に許可されたエグレス フローが不要になった場合、プラットフォーム チームは、ワークロードのセキュリティを維持するために、そのフローをブロックする必要があります。 また、他の仮想ネットワークまたはクロスプレミス エンドポイントへのルーティングの変更、またはアーキテクチャ コンポーネントへの変更も伝達します。 各リソースは、ポリシーとエグレス ファイアウォール制御の対象となる可能性があります。

考慮 事項

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、Microsoft Azure Well-Architected Framework のに関するページを参照してください。

確実

信頼性により、アプリケーションは顧客に対するコミットメントを確実に満たすことができます。 詳細については、「信頼性 設計レビューチェックリスト」を参照してください。

このアーキテクチャは、ベースライン アーキテクチャのにおける信頼性の保証と一致します。

信頼性のターゲット

エグレス ネットワーク制御などのコンポーネントが原因で、可能な最大複合 SLO がベースライン複合 SLO よりも 低くなります。 ランディング ゾーン環境で一般的なこれらのコンポーネントは、このアーキテクチャに固有ではありません。 ワークロード チームがこれらの Azure サービスを直接制御する場合、SLO も同様に削減されます。

可能な限り低い最大 SLO にもかかわらず、重要な信頼性の側面は、機能チーム間でのワークロード コンポーネントの分割です。 この方法により、ワークロード チームは、このワークロードやその他のワークロードで使用される重要なインフラストラクチャの運用に重点を置いた専門チームのメリットを得ることができます。

詳細については、「信頼性ターゲットを定義するための推奨事項」を参照してください。

重要な依存関係

ワークロードがプラットフォームとアプリケーションランディングゾーンで実行するすべての機能を依存関係として表示します。 インシデント対応計画では、ワークロード チームがこれらの依存関係の連絡先情報のポイントと方法を認識している必要があります。 また、これらの依存関係をワークロードの障害モード分析 (FMA) に含めます。

このアーキテクチャでは、次の依存関係を考慮してください。

• エグレス ファイアウォール: 複数のワークロードによって共有される一元化されたエグレス ファイアウォールは、ワークロードとは無関係に変更されます。

• ネットワーク ポートの枯渇: ネットワーク デバイスを共有するすべてのワークロードからの使用量が急増すると、エグレス ファイアウォールでネットワークの飽和またはポート不足が発生する可能性があります。

• DINE ポリシー: Azure DNS プライベート DNS ゾーン (またはその他のプラットフォームが提供する依存関係) の DINE ポリシーは、実行に SLA なしでベスト エフォート 。 DNS 構成の遅延により、アプリケーションがトラフィックを処理する準備が遅れる可能性があります。

• 管理グループ ポリシー: 環境間で一貫したポリシーが信頼性の鍵となります。 実稼働前環境が運用環境と類似していることを確認して、正確なテストを提供し、デプロイまたはスケールをブロックできる環境固有の逸脱を防ぎます。 詳細については、「Azure ランディング ゾーンでのアプリケーション開発環境の管理」を参照してください。

これらの考慮事項の多くは Azure ランディング ゾーンがない場合がありますが、ワークロードチームとプラットフォーム チームは、ニーズが満たされるように、これらの問題に共同で対処する必要があります。

詳細については、「エラー モードの分析を実行するための推奨事項」を参照してください。

安全

セキュリティは、意図的な攻撃や貴重なデータとシステムの悪用に対する保証を提供します。 詳細については、「セキュリティ 設計レビューチェックリスト」を参照してください。

このアーキテクチャのセキュリティに関する考慮事項は、ベースライン アーキテクチャから引き継がれた値です。 次のセクションの推奨事項は、Well-Architected Framework のセキュリティ設計レビュー チェックリストに基づいています。

ネットワークコントロール

ワークロードがセキュリティで保護されるようにネットワーク制御を適切に構成します。

イングレス トラフィック

サブネット上の NSG またはリージョン ハブの非推移的な性質または制御を使用して、組織内の他のワークロード スポークからワークロードを分離できます。 アプリケーションとそのインフラストラクチャの受信ネットワーク要件のみを許可する包括的な NSG を構築します。 セキュリティのために、ハブ ネットワークの非推移的な性質だけに依存しないことをお勧めします。

プラットフォーム チームは、Azure ポリシーを実装して、Application Gateway で Web アプリケーション ファイアウォールが拒否モード に設定されていることを確認し、サブスクリプションで使用できるパブリック IP の数やその他のチェックを制限します。 これらのポリシーに加えて、ワークロード チームは、イングレス セキュリティ体制を強化するワークロード中心のポリシーをデプロイする責任を負う必要があります。

次の表に、このアーキテクチャのイングレス コントロールの例を示します。

源	目的	ワークロード制御	プラットフォーム制御
インターネット	ユーザー トラフィック フロー	パブリック トラフィックがフロントエンド VM に入るプライベート トラフィックへの移行を許可する前に、NSG、Web アプリケーション ファイアウォール、およびルーティング規則を介してすべての要求をファネルします	何一つ
Azure Bastion	VM へのオペレーター アクセス	プラットフォームの指定された Azure Bastion サブネットからソース化されていない限り、リモート アクセス ポートへのすべてのトラフィックをブロックする VM サブネット上の NSG	何一つ
その他のスポーク	何一つ	NSG ルールを使用してブロックする	Azure Virtual WAN セキュリティで保護されたハブの場合の非トランザクション ルーティングまたは Azure Firewall 規則

エグレス トラフィック

ソリューションの必要な送信接続要件を表す NSG ルールを適用し、それ以外のすべてを拒否します。 ハブ ネットワークコントロールだけに依存しないでください。 ワークロード オペレーターは、望ましくないエグレス トラフィックを、実行可能なソースの近くで停止する必要があります。

仮想ネットワーク内でサブネットを所有している間、プラットフォーム チームは、キャプチャした要件をサブスクリプションの自動販売機プロセスの一部として具体的に表すファイアウォール規則を作成した可能性があることに注意してください。 アーキテクチャの有効期間中のサブネットとリソース配置の変更が、元の要求と互換性があることを確認します。 または、ネットワーク チームと協力して、最小アクセスエグレス制御の継続性を確保することもできます。

次の表に、このアーキテクチャのエグレスの例を示します。

エンドポイント	目的	ワークロード (NSG) コントロール	プラットフォーム (ハブ) コントロール
ntp.ubuntu.com	Linux VM のネットワーク タイム プロトコル (NTP)	UDP/123 をフロントエンド VM サブネット上のインターネットに します (エグレス ファイアウォールによって、この広範な開放が狭くなります)	ワークロード制御と同じファイアウォール ネットワーク規則の許容量
Windows Update エンドポイント	Microsoft サーバーからの Windows Update 機能	TCP/443 を し、バックエンド VM サブネット上のインターネットに TCP/80 を します (エグレス ファイアウォールによって、この広範な開放が狭くなります)	FQDN タグが WindowsUpdate のファイアウォール許容規則
エージェント エンドポイントの監視	VM 上の Monitor 拡張機能に必要なトラフィック	TCP/443 を両方の VM サブネット上のインターネットに します (エグレス ファイアウォールはこの広範な開放を狭めます)	TCP/443 上のすべての特定の FQDN に必要なファイアウォール アプリケーション規則の許容量
nginx.org	ベンダーから直接 Nginx (アプリケーション コンポーネントの例) をインストールするには	TCP/443 をフロントエンド VM サブネット上のインターネットに します (エグレス ファイアウォールによって、この広範な開放が狭くなります)	TCP/443 での nginx.org に必要なファイアウォール アプリケーション規則の許容量
Key Vault (キー・ボールト)	Application Gateway と VM に TLS 証明書をインポート (トランスポート層セキュリティ) するには	TCP/443を両方の VM サブネットからプライベート エンドポイント サブネットに - する Application Gateway サブネットからプライベート エンドポイント サブネットに TCP/443を - する 必要なアプリケーション セキュリティ グループ (ASG) の指定と Application Gateway サブネットでタグ付けされた VM から TCP/443を - する	何一つ

DDoS攻撃からの保護

ソリューションのすべてのパブリック IP を対象とする DDoS Protection プランの適用を担当するユーザーを決定します。 プラットフォーム チームは、IP 保護プランを使用することも、Azure Policy を使用して仮想ネットワーク保護プランを適用することもできます。 このアーキテクチャには、インターネットからのイングレス用のパブリック IP が含まれるため、カバレッジが必要です。

詳細については、「ネットワークと接続のに関する推奨事項」を参照してください。

シークレット管理

シークレット管理の場合、このアーキテクチャは ベースライン アーキテクチャのに従います。

ワークロード チームとして、Key Vault インスタンスにシークレットを保持し続けます。 アプリケーションとインフラストラクチャの操作をサポートするために、必要に応じてさらにインスタンスをデプロイします。

詳細については、「アプリケーション シークレットを保護するための推奨事項」を参照してください。

コストの最適化

コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コストの最適化 設計レビューチェックリスト」を参照してください。

ワークロード リソースの場合、ベースライン アーキテクチャのコスト最適化戦略 このアーキテクチャにも適用されます。

このアーキテクチャは、Azure ランディング ゾーン プラットフォーム リソースから大きなメリットを得られます。 チャージバック モデルを使用してこれらのリソースを使用する場合でも、追加されたセキュリティとクロスプレミス接続は、それらのリソースを自己管理するよりもコスト効率が高くなります。

プラットフォーム チームは、このアーキテクチャで次のリソースを管理します。 多くの場合、これらのリソースは使用量ベース (チャージバック) であるか、ワークロード チームに無料である可能性があります。

• Azure Firewall
• セキュリティ情報とイベント管理 (SIEM)
• Azure Bastion ホスト
• ExpressRoute などのクロスプレミス接続

プラットフォーム チームの他の一元化されたオファリングを活用して、SLO、目標復旧時間 (RTO)、または目標復旧ポイント (RPO) を損なうことなく、それらの利点をワークロードに拡張します。

詳細については、「コスト データの収集と確認に関する推奨事項」を参照してください。

このシナリオをデプロイする

この参照アーキテクチャのデプロイは、GitHub で入手できます。

実装: Azure ランディング ゾーン での VM ベースライン アーキテクチャ

次の手順

ワークロード チームとプラットフォーム チームの間で共有されているコラボレーションと技術的な詳細を確認します。

サブスクリプションの自動販売機

この記事のアーキテクチャは、仮想マシン (VM) ベースライン アーキテクチャ を拡張して、Azure ランディング ゾーンにデプロイするときの変更と期待に対応します。

この記事の例では、組織は、プラットフォーム チームが一元的に管理するフェデレーション リソースを VM ベースのワークロードで使用することを望んでいます。 これらのリソースには、クロスプレミス接続、ID アクセス管理、ポリシー用のネットワーク リソースが含まれます。 この例では、組織が Azure ランディング ゾーンを採用して、複数のワークロードにわたって一貫したガバナンスとコスト効率を適用することを前提としています。

ワークロード所有者は、共有リソースの管理を中央チームにオフロードできるため、ワークロード開発作業に集中できます。 この記事では、ワークロード チームの視点について説明します。 プラットフォーム チーム向けの推奨事項が指定されています。

大事な

Azure ランディング ゾーンとは Azure ランディング ゾーンは、組織のクラウド フットプリントの 2 つの観点を示します。 アプリケーション ランディング ゾーン は、ワークロードが実行される Azure サブスクリプションです。 組織の共有リソースに接続されています。 その接続を通じて、ネットワーク、ID アクセス管理、ポリシー、監視など、ワークロードを実行する基本的なインフラストラクチャにアクセスできます。 プラットフォーム ランディング ゾーン は、それぞれが特定の機能を持つさまざまなサブスクリプションのコレクションです。 たとえば、接続サブスクリプションでは、一元化されたドメイン ネーム システム (DNS) の解決、クロスプレミス接続、およびアプリケーション チームが使用できるネットワーク仮想アプライアンス (NVA) が提供されます。

このアーキテクチャの実装の準備に役立つ azure ランディング ゾーン 概念を理解することをお勧めします。

記事のレイアウト

建築	設計上の決定	Azure Well-Architected Framework のアプローチ
▪ アーキテクチャ図の ▪ ワークロード リソース を する ▪ フェデレーション リソース の	▪ サブスクリプションのセットアップ ▪ ネットワーク要件 ▪ ベースライン からのネットワーク設計の変更 ▪ 監視 ▪ Patch コンプライアンス ▪ 組織のガバナンス ▪ 変更管理	▪ 信頼性 ▪ セキュリティ ▪ コストの最適化の

先端

GitHub ロゴを この リファレンス実装 は、この記事で説明するベスト プラクティスを示しています。

リポジトリ成果物は、環境に合わせてカスタマイズ可能な基盤を提供します。 この実装では、デモンストレーション用に Azure Firewall などの共有リソースを使用してハブ ネットワークを設定します。 このセットアップは、個別のワークロードとプラットフォームの機能に対して個別のアプリケーション ランディング ゾーン サブスクリプションに適用できます。

建築

このアーキテクチャの Visio ファイル をダウンロードします。

コンポーネント

すべての Azure ランディング ゾーン アーキテクチャでは、プラットフォーム チームとワークロード チームの間で所有権が分離されています。 アプリケーション アーキテクトと DevOps チームは、直接的な影響や制御の下にあるものとそうでないものを理解するために、この責任分割について強く理解する必要があります。

ワークロード チーム所有のリソース

次のリソースは、ベースライン アーキテクチャのとほとんど変わりません。

• Azure Virtual Machines はアプリケーション プラットフォームです。 コンピューティング リソースは、可用性ゾーン間で分散されます。

• azure Load Balancer は、フロントエンド VM からバックエンド VM へのトラフィックをプライベートに負荷分散するために使用されます。 ロード バランサーは、ゾーン間で VM にトラフィックを分散します。

• Azure Application Gateway は、ユーザー要求をフロントエンド VM にルーティングするためのリバース プロキシとして使用されます。 選択した SKU は、悪意のある可能性のあるトラフィックからフロントエンド VM を保護するために、Azure Web アプリケーション ファイアウォールをホストするためにも使用されます。

• Azure Key Vault は、アプリケーション シークレットと証明書を格納するために使用されます。

• Azure Monitor、Log Analytics、および Application Insights は、監視データの収集、格納、視覚化に使用されます。

• Azure Policy は、ワークロードに固有のポリシーを適用するために使用されます。

ワークロード チームは、次のリソースと責任を維持し、実行します。

• スポーク仮想ネットワーク サブネットと、セグメント化を維持し、トラフィック フローを制御するためにそれらのサブネットに配置されるネットワーク セキュリティ グループ (NSG)。

• プライベート エンドポイント、サービスとしてのプラットフォーム (PaaS) ソリューションへの接続をセキュリティで保護し、それらのエンドポイントに必要な プライベート DNS ゾーン。

• Azure Managed Disks はバックエンド サーバーにログ ファイルを格納し、VM が再起動してもデータは保持されます。 フロントエンド サーバーには、ステートレス アプリケーションのデプロイに使用できるディスクが接続されています。

チーム所有のプラットフォーム リソース

プラットフォーム チームは、これらの一元化されたリソースを所有し、維持します。 このアーキテクチャでは、これらのリソースが事前にプロビジョニングされていることを前提とし、依存関係を考慮します。

• ハブ ネットワーク内 Azure Firewall は、エグレス トラフィックの検査と制限に使用されます。 このコンポーネントは、インターネットへの送信トラフィックに制限を提供しないベースライン アーキテクチャの標準ロード バランサーを置き換えます。

• ハブ ネットワークに Azure Bastion を 、ワークロード VM への安全な運用アクセスを提供します。 ベースライン アーキテクチャでは、ワークロード チームがこのコンポーネントを所有しています。

• スポーク仮想ネットワーク は、ワークロードがデプロイされる場所です。

• ユーザー定義ルート (UDR) は、ハブ ネットワークへのトンネリングを強制するために使用されます。

• Azure Policy ベースのガバナンス制約 と DeployIfNotExists (DINE) ポリシーは、ワークロード サブスクリプションの一部です。

大事な

Azure ランディング ゾーンは、プラットフォーム ランディング ゾーン サブスクリプションの一部として上記のリソースの一部を提供し、ワークロード サブスクリプションは他のリソースを提供します。 多くのリソースは接続サブスクリプションの一部であり、Azure ExpressRoute、Azure VPN Gateway、Azure DNS などの追加リソースがあります。 これらの追加リソースは、クロスプレミス アクセスと名前解決を提供します。 これらのリソースの管理は、この記事の範囲外です。

サブスクリプションのセットアップ

ランディング ゾーンのコンテキストでは、ワークロード チームはプラットフォーム チームに固有の要件を通知する必要があります。

ワークロード チーム には、プラットフォーム チームが必要なリソースを割り当てることができるように、ワークロードに必要なネットワーク領域に関する詳細情報が含まれている必要があります。 チームが要件を決定し、プラットフォーム チームは、仮想ネットワーク内で割り当てる IP アドレスと、サブスクリプションが割り当てられている管理グループを決定します。

プラットフォーム チーム は、ワークロードがインターネットに公開されている場合など、ワークロードのビジネスの重要度と技術的要件に基づいて適切な管理グループを割り当てます。 組織はこれらの管理グループの構成を決定し、プラットフォーム チームがそれらを実装します。

たとえば、ベースライン アーキテクチャ のアプリケーション シナリオの管理グループは、次の内容と見なされます。

• プライベート アプリケーション(社内の基幹業務アプリケーションや商用の既製 (COTS) ソリューションなど)、多くの場合、Azure ランディング ゾーンの Corp 管理グループの下にあります。

• パブリック アプリケーションは、インターネットに接続するアプリケーションと同様に。多くの場合、Corp または Online 管理グループの下にあります。

プラットフォーム チームは、ワークロードのデプロイ用にサブスクリプションまたはサブスクリプションのグループを設定する役割も担います。

次のセクションでは、サブスクリプションの初期セットアップに関するガイダンスを提供します。 ただし、プラットフォーム チームは通常、一元化されたサービスに変更を加えて、見落とされた要件や変更された要件に対処します。 プラットフォームの変更は、すべてのワークロード チームに広範な影響を与えます。

そのため、プラットフォーム チームは、すべての VM ワークロードが変更に対して準備されていることを確認し、VM ベースのソリューションのライフ サイクルとテスト サイクルを認識する必要があります。 詳細については、「時間経過に伴う変更の管理」を参照してください。

ワークロードの要件とフルフィルメント

ワークロード チームとプラットフォーム チームは、管理グループの割り当てとネットワークのセットアップという 2 つの主な責任を共有します。 このアーキテクチャでは、プラットフォーム チームと通信する必要がある次のネットワーク要件を検討してください。 これらのポイントを例として使用して、同様のアーキテクチャを実装するときに 2 つのチーム間のディスカッションとネゴシエーションを理解します。

• スポーク仮想ネットワークの数: このアーキテクチャでは、専用スポークが 1 つだけ必要です。 デプロイされたリソースは複数のネットワークにまたがる必要がなく、単一の仮想ネットワーク内に併置されます。

• スポーク ネットワークののサイズ: 運用要件とワークロードの予想される増加を考慮します。 たとえば、青/緑またはカナリアの更新プログラムを実装する予定の場合は、サイド バイ サイドデプロイで必要な領域を最大サイズで考慮する必要があります。

  今後の変更では、より多くの IP 領域が必要になる可能性があり、現在の割り当てとずれる可能性があります。 これらのスペースを統合すると、複雑さが増す可能性があります。 事前に準備し、割り当てられた領域が将来の拡張に対応できるように十分なネットワーク リソースを事前に要求します。

• デプロイ リージョン: ワークロードをデプロイするリージョンを指定することが重要です。 プラットフォーム チームは、この情報を使用して、スポークとハブの仮想ネットワークが同じリージョンに確実にプロビジョニングされるようにすることができます。 異なるリージョン間のネットワークでは、リージョン境界を越えるトラフィックが原因で待機時間の問題が発生する可能性があり、帯域幅の追加コストが発生する可能性もあります。

• ワークロードの特性と設計の選択: 設計の選択、コンポーネント、特性をプラットフォーム チームに伝えます。 たとえば、ワークロードがインターネットへの多数の同時接続 (チャット) を生成することが予想される場合、プラットフォーム チームは、枯渇を防ぐために十分なポートが使用可能であることを確認する必要があります。 トラフィックをサポートするために一元化されたファイアウォールに IP アドレスを追加したり、代替パスを介してトラフィックをルーティングするネットワーク アドレス変換 (NAT) ゲートウェイを設定したりできます。

  逆に、ワークロードが最小限のネットワーク トラフィック (バックグラウンド ノイズ) を生成することが予想される場合、プラットフォーム チームは組織全体でリソースを効率的に使用する必要があります。

  プラットフォーム チームは、依存関係を明確に理解する必要があります。 たとえば、ワークロードが別のチームが所有するデータベースへのアクセスが必要な場合や、ワークロードにクロスプレミス トラフィックがある場合があります。 ワークロードには Azure の外部に依存関係がありますか? このような情報は、プラットフォーム チームが知るために重要です。

• ファイアウォール構成: プラットフォーム チームは、スポーク ネットワークを離れ、ハブ ネットワークにトンネリングされるトラフィックを認識している必要があります。 ハブ内のファイアウォールでは、そのトラフィックをブロックできません。

  たとえば、ワークロードが Windows 更新プログラムにアクセスして修正プログラムを適用し続ける必要がある場合、ファイアウォールはこれらの更新プログラムをブロックしないようにする必要があります。 同様に、特定のエンドポイントにアクセスするモニター エージェントがある場合は、ワークロードの監視データが中断される可能性があるため、ファイアウォールでそのトラフィックをブロックしないでください。 アプリケーションでは、サード パーティのエンドポイントへのアクセスが必要になる場合があります。 いずれの場合も、一元化されたファイアウォールを使用して、予想されるトラフィックと警告されていないトラフィックを区別します。

• オペレーターアクセス: オペレーターが Azure Bastion 経由で VM にアクセスするために使用する Microsoft Entra ID セキュリティ グループがある場合は、プラットフォーム チームに通知します。 通常、Azure Bastion は中央リソースです。 セキュリティ グループと VM がセキュリティで保護されたプロトコルをサポートしていることを確認することが重要です。

  さらに、VM を含む IP 範囲についてプラットフォーム チームに通知します。 この情報は、ハブ ネットワークで Azure Bastion 周辺の NSG を構成するために必要です。

• パブリック IP: 予想されるパブリック IP アドレスを含め、イングレス トラフィック プロファイルについてプラットフォーム チームに通知します。 このアーキテクチャでは、インターネットソースのトラフィックのみが Application Gateway のパブリック IP を対象としています。 プラットフォーム チームは、これらの IP が Azure DDoS Protection プランの下にある場合、またはそれがワークロード チームの責任である場合は、ワークロード チームに通知する必要があります。

  このアーキテクチャでは、Azure Bastion 経由で運用アクセスするための別のパブリック IP があります。 プラットフォーム チームはこのパブリック IP を所有し、プラットフォーム チームが管理する DDoS Protection などのサービスに登録されます。

大事な

ワークロード チームからの情報をキャプチャするように設計された一連の質問を含むプラットフォーム チームには、サブスクリプションの自販ワークストリームをお勧めします。 これらの質問は組織によって異なる場合がありますが、サブスクリプションを実装するための要件を収集することが目的です。 詳細については、「サブスクリプションの自動販売機」を参照してください。

VM の設計の選択肢

VM SKU とディスクの選択は、ベースライン アーキテクチャと同じです。

組織は、特定の VM イメージの使用を義務付けるコンプライアンス要件をワークロード チームに課す場合があります。 このような要件を考えると、プラットフォーム チームは、組織全体で使用するために作成される、ゴールデン イメージと呼ばれる一連の標準化されたイメージを管理する場合があります。

プラットフォーム チームは、Azure コンピューティング ギャラリーやプライベート リポジトリなどのマネージド オファリングを使用して、承認された OS イメージまたはワークロード成果物を格納する場合があります。 VM の OS イメージを選択する場合は、イメージ ソース、更新頻度、および使用の期待についてプラットフォーム チームに問い合わせてください。 また、イメージがワークロードで満たす必要なビジネス要件を満たすことができることを確認します。

大事な

プラットフォーム チームの: コンピューティング ギャラリーを使用する場合、ワークロードにはプライベート ギャラリーに対するネットワークの可視性が必要です。 ワークロード チームと共同作業して、セキュリティで保護された接続を確立します。

ネットワーキング

ベースライン アーキテクチャでは、ワークロードは 1 つの仮想ネットワークにプロビジョニングされます。 ワークロード チームが仮想ネットワークを管理します。

このアーキテクチャでは、プラットフォーム チームがネットワーク トポロジを決定します。 このアーキテクチャでは、ハブスポーク トポロジが想定されています。

このアーキテクチャの Visio ファイル をダウンロードします。

• ハブ仮想ネットワーク: リージョン ハブには、同じリージョン内のワークロード リソースと通信する一元化されたサービスが含まれています。 詳細については、「プラットフォームのチーム所有リソース」を参照してください。 接続サブスクリプションにハブを配置することをお勧めします。

• スポーク仮想ネットワーク: このアーキテクチャでは、ベースライン アーキテクチャの単一の仮想ネットワークがスポーク ネットワークです。 一元化されたサービスを含むハブ ネットワークにピアリングされます。 プラットフォーム チームは、このスポーク ネットワークを所有し、管理します。 このネットワークには、ワークロード リソースが含まれています。 ワークロード チームは、サブネットを含め、このネットワーク内のリソースを所有しています。

プラットフォーム チームに ワークロード要件を伝え、定期的に確認。

大事な

プラットフォーム チームの: ワークロードで特に必要な場合を除き、スポーク ネットワークを別のスポーク仮想ネットワークに直接ピアリングしないでください。 この方法では、ワークロードのセグメント化目標を保護します。 チームは、推移的な仮想ネットワーク接続をすべて容易にする必要があります。

仮想ネットワーク サブネット

スポーク仮想ネットワークでは、ワークロード チームがサブネットを作成して割り当てます。 サブネットとの間でトラフィックを制限するコントロールを配置すると、セグメント化を実現するのに役立ちます。 このアーキテクチャでは、ベースライン アーキテクチャと同じサブネット トポロジが使用されます。このアーキテクチャには、Application Gateway、フロントエンド VM、ロード バランサー、バックエンド VM、プライベート エンドポイント用の専用サブネットがあります。

Azure ランディング ゾーンにワークロードをデプロイする場合でも、ネットワーク制御を実装する必要があります。 組織は、データ流出から保護し、中央セキュリティ オペレーション センター (SOC) と IT ネットワーク チームの可視性を確保するために制限を課す場合があります。

このアプローチにより、プラットフォーム チームは、組織全体のワークロードごとに冗長なセキュリティ制御をデプロイするのではなく、一元化されたサービスを使用して組織全体の支出を最適化できます。 このアーキテクチャでは、Azure Firewall が中央サービスの例です。 各ワークロード チームが独自のファイアウォール インスタンスを管理することは、コスト効率が高く、実用的ではありません。 ファイアウォール管理の一元化されたアプローチをお勧めします。

イングレス トラフィック

イングレス トラフィック フローは、ベースライン アーキテクチャと同じです。

ワークロード所有者は、ワークロードへのパブリック インターネットイングレスに関連するすべてのリソースを担当します。 たとえば、このアーキテクチャでは、Application Gateway とそのパブリック IP はハブ ネットワークではなくスポーク ネットワークに配置されます。 一部の組織では、一元化された非武装地帯 (DMZ) の実装を使用して、イングレス トラフィックを含むリソースを接続サブスクリプションに配置する場合があります。 この記事では、その特定のトポロジとの統合は範囲外です。

エグレス トラフィック

ベースライン アーキテクチャでは、ワークロード仮想マシン スケール セットは Azure Load Balancer を介してパブリック インターネットにアクセスしますが、そのトラフィックは制限されません。

このアーキテクチャでは、その設計が異なります。 スポーク仮想ネットワークを離れるすべてのトラフィックは、エグレス ファイアウォール経由でピアリングされたハブ ネットワーク経由でルーティングされます。 ルートは、ローカル仮想ネットワーク (0.0.0.0/0) に見つからない IP のすべてのトラフィックをハブの Azure Firewall に転送する、スポーク ネットワーク内のすべての可能なサブネットに接続されます。

このアーキテクチャの Visio ファイル をダウンロードします。

Key Vault アクセス用のプライベート エンドポイントへのワークロード通信は、ベースライン アーキテクチャと同じです。 このパスは、簡潔にするために前の図から省略されています。

ワークロード チームは、インフラストラクチャとワークロードの運用に必要なすべての送信トラフィック フローを特定し、文書化し、通信する必要があります。 プラットフォーム チームは必要なトラフィックを許可し、すべての非コミットエグレス トラフィックが拒否される可能性があります。

エグレス トラフィックの制御は、予想されるトラフィックが許可されることを確認するだけではありません。 また、予想されるトラフィックのみを許可 確認することも必要です。 非コミットのエグレス トラフィックは既定で拒否される可能性がありますが、トラフィックが適切にルーティングされるようにするのは、ワークロードのセキュリティ上の最善の目的です。

先端

Azure Firewall で IP グループを使用するようプラットフォーム チームに勧める。 この方法により、ワークロードのエグレス トラフィックのニーズが、ソース サブネットのみに厳密なスコープで正確に表現されるようになります。 たとえば、ワークロード VM が api.example.org に到達できるようにする規則は、同じ仮想ネットワーク内のサポート リソースが同じエンドポイントにアクセスできることを必ずしも意味するとは限りません。 このレベルの細かい制御により、ネットワークのセキュリティ体制を強化できます。

プラットフォーム チームに固有のエグレス トラフィック要件を伝えます。 たとえば、ワークロードで外部ネットワーク エンドポイントへの多数の同時接続が確立されている場合は、プラットフォーム チームに通知します。 その後、プラットフォーム チームは、適切な Azure NAT ゲートウェイ実装をプロビジョニングするか、軽減策のためにリージョン ファイアウォールにパブリック IP を追加できます。

組織には、ワークロード所有のパブリック IP をエグレスに使用するアーキテクチャ パターンの使用を推奨しない要件がある場合があります。 その場合は、Azure Policy を使用して、VM ネットワーク インターフェイス カード (NIC) とその他のパブリック IP (既知のイングレス ポイント以外) のパブリック IP を拒否できます。

プライベート DNS ゾーン

プライベート エンドポイントを使用するアーキテクチャでは、DNS プロバイダーと連携するためにプライベート DNS ゾーンが必要です。 ワークロード チームは、プラットフォーム チームが提供するサブスクリプションのプライベート DNS ゾーンの要件と管理を明確に理解している必要があります。 プライベート DNS ゾーンは通常、DINE ポリシーを使用して大規模に管理されます。これにより、Azure Firewall は信頼性の高い DNS プロキシとして機能し、完全修飾ドメイン名 (FQDN) ネットワーク規則をサポートできます。

このアーキテクチャでは、プラットフォーム チームは、プライベート リンク エンドポイントの信頼性の高いプライベート DNS 解決を保証します。 プラットフォーム チームと共同作業して、期待を理解します。

接続テスト

VM ベースのアーキテクチャの場合、ネットワークの見通し、ルーティング、DNS の問題を特定するのに役立つテスト ツールがいくつかあります。 netstat、nslookup、tcpingなどの従来のトラブルシューティング ツールを使用できます。 さらに、ネットワーク アダプターの動的ホスト構成プロトコル (DHCP) と DNS の設定を調べることができます。 NIC がある場合は、Azure Network Watcher を使用して接続チェックを実行できる、より多くのトラブルシューティング機能があります。

オペレーター アクセス

ベースライン アーキテクチャと同様に、このアーキテクチャでは Azure Bastion を介した運用アクセスがサポートされています。

ただし、ベースライン アーキテクチャでは、ワークロードの一部として Azure Bastion がデプロイされます。 Azure ランディング ゾーンを採用する一般的な組織では、各リージョンの中央リソースとして Azure Bastion をデプロイします。 プラットフォーム チームは Azure Bastion を所有し、維持し、組織内のすべてのワークロードで共有します。 このアーキテクチャのユース ケースを示すために、Azure Bastion は接続サブスクリプションのハブ ネットワークにあります。

オペレーター ID

このアーキテクチャでは、ベースライン アーキテクチャと同じ認証拡張機能が使用されます。

手記

オペレーターは VM にログインするときに、Microsoft Entra ID テナントで会社の ID を使用する必要があり、機能間でサービス プリンシパルを共有する必要はありません。

常に、長期的なアクセスではなく、最小限の特権と詳細なアクセスの原則から始めます。 ランディング ゾーンコンテキストでは、プラットフォーム チームが管理する Just-In-Time (JIT) サポートを利用します。

パッチのコンプライアンスと OS のアップグレード

ベースライン アーキテクチャ では、修正プログラムの適用とアップグレードに対する自律的なアプローチについて説明します。 ワークロードがランディング ゾーンと統合されると、そのアプローチが変わる可能性があります。 プラットフォーム チームは、すべてのワークロードが組織の要件に準拠するように修正プログラムの適用操作を指示する場合があります。

パッチ適用プロセスに、アーキテクチャに追加するすべてのコンポーネントが含まれていることを確認します。 たとえば、アプリケーションのデプロイ、スケーリング、管理を自動化するためにビルド エージェント VM を追加する場合、それらの VM はプラットフォームの要件に準拠している必要があります。

モニタリング

Azure ランディング ゾーン プラットフォームは、管理サブスクリプションの一部として共有可観測性リソースを提供します。 ただし、ワークロードの所有権の責任を容易にするために、独自の監視リソースをプロビジョニングすることをお勧めします。 このアプローチは、ベースライン アーキテクチャのと一致します。

ワークロード チームは、次のような監視リソースをプロビジョニングします。

• ワークロード チームのアプリケーション パフォーマンス監視 (APM) サービスとしての Application Insights。

• Log Analytics ワークスペースは、ワークロード所有の Azure リソースとアプリケーション コードから収集されるすべてのログとメトリックの統合シンクです。

このアーキテクチャの Visio ファイル をダウンロードします。

ベースラインと同様に、すべてのリソースは、ワークロード チームがリソースのコードとしてのインフラストラクチャ (IaC) デプロイの一部としてプロビジョニングする Log Analytics ワークスペースに Azure Diagnostics ログを送信するように構成されます。 また、中央の Log Analytics ワークスペースにログを送信する必要がある場合もあります。 Azure ランディング ゾーンでは、そのワークスペースは管理サブスクリプションにあります。

プラットフォーム チームには、集中管理サブスクリプションにログを送信するように診断を構成するために使用できる DINE ポリシーもあります。 実装で追加のログ フローが制限されないようにすることが重要です。

複数のシンクからのデータを関連付ける

ワークロードのログとメトリックとそのインフラストラクチャ コンポーネントは、ワークロードの Log Analytics ワークスペースに格納されます。 ただし、Azure Firewall、Microsoft Entra ID、Azure Bastion などの一元化されたサービスが生成するログとメトリックは、中央の Log Analytics ワークスペースに格納されます。 複数のシンクからのデータの関連付けは、複雑なタスクになる可能性があります。

相関データは、インシデント対応時によく使用されます。 複数のシンクからのデータの関連付けに問題がある場合は、このアーキテクチャのトリアージ Runbook がそれに対処し、問題がワークロード リソースを超える場合は、組織の連絡先が含まれていることを確認してください。 ワークロード管理者は、エンタープライズ ネットワーク、セキュリティ、またはその他のプラットフォーム サービスからのログ エントリを関連付けるために、プラットフォーム管理者の支援を必要とする場合があります。

大事な

プラットフォーム チームの場合: 可能な場合は、ロールベースのアクセス制御 (RBAC) を付与して、関連するプラットフォーム リソースのログ シンクのクエリと読み取りを行います。 アプリケーション チームはトラブルシューティング タスク中にこの情報を使用できるため、ネットワークとアプリケーション ルールの評価と DNS プロキシのファイアウォール ログを有効にします。

Azure Policy

プラットフォーム チームは、ワークロードのデプロイに影響を与えるポリシーを適用する可能性があります。 多くの場合、DINE ポリシーを適用して、アプリケーション ランディング ゾーン サブスクリプションへの自動デプロイを処理します。 DINE ポリシーを使用すると、ワークロード リソースを変更したり、デプロイにリソースを追加したりできます。これにより、ワークロード テンプレートを通じて宣言的にデプロイされるリソースと、処理要求が実際に使用するリソースとの間に不一致が生じる可能性があります。 一般的な解決策は、命令型アプローチを使用してこれらの変更を修正することです。これは理想的ではありません。

この不一致を回避するには、プラットフォームによって開始された変更を先取りして IaC テンプレートに組み込んでテストします。 プラットフォーム チームがアプリケーションの要件と競合する Azure ポリシーを使用している場合は、プラットフォーム チームと解決策をネゴシエートできます。

大事な

Azure ランディング ゾーンでは、プライベート エンドポイントを大規模に管理するポリシーなど、さまざまな DINE ポリシーが使用されます。 このポリシーは、プライベート エンドポイントのデプロイを監視し、プラットフォームで管理されるサブスクリプションの一部であるハブ ネットワーク内の Azure DNS を更新します。 ワークロード チームには、ハブ内のポリシーを変更するアクセス許可がありません。また、プラットフォーム チームは、DNS を自動的に更新するためにワークロード チームのデプロイを監視しません。 DINE ポリシーは、この接続を提供するために使用されます。

その他のポリシーは、次のようなポリシーを含め、このアーキテクチャに影響する可能性があります。

• Active Directory ドメインに参加するには、Windows VM が必要です。 このポリシーにより、JoinADDomainExtension VM 拡張機能がインストールおよび構成されます。 詳細については、「Windows VM を適用して Active Directory ドメインに参加させる」を参照してください。
• ネットワーク インターフェイスでの IP 転送を禁止します。

時間の経過に伴う変更の管理

プラットフォームによって提供されるサービスと操作は、このアーキテクチャでは外部の依存関係と見なされます。 プラットフォーム チームは引き続き変更の適用、ユーザーのオンボード、コスト管理の適用を行います。 組織にサービスを提供するプラットフォーム チームは、個々のワークロードに優先順位を付けられない可能性があります。 これらの依存関係に対する変更は、ゴールデン イメージの変更、ファイアウォールの変更、自動修正、ルールの変更のいずれであっても、複数のワークロードに影響を与える可能性があります。

そのため、ワークロードチームとプラットフォームチームは、すべての外部依存関係を管理するために効率的かつタイムリーに通信する必要があります。 ワークロードに悪影響を及ぼさないように、変更をテストすることが重要です。

ワークロードに影響するプラットフォームの変更

このアーキテクチャでは、プラットフォーム チームが次のリソースを管理します。 これらのリソースに対する変更は、ワークロードの信頼性、セキュリティ、運用、およびパフォーマンスのターゲットに影響する可能性があります。 これらの変更は、プラットフォーム チームがそれらを有効にしてワークロードに与える影響を判断する前に評価することが重要です。

• Azure ポリシー: Azure ポリシーの変更は、ワークロード リソースとその依存関係に影響する可能性があります。 たとえば、直接ポリシーが変更されたり、ランディング ゾーンが新しい管理グループ階層に移動されたりすることがあります。 これらの変更は、新しいデプロイが行われるまで気付かない可能性があるため、十分にテストすることが重要です。

• ファイアウォール規則: ファイアウォール規則の変更は、ワークロードの仮想ネットワークまたはすべてのトラフィックに広く適用される規則に影響を与える可能性があります。 これらの変更により、トラフィックがブロックされ、OS パッチの適用が失敗したなどのサイレント プロセスエラーが発生する可能性があります。 これらの潜在的な問題は、エグレス Azure ファイアウォールと Azure Virtual Network Manager によって適用される NSG 規則の両方に適用されます。

• 共有リソース: 共有リソースの SKU または機能の変更がワークロードに影響する可能性があります。

• ハブ ネットワークのルーティング: ハブ内のルーティングの推移的な性質の変化は、ワークロードが他の仮想ネットワークへのルーティングに依存している場合に、ワークロードの機能に影響する可能性があります。

• Azure Bastion ホスト : Azure Bastion ホストの可用性または構成の変更は、ワークロード操作に影響する可能性があります。 ジャンプ ボックス アクセス パターンの変更に、効果的なルーチン、アドホック、緊急アクセスがあることを確認します。

• 所有権の変更: ワークロードの管理要求とサポート要求に影響を与える可能性があるため、所有権と連絡先の変更をワークロード チームに伝えます。

プラットフォームに影響するワークロードの変更

次の例は、プラットフォーム チームに伝える必要がある、このアーキテクチャでのワークロードの変更です。 プラットフォーム チームが、新しいワークロード チームの変更に対してプラットフォーム サービスの信頼性、セキュリティ、運用、およびパフォーマンスのターゲットを検証してから有効にすることが重要です。

• ネットワーク エグレス: ネットワーク エグレスの大幅な増加を監視して、ネットワーク デバイスでワークロードがノイズの多いネイバーにならないようにします。 この問題は、他のワークロードのパフォーマンスまたは信頼性のターゲットに影響する可能性があります。

• パブリック アクセス: ワークロード コンポーネントへのパブリック アクセスの変更には、さらにテストが必要になる場合があります。 プラットフォーム チームは、ワークロードを別の管理グループに再配置する場合があります。

• ビジネスの重要度評価: ワークロードのサービス レベル アグリーメント (SLA) に変更がある場合は、プラットフォームチームとワークロード チームの間で新しいコラボレーション アプローチが必要になる場合があります。

• 所有権の変更: 所有権と連絡先の変更をプラットフォーム チームに伝えます。

ワークロードビジネス要件の変更

ワークロードのサービス レベル目標 (SLO) を維持するには、プラットフォーム チームがワークロード アーキテクチャの変更に関与する必要がある場合があります。 これらの変更には、プラットフォーム チームからの変更管理や、既存のガバナンスが変更された要件をサポートしていることを検証することが必要な場合があります。

たとえば、プラットフォーム チームがファイアウォール、Virtual Network Manager、またはその他のコンポーネントにそのフローを追加して必要なトラフィックをサポートできるように、以前に禁止されていたエグレス フローに変更を伝達します。 逆に、以前に許可されたエグレス フローが不要になった場合、プラットフォーム チームは、ワークロードのセキュリティを維持するために、そのフローをブロックする必要があります。 また、他の仮想ネットワークまたはクロスプレミス エンドポイントへのルーティングの変更、またはアーキテクチャ コンポーネントへの変更も伝達します。 各リソースは、ポリシーとエグレス ファイアウォール制御の対象となる可能性があります。

考慮 事項

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、Microsoft Azure Well-Architected Framework のに関するページを参照してください。

確実

信頼性により、アプリケーションは顧客に対するコミットメントを確実に満たすことができます。 詳細については、「信頼性 設計レビューチェックリスト」を参照してください。

このアーキテクチャは、ベースライン アーキテクチャのにおける信頼性の保証と一致します。

信頼性のターゲット

エグレス ネットワーク制御などのコンポーネントが原因で、可能な最大複合 SLO がベースライン複合 SLO よりも 低くなります。 ランディング ゾーン環境で一般的なこれらのコンポーネントは、このアーキテクチャに固有ではありません。 ワークロード チームがこれらの Azure サービスを直接制御する場合、SLO も同様に削減されます。

可能な限り低い最大 SLO にもかかわらず、重要な信頼性の側面は、機能チーム間でのワークロード コンポーネントの分割です。 この方法により、ワークロード チームは、このワークロードやその他のワークロードで使用される重要なインフラストラクチャの運用に重点を置いた専門チームのメリットを得ることができます。

詳細については、「信頼性ターゲットを定義するための推奨事項」を参照してください。

重要な依存関係

ワークロードがプラットフォームとアプリケーションランディングゾーンで実行するすべての機能を依存関係として表示します。 インシデント対応計画では、ワークロード チームがこれらの依存関係の連絡先情報のポイントと方法を認識している必要があります。 また、これらの依存関係をワークロードの障害モード分析 (FMA) に含めます。

このアーキテクチャでは、次の依存関係を考慮してください。

• エグレス ファイアウォール: 複数のワークロードによって共有される一元化されたエグレス ファイアウォールは、ワークロードとは無関係に変更されます。

• ネットワーク ポートの枯渇: ネットワーク デバイスを共有するすべてのワークロードからの使用量が急増すると、エグレス ファイアウォールでネットワークの飽和またはポート不足が発生する可能性があります。

• DINE ポリシー: Azure DNS プライベート DNS ゾーン (またはその他のプラットフォームが提供する依存関係) の DINE ポリシーは、実行に SLA なしでベスト エフォート 。 DNS 構成の遅延により、アプリケーションがトラフィックを処理する準備が遅れる可能性があります。

• 管理グループ ポリシー: 環境間で一貫したポリシーが信頼性の鍵となります。 実稼働前環境が運用環境と類似していることを確認して、正確なテストを提供し、デプロイまたはスケールをブロックできる環境固有の逸脱を防ぎます。 詳細については、「Azure ランディング ゾーンでのアプリケーション開発環境の管理」を参照してください。

これらの考慮事項の多くは Azure ランディング ゾーンがない場合がありますが、ワークロードチームとプラットフォーム チームは、ニーズが満たされるように、これらの問題に共同で対処する必要があります。

詳細については、「エラー モードの分析を実行するための推奨事項」を参照してください。

安全

セキュリティは、意図的な攻撃や貴重なデータとシステムの悪用に対する保証を提供します。 詳細については、「セキュリティ 設計レビューチェックリスト」を参照してください。

このアーキテクチャのセキュリティに関する考慮事項は、ベースライン アーキテクチャから引き継がれた値です。 次のセクションの推奨事項は、Well-Architected Framework のセキュリティ設計レビュー チェックリストに基づいています。

ネットワークコントロール

ワークロードがセキュリティで保護されるようにネットワーク制御を適切に構成します。

イングレス トラフィック

サブネット上の NSG またはリージョン ハブの非推移的な性質または制御を使用して、組織内の他のワークロード スポークからワークロードを分離できます。 アプリケーションとそのインフラストラクチャの受信ネットワーク要件のみを許可する包括的な NSG を構築します。 セキュリティのために、ハブ ネットワークの非推移的な性質だけに依存しないことをお勧めします。

プラットフォーム チームは、Azure ポリシーを実装して、Application Gateway で Web アプリケーション ファイアウォールが拒否モード に設定されていることを確認し、サブスクリプションで使用できるパブリック IP の数やその他のチェックを制限します。 これらのポリシーに加えて、ワークロード チームは、イングレス セキュリティ体制を強化するワークロード中心のポリシーをデプロイする責任を負う必要があります。

次の表に、このアーキテクチャのイングレス コントロールの例を示します。

源	目的	ワークロード制御	プラットフォーム制御
インターネット	ユーザー トラフィック フロー	パブリック トラフィックがフロントエンド VM に入るプライベート トラフィックへの移行を許可する前に、NSG、Web アプリケーション ファイアウォール、およびルーティング規則を介してすべての要求をファネルします	何一つ
Azure Bastion	VM へのオペレーター アクセス	プラットフォームの指定された Azure Bastion サブネットからソース化されていない限り、リモート アクセス ポートへのすべてのトラフィックをブロックする VM サブネット上の NSG	何一つ
その他のスポーク	何一つ	NSG ルールを使用してブロックする	Azure Virtual WAN セキュリティで保護されたハブの場合の非トランザクション ルーティングまたは Azure Firewall 規則

エグレス トラフィック

ソリューションの必要な送信接続要件を表す NSG ルールを適用し、それ以外のすべてを拒否します。 ハブ ネットワークコントロールだけに依存しないでください。 ワークロード オペレーターは、望ましくないエグレス トラフィックを、実行可能なソースの近くで停止する必要があります。

仮想ネットワーク内でサブネットを所有している間、プラットフォーム チームは、キャプチャした要件をサブスクリプションの自動販売機プロセスの一部として具体的に表すファイアウォール規則を作成した可能性があることに注意してください。 アーキテクチャの有効期間中のサブネットとリソース配置の変更が、元の要求と互換性があることを確認します。 または、ネットワーク チームと協力して、最小アクセスエグレス制御の継続性を確保することもできます。

次の表に、このアーキテクチャのエグレスの例を示します。

エンドポイント	目的	ワークロード (NSG) コントロール	プラットフォーム (ハブ) コントロール
ntp.ubuntu.com	Linux VM のネットワーク タイム プロトコル (NTP)	UDP/123 をフロントエンド VM サブネット上のインターネットに します (エグレス ファイアウォールによって、この広範な開放が狭くなります)	ワークロード制御と同じファイアウォール ネットワーク規則の許容量
Windows Update エンドポイント	Microsoft サーバーからの Windows Update 機能	TCP/443 を し、バックエンド VM サブネット上のインターネットに TCP/80 を します (エグレス ファイアウォールによって、この広範な開放が狭くなります)	FQDN タグが WindowsUpdate のファイアウォール許容規則
エージェント エンドポイントの監視	VM 上の Monitor 拡張機能に必要なトラフィック	TCP/443 を両方の VM サブネット上のインターネットに します (エグレス ファイアウォールはこの広範な開放を狭めます)	TCP/443 上のすべての特定の FQDN に必要なファイアウォール アプリケーション規則の許容量
nginx.org	ベンダーから直接 Nginx (アプリケーション コンポーネントの例) をインストールするには	TCP/443 をフロントエンド VM サブネット上のインターネットに します (エグレス ファイアウォールによって、この広範な開放が狭くなります)	TCP/443 での nginx.org に必要なファイアウォール アプリケーション規則の許容量
Key Vault (キー・ボールト)	Application Gateway と VM に TLS 証明書をインポート (トランスポート層セキュリティ) するには	TCP/443を両方の VM サブネットからプライベート エンドポイント サブネットに - する Application Gateway サブネットからプライベート エンドポイント サブネットに TCP/443を - する 必要なアプリケーション セキュリティ グループ (ASG) の指定と Application Gateway サブネットでタグ付けされた VM から TCP/443を - する	何一つ

DDoS攻撃からの保護

ソリューションのすべてのパブリック IP を対象とする DDoS Protection プランの適用を担当するユーザーを決定します。 プラットフォーム チームは、IP 保護プランを使用することも、Azure Policy を使用して仮想ネットワーク保護プランを適用することもできます。 このアーキテクチャには、インターネットからのイングレス用のパブリック IP が含まれるため、カバレッジが必要です。

詳細については、「ネットワークと接続のに関する推奨事項」を参照してください。

シークレット管理

シークレット管理の場合、このアーキテクチャは ベースライン アーキテクチャのに従います。

ワークロード チームとして、Key Vault インスタンスにシークレットを保持し続けます。 アプリケーションとインフラストラクチャの操作をサポートするために、必要に応じてさらにインスタンスをデプロイします。

詳細については、「アプリケーション シークレットを保護するための推奨事項」を参照してください。

コストの最適化

コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コストの最適化 設計レビューチェックリスト」を参照してください。

ワークロード リソースの場合、ベースライン アーキテクチャのコスト最適化戦略 このアーキテクチャにも適用されます。

このアーキテクチャは、Azure ランディング ゾーン プラットフォーム リソースから大きなメリットを得られます。 チャージバック モデルを使用してこれらのリソースを使用する場合でも、追加されたセキュリティとクロスプレミス接続は、それらのリソースを自己管理するよりもコスト効率が高くなります。

プラットフォーム チームは、このアーキテクチャで次のリソースを管理します。 多くの場合、これらのリソースは使用量ベース (チャージバック) であるか、ワークロード チームに無料である可能性があります。

• Azure Firewall
• セキュリティ情報とイベント管理 (SIEM)
• Azure Bastion ホスト
• ExpressRoute などのクロスプレミス接続

プラットフォーム チームの他の一元化されたオファリングを活用して、SLO、目標復旧時間 (RTO)、または目標復旧ポイント (RPO) を損なうことなく、それらの利点をワークロードに拡張します。

詳細については、「コスト データの収集と確認に関する推奨事項」を参照してください。

このシナリオをデプロイする

この参照アーキテクチャのデプロイは、GitHub で入手できます。

実装: Azure ランディング ゾーン での VM ベースライン アーキテクチャ

次の手順

ワークロード チームとプラットフォーム チームの間で共有されているコラボレーションと技術的な詳細を確認します。

サブスクリプションの自動販売機