Azure Firewall に関する FAQ

Azure Firewall は、Azure Virtual Network リソースを保護するクラウドベースのマネージド ネットワーク セキュリティ サービスです。 完全にステートフルなサービスとしてのファイアウォールで、組み込みの高可用性とクラウドによる無制限のスケーラビリティを備えています。 サブスクリプションと仮想ネットワークをまたいでアプリケーションとネットワークの接続ポリシーを一元的に作成、適用、記録できます。

Azure Firewall の機能の詳細については、「Azure Firewall の機能」を参照してください。

Azure Firewall は任意の仮想ネットワークにデプロイできますが、通常、お客様は中央の仮想ネットワークにデプロイし、ハブ アンド スポーク モデルでこれに他の仮想ネットワークをピアリングします。 こうすることで、この中央のファイアウォールの仮想ネットワークを指すように、ピアリングされた仮想ネットワークから既定のルートを設定できます。 グローバル VNet ピアリングはサポートされていますが、リージョン間の潜在的なパフォーマンスと待機時間の問題のため、推奨されません。 最適なパフォーマンスのため、リージョンごとに 1 つのファイアウォールをデプロイしてください。

このモデルの利点は、異なるサブスクリプションの複数のスポーク VNET に対して制御を集中的に実行できる点です。 VNet ごとに個別にファイアウォールを設置する必要がないため、コストも削減できます。 コスト削減は、カスタマーのトラフィック パターンに基づいて関連するピアリング コストに対して計測する必要があります。

Azure portal、PowerShell、REST API、またはテンプレートを使用して、Azure Firewall を設定できます。 「チュートリアル:Azure portal を使用して Azure Firewall をデプロイして構成する」を参照してください。

Azure Firewall は、ルールとルール コレクションをサポートしています。 ルール コレクションは、同じ順序と優先度を共有するルールのセットです。 ルール コレクションは、その優先度の順に実行されます。 DNAT ルール コレクションは優先順位が高いネットワーク ルール コレクションであり、アプリケーション ルール コレクションより優先順位が高く、すべてのルールが終了します。

次の 3 つの種類のルール コレクションがあります。

• "アプリケーション ルール": Virtual Network からアクセスできる完全修飾ドメイン名 (FQDN) を構成します。
• "ネットワーク ルール": 送信元アドレス、プロトコル、宛先ポート、および送信先アドレスを含むルールを構成します。
• "NAT 規則": 受信インターネットまたはイントラネット (プレビュー) 接続を許可するように DNAT 規則を構成します。

詳しくは、「Azure Firewall 規則を構成する」をご覧ください。

Azure Firewall は受信と送信のフィルター処理をサポートしています。 受信保護は、通常、RDP、SSH、FTP プロトコルなどの HTTP 以外のプロトコルに使用されます。 HTTP と HTTPS の受信保護には、Azure Web Application Firewall (WAF) などの Web アプリケーション ファイアウォール、または Azure Firewall Premium の TLS オフロードとディープ パケット インスペクション機能を使用します。

はい。Azure Firewall Basic では、強制トンネリングがサポートされています。

Azure Firewall は、ファイアウォール ログの表示と分析について Azure Monitor と統合されています。 Log Analytics、Azure Storage、または Event Hubs にログを送信できます。 Log Analytics や、Excel や Power BI などのさまざまなツールで分析できます。 詳細については、Azure Firewall のログを監視する方法に関するチュートリアルを参照してください。

Azure Firewall は、仮想ネットワーク リソースを保護する、クラウドベースのマネージド ネットワーク セキュリティ サービスです。 組み込みの高可用性とクラウドの無制限のスケーラビリティを備えた、完全にステートフルなサービスとしてのファイアウォールです。 仮想ネットワークとブランチ インターネット接続に高度なセキュリティを提供するため、サード パーティのサービスとしてのセキュリティ (SECaaS) プロバイダーと事前に統合されています。 Azure ネットワーク セキュリティの詳細については、「Azure ネットワーク セキュリティ」を参照してください。

Web アプリケーション ファイアウォール (WAF) は、一般的な脆弱性やその悪用から Web アプリケーションの受信保護を一元的に行う Application Gateway の機能です。 Azure Firewall は、非 HTTP/S プロトコル (例: RDP、SSH、FTP など) の受信保護、すべてのポートとプロトコルに対する送信ネットワークレベルの保護、送信 HTTP/S に対するアプリケーションレベルの保護を提供します。

Azure Firewall サービスは、ネットワーク セキュリティ グループの機能を補完します。 全体で、優れた "多層防御" ネットワーク セキュリティを実現します。 ネットワーク セキュリティ グループには、分散ネットワーク レイヤーのトラフィック フィルター機能があり、この機能によって各サブスクリプションの仮想ネットワーク内のリソースに対するトラフィックを制限します。 Azure Firewall は、完全にステートフルな一元化されたネットワーク ファイアウォールです。さまざまなサブスクリプションと仮想ネットワーク全体にネットワークレベルとアプリケーションレベルの保護を提供します。

Azure Firewall は、NIC レベル NSG (表示不可) によるプラットフォーム保護など、複数の保護レイヤーがあるマネージド サービスです。 サブネット レベル NSG は AzureFirewallSubnet で必要なく、サービスの中断を確実に防ぐために無効にされています。

PaaS サービスへのアクセスをセキュリティで保護するには、サービス エンドポイントをお勧めします。 Azure Firewall サブネット内のサービス エンドポイントを有効にし、接続されているスポーク仮想ネットワーク上ではそれらを無効にすることを選択できます。 このようにして、サービス エンドポイントのセキュリティとすべてのトラフィックの一元的ログ記録という、両方の機能の長所を活かすことができます。

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

Azure PowerShell の deallocate メソッドと allocate メソッドを使用できます。 強制トンネリング用に構成されたファイアウォールの場合、手順は若干異なります。

たとえば、管理 NIC が有効になって "いない" 状態で構成されたファイアウォールの場合は、以下のようになります。

# Stop an existing firewall

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

# Start the 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

管理 NIC を有効にして構成されたファイアウォールの場合、停止方法は同じです。 ただし、開始では、管理パブリック IP をファイアウォールに再度関連付ける必要があります。

# Stop an existing firewall

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

# Start the firewall

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azfw | Set-AzFirewall

セキュリティで保護された仮想ハブ アーキテクチャのファイアウォールの場合、停止するときは同じですが、開始するときは仮想ハブ ID を使用する必要があります。

# Stop and existing firewall

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

# Start the firewall

$virtualhub = get-azvirtualhub -ResourceGroupName "RG name of vHUB" -name "vHUB name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Azfw RG Name"
$azfw.Allocate($virtualhub.Id)
$azfw | Set-AzFirewall

割り当ておよび割り当て解除を行うと、それに応じてファイアウォールの課金が停止および開始されます。

最初のファイアウォールのデプロイ時に可用性ゾーンを構成することをお勧めします。 ただし、場合によっては、デプロイ後に可用性ゾーンを変更できます。 前提条件はつぎのとおりです。

• ファイアウォールは VNet にデプロイされます。 セキュリティ保護付き仮想ハブにデプロイされたファイアウォールではサポートされていません。
• ファイアウォールのリージョンでは、可用性ゾーンがサポートされています。
• アタッチされているパブリック IP アドレスはすべて、可用性ゾーンと共にデプロイされます。 各パブリック IP アドレスのプロパティ ページで、[可用性ゾーン] フィールドが存在し、ファイアウォール用に構成したのと同じゾーンで構成されていることを確認します。

可用性ゾーンの再構成は、ファイアウォールを再起動した場合にのみ実行できます。 ファイアウォールを割り当てた後、Set-AzFirewall でファイアウォールを起動する直前に、次の Azure PowerShell を使用してファイアウォールの Zones プロパティを変更します。

$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip= Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azFw.Zones=1,2,3
$azfw | Set-AzFirewall

Azure Firewall サービスの制限については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。

はい。ハブ仮想ネットワークで Azure Firewall を使用して、複数のスポーク仮想ネットワーク間のトラフィックをルーティングしたりフィルター処理したりできます。 このシナリオが適切に機能するためには、各スポーク仮想ネットワークのサブネットの UDR が、既定のゲートウェイとして Azure Firewall をポイントしている必要があります。

はい。 ただし、同じ VNET 内のサブネット間でトラフィックをリダイレクトするよう UDR を構成する場合は、さらに注意が必要です。 UDR のターゲット プレフィックスとして VNET アドレス範囲を使用する場合、これにより、Azure Firewall インスタンスを介して、同じサブネット内で一方のマシンから他方のマシンにすべてのトラフィックがルーティングされることになります。 これを回避するために、次ホップ タイプ VNET を使用して UDR にサブネットのルートを組み込みます。 これらのルートの管理は、手間がかかり、誤りが発生する可能性もあります。 内部ネットワークのセグメント化について推奨される方法は、UDR を必要としないネットワーク セキュリティ グループを使用する方法です。

宛先 IP アドレスがプライベート ネットワーク向けの IANA RFC 1918 または IANA RFC 6598 に従うプライベート IP 範囲である場合、Azure Firewall は SNAT を行いません。 組織でプライベート ネットワークに対してパブリック IP アドレス範囲を使用している場合、Azure Firewall は、SNAT を使用して、トラフィックのアドレスを AzureFirewallSubnet のいずれかのファイアウォール プライベート IP アドレスに変換します。 パブリック IP アドレス範囲の SNAT が行われないように、Azure Firewall を構成することができます。 詳細については、「Azure Firewall の SNAT プライベート IP アドレス範囲」を参照してください。

さらに、アプリケーション ルールによって処理されたトラフィックでは、常に SNAT が実行されます。 FQDN トラフィックのログに元の送信元 IP アドレスを表示する場合は、宛先 FQDN でネットワーク規則を使用できます。

強制トンネリングは、新しいファイアウォールを作成するときにサポートされます。 既存のファイアウォールを強制トンネリング用に構成することはできません。 詳細については、「Azure Firewall 強制トンネリング」を参照してください。

Azure Firewall には、インターネットへの直接接続が必要です。 AzureFirewallSubnet が BGP 経由のオンプレミス ネットワークへの既定のルートを学習する場合は、インターネットへの直接接続を保持するために、NextHopType の値を Internet に設定した 0.0.0.0/0 UDR でこれを上書きする必要があります。

使用する構成でオンプレミスのネットワークへの強制的なトンネリングが必要であり、インターネット上のアクセス先のターゲット IP プレフィックスを決定できる場合は、AzureFirewallSubnet 上のユーザー定義のルートを介して、次のホップとしてオンプレミスのネットワークに対してこれらの範囲を構成することができます。 または、BGP を使用してこれらのルートを定義することもできます。

はい。

• ファイアウォールと VNet は、同じリソース グループ内に存在する必要があります。
• パブリック IP アドレスは、どのリソース グループでもかまいません。
• ファイアウォール、VNet、パブリック IP アドレスはすべて、同じサブスクリプションに含まれる必要があります。

• URL - アスタリスクは、右端または左端に配置すると機能します。 左側にある場合、FQDN の一部にすることはできません。
• FQDN - アスタリスクは、左端に配置すると機能します。
• GENERAL - 左端のアスタリスクは、文字通り左側の "何か" が一致することを意味します。つまり、複数のサブドメインや望ましくない可能性のあるドメイン名のバリエーションが一致します。以下の例を参照してください。

例 :

構成の変更が適用されるたびに、Azure Firewall は、その基になるすべてのバックエンド インスタンスを更新しようとします。 まれに、これらのバックエンド インスタンスの 1 つが新しい構成での更新に失敗し、プロビジョニング失敗状態で更新プロセスが停止することがあります。 Azure Firewall はまだ動作できますが、適用された構成は矛盾した状態になっている可能性があります。この場合、一部のインスタンスは以前の構成で、他のインスタンスはルール セットが更新されています。 このような場合は、操作が成功してファイアウォールが "成功" プロビジョニング状態になるまで、もう一度構成を更新してみてください。

Azure Firewall は、アクティブ/アクティブ構成の複数のバックエンドノードで構成されます。 計画メンテナンスの場合は、ノードを適切に更新するための接続のドレイン ロジックがあります。 中断のリスクをさらに制限するため、更新は Azure リージョンごとに営業時間外に予定されます。 予期しない問題の場合は、新しいノードをインスタンス化して、障害が発生したノードを置き換えます。 新しいノードへの接続は、通常、障害発生時から 10 秒以内に再確立されます。

計画されたメンテナンスの場合、接続のドレイン ロジックにより、バックエンド ノードが適切に更新されます。 既存の接続が閉じられるまで、Azure Firewall は 90 秒間待機します。 最初の 45 秒間、バックエンド ノードは新しい接続を受け入れず、残りの時間はすべての着信パケットに RST で応答します。 必要に応じて、クライアントは別のバックエンド ノードへの接続を自動的に再確立できます。

はい。 ファイアウォール名には 50 文字の制限があります。

Azure Firewall では、スケールの際により多くの仮想マシン インスタンスをプロビジョニングする必要があります。 /26 アドレス空間を使用すると、スケールに対応できる十分な数の IP アドレスをファイアウォールに使用できるようになります。

いいえ。 Azure Firewall には、/26 よりも大きなサブネットは必要ありません。

Azure Firewall の初期スループット容量は 2.5 ~ 3 Gbps で、Standard SKU の場合は 30 Gbps、Premium SKU の場合は 100 Gbps にスケールアウトされます。 CPU 使用率、スループット、接続数に基づいて自動的にスケールアウトします。

Azure Firewall は、平均スループットまたは CPU 消費量が 60% になるか、接続使用率が 80% になると、徐々にスケーリングします。 たとえば、最大スループットの 60% に達すると、スケールアウトが開始されます。 最大スループット数は、ファイアウォール SKU と有効な機能によって異なります。 詳細については、「Azure Firewall のパフォーマンス」を参照してください。

スケールアウトには 5 から 7 分かかります。

パフォーマンス テストを行うときは、少なくとも 10 ～ 15 分のテストを行い、新しく作成されたファイアウォール ノードを活用するために新しい接続を開始してください。

接続がアイドル タイムアウト (4 分間、アクティビティがない状態) になると、Azure Firewall は TCP RST パケットを送信して接続を正常に終了します。

Azure Firewall VM インスタンスのシャットダウンは、仮想マシン スケール セットのスケールイン (スケールダウン) 中、またはフリート ソフトウェアのアップグレード中に発生する可能性があります。 このような場合、新しい着信接続は残りのファイアウォール インスタンスに負荷分散され、ダウンしたファイアウォール インスタンスには転送されません。 45 秒後、ファイアウォールは TCP RST パケットを送信して既存の接続の拒否を開始します。 さらに 45 秒が経過すると、ファイアウォール VM がシャットダウンします。 詳細については、「Load Balancer の TCP リセットおよびアイドルのタイムアウト」を参照してください。

いいえ。 Azure Firewall では、Active Directory へのアクセスは既定でブロックされます。 アクセスを許可するには、AzureActiveDirectory サービス タグを構成します。 詳しくは、「Azure Firewall サービス タグ」をご覧ください。

はい。Azure PowerShell を使用して、それを行うことができます。

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist 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 は実際にはターゲット FQDN に接続していません。 Azure Firewall では、ターゲット IP アドレスや FQDN への接続は、それを許可する明示的なルールがない限り許可されません。

TCP ping は特異なユース ケースであり、許可するルールがない場合、TCP ping はターゲット IP アドレスや FQDN に到達しませんが、ファイアウォール自体がクライアントの TCP ping 要求に応答します。 この場合、イベントはログされません。 ターゲット IP アドレスや FQDN へのアクセスを許可するネットワーク ルールがある場合は、ping 要求はターゲット サーバーに到達し、その応答がクライアントに送り返されます。 このイベントは、ネットワーク ルール ログに記録されます。

はい。 詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。

いいえ。IP グループを別のリソースグループに移動することは現在サポートされていません。

ネットワーク ファイアウォールの標準的な動作では、TCP 接続が確実に維持されるようにして、アクティビティがない場合はすぐに終了するようになっています。 Azure Firewall の TCP アイドル タイムアウトは 4 分です。 この設定はユーザーは構成できませんが、Azure サポートに問い合わせ、受信および送信接続のアイドル タイムアウトを最大 15 分に延長できます。 East-West トラフィックのアイドル タイムアウトは変更できません。

アイドル時間がタイムアウト値よりも長い場合、TCP や HTTP のセッションが維持される保証はありません。 一般的な方法として、TCP keep-alive を使用します。 この方法を使用すると、接続が長時間アクティブ状態に維持されます。 詳細については、.NET の例に関するページを参照してください。

はい。ただし、強制トンネリング モードでファイアウォールを構成する必要があります。 この構成により、Azure Firewall の操作に使用するパブリック IP アドレスを持つ管理インターフェイスが作成されます。 このパブリック IP アドレスは、管理トラフィック用です。 これは Azure プラットフォームによってのみ使用され、他の目的には使用できません。 テナント データ パス ネットワークは、パブリック IP アドレスなしで構成でき、インターネット トラフィックは、別のファイアウォールに強制的にトンネリングするか、完全にブロックすることができます。

Azure Firewall によって、顧客データがデプロイされているリージョン外に移動または格納されることはありません。

正解です。 詳細については、Logic Apps を使用した Azure Firewall と Azure Firewall ポリシーのバックアップに関する記事を参照してください。

いいえ。現在、セキュリティ保護付き仮想ハブ (vWAN) の Azure Firewall は、カタールではサポートされていません。

Azure Firewall では、接続数がハード制限されている Azure Virtual Machines を使用します。 仮想マシンあたりのアクティブな接続の合計数は 250,000 です。

ファイアウォールあたりの合計制限は、仮想マシンの接続制限 (250k) x ファイアウォール バックエンド プール内の仮想マシンの数です。 Azure Firewall は 2 つの仮想マシンで開始され、CPU 使用率とスループットに基づいてスケールアウトされます。

Azure Firewall では現在、送信 SNAT トラフィックに TCP/UDP ソース ポートを使用しており、アイドル待機時間はありません。 TCP/UDP 接続が閉じられると、使用された TCP ポートは、今後の接続ですぐに使用可能と見なされます。

特定のアーキテクチャの回避策として、Azure Firewall を使用した NAT Gateway を使用して、デプロイとスケーリングを行い、可変性と可用性のために SNAT ポートのより広いプールを提供できます。

特定の NAT については、その動作が、ファイアウォールの構成と、構成されている NAT の種類によって異なる場合があります。 たとえば、ファイアウォールに、受信トラフィック用の DNAT 規則と、ファイアウォールを経由する送信トラフィック用のネットワーク規則とアプリケーション規則がある場合があります。

詳細については、「Azure Firewall NAT の動作」を参照してください。