2025年までには楽になろう…

DC Firewall のベストプラクティス

最新SDNはエクセル台帳の夢をみるか？

自分の歳と似たような年式のクルマに乗っています。この種のクルマが好きな人からいえば決して旧車とは言ってもらえない中途半端な年代モノなのですが、私同様いささか旧式であることは間違いないです。そんなクルマなので快調に走ってはいますがところどころ細々したところが壊れてきています。私の愛車で言うとリアウィンドウの霜や雪を溶かす電熱線が機能せず、「直すのも高そうだししょうがないなぁ…」と毎冬諦めていたのですが、昨年ふと足元に落とした小銭を拾い上げる節に気がついた小さなスイッチをなんとはなしに押してみると、なんときちんと電熱線が温まって霜をとかすではないですか…では、いままで私がそのためのスイッチだと思って押していたものは一体何用なのか？！という謎が深まるばかりですが、説明書の類などはなくいまだ解がないため、次の車検の時に聞いてみようと思います。
一体何の話か？といいますと、そんな古いクルマですらいまだ新しい気付きがあるなか、最新の SDN Solution である NSX-T についてはなおのこと。日本語のドキュメントも懇切丁寧とは言い難く、まだまだ正しい使い方を日本のお客さまにきちんとお伝えしきれてなかったな、という自己反省をせざるを得ないような対応事案がいくつか続いたので、ここで改めて我々の NSX Firewall についての基本的な How To Use についてご紹介させていただければ、と思います。

データセンターにおける レガシー ファイアウォールの配備

従来よりハードウェアアプライアンスで提供されることが前提で長らく製造、販売、構築されてきたファイアウォールなので、必然、物理的なコンセプトが色濃く残っており、DC 内では主に Trusted Zone、Untrusted Zone という形で Zone に応じたセキュリティレベルを定義してデザインするのが一般的です。多くの場合、このコンセプトに沿って North-South トラフィックと表現されるような DC 内部と外部の境界を守ったり、最近では East-West トラフィックによる脅威も取り沙汰されることが多くなってきているので、その場合に内部ファイアウォールで Zone を区切る形でのデザインも採用されることが多くなってきましたが、それでもアプライアンスベースで考えるとこのくらいまでのセキュリティ防御がせいぜいの限界かと思います。

ネットワークとセキュリティの仮想化による変革

これに対して、ネットワークとセキュリティの仮想化ソリューションである NSX を前提で考えていただくと、マイクロセグメンテーションの愛称とともとにご愛顧いただいているファイアウォール機能の仮想化、分散化を実現する ”分散ファイアウォール” により、特にいままでのアプライアンスベースのファイアウォールでは制御しきれなかった East-West トラフィックに対する抜け漏れのない鉄壁防御を簡単にご提供できます。

できるようにはなるのですが、マイクロセグメンテーションの名前と有効性が有名になりすぎてしまっていて、最適なファイアウォールデザインの検討をバイパスしてしまうお客様も散見されてきた為ここで今一度アピールさせていただくと、分散ファイアウォールは NSX Firewall のウリではありますが全てではありません。対になる “ゲートウェイファイアウォール” も込で、シングルコンソールから統合的に管理することができる点、最適なセキュリティを最適なデザインで、簡単に大規模まで安定的にスケールアウトをしながら展開できることこそが NSX Firewall が提供できるセキュリティの本質です。

先ほどの North-South/East-West トラフィックと、データセンターの論理デザイン、それらに最適なツール（分散ファイアウォール & ゲートウェイファイアウォール）の関係を図示すると以下のような形になります。すべてのセキュリティポリシーを分散ファイアウォールで記載することもできなくはないですが、運用性、スケールの観点から最適な手法とは言えません。外部への接続やテナント間・Zone 間通信（North-South）についての制御はゲートウェイファイアウォールで行ったほうが一般的に比較的少ないセキュリティオブジェクトで緩やかに表現することができますし、より少ないポリシー数で記載することにもつながるので運用負荷も軽減されます。

統一的なユーザーインターフェイスの本質

以下が NSX-T における、それぞれ 2種の ファイアウォールを設定する UI 画面のサンプルになります。

分散ファイアウォール（DFW）のUI

ゲートウェイファイアウォール（GFW）のUI

如何ですか？ぱっと見とても似ていますよね？
このような形で本質的な役割や配備されるデザインが違う 2種のファイアウォールをひとつの UI から管理できることも嬉しいところですが、それ以上に本質的に重要なのは、これらを構成するコンセプトやツール群が旧来のレガシーファイアウォールではできない様々な運用上の利便性を生む仮想化ならではの形で統一的に実装されていることす。そのツール群やコンセプトを正しくご理解いただき、ゲートウェイファイアウォール（GFW）、分散ファイアウォール（DFW）共に必要なときに必要な場所へ適切に使っていただくことでデータセンター内におけるあらゆる通信セキュリティ要件に対して柔軟に対応できるようになります。

それでは、ここまで述べてきた NSX Firewall（GFW/DFW）を構成する仮想化ソリューションならではの便利なツールとコンセプトの使い方のコツについて、ベストプラクティス含めてご紹介できればと思います。

NSX Firewall のコツ その１；動的グループメンバーシップとタグを使いこなす

ファイアウォールはサービスの追加や要件の変更により日々、セキュリティポリシーを更新していくことになると思います。お客さま毎の環境によりますが、我々のヒアリングだと少なくとも週に 1 度、多くは週に 2,3 度といった頻度の変更を行っている方が多いようで、毎日なんらかのセキュリティポリシーの追加、変更を行っているといったお話を聞くことも珍しくありません。ときには セキュリティポリシーの設定をガッツリ触らなきゃいけないときもあるとは思いますが、できる限りシステム側でよしなにやってくれるにこしたことはないわけでこの辺の仕組みが NSX Firewall には備わっています。この便利さを享受してもらえてるかどうか、はひとえに導入時にオブジェクトグループの作成ポリシーをきちっと定めていただけてるかどうか、にかかってきます。

旧来のネットワークアプライアンスベース ファイアウォールのオブジェクトの作り方、考え方、というのは平たく言うとこんな感じかと思います。

# set address test ip-netmask 10.30.14.96/32
# set address-group test-group test

IP アドレスやネットワークセグメントを表現するオブジェクトを作成し、それをまとめるオブジェクトグループを構成、これをセキュリティポリシーに落とし込んで、Zone 毎に適用する、、、ベンダーによる CLI ごとの差分はあると思いますが考え方は一緒です。このデザインと運用が長らく続きすぎて脳裏に染み込んでいるので、NSX を入れ始める際にもこの考え方を前提にデザインし、運用に入ってしまいがちですが、ここでふと冷静に立ち止まり、「なんでファイアウォールの運用って楽にならないんだっけ？」「なんで NSX 使いたかったんだっけ？」と振り返ってみることが肝要です。”ネットワークアドレスとオブジェクトグループを設定で紐付ける”、という前提としてしまうと、それを管理し続ける必要が出てきてしまい、必然ネットワークの管理者に都度仕事が落ちてきます。その運用をできる限り自動化して楽したい我々 NSX 仮想ネットワーク組としては、より便利なツールの使用方法を正しく知り、導入時から仮想基盤側と歩調を併せてデザインし運用に入ることが必要です。その便利ツールの ２大巨頭こそが、”動的グループメンバーシップ” と ”タグ” になります。これらは仮想基盤のインベントリ情報と IP アドレスの紐付けを自動的に行うことで、我々ネットワーク管理者を楽にしてくれる便利ツールです。これはありがたく使わないともったいない。

・動的グループメンバーシップ

セキュリティグループの構成を、仮想マシン名、タグ、OS 名、またはコンピュータ名から自動的に構成することができる機構で、これにより IP アドレス管理の自動化を実現することができます。例えば「”仮想マシン” の ”名前” が ”Web” で ”始まる”」といった条件でグループを作ることができ、例えばこれで仮想基盤にいる Web-01 〜 Web-100 といった名前がついた 100 台の仮想サーバーに付与されている IP アドレスを一網打尽でセキュリティグループに入れ込む事ができます。また、明日 Web-101 という新しい 101 台目の仮想サーバーが立ち上がったとしても、我々ネットワーク管理者は何も手を下すことなくセキュリティグループが自動的にメンテナンスされる、という仕組みを構成することが可能になります。

動的グループメンバーシップの指定方法は、以下のように様々な組み合わせから表現することも可能ですので、更に複雑なグルーピングを and / or 条件を加えながら表現することもできるようになっています。

以前このあたりをデモ動画にしてたりもしますので、よかったらこちらもどうぞ。

→【ビデオ】NSX-T Data Center デモンストレーション その4 ; FW と LB の自動適用

・タグ

NSX Firewall におけるもう一つの便利ツールがタグになります。これは仮想マシンやネットワークなど、仮想空間におけるオブジェクトに対して”タグ”という付箋？、マーク？、フラグ？、のようなものをつけることによって簡単なグルーピングを提供するものになります。このタグを付けたオブジェクトの集合体を前述の動的グループメンバーシップで指定して使ってもらうことができます。例えば、「”仮想マシン” に ”Web” の ”タグ”が ”含まれている”」と言った具合です。

タグの使い方は簡単で、仮想マシンにタグを貼り付ける場合は、
1.名前を指定してタグを作成する
2.”仮想マシンの設定”リンクをクリック
3.仮想マシンの名前でフィルター
4.適用したい仮想マシンを選択してタグを適用
5. 保存
だけで利用準備完了です。

こうしていただくとタグという付箋を貼ったオブジェクトをひとまとめにしてFirewall のポリシーとして簡単に表現することができるようになります。例えば、以下のように旧来の環境でネットワーク単位でプロダクション（PROD）と開発環境（DEV）を分けて セキュリティポリシーで “PROD” と “DEV” 間の通信制御を行う制御をしていたとします。

# set address PROD1 ip-netmask 192.168.100.0/24
# set address-group PROD-GROUP PROD1

# set address DEV1 ip-netmask 192.168.200.0/24
# set address-group DEV-GROUP DEV1

ここに新たに ”192.168.250.0/24” というプロダクション用のセグメントと、”192.168.251.0/24” という開発用のセグメントが追加になる、となったらば如何でしょう？各セグメントのアドレス単位をオブジェクトグループに展開して、そのオブジェクトグループ間のセキュリティポリシーに整合性の合う形で設定を行う、という作業が発生します。あっという間にネットワークエンジニアにお仕事が降ってきましたね。

それと比べたときに、例えば以下のようなタグを指定したグループ間のポリシーを二行書いておいたらばどうでしょう？

これならば、仮想マシンに必要なタグを付与するだけでこのポリシーに自動的に適用させることが可能となります。さらに “192.168.100.0/24” と “192.168.250.0/24” がプロダクション用のネットワークで、 “192.168.200.0/24” と “192.168.251.0/24″ のネットワークが開発用のネットワークだ、というネットワークセグメント単位での管理や意識をする必要がなくなってきます。やろうと思えば、”192.168.0.0/16″ の範囲に存在する仮想マシン間の通信をタグによって制御すること、例えば、”PROD” のタグがついた “192.168.0.1/32″ の仮想マシンは、”DEV” のタグがついた “192.168.0.2/32” の仮想マシンに接続させない、というようなことは造作もなくできることになります。これは、これまでのネットワークを基としたゾーンセキュリティの構成概念から、より簡素化され独立したセキュリティポリシーへの管理へと転嫁させる、ということがこのタグの概念によってできるようになることを意味しています。

ちなみに仮想マシンへ付与できるタグは、1 枚に限ったことではなく複数枚付与することもできますので、慣れてくると「”Production（緑タグ）” の ”App-1（赤タグ）” の ”Web Tier（灰タグ）” にある仮想マシン全部」といったようなより柔軟な表現とコントロールができるようになってきます。

また、タグは仮想マシンだけではなくネットワークセグメントや仮想 NIC 単位にも付与することができますので、その点もお忘れなきよう。

ここまで見てきたように、動的グループメンバーシップやタグといったものは旧来のネットワークアプライアンスにはなかった概念だと思います。これは我々が NSX Firewall を使って楽をするための強力なツールになりますのでぜひ馴染んでいただければと思いますし、これを最大限有効活用するためにも導入時に仮想基盤側でどのようなルール（特に仮想マシンの命名規則）で運用を始めるか、それによってどのようなセキュリティポリシーが自動的に払い出されているか、という意識共有と（Team 内はもちろんのこと、多くの場合異なる Team 間での）合意が何よりも重要になりますので最初のデザイン時にまずこのあたりをきっちりと詰めておきましょう。

NSX Firewall のコツ その2；カテゴリーを意識してセキュリティポリシー数の圧縮と順番整理

それでは、NSX Firewall を利用する際の次のポイントです。それは作成され、適用されるファイアウォールルールのポリシー順序についてです。一般的なアプライアンス型のファイアウォールの場合、セキュリティポリシーは設定で記載された順序に応じて、上から下へとポリシーのルックアップが実行されます。これにより、競合するようなルールを書いてしまうと参照されるのは上位のルールだけで、その他は無駄なルールとなりつつゴミとして残り、これが’積もり積もってヒューマンエラーの源になります。また、セキュリティポリシー順序の正しさについて後から確認、修正を行うのは、一般的に数百〜数千行、時には数万行という量に達することもあるプロダクション環境のセキュリティポリシーでは非常に重い、憂鬱な作業になります。よって NSX Firewall ではカテゴリーという概念によりこの設定の順序管理を効率化する仕組みを採用しています。

・カテゴリー

こちらがNSX Firewall におけるカテゴリー部分を表示した UI 部分になります。記載された順序に応じて上から下へとセキュリティポリシーがルックアップされるのは従来型のファイアウォールと同様ですが、それとは別の軸で、カテゴリーという順序が設けられています。分散ファイアウォールでは、「イーサネット」→「緊急」→「インフラストラクチャ」→「環境」→「アプリケーション」というカテゴリー順序でポリシーの精査がおこなわれ、各カテゴリ内で上から下へポリシーがルックアップされる、という実装になっています。

Pre-defined のカテゴリーは、システムが自動的に利用するもの、3rd Party による検疫ソリューションなどで使われるもの、ユーザーさまが管理上使い分けるためのものと、いくつかのキャラクターにわかれているのですが、ユーザーさまが管理上使い分けるものだけをハイライトするとこのような形となります。

このカテゴリーの使い分けのポイントは、ファイアウォールポリシーの設定における絶対的な真理として「ヒットする確率の高いポリシーはできる限り上位に配備すべき」というものがあります。これにより、ファイアウォールが新規コネクションセットアップやポリシーの順序ルール変更による際に内部でルックアップするポリシーの処理数を減らすことが可能になり、それに付随して使用する CPU やメモリーといった内部リソースの節約にもつながります。新規コネクションの受付からセッションテーブルの作成、通信が Fast Path へ移行するまでの内部レイテンシーの低減にも繋がり、Day2 におけるセキュリティポリシー管理の観点でも整理、整頓、影響範囲の極小化というところにも関係してきます。

例えば DFW において、Shared サービスに対してのルールを記載する例を見てみましょう。これはインフラストラクチャ・カテゴリに “Shared Service Sample” というセキュリティポリシーを構成し、”Infra Rule Sample” というルールが、送信元 “GeneralService” グループで、宛先 “SharedServiceServer” グループにサービス “DNS&AD” を許可しているルールとなります。

このように DNS や AD 参照といった比較的利用されることが多いルールをインフラストラクチャカテゴリに記載しておいて、あとは送信元の “GeneralService” グループに許可する送信元を動的オブジェクトグループかタグで追加する運用を行うことで大きな簡略化が可能です。その後必要に応じて Zone ベースのセキュリティポリシーを環境カテゴリーに、アプリケーションやマイクロサービス毎のセキュリティポリシーをアプリケーションカテゴリーに記載していくことで、必然的に「ヒットする確率の高いポリシーが上位に」配備されていくことになります。

ちょっとした UI 上の工夫による実装で、あとはそれを使う側の気持ち一つですが、このような整理のもとにファイアウォールポリシーのルールを記載することによって変更時の影響範囲の極小化、もしくは繰り返し作業の軽減、という決して小さくない効果を生むことができるようになっていますので、ぜひご活用いただければと思います。

NSX Firewall のコツ その3；セキュリティポリシーは適用先（Applied To）を常に意識

この Blog でご紹介するトピックとしては最後のものになりますが、NSX Firewall の拡張性に関して多大な影響を持つ 適用先（Applied to）についてご紹介させていただきます。NSX Firewall は小さく始めていただきつつも、気に入っていただけたならばかなりの大規模構成まで拡張して使ってもらえるキャパシティを持っています。US のお客さま事例では、数千ホスト、数万 VMなんて規模の基盤で NSX および NSX Firewall を使っていただいているなんてこともしばしば。そのような大規模環境であっても安定的に動かすための秘訣がここでご紹介する”適用先（Applied to）”の概念となります。

・適用先（Applied to）

NSX Firewall のキラーアプリケーションとして分散ファイアウォール が支持されていることは先述申し上げました。この分散配備された仮想ファイアウォールを実装上どのようにスケールアウトできるように実現しているのか、という部分を司っている部分がこの、適用先フィールドです。Default ではここが ”分散ファイアウォール（DFW）”となっており、そのまま頬って置いても大概は動くので間違って放置したまま使ってしまっているケースをたまに見かけますが、それはダメです。重要なところなので繰り返しますが、適用先（Applied to）フィールドはプロダクションネットワークで NSX Firewall を利用する際には必ず指定するようにしてください。

これはなぜかと申しますと、サーバーのカーネルで分散配備された環境で動作する NSX Firewall であったとしても、CPU やメモリといったリソースは無限ではありません。この有限な資産を効率的に利用するために、NSX Firewall の分散アーキテクチャは仮想ファイアウォールに必要なリソースを、必要な時に、必要な分だけ、必要なところに要求する、という考え方で拡張性やスケーラビリティを担保する実装で作られています。これを Default のまま”分散ファイアウォール”のままにしておく、ということは仮想ファイアウォールのリソースをすべての NSX Transport Node （≒サーバーホスト）上に無駄に要求する、ということになってしまいます。これでは小規模のうちは問題ないですがスケールがあがるにつれて問題が浮上してきます。

よってデザインの基本として、必要なところに、必要なリソースを要求する、という認識のもとに適用先フィールドを指定して頂く必要があります。ここのフィールド指定にも先に紹介した動的メンバーシップクライテリアやタグ、と言った概念で柔軟にグルーピングしたオブジェクトグループを指定できますので、それによって必要なリソースだけをサーバーホストに要求する、という拡張性のあるデプロイメントを実現することが可能となっています。こうしておくことで、例えば vMotion で仮想マシンが他のホストに移動したとしても、それに追随して NSX が自動的に必要なリソースを必要な場所に再配備しています。よって、無駄なファイアウォールリソースが無駄な場所に残って浪費されてしまうようなこともありません。

適用先（Applied to）の設定は、セキュリティルール毎に個別で指定していただいてもいいですし、セキュリティポリシー毎にまとめて指定してもらっても構いません。ただし両方に記載をした場合は、セキュリティポリシーの方の適用先設定を優先して参照しますので、無駄に二重設定しない様にお気をつけください。

セキュリティルール”Sample Rule”に適用先を指定する場合（セキュリティポリシーはDefaultの”分散ファイアウォール（DFW）”のままでOK）

セキュリティポリシー”Sample Policy”に適用先を指定する場合（配下のルール全てに同様の適用先を指定）

まとめ

さて、長々と書いてしまいましたが、基本的にはここまででお知らせした3つのコツを念頭にデザイン、運用いただければ、概ね問題なくNSX Firewall による次世代仮想化ソリューションによる自動楽ちん運転をご享受いただけるのではないかと思います。長々書いてきたうえでなんですが、もっと長い資料もしたためてありますので、もしより細かな Tips にご興味を持っていただいたならばこちらの資料もぜひご参照ください。

さらにNSX FWの深淵に触れてみたいという方は、英語版になってはしまいますがこちらの NSX Seucirty Reference Guide もおすすめです。

弊社では日々様々なイベントを開催することも多く、アンケートにお答えいただける機会があるたびにお客さまに「今のネットワーク・セキュリティの運用での課題点はどこにありますか？」という質問をさせていただいています。その際のご回答が、一昔前は「VLANの制御や設定、ネットワークインフラの安定度が、、、」というお声も多かったのですが、最近ではすっかり「ファイアウォールの運用が日常業務内で多すぎて疲れます」という声のほうが大きくなってきている感じがします。ここまで読んでいただいた方はイメージいただけるのではないかと思いますが、たかがファイアウォール、されどファイアウォール、ということでもし既存ファイアウォールにおける日々の運用業務でお疲れならば、一度大きく運用の概念や考え方を再構成しながら楽な運用に持って行っていただくのはいかがでしょう。NSX Firewall はいまの NSX-T の前身バージョンである NSX for vShpere の時代から多くのお客さまにご愛顧頂いている鉄板のユースケースですが、まだまだお使いになったことがないお客さま、もしくはこれからはじめて使われようとされてるお客さまには上記の様な基本的な便利ツールの情報を改めてお伝えする場がなかったという反省から基本的な情報からご紹介させていただきました。少しでも皆さまの参考になれば幸いです。

余談ですが、この辺の便利ツールの使い勝手が最初はなかなかイメージしづらいのか、NSX Firewall をご検討いただくお客さまからたまに頂く質問で「いま○○社のファイアウォールを使ってるのですが、そこの Config を抜き取って、NSX Firewall に移植することってできますか？」と聞かれたりもします。セキュリティオブジェクトに IP Address やネットワークレンジをまとめて入れ込む設定もできなくはないので、API を駆使して多少の作り込みを行えば既存ファイアウォールの設定を自動的にインポート、というのもやろうと思えばできなくはないと思いますが、これではせっかく Tesla を買ったのに「レギュラーガソリンでも走りますか？」というご質問をされるようなものです。「やれること」と「やるべきこと」は異なるので、この場合に我々としてお返しすべきお答えは「給油口がないのでハイオクでも走りません」です。

せっかくネットワークとセキュリティの仮想化をご検討であれば、この機会にいっそ圧倒的に楽ちんな仮想化によるセキュリティの自動運転の世界へぜひいらしてください。VMware VCN Team 一同、ご相談をお待ちしております。

ちなみに冒頭お話した私の愛車は旧式とはいえまだまだ現役なレギュラーガソリン垂れ流し上等の非エコカーですが、趣味と生活には風流や風味が大切、昼間のビジネスはできるだけ合理的に楽しましょう、と言うのが私の信条でございます…ご迷惑をおかけして大変申し訳ありませんが、皆さまにおかれましてはぜひ地球にも優しく、でお願い申し上げます。