Azure Firewall を作って動かしてみた

1. 主要機能

Azure Firewall は、主に以下の機能を備えております。
内容は公開情報に記載のものを少しかみ砕いてご紹介させていただいております。

参考：Azure Firewall とは
https://docs.microsoft.com/ja-jp/azure/firewall/overview#features

• 組み込みの可用性 　
  • 高可用性が組み込まれており、ロードバランサーなどの追加が不要。


• 無制限のスケーラビリティ 　
  • パフォーマンスに応じて自動でスケールアップしてネットワーク トラフィック フローの変化に対応できるので、ピーク時のトラフィックを処理するためのプランニングが不要。


• アプリケーションの FQDN のフィルタリング規則 　
  • NSG では実現不可であった、ワイルド カードが含まれた完全修飾ドメイン名（FQDN）の指定した一覧に、送信 HTTP/S トラフィックを制限可能。


• ネットワーク トラフィックのフィルタリング規則 　
  • 送信元と送信先の IP アドレス、ポート、プロトコルを基準として、“許可” または “拒否” のネットワーク フィルタリング規則を一元的に作成可能。規則は、複数のサブスクリプションと仮想ネットワークをまたがって適用可能。


• FQDN のタグ 　
  • 組み込みのタグがいくつか用意されており、Windows Update などの主に Azure における管理系の通信の制御が簡単に可能。現状用意されているタグは以下の通り。
    • Windows Update
    • Windows 診断
    • Azure Backup
    • Microsoft Active Protection Service
    • App Service 環境


• サービスタグ 　
  • 各 Azure サービスに対応したタグが用意されており、各サービスの宛先 IP アドレスがグルーピングされた状態で提供される。アドレスが変化するとサービスタグは自動的に更新される。サービスはリージョンごとの指定が可能。


• 脅威インテリジェンス 　
  • ファイアウォール用に脅威インテリジェンスベースのフィルター処理を有効にして、既知の悪意のある IP アドレスやドメインとの間のトラフィックの警告と拒否を行うことが可能。


• 送信 SNAT サポート 　
  • 仮想ネットワーク トラフィックの送信 IP アドレスはすべて Azure Firewall パブリック IP に変換される。


• 受信 DNAT のサポート 　
  • ファイアウォールのパブリック IP アドレスへの着信ネットワーク トラフィックは、変換され、変換後の IP アドレスにてフィルタルールの処理が実行される。


• Azure Monitor ログ記録 　
  • すべてのイベントは Azure Monitor と統合されるため、ストレージ、イベントハブ、Log Analytics と連携可能。




本記事では、上記機能の中の

• アプリケーションの FQDN のフィルタリング規則
• ネットワーク トラフィックのフィルタリング規則

に焦点を当てて動作を見ていきたいと思います。

2. 環境準備

左右にスクロールしてご覧ください。

※1 Azure Firewall 用のサブネット名は必ず [AzureFirewallSubnet] でなければいけません
※2 Firewall 用サブネットのアドレス空間は最小で /25 のレンジが必要となります

リソースの準備が完了したら、以下のステップに従い Azure Firewall の環境を構築します。

1. Azure Firewall リソースの作成
2. スポークサブネットの紐づけ
3. ファイアウォール ルール の作成

1. Azure Firewall リソースの作成

[全てのサービス] の [その他] カテゴリ内の [ファイアウォール] を選択し、新規作成を実施します。

設定項目は以下の通りとなっており、選択した仮想ネットワーク内に Azure Firewall 用サブネットが存在しない場合は、デプロイに失敗します。
また、作成時に選択した パブリック IP アドレス は、SNAT 時に変換される値となります。

各項目を入力し、作成が完了したら、作成した Azure Firewall の [概要] タブにて表示されている IP アドレスをメモしておきます。（後でルートテーブルにルートを追加する際に使用します）

2. スポークサブネットの紐づけ

あらかじめ準備しておいた [スポークサブネット用ルートテーブル] をスポークサブネットに適用し、デフォルトルートを Azure Firewall に向けるルートを追加することにより Azure Firewall との紐づけを行います。

これで、[fwlab-sn01] に配置されているリソースのパブリック通信はすべて Azure Firewall を経由する構成となりました。

3. ファイアウォール ルール の作成

紐づけたサブネットからの接続を許可する通信を定義します。
まずは、アプリケーションルールコレクションより、許可する宛先 FQDN を定義します。今回の例では弊社のコーポレートサイトに接続できるよう構成してみました。

ルールコレクションは、各ターゲット FQDN の定義を束ねるグループのようなものと思っていただければよいかと思います。通信先として定義するカテゴリや、システムごとに分けると管理しやすいかと思います。

ルールを作成する際、ソースアドレスにはターゲット FQDN へのアクション（許可/拒否）を適用したい通信元のアドレスプレフィックスを入力する必要があります。

実はこの設定だけでも弊社のコーポレートサイトが閲覧可能となります。チュートリアルではネットワークルールコレクションより、外部 DNS へのアウトバウンドアクセスを許可するルールをセットして、NIC の参照 DNS を変更していますが、デフォルトで DHCP より配られている [168.63.129.16] は既定で通信が可能なようで、外部への名前解決ができてしまいます。

ただし、VNet 上に DNS を配置し、それを利用して外部の名前解決を行う場合は結局ネットワークルールの追加が必要となるので、DNS のルールは作成しておきましょう。

今回は Google Public DNS（8.8.8.8, 8.8.4.4）を参照するよう、ネットワークルールを作成します。

また、VM の NIC の参照 DNS にも Google Public DNS の値を設定しておきます。これで準備は完了です。

3. 動作検証

以下の図の通り、Azure Firewall と周辺環境が出来上がりました。

[fwlab-work] にリモートデスクトップ接続し、Internet Explore を開き、許可登録をした FQDN（https://www.softbanktech.co.jp/）を参照します。

以下の通り弊社のコーポレートサイトが表示されました。

また、許可登録のない FQDN を参照しようとすると、以下の通り正しくページが表示されない状態となります。

4. まとめ

Azure Firewall は、デプロイが手軽（周辺環境含め30分くらいで作成）で、スケールも勝手にやってくれるので、ルールの管理以外はほとんど手がかからず、インターネット方向の通信の集約をする目的ではとても使いやすいなという印象です。
ただし、プライベート通信の制御ができなかったり、インバウンドの制御については D-NAT くらいしかできないので、利用シーンを見極めて導入する必要があるかと思います。利用にあたっての制限事項や注意事項の詳細は、Part.2 にてご紹介できればと思っております。

最近では、サービスタグや脅威インテリジェンスの機能などが追加されてきているので、今後もサービス拡充が期待できそうですね！

次回予告

• RBAC を使用した ストレージアカウントデータ へのアクセス管理（GA）