この記事は Nicolas Vibert 氏のブログ Distributed Firewall on VMware Cloud on AWS の翻訳です。 翻訳の一覧はこちら。

今回のブログ記事では、VMware Cloud on AWS（VMC on AWS）上の分散ファイアウォール（DFW）について深堀りしていきます。まずは、分散ファイアウォールの基本的な概念からご説明します。

分散ファイアウォールの概念

分散ファイアウォールは、NSX Data Center の重要な機能であり、基本的には仮想マシンを仮想ファイアウォールで囲う機能を提供します。

仮想ファイアウォールはステートフルなレイヤー 4（L4）ファイアウォールで、OSI モデル のレイヤー 4 までのトラフィックを検査することができます。簡単に言えば、IP アドレス（送信元と送信先）とトランス ミッション プロトコル（TCP）/ ユーザー データグラム プロトコル（UDP）ポートを見て、これらの基準に基づいてトラフィックをフィルタリングします。

VMware のファイアウォールのユニークな点は、仮想データセンターの コンテキスト ビュー を持っていることです。これにより、分散ファイアウォールは、送信元と送信先の IP アドレスだけではなく、仮想マシン（VM）の基準に基づいてワークロードを保護することができます。

従来のファイアウォールは、送信元と送信先の IP アドレスに基づいています。VMware の分散ファイアウォールは、仮想マシンの 名前 や タグ などの メタデータ など、よりスマートな基準に基づいてワークロードを保護することができます。

これにより、ビジネス ロジックに基づいたセキュリティ ルールを構築することができます（タグや命名規則（うまく構築されていれば、物理的な場所、ビジネス アプリケーション、ワークロードがテストなのか、開発なのか本番なのか、などを指定することができます））。

VMware の分散ファイアウォールを使用することで、データセンター内で East-West のファイアウォールを提供し、マイクロセグメンテーションを実現し、最終的には潜在的なセキュリティ侵害の影響を軽減し、コンプライアンス目標を達成することができます。この概念について詳しく知りたい方は、Micro-Segmentation for Dummies という本 をお読みください。

North-South とは、インターネットから VMware Cloud on AWS に出入りするトラフィックを指します。East-West では、データセンター/クラウド内のトラフィックを指します。

それでは、VMware Cloud on AWS 上での DFW の利用に焦点を当ててみましょう。

VMware Cloud on AWS 上の分散ファイアウォール

分散ファイアウォールがなければ、VMware Cloud は基本的に 1 つのフラット ゾーンになります。

  • 論理セグメント 上のすべてのVMは、互いに通信することができます。
  • 論理セグメント上の VM は、別の論理セグメント上の VM と通信することができます。
  • East-West のセキュリティはありません。

VMware Cloud を使用している顧客が特定のアプリケーションをホストしたり、テスト/開発ワークロードをより多くホストする場合には問題ないかもしれませんが、顧客が DC 全体を VMC on AWS に避難 させたり、VMC 内で非武装ゾーン（DMZ）を用意したい場合には、ある程度のレベルのセグメンテーションが必要になることがよくあります。

VMC Cloud コンソール を開くと、以下のようなメニューが表示されます。

VMware Cloud on AWS 上の NSX Manager に直接アクセスすることはできず、ネットワークとセキュリティの設定はすべてVMware Cloud コンソールまたは API 経由で構築されていることを覚えておいてください。

分散ファイアウォールのセクション

セキュリティ要件を分解するためのルールには、4 つの上位レベルのセクションがあります。

これらの上位レベルのセクションは、単にセキュリティ ロジックを構築するための方法です。このモデルに合わせてセキュリティ ルールを作成する必要はありません。このモデルに合わせてセキュリティルールを作成する必要はありませんが、事前に設定したセクションのいずれかにすべてのルールを定義した方が、セキュリティ ルールを整理しやすいと思われる場合は、そのように定義することもできます。

4 つの上位レベルのセクション

緊急時のルール: 緊急時に必要な一時的なルールに適用されます。

例えば、VM の 1 つが侵害された場合、その VM との間のトラフィックをブロックするルールを作成することができます。

インフラストラクチャ ルール: インフラストラクチャ ルールのみに適用されます。

インフラストラクチャ ルールは、ワークロードとコア/共通サービス間の通信を定義するグローバル ルールです。例えば、次のようになります。すべてのアプリケーションは、アクティブ ディレクトリ（AD）とドメインネーム システム サーバー（DNS）のセットと通信する必要があります。

環境ルール: ゾーンを区切って広いグループに適用されます。

例えば、本番環境がテスト環境に到達できないようにルールを設定します。

アプリケーション ルール: 特定のアプリケーション ルールに適用されます。

例えば、「app-1」と「app-2」との通信を許可したり、「app-3」と「app-4」間のトラフィックをブロックしたりします。

デフォルト ルール: すべてのトラフィックを許可します。

トラフィックは最初に緊急ルール、次にインフラストラクチャ ルール、環境ルール、アプリケーション ルール、そして最後にデフォルト ルールによって処理されます。

最後のルールはすべてのトラフィックを許可します。今日では、デフォルトルールを「allow」から「deny」に変更することはできません。最後に「全てのトラフィックを許可する」ルールがあるということは、その前にトラフィックを「拒否対象をリスト」していることを意味します (前のルールでは許可できないトラフィックを指定しています)。

もし「許可対象をリスト」(どのトラフィックが通過を許可されているかを指定し、それ以外のすべてをブロックする) したいのであれば、すべてのトラフィックを拒否するために “アプリケーション ルール” カテゴリのルールの一番下に手動のルールを追加する必要があります。

セクションとルール

分散ファイアウォール ポータル内では、サブセクションを作成し、各セクション内にルールを作成することができます。

各ルールは標準的なファイアウォール ルールです。

なんの変哲もありません。各ファイアウォール ルールには、名前、ソース（“Nico’s VM” と呼ばれるグループ）、デスティネーション（“any”）、サービス（通常は TCP/UDP のポート番号、または、インターネット コントロール メッセージ プロトコル（ICMP））、アクション（許可、ドロップ、拒否）、VMware Log Intelligence（VMware のクラウド ログ プラットフォーム）にログインするかどうかが設定されています。

インベントリ、グループ化、およびタグ付け

上記では、「Nico’s VM」という名前のグループを作成したことがわかりました。

グループ化の概念は、基準に基づいてオブジェクトのグループを作成し、このグループにセキュリティ ポリシーを適用できるようにすることです。

タグ付けでは、ユーザーが仮想マシンにタグを割り当てることができます。これらのタグ付けされた仮想マシンは、自動的にファイアウォール ポリシーに使用されるグループの一部にすることができます。

以下のような異なる基準に基づいてグループ化オブジェクトを作成することができます。

  • IP アドレス
  • VM インスタンス
  • VM 名のマッチング条件
  • セキュリティタグのマッチング基準

では、これらを試してみましょう。

IP アドレスに基づくグループ

単一のIPアドレス、または Classless Inter-Domain Routing (CIDR) の範囲、またはその両方に基づくグループ。例えば、10.10.10.0.0/16 と固有 IP 10.20.34.56 のグループを作成してみました。

VM インスタンスに基づくグループ

手動で選択した VM に基づくグループ。このグループに追加できるのは 5 つの VM だけなので、価値は限られています。例えば、私は “WindowsM “という名前の単一の VM でグループを作成しました（そう、その VM は “WindowsVM “となるはずだったのですが、私の太い指のせいで Typo してしまいました）。

名前に基づくグループ

VM の名前に基づいたグループ。一貫した命名規則（例えば、COUNTRY-CITY-DC-PROD-APP-NUMBER）を構築すると、あなたの VM（例えば、UK-LONDON-DC-TEST-SQL-01A）は、作成時に自動的にセキュリティ グループにアタッチされ、セキュリティ ポリシーの番号が割り当てられるかもしれません。

名前に TEST が含まれているので、環境セクションで、このグループは PRODUCTION とは通信できないというルールがあるかもしれません。

また、名前に SQL が含まれている場合は、アプリケーション セクションで SQL 用のポート 1433 のみをその VM に許可するルールが指定されているかもしれません。

このようにポリシーを構築することの利点は複数あります。1) 最初から VM が保護されていること、2) セキュリティの一貫性があること、3) セキュリティ ルールがビジネス ロジックのように読めること（IP アドレスが何を表しているかを調べるのではなく）です。

下の例では、「webSG」というグループを作成しました。VM の名前に “web “が含まれている場合、自動的にグループの一部になり、ポート 443 または ポート 80 のトラフィックのみが許可されます。

下の VM は全て自動でグループに追加されました。実は WebServer-4 は私がグループを作成した後に作成したもので、作成時に自動的にこのグループに追加されて保護されていました。

タグに基づくグループ

タグはクラウド時代には非常に普及しており、特に AWS の世界ではクラウドプラットフォームを大規模に運用する上で非常に有用なものとなっています。タグは、クラウドのエンティティを識別し、それに基づいてコストや料金を検証するために使用することができます。タグはビジネスユニット、テナント、国、環境（テスト、開発、開発）などを表すことができます。

他のクラウドソリューションアーキテクトと共有したラボでは、自分の VM に自分の名前（nico）をタグ付けすることにしました。

グループが作成されるとすぐに、どのメンバーがグループの一部であるか、どこかで使用されているかどうかをすぐに確認することができます（ファイアウォールルールで使用されているかどうかは、参照先を表示することでわかります）。

実際のところ、これにより、ユーザーはセキュリティポリシーを大幅に簡素化し、「従来の」ファイアウォールのように IP アドレスを利用するのではなく、メタデータを利用してセキュリティポリシーを構築することができるようになります。

VMware Cloud on AWS のリソース

Check out my personal blog #RunVMC for more on VMC on AWS. Here are a few deep dive posts: VMC on AWS については、私の個人ブログ #RunVMC をチェックしてみてください。ここでは、いくつかの深堀りされた記事をご紹介します。

ハンズオンラボ（HOL）: インストール不要の無料で試せる テスト ドライブ をご利用いただけます。