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

セキュリティ境界のベスト プラクティス ページに戻るReturn to the Security Boundary Best Practices Page

この例では、境界ネットワーク (DMZ、非武装地帯、スクリーン サブネットともいう) を作成します。In this example, you create a perimeter network (also know as a DMZ, demilitarized zone, and screened subnet). 例では、ファイアウォール、4 台の Windows サーバー、ユーザー定義ルーティング (UDR)、IP 転送、およびネットワーク セキュリティ グループ (NSG) を実装します。The example implements a firewall, four Windows servers, user-defined routing (UDR), IP forwarding, and network security groups (NSGs). この記事では、各手順をより深く理解できるように、関連するコマンドを順に説明します。This article walks you through each of the relevant commands to provide a deeper understanding of each step. また、トラフィック シナリオ セクションでは、トラフィックが境界ネットワークの防御層を通過する過程を詳しく説明します。The traffic scenario section also explains in depth how traffic proceeds through the layers of defense in the perimeter network. 最後の「参照」セクションには、さまざまなシナリオでテストおよび実験ができるように、この環境を構築するためのすべてのコードと手順が含まれています。Finally, the references section contains all the code and instructions to build this environment so you can test and experiment with various scenarios.

NVA、NSG、UDR を含む双方向境界ネットワーク

環境のセットアップEnvironment setup

この例では、以下のコンポーネントを含むサブスクリプションを使用します。This example uses a subscription that contains the following components:

  • 3 つのクラウド サービス:SecSvc001、FrontEnd001、BackEnd001Three cloud services: SecSvc001, FrontEnd001, and BackEnd001
  • 次の 3 つのサブネットを含む仮想ネットワーク (CorpNetwork):SecNet、FrontEnd、BackEndA virtual network (CorpNetwork) with three subnets: SecNet, FrontEnd, and BackEnd
  • ネットワーク仮想アプライアンス: SecNet サブネットに接続されたファイアウォールA network virtual appliance: a firewall connected to the SecNet subnet
  • アプリケーション Web サーバーを表す Windows サーバー:IIS01A Windows server that represents an application web server: IIS01
  • アプリケーション バックエンド サーバーを表す 2 つの Windows サーバー:AppVM01、AppVM02Two Windows servers that represent application back-end servers: AppVM01, AppVM02
  • DNS サーバーを表す Windows サーバー:DNS01A Windows server that represents a DNS server: DNS01

「参照」セクションには、ここで説明しているほとんどの環境を構築する PowerShell スクリプトが含まれます。The references section contains a PowerShell script that builds most of the environment described here. それ以外、この記事では仮想マシン (VM) と仮想ネットワークを構築するための詳しい手順は示されていません。This article doesn't otherwise give detailed instructions for building the virtual machines (VMs) and virtual networks.

環境を構築するにはTo build the environment:

  1. 「参照」セクションに含まれるネットワーク構成 XML ファイルを保存します。Save the network config XML file included in the reference section. 特定のシナリオと一致するように、名前、場所、および IP アドレスで更新する必要があります。You'll need to update it with names, location, and IP addresses to match the given scenario.
  2. 完全なスクリプトでユーザー変数を更新し、自分の特定の環境 (サブスクリプション、サービス名など) と一致させます。Update the user variables in the full script to match your specific environment (for example, subscriptions, service names, and so on).
  3. PowerShell でスクリプトを実行します。Execute the script in PowerShell.

注意

PowerShell スクリプトで指定されたリージョンと、ネットワーク構成 XML ファイルで指定されたリージョンが一致している必要があります。The region specified in the PowerShell script must match the region specified in the network configuration XML file.

スクリプトが正常に実行された後、次の手順を行います。After the script runs successfully, take the following steps:

  1. ファイアウォール ルールを設定します。Set up the firewall rules. ファイアウォール規則」セクションを参照してください。See the firewall rules section.
  2. 必要に応じて、「参照」セクションの 2 つのスクリプトを使用して、Web サーバーとアプリ サーバーで Web アプリケーションを設定し、この DMZ 構成をテストできるようにします。Optionally, use the two scripts in the references section to set up a web application on the web server and app server to allow testing of this DMZ configuration.

ユーザー定義のルーティングUser-defined routing

既定では、次のシステム ルートが定義されています。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 は常に、その特定の仮想ネットワークに対して定義されるアドレス プレフィックスです。VNETLocal is always the defined address prefix(es) for that specific virtual network. たとえば、特定の各仮想ネットワークの定義方法に応じて、仮想ネットワーク間で変わります。For example, it will change from virtual network to virtual network depending on how each specific virtual network is defined. その他のシステム ルートは静的なものであり、上記のように既定値となっています。The remaining system routes are static and default as shown.

優先順位に関しては、ルートは最長プレフィックス マッチ (LPM) 方法を使用して処理されます。As for priority, routes are processed via the Longest Prefix Match (LPM) method. そのため、テーブル内で最も具体的なルートが、特定の宛先アドレスに適用されます。So the most specific route in the table applies to a given destination address.

したがって、ローカル ネットワーク (10.0.0.0/16) 上の DNS01 (10.0.2.4) のようなサーバーを対象としたトラフィックは、ルートが 10.0.0.0/16 であるため、仮想ネットワークを介してルーティングされます。Therefore, traffic intended for a server like DNS01 (10.0.2.4) on the local network (10.0.0.0/16) is routed across the virtual network because of the 10.0.0.0/16 route. 10.0.2.4 の場合、10.0.0.0/16 ルートが最も具体的なルートです。For 10.0.2.4, the 10.0.0.0/16 route is the most specific route. 10.0.0.0/8 と 0.0.0.0/0 も適用可能な場合でも、このルールが適用されます。This rule applies even though the 10.0.0.0/8 and 0.0.0.0/0 might also be applicable. しかし、これらは具体性が低いため、このトラフィックには影響しません。They are less specific, however, so they don’t affect this traffic. 10.0.2.4 へのトラフィックでは次ホップとしてローカル仮想ネットワークが指定されているため、宛先にルーティングされます。Traffic to 10.0.2.4 has the local virtual network as its next hop so is routed to the destination.

たとえば、10.0.0.0/16 ルートは、10.1.1.1 を対象とするトラフィックには適用されません。For example, the 10.0.0.0/16 route doesn't apply to traffic that is intended for 10.1.1.1. 10.0.0.0/8 システム ルートは最も具体的なものであり、次ホップが Null であるため、トラフィックは破棄されるか "ブラックホール" されます。The 10.0.0.0/8 system route is the most specific so the traffic is dropped or "black holed" because the next hop is Null.

宛先がいずれの Null プレフィックスにも VNETLocal プレフィックスにも適用されない場合、トラフィックは具体性の最も低いルート (0.0.0.0/0) に従います。If the destination doesn’t apply to any of the Null prefixes or the VNETLocal prefixes, then traffic follows the least specific route (0.0.0.0/0). 次ホップであるインターネットにルーティングされ、Azure のインターネット エッジの外に送出されます。It is routed out to the internet as the next hop, and out of Azure’s internet edge.

まったく同じ 2 つのプレフィックスがルート テーブルに存在した場合、優先順はルートのソース属性に基づきます。If there are two identical prefixes in the route table, the order of preference is based on the route's source attribute:

  1. VirtualAppliance:テーブルに手動で追加されたユーザー定義ルート。VirtualAppliance: A User-Defined Route manually added to the table.
  2. VPNGateway:動的ネットワーク プロトコルによって追加された動的ルート (ハイブリッド ネットワークで使用される場合は BGP)。VPNGateway: A Dynamic Route (BGP when used with hybrid networks) added by a dynamic network protocol. 動的プロトコルではピア ネットワークの変更が自動的に反映されるため、これらのルートは時間の経過と共に変わる場合があります。These routes may change over time as the dynamic protocol automatically reflects changes in peered network.
  3. 既定値は上記のルート テーブルに示されているシステム ルート、ローカル仮想ネットワーク、静的エントリ。Default: The system routes, the local virtual network, and the static entries as shown in the route table above.

注意

これで、ExpressRoute と VPN Gateway でユーザー定義ルーティング (UDR) を使用して、アウトバウンドおよびインバウンド クロスプレミス トラフィックをネットワーク仮想アプライアンス (NVA) に強制的にルーティングできるようになりました。You can now use user-defined routing (UDR) with ExpressRoute and VPN Gateways to force outbound and inbound cross-premises traffic to be routed to a network virtual appliance (NVA).

ローカル ルートを作成するCreate local routes

この例では、フロントエンドとバックエンドのサブネットに対して 1 つずつ、2 つのルーティング テーブルを使用します。This example uses two routing tables, one each for the front-end and back-end subnets. 各サブネットに適した静的ルートをそれぞれのテーブルに読み込みます。Each table is loaded with static routes appropriate for the given subnet. この例では、各テーブルに 3 つのルートが存在します。For the purpose of this example, each table has three routes:

  1. 次ホップが定義されていないローカル サブネット トラフィック。Local subnet traffic with no next hop defined. このルートでは、ローカル サブネット トラフィックでファイアウォールをバイパスできます。This route allows local subnet traffic to bypass the firewall.
  2. 次ホップがファイアウォールとして定義されている仮想ネットワーク トラフィック。Virtual network traffic with a next hop defined as firewall. このルートでは、ローカル仮想ネットワーク トラフィックによる直接ルーティングを許可する既定のルールがオーバーライドされます。This route 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.

ルーティング テーブルが作成された後、対応するサブネットにバインドされます。After the routing tables are created, they are bound to their subnets. フロントエンド サブネット ルーティング テーブルは次のようになります。The front-end subnet routing table should look like:

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

この例では以下のコマンドを使用して、ルート テーブルを構築し、ユーザー定義ルートを追加してから、ルート テーブルをサブネットにバインドします。This example uses the following commands to build the route table, add a user-defined route, and then bind the route table to a subnet. $BESubnet など、$ で始まる項目は、「参照」セクションのスクリプトからのユーザー定義変数です。Items that begin with $, such as $BESubnet, are user-defined variables from the script in the reference section.

  1. まず、ベース ルーティング テーブルを作成します。First, create the base routing table. 次のコード スニペットでは、バックエンド サブネット用のテーブルを作成します。The following code snippet creates the table for the back-end subnet. また、完全なスクリプトでは、フロントエンド サブネット用の対応するテーブルを作成します。The full script also creates a corresponding table for the front-end subnet.

    New-AzureRouteTable -Name $BERouteTableName `
        -Location $DeploymentLocation `
        -Label "Route table for $BESubnet subnet"
    
  2. ルート テーブルを作成した後、特定のユーザー定義ルートを追加できます。After you've created the route table, you can add specific user-defined routes. 次のコード スニペットでは、すべてのトラフィック (0.0.0.0/0) が仮想アプライアンス経由でルーティングされることを指定します。The following code snippet specifies that all traffic (0.0.0.0/0) is routed through the virtual appliance. 変数 $VMIP[0] は、スクリプトの前半で仮想アプライアンスが作成されたときに割り当てられた IP アドレスを渡すために使用されます。A variable $VMIP[0] is used to pass in the IP address assigned when the virtual appliance was created earlier in the script. また、完全なスクリプトでは、フロントエンド テーブルの対応するルールを作成します。The full script also creates a corresponding rule in the front-end table.

    Get-AzureRouteTable $BERouteTableName | `
        Set-AzureRoute -RouteName "All traffic to FW" -AddressPrefix 0.0.0.0/0 `
        -NextHopType VirtualAppliance `
        -NextHopIpAddress $VMIP[0]
    
  3. 前述のルート エントリによって既定の "0.0.0.0/0" ルートはオーバーライドされますが、既定の 10.0.0.0/16 ルールでは引き続き、仮想ネットワーク内のトラフィックを、ネットワーク仮想アプライアンスにではなく、直接宛先にルーティングできます。The previous route entry overrides the default "0.0.0.0/0" route, but the default 10.0.0.0/16 rule still allows traffic within the virtual network to route directly to the destination and not to the network virtual appliance. この動作を修正するには、次のルールを追加する必要があります。To correct this behavior, you need to add the following rule:

    Get-AzureRouteTable $BERouteTableName | `
        Set-AzureRoute -RouteName "Internal traffic to FW" -AddressPrefix $VNetPrefix `
        -NextHopType VirtualAppliance `
        -NextHopIpAddress $VMIP[0]
    
  4. この時点で、選択する必要があります。At this point, you have to make a choice. 前述の 2 つのルールでは、単一サブネット内のトラフィックを含む、すべてのトラフィックが評価のためにファイアウォールにルーティングされます。The two previous rules route all traffic to the firewall for assessment, including traffic within a single subnet. この動作が必要な場合があります。You might want this behavior. ただし、必要でない場合は、ファイアウォールを介さずに、サブネット内のトラフィックをローカルでルーティングすることができます。If you don't, however, you can allow traffic within a subnet to route locally without firewall involvement. 3 つ目の特定のルールを追加します。このルールでは、ローカル サブネット宛てのすべてのアドレスを直接ルーティングします (NextHopType = VNETLocal)。Add a third, specific rule that directly routes any address destined for the local subnet (NextHopType = VNETLocal).

    Get-AzureRouteTable $BERouteTableName | `
        Set-AzureRoute -RouteName "Allow Intra-Subnet Traffic" -AddressPrefix $BEPrefix `
            -NextHopType VNETLocal
    
  5. 最後に、ルーティング テーブルが作成され、ユーザー定義ルートが設定された後、そのテーブルをサブネットにバインドする必要があります。Finally, after the routing table is created and populated with user-defined routes, you need to bind the table to a subnet. 次のコード スニペットでは、バックエンド サブネット用のテーブルをバインドします。The following code snippet binds the table for the back-end subnet. また、完全なスクリプトでは、フロントエンド ルート テーブルをフロントエンド サブネットにバインドします。The full script also binds the front-end route table to the front-end subnet.

    Set-AzureSubnetRouteTable -VirtualNetworkName $VNetName `
        -SubnetName $BESubnet `
        -RouteTableName $BERouteTableName
    

IP 転送IP forwarding

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

たとえば、AppVM01 からのトラフィックで DNS01 サーバーに要求を行う場合、UDR ではトラフィックをファイアウォールにルーティングします。For example, if traffic from AppVM01 makes a request to the DNS01 server, UDR routes the traffic to the firewall. IP 転送が有効になっている場合、DNS01 (10.0.2.4) 宛てのトラフィックはファイアウォール アプライアンス (10.0.0.4) で受け入れられてから、最終的な宛先 (10.0.2.4) に転送されます。With IP Forwarding enabled, the traffic with the DNS01 destination (10.0.2.4) is accepted by the firewall 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 is not accepted by the appliance even though the route table has the firewall as the next hop.

重要

必ず、ユーザー定義ルーティングと併せて IP 転送を有効にしてください。Remember to enable IP forwarding in conjunction with user-defined routing.

VM の作成時に、単一のコマンドで IP 転送を有効にすることができます。IP forwarding can be enabled with a single command at VM creation time. ファイアウォール仮想アプライアンスである VM インスタンスを呼び出し、IP 転送を有効にします。You call the VM instance that is your firewall virtual appliance and enable IP forwarding. $VMName[0] など、$ で始まる赤色の項目は、このドキュメントの「参照」セクションのスクリプトからのユーザー定義変数であることに注意してください。Keep in mind that items in red that begin with $, like $VMName[0], are user-defined variables from the script in the reference section of this document. 角かっこで囲まれたゼロ [0] は、VM の配列内の最初の VM を表します。The zero in brackets, [0], represents the first VM in the array of VMs. このスクリプト例を変更せずに機能させるには、最初の VM (VM 0) がファイアウォールである必要があります。For the example script to work without modification, the first VM (VM 0) must be the firewall. 完全なスクリプトでは、関連するコード スニペットが末尾付近の UDR コマンドでグループ化されます。In full script, the relevant code snippet is grouped with the UDR commands near the end.

Get-AzureVM -Name $VMName[0] -ServiceName $ServiceName[0] | `
    Set-AzureIPForwarding -Enable

ネットワーク セキュリティ グループNetwork security groups

この例では、ネットワーク セキュリティ グループ (NSG) を構築してから、そこに単一のルールを読み込みます。In this example, you build an network security group (NSG) and then load it with a single rule. その後、この例では、(SecNet ではない) フロントエンドとバックエンドのサブネットにのみ、NSG をバインドします。The example then binds the NSG only to the front-end and back-end subnets (not the SecNet). NSG に読み込むルールは次のとおりです。The rule you load into the NSG is as follows:

  • インターネットから仮想ネットワーク全体 (すべてのサブネット) への任意のトラフィック (すべてのポート) を拒否する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, their main purpose is as a secondary layer of defense against manual misconfiguration. フロントエンド サブネットまたはバックエンド サブネットへのインターネットからのインバウンド トラフィックをすべてブロックする必要があります。You want 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, after which only appropriate traffic should get routed on to the front-end or back-end subnets. また、UDR ルールでは、フロントエンドまたはバックエンドのサブネットに到達するすべてのトラフィックをファイアウォールにルーティングします。In addition, the UDR rules route any traffic that reaches the front-end or back-end subnets to the firewall. ファイアウォールではそれが非対称フローと見なされ、アウトバウンド トラフィックは破棄されます。The firewall sees it as an asymmetric flow and drops the outbound traffic.

次の 3 層のセキュリティで、フロントエンドとバックエンドのサブネットが保護されます。Three layers of security protect the front-end and back-end subnets:

  1. FrontEnd001 と BackEnd001 のクラウド サービスのエンドポイントをすべて閉じるNo open endpoints on the FrontEnd001 and BackEnd001 cloud services
  2. インターネットからのトラフィックを NSG で拒否するNSGs deny traffic from the internet
  3. 非対称トラフィックをファイアウォールで破棄するThe firewall drops asymmetric traffic

この例の NSG に関する興味深い点は、以下に示すように、1 つのルールのみが含まれていることです。An interesting point about the NSG in this example is that it contains only one rule, shown below. このルールでは、セキュリティ サブネットを含む、仮想ネットワーク全体へのインターネット トラフィックが拒否されます。This rule denies internet traffic to the entire virtual network, including the Security subnet.

Get-AzureNetworkSecurityGroup -Name $NSGName | `
    Set-AzureNetworkSecurityRule -Name "Isolate the $VNetName VNet `
    from the internet" `
    -Type Inbound -Priority 100 -Action Deny `
    -SourceAddressPrefix INTERNET -SourcePortRange '*' `
    -DestinationAddressPrefix VIRTUAL_NETWORK `
    -DestinationPortRange '*' `
    -Protocol *

NSG がバインドされるのはフロントエンド サブネットとバックエンド サブネットのみであるため、セキュリティ サブネットに入ってくるトラフィックに対してルールは適用されません。Because the NSG is only bound to the front-end and back-end subnets, the rule isn’t applied to traffic inbound to the Security subnet. その結果、トラフィックはセキュリティ サブネットに到達します。As a result, traffic flows to the Security subnet.

Set-AzureNetworkSecurityGroupToSubnet -Name $NSGName `
    -SubnetName $FESubnet -VirtualNetworkName $VNetName

Set-AzureNetworkSecurityGroupToSubnet -Name $NSGName `
    -SubnetName $BESubnet -VirtualNetworkName $VNetName

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

ファイアウォールには、転送ルールを作成する必要があります。You must create forwarding rules on the firewall. ファイアウォールではすべてのインバウンド トラフィック、アウトバウンド トラフィック、仮想ネットワーク間トラフィックがブロックまたは転送されるため、多くのファイアウォール規則が必要です。Because the firewall blocks or forwards all inbound, outbound, and intra-virtual-network traffic, you need many firewall rules. また、ファイアウォールでは、(さまざまなポート上の) セキュリティ サービスのパブリック IP アドレスへのすべてのインバウンド トラフィックを処理する必要があります。Also, the firewall has to process all inbound traffic to the Security Service public IP address (on different ports). 後で作業し直さなくても済むように、サブネットとファイアウォール規則を設定する前に論理フローを図式化し、ベスト プラクティスに従います。To avoid rework later, follow the best practice by diagramming the logical flows before setting up the subnets and firewall rules. 次の図では、この例で使用するファイアウォール ルールを論理的に示しています。The following figure is a logical view of the firewall rules for this example:

Logical View of the Firewall Rules

注意

ネットワーク仮想アプライアンスによって、管理ポートは異なります。Management ports vary depending on the network virtual appliance. この例では、ポート 22、801、807 を使用する Barracuda NextGen Firewall を示します。This example shows a Barracuda NextGen Firewall which uses ports 22, 801, and 807. デバイスを管理するための実際のポートについては、アプライアンス ベンダーのドキュメントを参照してください。Please consult the appliance vendor documentation to find the exact ports to manage the device.

論理規則の説明Logical rule description

上の論理図にはセキュリティ サブネットが示されていません。これはファイアウォールがそのサブネットの唯一のリソースであるためです。The logical diagram above doesn't show the security subnet because the firewall is the only resource on that subnet. この図にはファイアウォール規則が示されています。また、実際の経路ではなく、論理的にトラフィック フローがどのように許可または拒否されるかが示されています。This diagram shows the firewall rules, how they logically allow or deny traffic flows, but not the actual routed path. また、リモート デスクトップ プロトコル (RDP) トラフィック用に選択された外部ポートは、より大きな番号範囲のポート (8014 から 8026) になっています。これらは、ローカル IP アドレスの最後の 2 つのオクテットに合わせ、見やすくするために選択されています。Also, the external ports selected for the remote desktop protocol (RDP) traffic are higher ranged ports (8014 – 8026), chosen for easier readability to align with the last two octets of the local IP addresses. たとえば、ローカル サーバー アドレス 10.0.1.4 は外部ポート 8014 に関連付けられています。For example, local server address 10.0.1.4 is associated with external port 8014. ただし、競合しなければ、もっと大きなポート番号を使用してもかまいません。You could, however, use any higher non-conflicting ports.

この例では、以下の種類のルールが必要です。You need the following types of rules for this example:

  • インバウンド トラフィック用の外部ルール:External rules for inbound traffic:

    1. ファイアウォール管理ルール: ネットワーク仮想アプライアンスの管理ポートへのトラフィックの通過を許可します。Firewall management rule: allows traffic to pass to the management ports of the network virtual appliance.

    2. Windows サーバーごとの RDP ルール: 個々のサーバーを RDP 経由で管理できるようにします。RDP rules for each windows server: allows management of the individual servers via RDP. ネットワーク仮想アプライアンスの機能によっては、ルールを 1 つにバンドルできる場合があります。Depending on the capabilities of your network virtual appliance, you might be able to bundle the rules into one.

    3. アプリケーション トラフィック ルール: フロントエンド Web トラフィック用に 1 つとバックエンド トラフィック用に 1 つ (Web サーバーからデータ層など)。Application traffic rules: one for front-end web traffic and one for back-end traffic (for example, web server to data tier). これらのルールの構成は、ネットワーク アーキテクチャおよびトラフィック フローによって異なります。The configuration of these rules depends on network architecture and traffic flows.

      • 最初のルールでは、実際のアプリケーション トラフィックがアプリケーション サーバーに到達できます。The first rule allows actual application traffic to reach the application server. セキュリティや管理などのルールとは異なり、アプリケーション ルールでは、外部のユーザーまたはサービスがアプリケーションにアクセスできるようにします。Unlike the rules for security, management, and so on, application rules allow external users or services to access the application(s). この例ではポート 80 に単一の Web サーバーがあります。これにより、単一のファイアウォール アプリケーション ルールでは、外部 IP アドレス宛てのトラフィックをリダイレクトし、代わりに Web サーバーの内部 IP アドレスにルーティングできます。This example has a single web server on port 80, which allows a single firewall application rule to redirect traffic that is destined for an external IP address to instead route to the web server's internal IP address. リダイレクトされたトラフィック セッションは、NAT によって内部サーバーに再マッピングされます。The redirected traffic session is remapped by NAT to the internal server.
      • 2 つ目のアプリケーション トラフィック ルールはバックエンド ルールです。Web サーバーで任意のポートを使用して、AppVM02 サーバーではなく、AppVM01 サーバーにトラフィックをルーティングできるようにします。The second application traffic rule is the back-end rule to allow the web server to use any port to route traffic to the AppVM01 server, but not to the AppVM02 server.
  • 仮想ネットワーク間トラフィック用の内部ルール:Internal rules for intra-virtual-network traffic:

    1. インターネットへのアウトバウンド規則: 任意のネットワークから選択されたネットワークへのトラフィックの通過を許可します。Outbound to internet rule: allows traffic from any network to pass to the selected networks. ファイアウォールでは通常、これが既定のルールですが、無効状態の場合です。This rule is usually a default on the firewall, but in a disabled state. この例では、このルールを有効にします。Enable this rule for this example.
    2. DNS ルール: DNS (ポート 53) トラフィックのみに DNS サーバーへの通過を許可します。DNS rule: only allows 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: allows 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 above criteria:

    1. 全トラフィック拒否ルール: 優先度の観点から、これが常に最後のルールとなります。Deny all traffic rule: always the final rule in terms of priority. トラフィック フローが上記のいずれのルールにも一致しなかった場合、このルールでブロックされます。If traffic flow fails to match any of the preceding rules, this rule blocks it. これが既定のルールになります。It is a default rule. 通常はアクティブ化されているため、変更は必要ありません。Because it is commonly activated, no modifications are needed.

ヒント

2 つ目のアプリケーション トラフィック ルールでは、この例を簡潔にするために任意のポートが許可されています。In the second application traffic rule, any port is allowed to keep this example simple. 実際のシナリオでは、特定のポートとアドレス範囲を使用して、このルールに対する攻撃面を小さくする必要があります。In a real scenario, you should use specific port and address ranges to reduce the attack surface of this rule.

重要

ルールを作成した後、各ルールの優先度を確認し、トラフィックの許可または拒否が意図したとおりになっていることを確かめることが重要です。After you have created the rules, it’s important that you review the priority of each rule to ensure that traffic is allowed or denied as desired. この例では、各ルールに優先順位が割り当てられています。For this example, the rules are in priority order. ルールの優先順位に間違いがある場合、ファイアウォールからロックアウトされやすくなります。It's easy to get locked out of the firewall if the rules are mis-ordered. ファイアウォール管理ルールには必ず、最も高い絶対優先順位を設定してください。Make sure to set the firewall management rule as the absolute highest priority.

ルールの前提条件Rule prerequisites

ファイアウォールを実行する仮想マシンには、パブリック エンドポイントが必要になります。Public endpoints are required for the virtual machine running the firewall. ファイアウォールでトラフィックを処理できるように、これらのパブリック エンドポイントを開く必要があります。These public endpoints must be open so that the firewall can process traffic. この例には、次の 3 種類のトラフィックがあります。There are three types of traffic in this example:

  1. ファイアウォールとファイアウォール規則を制御する管理トラフィックManagement traffic to control the firewall and firewall rules
  2. Windows サーバーを制御する RDP トラフィックRDP traffic to control the windows servers
  3. アプリケーション トラフィックApplication traffic

トラフィックの種類は、上記のファイアウォール規則の論理図の上半分に示されています。The traffic types appear in the upper half of the firewall rules logical diagram above.

重要

すべてのトラフィックがファイアウォールを経由することに注意してください。Remember that all traffic comes through the firewall. IIS01 サーバーにリモート デスクトップ接続するには、ポート 8014 上のファイアウォールに接続してから、ファイアウォールで IIS01 RDP ポートに内部的に RDP 要求をルーティングできるようにします。To remote desktop to the IIS01 server, you need to connect to the firewall on port 8014 and then allow the firewall to route the RDP request internally to the IIS01 RDP port. Azure ポータルの [接続] ボタンは機能しません。これは、RDP で直接 IIS01 に到達する経路が、ポータルから見える範囲では存在しないためです。The Azure portal's Connect button won't work because there is no direct RDP path to IIS01 as far as the portal can see. インターネットからのすべての接続は、セキュリティ サービスとポート (secscv001.cloudapp.net:xxxx など) に対するものです。All connections from the internet are to the security service and a port (for example, secscv001.cloudapp.net:xxxx ). 外部ポートおよび内部 IP とポートのマッピングについては、上の図を参照してください。Reference the above diagram for the mapping of external port and internal IP and port.

エンドポイントは、VM の作成時、または構築後に開くことができます。You can open an endpoint at the time of VM creation or after the build. スクリプト例と以下のコード スニペットでは、VM の作成後にエンドポイントが開かれます。The example script and the following code snippet open an endpoint after the VM is created.

$VMName[$i] など、$ で始まる項目は、「参照」セクションのスクリプトからのユーザー定義変数であることに注意してください。Keep in mind that items that begin with $, such as $VMName[$i], are user-defined variables from the script in the reference section. [$i] は、VM の配列における特定の VM の配列番号を表します。The [$i] represents the array number of a specific VM in an array of VMs.

Add-AzureEndpoint -Name "HTTP" -Protocol tcp -PublicPort 80 -LocalPort 80 `
    -VM (Get-AzureVM -ServiceName $ServiceName[$i] -Name $VMName[$i]) | `
    Update-AzureVM

ここでは変数が示されているためわかりにくいですが、エンドポイントはセキュリティ クラウド サービスでのみ開いてください。Although it's not clearly shown here because of variables, you should only open endpoints on the security cloud service. この予防措置は、ファイアウォールですべてのインバウンド トラフィックが必ず処理されるようにするのに役立ちます。ルーティングされるか、NAT によって再マッピングされるか、破棄されるかは関係ありません。This precaution helps ensure that the firewall handles all inbound traffic, whether it's routed, remapped by NAT, or dropped.

ファイアウォールを管理し、必要な構成を作成するには、PC 上に管理クライアントをインストールします。Install a management client on a PC to manage the firewall and create the necessary configurations. ファイアウォールまたは他の NVA を管理する方法の詳細については、ベンダーのドキュメントを参照してください。For details on how to manage your firewall or other NVA, refer to the vendor's documentation. このセクションの残りの部分と、「ファイアウォール規則の作成」セクションでは、ファイアウォールの構成について説明します。The remainder of this section as well as the Firewall rules creation section describe the configuration of the firewall. Azure ポータルや PowerShell ではなく、ベンダーの管理クライアントを使用します。Use the vendor's management client, not the Azure portal or PowerShell.

Barracuda NG Admin」に移動して管理クライアントをダウンロードし、Barracuda ファイアウォールへの接続方法を学習します。Go to Barracuda NG Admin to download the management client and learn how to connect to the Barracuda firewall.

ファイアウォールにログインした後、ファイアウォール規則を作成する前に、ネットワークとサービス オブジェクトを定義します。After you're logged into the firewall, define network and service objects before creating the firewall rules. これら 2 つの前提条件となるオブジェクト クラスでは、ルールをより簡単に作成できます。These two prerequisite object classes can make creating the rules easier.

この例では、それぞれに次の 3 つの名前付きネットワーク オブジェクトを定義します。For this example, define three named network objects for each:

  • フロントエンド サブネットFront-end subnet
  • バックエンド サブネットBack-end subnet
  • DNS サーバーの IP アドレスIP address of the DNS server

Barracuda NG Admin クライアント ダッシュボードから名前付きネットワークを作成するには、次のようにします。To create a named network from the Barracuda NG Admin client dashboard:

  1. [構成] タブに移動します。Go to the configuration tab.

  2. [Operational Configuration](操作の構成) セクションで [Ruleset](ルールセット) を選択しますSelect Ruleset in the Operational Configuration section

  3. [Firewall Objects](ファイアウォール オブジェクト) メニューで [ネットワーク] を選択します。Select Networks under the Firewall Objects menu.

  4. [ネットワークの編集] メニューで [新規] を選択します。Select New in the Edit Networks menu.

  5. 名前とプレフィックスを追加して、ネットワーク オブジェクトを作成します。Create the network object by adding the name and the prefix:

    フロントエンド ネットワーク オブジェクトを作成する

上記の手順では、フロントエンド サブネットの名前付きネットワークを作成します。The preceding steps create a named network for the front-end subnet. バックエンド サブネットにも同様のオブジェクトを作成します。Create a similar object for the back-end subnet as well. これでサブネットが参照しやすくなりました。ファイアウォール ルール内から名前で参照することができます。Now the subnets can be more easily referenced by name in the firewall rules.

DNS サーバー オブジェクトの場合:For the DNS server object:

DNS サーバー オブジェクトを作成する

この単一の IP アドレス参照は、ドキュメントの後半の DNS ルールで使用されます。This single IP address reference is used in a DNS rule later in the document.

その他のオブジェクト クラスには、サーバーごとの RDP 接続ポートを表す、サービス オブジェクトが含まれます。The other object class includes services objects, which represent the RDP connection ports for each server. 既存の RDP サービス オブジェクトは、既定の RDP ポートである 3389 にバインドされます。The existing RDP service object is bound to the default RDP port, 3389. したがって、外部ポート (8014 から 8026) からのトラフィックを許可するために新しいサービスを作成できます。Thus, you can create new services to allow traffic from the external ports (8014-8026). 既存の RDP サービスに新しいポートを追加することもできます。You can also add the new ports to the existing RDP service. しかし、デモをわかりやすくするため、サーバーごとに個々のルールを作成できます。However, for ease of demonstration, you can make an individual rule for each server. Barracuda NG Admin クライアント ダッシュボードからサーバーの新しい RDP ルールを作成するには、次のようにします。To create a new RDP rule for a server from the Barracuda NG Admin client dashboard:

  1. [構成] タブに移動します。Go to the configuration tab.

  2. [Operational Configuration](操作の構成) セクションで [Ruleset](ルールセット) を選択します。Select Ruleset in the Operational Configuration section.

  3. [Firewall Objects](ファイアウォール オブジェクト) メニューで [サービス] を選択します。Select Services under the Firewall Objects menu.

  4. サービス リストを下にスクロールして、[RDP] を選択します。Scroll down the list of services and select RDP.

  5. 右クリックして [コピー] を選択してから、右クリックして [貼り付け] を選択します。Right-click and select copy, then right-click and select paste.

  6. これで、編集可能な RDP-Copy1 というサービス オブジェクトが作成されました。There's now a RDP-Copy1 service object that can be edited. [RDP-Copy1] を右クリックし、[編集] を選択します。Right-click RDP-Copy1 and select Edit.

  7. 以下のように、[Edit Service Object](サービス オブジェクトの編集) ウィンドウがポップアップ表示されます。The Edit Service Object window pops up as shown here:

    Copy of Default RDP Rule

  8. 特定のサーバーの RDP サービスを表すように値を編集します。Edit the values to represent the RDP service for a specific server. AppVM01 の場合、既定の RDP ルールを変更して、図 8 で使用されている新しいサービスの名前説明、および外部 RDP ポートを反映する必要があります。For AppVM01, the default RDP rule should be modified to reflect a new service Name, Description, and external RDP Port used in the Figure 8 diagram. ポートは、RDP の既定値である 3389 から、この特定のサーバーの外部ポートに変更されることに注意してください。Keep in mind that the ports are changed from the RDP default of 3389 to the external port for this specific server. たとえば、AppVM01 の外部ポートは 8025 となります。For example, the external port for AppVM01 is 8025. 変更されたサービス ルールを以下に示します。The modified service rule is shown here:

    AppVM01 Rule

残りのサーバー (AppVM02、DNS01、IIS01) の RDP サービスを作成するには、このプロセスを繰り返します。Repeat this process to create RDP services for the remaining servers: AppVM02, DNS01, and IIS01. これらのサービスを利用すれば、次のセクションのルールを作成しやすくなり、わかりやすくなります。These services make the rules in the next section simpler to create and more obvious.

注意

ファイアウォール VM が Linux ベースのイメージであるため、ファイアウォールの RDP サービスは必要ありません。したがって、VM 管理用のポート 22 では、RDP ではなく、SSH が使用されます。An RDP service for the firewall is not needed because the firewall VM is a Linux-based image so SSH is used on port 22 for VM management instead of RDP. また、ポート 22 と他の 2 つのポートが、管理接続用に許可されます。Also, port 22 and two other ports are allowed for management connectivity. 次のセクションの「ファイアウォール管理ルール」を参照してください。See the Firewall management rule in the next section.

ファイアウォール規則の作成Firewall rules creation

この例には 3 種類のファイアウォール ルールが使われており、以下のように、すべて異なるアイコンで示されています。There are three types of firewall rules used in this example, all with distinct icons:

アプリケーション リダイレクト ルール:アプリケーション リダイレクト アイコンThe application redirect rule: Application Redirect Icon

送信先 NAT ルール:Destination NAT アイコンThe destination NAT rule: Destination NAT Icon

通過ルール:Pass アイコンThe pass rule: Pass Icon

これらのルールの詳細については、Barracuda の Web サイトを参照してください。More information on these rules can be found at the Barracuda website.

以下のルールを作成するか、既存の既定のルールを確認するには、次のようにします。To create the following rules or verify existing default rules:

  1. Barracuda NG Admin クライアント ダッシュボードから、[構成] タブに移動します。From the Barracuda NG Admin client dashboard, go to the configuration tab.
  2. [Operational Configuration](操作の構成) セクションで [Ruleset](ルールセット) を選択します。In the Operational Configuration section, select Ruleset.
  3. [Main Rules](メイン ルール) グリッドには、このファイアウォールの既存のアクティブおよび非アクティブ ルールが表示されます。The Main Rules grid shows the existing active and deactivated rules on this firewall. 新しいルールを作成するには、右上隅にある緑色の [+] を選択します。Select the green + in the upper right corner to create a new rule. 変更のためにファイアウォールがロックされている場合、[ロック] とマークされたボタンが表示され、ルールを作成したり、編集したりすることはできません。If your firewall is locked for changes, you see a button marked Lock and can't create or edit rules. [ロック] ボタンを選択し、ルール セットのロックを解除して、編集を許可します。Select the Lock button to unlock the rule set and allow editing. 編集するルールを右クリックし、[ルールの編集] を選択します。Right-click a rule you want to edit, and select Edit Rule.

ルールを作成または変更した後、ファイアウォールにプッシュしてアクティブ化します。After you create or modify any rules, push them to the firewall and activate them. そうしないと、ルール変更は有効になりません。Otherwise, the rule changes won't take effect. プッシュとアクティブ化のプロセスについては、「ルールのアクティブ化」で説明します。The push and activation process is described in rule activation.

この例を完了するために必要な各ルールの仕様を以下に示します。Here are the specifics of each rule required to complete this example:

  • ファイアウォール管理ルール:このアプリ リダイレクト ルールでは、ネットワーク仮想アプライアンス (この例では Barracuda NextGen Firewall) の管理ポート宛てのトラフィックが通過できるようにします。Firewall management rule: This app redirect rule allows traffic to pass to the management ports of the network virtual appliance, in this example a Barracuda NextGen Firewall. 管理ポートは 801 と 807、および (必要に応じて) 22 です。The management ports are 801, 807, and optionally 22. 外部ポートと内部ポートは同じです (ポートの変換は使用しません)。The external and internal ports are the same, no port translation. このルールを SETUP-MGMT-ACCESS といいます。This rule is called SETUP-MGMT-ACCESS. これは既定のルールであり、Barracuda NextGen Firewall バージョン 6.1 では既定で有効になります。It's a default rule and enabled by default in Barracuda NextGen Firewall, version 6.1.

    ファイアウォール管理ルール

    ヒント

    このルールのソース アドレス空間は Any です。The source address space in this rule is Any. 管理 IP アドレス範囲がわかっている場合、このスコープを減らすと、管理ポートへの攻撃面も減ります。If the management IP address ranges are known, reducing this scope also reduces the attack surface to the management ports.

  • RDP ルール:これらの送信先 NAT ルールでは、RDP 経由で個々のサーバーを管理できるようにします。RDP rules: These destination NAT rules allow management of the individual servers via RDP. これらのルールの重要なフィールドは次のとおりです。The critical fields for these rules are:

    • ソース。Source. 任意の場所からの RDP を許可するには、[ソース] フィールドで参照 [Any] を使用します。To allow RDP from anywhere, use the reference Any in the Source field.

    • サービス。Service. 先ほど作成した RDP サービス オブジェクトの AppVM01 RDP を使用します。Use the RDP service object you created earlier: AppVM01 RDP. 外部ポートでは、サーバーのローカル IP アドレスおよび既定の RDP ポート 3386 にリダイレクトします。The external ports redirect to the server's local IP address and to the default RDP port 3386. ここに示したルールは、AppVM01 への RDP アクセス用です。This specific rule is for RDP access to AppVM01.

    • 宛先。Destination. ファイアウォールのローカル ポートには、DCHP 1 ローカル IP または eth0 (静的 IP を使用している場合) を使用します。Use the local port on the firewall: DCHP 1 Local IP or eth0 if you're using static IPs. ご使用のネットワーク アプライアンスが複数のローカル インターフェイスを備えている場合、序数 (eth0、eth1 など) は異なる場合があります。The ordinal number (eth0, eth1, and so on) might be different if your network appliance has multiple local interfaces. ファイアウォールでは送信用にこのポートを使用します。これは受信ポートと同じである場合があります。The firewall uses this port for sending, and it might be the same as the receiving port. 実際のルーティング先は、[ターゲット リスト] フィールドにあります。The actual routed destination is in the Target List field.

    • リダイレクト。Redirection. このトラフィックの最終的なリダイレクト先を仮想アプライアンスに指示するように構成します。Configure to tell the virtual appliance where to ultimately redirect this traffic. 最もシンプルなリダイレクトは、[ターゲット リスト] フィールドに IP を配置することです。The simplest redirection is to place the IP in the Target List field. ポートを指定することもでき、NAT ではポートと IP アドレスの両方を再ルーティングします。You can also specify the port, and NAT reroutes both the port and the IP address. ポートを指定しない場合、仮想アプライアンスではインバウンド要求で宛先ポートが使用されます。If you don't specify a port, the virtual appliance uses the destination port on the inbound request.

      Firewall RDP Rule

      次の 4 つの RDP ルールを作成します。Create four RDP rules:

      規則の名前Rule Name サーバーServer ServiceService ターゲット リストTarget List
      RDP-to-IIS01RDP-to-IIS01 IIS01IIS01 IIS01 RDPIIS01 RDP 10.0.1.4:338910.0.1.4:3389
      RDP-to-DNS01RDP-to-DNS01 DNS01DNS01 DNS01 RDPDNS01 RDP 10.0.2.4:338910.0.2.4:3389
      RDP-to-AppVM01RDP-to-AppVM01 AppVM01AppVM01 AppVM01 RDPAppVM01 RDP 10.0.2.5:338910.0.2.5:3389
      RDP-to-AppVM02RDP-to-AppVM02 AppVM02AppVM02 AppVm02 RDPAppVm02 RDP 10.0.2.6:338910.0.2.6:3389

    ヒント

    [ソース] フィールドと [サービス] フィールドのスコープを狭くすると、攻撃面が小さくなります。Narrowing the scope of the Source and Service fields reduces the attack surface. 機能を許可する最も限定的なスコープを使用します。Use the most limited scope that allows functionality.

  • アプリケーション トラフィック ルール:2 つのアプリケーション トラフィック ルールがあります。Application traffic rules: There are two application traffic rules. 1 つはフロントエンド Web トラフィック用です。One is for the front-end web traffic. もう 1 つでは、Web サーバーからデータ層などのバックエンド トラフィックが対象となります。The other covers back-end traffic like web server to data tier. これらのルールは、ネットワーク アーキテクチャおよびトラフィック フローによって異なります。These rules depend on network architecture and traffic flows.

    • Web トラフィック用のフロントエンド ルール:The front-end rule for web traffic:

      Firewall Web Rule

      この宛先 NAT ルールでは、実際のアプリケーション トラフィックがアプリケーション サーバーに到達できるようにします。This Destination NAT rule allows actual application traffic to reach the application server. セキュリティや管理などのルールとは異なり、アプリケーション ルールでは、外部のユーザーまたはサービスがアプリケーションにアクセスできるようにします。Unlike the rules for security, management, and etcetera, application rules allow external users or services to access the application(s). この例ではポート 80 に単一の Web サーバーがあります。これにより、単一のファイアウォール アプリケーション ルールでは、外部 IP アドレス宛てのトラフィックをリダイレクトし、代わりに Web サーバーの内部 IP アドレスにルーティングできます。This example has a single web server on port 80, which allows a single firewall application rule to redirect traffic that is destined for an external IP address to instead route to the web server's internal IP address. リダイレクトされたトラフィック セッションは、NAT によって内部サーバーに再マッピングされます。The redirected traffic session is remapped by NAT to the internal server.

      注意

      [ターゲット リスト] フィールドで割り当てられているポートはありません。There is no port assigned in the Target List field. そのため、インバウンド ポート 80 (選択されたサービスでは 443) は、Web サーバーのリダイレクトに使用されます。Thus, the inbound port 80 (or 443 for the Service selected) is used in the redirection of the web server. Web サーバーで 8080 などの異なるポートがリッスンされている場合、[ターゲット リスト] フィールドを 10.0.1.4:8080 に更新して、ポートのリダイレクトも行うことができます。If the web server is listening on a different port like 8080, you can update the Target List field to 10.0.1.4:8080 to allow for the port redirection as well.

    • バックエンド ルールでは、任意のサービスを介した Web サーバーから AppVM01 サーバー (AppVM02 ではない) への通信を許可します。The back-end rule allows the web server to talk to the AppVM01 server, but not AppVM02, via Any service:

      Firewall AppVM01 Rule

      この通過ルールでは、フロントエンド サブネット上の IIS サーバーで任意のプロトコルを使用して任意のポートの AppVM01 (10.0.2.5) に到達し、Web アプリケーションでデータにアクセスできるようにします。This pass rule allows any IIS server on the front-end subnet to reach AppVM01 (10.0.2.5) on any port using any protocol so that data can be accessed by the web application.

      このスクリーンショットでは、[宛先] フィールドに <explicit-dest> が使用され、宛先として 10.0.2.5 が示されています。In this screenshot, <explicit-dest> is used in the Destination field to signify 10.0.2.5 as the destination. スクリーンショットに示すように、明示的に IP アドレスを指定できます。You can specify the IP address explicitly as shown in the screenshot. DNS サーバーの前提条件と同様に、名前付きネットワーク オブジェクトを使用することもできます。You can also use a named Network Object like in the prerequisites for the DNS server. ファイアウォール管理者は、使用する方法を選択できます。The firewall administrator can choose which method to use. 10.0.2.5 を明示的な宛先として追加するには、<explicit-dest> の下にある 1 つ目の空白行をダブルクリックし、開いたダイアログ ボックスにアドレスを入力します。To add 10.0.2.5 as an explicit destination, double-click on the first blank row under <explicit-dest> and enter the address in the dialog box that opens.

      この通過ルールでは、内部トラフィックが処理されるため、NAT は必要ありません。With this pass rule, no NAT is needed because it's handling internal traffic. [接続方法] を [No SNAT] に設定できます。You can set the Connection Method to No SNAT.

      注意

      このルールのソース ネットワークはフロントエンド サブネットの任意のリソースです (1 つしかない場合)。The Source network in this rule is any resource on the front-end subnet if there is only one. アーキテクチャが既知の数の Web サーバーを指定している場合は、ネットワーク オブジェクト リソースを作成し、フロントエンド サブネット全体ではなく、具体的に IP アドレスを指定することができます。If your architecture specifies a known number of web servers, you can create a Network Object resource to be more specific to those exact IP addresses instead of the entire front-end subnet.

      ヒント

      サンプル アプリケーションをより簡単に設定して使用できるように、このルールではサービスとして [Any] を使用します。This rule uses the service Any to make the sample application easier to setup and use. これにより、単一ルールで ICMPv4 (ping) が許可されます。It allows ICMPv4 (ping) in a single rule. しかし、この境界への攻撃面を減らすために、ポートとプロトコル サービスは、アプリケーションを操作できる可能な限り小さい値に制限することをお勧めします。However, to reduce the attack surface across this boundary, we recommend restricting the ports and protocols Services to the minimum possible that allow application operation.

      ヒント

      このルール例では <explicit-dest> 参照を使用しますが、ファイアウォール構成全体で一貫した方法を使用する必要があります。Although this example rule uses <explicit-dest> reference, you should use a consistent approach throughout the firewall configuration. 可読性と保守性の点から、名前付きネットワーク オブジェクトの使用をお勧めします。We recommended using a named Network Object for easier readability and supportability. ここで示す <explicit-dest> は、単に代替参照方法を示すためのものです。The <explicit-dest> shown here is only to show an alternative reference method. 通常、これは、特に複雑な構成ではお勧めできません。We don't generally recommended it, especially for complex configurations.

  • インターネットへのアウトバウンド規則:この通過ルールでは、任意のソース ネットワークから選択された宛先ネットワークへのトラフィックの通過を許可します。Outbound-to-internet rule: This pass rule allows traffic from any Source network to pass to the selected Destination networks. Barracuda NextGen Firewall では、通常、既定でこのルールが "オン" になりますが、無効状態の場合です。The Barracuda NextGen firewall usually has this rule "on" by default, but in a disabled state. このルールを右クリックして、Activate Rule コマンドにアクセスします。Right-click on this rule to access the Activate Rule command. スクリーンショットに示されているルールを変更し、バックエンドとフロントエンドのサブネットのネットワーク オブジェクトを、このルールのソース属性に追加します。Modify the rule shown in the screenshot to add the network objects for back-end and front-end subnets to the Source attribute of this rule. この記事の前提条件セクションで、これらのネットワーク オブジェクトを作成しました。You created these network objects in the prerequisite section of this article.

    Firewall Outbound Rule

  • DNS ルール:この通過ルールでは、DNS サーバーへの DNS (ポート 53) のトラフィックのみの通過を許可します。DNS rule: This pass rule allows only DNS (port 53) traffic to pass to the DNS server. この環境では、フロントエンドからバックエンドへのトラフィックは大部分がブロックされるため、このルールによって DNS トラフィックが明示的に許可されます。For this environment, most traffic from the front end to the back end is blocked so this rule specifically allows DNS traffic.

    Firewall DNS Rule

    注意

    このルールは内部 IP アドレス間のトラフィックを対象としており、NAT 経由の再ルーティングは不要であるため、[接続方法] は [No SNAT] に設定されています。The Connection Method is set to No SNAT because this rule is for internal IP to internal IP address traffic and no rerouting via NAT is required.

  • サブネット間ルール:この既定の通過ルールは有効になっており、バックエンド サブネット上の任意のサーバーから、フロントエンド サブネット上の任意のサーバーへの接続を許可するように変更が加えられています。Subnet-to-subnet rule: This default pass rule has been activated and modified to allow any server on the back-end subnet to connect to any server on the front-end subnet. このルールの対象は内部トラフィックのみであるため、[接続方法] は [No SNAT] に設定できます。This rule only coves internal traffic so the Connection Method can be set to No SNAT.

    Firewall Intra-VNet Rule

    注意

    [双方向] チェック ボックスがここではオンになっていないため、このルールは一方向のみで適用されます。The Bi-directional check box is not selected here so this rule applies in only one direction. バックエンド サブネットからフロントエンド ネットワークへの接続は開始できますが、その逆の接続は開始できません。A connection can be initiated from the back-end subnet to the front-end network, but not the reverse. そのチェック ボックスがオンになっていた場合、このルールによって、双方向トラフィックが有効になります。これは、論理図では望ましくないものとして示されています。If that check box were selected, this rule would enable bi-directional traffic, which we've specified as undesirable in our logical diagram.

  • 全トラフィック拒否ルール:優先度の観点から、これは常に最後のルールにする必要があります。Deny all traffic rule: This rule should always be the final rule in terms of priority. トラフィック フローが上記のいずれのルールとも一致しない場合、このルールによって破棄されます。If traffic flow does not match any of the preceding rules, this rule causes it to be dropped. 通常、ルールは既定でアクティブ化されているため、変更は必要ありません。The rule is commonly activated by default so no modifications are needed.

    Firewall Deny Rule

重要

上記のルールがすべて作成された後、各ルールの優先度を確認し、トラフィックの許可または拒否が意図したとおりになっていることを確かめてください。After all of the preceding rules are created, review the priority of each rule to ensure traffic is allowed or denied as desired. この例では、Barracuda 管理クライアントのメイン グリッドの転送ルールで表示される順序でルールがリストされています。For this example, the rules are listed in the order they should appear in the Barracuda Management client's main grid of forwarding rules.

ルールのアクティブ化Rule activation

論理図の仕様を満たすためにルール セットを変更した後、ルール セットをファイアウォールにアップロードしてアクティブ化する必要があります。After you've modified the rule set to meet the specifications of the logic diagram, you need to upload the rule set to the firewall and activate it.

Firewall Rule Activation

管理クライアント ウィンドウの右上隅を確認し、[Send Changes](変更の送信) を選択して、変更されたルールをファイアウォールにアップロードします。Look in the upper right corner of the management client window and select Send Changes to upload the modified rules to the firewall. [アクティブ化] を選択します。Select Activate.

ファイアウォール規則セットをアクティブ化したら、この例の環境は完了です。When you activate the firewall rule set, this example environment is complete.

トラフィックのシナリオTraffic scenarios

重要

すべてのトラフィックがファイアウォールを経由することに注意してください。Remember that all traffic comes through the firewall. IIS01 サーバーにリモート デスクトップ接続するには、ポート 8014 上のファイアウォールに接続してから、ファイアウォールで IIS01 RDP ポートに内部的に RDP 要求をルーティングできるようにします。To remote desktop to the IIS01 server, you need to connect to the firewall on port 8014 and then allow the firewall to route the RDP request internally to the IIS01 RDP port. Azure ポータルの [接続] ボタンは機能しません。これは、RDP で直接 IIS01 に到達する経路が、ポータルから見える範囲では存在しないためです。The Azure portal's Connect button won't work because there is no direct RDP path to IIS01 as far as the portal can see. インターネットからのすべての接続は、セキュリティ サービスとポート (secscv001.cloudapp.net:xxxx など) に対するものです。All connections from the internet are to the security service and a port (for example, secscv001.cloudapp.net:xxxx ). 外部ポートおよび内部 IP とポートのマッピングについては、上の図を参照してください。Reference the above diagram for the mapping of external port and internal IP and port.

以下のシナリオでは、次のファイアウォール ルールが設定されている必要があります。For these scenarios, the following firewall rules should be in place:

  1. ファイアウォール管理 (FW Mgmt)Firewall Management (FW Mgmt)
  2. IIS01 への RDPRDP to IIS01
  3. DNS01 への RDPRDP to DNS01
  4. AppVM01 への RDPRDP to AppVM01
  5. AppVM02 への RDPRDP to AppVM02
  6. Web へのアプリ トラフィックApp Traffic to the Web
  7. AppVM01 へのアプリ トラフィックApp Traffic to AppVM01
  8. インターネットへのアウトバウンドOutbound to the internet
  9. フロントエンドから DNS01Front end to DNS01
  10. サブネット間トラフィック (バックエンドからフロント エンドのみ)Intra-Subnet Traffic (back end to front end only)
  11. すべて拒否Deny All

実際のファイアウォール規則セットではほとんどの場合、この例のルールより多くのルールが必要になります。Your actual firewall rule set will most likely require more rules than those in this example. 異なる優先順位番号が使用される場合もあります。They're likely to have different priority numbers as well. 互いに相対的な優先順位について、このリストと関連する番号を参照する必要があります。You should refer to this list and associated numbers for their relative priority to each other. たとえば、"IIS01 への RDP" ルールは実際のファイアウォールでは番号が 5 である場合がありますが、それが "ファイアウォール管理" ルールよりも下でかつ "DNS01 への RDP" ルールよりも上であれば、セットはこのリストの意図と一致します。For example, the "RDP to IIS01" rule might be number 5 on the actual firewall, but as long as it’s below the "Firewall Management" rule and above the "RDP to DNS01" rule, the set aligns with the intention of this list. このリストは、以降のシナリオの手順を簡略化するのにも役立ちます。This list also helps simplify the instructions for scenarios that follow. たとえば、"ファイアウォール ルール 9 (DNS)" です。For example, "Firewall rule 9 (DNS)." トラフィック シナリオが RDP とは無関係である場合、4 つの RDP ルールを総称して "RDP ルール" と表記していることに注意してください。Be aware that the four RDP rules are collectively called "the RDP rules" when the traffic scenario is unrelated to RDP.

また、ネットワーク セキュリティ グループ (NSG) の適用先は、フロントエンド サブネットとバックエンド サブネットのインバウンド インターネット トラフィックであることを思い出してください。Also recall that network security groups (NSGs) are in place for inbound internet traffic on the front-end and back-end subnets.

(許可) インターネットから Web サーバー(Allowed) Internet to web server

  1. インターネット ユーザーが、SecSvc001.CloudApp.Net (インターネットに接続されたクラウド サービス) にある HTTP ページを要求します。An internet user requests HTTP page from SecSvc001.CloudApp.Net (internet-facing cloud service).
  2. クラウド サービスでは、ポート 80 上の開いているエンドポイントを介して、10.0.0.4:80 のファイアウォール インターフェイスにトラフィックを渡します。The cloud service passes traffic through an open endpoint on port 80 to the firewall interface on 10.0.0.4:80.
  3. セキュリティ サブネットに NSG は割り当てられていないため、システムの NSG ルールによってファイアウォールへのトラフィックが許可されます。No NSG is assigned to Security subnet so the system NSG rules allow the traffic to the firewall.
  4. トラフィックはファイアウォールの内部 IP アドレス (10.0.1.4) に到達します。The traffic hits an internal IP address of the firewall (10.0.1.4).
  5. ファイアウォールではルールの処理を行います。The firewall performs rule processing:
    1. ファイアウォール規則 1 (FW Mgmt) は適用されません。Firewall rule 1 (FW Mgmt) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. ファイアウォール規則 2 から 5 (RDP ルール) は適用されません。Firewall rules 2 - 5 (RDP rules) don’t apply. 次のルールに進みます。Move to next rule.
    3. ファイアウォール規則 6 (アプリ:Web) が適用されます。Firewall rule 6 (App: Web) does apply. トラフィックは許可されます。The traffic is allowed. ファイアウォールでは、10.0.1.4 (IIS01) に NAT 経由でトラフィックを再ルーティングします。Firewall reroutes the traffic via NAT to 10.0.1.4 (IIS01).
  6. フロントエンド サブネットでは、インバウンド ルールの処理を行います。The front-end subnet performs inbound rule processing:
    1. NSG ルール 1 (インターネットをブロック) は適用されません。NSG rule 1 (Block internet) doesn’t apply. ファイアウォールでこのトラフィックが NAT 経由で再ルーティングされたため、ソース アドレスは現在、ファイアウォールです。The firewall rerouted this traffic via NAT so the source address is now the firewall. ファイアウォールはセキュリティ サブネット上にあり、フロントエンド サブネットの NSG へのローカル トラフィックとして表示されるため、トラフィックは許可されます。Because the firewall is on the Security subnet and appears as local traffic to the front-end subnet NSG, the traffic is allowed. 次のルールに進みます。Move to next rule.
    2. 既定の NSG ルールではサブネット間トラフィックが許可されるため、このトラフィックは許可されます。Default NSG rules allow subnet-to-subnet traffic so this traffic is allowed. NSG ルールの処理はここで終了します。Stop NSG rule processing.
  7. IIS01 では Web トラフィックをリッスンします。IIS01 is listening for web traffic. この要求を受信し、要求の処理を開始します。It receives this request and starts processing the request.
  8. IIS01 で、バックエンド サブネットにある AppVM01 への FTP セッションの開始を試みます。IIS01 attempts to initiate an FTP session to AppVM01 on the back-end subnet.
  9. フロントエンド サブネット上の UDR ルートによって、ファイアウォールが次ホップに設定されます。The UDR route on front-end subnet makes the firewall the next hop.
  10. フロントエンド サブネットにアウトバウンド規則はないので、トラフィックは許可されます。There are no outbound rules on front-end subnet so the traffic is allowed.
  11. ファイアウォール ルールの処理が開始されます。Firewall begins rule processing:
    1. ファイアウォール規則 1 (FW Mgmt) は適用されません。Firewall rule 1 (FW Mgmt) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. ファイアウォール規則 2 から 5 (RDP ルール) は適用されません。Firewall rules 2 - 5 (RDP rules) don’t apply. 次のルールに進みます。Move to next rule.
    3. ファイアウォール規則 6 (アプリ:Web) は適用されません。Firewall rule 6 (App: Web) doesn't apply. 次のルールに進みます。Move to next rule.
    4. ファイアウォール規則 7 (アプリ: バックエンド) が適用されます。Firewall rule 7 (App: back end) does apply. トラフィックは許可されます。The traffic is allowed. ファイアウォールで 10.0.2.5 (AppVM01) にトラフィックが転送されます。The firewall forwards the traffic to 10.0.2.5 (AppVM01).
  12. バックエンド サブネットでは、インバウンド規則の処理を行います。The back-end subnet performs inbound rule processing:
    1. NSG ルール 1 (インターネットをブロック) は適用されません。NSG rule 1 (Block internet) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. 既定の NSG ルールではサブネット間トラフィックが許可されます。Default NSG rules allow subnet-to-subnet traffic. トラフィックは許可されます。The traffic is allowed. NSG ルールの処理はここで終了します。Stop NSG rule processing.
  13. AppVM01 で要求を受信し、セッションを開始して応答します。AppVM01 receives the request, initiates the session, and responds.
  14. バックエンド サブネット上の UDR ルートによって、ファイアウォールが次ホップに設定されます。The UDR route on back-end subnet makes the firewall the next hop.
  15. バックエンド サブネットにアウトバウンド NSG ルールは存在しないので、応答は許可されます。There are no outbound NSG rules on the back-end subnet so the response is allowed.
  16. これは、確立済みのセッション上の戻りトラフィックであるため、ファイアウォールでは Web サーバー (IIS01) に応答を戻します。Because it is returning traffic on an established session, the firewall passes the response back to the web server (IIS01).
  17. フロントエンド サブネットでは、インバウンド規則の処理を行います。Front-end subnet performs inbound rule processing:
    1. NSG ルール 1 (インターネットをブロック) は適用されません。NSG rule 1 (Block internet) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. 既定の NSG ルールではサブネット間トラフィックが許可されるため、このトラフィックは許可されます。The default NSG rules allow subnet-to-subnet traffic so this traffic is allowed. NSG ルールの処理はここで終了します。Stop NSG rule processing.
  18. IIS サーバーで応答を受信し、AppVM01 とのトランザクションを完了します。The IIS server receives the response and completes the transaction with AppVM01. その後、サーバーで HTTP 応答の構築を完了し、要求元に送信します。Then the server completes building the HTTP response and sends it to the requestor.
  19. フロントエンド サブネットにアウトバウンド NSG ルールは存在しないので、応答は許可されます。There are no outbound NSG rules on the front-end subnet so the response is allowed.
  20. HTTP 応答がファイアウォールに到達します。The HTTP response hits the firewall. これは確立済みの NAT セッションへの応答であるため、ファイアウォールでこれを受け入れます。Because it is a response to an established NAT session, the firewall accepts it.
  21. ファイアウォールで応答をリダイレクトしてインターネット ユーザーに返します。The firewall redirects the response back to the internet user.
  22. フロントエンド サブネットにアウトバウンド NSG ルールや UDR ホップは存在しないので、応答は許可されます。There are no outbound NSG rules or UDR hops on the front-end subnet so the response is allowed. インターネット ユーザーは要求された Web ページを受信します。The internet user receives the web page requested.

(許可) インターネットからバックエンドへの RDP(Allowed) Internet RDP to back end

  1. インターネット上のサーバー管理者は、SecSvc001.CloudApp.Net:8025 経由で AppVM01 への RDP セッションを要求します。A server admin on the internet requests an RDP session to AppVM01 via SecSvc001.CloudApp.Net:8025. 8025 は、ファイアウォール規則 4 (RDP AppVM01) でユーザーが割り当てたポート番号です。8025 is the user-assigned port number for the firewall rule 4 (RDP AppVM01).
  2. クラウド サービスでは、ポート 8025 上の開いているエンドポイントを介して、10.0.0.4:8025 のファイアウォール インターフェイスにトラフィックを渡します。The cloud service passes traffic through the open endpoint on port 8025 to firewall interface on 10.0.0.4:8025.
  3. セキュリティ サブネットに NSG は割り当てられていないため、システムの NSG ルールによってファイアウォールへのトラフィックが許可されます。No NSG is assigned to Security subnet so system NSG rules allow traffic to the firewall.
  4. ファイアウォールではルールの処理を行います。The firewall performs rule processing:
    1. ファイアウォール規則 1 (FW Mgmt) は適用されません。Firewall rule 1 (FW Mgmt) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. ファイアウォール規則 2 (RDP IIS) は適用されません。Firewall rule 2 (RDP IIS) doesn’t apply. 次のルールに進みます。Move to next rule.
    3. ファイアウォール規則 3 (RDP DNS01) は適用されません。Firewall rule 3 (RDP DNS01) doesn’t apply. 次のルールに進みます。Move to next rule.
    4. ファイアウォール規則 4 (RDP AppVM01) が適用されるため、トラフィックは許可されます。Firewall rule 4 (RDP AppVM01) does apply so traffic is allowed. ファイアウォールでは、それを NAT 経由で 10.0.2.5:3386 (AppVM01 の RDP ポート) に再ルーティングします。The firewall reroutes it via NAT to 10.0.2.5:3386 (RDP port on AppVM01).
  5. バックエンド サブネットでは、インバウンド規則の処理を行います。The back-end subnet performs inbound rule processing:
    1. NSG ルール 1 (インターネットをブロック) は適用されません。NSG rule 1 (Block internet) doesn’t apply. ファイアウォールでこのトラフィックが NAT 経由で再ルーティングされたため、ソース アドレスは現在、セキュリティ サブネット上にあるファイアウォールです。The firewall rerouted this traffic via NAT so the source address is now the firewall that is on the Security subnet. これは、バックエンド サブネットの NSG によってローカル トラフィックと見なされ、許可されます。It's seen by the back-end subnet NSG to be local traffic and is allowed. 次のルールに進みます。Move to next rule.
    2. 既定の NSG ルールではサブネット間トラフィックが許可されるため、このトラフィックは許可されます。Default NSG rules allow subnet-to-subnet traffic so this traffic is allowed. NSG ルールの処理はここで終了します。Stop NSG rule processing.
  6. AppVM01 が RDP トラフィックをリッスンして応答します。AppVM01 is listening for RDP traffic and responds.
  7. アウトバウンド NSG ルールはないため、既定のルールが適用されます。There are no outbound NSG rules so default rules apply. 戻りトラフィックは許可されます。Return traffic is allowed.
  8. UDR では、アウトバウンド トラフィックを次ホップであるファイアウォールにルーティングします。UDR routes outbound traffic to the firewall as the next hop.
  9. これは、確立済みのセッション上の戻りトラフィックであるため、ファイアウォールではインターネット ユーザーに応答を戻します。Because it is returning traffic on an established session, the firewall passes the response back to the internet user.
  10. RDP セッションが有効になります。RDP session is enabled.
  11. AppVM01 でユーザー名とパスワードを求めるメッセージが表示されます。AppVM01 prompts for user name password.

(許可) DNS サーバーに対する Web サーバーの DNS 参照(Allowed) Web server DNS lookup on DNS server

  1. Web サーバー IIS01 で http://www.data.gov にあるデータ フィードを要求していますが、アドレスを解決する必要があります。Web server IIS01 requests a data feed at http://www.data.gov, but needs to resolve the address.
  2. 仮想ネットワーク用のネットワーク構成では、プライマリ DNS サーバーとして DNS01 (バックエンド サブネット上の 10.0.2.4) がリストされています。The network configuration for the virtual network lists DNS01 (10.0.2.4 on the back-end subnet) as the primary DNS server. IIS01 は DNS 要求を DNS01 に送信します。IIS01 sends the DNS request to DNS01.
  3. UDR では、アウトバウンド トラフィックを次ホップであるファイアウォールにルーティングします。UDR routes outbound traffic to the firewall as the next hop.
  4. フロントエンド サブネットにアウトバウンド NSG ルールはバインドされません。No outbound NSG rules are bound to the front-end subnet. トラフィックは許可されます。The traffic is allowed.
  5. ファイアウォールでルールの処理を行います。Firewall performs rule processing:
    1. ファイアウォール規則 1 (FW Mgmt) は適用されません。Firewall rule 1 (FW Mgmt) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. ファイアウォール規則 2 から 5 (RDP ルール) は適用されません。Firewall rule 2 - 5 (RDP Rules) don’t apply. 次のルールに進みます。Move to next rule.
    3. ファイアウォール規則 6 と 7 (アプリ ルール) は適用されません。Firewall rules 6 & 7 (App Rules) don’t apply. 次のルールに進みます。Move to next rule.
    4. ファイアウォール規則 8 (インターネットへの) は適用されません。Firewall rule 8 (To internet) doesn’t apply. 次のルールに進みます。Move to next rule.
    5. ファイアウォール規則 9 (DNS) は適用されます。Firewall rule 9 (DNS) does apply. トラフィックは許可されます。The traffic is allowed. ファイアウォールで 10.0.2.4 (DNS01) にトラフィックが転送されます。Firewall forwards the traffic to 10.0.2.4 (DNS01).
  6. バックエンド サブネットでは、インバウンド規則の処理を行います。The back-end subnet performs inbound rule processing:
    1. NSG ルール 1 (インターネットをブロック) は適用されません。NSG rule 1 (Block internet) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. 既定の NSG ルールではサブネット間トラフィックが許可されます。Default NSG rules allow subnet-to-subnet traffic. トラフィックは許可されます。The traffic is allowed. NSG ルールの処理はここで終了します。Stop NSG rule processing.
  7. DNS サーバーが要求を受信します。The DNS server receives the request.
  8. DNS サーバーではアドレスがキャッシュされておらず、インターネット上のルート DNS サーバーに要求します。The DNS server doesn’t have the address cached and asks a root DNS server on the internet.
  9. UDR ではアウトバウンド トラフィックを、次ホップであるファイアウォールにルーティングします。UDR routes the outbound traffic to the firewall as the next hop.
  10. バックエンド サブネットにアウトバウンド NSG ルールはないので、トラフィックは許可されます。There are no outbound NSG rules on back-end subnet to the traffic is allowed.
  11. ファイアウォールでルールの処理を行います。Firewall performs rule processing:
    1. ファイアウォール規則 1 (FW Mgmt) は適用されません。Firewall rule 1 (FW Mgmt) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. ファイアウォール規則 2 から 5 (RDP ルール) は適用されません。Firewall rule 2 - 5 (RDP Rules) don’t apply. 次のルールに進みます。Move to next rule.
    3. ファイアウォール規則 6 と 7 (アプリ ルール) は適用されません。Firewall rules 6 & 7 (App Rules) don’t apply. 次のルールに進みます。Move to next rule.
    4. ファイアウォール規則 8 (インターネットへの) は適用されます。Firewall rule 8 (to the internet) does apply. トラフィックは許可されます。The traffic is allowed. セッションは SNAT 経由で、インターネット上のルート DNS サーバーに再ルーティングされます。The session is rerouted via SNAT to the root DNS server on the internet.
  12. インターネット DNS サーバーが応答します。The internet DNS server responds. このセッションはファイアウォールから開始されたため、ファイアウォールで応答が受け入れられます。This session was initiated from the firewall so the response is accepted by the firewall.
  13. このセッションは既に確立されているため、ファイアウォールで開始元のサーバーである DNS01 に応答が転送されます。This session is already established so the firewall forwards the response to the initiating server, DNS01.
  14. バックエンド サブネットでは、インバウンド規則の処理を行います。The back-end subnet performs inbound rule processing:
    1. NSG ルール 1 (インターネットをブロック) は適用されません。NSG rule 1 (Block internet) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. 既定の NSG ルールではサブネット間トラフィックが許可されるため、このトラフィックは許可されます。Default NSG rules allow subnet-to-subnet traffic to this traffic is allowed. NSG ルールの処理はここで終了します。Stop NSG rule processing.
  15. DNS サーバーで応答を受信し、キャッシュしてから、最初の要求に応答して IIS01 に戻します。The DNS server receives and caches the response, and then responds to the initial request back to IIS01.
  16. バックエンド サブネット上の UDR ルートによって、ファイアウォールが次ホップに設定されます。The UDR route on back-end subnet makes the firewall the next hop.
  17. バックエンド サブネットにアウトバウンド NSG ルールは存在しないので、トラフィックは許可されます。No outbound NSG rules exist on the back-end subnet so the traffic is allowed.
  18. このセッションはファイアウォール上で既に確立されているため、ファイアウォールで応答が再ルーティングされ、IIS サーバーに戻されます。This session is already established on the firewall so the firewall reroutes the response back to the IIS server.
  19. フロントエンド サブネットでは、インバウンド ルールの処理を行います。The front-end subnet performs inbound rule processing:
    1. バックエンド サブネットからフロントエンド サブネットへのインバウンド トラフィックの NSG ルールはないため、どの NSG ルールも適用されません。There's no NSG rule for inbound traffic from the back-end subnet to the front-end subnet so none of the NSG rules apply.
    2. 既定のシステム ルールでは、サブネット間トラフィックが許可されます。The default system rule allows traffic between subnets. トラフィックは許可されます。The traffic is allowed.
  20. IIS01 が DNS01 から応答を受信します。IIS01 receives the response from DNS01.

(許可) バックエンド サーバーからフロントエンド サーバー(Allowed) Back-end server to front-end server

  1. RDP 経由で AppVM02 にログオンしている管理者は、Windows エクスプローラーで IIS01 サーバーから直接ファイルを要求します。An administrator logged on to AppVM02 via RDP requests a file directly from the IIS01 server via windows file explorer.
  2. バックエンド サブネット上の UDR ルートによって、ファイアウォールが次ホップに設定されます。The UDR route on back-end subnet makes the firewall the next hop.
  3. バックエンド サブネットにアウトバウンド NSG ルールは存在しないので、応答は許可されます。There are no outbound NSG rules on the back-end subnet so the response is allowed.
  4. ファイアウォールではルールの処理を行います。The firewall performs rule processing:
    1. ファイアウォール規則 1 (FW Mgmt) は適用されません。Firewall rule 1 (FW Mgmt) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. ファイアウォール規則 2 から 5 (RDP ルール) は適用されません。Firewall rule 2 - 5 (RDP rules) don’t apply. 次のルールに進みます。Move to next rule.
    3. ファイアウォール規則 6 と 7 (アプリ ルール) は適用されません。Firewall rules 6 & 7 (App rules) don’t apply. 次のルールに進みます。Move to next rule.
    4. ファイアウォール規則 8 (インターネットへの) は適用されません。Firewall rule 8 (To internet) doesn’t apply. 次のルールに進みます。Move to next rule.
    5. ファイアウォール規則 9 (DNS) は適用されません。Firewall rule 9 (DNS) doesn’t apply. 次のルールに進みます。Move to next rule.
    6. ファイアウォール規則 10 (サブネット間) が適用されます。Firewall rule 10 (Intra-Subnet) does apply. トラフィックは許可されます。The traffic is allowed. ファイアウォールで 10.0.1.4 (IIS01) にトラフィックが渡されます。The firewall passes traffic to 10.0.1.4 (IIS01).
  5. フロントエンド サブネットで、以下に示すインバウンド規則の処理が開始されます。The front-end subnet begins inbound rule processing:
    1. NSG ルール 1 (インターネットをブロック) は適用されません。次のルールに進みますNSG Rule 1 (Block internet) doesn’t apply, move to next rule
    2. 既定の NSG ルールではサブネット間トラフィックが許可されるため、トラフィックは許可されます。The default NSG rules allow subnet-to-subnet traffic so the traffic is allowed. NSG ルールの処理はここで終了します。Stop NSG rule processing.
  6. 適切な認証および承認であると仮定し、IIS01 で要求を受け入れて応答します。Assuming proper authentication and authorization, IIS01 accepts the request and responds.
  7. フロントエンド サブネット上の UDR ルートによって、ファイアウォールが次ホップに設定されます。The UDR route on the front-end subnet makes the firewall the next hop.
  8. フロントエンド サブネットにアウトバウンド NSG ルールはないため、応答は許可されます。There are no outbound NSG rules on the front-end subnet so the response is allowed.
  9. このセッションは既にファイアウォール上に存在するため、この応答は許可されます。This session already exists on the firewall so this response is allowed. ファイアウォールで AppVM02 に応答が返されます。The firewall returns the response to AppVM02.
  10. バックエンド サブネットでは、インバウンド規則の処理を行います。The back-end subnet performs inbound rule processing:
    1. NSG ルール 1 (インターネットをブロック) は適用されません。NSG rule 1 (Block internet) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. 既定の NSG ルールではサブネット間トラフィックが許可されるため、トラフィックは許可されます。The default NSG Rules allow subnet-to-subnet traffic so the traffic is allowed. NSG ルールの処理はここで終了します。Stop NSG rule processing.
  11. AppVM02 で応答が受信されます。AppVM02 receives the response.

(拒否) Web サーバーへの直接インターネット アクセス(Denied) Internet direct to web server

  1. インターネット ユーザーが、FrontEnd001.CloudApp.Net サービスを介して IIS01 Web サーバーへのアクセスを試みます。An internet user tries to access the IIS01 web server through the FrontEnd001.CloudApp.Net service.
  2. HTTP トラフィック用に開かれたエンドポイントはないため、このトラフィックはクラウドサービスを通過しません。There are no endpoints open for HTTP traffic so this traffic doesn't pass through the cloud service. トラフィックはサーバーに到達しません。The traffic doesn't reach the server.
  3. 何らかの理由でエンドポイントが開かれている場合、フロントエンド サブネットの NSG (インターネットをブロック) によって、このトラフィックはブロックされます。If the endpoints are open for some reason, the NSG (Block internet) on the front-end subnet blocks this traffic.
  4. 最後に、フロントエンド サブネットの UDR ルートで、IIS01 からのアウトバウンド トラフィックはすべて、次ホップであるファイアウォールに送信されます。Finally, the front-end subnet UDR route sends any outbound traffic from IIS01 to the firewall as the next hop. ファイアウォールではそれが非対称トラフィックと見なされ、アウトバウンド応答は破棄されます。The firewall sees it as asymmetric traffic and drops the outbound response.

そのため、インターネットと IIS01 間には、少なくとも 3 つの独立した防御層があります。Thus, there are at least three independent layers of defense between the internet and IIS01. クラウド サービスで、未承認アクセスや不適切なアクセスを防ぎます。The cloud service prevents unauthorized or inappropriate access.

(拒否) インターネットからバックエンド サーバー(Denied) Internet to back-end server

  1. インターネット ユーザーが、BackEnd001.CloudApp.Net サービスを介して AppVM01 上のファイルにアクセスを試みます。An internet user tries to access a file on AppVM01 through the BackEnd001.CloudApp.Net service.
  2. ファイル共有のために開かれたエンドポイントはないため、この要求でクラウド サービスは渡されません。There are no endpoints open for file sharing so this request doesn't pass the cloud service. トラフィックはサーバーに到達しません。The traffic doesn't reach the server.
  3. 何らかの理由でエンドポイントが開かれている場合、NSG (インターネットをブロック) でこのトラフィックはブロックされます。If the endpoints are open for some reason, the NSG (Block internet) blocks this traffic.
  4. 最後に、UDR ルートで、AppVM01 からのアウトバウンド トラフィックはすべて、次ホップであるファイアウォールに送信されます。Finally, the UDR route sends any outbound traffic from AppVM01 to the firewall as the next hop. ファイアウォールではそれが非対称トラフィックと見なされ、アウトバウンド応答は破棄されます。The firewall sees it as asymmetric traffic and drops the outbound response.

そのため、インターネットと AppVM01 間には、少なくとも 3 つの独立した防御層があります。Thus, there are at least three independent layers of defense between the internet and AppVM01. クラウド サービスで、未承認アクセスや不適切なアクセスを防ぎます。The cloud service prevents unauthorized or inappropriate access.

(拒否) フロントエンド サーバーからバックエンド サーバー(Denied) Front-end server to back-end server

  1. IIS01 のセキュリティが侵害され、バックエンド サブネット サーバーをスキャンしようとする悪質なコードが実行されています。IIS01 is compromised and is running malicious code trying to scan the back-end subnet servers.
  2. フロントエンド サブネットの UDR ルートで、IIS01 からのアウトバウンド トラフィックはすべて、次ホップであるファイアウォールに送信されます。The front-end subnet UDR route sends any outbound traffic from IIS01 to the firewall as the next hop. 侵害された VM でこのルーティングを変更することはできません。The compromised VM can't alter this routing.
  3. ファイアウォールでトラフィックが処理されます。The firewall processes the traffic. 要求が AppVM01、または DNS ルックアップ用の DNS サーバーに対するものである場合、ファイアウォールでトラフィックが許可される可能性があります。これは、ファイアウォール規則 7 と 9 によるものです。If the request is to AppVM01 or to the DNS server for DNS lookups, the firewall might potentially allow the traffic because of Firewall rules 7 and 9. 他のすべてのトラフィックは、ファイアウォール規則 11 (すべて拒否) によってブロックされます。All other traffic is blocked by Firewall rule 11 (Deny All).
  4. ファイアウォールで高度な脅威検出を有効にすると、高度な脅威ルールにフラグを付ける既知のシグネチャまたはパターンを含むトラフィックを防ぐことができます。If you enable advanced threat detection on the firewall, traffic that contains known signatures or patterns that flag an advanced threat rule could be prevented. この記事で説明されている基本的な転送ルールに従って、トラフィックが許可されている場合でも、この方法を使用できます。This measure can work even if the traffic is allowed according to the basic forwarding rules that are discussed in this article. 高度な脅威検出については、このドキュメントでは説明しません。Advanced threat detection isn't covered in this document. 特定のネットワーク アプライアンスの高度な脅威機能については、ベンダーのドキュメントを参照してください。See the vendor documentation for your specific network appliance advanced threat capabilities.

(拒否) インターネットから DNS サーバーへの DNS 参照(Denied) Internet DNS lookup on DNS server

  1. インターネット ユーザーが、BackEnd001.CloudApp.Net サービスを介して、DNS01 上の内部 DNS レコードを参照しようとしています。An internet user tries to look up an internal DNS record on DNS01 through BackEnd001.CloudApp.Net service.
  2. DNS トラフィック用に開かれたエンドポイントはないため、このトラフィックはクラウドサービスを通過しません。Since there are no endpoints open for DNS traffic, this traffic doesn't pass through the cloud service. サーバーには到達しません。It doesn't reach the server.
  3. 何らかの理由でエンドポイントが開かれている場合、フロントエンド サブネットの NSG ルール (インターネットをブロック) によって、このトラフィックはブロックされます。If the endpoints are open for some reason, the NSG rule (Block internet) on the front-end subnet blocks this traffic.
  4. 最後に、バックエンド サブネットの UDR ルートで、DNS01 からのアウトバウンド トラフィックはすべて、次ホップであるファイアウォールに送信されます。Finally, the back-end subnet UDR route sends any outbound traffic from DNS01 to the firewall as the next hop. ファイアウォールではこれが非対称トラフィックと見なされ、アウトバウンド応答は破棄されます。The firewall sees this as asymmetric traffic and drops the outbound response.

そのため、インターネットと DNS01 間には、少なくとも 3 つの独立した防御層があります。Thus, there are at least three independent layers of defense between the internet and DNS01. クラウド サービスで、未承認アクセスや不適切なアクセスを防ぎます。The cloud service prevents unauthorized or inappropriate access.

(拒否) インターネットからファイアウォールを経由して SQL にアクセス(Denied) Internet to SQL access through firewall

  1. インターネット ユーザーが、SecSvc001.CloudApp.Net というインターネットに接続されたクラウド サービスにある SQL データを要求します。An internet user requests SQL data from the SecSvc001.CloudApp.Net internet-facing cloud service.
  2. SQL 用に開かれたエンドポイントはないため、このトラフィックはクラウド サービスを通過しません。There are no endpoints open for SQL so this traffic doesn't pass the cloud service. ファイアウォールには到達しません。It doesn't reach the firewall.
  3. 何らかの理由で SQL エンドポイントが開かれている場合、ファイアウォールでルールの処理が行われます。If SQL endpoints are open for some reason, the firewall performs rule processing:
    1. ファイアウォール規則 1 (FW Mgmt) は適用されません。Firewall rule 1 (FW Mgmt) doesn’t apply. 次のルールに進みます。Move to next rule.
    2. ファイアウォール規則 2 から 5 (RDP ルール) は適用されません。Firewall rules 2 - 5 (RDP Rules) don’t apply. 次のルールに進みます。Move to next rule.
    3. ファイアウォール規則 6 と 7 (アプリケーション ルール) は適用されません。Firewall rules 6 & 7 (Application Rules) don’t apply. 次のルールに進みます。Move to next rule.
    4. ファイアウォール規則 8 (インターネットへの) は適用されません。Firewall rule 8 (To internet) doesn’t apply. 次のルールに進みます。Move to next rule.
    5. ファイアウォール規則 9 (DNS) は適用されません。Firewall rule 9 (DNS) doesn’t apply. 次のルールに進みます。Move to next rule.
    6. ファイアウォール規則 10 (サブネット間) は適用されません。Firewall rule 10 (Intra-Subnet) doesn’t apply. 次のルールに進みます。Move to next rule.
    7. ファイアウォール規則 11 (すべて拒否) が適用されます。Firewall rule 11 (Deny All) does apply. トラフィックはブロックされます。Traffic is blocked. ルールの処理はここで終了します。Stop rule processing.

参照References

このセクションには以下の項目が含まれます。This section contains the following items:

  • 完全なスクリプト。Full script. PowerShell スクリプト ファイルに保存します。Save it in a PowerShell script file.
  • ネットワーク構成。NetworkConf2.xml という名前のファイルに保存します。Network Config. Save it into a file named NetworkConf2.xml.

必要に応じて、ファイル内のユーザー定義変数を変更します。Modify the user-defined variables in the files as needed. スクリプトを実行してから、この記事の前半でリストされているファイアウォール規則の設定手順に従ってください。Run the script, and then follow the Firewall rule setup instructions listed earlier in this article.

完全なスクリプトFull script

ユーザー定義変数を設定した後、このスクリプトを実行して以下のことを行います。After setting the user-defined variables, run this script to:

  1. Azure サブスクリプションに接続するConnect to an Azure subscription
  2. 新しいストレージ アカウントの作成Create a new storage account
  3. ネットワーク構成ファイルの定義に従って、新しい仮想ネットワークを 1 つと、サブネットを 3 つ作成するCreate a new virtual network and three subnets as defined in the Network Config file
  4. 仮想マシンを 5 つ構築する: ファイアウォール用に 1 つと Windows Server VM 用に 4 つBuild five virtual machines: a firewall and four Windows Server VMs
  5. UDR を構成する:Configure UDR:
    1. 新しいルート テーブルを 2 つ作成するCreate two new route tables
    2. テーブルにルートを追加Add routes to the tables
    3. 適切なサブネットにテーブルをバインドBind tables to appropriate subnets
  6. ネットワーク仮想アプライアンスで IP 転送を有効にするEnable IP Forwarding on the NVA
  7. NSG を構成する:Configure NSG:
    1. NSG を作成するCreate an NSG
    2. 規則を追加するAdd a rule
    3. 適切なサブネットに NSG をバインドするBind the NSG to the appropriate subnets

この PowerShell スクリプトを、インターネットに接続されている PC またはサーバー上でローカルに実行します。Run this PowerShell script locally on an internet connected PC or server.

重要

このスクリプトを実行すると、PowerShell に警告またはその他の情報メッセージがポップアップ表示される場合があります。When you run this script, warnings or other informational messages might pop up in PowerShell. 赤色のエラー メッセージのみが問題の原因となります。Only red error messages are cause for concern.

    <#
     .SYNOPSIS
      Example of DMZ and User Defined Routing in an isolated network (Azure only, no hybrid connections)

     .DESCRIPTION
      This script will build out a sample DMZ setup containing:
       - A default storage account for VM disks
       - Three new cloud services
       - Three Subnets (SecNet, FrontEnd, and BackEnd subnets)
       - A Network Virtual Appliance (NVA), in this case a Barracuda NextGen Firewall
       - One server on the FrontEnd Subnet
       - Three Servers on the BackEnd Subnet
       - IP Forwarding from the FireWall out to the internet
       - User Defined Routing FrontEnd and BackEnd Subnets to the NVA

      Before running script, ensure the network configuration file is created in
      the directory referenced by $NetworkConfigFile variable (or update the
      variable to reflect the path and file name of the config file being used).

     .Notes
      Everyone's security requirements are different and can be addressed in a myriad of ways.
      Please be sure that any sensitive data or applications are behind the appropriate
      layer(s) of protection. This script serves as an example of some of the techniques
      that can be used, but should not be used for all scenarios. You are responsible to
      assess your security needs and the appropriate protections needed, and then effectively
      implement those protections.

      Security Service (SecNet subnet 10.0.0.0/24)
       myFirewall - 10.0.0.4

      FrontEnd Service (FrontEnd subnet 10.0.1.0/24)
       IIS01      - 10.0.1.4

      BackEnd Service (BackEnd subnet 10.0.2.0/24)
       DNS01      - 10.0.2.4
       AppVM01    - 10.0.2.5
       AppVM02    - 10.0.2.6

    #>

    # Fixed Variables
        $LocalAdminPwd = Read-Host -Prompt "Enter Local Admin Password to be used for all VMs"
        $VMName = @()
        $ServiceName = @()
        $VMFamily = @()
        $img = @()
        $size = @()
        $SubnetName = @()
        $VMIP = @()

    # User Defined Global Variables
      # These should be changes to reflect your subscription and services
      # Invalid options will fail in the validation section

      # Subscription Access Details
        $subID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

      # VM Account, Location, and Storage Details
        $LocalAdmin = "theAdmin"
        $DeploymentLocation = "Central US"
        $StorageAccountName = "vmstore02"

      # Service Details
        $SecureService = "SecSvc001"
        $FrontEndService = "FrontEnd001"
        $BackEndService = "BackEnd001"

      # Network Details
        $VNetName = "CorpNetwork"
        $VNetPrefix = "10.0.0.0/16"
        $SecNet = "SecNet"
        $FESubnet = "FrontEnd"
        $FEPrefix = "10.0.1.0/24"
        $BESubnet = "BackEnd"
        $BEPrefix = "10.0.2.0/24"
        $NetworkConfigFile = "C:\Scripts\NetworkConf3.xml"

      # VM Base Disk Image Details
        $SrvImg = Get-AzureVMImage | Where {$_.ImageFamily -match 'Windows Server 2012 R2 Datacenter'} | sort PublishedDate -Descending | Select ImageName -First 1 | ForEach {$_.ImageName}
        $FWImg = Get-AzureVMImage | Where {$_.ImageFamily -match 'Barracuda NextGen Firewall'} | sort PublishedDate -Descending | Select ImageName -First 1 | ForEach {$_.ImageName}

      # UDR Details
        $FERouteTableName = "FrontEndSubnetRouteTable"
        $BERouteTableName = "BackEndSubnetRouteTable"

      # NSG Details
        $NSGName = "MyVNetSG"

    # User Defined VM Specific Config
        # Note: To ensure UDR and IP forwarding is setup
        # properly this script requires VM 0 be the NVA.

        # VM 0 - The Network Virtual Appliance (NVA)
          $VMName += "myFirewall"
          $ServiceName += $SecureService
          $VMFamily += "Firewall"
          $img += $FWImg
          $size += "Small"
          $SubnetName += $SecNet
          $VMIP += "10.0.0.4"

        # VM 1 - The Web Server
          $VMName += "IIS01"
          $ServiceName += $FrontEndService
          $VMFamily += "Windows"
          $img += $SrvImg
          $size += "Standard_D3"
          $SubnetName += $FESubnet
          $VMIP += "10.0.1.4"

        # VM 2 - The First Application Server
          $VMName += "AppVM01"
          $ServiceName += $BackEndService
          $VMFamily += "Windows"
          $img += $SrvImg
          $size += "Standard_D3"
          $SubnetName += $BESubnet
          $VMIP += "10.0.2.5"

        # VM 3 - The Second Application Server
          $VMName += "AppVM02"
          $ServiceName += $BackEndService
          $VMFamily += "Windows"
          $img += $SrvImg
          $size += "Standard_D3"
          $SubnetName += $BESubnet
          $VMIP += "10.0.2.6"

        # VM 4 - The DNS Server
          $VMName += "DNS01"
          $ServiceName += $BackEndService
          $VMFamily += "Windows"
          $img += $SrvImg
          $size += "Standard_D3"
          $SubnetName += $BESubnet
          $VMIP += "10.0.2.4"

    # ----------------------------- #
    # No User Defined Variables or   #
    # Configuration past this point #
    # ----------------------------- #

      # Get your Azure accounts
        Add-AzureAccount
        Set-AzureSubscription –SubscriptionId $subID -ErrorAction Stop
        Select-AzureSubscription -SubscriptionId $subID -Current -ErrorAction Stop

      # Create Storage Account
        If (Test-AzureName -Storage -Name $StorageAccountName) {
            Write-Host "Fatal Error: This storage account name is already in use, please pick a different name." -ForegroundColor Red
            Return}
        Else {Write-Host "Creating Storage Account" -ForegroundColor Cyan
              New-AzureStorageAccount -Location $DeploymentLocation -StorageAccountName $StorageAccountName}

      # Update Subscription Pointer to New Storage Account
        Write-Host "Updating Subscription Pointer to New Storage Account" -ForegroundColor Cyan 
        Set-AzureSubscription –SubscriptionId $subID -CurrentStorageAccountName $StorageAccountName -ErrorAction Stop

    # Validation
    $FatalError = $false

    If (-Not (Get-AzureLocation | Where {$_.DisplayName -eq $DeploymentLocation})) {
         Write-Host "This Azure Location was not found or available for use" -ForegroundColor Yellow
         $FatalError = $true}

    If (Test-AzureName -Service -Name $SecureService) { 
        Write-Host "The SecureService service name is already in use, please pick a different service name." -ForegroundColor Yellow
        $FatalError = $true}
    Else { Write-Host "The FrontEndService service name is valid for use." -ForegroundColor Green}

    If (Test-AzureName -Service -Name $FrontEndService) { 
        Write-Host "The FrontEndService service name is already in use, please pick a different service name." -ForegroundColor Yellow
        $FatalError = $true}
    Else { Write-Host "The FrontEndService service name is valid for use" -ForegroundColor Green}

    If (Test-AzureName -Service -Name $BackEndService) { 
        Write-Host "The BackEndService service name is already in use, please pick a different service name." -ForegroundColor Yellow
        $FatalError = $true}
    Else { Write-Host "The BackEndService service name is valid for use." -ForegroundColor Green}

    If (-Not (Test-Path $NetworkConfigFile)) { 
        Write-Host 'The network config file was not found, please update the $NetworkConfigFile variable to point to the network config xml file.' -ForegroundColor Yellow
        $FatalError = $true}
    Else { Write-Host "The network config file was found" -ForegroundColor Green
            If (-Not (Select-String -Pattern $DeploymentLocation -Path $NetworkConfigFile)) {
                Write-Host 'The deployment location was not found in the network config file, please check the network config file to ensure the $DeploymentLocation variable is correct and the network config file matches.' -ForegroundColor Yellow
                $FatalError = $true}
            Else { Write-Host "The deployment location was found in the network config file." -ForegroundColor Green}}

    If ($FatalError) {
        Write-Host "A fatal error has occurred, please see the above messages for more information." -ForegroundColor Red
        Return}
    Else { Write-Host "Validation passed, now building the environment." -ForegroundColor Green}

    # Create VNET
        Write-Host "Creating VNET" -ForegroundColor Cyan 
        Set-AzureVNetConfig -ConfigurationPath $NetworkConfigFile -ErrorAction Stop

    # Create Services
        Write-Host "Creating Services" -ForegroundColor Cyan
        New-AzureService -Location $DeploymentLocation -ServiceName $SecureService -ErrorAction Stop
        New-AzureService -Location $DeploymentLocation -ServiceName $FrontEndService -ErrorAction Stop
        New-AzureService -Location $DeploymentLocation -ServiceName $BackEndService -ErrorAction Stop

    # Build VMs
        $i=0
        $VMName | Foreach {
            Write-Host "Building $($VMName[$i])" -ForegroundColor Cyan
            If ($VMFamily[$i] -eq "Firewall") 
                { 
                New-AzureVMConfig -Name $VMName[$i] -ImageName $img[$i] –InstanceSize $size[$i] | `
                    Add-AzureProvisioningConfig -Linux -LinuxUser $LocalAdmin -Password $LocalAdminPwd  | `
                    Set-AzureSubnet  –SubnetNames $SubnetName[$i] | `
                    Set-AzureStaticVNetIP -IPAddress $VMIP[$i] | `
                    New-AzureVM –ServiceName $ServiceName[$i] -VNetName $VNetName -Location $DeploymentLocation
                # Set up all the EndPoints we'll need once we're up and running
                # Note: All traffic goes through the firewall, so we'll need to set up all ports here.
                #       Also, the firewall will be redirecting traffic to a new IP and Port in a forwarding
                #       rule, so all of these endpoint have the same public and local port and the firewall
                #       will do the mapping, NATing, and/or redirection as declared in the firewall rules.
                Add-AzureEndpoint -Name "MgmtPort1" -Protocol tcp -PublicPort 801  -LocalPort 801  -VM (Get-AzureVM -ServiceName $ServiceName[$i] -Name $VMName[$i]) | Update-AzureVM
                Add-AzureEndpoint -Name "MgmtPort2" -Protocol tcp -PublicPort 807  -LocalPort 807  -VM (Get-AzureVM -ServiceName $ServiceName[$i] -Name $VMName[$i]) | Update-AzureVM
                Add-AzureEndpoint -Name "HTTP"      -Protocol tcp -PublicPort 80   -LocalPort 80   -VM (Get-AzureVM -ServiceName $ServiceName[$i] -Name $VMName[$i]) | Update-AzureVM
                Add-AzureEndpoint -Name "RDPWeb"    -Protocol tcp -PublicPort 8014 -LocalPort 8014 -VM (Get-AzureVM -ServiceName $ServiceName[$i] -Name $VMName[$i]) | Update-AzureVM
                Add-AzureEndpoint -Name "RDPApp1"   -Protocol tcp -PublicPort 8025 -LocalPort 8025 -VM (Get-AzureVM -ServiceName $ServiceName[$i] -Name $VMName[$i]) | Update-AzureVM
                Add-AzureEndpoint -Name "RDPApp2"   -Protocol tcp -PublicPort 8026 -LocalPort 8026 -VM (Get-AzureVM -ServiceName $ServiceName[$i] -Name $VMName[$i]) | Update-AzureVM
                Add-AzureEndpoint -Name "RDPDNS01"  -Protocol tcp -PublicPort 8024 -LocalPort 8024 -VM (Get-AzureVM -ServiceName $ServiceName[$i] -Name $VMName[$i]) | Update-AzureVM
                # Note: A SSH endpoint is automatically created on port 22 when the appliance is created.
                }
            Else
                {
                New-AzureVMConfig -Name $VMName[$i] -ImageName $img[$i] –InstanceSize $size[$i] | `
                    Add-AzureProvisioningConfig -Windows -AdminUsername $LocalAdmin -Password $LocalAdminPwd  | `
                    Set-AzureSubnet  –SubnetNames $SubnetName[$i] | `
                    Set-AzureStaticVNetIP -IPAddress $VMIP[$i] | `
                    Set-AzureVMMicrosoftAntimalwareExtension -AntimalwareConfiguration '{"AntimalwareEnabled" : true}' | `
                    Remove-AzureEndpoint -Name "RemoteDesktop" | `
                    Remove-AzureEndpoint -Name "PowerShell" | `
                    New-AzureVM –ServiceName $ServiceName[$i] -VNetName $VNetName -Location $DeploymentLocation
                }
            $i++
        }

    # Configure UDR and IP Forwarding
        Write-Host "Configuring UDR" -ForegroundColor Cyan

      # Create the Route Tables
        Write-Host "Creating the Route Tables" -ForegroundColor Cyan 
        New-AzureRouteTable -Name $BERouteTableName `
            -Location $DeploymentLocation `
            -Label "Route table for $BESubnet subnet"
        New-AzureRouteTable -Name $FERouteTableName `
            -Location $DeploymentLocation `
            -Label "Route table for $FESubnet subnet"

      # Add Routes to Route Tables
        Write-Host "Adding Routes to the Route Tables" -ForegroundColor Cyan 
        Get-AzureRouteTable $BERouteTableName `
            |Set-AzureRoute -RouteName "All traffic to FW" -AddressPrefix 0.0.0.0/0 `
            -NextHopType VirtualAppliance `
            -NextHopIpAddress $VMIP[0]
        Get-AzureRouteTable $BERouteTableName `
            |Set-AzureRoute -RouteName "Internal traffic to FW" -AddressPrefix $VNetPrefix `
            -NextHopType VirtualAppliance `
            -NextHopIpAddress $VMIP[0]
        Get-AzureRouteTable $BERouteTableName `
            |Set-AzureRoute -RouteName "Allow Intra-Subnet Traffic" -AddressPrefix $BEPrefix `
            -NextHopType VNETLocal
        Get-AzureRouteTable $FERouteTableName `
            |Set-AzureRoute -RouteName "All traffic to FW" -AddressPrefix 0.0.0.0/0 `
            -NextHopType VirtualAppliance `
            -NextHopIpAddress $VMIP[0]
        Get-AzureRouteTable $FERouteTableName `
            |Set-AzureRoute -RouteName "Internal traffic to FW" -AddressPrefix $VNetPrefix `
            -NextHopType VirtualAppliance `
            -NextHopIpAddress $VMIP[0]
        Get-AzureRouteTable $FERouteTableName `
            |Set-AzureRoute -RouteName "Allow Intra-Subnet Traffic" -AddressPrefix $FEPrefix `
            -NextHopType VNETLocal

      # Associate the Route Tables with the Subnets
        Write-Host "Binding Route Tables to the Subnets" -ForegroundColor Cyan 
        Set-AzureSubnetRouteTable -VirtualNetworkName $VNetName `
            -SubnetName $BESubnet `
            -RouteTableName $BERouteTableName
        Set-AzureSubnetRouteTable -VirtualNetworkName $VNetName `
            -SubnetName $FESubnet `
            -RouteTableName $FERouteTableName

     # Enable IP Forwarding on the Virtual Appliance
        Get-AzureVM -Name $VMName[0] -ServiceName $ServiceName[0] `
            |Set-AzureIPForwarding -Enable

    # Configure NSG
        Write-Host "Configuring the Network Security Group (NSG)" -ForegroundColor Cyan

      # Build the NSG
        Write-Host "Building the NSG" -ForegroundColor Cyan
        New-AzureNetworkSecurityGroup -Name $NSGName -Location $DeploymentLocation -Label "Security group for $VNetName subnets in $DeploymentLocation"

      # Add NSG Rule
        Write-Host "Writing rules into the NSG" -ForegroundColor Cyan
        Get-AzureNetworkSecurityGroup -Name $NSGName | Set-AzureNetworkSecurityRule -Name "Isolate the $VNetName VNet from the Internet" -Type Inbound -Priority 100 -Action Deny `
            -SourceAddressPrefix INTERNET -SourcePortRange '*' `
            -DestinationAddressPrefix VIRTUAL_NETWORK -DestinationPortRange '*' `
            -Protocol *

      # Assign the NSG to two Subnets
        # The NSG is *not* bound to the Security Subnet. The result
        # is that internet traffic flows only to the Security subnet
        # since the NSG bound to the FrontEnd and BackEnd subnets
        # will Deny internet traffic to those subnets.
        Write-Host "Binding the NSG to two subnets" -ForegroundColor Cyan
        Set-AzureNetworkSecurityGroupToSubnet -Name $NSGName -SubnetName $FESubnet -VirtualNetworkName $VNetName
        Set-AzureNetworkSecurityGroupToSubnet -Name $NSGName -SubnetName $BESubnet -VirtualNetworkName $VNetName

    # Optional Post-script Manual Configuration
      # Configure Firewall
      # Install Test Web App (Run Post-Build Script on the IIS Server)
      # Install BackEnd resource (Run Post-Build Script on the AppVM01)
      Write-Host
      Write-Host "Build Complete!" -ForegroundColor Green
      Write-Host
      Write-Host "Optional Post-script Manual Configuration Steps" -ForegroundColor Gray
      Write-Host " - Configure Firewall" -ForegroundColor Gray
      Write-Host " - Install Test Web App (Run Post-Build Script on the IIS Server)" -ForegroundColor Gray
      Write-Host " - Install Backend resource (Run Post-Build Script on the AppVM01)" -ForegroundColor Gray
      Write-Host

ネットワーク構成ファイルNetwork config file

場所を更新して、この XML ファイルを保存します。Save this XML file with updated location. 上記の完全なスクリプトで $NetworkConfigFile 変数を変更し、保存されたネットワーク構成ファイルにリンクします。Change the $NetworkConfigFile variable in the full script above to link to the saved network config file.

    <NetworkConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
      <VirtualNetworkConfiguration>
        <Dns>
          <DnsServers>
            <DnsServer name="DNS01" IPAddress="10.0.2.4" />
            <DnsServer name="Level3" IPAddress="209.244.0.3" />
          </DnsServers>
        </Dns>
        <VirtualNetworkSites>
          <VirtualNetworkSite name="CorpNetwork" Location="Central US">
            <AddressSpace>
              <AddressPrefix>10.0.0.0/16</AddressPrefix>
            </AddressSpace>
            <Subnets>
              <Subnet name="SecNet">
                <AddressPrefix>10.0.0.0/24</AddressPrefix>
              </Subnet>
              <Subnet name="FrontEnd">
                <AddressPrefix>10.0.1.0/24</AddressPrefix>
              </Subnet>
              <Subnet name="BackEnd">
                <AddressPrefix>10.0.2.0/24</AddressPrefix>
              </Subnet>
            </Subnets>
            <DnsServersRef>
              <DnsServerRef name="DNS01" />
              <DnsServerRef name="Level3" />
            </DnsServersRef>
          </VirtualNetworkSite>
        </VirtualNetworkSites>
      </VirtualNetworkConfiguration>
    </NetworkConfiguration>

次の手順Next steps

この境界ネットワーク例に役立つ、サンプル アプリケーションをインストールできます。You can install a sample application to help with this perimeter network example.