次の方法で共有


Azure ベースのネットワーク通信のセグメント化にゼロ トラストの原則を適用する

この記事では、Azure 環境でのネットワークのセグメント化に対するゼロ トラスト原則の適用に関するガイダンスを提供します。 ゼロ トラストの原則を次に示します。

ゼロ トラストの標準 Definition
明示的に検証する 常に利用可能なすべてのデータポイントに基づいて認証および承認してください。
最小限の特権アクセスを使用する ジャスト・イン・タイムおよびジャスト・エナフ・アクセス(JIT/JEA)、リスクベースのアダプティブ・ポリシー、データ保護により、ユーザー・アクセスを制限します。
侵害を前提とする 影響範囲を最小限に抑えるために、アクセスをセグメント化します。 エンドツーエンドの暗号化を検証し、分析を使用して可視性を得て、脅威検出を促進し、防御を強化します。

Azure インフラストラクチャのさまざまなレベルでネットワークのセグメント化を実行することで、サイバー攻撃の影響範囲を最小限に抑え、アクセスをセグメント化できます。

この記事は、Azure ネットワークにゼロ トラストの原則を適用する方法を示す一連の記事の一部です。

組織が小規模企業から大企業に成長するにつれて、多くの場合、1 つの Azure サブスクリプションから複数のサブスクリプションに移行して、部門ごとにリソースを分離する必要があります。 ネットワークのセグメント化を慎重に計画して、環境間の論理的な境界と分離を作成することが重要です。

各環境は、通常、組織の個別の部門を反映しており、特定のワークロードに対する独自のアクセス許可とポリシーを持っている必要があります。 たとえば、内部ソフトウェア開発者サブスクリプションのユーザーは、接続サブスクリプション内のネットワーク リソースの管理とデプロイにアクセスできないようにする必要があります。 ただし、これらの環境では、DNS、ハイブリッド接続などの基本的なサービスに必要な機能を実現し、異なる Azure 仮想ネットワーク (VNet) 経由で他のリソースにアクセスできるようにするために、ネットワーク接続が必要です。

Azure インフラストラクチャのセグメント化により、分離が提供されるだけでなく、攻撃者が環境間を移動して追加の損害を与えるのを防ぐセキュリティ境界を作成することもできます (侵害を想定するというゼロ トラスト原則)。

リファレンス アーキテクチャ

Azure のさまざまなレベルのセグメント化を使用して、承認されていないアクセスや悪意のある攻撃からリソースを保護できます。 これらのレベルのセグメント化は、サブスクリプション レベルから始まり、仮想マシンで実行されているアプリケーションに至ります。 セグメント化により、ある環境を別の環境から分離する境界が作成され、それぞれに独自のルールとポリシーが設定されます。 侵害が発生する可能性があることを前提として、ネットワークをセグメント化して拡散を防ぐ必要があります。

Azure ネットワークでは、次のレベルのセグメント化が使用されます。

  • サブスクリプション

    Azure サブスクリプションは、Azure でリソースをプロビジョニングするために使用される論理コンテナーです。 Microsoft Entra ID テナント内の Azure アカウントにリンクされ、サブスクリプションに割り当てられている Azure リソースの単一の課金単位として機能します。 Azure サブスクリプションは、サブスクリプションに含まれるリソースにアクセスするための論理境界でもあります。 異なるサブスクリプション内のリソース間のアクセスには、明示的なアクセス許可が必要です。

  • VNet

    Azure VNet は分離されたプライベート ネットワークであり、既定では、その中のすべての仮想マシンが相互に通信できます。 既定では、ピアリング、VPN 接続、または ExpressRoute を使用した接続を作成しない限り、VNet と他の VNet の通信はできません。 個々の VNet は、さまざまなアプリケーション、ワークロード、部門、または組織を分割する信頼境界として使用できます。

    Azure Virtual Network Manager (AVNM) は、1 つの管理チームによって VNet を管理し、複数のサブスクリプションにわたってセキュリティ規則をグローバルに適用できるネットワーク管理サービスです。 AVNM を使用してネットワーク グループを定義し、相互に通信できる VNet を決定できます。 AVNM を使用して、ネットワーク構成の変更を監視することもできます。

  • VNet 内のワークロード

    VNet 内のワークロード (たとえば仮想マシンや、Azure Databricks や App Service などの VNet 統合をサポートする PaaS サービスなど) の場合、それらは同じ VNet 内に含まれているため、通信は既定で許可され、ネットワーク セキュリティ グループを使用してセキュリティ保護を強化する必要があります。 VNet 内のセグメント化のためのツールとサービスには、次のものが含まれます。

    • Azure Firewall

      Azure Firewall は、クラウド リソース、オンプレミス、インターネットの間のトラフィックをフィルター処理するために VNet にデプロイされたサービスです。 Azure Firewall では、ネットワーク層とアプリケーション層でトラフィックを許可または拒否するルールとポリシーを定義できます。 また、侵入検出および防止システム (IDPS)、トランスポート層セキュリティ (TLS) 検査、脅威インテリジェンスベースのフィルター処理など、Azure Firewall によって提供される高度な、脅威に対する保護の機能を利用することもできます。

    • ネットワーク セキュリティ グループ

      ネットワーク セキュリティ グループは、VNet 内の仮想マシンなどの Azure リソース間のネットワーク トラフィックをフィルター処理するアクセス制御メカニズムです。 ネットワーク セキュリティ グループには、VNet 内のサブネットまたは仮想マシンのレベルでトラフィックを許可または拒否するセキュリティ規則が含まれています。 ネットワーク セキュリティ グループの一般的な用途は、異なるサブネット内の仮想マシンのセットをセグメント化することです。

    • アプリケーション セキュリティ グループ

      アプリケーション セキュリティ グループは、仮想マシンの役割と機能に基づいて仮想マシンのネットワーク インターフェイスをグループ化できる、ネットワーク セキュリティ グループの拡張機能です。 これにより、仮想マシンの IP アドレスを定義しなくても、ネットワーク セキュリティ グループ内のアプリケーション セキュリティ グループを大規模に使用できるようになります。

    • Azure Front Door

      Azure Front Door は、Microsoft の最新のクラウド コンテンツ配信ネットワーク (CDN) であり、世界中のユーザーとアプリケーションの静的および動的 Web コンテンツの間で、高速で信頼性が高く、セキュリティで保護されたアクセスを提供します。

次の図は、セグメント化のレベルの参照アーキテクチャを示しています。

Azure ネットワークの参照アーキテクチャとセグメント化のレベルを示す図。

この図で、赤色の実線は以下の間でのセグメント化のレベルを示しています。

  1. Azure サブスクリプション
  2. サブスクリプション内の VNet
  3. VNet 内のサブネット
  4. インターネットと VNet

この図には、複数の Azure サブスクリプションにまたがる AVNM によって管理される VNet のセットも示されています。

この記事の内容は?

ゼロ トラスト原則は、Azure クラウド内の参照アーキテクチャ全体に適用されます。 次の表では、侵害を想定するというゼロ トラスト原則に準拠するための、このアーキテクチャ全体でのネットワークのセグメント化に関する推奨事項について説明します。

ステップ タスク
1 個々の VNet 内でセグメント化する。
2 ピアリングを使用して複数の VNet を接続する。
3 ハブ アンド スポークの構成で複数の VNet を接続する。

手順 1: 個々の VNet 内でセグメント化する

Azure サブスクリプション内の 1 つの VNet 内では、サブネットを使用してリソースの分離とセグメント化を実現します。 たとえば、VNet 内には、データベース サーバー用のサブネットや Web アプリケーション用のもの、Azure Firewall 用または Web Application Firewall を使用した Azure Application Gateway 用の専用サブネットが存在する場合があります。 既定では、VNet 内でのサブネット間のすべての通信が有効になっています。

サブネット間の分離を作成するには、ネットワーク セキュリティ グループまたはアプリケーション セキュリティ グループを適用して、IP アドレス、ポート、またはプロトコルに基づいて特定のネットワーク トラフィックを許可または拒否することができます。 ただし、ネットワーク セキュリティ グループとアプリケーション セキュリティ グループを設計して管理すると、管理のオーバーヘッドが発生する可能性もあります。

この図は、階層ごとに異なるサブネットがある 3 層アプリケーションの一般的な推奨される構成と、ネットワーク セキュリティ グループとアプリケーション セキュリティ グループを使用して各サブネット間にセグメント化された境界を作成する方法を示しています。

サブネット間のセグメント化にネットワーク セキュリティ グループとアプリケーション セキュリティ グループを使用する方法を示す図。

リソースのセグメント化は、Azure ファイアウォールまたはサードパーティのネットワーク仮想アプライアンス (NVA) を指すユーザー定義ルート (UDR) を使用して、サブネット間トラフィックをルーティングすることでも実現できます。 Azure Firewall と NVA には、レイヤー 3 からレイヤー 7 のコントロールを使用してトラフィックを許可または拒否する機能もあります。 これらのサービスのほとんどに、高度なフィルター機能があります。

詳細については、「パターン 1: 単一の仮想ネットワーク」のガイダンスを参照してください。

手順 2: ピアリングを使用して複数の VNet を接続する

既定では、1 つの Azure サブスクリプションを使用している、または複数のサブスクリプションにまたがる VNet 間の通信は許可されません。 異なるエンティティに属する複数の VNet には、それら独自のアクセス制御があります。 それらは VNet ピアリングを使用して、相互に、または一元化されたハブ VNet に接続することができます。この場合、すべてのトラフィックが Azure ファイアウォールまたはサード パーティの NVA によって検査されます。

この図は、2 つの VNet 間の VNet ピアリング接続と、接続の両端での Azure Firewall の使用を示しています。

VNet ピアリングと、Azure Firewall を使用して 2 つの VNet を接続およびセグメント化する方法を示す図。

ハブ VNet には、通常、ファイアウォール、ID プロバイダー、ハイブリッド接続コンポーネントなどの共有コンポーネントが含まれます。 マイクロセグメント化に特定のプレフィックス UDR を追加する必要があるのは、VNet 内トラフィックが要件である場合のみであるため、UDR 管理が簡単になります。 ただし、VNet には独自の境界があるため、セキュリティ制御は既に実施されています。

詳細については、次のガイダンスを参照してください。

手順 3: ハブ アンド スポークの構成で複数の VNet を接続する

ハブ アンド スポークの構成に複数の VNet がある場合は、これらの境界に対してネットワーク トラフィックをセグメント化する方法を検討する必要があります。

  • インターネット境界
  • オンプレミスのネットワーク境界
  • グローバル Azure サービスに対する境界

インターネット境界

インターネット トラフィックのセキュリティ保護は、ネットワーク セキュリティの基本的な優先事項です。これには、インターネットからのイングレス トラフィック (信頼されていない) と、Azure ワークロードからインターネットに向かうエグレス トラフィック (信頼済み) の管理が含まれます。

Microsoft のお勧めは、インターネットからのイングレス トラフィックには、単一のエントリ ポイントを設定することです。 Microsoft では、イングレス トラフィックが Azure Firewall、Azure Front Door、Azure Application Gateway などの Azure PaaS リソースを通過するようにすることを強くお勧めします。 これらの PaaS リソースは、パブリック IP アドレスを持つ仮想マシンよりも多くの機能を提供します。

Azure Firewall

この図は、独自のサブネット内にある Azure Firewall が、インターネットと Azure VNet 内の 3 層ワークロードとの間で、トラフィックの中央エントリ ポイントおよびセグメント化の境界としてどのように機能するかを示しています。

VNet とインターネットの間でのトラフィックのセグメント化に Azure Firewall を使用する方法を示す図。

詳細については、Microsoft Azure Well-Architected Framework の Azure Firewall に関するページを参照してください。

Azure Front Door

Azure Front Door は、インターネットと、Azure でホストされているサービスとの間の境界として機能できます。 Azure Front Door では、VNet アクセスの内部負荷分散 (ILB)、静的 Web サイトと BLOB ストレージのストレージ アカウント、Azure App Services などのリソースへの Private Link 接続がサポートされています。 Azure Front Door は通常、大規模なデプロイに対して行われます。

Azure Front Door は負荷分散サービス以上のものです。 Azure Front Door インフラストラクチャには DDoS 保護が組み込まれています。 キャッシュが有効になっている場合、常にバックエンド サーバーにアクセスするのではなく、ポイント オブ プレゼンス (POP) の場所からコンテンツを取得できます。 キャッシュの有効期限が切れると、Azure Front Door は要求されたリソースを取得し、キャッシュを更新します。 エンド ユーザーがサーバーにアクセスするのではなく、Azure Front Door では 2 つの個別の接続に分割 TCP が使用されます。 これにより、エンド ユーザー エクスペリエンスが向上するだけでなく、悪意のあるアクターがリソースに直接アクセスするのを防ぐことができます。

この図は、インターネット ユーザーと、ストレージ アカウント内に存在する可能性がある Azure リソースとの間のセグメント化が、Azure Front Door によってどのように提供されるかを示しています。

インターネットと Azure でホストされているサービスとの境界としての Azure Front Door の使用を示す図。

詳細については、Azure Well-Architected Framework の Azure Front Door に関するページを参照してください。

Azure Application Gateway

インターネットのエントリ ポイントは、イングレス ポイントの組み合わせにすることもできます。 たとえば、HTTP/HTTPS トラフィックは、Web アプリケーション ファイアウォールまたは Azure Front Door によって保護されたアプリケーション ゲートウェイ経由で受信できます。 RDP や SSH などの HTTP/HTTPS 以外のトラフィックは、Azure Firewall または NVA 経由で受信できます。 これら 2 つの要素を並行して使用して、より詳細な検査を行い、UDR を使用してトラフィック フローを制御できます。

この図は、インターネットのイングレス トラフィックと、HTTP/HTTPS トラフィック用のアプリケーション ゲートウェイと Web アプリケーション ファイアウォール、他のすべてのトラフィック用の Azure ファイアウォールの使用を示しています。

Azure サブスクリプションとオンプレミス ネットワークの間でトラフィックを接続してセグメント化する方法を示す図。

一般的に推奨される 2 つのシナリオは次のとおりです。

  • Azure ファイアウォールまたは NVA をアプリケーション ゲートウェイと並列に配置します。
  • アプリケーション ゲートウェイの後に Azure ファイアウォールまたは NVA を配置し、宛先に到達する前にトラフィックをさらに検査します。

詳細については、Microsoft Azure Well-Architected Framework の Azure Application Gateway に関するページを参照してください。

インターネット トラフィック フローのその他の一般的なパターンを次に示します。

複数のインターフェイスを使用したイングレス トラフィック

1 つのアプローチとして、NVA を使用する場合に仮想マシンで複数のネットワーク インターフェイスを使用する方法があります。1 つは信頼されていないトラフィック (外部接続) 用、もう 1 つは信頼済みトラフィック (内部接続) 用です。 トラフィック フローに関しては、UDR を使用してオンプレミスから NVA にイングレス トラフィックをルーティングする必要があります。 NVA によって受信されたインターネットからのイングレス トラフィックは、ゲスト OS アプライアンスと UDR の静的ルートの組み合わせによって、適切な VNet またはサブネット上の宛先ワークロードにルーティングされる必要があります。

エグレス トラフィックと UDR

VNet からインターネットに向けて送信されるトラフィックの場合は、選択した NVA をネクスト ホップとするルート テーブルを使用して UDR を適用できます。 複雑さを軽減するために、Azure Virtual WAN ハブ内に Azure ファイアウォールまたは NVA をデプロイし、ルーティングインテントを使用したインターネット セキュリティを有効にすることができます。 これにより、(ネットワーク スコープに出入りする) 南北のトラフィックと、Azure 以外の仮想 IP アドレス (VIP) 宛ての東西のトラフィック (ネットワーク スコープ内のデバイス間) の両方が検査されます。

エグレス トラフィックと既定のルート

一部の方法では、さまざまな方法で既定のルート (0.0.0.0/0) を管理する必要があります。 一般的なルールとして、Azure 内から送信されるエグレス トラフィックでは、Azure Firewall または NVA による出口ポイントと検査を利用することをお勧めします。理由は、Azure インフラストラクチャで処理できるスループットの量です。それはほとんどの場合、はるかに大きく回復性が高い可能性があります。 この場合、ワークロード サブネットの UDR で既定のルートを構成すると、それらの出口ポイントにトラフィックを強制できます。 また、出口ポイントとして、オンプレミスから Azure にエグレス トラフィックをルーティングすることもできます。 この場合は、Azure Route Server を NVA と組み合わせて使用 し、Border Gateway Protocol (BGP) を利用してオンプレミスへの既定のルートをアドバタイズします。

特別なケースとして、BGP 経由で既定のルートをアドバタイズして、すべてのエグレス トラフィックをオンプレミスにルーティングし戻すことが必要な場合があります。 これにより、VNet から送信されるトラフィックは、検査のためにオンプレミス ネットワーク経由でファイアウォールに強制的にトンネリングされます。 この最後のアプローチは、待ち時間が長くなり、Azure によって提供されるセキュリティ制御がないため、最も望ましくない方法です。 この手法は、オンプレミス環境内のトラフィック検査に固有の要件が存在する、政府および銀行セクターによって広く採用されています。

スケールの観点から:

  • 1 つの VNet では、レイヤー 4 のセマンティクスに厳密に準拠するネットワーク セキュリティ グループを使用することも、レイヤー 4 とレイヤー 7 の両方のセマンティクスに準拠する Azure ファイアウォールを使用することもできます。
  • 複数の VNet の場合でも、到達可能な場合は単一の Azure ファイアウォールを使用できます。また、各仮想ネットワークに Azure ファイアウォールをデプロイし、UDR を使用してトラフィックを転送することもできます。

大規模なエンタープライズ分散ネットワークの場合でも、ハブ アンド スポーク モデルを使用して UDR でトラフィックを転送できます。 ただし、これにより、管理オーバーヘッドが発生し、VNet ピアリングの制限に達する可能性があります。 使いやすくするために、Azure Virtual WAN では、仮想ハブに Azure ファイアウォールをデプロイし、インターネット セキュリティのルーティングインテントをアクティブ化することで、これを実現できるようになっています。 これにより、すべてのスポークとブランチ ネットワークに既定のルートが挿入され、インターネットにバインドされたトラフィックが検査のために Azure ファイアウォールに送信されます。 RFC 1918 アドレス ブロック宛てのプライベート トラフィックは、Azure Virtual WAN ハブ内の指定されたネクスト ホップとしての Azure ファイアウォールまたは NVA に送信されます。

オンプレミスのネットワーク境界

Azure では、オンプレミス ネットワークとの接続を確立するための主な方法として、インターネット プロトコル (IPsec) トンネル、ExpressRoute トンネル、ソフトウェア定義型 WAN (SD-WAN) トンネルなどがあります。 通常、Azure サイト間 (S2S) VPN 接続は、必要とする帯域幅が少ない小規模なワークロードに使用します。 専用のサービス パスを必要とする、より高いスループットのニーズがあるワークロードの場合、Microsoft では ExpressRoute をお勧めします。

この図は、Azure 環境とオンプレミス ネットワークの間のさまざまな種類の接続方法を示しています。

Azure 環境とオンプレミス ネットワークの間のさまざまな種類の接続方法を示す図。

Azure VPN 接続では複数のトンネルをサポートできますが、ExpressRoute は多くの場合、接続パートナーを介した、より高い帯域幅とプライベート接続を必要とする大規模なエンタープライズ ネットワーク用に構成されます。 ExpressRoute では同じ VNet を複数の回線に接続できますが、そうすると相互に接続されていない VNet の通信が許可されるため、これは多くの場合、セグメント化の目的には理想的ではありません。

セグメント化の方法の 1 つは、スポークの VNet でリモート ゲートウェイを使用しないことを選択するか、ルート テーブルを使用している場合は BGP ルート伝達を無効にすることです。 その場合も、NVA とファイアウォールを使用して ExpressRoute に接続されているハブをセグメント化できます。 ハブにピアリングされているスポークに対しては、リモート ゲートウェイを使用しないことを VNet ピアリング プロパティで選択できます。 そうすることで、スポークは直接接続されたハブについてのみ学習し、オンプレミスのルートは学習しません。

オンプレミスとの間で送受信されるトラフィックをセグメント化するためのもう 1 つの新しいアプローチは、SD-WAN テクノロジの使用です。 Azure でサードパーティの NVA を使用して、ブランチの場所を Azure SD-WAN に拡張し、NVA アプライアンス内の異なるブランチからの SD-WAN トンネルに基づいてセグメント化を作成できます。 Azure Route Server を使用して、ハブ アンド スポーク トポロジ用の Azure プラットフォームに SD-WAN トンネルのアドレス プレフィックスを挿入できます。

仮想 WAN トポロジの場合は、仮想ハブ内にサードパーティの SD-WAN NVA を直接統合できます。 また、BGP エンドポイントを使用して SD-WAN ソリューションを使用し、仮想ハブ統合 NVA からトンネルを作成することもできます。

どちらのモデルでも、ExpressRoute を使用して、基になるプライベートまたはパブリック接続をプライベート ピアリングまたは Microsoft ピアリングでセグメント化できます。 セキュリティ上の理由から、ExpressRoute 経由で既定のルートをアドバタイズするのが一般的な方法です。 これにより、VNet から送信されるすべてのトラフィックが、検査のためにオンプレミス ネットワークにトンネリングされます。 同様に、VPN と ExpressRoute の両方を経由するトラフィックは、さらに検査するために NVA に送信できます。 これは、Azure から送信されるトラフィックにも適用されます。 環境が小さい場合 (リージョンが 1 つか 2 つなど)、これらの方法は簡単です。

大規模な分散ネットワークの場合も、ルーティング インテントを使用してプライベート トラフィック検査をアクティブ化することで、Azure Virtual WAN を使用できます。 これにより、NVA のプライベート IP アドレス宛てのすべてのトラフィックが検査のために転送されます。 上記の方法と同様に、環境が複数のリージョンにまたがっている場合、管理がはるかに簡単になります。

Azure Virtual WAN でのもう 1 つのアプローチは、分離境界にカスタム ルート テーブルを使用することです。 カスタム ルートを作成し、必要な VNet のみを関連付けて、それらのルート テーブルに伝達できます。 ただし、現時点では、この機能をルーティング インテントと組み合わせることはできません。 ブランチを分離するには、ラベルを割り当ててブランチをそのラベルに関連付けることができます。 ハブごとに既定のラベルへの伝達を無効にすることもできます。 現時点では、Azure 内の個々のブランチを 1 つのハブで個別に分離することはできません。 たとえば、ExpressRoute から SD-WAN を分離することはできません。 ただし、ハブ全体で、既定のラベルへの伝達を無効にできます。

グローバル Azure サービスに対する境界

Azure では、ほとんどのサービスは既定で Azure グローバル WAN 経由でアクセスできます。 これは、Azure PaaS サービスへのパブリック アクセスにも適用されます。 たとえば、Azure Storage には組み込みのファイアウォールがあり、VNet へのアクセスを制限し、パブリック アクセスをブロックできます。 ただし、多くの場合、より細かい制御が必要です。 提供される既定のパブリック IP アドレスを使用するのではなく、Azure VIP にプライベートに接続するのが一般的な設定です。

PaaS リソースへのアクセスを制限する最も一般的な方法は、Azure Private Link を使用することです。 プライベート エンドポイントを作成すると、VNet に挿入されます。 Azure はこのプライベート IP アドレスを使って、対象の PaaS リソースにトンネリングします。 Azure は、Azure プライベート DNS ゾーンを使用して DNS A レコードをプライベート エンドポイントにマップし、CNAME レコードをプライベート リンク PaaS リソースにマップします。

サービス エンドポイントにより、PaaS VIP への別の接続方法が提供されます。 サービス タグを選択すると、そのタグ内のすべての PaaS リソースへの接続を許可し、PaaS リソースへのプライベート接続を提供できます。

もう 1 つの一般的な方法では、ExpressRoute に Microsoft ピアリングを使用します。 オンプレミスから PaaS VIP に接続する場合は、Microsoft ピアリングを設定できます。 VIP を使用する BGP コミュニティを選択すると、Microsoft ピアリング パス経由でアドバタイズされます。

詳細については、次のガイダンスを参照してください。

セグメント化の概要

次の表は、さまざまなレベルのセグメント化とセキュリティの方法をまとめたものです。

[開始 既定の動作 通信を有効にする方法... セグメント化のセキュリティの方法
サブスクリプション 通信しない - VNet ピアリング

- VPN ゲートウェイ
Azure Firewall
VNet 通信しない - VNet ピアリング

- VPN ゲートウェイ
Azure Firewall
VNet 内のサブネット上のワークロード オープンなコミュニケーション 該当なし - ネットワーク セキュリティ グループ

- アプリケーション セキュリティ グループ
インターネットと VNet 通信しない - ロード バランサー

- パブリック IP

- Application Gateway

- Azure Front Door
- Azure Application Gateway と Web アプリケーション ファイアウォール

- Azure Firewall

- Azure Front Door と Web アプリケーション ファイアウォール
インターネットとオンプレミス ネットワーク 通信しない - Azure S2S VPN

- IPSec トンネル

- ExpressRoute トンネル

- SD-WAN トンネル
Azure Firewall
インターネットと VNet 内の仮想マシン 仮想マシンにプライベート IP アドレスしかない場合は通信しない 仮想マシンにパブリック IP アドレスを割り当てる 仮想マシンのローカル ファイアウォール

次のステップ

Azure ネットワークへのゼロ トラストの適用の詳細については、以下を参照してください。

関連情報

この記事でメンションされているさまざまなサービスとテクノロジについては、次のリンクを参照してください。