Azure Firewallとトラフィックの検査

Azure Firewallは、Azure仮想ネットワークの一元的なトラフィック検査とフィルター処理を提供する、クラウドネイティブのマネージド ネットワーク セキュリティ サービスです。 レイヤー 4 で動作するネットワーク セキュリティ グループとは異なり、Azure Firewallはレイヤー 3 から 7 のトラフィックを検査します。 この機能により、完全修飾ドメイン名 (FQDN) フィルタリング、脅威インテリジェンス、侵入検出および防止 (IDPS)、TLS 検査が可能になります。 ハブ仮想ネットワーク内の専用サブネットにAzure Firewallをデプロイし、スポーク ワークロードからのトラフィックをファイアウォール経由でルーティングし、検査を行ってから宛先に到達します。

この記事では、適切なAzure Firewall SKU を選択し、ハブスポーク トポロジにファイアウォールを配置し、規則の種類を構成し、NAT ゲートウェイやルート サーバーなどの補完的なサービスと統合する方法について説明します。 Azure Firewallは、Azure DDoS ProtectionおよびAzure Web Application Firewallと並ぶ3つのコアAzureネットワークセキュリティサービスの一つです。

この記事の内容

この記事では、Azure Firewallを使った集中型ネットワークトラフィックの検査について説明します。 以下について学習します。

  • セキュリティ要件とワークロードの機密性に基づく SKU レベルの選択。
  • ファイアウォールを通過するトラフィックを強制するハブ配置とユーザー定義ルート (UDR) パターン。
  • DNAT、ネットワーク、およびアプリケーションルールのルール処理ロジック。
  • オンプレミスでの検査を必要とする環境向けの強制トンネリング。
  • Premium レベルの TLS 検査と IDPS 機能。
  • SNAT ポート スケーリング用の NAT ゲートウェイと BGP ベースのルーティング用のルート サーバーとの統合。

この記事が必要なユーザー

ワークロードで次の 1 つ以上の機能が必要な場合に、Azure Firewallをデプロイします。

  • 一元化されたエグレス制御: NSG IP ベースの規則を超えて、ワークロードが到達できる外部 FQDN と URL を制限する必要があります。
  • 東西検査: スポーク仮想ネットワーク間のトラフィックは、ファイアウォールで許可される前にステートフルな検査ポイントを通過する必要があります。
  • コンプライアンスが義務付けられたログ記録: 規制フレームワークでは、FQDN レベルの細分性を使用して、許可された接続と拒否された接続をレイヤー 7 で完全に可視化する必要があります。
  • 脅威の防止: コマンド アンド コントロール コールバック、悪用の試行、横移動などの悪意のあるトラフィック パターンを識別するには、署名ベースの侵入検出と防止が必要です。
  • TLS 検査: 暗号化されたトラフィック (HTTPS) がワークロードに到達するか、ネットワークを離れる前に、脅威を復号化して検査する必要があります。

FQDN を認識せずにレイヤー 4 パケット フィルタリングのみを必要とする組織では、 NSG と ASG を 、よりシンプルで低コストの代替手段として考慮する必要があります。

リフトアンドシフトフォーカス:オンプレミスのファイアウォール規則ベースをAzure Firewall ポリシーに変換します。 まず、HTTP/S 以外のトラフィックのネットワーク 規則と、FQDN ベースのフィルター処理のアプリケーション ルールから始めます。 移行中に広範な許可ポリシーから始めて、Azure Firewallログを確認した後で規則を強化します。

フォーカスを最新化する:ハブ内の一元化された SNAT および DNAT ポイントとしてAzure Firewallを使用します。 アプリケーション スポーク間およびスポークとインターネット間のトラフィックを検査し、AKS と Azure PaaS エグレスにアプリケーション ルールと FQDN タグを使用し、アプリケーション層が機密性の高いトラフィックを交換する TLS 検査を計画します。

クラウド間のフォーカス:セキュリティで保護された仮想ハブにAzure Firewallをデプロイして、クラウド間のトランジット トラフィックを検査します。 AWS または Google Cloud からの IPSec トンネル トラフィックのネットワーク ルールを構成し、IDPS を使用して接続されたクラウド間の異常なトラフィック パターンを監視します。

Azure Firewall SKU の階層

Azure Firewallは、3 つの SKU レベルで利用できます。 各層は、前のレベルの機能に基づいて構築されます。

能力 Basic Standard Premium
ステートフル パケット インスペクション ✔ ✔ ✔
FQDN フィルタリング（送信方向） ✔ ✔ ✔
ネットワーク 規則 (IP、ポート、プロトコル) ✔ ✔ ✔
アプリケーション ルール (FQDN、URL) ✔ ✔ ✔
NAT 規則 (DNAT) ✔ ✔ ✔
脅威インテリジェンスのフィルター処理 アラートのみ ✔ (アラート + 拒否) ✔ (アラート + 拒否)
DNS プロキシ ✗ ✔ ✔
Web カテゴリ ✗ ✔ ✔
IDPS (侵入の検出と防止) ✗ ✗ ✔
TLS 検査 ✗ ✗ ✔
URLフィルタリング（フルパス） ✗ ✗ ✔
明示的なプロキシ ✗ ✔ ✔
リージョンの可用性 制限付きリージョン すべてのリージョン すべてのリージョン
最適な用途 開発/テスト、小規模なワークロード 標準生産 セキュリティが高く、コンプライアンスに基づく

SKU を選択する方法

次の決定基準を使用します。

  • 開発/テスト環境がある場合、または脅威インテリジェンス フィルター処理 (拒否モード) や高度な検査を行わずに FQDN ベースのエグレス フィルター処理を必要とする小規模なワークロードがある場合は、[基本] を選択します。 Basic SKU には、アラート専用モードの脅威インテリジェンスが含まれていますが、拒否モード、DNS プロキシ、または Web カテゴリはサポートされていません。 Basic SKU には、AzureFirewallManagementSubnetと共に専用のAzureFirewallSubnet (/26 以上) が必要であり、限られたリージョンで利用できます。
  • 脅威インテリジェンスベースのフィルター処理、FQDN ルール解決用の DNS プロキシ、Web カテゴリのフィルター処理、Azure Firewall Managerによる一元化されたポリシー管理を必要とする運用ワークロードには Standard を選択します。 Standard は、既知の悪意のある IP アドレスとドメインへの接続をブロックする脅威インテリジェンス フィードを備えた完全なステートフル検査エンジンを提供します。
  • 暗号化トラフィックの TLS インスペクション、継続的に更新されるルールを備えたシグネチャベースの IDPS（50 を超えるカテゴリにまたがる 67,000 件以上のシグネチャをリアルタイムで更新）、または FQDN を超えて URL パス全体をフィルタリングする機能が、規制要件またはセキュリティ要件で義務付けられている場合は、Premium を選択してください。 Premium は、暗号化されたトラフィック検査が必須である金融サービス、医療、政府などの業界に必要です。

Note

ファイアウォールを再デプロイせずに Standard から Premium にアップグレードします。 Premium から Standard にダウングレードするには、再デプロイが必要です。

ハブ配置と UDR ルーティング パターン

ハブ仮想ネットワーク内で正確にAzureFirewallSubnetという名前の専用サブネットにAzure Firewallをデプロイします。 このサブネットには、最小サイズ /26 (使用可能な IP アドレス 59) が必要です。

ルーティング アーキテクチャ

スポーク サブネット トラフィックが、インターネットやその他のスポークに到達する前にハブ仮想ネットワーク内のAzure Firewall経由でルーティングされるハブスポーク トポロジの図。

ハブスポーク トポロジでは、スポーク ワークロード サブネットはトラフィックをインターネットや他のスポークに直接ルーティングしません。 代わりに、各スポーク サブネットの UDR は、既定のルート (0.0.0.0/0) をAzure Firewallプライベート IP アドレスに設定します。 このパターンにより、南北 (インターネットに接続) と東西 (スポーク間) の両方のすべてのトラフィックが、検査のためにファイアウォールを通過します。

UDR 構成パターン:

ルート テーブル (適用先) アドレスプレフィックス ネクストホップの種類 ネクストホップ アドレス
スポーク サブネット A 0.0.0.0/0 仮想アプライアンス ファイアウォールプライベート IP
スポーク サブネット A 10.1.0.0/16（別のスポーク） 仮想アプライアンス ファイアウォールプライベート IP
スポーク サブネット B 0.0.0.0/0 仮想アプライアンス ファイアウォールプライベート IP
スポーク サブネット B 10.0.0.0/16（別のスポーク） 仮想アプライアンス ファイアウォールプライベート IP

AzureFirewallSubnet自体はほとんどのシナリオでUDRを必要としません。なぜならファイアウォールはシステムルートを使って仮想ネットワークピアリングを通じてスポークネットワークに到達しているからです。 Azure Route Serverと統合すると、ファイアウォール サブネットは BGP 経由のルートを学習します。 この方法では、ネットワークの拡大に合わせて手動でルートメンテナンスを行う必要がなくなります。

Tip

Azure Virtual Network Managerは、Azure Firewallを次ホップとして使用するようにルート テーブルの構成を自動化できるため、多くのスポーク サブスクリプションで手動の UDR 管理を減らすことができます。

サブネットの要件

Subnet 最小サイズ Purpose メモ
AzureFirewallSubnet /26 Azure Firewall インスタンスをホストする 厳密に名前を付ける必要があります AzureFirewallSubnet
AzureFirewallManagementSubnet /26 管理トラフィック (Basic SKU のみ) Basic SKU に必要です。他の SKU での強制トンネリングの場合は省略可能

ハブ仮想ネットワークの設計とサブネットの計画の詳細については、 ハブスポーク トポロジに関するページを参照してください。

ルールの種類と処理ロジック

Azure Firewallは、Azure Firewall ポリシーを使用してルールを処理します。 ルールはルール コレクションに編成され、ルール コレクション グループにグループ化されます。 ファイアウォールは、次の優先順位で規則を評価します。

  1. DNAT ルール (宛先ネットワーク アドレス変換): 最初に処理されます。 パブリック IP からの受信トラフィックを、ファイアウォールの背後にあるプライベート IP に変換します。
  2. ネットワーク ルール: 2 番目に処理されます。 送信元 IP、宛先 IP、ポート、プロトコル (レイヤー 3/4) に基づいてトラフィックを許可または拒否します。
  3. アプリケーション ルール: 最後に処理されました。 FQDN、URL、または Web カテゴリ (レイヤー 7) に基づいて送信トラフィックを許可または拒否します。

各ルールの種類内で、ルール コレクション グループは優先度 (最も低い数値 = 最も高い優先度) によって評価されます。 グループ内では、ルール コレクションは優先度によって評価されます。 最初の一致ルールは、アクション (許可または拒否) を決定し、さらに評価を停止します。

DNAT ルール

DNAT 規則を使用して、ファイアウォールのパブリック IP アドレスを介して内部サービスを発行します。 ファイアウォールは、宛先アドレスをパブリック IP からバックエンド サービスのプライベート IP に変換します。 一般的なシナリオは次のとおりです。

  • ポート 443 でファイアウォールのパブリック IP を介して内部 Web サーバーを公開する
  • パブリック IP を VM に割り当てずに、ジャンプ ボックスへの制御された RDP または SSH アクセスを提供する
  • インターネットからの受信アクセスを必要とする HTTP/S 以外のサービスの発行
Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

DNAT ルールは、変換されたトラフィックを許可するための対応するネットワーク ルールを暗黙的に追加します。 DNAT ルールが一致すると、トラフィックは変換され、それ以上ネットワーク ルール処理なしで許可されます。 セキュリティを確保するために、ワイルドカードを使用するのではなく、DNAT ルール内のソース IP アドレスを特定のインターネット ソースに制限します。

ネットワーク ルール

ネットワーク ルールは、レイヤー 3 とレイヤー 4 のトラフィックをフィルター処理します。 送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコルに基づいてトラフィックを許可または拒否する必要がある場合は、ネットワーク ルールを使用します。 ネットワーク ルールは FQDN 解決を実行しません。 IP アドレスに対して厳密に動作します。 一般的なユース ケースは次のとおりです。

  • 特定のポートでのスポーク間通信を許可する (たとえば、TCP 1433 上の SQL Server)。
  • 特定のタイム サーバーへの NTP (UDP 123) の許可。
  • 拒否規則を使用して既知の悪意のある IP 範囲へのトラフィックをブロックする。
  • 特定のサブネット間のネットワーク診断に ICMP を許可する。

ネットワーク ルールでは、TCP、UDP、ICMP、および任意のプロトコルの種類がサポートされます。 IP アドレス、IP 範囲、サービス タグ、および IP グループをソースと宛先として指定できます。

アプリケーション ルール

アプリケーション ルールは、FQDN、URL、Web カテゴリに基づいて送信 HTTP/S および MSSQL トラフィックをフィルター処理します。 アプリケーション ルールでは、FQDN 解決のために DNS プロキシ機能が必要です。 アプリケーション ルールは、次の場合に使用します。

  • 特定の FQDN ( *.microsoft.com や storage.blob.core.windows.netなど) へのアクセスを許可する必要があります。
  • github.com/myorg/* を許可し、GitHub の他のパスをブロックする場合など、URL パス（Premium SKU のみ）でフィルターしたいことがあります。
  • Web カテゴリ全体を許可またはブロックする必要があります (たとえば、"開発者ツール" を許可し、"ギャンブル" をブロックします)。

アプリケーション ルールは、一般的なAzure サービス (Windows Update、Azure Backup、HDInsight など) の FQDN タグを提供します。これにより、必要な FQDN を 1 つのタグにグループ化することでルールの作成が簡略化されます。

Important

Azure Firewallで DNS プロキシを有効にすると、ファイアウォールはワークロードの DNS リゾルバーとして機能します。 仮想ネットワークのDNS設定をファイアウォールのプライベートIPを指すように設定し、FQDNベースのルールが正しく解決できるようにします。 DNS アーキテクチャの詳細については、 DNS セキュリティとプライベート名解決に関するページを参照してください。

SNAT の動作

既定では、Azure Firewallはパブリック IP アドレス宛ての送信トラフィックに SNAT (送信元ネットワーク アドレス変換) を適用します。 宛先がプライベート IP 範囲 (RFC 1918) または共有アドレス空間 (RFC 6598) の場合、ファイアウォールは SNAT トラフィックを行いません。 ファイアウォールは、インターネットにバインドされた接続のソース IP を、そのパブリック IP アドレスのいずれかに変換します。 各パブリック IP は、バックエンド インスタンスあたり 2,496 の SNAT ポートを提供します。

送信接続率が高いワークロードの場合は、NAT ゲートウェイと統合して、パブリック IP あたり 64,512 ポート (最大 16 個のパブリック IP、合計約 100 万の SNAT ポート) にスケーリングします。

NAT ゲートウェイを AzureFirewallSubnetに関連付けると、すべての送信インターネット トラフィックで NAT ゲートウェイのパブリック IP アドレスが自動的に使用されます。 ファイアウォールは引き続きトラフィックを検査しますが、NAT ゲートウェイは SNAT 変換を処理します。 二重 NAT は発生しません。

Note

ゾーン冗長Azure Firewallを使用する NAT ゲートウェイには、StandardV2 NAT ゲートウェイ SKU が必要です。 NAT ゲートウェイは、セキュリティで保護されたハブ アーキテクチャVirtual WANではサポートされていません。

Firewall Manager とポリシーの継承

Azure Firewall Managerでは、複数のAzure Firewall インスタンスにわたって一元化されたセキュリティ ポリシーとルート管理が提供されます。 主な機能は次のとおりです。

  • ポリシー階層: 組織全体のルールを使用して基本 (親) ポリシーを作成し、子チームが親から継承する子ポリシーを作成できるようにします。 親ルールは、子の優先順位の値に関係なく常に優先されます。
  • リージョン間管理: ファイアウォール ポリシーは、任意のリージョンまたはサブスクリプションのファイアウォールに関連付けることができるグローバル リソースです。
  • マルチファイアウォール ガバナンス: 異なるリージョンのハブ ファイアウォール間、またはセキュリティで保護されたVirtual WAN ハブ間で、一貫したセキュリティ体制を適用します。

NAT 規則はファイアウォール固有であり、親ポリシーから継承されません。 脅威インテリジェンス モードは継承されますが、子ポリシーではより厳密なモードでのみオーバーライドできます。 ファイアウォールの関連付けが 0 個または 1 個のポリシーは、追加料金なしで含まれます。 追加の関連付けでは課金が発生します。

強制トンネリング

一部の規制環境では、インターネットに接続されているすべてのトラフィックは、インターネットに到達する前に、まずオンプレミスの検査ポイントを経由する必要があります。 Azure Firewallでは、この要件に対応するための強制トンネリングがサポートされています。

強制トンネリングを有効にする場合:

  • AzureFirewallManagementSubnetは、ファイアウォール管理トラフィックをインターネットに直接送信します。 このサブネットには、次ホップ インターネットを使用して 0.0.0.0/0 へのルートが必要です。 オンプレミスの検査を通じて管理トラフィックを強制することはできません。
  • このAzureFirewallSubnetは、インターネットに接続されたワークロードトラフィックを、ExpressRouteやVPN Gatewayを通じてオンプレミスのファイアウォールやサードパーティネットワーク仮想アプライアンス(NVA)にルーティングします。
  • DNAT ルールは、受信トラフィックがファイアウォールのパブリック IP に直接到達できないため、強制トンネリング モードではサポートされていません。
  • ファイアウォールでは、強制トンネリングを構成するときに、 AzureFirewallSubnet のパブリック IP は必要ありません。これは、すべての送信トラフィックがオンプレミス パスを経由して終了するためです。

コンプライアンスが義務付けられている場合は、すべてのインターネットにバインドされたトラフィックのオンプレミスの可視性が必要な場合、または既存のオンプレミスセキュリティ スタックでAzure Firewallをチェーンする必要がある場合は、強制トンネリングを使用します。 一般的なシナリオとしては、データ所在地の規制の対象となる金融サービス環境や、一元化されたインターネット ブレークアウト要件を持つ政府ネットワークなどがあります。

Important

強制トンネリング モードでは、 AzureFirewallManagementSubnet には独自のパブリック IP と、次ホップとしてインターネットを指す 0.0.0.0/0 の UDR が必要です。 この構成により、Azureは管理チャネルをファイアウォールに保持できます。

TLS 検査 (Premium)

Azure Firewall Premium は、送信 HTTPS 接続を傍受し、トラフィックを復号化して、IDPS シグネチャとアプリケーション ルールに照らして検査した後、再暗号化して転送します。 このプロセスには、Azure Key Vaultに格納されている中間 CA 証明書が必要です。

証明書の要件

Requirement 仕様
証明書タイプ 中間 CA
キー サイズ RSA 2048ビット以上
CA フラグ TRUE
主な使用法 KeyCertSign
有効性 少なくとも 1 年先
Storage Azure Key Vault (エクスポート可能である必要があります)

ファイアウォールは中間 CA 証明書を使用して、インターセプトされた接続用のサーバー証明書を動的に生成します。 信頼の警告を回避するために、エンド ユーザーのブラウザーとアプリケーションは、証明書ストア内の組織のルート CA または中間 CA を信頼する必要があります。

侵入検知および防止システム (IDPS)

Premium SKU には、50 以上のカテゴリにわたって 67,000 を超えるルールを持つフル マネージド IDPS エンジンが含まれています。 署名は、毎日 20 ~ 40 以上の新しいルールがリリースされ、継続的に更新されます。 IDPS は、次の 2 つのモードで動作します。

  • アラート モード: トラフィックをブロックせずに署名の一致をログに記録します。 初期デプロイとチューニング中に使用します。
  • アラートモードと拒否モード: IDPS 署名に一致するトラフィックをログに記録し、ブロックします。 チューニング後に運用環境で使用します。

IDPS カテゴリには、マルウェアのコマンド アンド コントロール、フィッシング、トロイの木馬、ボットネット、エクスプロイト キット、脆弱性、SCADA/ICS プロトコルが含まれます。

Caution

TLS 検査では待機時間が発生し、プライバシーに影響します。 組織の法務チームとコンプライアンス チームが、暗号化されたトラフィックの検査を承認していることを確認します。 バイパス ルールを使用して、必要に応じて機密性の高いカテゴリ (医療、銀行) を除外します。

AKS エグレス フィルタリング

Azure Kubernetes Service (AKS)クラスターで制御されたエグレスが必要な場合、Azure Firewallはクラスター ノードの FQDN ベースの送信フィルター処理を提供します。 エグレス フィルターを使用しないと、AKS ノードは任意のインターネット エンドポイントに到達できるため、サプライ チェーンとデータ流出攻撃の攻撃対象領域が増加します。

このパターンを実装するには:

  1. outboundTypeが userDefinedRouting に設定され、ノード サブネット上にカスタム ルート テーブルが設定された AKS をデプロイします。
  2. 既定のルート (0.0.0.0/0) を Azure Firewall プライベート IP に設定します。
  3. 必要な AKS FQDN (コンテナー レジストリ、API サーバー エンドポイント、Microsoft パッケージ リポジトリ) を許可するアプリケーション 規則をファイアウォール ポリシーに作成します。
  4. 必要な非 HTTP/S エンドポイント (NTP、DNS、トンネル接続) のネットワーク 規則を作成します。

このパターンにより、セキュリティ チームは、AKS ノードが到達できる外部エンドポイントを可視化し、制御しながら、クラスターが正常に機能できるようになります。 必要な FQDN は、AKS 機能セットによって異なります。 GPU ノード、Azure Monitor、またはAzure Policyを使用するクラスターには、追加の承認済みリスト エントリが必要です。

FQDN の要件と規則の詳細な例については、「Azure Firewallを使用して AKS デプロイを保護する」を参照してください。

Note

Azure Firewallを使用した AKS エグレス フィルター処理では、プラットフォームチームとアプリケーション チーム間で慎重に調整する必要があります。 FQDN ルールが見つからないと、ポッドのスケジュールエラーとイメージ プル エラーが発生します。 制限の緩いポリシーから始めて、ファイアウォール ログでトラフィック パターンを観察した後で締め付けます。

設計上の考慮事項

ファイアウォールの設計フォーカスをリフトアンドシフトする

  • オンプレミスのファイアウォール規則をAzure Firewallポリシーに変換します。HTTP/S 以外のプロトコルにはネットワーク規則を使用し、FQDN フィルタリングが必要な HTTP/S または MSSQL の宛先にはアプリケーションルールを使用します。
  • 現在のセキュリティ体制を反映する広範な許可ルールから始めて、移行後にAzure Firewall ログを使用して必要な宛先とポートを特定して、それらを強化します。
  • IP グループを使用してソースゾーンと宛先ゾーンをモデル化し、ルールのメンテナンスが既存のセグメント化境界に従います。
  • 1 日目に診断設定を有効にして、アクセスを絞り込む前に、Azureトラフィック パターンをオンプレミスのベースラインと比較できるようにします。

ファイアウォール設計の焦点を最新化する

  • アプリケーション スポークの集中型 SNAT および DNAT ポイントとしてハブ ファイアウォールを使用して、イングレス ポリシーとエグレス ポリシーを IT マネージド ハブに維持します。
  • アプリケーション層間で東西 TLS 検査または運用 IDPS の強制が必要な場合は、Azure Firewall Premium を有効にします。
  • FQDN タグとアプリケーション ルールを使用して、大規模な宛先 IP リストを維持することなく、AKS と Azure PaaS の依存関係を許可します。
  • 受信フローが承認された検査パスを介してのみバックエンド スポークに到達するように、Front Door または Application Gateway の設計で DNAT 要件を確認します。

クロスクラウド ファイアウォールの設計に重点を置く

  • Azureがブランチ、Azure、およびその他のクラウド ネットワークの通過ポイントである場合は、セキュリティで保護された仮想ハブにAzure Firewallをデプロイします。
  • ルートがAzureに到着した後、ネットワークルールを使用して、AWS トランジットゲートウェイ、AWS 仮想プライベートゲートウェイ、または Google Cloud VPN 添付ファイルからの IPSec トンネルトラフィックを検査します。
  • IDPS を有効にして、クラウド環境間の横移動を示す異常な東西およびクラウド間のトラフィック パターンを検出できます。
  • 脅威インテリジェンス のフィルター処理を有効にして、1 つのポリシー サーフェスを使用して、接続されているすべてのクラウドの既知の悪意のある宛先をブロックします。

前提条件

Azure Firewallをデプロイする前に、次の手順を実行します。

  • AzureFirewallSubnet: ハブ仮想ネットワークには、最小サイズ /26 の AzureFirewallSubnet という名前の専用サブネットが含まれている必要があります。 サブネット計画のガイダンスについては、 仮想ネットワークとサブネットの設計 に関するページを参照してください。
  • ハブ スポークまたはVirtual WAN トポロジ: スポーク ネットワークからのトラフィックをルーティングする中央ハブにAzure Firewallをデプロイします。 トポロジ オプションについては、ハブスポーク トポロジまたはVirtual WANを参照してください。
  • IP アドレス プラン: ファイアウォール サブネット、管理サブネット (強制トンネリングを使用する場合)、およびパブリック IP アドレスのアドレス空間を予約します。 IP アドレスの計画を参照してください。
  • Azure Firewall Manager: 複数のファイアウォール インスタンス間で基本規則を共有するポリシー階層が必要な場合は、Azure Firewall Managerを使用します。
  • Log Analytics ワークスペース: デプロイ前にファイアウォール診断ログ用のワークスペースを作成し、1 日目からトラフィックを監視し、ルールをトラブルシューティングできるようにします。

セキュリティに関する考慮事項

  • ログ記録: 診断設定を有効にして、Azure Firewallログを Log Analytics ワークスペースに送信します。 構造化ログは、許可および拒否されたすべての接続に対する FQDN レベルの可視性を提供し、監査とフォレンジック分析をサポートします。
  • 可用性: 可用性ゾーン間でAzure Firewallをデプロイし、可用性 SLA を最大化します。 現在の SLA の割合については、Azure Firewallの SLA を参照してください。
  • 多層防御: Azure Firewallは NSG を補完しますが、置き換えるわけではありません。 マイクロセグメント化のためにサブネットと NIC レベルで NSG を適用します。 ファイアウォールを使用して、一元化されたポリシー、脅威インテリジェンス、およびレイヤー 7 の検査を行います。
  • 検査対象の適切なサイズ: Web からアプリ、アプリからデータベースへのアクセスなどのアプリケーション内層を含め、ファイアウォールを通過するすべてのフローを強制すると、待機時間とギガバイト単位の処理コストが追加されます。 信頼された層間の東西トラフィックには NSG と ASG を使用し、信頼境界を越えるトラフィック (インターネットバインド、クロススポーク、ハイブリッド、またはクロスクラウド) のファイアウォール検査を予約します。 このアプローチにより、ファイアウォールは検査のメリットを得るトラフィックに集中し続け、不要なコストを回避できます。
  • DDoS 保護: Azure DDoS Protection を使用して、Azure Firewallに関連付けられているパブリック IP を保護します。 DDoS 保護を参照してください。
  • ExpressRoute トラフィック: ExpressRoute を使用する場合は、ハイブリッド トラフィック フローを検査するために、Azure Firewall経由でプライベート ピアリング トラフィックを転送するように UDR を構成します。

詳細情報

次のステップ

Tip

あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。

リフトアンドシフト体験の次の手順:

移行されたネットワークの監視を設定する: ファイアウォールを構成した後、Network Watcherを使用して接続とパフォーマンスを検証します。

次に、最新化の取り組みを行います。

WAF を使用して Web アプリケーションを保護する: 顧客向けの Web アプリ用に Front Door または Application Gateway にWeb Application Firewallを追加します。

マルチクラウドへの移行における次のステップ:

クラウド間の監視を設定する: クラウド間の資産のトラブルシューティングは、運用上困難です。 監視は必須であり、オプションではありません。

  • Last updated on