どのようなときに Azure Firewall を使用するか

  • 8 分

Azure Firewall がどのようなもので、どのように機能するかがわかりました。 ここで、自分の会社にとって Azure Firewall と Azure Firewall Manager が適切な選択肢であるかどうかを評価するのに役立つ条件がいくつか必要になります。 判断の助けになるように、以下のシナリオについて考えてみましょう。

  • 侵入からネットワークを保護する必要がある。
  • ユーザーのエラーからネットワークを保護する必要がある。
  • 事業内容に e コマースやクレジット カードによる支払いが含まれる。
  • スポーク間の接続を構成する必要がある。
  • 受信と送信のトラフィックを監視する必要がある。
  • ネットワークには複数のファイアウォールが必要である。
  • 階層構造のファイアウォール ポリシーを実装する必要がある。

あなたは、Azure Firewall と Azure Firewall Manager の評価の一環として、Contoso はこれらのシナリオのいくつかに直面したことを知っています。 詳細については、以降の対応するセクションを参照してください。

侵入からネットワークを保護する必要がある

多くの悪意のあるアクターに共通する目標は、ネットワークに侵入することです。 これらの侵入者は、ネットワーク リソースの利用や、機密データや専有データの調査、盗難、破壊を望んでいる場合があります。

Azure Firewall は、そのような侵入の防止を支援するために設計されています。 たとえば、悪意のあるハッカーがネットワーク リソースへのアクセスを要求して、ネットワークへの侵入を試みることがあります。 Azure Firewall では、ネットワーク パケットのステートフル検査を使用して、そのような要求のコンテキストを調べます。 要求が以前の正当なアクティビティに対する応答である場合、ファイアウォールではおそらく要求が許可されます。侵入者予備軍が送信した要求のように、見たところ要求がどこからともなく出現した場合、その要求はファイアウォールで拒否されます。

ユーザーのエラーからネットワークを保護する必要がある

ネットワークに侵入したり、ネットワーク コンピューターにマルウェアをインストールしたりするための最も一般的な方法は、おそらく、ネットワーク ユーザーだまして電子メール メッセージ内のリンクをクリックさせることです。 ユーザーはそのリンクによって、悪意のあるハッカーが管理する Web サイトに送られ、そこでマルウェアがインストールされるか、だまされてネットワーク資格情報を入力させられます。

Azure Firewall では、脅威インテリジェンスを利用して、既知の悪意のあるドメインと IP アドレスへのアクセスを拒否することによって、このような攻撃を防止します。

事業内容に e コマースやクレジット カードによる支払いが含まれる

会社の事業で、e コマースのコンポーネントを使用していたり、オンラインのクレジット カード支払いを処理したりしていますか。 その場合、あなたの会社は Payment Card Industry Data Security Standard (PCI DSS) への準拠が必要な可能性があります。 PCI DSS は、PCI Security Standards Council によって作成および管理されている、一連のセキュリティ標準です。 PCI への準拠を実現するために、PCI DSS には 12 の要件が列挙されています。 最初の要件は次のとおりです。

  • カード所有者データを保護するファイアウォール構成をインストールして管理すること。

PCI DSS では、信頼されていないネットワークとホストからの、受信と送信のすべてのトラフィックを制限するファイアウォール構成を設定する必要があると明示されています。 このファイアウォールでは、ペイメント カードの処理に必要なプロトコル以外の他のトラフィックはすべて拒否する必要もあります。

スポーク間の接続を構成する必要がある

典型的なハブとスポークのネットワーク トポロジには、次の特性があります。

  • 中央の接続ポイントとして機能する 1 つの仮想ネットワーク—"hub"。
  • ハブとピアリングされた 1 つ以上の仮想ネットワーク—"スポーク"。 ExpressRoute 回線または VPN ゲートウェイ経由で接続されたオンプレミス ネットワークも、このトポロジのスポークと見なすことができます。

スポーク ネットワークは、ハブとデータをやり取りできますが、スポークが相互に直接通信することはできません。 このような直接接続が必要な場合があります。 たとえば、あるスポーク ネットワークが、別のスポークにデプロイされた SQL データベースの情報を必要とするアプリケーション プログラミング インターフェイス (API) をホストしている場合があります。

1 つの解決策は、スポーク ネットワークを互いにピアリングすることです。 そのような接続がいくつかであればこれも機能しますが、接続数の増加につれて、短い間に手に負えない状態になる可能性があります。

より容易でセキュリティが確保される解決策は、Azure Firewall を使用してスポーク間に直接接続を設定することです。 この接続を実現するには、まずハブ内に Azure Firewall インスタンスをデプロイします。 次に、ファイアウォールを経由して他のスポークに至るよう明確にデータをルーティングするユーザー定義ルート (UDR) を指定して、スポーク仮想ネットワークを構成します。

Network diagram of a spoke-to-spoke connection between a virtual machine and a SQL database via Azure Firewall.

受信と送信のトラフィックを監視する必要がある

会社では、受信と送信のネットワーク トラフィックに関する詳細なレポートの分析が必要になる場合があります。 規制コンプライアンス、インターネット使用に関する企業ポリシーの適用、問題のトラブルシューティングなど、そのようなレポートが必要になる理由は多数あります。

Azure Firewall を構成すると、次の 4 種類のファイアウォール アクティビティの診断ログを管理できます。

  • アプリケーション ルール
  • ネットワーク ルール
  • 脅威インテリジェンス
  • DNS プロキシ

たとえば、ファイアウォールのアプリケーション規則のログには、送信要求についての次のようなエントリが含まれていることがあります。

  • 10.1.0.20:24352 から somewebsite.com:443 への HTTPS 要求。 アクション: 許可。 規則コレクション: collection100。 規則: rule105

同様に、ファイアウォールのネットワーク規則のログには、受信要求についての次のようなエントリが含まれていることがあります。

  • 73.121.236.17:12354 から 10.0.0.30:3389 への TCP 要求。 アクション:拒否

診断ログを有効にすると、以下の方法でログを監視し、分析することができます。

  • ログはネイティブの JSON 形式で直接調査できます。
  • ログは Azure Monitor で調査できます。
  • ログは Azure Firewall のブックで調査と分析を行えます。

ネットワークには複数のファイアウォールが必要である

会社の Azure フットプリントが複数の Azure リージョンにまたがっている場合は、複数のインターネット接続が存在することになります。つまり、これらの接続ごとにファイアウォール インスタンスをデプロイする必要があります。 これらのファイアウォールを個別に構成して管理することもできますが、それを行うといくつかの問題が発生します。

  • 複数のファイアウォールの管理では、作業量が非常に多くなります。
  • グローバルな規則と設定の変更は、すべてのファイアウォールに反映する必要があります。
  • すべてのファイアウォールにわたって一貫性を維持することは困難です。

Azure Firewall Manager では、すべての Azure リージョンとサブスクリプションにわたって、すべての Azure Firewall インスタンスが対象の中央管理インターフェイスを提供し、これらの問題を解決しています。 ファイアウォール ポリシーを作成してから、それらをすべてのファイアウォールに適用して一貫性を維持することができます。 ポリシーに対する変更は、すべてのファイアウォール インスタンスに自動的に反映されます。

階層構造のファイアウォール ポリシーを実装する必要がある

小規模企業の多くは、1 つでどの規模にも適合するファイアウォール ポリシーを使用できます。 つまり小規模企業では、多くの場合、ネットワーク上のすべてのユーザーとリソースに適用される単一のファイアウォール ポリシーを作成します。

ただし、より規模が大きい企業では、より細かな差異に対応する詳細なアプローチが必要とされます。 たとえば、次の 2 つのシナリオについて考えます。

  • DevOps の職場では、アプリを開発するための仮想ネットワーク、アプリをステージングするための別の仮想ネットワーク、運用バージョンのアプリ用の 3 つ目の仮想ネットワークを使用している場合があります。
  • 大規模な企業では、データベース ユーザー、エンジニアリング部門、営業部門に向けて、別個のチームが用意されている場合があります。 それらのチームはそれぞれ、別個の仮想ネットワークで実行される独自のアプリケーション セットを持っています。

すべてに共通するファイアウォール規則がありますが、各仮想ネットワーク内のユーザーとリソースには、特定のファイアウォール規則が必要です。 そのため、大規模な企業では、ほぼ必ず、"階層構造" のファイアウォール ポリシーが必要になります。 階層構造のファイアウォール ポリシーは、次の 2 つのコンポーネントで構成されます。

  • 全社的に適用する必要がある規則を実装する、単一の "基本ファイアウォール ポリシー"。
  • 特定のアプリ、チーム、またはサービスに固有の規則を実装する、1 つ以上の "ローカル ファイアウォール ポリシー"。 ローカル ポリシーでは、基本ファイアウォール ポリシーを継承してから、基になるアプリ、チーム、またはサービスに関連する規則を追加します。

Azure Firewall Manager の使用時は、基本ファイアウォール ポリシーを設定してから、基本ポリシーを継承するローカル ポリシーを作成し、基になるリソース用に設計した特定の規則を実装することができます。