Azure Firewall に関する FAQAzure Firewall FAQ

Azure Firewall とはWhat is Azure Firewall?

Azure Firewall は、Azure Virtual Network リソースを保護するクラウドベースのマネージド ネットワーク セキュリティ サービスです。Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. 完全にステートフルなサービスとしてのファイアウォールで、組み込みの高可用性とクラウドによる無制限のスケーラビリティを備えています。It's a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. サブスクリプションと仮想ネットワークをまたいでアプリケーションとネットワークの接続ポリシーを一元的に作成、適用、記録できます。You can centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks.

Azure Firewall ではどのような機能がサポートされていますか?What capabilities are supported in Azure Firewall?

Azure Firewall の機能の詳細については、「Azure Firewall の機能」を参照してください。To learn about Azure Firewall features, see Azure Firewall features.

Azure Firewall の一般的なデプロイ モデルを教えてくださいWhat is the typical deployment model for Azure Firewall?

Azure Firewall は任意の仮想ネットワークにデプロイできますが、通常、お客様は中央の仮想ネットワークにデプロイし、ハブ アンド スポーク モデルでこれに他の仮想ネットワークをピアリングします。You can deploy Azure Firewall on any virtual network, but customers typically deploy it on a central virtual network and peer other virtual networks to it in a hub-and-spoke model. こうすることで、この中央のファイアウォールの仮想ネットワークを指すように、ピアリングされた仮想ネットワークから既定のルートを設定できます。You can then set the default route from the peered virtual networks to point to this central firewall virtual network. グローバル VNet ピアリングはサポートされていますが、リージョン間の潜在的なパフォーマンスと待機時間の問題のため、推奨されません。Global VNet peering is supported, but it isn't recommended because of potential performance and latency issues across regions. 最適なパフォーマンスのため、リージョンごとに 1 つのファイアウォールをデプロイしてください。For best performance, deploy one firewall per region.

このモデルの利点は、異なるサブスクリプションの複数のスポーク VNET に対して制御を集中的に実行できる点です。The advantage of this model is the ability to centrally exert control on multiple spoke VNETs across different subscriptions. VNet ごとに個別にファイアウォールを設置する必要がないため、コストも削減できます。There are also cost savings as you don't need to deploy a firewall in each VNet separately. コスト削減は、カスタマーのトラフィック パターンに基づいて関連するピアリング コストに対して計測する必要があります。The cost savings should be measured versus the associate peering cost based on the customer traffic patterns.

Azure Firewall のインストール方法を教えてくださいHow can I install the Azure Firewall?

Azure portal、PowerShell、REST API、またはテンプレートを使用して、Azure Firewall を設定できます。You can set up Azure Firewall by using the Azure portal, PowerShell, REST API, or by using templates. チュートリアル:Azure portal を使用して Azure Firewall をデプロイして構成する」を参照してください。See Tutorial: Deploy and configure Azure Firewall using the Azure portal for step-by-step instructions.

Azure Firewall の概念をいくつか教えてください。What are some Azure Firewall concepts?

Azure Firewall は、ルールとルール コレクションをサポートしています。Azure Firewall supports rules and rule collections. ルール コレクションは、同じ順序と優先度を共有するルールのセットです。A rule collection is a set of rules that share the same order and priority. ルール コレクションは、その優先度の順に実行されます。Rule collections are executed in order of their priority. ネットワーク ルール コレクションはアプリケーション ルール コレクションよりも優先されます。また、すべてのルールは終了されます。Network rule collections are higher priority than application rule collections, and all rules are terminating.

次の 3 つの種類のルール コレクションがあります。There are three types of rule collections:

  • "アプリケーション ルール": サブネットからアクセスできる完全修飾ドメイン名 (FQDN) を構成します。Application rules: Configure fully qualified domain names (FQDNs) that can be accessed from a subnet.
  • "ネットワーク ルール": 送信元アドレス、プロトコル、宛先ポート、および送信先アドレスを含むルールを構成します。Network rules: Configure rules that contain source addresses, protocols, destination ports, and destination addresses.
  • NAT ルール:着信インターネット接続を許可する DNAT ルールを構成します。NAT rules: Configure DNAT rules to allow incoming Internet connections.

Azure Firewall は受信トラフィック フィルター処理をサポートしていますか?Does Azure Firewall support inbound traffic filtering?

Azure Firewall は受信と送信のフィルター処理をサポートしています。Azure Firewall supports inbound and outbound filtering. 受信保護は、通常、非 HTTP/S プロトコルに使用されます。Inbound protection is typically used for non-HTTP/S protocols. たとえば、RDP、SSH、および FTP プロトコルです。For example RDP, SSH, and FTP protocols. インバウンド HTTP/S を最適に保護するには、Azure Web アプリケーション ファイアウォール (WAF) などの Web アプリケーション ファイアウォールを使用します。For best inbound HTTP/S protection, use a web application firewall such as Azure Web Application Firewall (WAF).

Azure Firewall では、どのログ記録および分析サービスがサポートされていますか?Which logging and analytics services are supported by the Azure Firewall?

Azure Firewall は、ファイアウォール ログの表示と分析について Azure Monitor と統合されています。Azure Firewall is integrated with Azure Monitor for viewing and analyzing firewall logs. Log Analytics、Azure Storage、または Event Hubs にログを送信できます。Logs can be sent to Log Analytics, Azure Storage, or Event Hubs. Log Analytics や、Excel や Power BI などのさまざまなツールで分析できます。They can be analyzed in Log Analytics or by different tools such as Excel and Power BI. 詳細については、Azure Firewall のログを監視する方法に関するチュートリアルを参照してください。For more information, see Tutorial: Monitor Azure Firewall logs.

Azure Firewall の動作は、マーケットプレースの NVA などの既存のサービスとどのように異なりますか?How does Azure Firewall work differently from existing services such as NVAs in the marketplace?

Azure Firewall は、特定のお客様のシナリオに対応できる基本的なファイアウォール サービスです。Azure Firewall is a basic firewall service that can address certain customer scenarios. サード パーティ製の NVA と Azure Firewall を組み合わせることが想定されています。It's expected that you'll have a mix of third-party NVAs and Azure Firewall. よりよい連携が重要な優先項目です。Working better together is a core priority.

Application Gateway WAF と Azure Firewall の違いは何ですか?What is the difference between Application Gateway WAF and Azure Firewall?

Web アプリケーション ファイアウォール (WAF) は、一般的な脆弱性やその悪用から Web アプリケーションの受信保護を一元的に行う Application Gateway の機能です。The Web Application Firewall (WAF) is a feature of Application Gateway that provides centralized inbound protection of your web applications from common exploits and vulnerabilities. Azure Firewall は、非 HTTP/S プロトコル (例: RDP、SSH、FTP など) の受信保護、すべてのポートとプロトコルに対する送信ネットワークレベルの保護、送信 HTTP/S に対するアプリケーションレベルの保護を提供します。Azure Firewall provides inbound protection for non-HTTP/S protocols (for example, RDP, SSH, FTP), outbound network-level protection for all ports and protocols, and application-level protection for outbound HTTP/S.

ネットワーク セキュリティ グループ (NSG) と Azure Firewall の違いは何ですか?What is the difference between Network Security Groups (NSGs) and Azure Firewall?

Azure Firewall サービスは、ネットワーク セキュリティ グループの機能を補完します。The Azure Firewall service complements network security group functionality. 全体で、優れた "多層防御" ネットワーク セキュリティを実現します。Together, they provide better "defense-in-depth" network security. ネットワーク セキュリティ グループには、分散ネットワーク レイヤーのトラフィック フィルター機能があり、この機能によって各サブスクリプションの仮想ネットワーク内のリソースに対するトラフィックを制限します。Network security groups provide distributed network layer traffic filtering to limit traffic to resources within virtual networks in each subscription. Azure Firewall は、完全にステートフルな一元化されたネットワーク ファイアウォールです。さまざまなサブスクリプションと仮想ネットワーク全体にネットワークレベルとアプリケーションレベルの保護を提供します。Azure Firewall is a fully stateful, centralized network firewall as-a-service, which provides network- and application-level protection across different subscriptions and virtual networks.

AzureFirewallSubnet でネットワーク セキュリティ グループ (NSG) はサポートされていますか?Are Network Security Groups (NSGs) supported on the AzureFirewallSubnet?

Azure Firewall は、NIC レベル NSG (表示不可) によるプラットフォーム保護など、複数の保護レイヤーがあるマネージド サービスです。Azure Firewall is a managed service with multiple protection layers, including platform protection with NIC level NSGs (not viewable). サブネット レベル NSG は AzureFirewallSubnet で必要なく、サービスの中断を確実に防ぐために無効にされています。Subnet level NSGs aren't required on the AzureFirewallSubnet, and are disabled to ensure no service interruption.

サービス エンドポイントに Azure Firewall を設定するにはどうすればよいですか?How do I set up Azure Firewall with my service endpoints?

PaaS サービスへのアクセスをセキュリティで保護するには、サービス エンドポイントをお勧めします。For secure access to PaaS services, we recommend service endpoints. Azure Firewall サブネット内のサービス エンドポイントを有効にし、接続されているスポーク仮想ネットワーク上ではそれらを無効にすることを選択できます。You can choose to enable service endpoints in the Azure Firewall subnet and disable them on the connected spoke virtual networks. このようにして、サービス エンドポイントのセキュリティとすべてのトラフィックの一元的ログ記録という、両方の機能の長所を活かすことができます。This way you benefit from both features: service endpoint security and central logging for all traffic.

Azure Firewall の価格を教えてくださいWhat is the pricing for Azure Firewall?

Azure Firewall の価格」を参照してください。See Azure Firewall Pricing.

Azure Firewall の停止と起動の方法を教えてくださいHow can I stop and start Azure Firewall?

Azure PowerShell の deallocate メソッドと allocate メソッドを使用できます。You can use Azure PowerShell deallocate and allocate methods.

次に例を示します。For example:

# Stop an existing firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw
# Start a firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet,@($publicip1,$publicip2))

Set-AzFirewall -AzureFirewall $azfw

注意

ファイアウォールとパブリック IP を、元のリソース グループとサブスクリプションに再割り当てする必要があります。You must reallocate a firewall and public IP to the original resource group and subscription.

既知のサービスの制限には何がありますか?What are the known service limits?

Azure Firewall サービスの制限については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。For Azure Firewall service limits, see Azure subscription and service limits, quotas, and constraints.

Azure Firewall では、ハブ仮想ネットワークで 2 つのスポーク仮想ネットワーク間のネットワーク トラフィックを転送したりフィルター処理したりできますか?Can Azure Firewall in a hub virtual network forward and filter network traffic between two spoke virtual networks?

はい。ハブ仮想ネットワークで Azure Firewall を使用して、2 つのスポーク仮想ネットワーク間のトラフィックをルーティングしたりフィルター処理したりできます。Yes, you can use Azure Firewall in a hub virtual network to route and filter traffic between two spoke virtual network. このシナリオが適切に機能するためには、各スポーク仮想ネットワークのサブネットの UDR が、既定のゲートウェイとして Azure Firewall をポイントしている必要があります。Subnets in each of the spoke virtual networks must have a UDR pointing to the Azure Firewall as a default gateway for this scenario to work properly.

Azure Firewall では、同じ仮想ネットワーク (またはピアリングされた仮想ネットワーク) のサブネット間のネットワーク トラフィックを転送したりフィルター処理したりできますか?Can Azure Firewall forward and filter network traffic between subnets in the same virtual network or peered virtual networks?

はい。Yes. ただし、同じ VNET 内のサブネット間でトラフィックをリダイレクトするよう UDR を構成する場合、さらに注意が必要です。However, configuring the UDRs to redirect traffic between subnets in the same VNET requires additional attention. UDR のターゲット プレフィックスとして VNET アドレス範囲を使用する場合、これにより、Azure Firewall インスタンスを介して、同じサブネット内で一方のマシンから他方のマシンにすべてのトラフィックがルーティングされることになります。While using the VNET address range as a target prefix for the UDR is sufficient, this also routes all traffic from one machine to another machine in the same subnet through the Azure Firewall instance. これを回避するために、次ホップ タイプ VNET を使用して UDR にサブネットのルートを組み込みます。To avoid this, include a route for the subnet in the UDR with a next hop type of VNET. これらのルートの管理は、手間がかかり、誤りが発生する可能性もあります。Managing these routes might be cumbersome and prone to error. 内部ネットワークのセグメント化について推奨される方法は、UDR を必要としないネットワーク セキュリティ グループを使用する方法です。The recommended method for internal network segmentation is to use Network Security Groups, which don't require UDRs.

Azure Firewall で、プライベート ネットワーク間のアウトバウンド SNAT は実行されますか?Does Azure Firewall outbound SNAT between private networks?

宛先 IP アドレスが IANA RFC 1918 のプライベート IP 範囲である場合、Azure Firewall は SNAT を行いません。Azure Firewall doesn't SNAT when the destination IP address is a private IP range per IANA RFC 1918. 組織でプライベート ネットワークに対してパブリック IP アドレス範囲を使用している場合、Azure Firewall は、SNAT を使用して、トラフィックのアドレスを AzureFirewallSubnet のいずれかのファイアウォール プライベート IP アドレスに変換します。If your organization uses a public IP address range for private networks, Azure Firewall SNATs the traffic to one of the firewall private IP addresses in AzureFirewallSubnet. パブリック IP アドレス範囲の SNAT が行われないように、Azure Firewall を構成することができます。You can configure Azure Firewall to not SNAT your public IP address range. 詳細については、「Azure Firewall の SNAT プライベート IP アドレス範囲」を参照してください。For more information, see Azure Firewall SNAT private IP address ranges.

サポートされているネットワーク仮想アプライアンスに、トンネリング/チェーンが強制されますか。Is forced tunneling/chaining to a Network Virtual Appliance supported?

強制トンネリングは、新しいファイアウォールを作成するときにサポートされます。Forced tunneling is supported when you create a new firewall. 既存のファイアウォールを強制トンネリング用に構成することはできません。You can't configure an existing firewall for forced tunneling. 詳細については、「Azure Firewall 強制トンネリング」を参照してください。For more information, see Azure Firewall forced tunneling.

Azure Firewall には、インターネットへの直接接続が必要です。Azure Firewall must have direct Internet connectivity. AzureFirewallSubnet が BGP 経由のオンプレミス ネットワークへの既定のルートを学習する場合は、インターネットへの直接接続を保持するために、NextHopType の値を Internet に設定した 0.0.0.0/0 UDR でこれを上書きする必要があります。If your AzureFirewallSubnet learns a default route to your on-premises network via BGP, you must override this with a 0.0.0.0/0 UDR with the NextHopType value set as Internet to maintain direct Internet connectivity.

使用する構成でオンプレミスのネットワークへの強制的なトンネリングが必要であり、インターネット上のアクセス先のターゲット IP プレフィックスを決定できる場合は、AzureFirewallSubnet 上のユーザー定義のルートを介して、次のホップとしてオンプレミスのネットワークに対してこれらの範囲を構成することができます。If your configuration requires forced tunneling to an on-premises network and you can determine the target IP prefixes for your Internet destinations, you can configure these ranges with the on-premises network as the next hop via a user defined route on the AzureFirewallSubnet. または、BGP を使用してこれらのルートを定義することもできます。Or, you can use BGP to define these routes.

ファイアウォール リソース グループの制限はありますか。Are there any firewall resource group restrictions?

はい。Yes. ファイアウォール、VNet、パブリック IP アドレスすべては同じリソース グループに属していなければなりません。The firewall, VNet, and the public IP address all must be in the same resource group.

インバウンド インターネット ネットワーク トラフィックの DNAT を構成する際、そのトラフィックを許可するために、対応するネットワーク ルールも構成しなければならないのでしょうか。When configuring DNAT for inbound Internet network traffic, do I also need to configure a corresponding network rule to allow that traffic?

いいえ。No. NAT ルールは、変換されたトラフィックを許可するための対応するネットワーク ルールを暗黙的に追加します。NAT rules implicitly add a corresponding network rule to allow the translated traffic. この動作は、変換されたトラフィックに一致する拒否ルールを使用してネットワーク ルール コレクションを明示的に追加することで、オーバーライドすることができます。You can override this behavior by explicitly adding a network rule collection with deny rules that match the translated traffic. Azure Firewall ルール処理ロジックの詳細については、「Azure Firewall ルール処理ロジック」を参照してください。To learn more about Azure Firewall rule processing logic, see Azure Firewall rule processing logic.

アプリケーション ルールのターゲット FQDN でワイルドカードはどのように機能しますか。How do wildcards work in an application rule target FQDN?

現在、ワイルドカードは FQDN の左側でのみ使用できます。Wildcards currently can only be used on the left side of the FQDN. たとえば、* .contoso.com や *contoso.com などです。For example, *.contoso.com and *contoso.com.

* .contoso.com を構成した場合、これにより、何らかの値.contoso.com は許可されますが、contoso.com (ドメインの頂点) は許可されません。If you configure *.contoso.com, it allows anyvalue.contoso.com, but not contoso.com (the domain apex). ドメインの頂点を許可する場合は、それをターゲット FQDN として明示的に構成する必要があります。If you want to allow the domain apex, you must explicitly configure it as a target FQDN.

"プロビジョニング状態: 失敗" はどのような意味ですか。What does Provisioning state: Failed mean?

構成の変更が適用されるたびに、Azure Firewall は、その基になるすべてのバックエンド インスタンスを更新しようとします。Whenever a configuration change is applied, Azure Firewall attempts to update all its underlying backend instances. まれに、これらのバックエンド インスタンスの 1 つが新しい構成での更新に失敗し、更新プロセスが停止して、失敗したプロビジョニングの状態になることがあります。In rare cases, one of these backend instances may fail to update with the new configuration and the update process stops with a failed provisioning state. Azure Firewall はまだ操作可能ですが、適用された構成は矛盾した状態になっている可能性があります。この場合、一部のインスタンスは以前の構成であり、他のインスタンスはルール セットが更新されています。Your Azure Firewall is still operational, but the applied configuration may be in an inconsistent state, where some instances have the previous configuration where others have the updated rule set. このような場合は、操作が成功してファイアウォールが "成功" プロビジョニング状態になるまで、もう一度構成を更新してみてください。If this happens, try updating your configuration one more time until the operation succeeds and your Firewall is in a Succeeded provisioning state.

Azure Firewall は計画メンテナンスや予期しない障害にどのように対処しますか。How does Azure Firewall handle planned maintenance and unplanned failures?

Azure Firewall は、アクティブ/アクティブ構成の複数のバックエンドノードで構成されます。Azure Firewall consists of several backend nodes in an active-active configuration. 計画メンテナンスの場合は、ノードを適切に更新するための接続のドレイン ロジックがあります。For any planned maintenance, we have connection draining logic to gracefully update nodes. 更新は、中断のリスクをさらに制限するために、Azure リージョンごとに営業時間外に予定されます。Updates are planned during non-business hours for each of the Azure regions to further limit risk of disruption. 予期しない問題の場合は、新しいノードをインスタンス化して、障害が発生したノードを置き換えます。For unplanned issues, we instantiate a new node to replace the failed node. 新しいノードへの接続は、通常、障害発生時から 10 秒以内に再確立されます。Connectivity to the new node is typically reestablished within 10 seconds from the time of the failure.

接続のドレインはどのように機能しますか。How does connection draining work?

計画されたメンテナンスの場合、接続のドレイン ロジックにより、バックエンド ノードが適切に更新されます。For any planned maintenance, connection draining logic gracefully updates backend nodes. 既存の接続が閉じられるまで、Azure Firewall は 90 秒間待機します。Azure Firewall waits 90 seconds for existing connections to close. 必要に応じて、クライアントは別のバックエンド ノードへの接続を自動的に再確立できます。If needed, clients can automatically re-establish connectivity to another backend node.

ファイアウォール名に文字制限はありますか。Is there a character limit for a firewall name?

はい。Yes. ファイアウォール名には 50 文字の制限があります。There's a 50 character limit for a firewall name.

Azure Firewall に /26 サブネット サイズが必要なのはなぜですか。Why does Azure Firewall need a /26 subnet size?

Azure Firewall では、スケールの際により多くの仮想マシン インスタンスをプロビジョニングする必要があります。Azure Firewall must provision more virtual machine instances as it scales. /26 アドレス空間を使用すると、スケールに対応できる十分な数の IP アドレスをファイアウォールに使用できるようになります。A /26 address space ensures that the firewall has enough IP addresses available to accommodate the scaling.

サービスのスケールに応じてファイアウォール サブネットのサイズを変更する必要はありますか。Does the firewall subnet size need to change as the service scales?

いいえ。No. Azure Firewall には、/26 よりも大きなサブネットは必要ありません。Azure Firewall doesn't need a subnet bigger than /26.

ファイアウォールのスループットを増やすにはどうすればよいですか。How can I increase my firewall throughput?

Azure Firewall の初期スループット容量は 2.5 から 3 Gbps で、30 Gbps までスケールアウトします。Azure Firewall's initial throughput capacity is 2.5 - 3 Gbps and it scales out to 30 Gbps. CPU 使用率とスループットに基づいて自動的にスケールアウトされます。It scales out automatically based on CPU usage and throughput.

Azure Firewall のスケールアウトにはどのくらいの時間がかかりますか。How long does it take for Azure Firewall to scale out?

Azure Firewall は、平均スループットまたは CPU 使用率が 60% になると、徐々にスケーリングされます。Azure Firewall gradually scales when average throughput or CPU consumption is at 60%. 既定のデプロイの最大スループットは約 2.5 ~ 3 Gbps で、その量の 60% に達したときにスケールアウトが開始されます。A default deployment maximum throughput is approximately 2.5 - 3 Gbps and starts to scale out when it reaches 60% of that number. スケールアウトには 5 から 7 分かかります。Scale out takes five to seven minutes.

パフォーマンス テストを行うときは、少なくとも 10 ~ 15 分のテストを行い、新しく作成されたファイアウォール ノードを活用するために新しい接続を開始してください。When performance testing, make sure you test for at least 10 to 15 minutes, and start new connections to take advantage of newly created Firewall nodes.

Azure Firewall では Active Directory へのアクセスが既定で許可されますか。Does Azure Firewall allow access to Active Directory by default?

いいえ。No. Azure Firewall では、Active Directory へのアクセスは既定でブロックされます。Azure Firewall blocks Active Directory access by default. アクセスを許可するには、AzureActiveDirectory サービス タグを構成します。To allow access, configure the AzureActiveDirectory service tag. 詳しくは、「Azure Firewall サービス タグ」をご覧ください。For more information, see Azure Firewall service tags.

Azure Firewall の脅威インテリジェンス ベースのフィルター処理から、FQDN または IP アドレスを除外できますか。Can I exclude a FQDN or an IP address from Azure Firewall Threat Intelligence based filtering?

はい。Azure PowerShell を使用して、それを行うことができます。Yes, you can use Azure PowerShell to do it:

# Add a Threat Intelligence allow list to an Existing Azure Firewall

## Create the allow list with both FQDN and IPAddresses

$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

## Or Update FQDNs and IpAddresses separately

$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

TCP ping や類似のツールが、そのトラフィックを許可するルールが Azure Firewall にない場合でも、ターゲット FQDN に正常に接続できるのはなぜですか。Why can a TCP ping and similar tools successfully connect to a target FQDN even when no rule on Azure Firewall allows that traffic?

TCP ping は実際にはターゲット FQDN に接続していません。A TCP ping isn't actually connecting to the target FQDN. Azure Firewall の透過プロキシでは、ポート 80/443 で送信トラフィックがリッスンされるためにこのようなことが起こります。This happens because Azure Firewall's transparent proxy listens on port 80/443 for outbound traffic. TCP ping を実行すると、ファイアウォールとの接続が確立されます。これにより、パケットが破棄され、接続がログに記録されます。The TCP ping establishes a connection with the firewall, which then drops the packet and logs the connection. この動作はセキュリティに影響しません。This behavior doesn't have any security impact. ただし、混乱を避けるために、この動作に対する変更の可能性を調査しています。However, to avoid confusion we're investigating potential changes to this behavior.

IP グループでサポートされる IP アドレスの数に制限はありますか。Are there limits for the number of IP addresses supported by IP Groups?

はい。Yes. 詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。For more information, see Azure subscription and service limits, quotas, and constraints

別のリソース グループに IP グループを移動できますか。Can I move an IP Group to another resource group?

いいえ。IP グループを別のリソースグループに移動することは現在サポートされていません。No, moving an IP Group to another resource group isn't currently supported.

Azure Firewall の TCP アイドル タイムアウトはどうなっていますか。What is the TCP Idle Timeout for Azure Firewall?

ネットワーク ファイアウォールの標準的な動作では、TCP 接続が確実に維持されるようにして、アクティビティがない場合はすぐに終了するようになっています。A standard behavior of a network firewall is to ensure TCP connections are kept alive and to promptly close them if there's no activity. Azure Firewall の TCP アイドル タイムアウトは 4 分です。Azure Firewall TCP Idle Timeout is four minutes. この設定を構成することはできません。This setting isn't configurable. アイドル時間がタイムアウト値よりも長い場合、TCP や HTTP のセッションが維持される保証はありません。If a period of inactivity is longer than the timeout value, there's no guarantee that the TCP or HTTP session is maintained. 一般的な方法として、TCP keep-alive を使用します。A common practice is to use a TCP keep-alive. この方法を使用すると、接続が長時間アクティブ状態に維持されます。This practice keeps the connection active for a longer period. 詳細については、.NET の例に関するページを参照してください。For more information, see the .NET examples.

パブリック IP アドレスを使用せずに Azure Firewall をデプロイできますか。Can I deploy Azure Firewall without a public IP address?

いいえ。現時点では、Azure Firewall はパブリック IP アドレスを使用してデプロイする必要があります。No, currently you must deploy Azure Firewall with a public IP address.

顧客データは Azure Firewall によってどこに格納されますか?Where does Azure Firewall store customer data?

Azure Firewall によって、顧客データがデプロイされているリージョン外に移動または格納されることはありません。Azure Firewall doesn't move or store customer data out of the region it's deployed in.