基礎から学ぶ！NSX検証環境構築第3回分散ファイアウォールの設定前編｜技術ブログ

2023.03.31

こんにちは。SB C&Sの山田です。

この記事は「基礎から学ぶ！NSX検証環境構築」シリーズの第3回として、分散ファイアウォール(DFW)設定の概要をご説明します。

NSXではソフトウェアとしてファイアウォール機能を提供しており、仮想マシンのネットワークを分離しなくても、マイクロセグメンテーションによってセキュリティを高めることが可能です。この前提となる準備については第2回の記事をご確認ください。

1. 分散ファイアウォール設定の概要

今回の検証環境では、分散ファイアウォール(DFW)による通信制御を確認します。実際の企業インフラでは、情報漏洩対策として仮想デスクトップ間の通信を制御するようなケースがあります。そこで今回はHorizonによる仮想デスクトップの通信制御を想定した検証環境構築を行います。

また、以前のバージョンのNSX-T分散ファイアウォールを利用するには、仮想マシンのvNIC（仮想NIC）が NSXのセグメント（オーバーレイセグメントまたはVLAN セグメント）に接続されている必要がありました。しかしNSX-T Data Center 3.2から分散ポートグループでも利用可能になりました。

今回の検証環境はNSX 4.0を利用するため、NSXのセグメントは利用せず、分散ポートグループのみを利用する環境で分散ファイアウォールを設定します。この場合も従来どおりトランスポートノードとして準備したESXiが必要ですが、その設定は第2回で済ませてあります。

2.VNware Horizonとのインテグレーション

VMware Horizon環境にNSXの分散ファイアウォールを導入するメリットとして、仮想デスクトップ同士の通信制御のルールを設定する際に、仮想マシン単位で指定できることが挙げられます。

例えば、情報漏洩の対策として部署Aから部署Bの仮想デスクトップの接続を遮断したい場合、以下のように仮想マシンをベースにした設定ができます。

部署A、部署Bの仮想デスクトップの実体となる仮想マシンを対象としたグループを作成
送信元を部署Aグループ、宛先を部署Bグループに設定して通信を制御（許可や遮断）

図1.png

そこで今回の検証は、Horizon環境での分散ファイアウォール活用に入門できるように工夫してあります。以前に投稿した「基礎から学ぶ！Horizon検証環境構築」で作成した環境をベースとして、仮想デスクトップの通信を分散ファイアウォールによって制御します。

3. 分散ファイアウォールポリシー設定の準備

ここからは、分散ファイアウォールポリシー設定の作業について概要をご紹介していきます。分散ファイアウォールの通信制御では、まずファイアウォールのポリシーを作成し、そこにルールを作成していきます。

ファイアウォールポリシー

分散ファイアウォールポリシーごとにルールは複数作成可能で、上から順番に処理されます。

それぞれのルールには、以下のような設定項目があります。

名前
- ファイアウォールのルール名です。
送信元、宛先
- グループを設定します。設定したグループに所属している仮想マシンやIPアドレスが、通信制御の対象になります。
サービス
- TCP、UDP、ICMPといったプロトコルとポート番号によるサービスが設定できます。
適用先
- ルールの適用先として、分散ファイアウォール全体か特定のグループを選択します。
アクション
- ルールにマッチしたパケットに対するアクションを指定します。

実際のNSX Managerでは以下のような画面です。

図2.png

この画面での分散ファイアウォールポリシー作成に関連する作業としては以下のものがあるので、それぞれ説明します。

グループ作成
タグ作成
除外リスト登録

グループ

分散ファイアウォールポリシールールの送信元または宛先としては、仮想マシンなどのグループを指定できます。

仮想マシンをグループへ追加する際には、仮想マシン名、OS名、NSXの機能によるタグなどをもとに検索やフィルタリングすることができます。また、１つのグループには複数の条件を設定することができます。

図3.png

グループの作成では、NSXの機能によるタグを使用できます。タグとはNSXが仮想マシンに任意の識別子を定義するラベルのような機能であり、使用することで大規模環境における仮想マシンの検索や、フィルタリングなどを迅速にできるといった管理性の向上が期待できます。

今回の検証環境では、分散ファイアウォールポリシーのルール設定でタグを使用しません。かわりに、分散ファイアウォールの除外リストに登録する管理系仮想マシン（vCenter ServerやNSX-T Managerなど）をグループ化するためにタグを使用することで機能を確認します。

図4.png

除外リスト

分散ファイアウォールは管理系の仮想マシンも適用対象となります。しかし、Connection Serverなどの通信が意図せず遮断されると仮想化基盤に大きな影響があるため、慎重なポリシー設定が必要になります。また、一般的なインフラの構成では、管理系のサーバーはセキュリティが考慮された専用ネットワークに配置されます。そのようなケースでは、管理系サーバーの仮想マシンを分散ファイアウォールポリシーの適用対象から除外しておきたい場合があります。

このような状況の対応手段のひとつとして、分散ファイアウォールには「除外リスト」という機能があり、除外対象グループのメンバーを、本来適用される分散ファイアウォールルールの対象外にできます。

4. 分散ファイアウォールのイメージ

今回の検証手順は、以下のように進めます。

仮想デスクトップ同士の通信制御

今回の検証では、Horizonによるフルクローンとインスタントクローンのデスクトッププールを、それぞれ企業の部署に見立ててグループ化し、分散ファイアウォールによる通信制御を実施します。

まず、仮想デスクトッププール同士で通信制御できるように、次のようなそれぞれの仮想デスクトップが含まれるグループを作成します。

1つ目の部署：フルクローンの仮想デスクトップによる「FC」グループ
2つ目の部署：インスタントクローンの仮想デスクトップによる「IC」グループ

そして、「FC」グループから「IC」グループへの通信制御が機能していることを確認するために、分散ファイアウォールによってICMP通信を制御（許可/拒否）します。

図6.png

許可した通信以外をドロップ（許可リスト化）

分散ファイアウォールによる基本的なポリシー作成手順を確認できたら、次の作業として、デフォルトでは通信を拒否しておき、許可された通信のみを通す「許可リスト」方式でポリシーを設定してみます。(以前はホワイトリストと呼ばれていました)

ファイアウォールのルールでは、以下のように許可ルールを追加して、それ以外の通信はドロップするように設定変更します。

FCグループとICグループからinfraグループへの通信を許可
Connection ServerからFCグループとICグループへの通信を許可
Console（操作用端末）からFCグループとICグループへの通信を許可

許可していない通信をドロップするためには、デフォルトで作成されている「Default Layer3 Rule」のアクションを「却下」に設定変更します。これにより、「FC」「IC」グループ内の仮想デスクトップ同士の通信や、「IC」グループから「FC」グループへの通信がドロップされます。

今回の検証の全体完成イメージ図は以下です。

図7.png

なお今回の検証環境では、「分散ファイアウォールのルール設定を実機で体験してみること」を優先して、ルールをできるだけシンプルにしています。そこで、管理サーバー群が分散ファイアウォールの影響を受けないように「除外リスト」を利用します。

5. 除外リスト作成

この検証環境構築では管理サーバーを除外リストに登録しておくことで、入門的な検証をしやすいシンプルなファイアウォールポリシー構成にします。今回は分散ファイアウォールポリシーの設定と動作確認をする準備として、除外リストに管理系サーバーを追加しておきます。これにより、管理操作を行うコンソールマシンから管理サーバーへアクセスできる状態と、管理サーバー同士がアクセスできる状態が維持されます。

今回の検証環境の除外リストには、次の4つの管理サーバーを含めます。除外リストの対象はグループ単位で指定する都合上、仮想マシンには「management」タグを付与して、物理マシンはIPアドレスをもとにすることでグループに追加します。なお、今回は機能検証のためにあえてタグを利用しますが、グループでメンバーを指定するためにタグが必須というわけではありません。

除外リストに追加する対象は下記のとおりです。