単一リージョン シナリオ - Azure Virtual WAN での Private Link と DNS

Azure Private Link
Azure DNS
Azure Firewall
Azure Virtual WAN

この記事では、プライベート エンドポイント経由で PaaS リソースを単一リージョン内の特定のワークロードに公開する方法について説明します。 このシナリオでは、ネットワーク トポロジはハブスポークであり、ハブは Azure Virtual WAN ハブです。

重要

この記事は、Virtual WAN での Azure Private Link と Azure DNS に関するシリーズの一部であり、シナリオ ガイドで定義されているネットワーク トポロジに基づいています。 ベース ネットワーク アーキテクチャと主な課題については、最初に概要ページをご覧ください。

シナリオ

単一リージョン アーキテクチャを示す図。

図 1: Private Link と Azure DNS を使用した Virtual WAN の単一リージョン シナリオ - 課題

このアーキテクチャの Visio ファイルをダウンロードします。 このセクションでは、シナリオを定義し、このシナリオの課題を再定義します (課題は、概要ページの機能しない例と同じです)。 最初のシナリオ アーキテクチャは、概要ガイドで定義されている開始ネットワーク トポロジに基づいています。 追加した点と変更した点は次のとおりです。

  • 1 つの仮想ハブを持つリージョンは 1 つだけあります。
  • パブリック ネットワーク アクセスが無効になっている Azure Storage アカウントが、リージョン内にあります。 このシナリオでは、1 つのワークロードのみがストレージ アカウントにアクセスすることを前提としています。
  • 最初は、仮想ハブに接続された単一仮想ネットワークがあります。
  • 仮想ネットワークには、仮想マシン (VM) クライアントを含んだワークロード サブネットがあります。
  • 仮想ネットワークには、ストレージ アカウントのプライベート エンドポイントを含んだプライベート エンドポイント サブネットが含まれます。

成功した結果

Azure Virtual Machine クライアントは、同じ仮想ネットワーク内にあるストレージ アカウントのプライベート エンドポイントを介して Azure Storage アカウントに接続でき、その他のストレージ アカウントへのアクセスはすべてブロックされます。

障害

ストレージ アカウントの完全修飾ドメイン名 (FQDN) を、プライベート エンドポイントのプライベート IP アドレスに解決できる DNS レコードが DNS フロー内に必要です。 概要で示されているように、シナリオに関する課題には次の 2 つの部分があります。

  1. ストレージ アカウントに必要な DNS レコードを保持するプライベート DNS ゾーンを、仮想ハブにリンクすることができません。
  2. プライベート DNS ゾーンをワークロード ネットワークにリンクできるので、機能すると思うかもしれません。 残念ながら、接続されている各仮想ネットワークで、Azure Firewall DNS プロキシを使用するように DNS サーバーが構成されていることが、ベースライン アーキテクチャで規定されています。

プライベート DNS ゾーンを仮想ハブにリンクすることはできず、Azure Firewall DNS プロキシを使用するように仮想ネットワークが構成されているため、Azure DNS サーバーには、ストレージ アカウントの (FQDN) をプライベート エンドポイントのプライベート IP アドレスに解決するメカニズムはありません。 そのため、クライアントが誤った DNS 応答を受け取る結果になります。

DNS フローと HTTP フロー

このワークロードについて、DNS と結果の HTTP 要求フローを確認しましょう。 このレビューは、前に説明した懸案事項の視覚化に役立ちます。

単一リージョンの課題を示す図。

図 2: Private Link と Azure DNS を使用した Virtual WAN の単一リージョン シナリオ - 課題

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

DNS フロー

  1. クライアントからの stgworkload00.blob.core.windows.net に関する DNS クエリは、ピアリングされたリージョン ハブ内の Azure Firewall である構成済みの DNS サーバーに送信されます。
  2. 要求は Azure Firewall によって Azure DNS にプロキシされます。 プライベート DNS ゾーンを仮想ハブにリンクすることはできないので、FQDN をプライベート エンドポイントのプライベート IP アドレスに解決する方法が Azure DNS にはわかりません。 FQDN をストレージ アカウントのパブリック IP アドレスに解決する方法はわかっているので、ストレージ アカウントのパブリック IP アドレスが返されます。

HTTP フロー

  1. DNS の結果、ストレージ アカウントのパブリック IP アドレスが得られるので、クライアントは stgworkload00.blob.core.windows.net に対して HTTP 要求を発行します。
  2. 要求はストレージ アカウントのパブリック IP アドレスに送信されます。 この要求は、さまざまな理由で失敗します。
    • ワークロード サブネット上の NSG で、このインターネットへのトラフィックが許可されない場合があります。
    • インターネットへのエグレス トラフィックをフィルター処理している Azure Firewall には、このフローをサポートするアプリケーション ルールがない可能性があります。
    • NSG と Azure Firewall の両方にこの要求フローに対する許容量がある場合でも、ストレージ アカウントはすべてのパブリック ネットワーク アクセスをブロックするように構成されます。 この試みは最終的には、プライベート エンドポイント経由でストレージ アカウントへのアクセスのみを許可するというここでの目標に違反します。

ソリューション - DNS の仮想ハブ拡張機能を確立する

課題のソリューションは、エンタープライズ ネットワーク チームが DNS 用の仮想ハブ拡張機能を実装するというものです。 DNS 仮想ハブ拡張機能の単一責任は、この開始 Virtual WAN ハブ トポロジ内のアーキテクチャでプライベート DNS ゾーンを使用する必要があるワークロード チームを有効にすることです。

DNS 拡張機能は、リージョン仮想ハブとピアリングされた仮想ネットワーク スポークとして実装されます。 プライベート DNS ゾーンをこの仮想ネットワークにリンクさせることができます。 仮想ネットワークには、この仮想ネットワーク外のサービス (Azure Firewall など) が、リンクされているすべてのプライベート DNS ゾーンの値に対してクエリを実行して受信できるようにする Azure DNS Private Resolver も含まれています。 DNS の一般的な仮想ハブ拡張機能のコンポーネントと、必要な構成変更を次に示します。

  • リージョンの仮想ハブとピアリングされる新しいスポーク仮想ネットワーク。 このスポークは他のスポークと同様に構成されます。つまり、既定の DNS サーバーとルーティング規則により、リージョン ハブで Azure Firewall が強制的に使用されます。
  • DNS Private Resolver リソースは、スポーク仮想ネットワーク内の受信エンドポイントと共にデプロイされます。
  • privatelink.blob.core.windows.net という名前のプライベート DNS ゾーン リソースが作成されます。
    • このゾーンには、ストレージ アカウントの FQDN 名からストレージ アカウントのプライベート エンドポイントのプライベート IP アドレスにマップされる A レコードが含まれます。
    • プライベート DNS ゾーンは、スポーク仮想ネットワークにリンクされます。
    • ロールベースのアクセス制御 (RBAC) で許可されている場合は、自動登録またはサービスマネージド エントリを使用して、これらの DNS レコードを維持できます。 そうでない場合は、手動で維持できます。
  • リージョン ハブでは、DNS Private Resolver の受信エンドポイントを指すように、Azure Firewall の DNS サーバーが変更されます。

次の図には、このアーキテクチャを、DNS フローおよび HTTP フローの両方と共に示しています。

DNS の仮想ハブ拡張機能を使用した実際のソリューションを示した図。

図 3: Private Link と DNS を使用した Virtual WAN の単一リージョン シナリオの実際のソリューション

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

DNS の仮想ハブ拡張機能を確立するための DNS フロー

  1. クライアントからの stgworkload00.blob.core.windows.net に関する DNS クエリは、ピアリングされたリージョン ハブ内の Azure Firewall である構成済みの DNS サーバー (この場合は 10.100.0.132) に送信されます。

    DNS サーバーが、追加されたハブをセキュリティ保護する Azure Firewall のカスタムおよびプライベート IP アドレスに設定されていることを示す、ワークロード仮想ネットワークのスクリーンショット。図 4: ワークロード仮想ネットワークの DNS サーバー構成

  2. Azure Firewall により、ハブ拡張機能のリージョンの Azure DNS Private Resolver (この場合は 10.200.1.4。これは、DNS Private Resolver の受信エンドポイントのプライベート IP アドレス) に要求がプロキシされます。

    DNS プロキシが有効で、DNS サーバーが設定されている Azure Firewall ポリシーのスクリーンショット。

    図 5: Azure Firewall ポリシーでの DNS 構成

  3. DNS Private Resolver は、要求を Azure DNS にプロキシします。 プライベート DNS ゾーンは受信エンドポイントを含む仮想ネットワークにリンクされているため、Azure DNS では、これらのリンクされたプライベート DNS ゾーンでレコードを使用できます。

    DNS 拡張機能仮想ネットワークへのリンクを示す、プライベート DNS ゾーンの仮想ネットワーク リンクのスクリーンショット。図 6: プライベート DNS ゾーンの仮想ネットワークリンク

  4. Azure DNS では、リンクされたプライベート DNS ゾーンを調べ、stgworkload00.blob.core.windows.net の FQDN を 10.1.2.4 (ストレージ アカウントのプライベート エンドポイントの IP アドレス) に解決します。 この応答は Azure Firewall DNS に提供され、そこからストレージ アカウントのプライベート IP アドレスがクライアントに返されます。

    名前が stgworkload00 で、値が 10.1.2.4 である A レコードを伴うプライベート DNS ゾーンのスクリーンショット。図 7: ストレージ アカウント プライベート エンドポイントの A レコードを伴うプライベート DNS ゾーン

HTTP フロー

  1. DNS の結果、ストレージ アカウントのプライベート IP アドレスが得られるので、クライアントは stgworkload00.blob.core.windows.net に対して HTTP 要求を発行します。
  2. 要求はストレージ アカウントのプライベート IP アドレス (10.1.2.4) に送信されます。 クライアント サブネットまたはプライベート エンドポイント サブネット上のローカル ネットワーク セキュリティ グループに対して競合する制限がない場合、この要求は正常にルーティングされます。 プライベート エンドポイントがクライアントと同じ仮想ネットワーク内にあるため、Azure Firewall でプライベート トラフィックがセキュリティ保護されていたとしても、要求はルーティングされないという点を理解しておくことが重要です。 つまり、Azure Firewall でこのシナリオを考慮する必要はありません。
  3. ストレージ アカウントへのプライベート接続が、Private Link サービスを介して確立されます。 ストレージ アカウントではプライベート ネットワーク アクセスのみが許可され、HTTP 要求が受け入れられます。

DNS 用の仮想ハブ拡張機能に関する考慮事項

企業向けの拡張機能を実装する場合は、次のガイダンスを考慮してください。

  • DNS 拡張機能のデプロイは、ワークロード チームのタスクではありません。 このタスクはエンタープライズ ネットワーク機能であり、これらの個人と一緒に実装を決定する必要があります。
  • プライベート エンドポイント DNS レコードを構成する PaaS サービスを追加する前に、DNS 拡張機能とプライベート DNS ゾーンが存在している必要があります。
  • 仮想ハブ拡張機能はリージョン リソースであり、リージョン間トラフィックを回避し、プライベート エンドポイントの DNS 解決が必要なリージョン ハブごとにハブ拡張機能を確立します。

スポーク仮想ネットワーク

  • 単一責任の原則に従って、DNS 拡張機能の仮想ネットワークには、DNS 解決に必要なリソースのみを含める必要があります。このネットワークを他のリソースと共有しないでください。
  • DNS 拡張機能の仮想ネットワークは、「スポーク ネットワークの追加」の同じ構成ガイドラインに従う必要があります。

Azure DNS Private Resolver

  • 各リージョンには、1 つの DNS Private Resolver を含む 1 つの仮想ハブ DNS 拡張機能が必要です。

  • このシナリオでは、DNS Private Resolver には受信エンドポイントのみが必要であり、送信エンドポイントは必要ありません。 受信エンドポイントのプライベート IP は、Azure Firewall ポリシーのカスタム DNS サービスに設定されているものです (図 5 を参照)。

  • 回復性を高め負荷処理を増強するために、プロキシによる解決のために Azure DNS プロキシを複数の IP アドレスで構成して、リージョンごとに複数の DNS Private Resolver インスタンスをデプロイすることができます。

    1 つのエンドポイントを示す、DNS Private Resolver の受信エンドポイントのスクリーンショット。図 8: DNS Private Resolver の受信エンドポイント

  • DNS Private Resolver の仮想ネットワーク制限に従ってください。

  • DNS Private Resolver の受信エンドポイントのサブネット内のネットワーク セキュリティ グループでは、リージョン ハブからポート 53 への UDP トラフィックのみが許可される必要があります。 他の受信トラフィックと送信トラフィックをすべてブロックする必要があります。

プライベート DNS ゾーン

Azure DNS Private Resolver では Azure DNS を介して DNS を解決しているため、受信サブネットの仮想ネットワークにリンクされているプライベート DNS ゾーンはすべて Azure DNS で取得できます。

シナリオに関する考慮事項

適切に管理された仮想ハブの DNS 拡張機能が用意できたので、ワークロードに戻って、このシナリオでの成功した結果の目標の実現に役立つ追加ポイントに対処しましょう。

ストレージ アカウント

  • [ネットワーク接続] の下で [パブリック ネットワーク アクセス] を [無効] に設定して、ストレージ アカウントにプライベート エンドポイント経由でのみアクセスできるようにします。
  • ワークロードの仮想ネットワーク内の専用プライベート エンドポイント サブネットにプライベート エンドポイントを追加します。
  • ワークロード Log Analytics ワークスペースに Azure Diagnostics を送信します。 アクセス ログを使用して、構成問題のトラブルシューティングに役立てることができます。

プライベート エンドポイント セキュリティ

このソリューションの要件は、このストレージ アカウントの公開を制限することです。 PaaS リソースへのパブリック インターネット アクセスを削除したら、プライベート ネットワークのセキュリティに対処する必要があります。

Azure Firewall では、Virtual WAN ハブスポーク トポロジでプライベート トラフィックをセキュリティで保護している場合、既定でスポーク間接続を拒否します。 この既定の設定により、他のスポーク ネットワークのワークロードが、ワークロード仮想ネットワーク内のプライベート エンドポイント (および他のリソース) にアクセスできなくなります。 完全に仮想ネットワーク内にあるトラフィックは、Azure Firewall 経由でルーティングされません。 仮想ネットワーク内のアクセスを制御し、より詳細な保護を追加するには、次のネットワーク セキュリティ グループ (NSG) の推奨事項を検討してください。

  • アプリケーション セキュリティ グループ (ASG) を作成して、受信または送信アクセスのニーズが似ているリソースをグループ化します。 このシナリオでは、ストレージにアクセスする必要があるクライアント VM に 1 つの ASG を、アクセスされるストレージ アカウントに 1 つの ASG を使用します。 「プライベート エンドポイントを使用してアプリケーション セキュリティ グループ (ASG) を構成する」を参照してください。
  • ワークロード VM を含むサブネットに NSG があることを確認します。
  • プライベート エンドポイントを含むサブネットに NSG があることを確認します。

ワークロード VM を含むサブネットの NSG ルール

ワークロードで必要になるその他のネットワーク ルールに加えて、次のルールを構成します。

  • 送信ルール:
    • コンピューティング ASG によるストレージ アカウント ASG へのアクセスを許可します。
    • ポート 53 で UDP 用のリージョン ハブ Azure Firewall のプライベート IP へのアクセスをコンピューティング ASG に許可します。

ワークロード サブネットの NSG ルールを示すスクリーンショット。*図 9: ワークロード サブネットの NSG ルール

プライベート エンドポイントを含むサブネットの NSG ルール

使用している仮想ネットワーク内の小規模な専用サブネットでプライベート エンドポイントを公開することをお勧めします。 その理由の 1 つは、トラフィック制御とセキュリティを強化するために、ユーザー定義のルートと、ネットワーク セキュリティ グループのプライベート エンドポイント用ネットワーク ポリシーを適用できるということにあります。

このシナリオでは、非常に制限の厳しいネットワーク セキュリティ グループを適用できます。

  • 受信ルール:
    • コンピューティング ASG によるストレージ アカウント ASG へのアクセスを許可する
    • その他のすべてのトラフィックを拒否する
  • 送信ルール:
    • すべてのトラフィックを拒否する

プライベート エンドポイント サブネットの NSG ルールを示すスクリーンショット。*図 10: プライベート エンドポイント サブネットの NSG ルール

動作中のプライベート エンドポイント セキュリティ

次の図は、概説された考慮事項に従って多層防御セキュリティを実現する方法を示しています。 この図は、2 つ目の VM を持つ 2 つ目のスポーク仮想ネットワークを示しています。 そのワークロードはプライベート エンドポイントにアクセスできません。

プライベート エンドポイントにアクセスできない、2 つ目のスポーク仮想ネットワークにおけるワークロードを示す図。

図 11: Private Link と DNS を使用した Virtual WAN の単一リージョン シナリオの実際のソリューション

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

DNS フロー

DNS フローは、ソリューション フローとまったく同じです。

強調すべき重要な点は、FQDN がパブリック IP アドレスではなくプライベート IP アドレスに解決されるということです。 この解決は、すべてのスポークが常にこのサービスのプライベート IP アドレスを受信することを意味します。 別のシナリオでは、このアプローチを使用して、複数の使用ワークロードにわたって PaaS サービスを共有する方法について説明しています。 この単一ワークロード シナリオでは、これは問題ではありません。

HTTP フロー

  1. DNS の結果、ストレージ アカウントのプライベート IP アドレスが得られるので、クライアントは stgworkload00.blob.core.windows.net に対して HTTP 要求を発行します。
  2. 要求はストレージ アカウントのプライベート IP アドレスに送信されます。 この要求は、さまざまな理由で適切に失敗します。
    • Azure Firewall はプライベート トラフィックをセキュリティで保護するように構成されているため、要求は Azure Firewall により処理されます。 Azure Firewall で、フローを許可するネットワークまたはアプリケーション ルールが設定されていない限り、Azure Firewall は要求をブロックします。
    • プライベート トラフィックをセキュリティで保護するために、ハブで Azure Firewall を使用する必要はありません。 たとえば、ネットワークでプライベートなリージョン間トラフィックがサポートされている場合でも、プライベート エンドポイント サブネット上の NSG は、ワークロードをホストする仮想ネットワーク内のコンピューティング ASG ソース以外のすべてのトラフィックをブロックするように構成されています。

まとめ

この記事では、VM クライアントが Azure Storage アカウントに、そのストレージ アカウントのプライベート エンドポイントを介して接続するシナリオについて説明します。 エンドポイントは、クライアントと同じ仮想ネットワーク内にあります。 ストレージ アカウントへのその他のアクセスはすべてブロックされます。 このシナリオでは、ストレージ アカウントの完全修飾ドメイン名 (FQDN) を、プライベート エンドポイントのプライベート IP アドレスに解決できる DNS レコードが DNS フロー内に必要です。

このシナリオの開始ネットワーク トポロジでは、次の 2 つの課題が導入されます。

  • ストレージ アカウントに必要な DNS レコードを伴うプライベート DNS ゾーンを仮想ハブにリンクすることはできません。
  • ワークロード サブネットへのプライベート DNS ゾーンのリンクは機能しません。 開始ネットワーク トポロジでは、既定の DNS サーバーとルーティング規則によって、リージョン ハブで Azure Firewall が強制的に使用される必要があります。

提案されるソリューションは、エンタープライズ ネットワーク チームが DNS 用の仮想ハブ拡張機能を実装することです。 この拡張機能を使用すると、エンタープライズ ネットワーク チームは、共有 DNS サービスを、それらを必要とするワークロード スポークに公開できます。