Microsoft クラウド サービスとネットワーク セキュリティMicrosoft cloud services and network security

Microsoft クラウド サービスでは、ハイパースケール サービスとインフラストラクチャ、エンタープライズ レベルの機能、ハイブリッド接続の多くの選択肢を提供しています。Microsoft cloud services deliver hyper-scale services and infrastructure, enterprise-grade capabilities, and many choices for hybrid connectivity. 顧客は、これらのサービスにインターネット経由でアクセスするか、プライベート ネットワーク接続を提供する Azure ExpressRoute を使用してアクセスするかを選択できます。Customers can choose to access these services either via the Internet or with Azure ExpressRoute, which provides private network connectivity. Microsoft Azure Platform により、顧客は自身のインフラストラクチャをシームレスにクラウドに拡張し、多層アーキテクチャを構築できます。The Microsoft Azure platform allows customers to seamlessly extend their infrastructure into the cloud and build multi-tier architectures. また、サード パーティは、セキュリティ サービスや仮想アプライアンスを提供することで、機能を強化できます。Additionally, third parties can enable enhanced capabilities by offering security services and virtual appliances. このホワイト ペーパーでは、顧客が ExpressRoute 経由でアクセスした Microsoft クラウド サービスを使用するときに考慮する必要がある、セキュリティとアーキテクチャの問題の概要を説明します。This white paper provides an overview of security and architectural issues that customers should consider when using Microsoft cloud services accessed via ExpressRoute. また、Azure 仮想ネットワークでより安全なサービスを作成する方法についても説明します。It also covers creating more secure services in Azure virtual networks.

はじめにFast start

次の論理チャートは、Azure Platform で利用可能な多数のセキュリティ手法の具体例を示しています。The following logic chart can direct you to a specific example of the many security techniques available with the Azure platform. クイック リファレンスでは、現在の状況に最も適した例を紹介します。For quick reference, find the example that best fits your case. 詳細については、このホワイト ペーパーを引き続きお読みください。For expanded explanations, continue reading through the paper. 00

例 1: 境界ネットワーク (DMZ、非武装地帯、またはスクリーン サブネットとも呼ばれます) を構築し、ネットワーク セキュリティ グループ (NSG) を使用してアプリケーションを保護する。Example 1: Build a perimeter network (also known as DMZ, demilitarized zone, or screened subnet) to help protect applications with network security groups (NSGs).
例 2: 境界ネットワークを構築し、ファイアウォールと NSG を使用してアプリケーションを保護する。 Example 2: Build a perimeter network to help protect applications with a firewall and NSGs.
例 3: 境界ネットワークを構築し、ファイアウォール、ユーザー定義ルート (UDR)、および NSG を使用してネットワークを保護する。 Example 3: Build a perimeter network to help protect networks with a firewall, user-defined route (UDR), and NSG.
例 4: サイト間の仮想アプライアンス仮想プライベート ネットワーク (VPN) を使用してハイブリッド接続を追加する。 Example 4: Add a hybrid connection with a site-to-site, virtual appliance virtual private network (VPN).
例 5: サイト間の Azure VPN ゲートウェイを使用してハイブリッド接続を追加する。 Example 5: Add a hybrid connection with a site-to-site, Azure VPN gateway.
例 6: ExpressRoute を使用してハイブリッド接続を追加する。 Example 6: Add a hybrid connection with ExpressRoute.
仮想ネットワーク間の接続、高可用性、サービス チェイニングの追加の例については、今後数か月の間にこのドキュメントに追加される予定です。Examples for adding connections between virtual networks, high availability, and service chaining will be added to this document over the next few months.

Microsoft のコンプライアンスとインフラストラクチャの保護Microsoft compliance and infrastructure protection

個人データの収集と使用に関する国、地域、および業界固有の要件に組織が準拠できるように、Microsoft は 40 種類を超える認定と認証を提供しています。To help organizations comply with national, regional, and industry-specific requirements governing the collection and use of individuals’ data, Microsoft offers over 40 certifications and attestations. これはクラウド サービス プロバイダーの中でも最も包括的なセットです。The most comprehensive set of any cloud service provider.

詳細については、Microsoft セキュリティ センターのコンプライアンス情報を参照してください。For more information, see the compliance information on the Microsoft Trust Center.

Microsoft は、非常にスケール性の高いグローバル サービスの実行に必要なクラウド インフラストラクチャを保護するための包括的なアプローチを備えています。Microsoft has a comprehensive approach to protect cloud infrastructure needed to run hyper-scale global services. Microsoft のクラウド インフラストラクチャには、物理的なデータ センターに加え、ハードウェア、ソフトウェア、ネットワーク、管理スタッフ、運用スタッフも含まれています。Microsoft cloud infrastructure includes hardware, software, networks, and administrative and operations staff, in addition to the physical data centers.

22

このアプローチでは、顧客が Microsoft のクラウドでサービスをデプロイするためのより安全な基盤を提供します。This approach provides a more secure foundation for customers to deploy their services in the Microsoft cloud. 次の手順では、顧客がこれらのサービスを保護するためのセキュリティ アーキテクチャを設計して作成します。The next step is for customers to design and create a security architecture to protect these services.

従来のセキュリティ アーキテクチャと境界ネットワークTraditional security architectures and perimeter networks

Microsoft は、クラウド インフラストラクチャの保護に多額の投資を行っていますが、顧客も自身のクラウド サービスとリソース グループを保護する必要があります。Although Microsoft invests heavily in protecting the cloud infrastructure, customers must also protect their cloud services and resource groups. セキュリティの多層アプローチにより、最大限の保護が実現されます。A multilayered approach to security provides the best defense. 境界ネットワークのセキュリティ ゾーンは、信頼されていないネットワークから内部のネットワーク リソースを保護します。A perimeter network security zone protects internal network resources from an untrusted network. 境界ネットワークは、インターネットと企業の保護された IT インフラストラクチャの間にあるネットワークの境界または領域を指します。A perimeter network refers to the edges or parts of the network that sit between the Internet and the protected enterprise IT infrastructure.

一般的な企業ネットワークでは、複数層のセキュリティ デバイスにより、コア インフラストラクチャの境界が厳重に防備されています。In typical enterprise networks, the core infrastructure is heavily fortified at the perimeters, with multiple layers of security devices. 各層の境界は、デバイスとポリシー適用ポイントで構成されます。The boundary of each layer consists of devices and policy enforcement points. 各層には、ネットワーク セキュリティ デバイス (ファイアウォール、サービス拒否 (DoS) 防止、侵入検出システムまたは侵入防止システム (IDS/IPS)、VPN デバイスなど) を組み合わせたものを含めることができます。Each layer can include a combination of the following network security devices: firewalls, Denial of Service (DoS) prevention, Intrusion Detection or Protection Systems (IDS/IPS), and VPN devices. ポリシーの適用は、ファイアウォール ポリシー、アクセス制御リスト (ACL)、または特定のルーティングという形で行われます。Policy enforcement can take the form of firewall policies, access control lists (ACLs), or specific routing. ネットワークにおける防御の最前線では、インターネットから着信トラフィックを直接受け取ると、これらのメカニズムを組み合わせて攻撃や有害なトラフィックをブロックすると同時に、有効な要求をネットワークの内部に送信します。The first line of defense in the network, directly accepting incoming traffic from the Internet, is a combination of these mechanisms to block attacks and harmful traffic while allowing legitimate requests further into the network. このトラフィックは、境界ネットワーク内のリソースに直接ルーティングされます。This traffic routes directly to resources in the perimeter network. その後、そのリソースはネットワーク内のさらに深い場所にあるリソースと "対話" し、まずは検証のために次の境界を通過します。That resource may then “talk” to resources deeper in the network, transiting the next boundary for validation first. 最も外側の層が境界ネットワークと呼ばれます。ネットワークのこの部分は、インターネットに接する部分で、通常、内側と外側は何らかの形で保護されています。The outermost layer is called the perimeter network because this part of the network is exposed to the Internet, usually with some form of protection on both sides. 次の図は、2 つのセキュリティ境界を持つ企業ネットワークにおける単一のサブネット境界ネットワークの例を示しています。The following figure shows an example of a single subnet perimeter network in a corporate network, with two security boundaries.

33

境界ネットワークを実装するためには、多くのアーキテクチャが使用されます。There are many architectures used to implement a perimeter network. これらのアーキテクチャは、単純なロード バランサーから、トラフィックをブロックして企業ネットワークのより深い層を保護するために各境界でさまざまなメカニズムを使用する複数サブネット境界ネットワークまで、多岐にわたることがあります。These architectures can range from a simple load balancer to a multiple-subnet perimeter network with varied mechanisms at each boundary to block traffic and protect the deeper layers of the corporate network. 境界ネットワークを構築する方法は、組織の具体的なニーズや全体的なリスク許容度によって異なります。How the perimeter network is built depends on the specific needs of the organization and its overall risk tolerance.

顧客がワークロードをパブリック クラウドに移行する場合、重要なのは、Azure の境界ネットワーク アーキテクチャで同様の機能をサポートし、コンプライアンスとセキュリティの要件を満たすことです。As customers move their workloads to public clouds, it is critical to support similar capabilities for perimeter network architecture in Azure to meet compliance and security requirements. このドキュメントでは、顧客がセキュリティで保護されたネットワーク環境を Azure で構築する方法に関するガイドラインを示します。This document provides guidelines on how customers can build a secure network environment in Azure. 境界ネットワークに重点を置いて説明しますが、ネットワーク セキュリティのさまざまな側面についても包括的に説明します。It focuses on the perimeter network, but also includes a comprehensive discussion of many aspects of network security. 次の質問は、この説明のポイントとなります。The following questions inform this discussion:

  • Azure では、境界ネットワークをどのように構築できますか。How can a perimeter network in Azure be built?
  • 境界ネットワークの構築に使用できる Azure の機能を教えてください。What are some of the Azure features available to build the perimeter network?
  • バック エンドのワークロードはどのように保護できますか。How can back-end workloads be protected?
  • インターネット通信はどのように Azure のワークロードに制御されていますか。How are Internet communications controlled to the workloads in Azure?
  • Azure のデプロイからオンプレミスのネットワークを保護するにはどうすればよいですか。How can the on-premises networks be protected from deployments in Azure?
  • サード パーティ製のアプライアンスやサービスと比較して、どのような場合にネイティブの Azure セキュリティ機能を使用する必要がありますか。When should native Azure security features be used versus third-party appliances or services?

次の図は、Azure が顧客に提供するさまざまなセキュリティ層を示しています。The following diagram shows various layers of security Azure provides to customers. これらの層は、Azure プラットフォーム自体とユーザー定義機能の両方でネイティブです。These layers are both native in the Azure platform itself and customer-defined features:

44

インターネットから受信する場合は、Azure DDoS が Azure に対する大規模な攻撃から保護します。Inbound from the Internet, Azure DDoS helps protect against large-scale attacks against Azure. 次の層は、顧客が定義したパブリック IP アドレス (エンドポイント) です。これらのエンドポイントは、クラウド サービスを通過して仮想ネットワークに到達できるトラフィックを決定するために使用されます。The next layer is customer-defined public IP addresses (endpoints), which are used to determine which traffic can pass through the cloud service to the virtual network. Azure のネイティブな仮想ネットワーク分離により、その他すべてのネットワークからの完全な分離が実現し、トラフィックはユーザーが構成した経路と方法のみを使用して流れるようになります。Native Azure virtual network isolation ensures complete isolation from all other networks and that traffic only flows through user configured paths and methods. これらの経路と方法が次の層となります。次の層では、NSG、UDR、ネットワーク仮想アプライアンスを使用して DMZ などのセキュリティ境界を構築し、保護されているネットワークにおけるアプリケーションのデプロイを保護することができます。These paths and methods are the next layer, where NSGs, UDR, and network virtual appliances can be used to create security boundaries to protect the application deployments in the protected network.

次のセクションでは、Azure 仮想ネットワークの概要を説明します。The next section provides an overview of Azure virtual networks. これらの仮想ネットワークは顧客によって作成され、デプロイされたワークロードの接続先となります。These virtual networks are created by customers, and are what their deployed workloads are connected to. 仮想ネットワークは、Azure で顧客のデプロイメントを保護する境界ネットワークの構築に必要なすべてのネットワーク セキュリティ機能の基盤となります。Virtual networks are the basis of all the network security features required to establish a perimeter network to protect customer deployments in Azure.

Azure 仮想ネットワークの概要Overview of Azure virtual networks

インターネット トラフィックが Azure 仮想ネットワークに到達する前に、Azure Platform に固有のセキュリティ層が 2 つあります。Before Internet traffic can get to the Azure virtual networks, there are two layers of security inherent to the Azure platform:

  1. DDoS 保護: DDoS 保護は、大規模なインターネットベースの攻撃から Azure Platform 自体を保護する Azure 物理ネットワークの層です。DDoS protection: DDoS protection is a layer of the Azure physical network that protects the Azure platform itself from large-scale Internet-based attacks. このような攻撃では 1 回の攻撃で複数の"bot"ノードを使用し、インターネット サービスに過剰な負荷をかけます。These attacks use multiple “bot” nodes in an attempt to overwhelm an Internet service. Azure には、すべての受信、送信、Azure リージョン間接続に対する堅牢な DDoS 防御網が用意されています。Azure has a robust DDoS protection mesh on all inbound, outbound, and cross-Azure region connectivity. この DDoS 保護層にはユーザーが構成できる属性がないため、顧客はこの層にアクセスできません。This DDoS protection layer has no user configurable attributes and is not accessible to the customer. DDoS 保護層は、プラットフォームとしての Azure を大規模な攻撃から保護するほか、送信トラフィックと Azure リージョン間トラフィックを監視します。The DDoS protection layer protects Azure as a platform from large-scale attacks, it also monitors out-bound traffic and cross-Azure region traffic. 顧客は VNet のネットワーク仮想アプライアンスを使用して、プラットフォーム レベルの保護が作動しない小規模な攻撃に対する追加の復元層を構成することができます。Using network virtual appliances on the VNet, additional layers of resilience can be configured by the customer against a smaller scale attack that doesn't trip the platform level protection. DDoS の動作の例は次のとおりです。インターネットに接続する IP アドレスが大規模な DDoS 攻撃を受けた場合、攻撃が目的の対象に到達する前に Azure は攻撃元を検出し、問題のあるトラフィックを除去します。An example of DDoS in action; if an internet facing IP address was attacked by a large-scale DDoS attack, Azure would detect the sources of the attacks and scrub the offending traffic before it reached its intended destination. ほとんどの場合、攻撃対象のエンドポイントは攻撃の影響を受けません。In almost all cases, the attacked endpoint isn't affected by the attack. まれにエンドポイントが影響を受けることがありますが、その場合は他のエンドポイントにまでトラフィックの影響が及ぶことはなく、攻撃対象のエンドポイントにのみ影響があります。In the rare cases that an endpoint is affected, no traffic is affected to other endpoints, only the attacked endpoint. したがって、他の顧客やサービスからは、その攻撃による影響がわかりません。Thus other customers and services would see no impact from that attack. Azure DDoS が確認するのは大規模な攻撃のみであることに注意してください。It's critical to note that Azure DDoS is only looking for large-scale attacks. プラットフォーム レベルの保護のしきい値を超える前に、特定のサービスに過剰な負荷がかかる可能性があります。It is possible that your specific service could be overwhelmed before the platform level protection thresholds are exceeded. たとえば、Azure のプラットフォーム レベルの DDoS 保護が脅威を登録する前に、1 台の A0 IIS サーバー上の Web サイトが DDoS 攻撃によってオフラインにされる可能性があります。For example, a web site on a single A0 IIS server, could be taken offline by a DDoS attack before Azure platform level DDoS protection registered a threat.

  2. Public IP Addresses: Public IP Addresses (リソースにルーティングされるパブリック IP アドレスをインターネットに提示する、サービス エンドポイント、Public IP Addresses、Application Gateway などの Azure 機能を通じて有効化) を使用することで、クラウド サービスまたはリソース グループはパブリック インターネット IP アドレスとポートを公開できます。Public IP Addresses: Public IP addresses (enabled via service endpoints, Public IP addresses, Application Gateway, and other Azure features that present a public IP address to the internet routed to your resource) allow cloud services or resource groups to have public Internet IP addresses and ports exposed. エンドポイントでは、ネットワーク アドレス変換 (NAT) を使用して、トラフィックを Azure 仮想ネットワークの内部アドレスとポートにルーティングします。The endpoint uses Network Address Translation (NAT) to route traffic to the internal address and port on the Azure virtual network. これは、外部トラフィックが仮想ネットワークに到達するための主な経路です。This path is the primary way for external traffic to pass into the virtual network. Public IP Addresses は、仮想ネットワークに渡されるトラフィックと、そのトラフィックが仮想ネットワークのどこでどのように変換されるかを決定するために構成できます。The Public IP addresses are configurable to determine which traffic is passed in, and how and where it's translated on to the virtual network.

トラフィックが仮想ネットワークに到達すると、多くの機能を使用できるようになります。Once traffic reaches the virtual network, there are many features that come into play. Azure 仮想ネットワークは、顧客がワークロードを接続するための基盤であり、基本的なネットワーク レベルのセキュリティが適用されます。Azure virtual networks are the foundation for customers to attach their workloads and where basic network-level security applies. 次の機能と特性を使用する顧客の場合、これが Azure のプライベート ネットワーク (仮想ネットワークのオーバーレイ) になります。It is a private network (a virtual network overlay) in Azure for customers with the following features and characteristics:

  • トラフィックの分離: 仮想ネットワークは、Azure Platform でのトラフィックの分離境界となります。Traffic isolation: A virtual network is the traffic isolation boundary on the Azure platform. ある仮想ネットワーク内の仮想マシン (VM) と別の仮想ネットワーク内の VM は、両方の仮想ネットワークを同じ顧客が作成した場合でも、直接通信することはできません。Virtual machines (VMs) in one virtual network cannot communicate directly to VMs in a different virtual network, even if both virtual networks are created by the same customer. 分離は、顧客の VM と通信が仮想ネットワーク内でプライベートであることを保証する重要な特性です。Isolation is a critical property that ensures customer VMs and communication remains private within a virtual network.

注意

トラフィックの分離は、仮想ネットワークへの "受信" 方向のトラフィックのみに適用されます。Traffic isolation refers only to traffic inbound to the virtual network. 既定では、VNet からインターネットへの送信トラフィックは許可されていますが、必要に応じて NSG でブロックできます。By default outbound traffic from the VNet to the internet is allowed, but can be prevented if desired by NSGs.

  • 多層トポロジ: 仮想ネットワークでは、顧客は、サブネットを割り当てて、ワークロードのさまざまな要素 ("層") に個別のアドレス空間を指定することで、多層トポロジを定義できます。Multi-tier topology: Virtual networks allow customers to define multi-tier topology by allocating subnets and designating separate address spaces for different elements or “tiers” of their workloads. このような論理的なグループとトポロジを使用すると、顧客は、ワークロードの種類に基づいて異なるアクセス ポリシーを定義するだけでなく、各層の間のトラフィック フローを制御することもできます。These logical groupings and topologies enable customers to define different access policy based on the workload types, and also control traffic flows between the tiers.
  • クロスプレミス接続: Azure で 1 つの仮想ネットワークと複数のオンプレミス サイトや他の仮想ネットワークとの間にクロスプレミス接続を確立できます。Cross-premises connectivity: Customers can establish cross-premises connectivity between a virtual network and multiple on-premises sites or other virtual networks in Azure. 顧客は、接続を構成する際、VNet のピアリング、Azure VPN ゲートウェイ、サードパーティ製のネットワーク仮想アプライアンス、または ExpressRoute を使用できます。To construct a connection, customers can use VNet Peering, Azure VPN Gateways, third-party network virtual appliances, or ExpressRoute. Azure では、標準的な IPsec/IKE プロトコルと ExpressRoute プライベート接続を使用したサイト間 (S2S) VPN をサポートしています。Azure supports site-to-site (S2S) VPNs using standard IPsec/IKE protocols and ExpressRoute private connectivity.
  • NSG を使用して、必要なレベルの粒度 (ネットワーク インターフェイス、個々の VM、仮想サブネットなど) でルール (ACL) を作成できます。NSG allows customers to create rules (ACLs) at the desired level of granularity: network interfaces, individual VMs, or virtual subnets. 顧客は、仮想ネットワーク内でのワークロード間の通信を許可または拒否することで、クロスプレミス接続を介した顧客のネットワーク上のシステムからのアクセス、または直接インターネット通信を制御できます。Customers can control access by permitting or denying communication between the workloads within a virtual network, from systems on customer’s networks via cross-premises connectivity, or direct Internet communication.
  • UDRIP 転送を使用して、仮想ネットワーク内の異なる層間の通信経路を定義できます。UDR and IP Forwarding allow customers to define the communication paths between different tiers within a virtual network. ファイアウォール、IDS/IPS、その他の仮想アプライアンスをデプロイし、これらのセキュリティ アプライアンスを介してネットワーク トラフィックをルーティングすることで、セキュリティ境界ポリシーを適用、監査、検査することができます。Customers can deploy a firewall, IDS/IPS, and other virtual appliances, and route network traffic through these security appliances for security boundary policy enforcement, auditing, and inspection.
  • ネットワーク仮想アプライアンス : ファイアウォール、ロード バランサー、IDS/IPS などのセキュリティ アプライアンスは、Azure Marketplace と VM イメージ ギャラリーで入手できます。Network virtual appliances in the Azure Marketplace: Security appliances such as firewalls, load balancers, and IDS/IPS are available in the Azure Marketplace and the VM Image Gallery. これらのアプライアンスを仮想ネットワーク、特にセキュリティ境界 (境界ネットワーク サブネットを含む) にデプロイすることで、多層のセキュリティで保護されたネットワーク環境を実現できます。Customers can deploy these appliances into their virtual networks, and specifically, at their security boundaries (including the perimeter network subnets) to complete a multi-tiered secure network environment.

このような機能を使用した場合に Azure で境界ネットワーク アーキテクチャがどのように構築されるかについて、一例を次の図に示します。With these features and capabilities, one example of how a perimeter network architecture could be constructed in Azure is the following diagram:

55

境界ネットワークの特性と要件Perimeter network characteristics and requirements

境界ネットワークはネットワークのフロントエンドであり、インターネットからの通信を直接受ける部分です。The perimeter network is the front end of the network, directly interfacing communication from the Internet. 受信パケットは、バックエンド サーバーに到達するまでにセキュリティ アプライアンス (ファイアウォール、IDS、IPS など) を通過する必要があります。The incoming packets should flow through the security appliances, such as the firewall, IDS, and IPS, before reaching the back-end servers. また、ワークロードからインターネットへのパケットも、ネットワークから送信される前に、ポリシーの適用、検査、監査を行うために境界ネットワーク内のセキュリティ アプライアンスを通過する場合があります。Internet-bound packets from the workloads can also flow through the security appliances in the perimeter network for policy enforcement, inspection, and auditing purposes, before leaving the network. さらに、境界ネットワークでは、顧客の仮想ネットワークとオンプレミス ネットワーク間のクロスプレミスの VPN ゲートウェイをホストすることもできます。Additionally, the perimeter network can host cross-premises VPN gateways between customer virtual networks and on-premises networks.

境界ネットワークの特性Perimeter network characteristics

上の図を参照し、次の適切な境界ネットワークの特性を確認します。Referencing the previous figure, some of the characteristics of a good perimeter network are as follows:

  • インターネットに面する場合:Internet-facing:
    • 境界ネットワーク サブネット自体がインターネットに接続されており、インターネットと直接通信します。The perimeter network subnet itself is Internet-facing, directly communicating with the Internet.
    • パブリック IP アドレス、VIP、サービス エンドポイントは、フロントエンドのネットワークとデバイスにインターネット トラフィックを渡します。Public IP addresses, VIPs, and/or service endpoints pass Internet traffic to the front-end network and devices.
    • インターネットからの受信トラフィックは、セキュリティ デバイスを通過してからフロントエンド ネットワーク上の他のリソースに到達します。Inbound traffic from the Internet passes through security devices before other resources on the front-end network.
    • 送信セキュリティが有効になっている場合、トラフィックは、セキュリティ デバイスを通過してから、最終段階としてインターネットに渡されます。If outbound security is enabled, traffic passes through security devices, as the final step, before passing to the Internet.
  • 保護されたネットワーク:Protected network:
    • インターネットからコア インフラストラクチャへの直接パスはありません。There is no direct path from the Internet to the core infrastructure.
    • コア インフラストラクチャへのチャネルは、NSG、ファイアウォール、VPN デバイスなどのセキュリティ デバイスを経由する必要があります。Channels to the core infrastructure must traverse through security devices such as NSGs, firewalls, or VPN devices.
    • 他のデバイスがインターネットとコア インフラストラクチャの橋渡しをすることはできません。Other devices must not bridge Internet and the core infrastructure.
    • インターネットに面した境界と、保護されているネットワークに面した境界の両方にあるセキュリティ デバイス (例: 上の図で表示されている 2 つのファイアウォール アイコン) は、実際には、各境界に区別されたルールまたはインターフェイスを持つ 1 つの仮想アプライアンスである可能性があります Security devices on both the Internet-facing and the protected network facing boundaries of the perimeter network (for example, the two firewall icons shown in the previous figure) may actually be a single virtual appliance with differentiated rules or interfaces for each boundary. たとえば、境界ネットワークの両方の境界の負荷を処理する、論理的に分離された 1 つのデバイスなどです。For example, one physical device, logically separated, handling the load for both boundaries of the perimeter network.
  • その他の一般的な慣行と制約:Other common practices and constraints:
    • ワークロードには、ビジネスに不可欠な情報を格納することはできません。Workloads must not store business critical information.
    • 境界ネットワークの構成とデプロイへのアクセスと更新は、承認された管理者のみに制限されます。Access and updates to perimeter network configurations and deployments are limited to only authorized administrators.

境界ネットワーク に関する要件Perimeter network requirements

これらの特性を有効にするために、正常な境界ネットワークを実装するための仮想ネットワークの要件に関する次のガイドラインに従います。To enable these characteristics, follow these guidelines on virtual network requirements to implement a successful perimeter network:

  • サブネット アーキテクチャ: サブネット全体が境界ネットワークとして特化されるように仮想ネットワークを指定すると、同じ仮想ネットワーク内の他のサブネットから分離されます。Subnet architecture: Specify the virtual network such that an entire subnet is dedicated as the perimeter network, separated from other subnets in the same virtual network. この分離により、境界ネットワークとその他の内部またはプライベートのサブネット層との間のトラフィックは、ファイアウォールまたは IDS/IPS 仮想アプライアンスを通過します。This separation ensures the traffic between the perimeter network and other internal or private subnet tiers flows through a firewall or IDS/IPS virtual appliance. このトラフィックを仮想アプライアンスに転送するには、境界サブネット上のユーザー定義ルートが必要です。User-defined routes on the boundary subnets are required to forward this traffic to the virtual appliance.
  • NSG: インターネットとの通信を許可するために境界ネットワーク サブネット自体を開いた状態にしておく必要があります。ただし、顧客が NSG をバイパスする必要があるという意味ではありません。NSG: The perimeter network subnet itself should be open to allow communication with the Internet, but that does not mean customers should be bypassing NSGs. 一般的なセキュリティの慣例に従い、インターネットに公開されるネットワークの場所を最小限に抑えます。Follow common security practices to minimize the network surfaces exposed to the Internet. デプロイや開いている特定のアプリケーション プロトコルまたはポートへのアクセスを許可するリモート アドレスの範囲をロック ダウンします。Lock down the remote address ranges allowed to access the deployments or the specific application protocols and ports that are open. ただし、完全なロック ダウンが不可能な場合もあります。There may be circumstances, however, in which a complete lock-down is not possible. たとえば、顧客が Azure に外部 Web サイトを所有している場合、境界ネットワークではパブリック IP アドレスからの着信 Web 要求を許可する必要がありますが、開く必要がある Web アプリケーション ポートは TCP ポート 80 と TCP ポート 443 のみです。For example, if customers have an external website in Azure, the perimeter network should allow the incoming web requests from any public IP addresses, but should only open the web application ports: TCP on port 80 and/or TCP on port 443.
  • ルーティング テーブル: 境界ネットワーク サブネット自体は、インターネットと直接通信できる必要がありますが、ファイアウォールやセキュリティ アプライアンスを介さずにバックエンド ネットワークまたはオンプレミス ネットワークと直接通信することはできないようにする必要があります。Routing table: The perimeter network subnet itself should be able to communicate to the Internet directly, but should not allow direct communication to and from the back end or on-premises networks without going through a firewall or security appliance.
  • セキュリティ アプライアンスの構成: 境界ネットワークと他の保護されているネットワークとの間でパケットをルーティングして検査するために、セキュリティ アプライアンス (ファイアウォール、IDS、IPS デバイスなど) はマルチホームにすることができます。Security appliance configuration: To route and inspect packets between the perimeter network and the rest of the protected networks, the security appliances such as firewall, IDS, and IPS devices may be multi-homed. この場合、境界ネットワークとバックエンド サブネットに個別の NIC を使用することがあります。They may have separate NICs for the perimeter network and the back-end subnets. 境界ネットワークの NIC は、対応する NSG と境界ネットワーク ルーティング テーブルを使用して、インターネットと直接通信します。The NICs in the perimeter network communicate directly to and from the Internet, with the corresponding NSGs and the perimeter network routing table. バックエンド サブネットに接続する NIC では、対応するバックエンド サブネットの NSG とルーティング テーブルがより限定的になります。The NICs connecting to the back-end subnets have more restricted NSGs and routing tables of the corresponding back-end subnets.
  • セキュリティ アプライアンスの機能: 境界ネットワークにデプロイされているセキュリティ アプライアンスは、通常、次の機能を実行します。Security appliance functionality: The security appliances deployed in the perimeter network typically perform the following functionality:
    • ファイアウォール: 受信要求にファイアウォール ルールまたはアクセス制御ポリシーを適用します。Firewall: Enforcing firewall rules or access control policies for the incoming requests.
    • 脅威の検出と防止: インターネットからの悪意のある攻撃を検出して軽減します。Threat detection and prevention: Detecting and mitigating malicious attacks from the Internet.
    • 監査とログ記録: 監査と分析のために詳細なログを保持します。Auditing and logging: Maintaining detailed logs for auditing and analysis.
    • リバース プロキシ: 受信要求を対応するバックエンド サーバーにリダイレクトします。Reverse proxy: Redirecting the incoming requests to the corresponding back-end servers. このリダイレクトには、フロントエンド デバイス (通常はファイアウォール) の宛先アドレスをバックエンド サーバーのアドレスにマッピングして変換することが含まれます。This redirection involves mapping and translating the destination addresses on the front-end devices, typically firewalls, to the back-end server addresses.
    • 転送プロキシ: NAT 機能を提供し、仮想ネットワーク内からインターネットに対して開始された通信の監査を実行します。Forward proxy: Providing NAT and performing auditing for communication initiated from within the virtual network to the Internet.
    • ルーター: 仮想ネットワーク内で着信トラフィックとサブネット間トラフィックを転送します。Router: Forwarding incoming and cross-subnet traffic inside the virtual network.
    • VPN デバイス: 顧客のオンプレミス ネットワークと Azure の仮想ネットワークとの間のクロスプレミス VPN 接続でクロスプレミスの VPN ゲートウェイとして動作します。VPN device: Acting as the cross-premises VPN gateways for cross-premises VPN connectivity between customer on-premises networks and Azure virtual networks.
    • VPN サーバー: Azure の仮想ネットワークに接続している VPN クライアントを受け入れます。VPN server: Accepting VPN clients connecting to Azure virtual networks.

ヒント

2 つのグループ (境界ネットワークのセキュリティ ギアへのアクセスが許可されている個人と、アプリケーションの開発、デプロイ、操作の管理者として承認された個人) を区別してください。Keep the following two groups separate: the individuals authorized to access the perimeter network security gear and the individuals authorized as application development, deployment, or operations administrators. これらのグループを区別すると、義務の分離も可能になり、1 人でアプリケーション セキュリティとネットワーク セキュリティの両方の制御をバイパスできなくなります。Keeping these groups separate allows for a segregation of duties and prevents a single person from bypassing both applications security and network security controls.

ネットワーク境界を構築する際の質問事項Questions to be asked when building network boundaries

このセクションでは、特に記載している場合を除き、"ネットワーク" という用語は、サブスクリプション管理者によって作成された、プライベートな Azure 仮想ネットワークを指しています。In this section, unless specifically mentioned, the term "networks" refers to private Azure virtual networks created by a subscription administrator. この用語は、Azure 内の基となる物理ネットワークを指していません。The term doesn't refer to the underlying physical networks within Azure.

また、Azure 仮想ネットワークは、従来のオンプレミス ネットワークを拡張するためによく使用されます。Also, Azure virtual networks are often used to extend traditional on-premises networks. サイト間または ExpressRoute のハイブリッド ネットワーク ソリューションと境界ネットワーク アーキテクチャを組み合わせることができます。It is possible to incorporate either site-to-site or ExpressRoute hybrid networking solutions with perimeter network architectures. このハイブリッド リンクは、ネットワーク セキュリティ境界を作成する際の重要な考慮事項です。This hybrid link is an important consideration in building network security boundaries.

境界ネットワークと複数のセキュリティ境界を使用したネットワークを構築する場合は、次の 3 つの重要な質問を確認する必要があります。The following three questions are critical to answer when you're building a network with a perimeter network and multiple security boundaries.

1) 境界はいくつ必要か1) How many boundaries are needed?

最初の決定ポイントでは、特定のシナリオで必要なセキュリティ境界の数を決定します。The first decision point is to decide how many security boundaries are needed in a given scenario:

  • 境界が 1 つの場合: 仮想ネットワークとインターネットの間のフロントエンド境界ネットワーク上に 1 つ。A single boundary: One on the front-end perimeter network, between the virtual network and the Internet.
  • 境界が 2 つの場合: 境界ネットワークのインターネット側に 1 つ、境界ネットワーク サブネットと Azure 仮想ネットワーク内のバックエンド サブネットの間に 1 つ。Two boundaries: One on the Internet side of the perimeter network, and another between the perimeter network subnet and the back-end subnets in the Azure virtual networks.
  • 境界が 3 つの場合: 境界ネットワークのインターネット側に 1 つ、境界ネットワーク サブネットとバックエンド サブネットの間に 1 つ、バックエンド サブネットとオンプレミス ネットワークの間に 1 つ。Three boundaries: One on the Internet side of the perimeter network, one between the perimeter network and back-end subnets, and one between the back-end subnets and the on-premises network.
  • 境界が N 個の場合: 変数の数。N boundaries: A variable number. セキュリティの要件によっては、特定のネットワークに適用できるセキュリティ境界の数に制限はありません。Depending on security requirements, there is no limit to the number of security boundaries that can be applied in a given network.

必要な境界の数と種類は、企業のリスク許容度と、実装する特定のシナリオに応じて異なります。The number and type of boundaries needed vary based on a company’s risk tolerance and the specific scenario being implemented. これは、多くの場合、リスク/コンプライアンス チーム、ネットワーク/プラットフォーム チーム、アプリケーション開発チームなど、組織内の複数のグループによって共同で決定されます。This decision is often made together with multiple groups within an organization, often including a risk and compliance team, a network and platform team, and an application development team. 各実装に適切なセキュリティへの対応を確保するために、セキュリティ、関連するデータ、使用されるテクノロジに詳しい人物がこの決定について権限を持つ必要があります。People with knowledge of security, the data involved, and the technologies being used should have a say in this decision to ensure the appropriate security stance for each implementation.

ヒント

特定の状況のセキュリティ要件を満たす境界の数は最小限に抑えてください。Use the smallest number of boundaries that satisfy the security requirements for a given situation. 境界の数が増えると、運用とトラブルシューティングが困難になり、複数の境界ポリシーの管理に伴うオーバーヘッドも時間と共に増大します。With more boundaries, operations and troubleshooting can be more difficult, as well as the management overhead involved with managing the multiple boundary policies over time. ただし、境界の数が不足するとリスクが高まります。However, insufficient boundaries increase risk. 適切なバランスを見つけることが重要です。Finding the balance is critical.

66

上の図では、3 つのセキュリティ境界ネットワークの概要を示しています。The preceding figure shows a high-level view of a three security boundary network. 境界は、境界ネットワークとインターネット、Azure フロント エンドとバック エンド プライベート サブネット、および Azure バックエンド サブネットとオンプレスの企業ネットワークの間に存在します。The boundaries are between the perimeter network and the Internet, the Azure front-end and back-end private subnets, and the Azure back-end subnet and the on-premises corporate network.

2. 境界をどこに配置するか2) Where are the boundaries located?

境界の数が決まったら、どこでそれらを実装するかが次の決定ポイントになります。Once the number of boundaries are decided, where to implement them is the next decision point. 一般的には、次の 3 つの選択肢があります。There are generally three choices:

  • インターネット ベースの中間サービスの使用時 (例: クラウドベースの Web アプリケーション ファイアウォール。このドキュメントでは説明しません)Using an Internet-based intermediary service (for example, a cloud-based Web application firewall, which is not discussed in this document)
  • Azure のネイティブ機能またはネットワーク仮想アプライアンスの使用時Using native features and/or network virtual appliances in Azure
  • オンプレミス ネットワーク上の物理デバイスの使用時Using physical devices on the on-premises network

純粋に Azure ネットワークの場合、Azure のネイティブ機能 (例: Azure Load Balancer) または Azure の優れたパートナー エコシステムのネットワーク仮想アプライアンス (例: Check Point ファイアウォール) を選択できます。On purely Azure networks, the options are native Azure features (for example, Azure Load Balancers) or network virtual appliances from the rich partner ecosystem of Azure (for example, Check Point firewalls).

Azure とオンプレミス ネットワークの間に境界が必要な場合は、セキュリティ デバイスを接続の片側 (または両側) に配置できます。If a boundary is needed between Azure and an on-premises network, the security devices can reside on either side of the connection (or both sides). したがって、セキュリティ ギアを配置する場所について決定する必要があります。Thus a decision must be made on the location to place security gear.

上の図では、インターネットと境界ネットワーク間の境界およびフロントエンドとバックエンド間の境界が完全に Azure 内部に含まれており、Azure のネイティブ機能とネットワーク仮想アプライアンスのいずれかになっています。In the previous figure, the Internet-to-perimeter network and the front-to-back-end boundaries are entirely contained within Azure, and must be either native Azure features or network virtual appliances. Azure (バックエンド サブネット) と企業ネットワーク間の境界上のセキュリティ デバイスは、Azure 側にある場合、オンプレミス側にある場合、さらに、両方のデバイスを組み合わせたものである場合もあります。Security devices on the boundary between Azure (back-end subnet) and the corporate network could be either on the Azure side or the on-premises side, or even a combination of devices on both sides. どちらのオプションにも、真剣に検討する必要のある重要な長所と短所があります。There can be significant advantages and disadvantages to either option that must be seriously considered.

たとえば、オンプレミス ネットワーク側で既存の物理的なセキュリティ ギアを使用する場合、新しいギアが必要ないという長所があります。For example, using existing physical security gear on the on-premises network side has the advantage that no new gear is needed. 再構成だけが必要です。It just needs reconfiguration. ただし、セキュリティ ギアで確認できるように、すべてのトラフィックを Azure からオンプレミス ネットワークに戻す必要があるという短所もあります。The disadvantage, however, is that all traffic must come back from Azure to the on-premises network to be seen by the security gear. このため、Azure 間のトラフィックがセキュリティ ポリシー適用のためにオンプレミス ネットワークに強制的に戻される場合、大幅な遅延が発生し、アプリケーションのパフォーマンスとユーザー エクスペリエンスに影響することがあります。Thus Azure-to-Azure traffic could incur significant latency, and affect application performance and user experience, if it was forced back to the on-premises network for security policy enforcement.

3. どのように境界を実装するか3) How are the boundaries implemented?

各セキュリティ境界では、機能の要件が異なる可能性があります (例: 境界ネットワークのインターネット側では IDS とファイアウォール ルールが必要ですが、境界ネットワークとバックエンド サブネットの間には ACL のみが必要)。Each security boundary will likely have different capability requirements (for example, IDS and firewall rules on the Internet side of the perimeter network, but only ACLs between the perimeter network and back-end subnet). 使用するデバイス (またはデバイスの個数) は、シナリオとセキュリティ要件に応じて決定します。Deciding on which device (or how many devices) to use depends on the scenario and security requirements. 次のセクションの例 1、2、3 では、使用可能ないくつかのオプションについて説明します。In the following section, examples 1, 2, and 3 discuss some options that could be used. Azure のネイティブ ネットワーク機能と Azure で使用できるパートナー エコシステムのデバイスを調べると、ほとんどすべてのシナリオを解決できる多種多様なオプションが見つかります。Reviewing the Azure native network features and the devices available in Azure from the partner ecosystem shows the myriad options available to solve virtually any scenario.

実装に関するもう 1 つの重要な決定ポイントとして、Azure とオンプレミス ネットワークの接続方法があります。Another key implementation decision point is how to connect the on-premises network with Azure. Azure 仮想ゲートウェイまたはネットワーク仮想アプライアンスを使用する必要があります。Should you use the Azure virtual gateway or a network virtual appliance? これらのオプションについては、次のセクション (例 4、5、6) でさらに詳しく説明します。These options are discussed in greater detail in the following section (examples 4, 5, and 6).

さらに、Azure 内の仮想ネットワーク間のトラフィックが必要な場合もあります。Additionally, traffic between virtual networks within Azure may be needed. これらのシナリオは、今後追加される予定です。These scenarios will be added in the future.

前の質問に対する答えがわかれば、「 はじめに 」セクションが、特定のシナリオに最も適切な例を見つけるのに役立ちます。Once you know the answers to the previous questions, the Fast Start section can help identify which examples are most appropriate for a given scenario.

例: Azure 仮想ネットワークでセキュリティ境界を構築するExamples: Building security boundaries with Azure virtual networks

例 1: 境界ネットワークを構築し、NSG を使用してアプリケーションを保護するExample 1 Build a perimeter network to help protect applications with NSGs

「はじめに」に戻る | この例の詳細な構築手順Back to Fast start | Detailed build instructions for this example

77

環境の説明Environment description

この例で使用するサブスクリプションには、以下のリソースが含まれています。In this example, there is a subscription that contains the following resources:

  • 単一リソース グループA single resource group
  • 仮想ネットワークと 2 つのサブネット ("FrontEnd" と "BackEnd")A virtual network with two subnets: “FrontEnd” and “BackEnd”
  • 両方のサブネットに適用されるネットワーク セキュリティ グループA Network Security Group that is applied to both subnets
  • アプリケーション Web サーバーを表す Windows サーバー ("IIS01")A Windows server that represents an application web server (“IIS01”)
  • アプリケーション バックエンド サーバーを表す 2 つの Windows サーバー ("AppVM01"、"AppVM02")Two Windows servers that represent application back-end servers (“AppVM01”, “AppVM02”)
  • DNS サーバーを表す Windows サーバー ("DNS01")A Windows server that represents a DNS server (“DNS01”)
  • アプリケーションの Web サーバーに関連付けられているパブリック IPA public IP associated with the application web server

スクリプトと Azure Resource Manager テンプレートについては、詳細な構築手順をご覧ください。For scripts and an Azure Resource Manager template, see the detailed build instructions.

NSG の説明NSG description

この例では、NSG グループを作成し、そこに 6 つのルールを設定します。In this example, an NSG group is built and then loaded with six rules.

ヒント

一般的には、具体的な "Allow" ルールを作成してから、包括的な "Deny" ルールを作成してください。Generally speaking, you should create your specific “Allow” rules first, followed by the more generic “Deny” rules. どのルールが先に評価されるかは、割り当てる優先度によって決まります。The given priority dictates which rules are evaluated first. 具体的なルールが一度適用されたトラフィックに対しては、他のルールは評価されません。Once traffic is found to apply to a specific rule, no further rules are evaluated. NSG ルールは、(サブネットから見て) 受信方向または送信方向のどちらか一方に適用できます。NSG rules can apply in either the inbound or outbound direction (from the perspective of the subnet).

ここでは、受信トラフィックに対して次の内容のルールを作成しています。Declaratively, the following rules are being built for inbound traffic:

  1. 内部的な DNS トラフィック (ポート 53) を許可する。Internal DNS traffic (port 53) is allowed.
  2. インターネットから任意の仮想マシンへの RDP トラフィック (ポート 3389) を許可する。RDP traffic (port 3389) from the Internet to any Virtual Machine is allowed.
  3. インターネットから Web サーバー (IIS01) への HTTP トラフィック (ポート 80) を許可する。HTTP traffic (port 80) from the Internet to web server (IIS01) is allowed.
  4. IIS01 から AppVM1 への任意のトラフィック (すべてのポート) を許可する。Any traffic (all ports) from IIS01 to AppVM1 is allowed.
  5. インターネットから仮想ネットワーク全体 (両方のサブネット) への任意のトラフィック (すべてのポート) を拒否する。Any traffic (all ports) from the Internet to the entire virtual network (both subnets) is denied.
  6. フロントエンド サブネットからバックエンド サブネットへの任意のトラフィック (すべてのポート) を拒否する。Any traffic (all ports) from the front-end subnet to the back-end subnet is denied.

これらのルールが各サブネットにバインドされている状態で、インターネットから Web サーバーへの HTTP 要求が受信された場合、ルール 3 (Allow) とルール 5 (Deny) の両方が該当します。With these rules bound to each subnet, if an HTTP request was inbound from the Internet to the web server, both rules 3 (allow) and 5 (deny) would apply. しかし、ルール 3 の方が優先度が高いので、ルール 3 のみが適用され、ルール 5 は作用しません。But because rule 3 has a higher priority, only it would apply, and rule 5 would not come into play. したがって、Web サーバーへの HTTP 要求は許可されます。Thus the HTTP request would be allowed to the web server. 同じトラフィックが DNS01 サーバーに到達しようとしている場合は、ルール 5 (Deny) が最初に適用されるので、トラフィックはサーバーに到達できません。If that same traffic was trying to reach the DNS01 server, rule 5 (deny) would be the first to apply, and the traffic would not be allowed to pass to the server. フロントエンド サブネットからバックエンド サブネットへの通信は、ルール 6 (Deny) によってブロックされます (ルール 1 とルール 4 で許可されたトラフィックを除く)。Rule 6 (deny) blocks the front-end subnet from talking to the back-end subnet (except for allowed traffic in rules 1 and 4). フロントエンドにある Web アプリケーションのセキュリティが攻撃者によって侵害されたとしても、このルール セットによってバックエンド ネットワークは保護されます。This rule-set protects the back-end network in case an attacker compromises the web application on the front end. バックエンドの "保護された" ネットワークに対する攻撃者のアクセスは (AppVM01 サーバー上で公開されているリソースのみに) 限定されます。The attacker would have limited access to the back-end “protected” network (only to resources exposed on the AppVM01 server).

インターネットへ向かうトラフィックは、既定の送信ルールによって許可されています。There is a default outbound rule that allows traffic out to the Internet. この例では、送信トラフィックを許可していますが、送信ルールに対する変更は一切行っていません。For this example, we’re allowing outbound traffic and not modifying any outbound rules. 両方向のトラフィックをロック ダウンするには、ユーザー定義ルーティングが必要です (例 3 を参照)。To lock down traffic in both directions, user-defined routing is required (see example 3).

まとめConclusion

この例は、バックエンド サブネットを受信トラフィックから分離する方法としては比較的単純な部類に入ります。This example is a relatively simple and straightforward way of isolating the back-end subnet from inbound traffic. 詳細については、詳細な構築手順をご覧ください。For more information, see the detailed build instructions. この手順の内容は次のとおりです。These instructions include:

  • クラシック PowerShell スクリプトを使用してこの境界ネットワークを構築する方法How to build this perimeter network with classic PowerShell scripts.
  • Azure Resource Manager テンプレートを使用してこの境界ネットワークを構築する方法How to build this perimeter network with an Azure Resource Manager template.
  • 各 NSG コマンドの詳細な説明Detailed descriptions of each NSG command.
  • トラフィック フローの詳細なシナリオ (各層でトラフィックを許可または拒否する方法を示します)Detailed traffic flow scenarios, showing how traffic is allowed or denied in each layer.

例 2: 境界ネットワークを構築し、ファイアウォールと NSG を使用してアプリケーションを保護するExample 2 Build a perimeter network to help protect applications with a firewall and NSGs

「はじめに」に戻る | この例の詳細な構築手順Back to Fast start | Detailed build instructions for this example

88

環境の説明Environment description

この例で使用するサブスクリプションには、以下のリソースが含まれています。In this example, there is a subscription that contains the following resources:

  • 単一リソース グループA single resource group
  • 仮想ネットワークと 2 つのサブネット ("FrontEnd" と "BackEnd")A virtual network with two subnets: “FrontEnd” and “BackEnd”
  • 両方のサブネットに適用されるネットワーク セキュリティ グループA Network Security Group that is applied to both subnets
  • フロントエンド サブネットに接続されたネットワーク仮想アプライアンス (この場合はファイアウォール)A network virtual appliance, in this case a firewall, connected to the front-end subnet
  • アプリケーション Web サーバーを表す Windows サーバー ("IIS01")A Windows server that represents an application web server (“IIS01”)
  • アプリケーション バックエンド サーバーを表す 2 つの Windows サーバー ("AppVM01"、"AppVM02")Two Windows servers that represent application back-end servers (“AppVM01”, “AppVM02”)
  • DNS サーバーを表す Windows サーバー ("DNS01")A Windows server that represents a DNS server (“DNS01”)

スクリプトと Azure Resource Manager テンプレートについては、詳細な構築手順をご覧ください。For scripts and an Azure Resource Manager template, see the detailed build instructions.

NSG の説明NSG description

この例では、NSG グループを作成し、そこに 6 つのルールを設定します。In this example, an NSG group is built and then loaded with six rules.

ヒント

一般的には、具体的な "Allow" ルールを作成してから、包括的な "Deny" ルールを作成してください。Generally speaking, you should create your specific “Allow” rules first, followed by the more generic “Deny” rules. どのルールが先に評価されるかは、割り当てる優先度によって決まります。The given priority dictates which rules are evaluated first. 具体的なルールが一度適用されたトラフィックに対しては、他のルールは評価されません。Once traffic is found to apply to a specific rule, no further rules are evaluated. NSG ルールは、(サブネットから見て) 受信方向または送信方向のどちらか一方に適用できます。NSG rules can apply in either the inbound or outbound direction (from the perspective of the subnet).

ここでは、受信トラフィックに対して次の内容のルールを作成しています。Declaratively, the following rules are being built for inbound traffic:

  1. 内部的な DNS トラフィック (ポート 53) を許可する。Internal DNS traffic (port 53) is allowed.
  2. インターネットから任意の仮想マシンへの RDP トラフィック (ポート 3389) を許可する。RDP traffic (port 3389) from the Internet to any Virtual Machine is allowed.
  3. ネットワーク仮想アプライアンス (ファイアウォール) へのすべてのインターネット トラフィック (すべてのポート) を許可する。Any Internet traffic (all ports) to the network virtual appliance (firewall) is allowed.
  4. IIS01 から AppVM1 への任意のトラフィック (すべてのポート) を許可する。Any traffic (all ports) from IIS01 to AppVM1 is allowed.
  5. インターネットから仮想ネットワーク全体 (両方のサブネット) への任意のトラフィック (すべてのポート) を拒否する。Any traffic (all ports) from the Internet to the entire virtual network (both subnets) is denied.
  6. フロントエンド サブネットからバックエンド サブネットへの任意のトラフィック (すべてのポート) を拒否する。Any traffic (all ports) from the front-end subnet to the back-end subnet is denied.

これらのルールが各サブネットにバインドされている状態で、インターネットからファイアウォールへの HTTP 要求が受信された場合、ルール 3 (Allow) とルール 5 (Deny) の両方が該当します。With these rules bound to each subnet, if an HTTP request was inbound from the Internet to the firewall, both rules 3 (allow) and 5 (deny) would apply. しかし、ルール 3 の方が優先度が高いので、ルール 3 のみが適用され、ルール 5 は作用しません。But because rule 3 has a higher priority, only it would apply, and rule 5 would not come into play. したがって、ファイアウォールへの HTTP 要求は許可されます。Thus the HTTP request would be allowed to the firewall. 同じトラフィックが IIS01 サーバーに到達しようとしている場合は、そのサーバーがフロントエンド サブネット上にあったとしても、ルール 5 (Deny) が適用されるので、トラフィックはサーバーに到達できません。If that same traffic was trying to reach the IIS01 server, even though it’s on the front-end subnet, rule 5 (deny) would apply, and the traffic would not be allowed to pass to the server. フロントエンド サブネットからバックエンド サブネットへの通信は、ルール 6 (Deny) によってブロックされます (ルール 1 とルール 4 で許可されたトラフィックを除く)。Rule 6 (deny) blocks the front-end subnet from talking to the back-end subnet (except for allowed traffic in rules 1 and 4). フロントエンドにある Web アプリケーションのセキュリティが攻撃者によって侵害されたとしても、このルール セットによってバックエンド ネットワークは保護されます。This rule-set protects the back-end network in case an attacker compromises the web application on the front end. バックエンドの "保護された" ネットワークに対する攻撃者のアクセスは (AppVM01 サーバー上で公開されているリソースのみに) 限定されます。The attacker would have limited access to the back-end “protected” network (only to resources exposed on the AppVM01 server).

インターネットへ向かうトラフィックは、既定の送信ルールによって許可されています。There is a default outbound rule that allows traffic out to the Internet. この例では、送信トラフィックを許可していますが、送信ルールに対する変更は一切行っていません。For this example, we’re allowing outbound traffic and not modifying any outbound rules. 両方向のトラフィックをロック ダウンするには、ユーザー定義ルーティングが必要です (例 3 を参照)。To lock down traffic in both directions, user-defined routing is required (see example 3).

ファイアウォール ルールの説明Firewall rule description

ファイアウォールには、転送ルールを作成する必要があります。On the firewall, forwarding rules should be created. この例でルーティングするのは、インターネットからファイアウォールを介して Web サーバーに到達する受信トラフィックだけであるため、必要なネットワーク アドレス転送 (NAT) ルールは 1 つだけです。Since this example only routes Internet traffic in-bound to the firewall and then to the web server, only one forwarding network address translation (NAT) rule is needed.

この転送ルールでは、HTTP のポート 80 または HTTPS のポート 443 を宛先としてファイアウォールに到達したすべての受信元アドレスを受け入れます。The forwarding rule accepts any inbound source address that hits the firewall trying to reach HTTP (port 80 or 443 for HTTPS). 転送ルールは、ファイアウォールのローカル インターフェイスから送出され、IP アドレス 10.0.1.5 の Web サーバーにリダイレクトされます。It's sent out of the firewall’s local interface and redirected to the web server with the IP Address of 10.0.1.5.

まとめConclusion

この例は、アプリケーションをファイアウォールで保護したり、バックエンド サブネットを受信トラフィックから切り離したりする方法としては比較的わかりやすい部類に入ります。This example is a relatively straightforward way of protecting your application with a firewall and isolating the back-end subnet from inbound traffic. 詳細については、詳細な構築手順をご覧ください。For more information, see the detailed build instructions. この手順の内容は次のとおりです。These instructions include:

  • クラシック PowerShell スクリプトを使用してこの境界ネットワークを構築する方法How to build this perimeter network with classic PowerShell scripts.
  • Azure Resource Manager テンプレートを使用してこの例を構築する方法How to build this example with an Azure Resource Manager template.
  • 各 NSG コマンドとファイアウォール ルールの詳細な説明Detailed descriptions of each NSG command and firewall rule.
  • トラフィック フローの詳細なシナリオ (各層でトラフィックを許可または拒否する方法を示します)Detailed traffic flow scenarios, showing how traffic is allowed or denied in each layer.

例 3: 境界ネットワークを構築し、ファイアウォール、UDR、および NSG を使用してネットワークを保護するExample 3 Build a perimeter network to help protect networks with a firewall and UDR and NSG

「はじめに」に戻る | この例の詳細な構築手順Back to Fast start | Detailed build instructions for this example

99

環境の説明Environment description

この例で使用するサブスクリプションには、以下のリソースが含まれています。In this example, there is a subscription that contains the following resources:

  • 単一リソース グループA single resource group
  • 3 つのサブネット ("SecNet"、"FrontEnd"、"BackEnd") を含む仮想ネットワークA virtual network with three subnets: “SecNet”, “FrontEnd”, and “BackEnd”
  • SecNet サブネットに接続されたネットワーク仮想アプライアンス (この場合はファイアウォール)A network virtual appliance, in this case a firewall, connected to the SecNet subnet
  • アプリケーション Web サーバーを表す Windows サーバー ("IIS01")A Windows server that represents an application web server (“IIS01”)
  • アプリケーション バックエンド サーバーを表す 2 つの Windows サーバー ("AppVM01"、"AppVM02")Two Windows servers that represent application back-end servers (“AppVM01”, “AppVM02”)
  • DNS サーバーを表す Windows サーバー ("DNS01")A Windows server that represents a DNS server (“DNS01”)

スクリプトと Azure Resource Manager テンプレートについては、詳細な構築手順をご覧ください。For scripts and an Azure Resource Manager template, see the detailed build instructions.

UDR の説明UDR description

既定では、次のシステム ルートが定義されています。By default, the following system routes are defined as:

    Effective routes :
     Address Prefix    Next hop type    Next hop IP address Status   Source     
     --------------    -------------    ------------------- ------   ------     
     {10.0.0.0/16}     VNETLocal                            Active   Default    
     {0.0.0.0/0}       Internet                             Active   Default    
     {10.0.0.0/8}      Null                                 Active   Default    
     {100.64.0.0/10}   Null                                 Active   Default    
     {172.16.0.0/12}   Null                                 Active   Default    
     {192.168.0.0/16}  Null                                 Active   Default

VNETLocal は、必ず 1 つ以上定義されるアドレス プレフィックスであり、特定のネットワークの仮想ネットワークを構成します (つまり、特定の仮想ネットワークがそれぞれどのように定義されているかによって変わります)。The VNETLocal is always one or more defined address prefixes that make up the virtual network for that specific network (that is, it changes from virtual network to virtual network, depending on how each specific virtual network is defined). その他のシステム ルートは静的ルートで、表に示すように既定値となっています。The remaining system routes are static and default as indicated in the table.

この例では、フロントエンドとバックエンドのサブネットに対して 1 つずつ、2 つのルーティング テーブルが作成されます。In this example, two routing tables are created, one each for the front-end and back-end subnets. 各サブネットに適した静的ルートをそれぞれのテーブルに読み込みます。Each table is loaded with static routes appropriate for the given subnet. この例では、すべてのトラフィック (0.0.0.0/0) をファイアウォール (次ホップ = 仮想アプライアンスの IP アドレス) 経由で送信する 3 つのルートが各テーブルに存在します。In this example, each table has three routes that direct all traffic (0.0.0.0/0) through the firewall (Next hop = Virtual Appliance IP address):

  1. ローカル サブネット トラフィック。次ホップは定義されず、ローカル サブネット トラフィックはファイアウォールをバイパスすることができます。Local subnet traffic with no Next Hop defined to allow local subnet traffic to bypass the firewall.
  2. 次ホップがファイアウォールとして定義されている仮想ネットワーク トラフィック。Virtual network traffic with a Next Hop defined as firewall. この次ホップでは、ローカル仮想ネットワーク トラフィックによる直接ルーティングを許可する既定のルールは上書きされます。This next hop overrides the default rule that allows local virtual network traffic to route directly.
  3. その他すべてのトラフィック (0/0)。次ホップはファイアウォールとして定義されます。All remaining traffic (0/0) with a Next Hop defined as the firewall.

ヒント

UDR にローカル サブネットのエントリがないと、ローカル サブネットの通信が切断されます。Not having the local subnet entry in the UDR breaks local subnet communications.

  • この例で重要なのは、VNETLocal を指す 10.0.1.0/24 です。In our example, 10.0.1.0/24 pointing to VNETLocal is critical! これがないと、Web サーバー (10.0.1.4) から別のローカル サーバー (たとえば) 10.0.1.25 に送信されたパケットは NVA に送信され、失敗してしまいます。Without it, packet leaving the Web Server (10.0.1.4) destined to another local server (for example) 10.0.1.25 will fail as they will be sent to the NVA. NVA はこれをサブネットに送信し、サブネットは NVA に再送するので、無限ループとなります。The NVA will send it to the subnet, and the subnet will resend it to the NVA in an infinite loop.
  • 個別のサブネットに接続されている複数の NIC を備えるアプライアンスでは、ルーティング ループに陥る可能性が高くなります。多くの場合、このようなアプライアンスには、従来のオンプレミス アプライアンスが該当します。The chances of a routing loop are typically higher on appliances with multiple NICs that are connected to separate subnets, which is often of traditional, on-premises appliances.

ルーティング テーブルは、作成されたら、対応するサブネットにバインドされる必要があります。Once the routing tables are created, they must be bound to their subnets. フロントエンド サブネット ルーティング テーブルは、作成されてサブネットにバインドされると、次の出力のようになります。The front-end subnet routing table, once created and bound to the subnet, would look like this output:

    Effective routes :
     Address Prefix    Next hop type    Next hop IP address Status   Source     
     --------------    -------------    ------------------- ------   ------     
     {10.0.1.0/24}     VNETLocal                            Active
     {10.0.0.0/16}     VirtualAppliance 10.0.0.4            Active    
     {0.0.0.0/0}       VirtualAppliance 10.0.0.4            Active

注意

ExpressRoute circuit が接続されているゲートウェイ サブネットに UDR を適用できるようになりました。UDR can now be applied to the gateway subnet on which the ExpressRoute circuit is connected.

ExpressRoute またはサイト間ネットワークを使用した境界ネットワークを有効にする方法の例については、例 3 と 4 で説明します。Examples of how to enable your perimeter network with ExpressRoute or site-to-site networking are shown in examples 3 and 4.

IP 転送の説明IP Forwarding description

IP 転送は、UDR と併用される機能です。IP Forwarding is a companion feature to UDR. IP 転送とは、実際には自分自身宛てではないトラフィックを受信し、それを最終的な宛先に転送することができる、仮想アプライアンス上の設定です。IP Forwarding is a setting on a virtual appliance that allows it to receive traffic not specifically addressed to the appliance, and then forward that traffic to its ultimate destination.

たとえば、AppVM01 が DNS01 サーバーに要求を行う場合、UDR はこのトラフィックをファイアウォールにルーティングします。For example, if AppVM01 makes a request to the DNS01 server, UDR would route this traffic to the firewall. IP 転送が有効になっている場合、DNS01 (10.0.2.4) 宛てのトラフィックはまずアプライアンス (10.0.0.4) で受信されて、最終的な宛先 (10.0.2.4) に転送されます。With IP Forwarding enabled, the traffic for the DNS01 destination (10.0.2.4) is accepted by the appliance (10.0.0.4) and then forwarded to its ultimate destination (10.0.2.4). ファイアウォールで IP 転送が無効になっている場合、ルート テーブルに次ホップとしてファイアウォールが指定されていても、アプライアンスは、そのトラフィックを受け付けません。Without IP Forwarding enabled on the firewall, traffic would not be accepted by the appliance even though the route table has the firewall as the next hop. 仮想アプライアンスを使用するには、UDR と併せて IP 転送も忘れずに有効にすることが重要です。To use a virtual appliance, it’s critical to remember to enable IP Forwarding along with UDR.

NSG の説明NSG description

この例では、NSG グループを作成し、そこに単一のルールを設定します。In this example, an NSG group is built and then loaded with a single rule. このグループは、(SecNet を除いた) フロントエンドとバックエンドのサブネットにのみバインドします。This group is then bound only to the front-end and back-end subnets (not the SecNet). ここで作成しているルールの内容は次のとおりです。Declaratively the following rule is being built:

  • インターネットから仮想ネットワーク全体 (すべてのサブネット) への任意のトラフィック (すべてのポート) を拒否する。Any traffic (all ports) from the Internet to the entire virtual network (all subnets) is denied.

この例では NSG が使用されていますが、その主な役割は、手動構成のミスに対する第 2 の防御層としての機能です。Although NSGs are used in this example, its main purpose is as a secondary layer of defense against manual misconfiguration. その目的は、フロントエンド サブネットまたはバックエンド サブネットへのインターネットからの受信トラフィックをすべてブロックすることです。The goal is to block all inbound traffic from the Internet to either the front-end or back-end subnets. 必ず SecNet サブネットを介してファイアウォールに (その後必要に応じてフロントエンド サブネットまたはバックエンド サブネットに) トラフィックを流す必要があります。Traffic should only flow through the SecNet subnet to the firewall (and then, if appropriate, on to the front-end or back-end subnets). 加えて UDR ルールが設定されているので、万一フロントエンド サブネットまたはバックエンド サブネットにうまく到達できたトラフィックも (UDR が設定されているために) すべてファイアウォールへと送信させることができます。Plus, with the UDR rules in place, any traffic that did make it into the front-end or back-end subnets would be directed out to the firewall (thanks to UDR). ファイアウォールは、そのようなトラフィックを非対称フローと見なし、その送信トラフィックは破棄されます。The firewall would see this traffic as an asymmetric flow and would drop the outbound traffic. つまり、サブネットを保護するセキュリティは次の 3 つの層で構成されます。Thus there are three layers of security protecting the subnets:

  • FrontEnd NIC または BackEnd NIC にパブリック IP アドレスがない。No Public IP addresses on any FrontEnd or BackEnd NICs.
  • インターネットからのトラフィックを NSG で拒否する。NSGs denying traffic from the Internet.
  • 非対称トラフィックをファイアウォールで破棄するThe firewall dropping asymmetric traffic.

この例の NSG に存在するルールは 1 つだけである点に注目してください。セキュリティ サブネットを含め、仮想ネットワーク全体でインターネット トラフィックを拒否する、というルールが 1 つあるだけです。One interesting point regarding the NSG in this example is that it contains only one rule, which is to deny Internet traffic to the entire virtual network, including the Security subnet. しかし、この NSG がバインドされるのはフロントエンド サブネットとバックエンド サブネットだけです。セキュリティ サブネットに入ってくるトラフィックに対してはルールの処理は適用されません。However, since the NSG is only bound to the front-end and back-end subnets, the rule isn’t processed on traffic inbound to the Security subnet. その結果、トラフィックはセキュリティ サブネットに到達します。As a result, traffic flows to the Security subnet.

ファイアウォール規則Firewall rules

ファイアウォールには、転送ルールを作成する必要があります。On the firewall, forwarding rules should be created. 受信トラフィック、送信トラフィック、仮想ネットワーク間トラフィックをすべてブロックまたは転送する役割を果たすファイアウォールには、多くのファイアウォール ルールが必要です。Since the firewall is blocking or forwarding all inbound, outbound, and intra-virtual network traffic, many firewall rules are needed. また、すべての受信トラフィックは、セキュリティ サービスのパブリック IP アドレス (の各種ポート) に到達し、そこでファイアウォールの処理が適用されます。Also, all inbound traffic hits the Security Service public IP address (on different ports), to be processed by the firewall. 手戻り作業をなくすために、あらかじめ論理フローを図式化したうえでサブネットとファイアウォール ルールを設定することをお勧めします。A best practice is to diagram the logical flows before setting up the subnets and firewall rules, to avoid rework later. 次の図では、この例で使用するファイアウォール ルールを論理的に示しています。The following figure is a logical view of the firewall rules for this example:

1010

注意

使用するネットワーク仮想アプライアンスによって管理ポートは異なります。Based on the Network Virtual Appliance used, the management ports vary. ここでは、ポート 22、801、807 が使用されている Barracuda NextGen Firewall を例に説明しています。In this example, a Barracuda NextGen Firewall is referenced, which uses ports 22, 801, and 807. ご使用のデバイスの管理に使用される実際のポートについては、アプライアンス製造元のマニュアルを参照してください。Consult the appliance vendor documentation to find the exact ports used for management of the device being used.

ファイアウォール ルールの説明Firewall rules description

上の論理図ではセキュリティのサブネットが記載されていませんが、これはファイアウォールがそのサブネットの唯一のリソースであるためです。In the preceding logical diagram, the security subnet is not shown because the firewall is the only resource on that subnet. この図にはファイアウォール ルールが示されており、実際の経路を指定するのではなく論理的にトラフィック フローを許可または拒否していることがわかります。The diagram is showing the firewall rules and how they logically allow or deny traffic flows, not the actual routed path. また、RDP トラフィック用に選択した外部ポートは、他のトラフィックよりも大きな番号範囲 (8014 ~ 8026) を使用しています。また、見やすくするために、外部ポート番号は、ローカル IP アドレスの最後の 2 オクテットと大まかに揃える形で選択しました (たとえば、ローカル サーバー アドレス 10.0.1.4 は外部ポート 8014 に関連付けられています)。Also, the external ports selected for the RDP traffic are higher ranged ports (8014 – 8026) and were selected to loosely align with the last two octets of the local IP address for easier readability (for example, local server address 10.0.1.4 is associated with external port 8014). ただし、競合さえしなければ、もっと大きなポート番号を使用してもかまいません。Any higher non-conflicting ports, however, could be used.

この例では、次の 7 種類のルールが必要です。For this example, we need seven types of rules:

  • 外部ルール (受信トラフィック用):External rules (for inbound traffic):
    1. ファイアウォール管理ルール: ネットワーク仮想アプライアンスの管理ポート宛てのトラフィックを通過させるための App Redirect ルールです。Firewall management rule: This App Redirect rule allows traffic to pass to the management ports of the network virtual appliance.
    2. RDP ルール (Windows Server ごと): 個々のサーバーを RDP 経由で管理するためには、この 4 つのルール (サーバー 1 台につき 1 つ) が必要となります。RDP rules (for each Windows server): These four rules (one for each server) allow management of the individual servers via RDP. 使用するネットワーク仮想アプライアンスの機能によっては、これら 4 つの RDP ルールを 1 つにまとめることもできます。The four RDP rules could also be collapsed into one rule, depending on the capabilities of the network virtual appliance being used.
    3. アプリケーション トラフィック ルール: フロント エンド Web トラフィック用とバックエンド トラフィック用 (Web サーバーからデータ層など) の 2 つのアプリケーション トラフィック ルールがあります。Application traffic rules: There are two of these rules, the first for the front-end web traffic, and the second for the back-end traffic (for example, web server to data tier). これらのルールの構成は、(サーバーが置かれている) ネットワーク アーキテクチャとトラフィック フロー (トラフィック フローの方向と使用ポート) によって異なります。The configuration of these rules depends on the network architecture (where your servers are placed) and traffic flows (which direction the traffic flows, and which ports are used).
      • 実際のアプリケーション トラフィックは、1 つ目のルールによってアプリケーション サーバーに到達できます。The first rule allows the actual application traffic to reach the application server. 他のルールがセキュリティや管理を目的としているのに対し、アプリケーション トラフィック ルールの目的は、外部のユーザーまたはサービスがアプリケーションにアクセスできるようにすることです。While the other rules allow for security and management, application traffic rules are what allow external users or services to access the applications. この例では、1 台の Web サーバー (ポート 80) があります。For this example, there is a single web server on port 80. このため、単一のファイアウォール アプリケーション ルールで、外部 IP 宛ての受信トラフィックを Web サーバーの内部 IP アドレスにリダイレクトします。Thus a single firewall application rule redirects inbound traffic to the external IP, to the web servers internal IP address. リダイレクトされたトラフィック セッションは、NAT を介して内部サーバーに変換されます。The redirected traffic session would be translated via NAT to the internal server.
      • 2 つ目のルールはバック エンド ルールです。任意のポートを介した Web サーバーから AppVM01 サーバー (ただし、AppVM02 は不可) への通信を許可します。The second rule is the back-end rule to allow the web server to talk to the AppVM01 server (but not AppVM02) via any port.
  • 内部ルール (仮想ネットワーク間のトラフィック用)Internal rules (for intra-virtual network traffic)
    1. インターネットへの送信ルール: 任意のネットワークから特定のネットワークへのトラフィックの通過を許可するルールです。Outbound to Internet rule: This rule allows traffic from any network to pass to the selected networks. 通常、ファイアウォールにはこのルールが、既定のルールとして (ただし無効状態で) あらかじめ設定されています。This rule is usually a default rule already on the firewall, but in a disabled state. この例では、このルールを有効にする必要があります。This rule should be enabled for this example.
    2. DNS ルール: DNS (ポート 53) のトラフィックのみに DNS サーバーへの通過を許可するルールです。DNS rule: This rule allows only DNS (port 53) traffic to pass to the DNS server. この環境では、フロントエンドからバックエンドへのトラフィックの大部分がブロックされます。For this environment, most traffic from the front end to the back end is blocked. このルールによって、任意のローカル サブネットからの DNS を明示的に許可します。This rule specifically allows DNS from any local subnet.
    3. サブネット間ルール: バックエンド サブネット上の任意のサーバーからフロントエンド サブネット上の任意のサーバーへの接続を許可するルールです (ただしその逆は不可)。Subnet to subnet rule: This rule is to allow any server on the back-end subnet to connect to any server on the front-end subnet (but not the reverse).
  • フェールセーフ ルール (上記のルールに該当しないトラフィック用):Fail-safe rule (for traffic that doesn’t meet any of the previous):
    1. 全トラフィック拒否ルール: この拒否ルールは (優先度の観点から) 必ず最後に置く必要があります。先行するいずれのルールにも該当しなかったトラフィック フローが、このルールによって破棄されます。Deny all traffic rule: This deny rule should always be the final rule (in terms of priority), and as such if a traffic flow fails to match any of the preceding rules it is dropped by this rule. このルールは既定のルールであり、通常は設定済みでアクティブになっています。This rule is a default rule and usually in-place and active. 通常、この規則に変更は必要ありません。No modifications are usually needed to this rule.

ヒント

この例では、わかりやすくするために 2 つ目のアプリケーション トラフィック ルールで任意のポートを許可しています。On the second application traffic rule, to simplify this example, any port is allowed. 実際のシナリオでは、ポートとアドレス範囲をできるだけ具体的に指定して、このルールに対する攻撃対象領域を小さくする必要があります。In a real scenario, the most specific port and address ranges should be used to reduce the attack surface of this rule.

以上のルールを作成したら、各ルールの優先度を再確認し、トラフィックの許可または拒否が意図したとおりになっていることを確かめてください。Once the previous rules are created, it’s important to review the priority of each rule to ensure traffic is allowed or denied as desired. この例では、各ルールに優先順位が割り当てられています。For this example, the rules are in priority order.

まとめConclusion

この例は、ネットワークを保護および分離する方法としては、前の例より複雑ですが完成度は高くなっています。This example is a more complex but complete way of protecting and isolating the network than the previous examples. この設計では、両方向のトラフィックを監視できます。(Example 2 protects just the application, and Example 1 just isolates subnets). また、受信アプリケーション サーバーを保護するだけでなく、このネットワーク上のすべてのサーバーにネットワーク セキュリティ ポリシーを適用します。This design allows for monitoring traffic in both directions, and protects not just the inbound application server but enforces network security policy for all servers on this network. さらに、使用されるアプライアンスに応じて、トラフィックの完全な監査と対応を実現できます。Also, depending on the appliance used, full traffic auditing and awareness can be achieved. 詳細については、詳細な構築手順をご覧ください。For more information, see the detailed build instructions. この手順の内容は次のとおりです。These instructions include:

  • クラシック PowerShell スクリプトを使用してこの例の境界ネットワークを構築する方法How to build this example perimeter network with classic PowerShell scripts.
  • Azure Resource Manager テンプレートを使用してこの例を構築する方法How to build this example with an Azure Resource Manager template.
  • 各 UDR、NSG コマンド、ファイアウォール ルールの詳細な説明Detailed descriptions of each UDR, NSG command, and firewall rule.
  • トラフィック フローの詳細なシナリオ (各層でトラフィックを許可または拒否する方法を示します)Detailed traffic flow scenarios, showing how traffic is allowed or denied in each layer.

例 4 - サイト間の仮想アプライアンス VPN を使用してハイブリッド接続を追加するExample 4 Add a hybrid connection with a site-to-site, virtual appliance VPN

「はじめに」に戻る | 詳細な構築手順 (近日公開予定)Back to Fast start | Detailed build instructions available soon

1111

環境の説明Environment description

ネットワーク仮想アプライアンス (NVA) を使用するハイブリッド ネットワークは、例 1、2、3 で説明したどの境界ネットワークの種類にも追加できます。Hybrid networking using a network virtual appliance (NVA) can be added to any of the perimeter network types described in examples 1, 2, or 3.

上の図に示すように、オンプレミス ネットワークを NVA を介して Azure 仮想ネットワークに接続する場合は、インターネット経由 (サイト間) の VPN 接続を使用します。As shown in the previous figure, a VPN connection over the Internet (site-to-site) is used to connect an on-premises network to an Azure virtual network via an NVA.

注意

Azure のパブリック ピアリング オプションを有効にした状態で ExpressRoute を使用する場合は、静的ルートを作成する必要があります。If you use ExpressRoute with the Azure Public Peering option enabled, a static route should be created. この静的ルートにより、ExpressRoute 接続を介さずに、企業のインターネットの外へと NVA VPN の IP アドレスにルーティングされます。This static route should route to the NVA VPN IP address out your corporate Internet and not via the ExpressRoute connection. ExpressRoute の Azure パブリック ピアリング オプションで必要な NAT により、VPN セッションが中断される可能性があります。The NAT required on the ExpressRoute Azure Public Peering option can break the VPN session.

VPN が確立されると、NVA はすべてのネットワークとサブネットの中心的な "ハブ" になります。Once the VPN is in place, the NVA becomes the central hub for all networks and subnets. ファイアウォールの転送ルールにより、許可するトラフィック フロー、NAT を介して変換するトラフィック フロー、リダイレクトするトラフィック フロー、削除するトラフィック フロー (オンプレミス ネットワークと Azure の間のトラフィック フローの場合でも) が決まります。The firewall forwarding rules determine which traffic flows are allowed, are translated via NAT, are redirected, or are dropped (even for traffic flows between the on-premises network and Azure).

トラフィック フローは、具体的な使用事例に応じてこの設計パターンで最適化されることもあれば、状態が低下することもあるため、慎重に検討する必要があります。Traffic flows should be considered carefully, as they can be optimized or degraded by this design pattern, depending on the specific use case.

例 3 で構築した環境を使用した後にサイト間 VPN のハイブリッド ネットワーク接続を追加すると、次のような設計になります。Using the environment built in example 3, and then adding a site-to-site VPN hybrid network connection, produces the following design:

1212

オンプレミスのルーター、または VPN 用の NVA と互換性のあるその他のネットワーク デバイスが VPN クライアントになります。The on-premises router, or any other network device that is compatible with your NVA for VPN, would be the VPN client. この物理デバイスの役割は、NVA で VPN 接続を開始して維持することです。This physical device would be responsible for initiating and maintaining the VPN connection with your NVA.

論理的な観点から、NVA にとってのネットワークは、4 つの独立した "セキュリティ ゾーン" で、NVA のルールがこれらのゾーン間のトラフィックに対する司令塔のように見えます。Logically to the NVA, the network looks like four separate “security zones” with the rules on the NVA being the primary director of traffic between these zones:

1313

まとめConclusion

サイト間 VPN のハイブリッド ネットワーク接続を Azure 仮想ネットワークに追加すると、安全な方法でオンプレミス ネットワークを Azure に拡張できます。The addition of a site-to-site VPN hybrid network connection to an Azure virtual network can extend the on-premises network into Azure in a secure manner. VPN 接続を使用している場合は、トラフィックが暗号化され、インターネット経由でルーティングされます。In using a VPN connection, your traffic is encrypted and routes via the Internet. この例の NVA は、セキュリティ ポリシーの適用と管理を一元化しています。The NVA in this example provides a central location to enforce and manage the security policy. 詳細については、詳細な構築手順をご覧ください (近日公開予定)。For more information, see the detailed build instructions (forthcoming). この手順の内容は次のとおりです。These instructions include:

  • PowerShell スクリプトを使用してこの例の境界ネットワークを構築する方法How to build this example perimeter network with PowerShell scripts.
  • Azure Resource Manager テンプレートを使用してこの例を構築する方法How to build this example with an Azure Resource Manager template.
  • トラフィック フローの詳細なシナリオ (この設計によるトラフィック フローを示します)Detailed traffic flow scenarios, showing how traffic flows through this design.

例 5: サイト間の Azure VPN ゲートウェイを使用してハイブリッド接続を追加するExample 5 Add a hybrid connection with a site-to-site, Azure VPN gateway

「はじめに」に戻る | 詳細な構築手順 (近日公開予定)Back to Fast start | Detailed build instructions available soon

1414

環境の説明Environment description

Azure VPN ゲートウェイを使用するハイブリッド ネットワークは、例 1 または 2 で説明した境界ネットワークの種類に追加できます。Hybrid networking using an Azure VPN gateway can be added to either perimeter network type described in examples 1 or 2.

上の図に示すように、オンプレミス ネットワークを Azure VPN ゲートウェイを介して Azure 仮想ネットワークに接続する場合は、インターネット経由 (サイト間) の VPN 接続を使用します。As shown in the preceding figure, a VPN connection over the Internet (site-to-site) is used to connect an on-premises network to an Azure virtual network via an Azure VPN gateway.

注意

Azure のパブリック ピアリング オプションを有効にした状態で ExpressRoute を使用する場合は、静的ルートを作成する必要があります。If you use ExpressRoute with the Azure Public Peering option enabled, a static route should be created. この静的ルートにより、ExpressRoute WAN を介さずに、企業のインターネットの外へと NVA VPN の IP アドレスにルーティングされます。This static route should route to the NVA VPN IP address out your corporate Internet and not via the ExpressRoute WAN. ExpressRoute の Azure パブリック ピアリング オプションで必要な NAT により、VPN セッションが中断される可能性があります。The NAT required on the ExpressRoute Azure Public Peering option can break the VPN session.

次の図は、この例の 2 つのネットワーク エッジを示しています。The following figure shows the two network edges in this example. 1 つ目のエッジでは、Azure 内のネットワークのトラフィック フローおよび Azure とインターネット間のトラフィック フローを NVA と NSG が制御します。On the first edge, the NVA and NSGs control traffic flows for intra-Azure networks and between Azure and the Internet. 2 つ目のエッジは Azure VPN ゲートウェイで、オンプレミスと Azure の間で切り離されて分離したネットワーク エッジです。The second edge is the Azure VPN gateway, which is a separate and isolated network edge between on-premises and Azure.

トラフィック フローは、具体的な使用事例に応じてこの設計パターンで最適化されることもあれば、状態が低下することもあるため、慎重に検討する必要があります。Traffic flows should be considered carefully, as they can be optimized or degraded by this design pattern, depending on the specific use case.

例 1 で構築した環境を使用した後にサイト間 VPN のハイブリッド ネットワーク接続を追加すると、次のような設計になります。Using the environment built in example 1, and then adding a site-to-site VPN hybrid network connection, produces the following design:

1515

まとめConclusion

サイト間 VPN のハイブリッド ネットワーク接続を Azure 仮想ネットワークに追加すると、安全な方法でオンプレミス ネットワークを Azure に拡張できます。The addition of a site-to-site VPN hybrid network connection to an Azure virtual network can extend the on-premises network into Azure in a secure manner. ネイティブの Azure VPN ゲートウェイを使用する場合、トラフィックは IPSec によって暗号化され、インターネット経由でルーティングされます。Using the native Azure VPN gateway, your traffic is IPSec encrypted and routes via the Internet. また、Azure VPN ゲートウェイを使用すると、よりコストが低いオプションを利用できます (サード パーティ製の NVA と同様に、追加のライセンス コストはありません)。Also, using the Azure VPN gateway can provide a lower-cost option (no additional licensing cost as with third-party NVAs). NVA が使用されていない例 1 では、このオプションが最も経済的です。This option is most economical in example 1, where no NVA is used. 詳細については、詳細な構築手順をご覧ください (近日公開予定)。For more information, see the detailed build instructions (forthcoming). この手順の内容は次のとおりです。These instructions include:

  • PowerShell スクリプトを使用してこの例の境界ネットワークを構築する方法How to build this example perimeter network with PowerShell scripts.
  • Azure Resource Manager テンプレートを使用してこの例を構築する方法How to build this example with an Azure Resource Manager template.
  • トラフィック フローの詳細なシナリオ (この設計によるトラフィック フローを示します)Detailed traffic flow scenarios, showing how traffic flows through this design.

例 6: ExpressRoute を使用してハイブリッド接続を追加するExample 6 Add a hybrid connection with ExpressRoute

「はじめに」に戻る | 詳細な構築手順 (近日公開予定)Back to Fast start | Detailed build instructions available soon

1616

環境の説明Environment description

ExpressRoute のプライベート ピアリング接続を使用するハイブリッド ネットワークは、例 1 または 2 で説明したいずれかの境界ネットワークの種類に追加できます。Hybrid networking using an ExpressRoute private peering connection can be added to either perimeter network type described in examples 1 or 2.

上の図に示すように、ExpressRoute のプライベート ピアリングでは、オンプレミス ネットワークと Azure 仮想ネットワークが直接接続されています。As shown in the preceding figure, ExpressRoute private peering provides a direct connection between your on-premises network and the Azure virtual network. トラフィックは、サービス プロバイダーのネットワークと Microsoft Azure のネットワークを通過するだけで、インターネットに到達することはありません。Traffic transits only the service provider network and the Microsoft Azure network, never touching the Internet.

ヒント

ExpressRoute を使用すると、企業のネットワーク トラフィックはインターネットから切断されたままとなります。Using ExpressRoute keeps corporate network traffic off the Internet. ExpressRoute プロバイダーのサービス レベル アグリーメントも考慮されます。It also allows for service level agreements from your ExpressRoute provider. ExpressRoute を使用する場合、Azure ゲートウェイでは最大 10 Gbps のスループットを実現できるのに対し、サイト間 VPN を使用する場合は、Azure ゲートウェイの最大スループットは 200 Mbps になります。The Azure Gateway can pass up to 10 Gbps with ExpressRoute, whereas with site-to-site VPNs, the Azure Gateway maximum throughput is 200 Mbps.

次の図のように、このオプションを使用すると、環境には 2 つのネットワーク エッジが用意されます。As seen in the following diagram, with this option the environment now has two network edges. NVA と NSG は Azure 内のネットワークのトラフィック フローおよび Azure とインターネット間のトラフィック フローを制御しますが、ゲートウェイは、オンプレミスと Azure の間で切り離されて分離したネットワーク エッジです。The NVA and NSG control traffic flows for intra-Azure networks and between Azure and the Internet, while the gateway is a separate and isolated network edge between on-premises and Azure.

トラフィック フローは、具体的な使用事例に応じてこの設計パターンで最適化されることもあれば、状態が低下することもあるため、慎重に検討する必要があります。Traffic flows should be considered carefully, as they can be optimized or degraded by this design pattern, depending on the specific use case.

例 1 で構築した環境を使用した後に ExpressRoute ハイブリッド ネットワーク接続を追加すると、次のような設計になります。Using the environment built in example 1, and then adding an ExpressRoute hybrid network connection, produces the following design:

1717

まとめConclusion

ExpressRoute プライベート ピアリング ネットワーク接続を追加すると、安全で待機時間が短く、パフォーマンスの高い方法でオンプレミス ネットワークを Azure に拡張できます。The addition of an ExpressRoute Private Peering network connection can extend the on-premises network into Azure in a secure, lower latency, higher performing manner. また、ネイティブの Azure ゲートウェイを使用すると、この例のように、よりコストが低いオプションを利用できます (サード パーティ製の NVA と同様に、追加のライセンスはありません)。Also, using the native Azure Gateway, as in this example, provides a lower-cost option (no additional licensing as with third-party NVAs). 詳細については、詳細な構築手順をご覧ください (近日公開予定)。For more information, see the detailed build instructions (forthcoming). この手順の内容は次のとおりです。These instructions include:

  • PowerShell スクリプトを使用してこの例の境界ネットワークを構築する方法How to build this example perimeter network with PowerShell scripts.
  • Azure Resource Manager テンプレートを使用してこの例を構築する方法How to build this example with an Azure Resource Manager template.
  • トラフィック フローの詳細なシナリオ (この設計によるトラフィック フローを示します)Detailed traffic flow scenarios, showing how traffic flows through this design.

参照References

役に立つ Web サイトとドキュメントHelpful websites and documentation