Restructuring dc f-wbynsx_202106

1
©2021 VMware, Inc.
Data Center Firewall の再定義
ヴイエムウェア株式会社
ソリューション技術本部
ネットワーク＆セキュリティ技術統括部
NSX Service-defined Firewall Best Practice

©2021 VMware, Inc. 2
 この資料には、現在開発中の製品/サービスの機能が含まれている場合があります。
 新しいテクノロジーに関するこのセッションおよび概要は、VMware が市販の
製品/サービスにこれらの機能を搭載することを約束するものではありません。
 機能は変更される場合があるため、いかなる種類の契約書、受注書、
または販売契約書に記述してはなりません。
 技術的な問題および市場の需要により、最終的に出荷される製品/サービスでは
機能が変わる場合があります。
 ここで検討されているまたは提示されている新しいテクノロジーまたは機能の価格および
パッケージは、決定されたものではありません。
免責事項

Intrinsic Security
Built-in Context-centric
Unified
あらゆるデバイスからネットワークやクラウドに至るまで、
インフラ全体でアプリとデータをセキュアに保つための包括的アプローチ

Hybrid Edge Public
Any Device
Any Application Traditional Cloud Native SaaS
Any Cloud Telco
エンドポイントからクラウドまでアプリとデータに関与するインフラ全体のセキュリティを制御
Intrinsic Security
Workload
Endpoint Identity
Cloud
Apps and
Data
Network
Analytics

5
©2021 VMware, Inc.
DC Security Overview

North-South と East-West トラフィック
これまでの Data Center Security
External Networks
Mgmt Shared PCI
East-West
DMZ
North-South
Data Center
• 階層型に配備された多段のファイアウォール
• できる限り通信の送信元に近い場所でセキュ
リティポリシーの強制を実施
より緩やかなルールセット
より細かなルールセット

Virtual Security Zones と Micro-Segmentation
• Zone 間の通信は基本的にはNGにしたい
• Zone間で許可する通信、およびZone内で許可する
通信をできる限り最小化したい
（Micro-Segmentation）
- Deny by default or
- Allow by default (から始めて徐々に絞る)
• Network を論理的な境界でセグメント化（Zone）
- e.g. テナント、組織、部門など
10.1.4.0
Data Center
VM-1
VM-3
VM-2
10.1.3.0
10.1.1.0 10.1.2.0
DMZ
境界型FW
（Mgmt Zone）
境界型FW
（共有 Zone）
境界型FW
（PCI Zone）
境界型FW
（外部接続）
DC内の通信セキュリティのために；

NSX による Gateway Firewall と Distributed Firewall
SDDC
• Gateway Firewalls（GFWs）
- 仮想マシン or 物理アプライアンスとして動作
する NSX Edge node がGFW機能を提供
- ネットワーク境界でのトラフィック精査を実施
- 各 Edge node は個々のファイアウォールとし
て動作するが、NSX Manager により一元的に
管理することが可能
• Distributed Firewall（DFW）
- ハイパーバイザーに組み込まれ、各VMごとに
専用のファイアウォールを仮想的に配備
- ネットワーク・トポロジーに依存しないセキ
ュリティ強制を提供可能
- 分散配備された一つの仮想的なファイアウォ
ールとして動作
VM-1 VM-2
ESXi
VM-3 VM-4
ESXi
NSX Edge
DFW
GFWs
DC内の通信セキュリティを GFWとDFWで NSXが効率的に提供

10.0.0.0
NSX による Gateway Firewall と Distributed Firewall
SDDC
• Gateway Firewalls（GFWs）
- North-South通信とEast-West通信を制御する
境界型ファイアウォールとしての柔軟なデザイ
ンを提供
- 仮想/物理間接続用外部強化ファイアウォール（N-S）
- Zone 間接続の境界ファイアウォール（E-W）
• Distributed Firewall（DFW）
- テナント内部の通信を可視化・最小化するこ
とによるマイクロセグメンテーション化
- ゼロトラストを実現するワークロード毎の最小単位
でのセキュリティ（E-W)
DC内の通信セキュリティを GFWとDFWで NSXが効率的に提供
10.3.x.0
NSX Edge Node
10.1.x.0 10.2.x.0
VM-1
VM-3
VM-2
VM-1
VM-3
VM-2
VM-1
VM-3
VM-2
DFW
GFWs DMZ
境界型FW
（Mgmt Zone）
境界型FW
（共有 Zone）
境界型FW
（PCI Zone）
境界型FW
（外部接続）

10
©2021 VMware, Inc.
Virtual Zones
- Deployment Options

旧来型のアプライアンスによる対応とヘアピントラフィック
Data Center のセキュア化は困難で複雑
課題
限定的なスループット
選択的な適用と可視化
柔軟性の欠如と安定的なポリ
シー適用の困難性
データセンター全体に統一的
なセキュリティレベルを展開
できない
IDS/IPS
FIREWALL

NSX の Servcie-defined Firewall：
旧来型のアプローチによるトレードオフを解消
解決策
分散・ハイパーバイザー内へ
の組み込み型セキュリティ
圧倒的なスループットを提供
するスケールアウト型アーキ
テクチャ
インフラ全体に渡ってブライ
ンドスポットを削減し統一的
なセキュリティを展開可能
FIREWALL
IDS/IPS

Perimeter
Test Prod
データセンタートラフィックの
うち East-West トラフィックが
占める割合
~85%
Dev
NSX Service-defined Firewall
定義されたオブジェクトを利用
Test/Dev/Prod
Network/Tags
早急なコンプライアンス対応
拡張性の影響を受けないスケール
アウト
アプリケーション単位の可視化
セキュリティの変更時にネットワ
ークの変更は必要なし
Virtual Zones - Network Segmentation

NSX-T Distributed IDS/IPS
NSX-T Distributed Firewall
ESXi / KVM NSX-T BM Edge
Distributed & Gateway Firewall
Centralized
Management
NSX-T VM Edge
NSX-T
Gateway Firewall
Tier-0/1 GW
Physical Router
NSX Manager

既存の論理/物理ネットワークを利
用した仮想Zone
各 VM ごとに専用のZone ファイ
アウォールを配備することが可能
ハイパーバイザーのカーネル内で
機能を提供
コンピュートキャパシティが向上
するごとにスケールを拡張
Virtual Zones – With Distributed Firewall
AD NTP DHCP DNS CERT
境界FW
DMZ
NON-PROD
PROD
Services

Virtual Zones – With Gateway Firewall
Gateway Firewall
Tier-0
Physical
Router
PROD
Tier-1 GW
10.1.1.0/24 10.2.2.0/24
10.2.1.0/24
外部との境界、Zone間境界、テナ
ント間境界、での通信制御
Use case
Implementation
tier-0 , tier-1 ゲートウェイで動作
Gateway (Tier-0 and Tier-1) の
Uplink ポートで機能を提供
Gateway Firewall は NSX-T
Edge Node （仮想マシン or 物理
アプライアンス）内にインスタン
スとして配備される
NON-PROD
Tier-1 GW
10.1.2.0/24
Gateway Firewall

NSX Firewall – データーセンター内のあらゆる通信要件に対応
VLAN と Overlay、NSX & Non-NSX 環境のワークロードに対応
物理ルーター
VM VM
VLAN SEG 300
NSX Managed
VM
Physical Server Physical Server
VLAN SEG 200
NSX Managed
1
Tier-0
VM
Overlay-Seg
VM
2
Tier-1
VM
VLAN 500
Non-NSX managed
VM
VLAN 600
Non-NSX managed
3
Gatewy の “Service Interface” を利用す
ることによる NSX で管理していない
VLAN 上のワークロード間通信に対する
Gateway FW
NSX により管理された
Overlay セグメント上のワークロード
に対する DFW
Overlay-Seg
VM
Tier-1
VM
VLAN 400
NSX Bridge
Firewall
Non-NSX managed
4
NSX Overlayセグメント上のワークロードと
NSX に管理されていないVLAN上のワークロード
通信に対する Bridge (L2) Gateway FW
NSX により管理された VLAN 上のワ
ークロードとベアメタルサーバーに
対する DFW DFW-> NSX Distributed Firewall
GFW-> NSX Gateway Firewall
BFW-> NSX Bridge Firewall
Tier-1
2
B
2
B
Zone/テナント間の境界FW
としての Gateway FW

18
©2021 VMware, Inc.
Architecture

ユーザーのセキュリティポリシーを保持
セキュリティポリシーに適用されたオブジェク
トをIP アドレスに変換してデータプレーンに
書き込み
オブジェクトを構成するIP データベースをメ
ンテナンスし、ユーザーにStatusを提示
Management, Control and Data Planes
Management/Control Plane
Distributed data plane
ESX/KVM
VM Edge
N-VDS
LCP MPA
MPA- Management plane Agent, CCP- Central Control Plane, LCP- Local Control Plane, N-VDS – NSX-managed Virtual Distributed Switch
vNICごとに L3/L4/L7 AP-ID のルールをデー
タプレーンにプログラム
Flow State テーブルの管理
Status/Stats をMPにレポート
Management/C
ontrol Plane
NSX Manager Cluster
GUI/REST/CMP
LCP MPA
VDS 7.0
ESX/KVM
LCP MPA
VDS 7.0
ESX/KVM
LCP MPA
VDS 7.0
中央集中型サービス
Edge Node (VM or BM) による中央集中型サ
ービスの提供 - GW Firewall, NAT, DHCP,
VPN, LB, etc…
BM Edge

NSX-T Distributed Firewall (DFW)
ZONE 間 FW のパケットウォーク
ESX/KVM
Logical Representation Physical Representation
Tier-1
DR
10.1.1.0/24 10.2.1.0/24 10.2.2.0/24
10.2.2.0/24
Tier-0
Tier-1 Tier-1
10.1.1.0/24 10.2.1.0/24 10.2.2.0/24
10.2.2.0/24
Tier-1
DR
Tier-1
DR
Physical Router
Ç√
Distributed FW
Policy Enforcement
Ç√

VM へ vNIC ごとのステートフル
な Context ベースのファイアウォ
ールを提供
柔軟な制御を持ったセキュリティ
を提供
不必要な Port や Protocol の通信
をBlock
不必要な East-West トラフィック
が無制限に通信を行える
あらゆる Port や Porotocol の通
信が許可されてしまう
Without NSX
With NSX
Micro-segmentation
What does it mean?
Without NSX
With NSX
あらゆる Port と Protocol
の通信が許可
TCP 443 or APP_ID = HTTPS
User = corpUser1

NSX-T Datacenter Distributed Firewall
ESX における Data Plane の実装
ESX Data Plane
VDS 7.0/N-VDS*
ESX
MPA
GUI/REST
LCP
https
TCP 443, TLS 1.2
Policy Rules & Groups
NSX Channel
TCP 1235, TLS 1.2
vSIP
FW Kernel Module
Slot 2
Userspace
Kernel Space
Stats & Status
TCP 1234, TLS 1.2
DFW
Rule & Flow Table
NSX Manager Cluster
*-> N-VDS = NSX Virtual Distributed Switch
DPI
Engine
L7 APP-ID
ワークロードに対する接続を
vSphere VDS 7.0 or NSX Virtual
Distributed switch (N-VDS) が提
供
DFW は vSip カーネルモジュール
と IO chain フィルターから構成さ
れる
LCP がポリシー内の “Applied To”
フィールドを参照しながら、各
vNIC 単位のファイアウォールルー
ルテーブルを効率的に管理
管理者が定義したRuleにのっとっ
てActiveなFlowの Flow State テ
ーブルを管理

Rule ID SRC DST Service Action
1 ANY WEB HTTPS Allow
2 WEB APP HTTP Allow
3 APP DB MYSQL Allow
4 ANY ANY ANY Block
Flow Table
Rule Table
State
EST
Flow
Entry
Flow 1
Index
1
Flow 2 のパケットは
通信を許可するFW
Rule 2にヒットし、パ
ケットは宛先へ転送さ
れる
Flow 2 Not Found
2
4
WEB VM が APP VM に対して新規に通信を開始（eg. Flow2）
“SRC: WEB
DST: APP
PORT: HTTP
TCP- SYN”
1
DFW がこの新規通信を受信し、既存Flowで
該当する通信がないか Flow Table を参照
-> このFlow2の新規通信はFlow Tableにないので新規Flowとして認識.
3
Flow Table には Flow 2が存在していないので、
DFW は Rule Table を上から下へ順に 5 tuple での参照を行う
このとき許可された “Flow 2” の通信が Flow table に New Flow Stateとして登録される
これによりこのセッションの後続のパケットは既存通信としてFlow Tableにて認識され高速に転送される
5
VDS 7.0
EST
Flow 2
2
NSX-T Datacenter Distributed Firewall
DFW Policy Lookup – Flow Table & Rule Table
DFW
ESX

NSX-T Gateway Firewall (GFW)
ZONE 間 FW のパケットウォーク
ESX/KVM
Tier-1
SR/DR
Tier-1
SR/DR
Tier-0
SR/DR
Tier-1
DR
10.1.1.0/24 10.2.1.0/24 10.2.2.0/24
10.2.2.0/24
Tier-0
Tier-1 Tier-1
10.1.1.0/24 10.2.1.0/24 10.2.2.0/24
10.2.2.0/24
Tier-1
DR
Tier-1
DR
Physical Router
Physical Router
Centralized FW
Policy Enforcement
BM Edge Node
VM Edge Node

NSX-T Gateway Firewall (GFW)
外部から内部 Zone への FW パケットウォーク
ESX/KVM
Tier-1
SR/DR
Tier-1
SR/DR
Tier-0
SR/DR
Tier-1
DR
10.1.1.0/24 10.2.1.0/24 10.2.2.0/24
10.2.2.0/24
Tier-0
Tier-1 Tier-1
10.1.1.0/24 10.2.1.0/24 10.2.2.0/24
10.2.2.0/24
Tier-1
DR
Tier-1
DR
Physical Router
Physical Router
Centralized FW
Policy Enforcement
BM Edge Node
VM Edge Node

NSX-T Gateway Firewall
• Tier-0 External Interfaces
 外部ネットワークの物理ルーター
（TOR）に接続
 ユーザーが設定で作成
• Tier-1 Uplink Interfaces
 Tier-0 ゲートウェイに接続
 Tier-1 ゲートウェイを Tier-0 ゲートウ
ェイに接続した際にシステムが作成
 Service Interface
 NSX-Tのサービスを NSX が管理して
いない VLAN にいるワークロードに対
して提供する場合に利用
 VLANとの接続を提供
 Tier-1 Gatewayにて利用可能
 Downlink Interface:
 Overlay セグメントをゲートウェイに
接続するためのインターフェイス
 GFW 機能は未サポート
GW Interfaces
Tier-1 GW
Tier-0 GW
External Interface (Uplinks)
Tier-1 Uplink
Gateway Firewall
Service Interface
10.1.1.0/24 10.1.2.0/24
Physical Router
（TOR）
Downlink Interface
U1 U2
Gateway Firewall

GFW Active/Standby Tier-1/0
• GFW の Flow state はGateway
間でActive から Standby へと
リアルタイムに同期される
• GW と GFW 切り替えは Edge
Node の Health-check/Failover
に依存
• GFW failover の最短時間は、
BM Edge で~300 msec
VM Edge で ~1.5 sec
• 切替時には既存の N-S 通信の
flow は新しくActive になった
GW と同期された Flow State
を即座に利用できる
High Availability
Flow State
Sync
Edge Node 1
Tier-1
Tier-0
Active
Active
Edge Node 2
Tier-1
Tier-0
Standby
Standby
Flow State
Sync
Edge HA BFD Keepalive/Failover Time
Bare Metal Edge: Keep alive/Failover: 100msec / ~ 300 msec
VM Edge: Keep alive/Failover: 500 msec /~1.5 sec
Edge Cluster

High Availability - – NSXCLI GFW HA output
GFW Active/Standby Tier-1/0
Flow State
Sync
Edge Node 1
Tier-1
Tier-0
Active
Active
Edge Node 2
Tier-1
Tier-0
Standby
Standby
Flow State
Sync
Edge HA BFD Keepalive/Failover Time
Bare Metal Edge: Keep alive/Failover: 100msec / ~ 300 msec
VM Edge: Keep alive/Failover: 500 msec /~1.5 sec
Edge Cluster
Edge-1> get firewall 16cea0ab-c977-4ceb-b00f-3772436ad972
sync config
HA mode : primary-active
Firewall enabled : true
Sync pending : false
Bulk sync pending : false Last status: not-started
Failover mode : non-preemptive
Local VTEP IP : 172.16.213.123
Peer VTEP IP : 172.16.213.125
Local context : 16f04a64-ef71-4c03-bb5c-253a61752222
Peer context : 16f04a64-ef71-4c03-bb5c-253a61752222
connection
Connection count: 1
0x00002551a000004c: 10.114.217.26:33650 ->
10.114.208.136:22 dir out protocol tcp state
ESTABLISHED:ESTABLISHED fn 3061:0
Edge-1>
Edge-2>get firewall 16cea0ab-c977-4ceb-b00f-3772436ad972
sync config
HA mode : secondary-passive
Firewall enabled : true
Sync pending : false
Bulk sync pending : true Last status: ok
Failover mode : non-preemptive
Local VTEP IP : 172.16.213.125
Peer VTEP IP : 172.16.213.123
Local context : 16f04a64-ef71-4c03-bb5c-253a61752222
Peer context : 16f04a64-ef71-4c03-bb5c-253a61752222
connection
Connection count: 1
0x00002551a000004c: 10.114.217.26:33650 ->
10.114.208.136:22 dir out protocol tcp state
ESTABLISHED:ESTABLISHED fn 3061:0
Edge-2>

29
©2021 VMware, Inc.
Virtual Zone
- Design Consideration

Getting Started
NSX Internal Firewall – Virtual Security Zones
DMZ
PROD NON-PROD
SERVICES

Inter Zone & Intra Zone Policy
Phase-1: Virtual Security Zones/Segmentation
DMZ
PROD NON-PROD
SERVICES

各アプリ単位でのセキュリティ – アプリが利用するポートとプロトコルをプロファイル
Phase 2: NSX APP Level Security
DMZ
PROD NON-PROD
SERVICES
APP-1-VM’s
APP-2-VM’s
Phase-2: APP Level Firewall Policy
各アプリのContextに則った仮想Zoneを構成

アプリのプロフィルを利用 - Micro-Segmentation policiy でアプリ内の通信を必要最低限に
Phase 3: Intra-APP Micro-Seg Policy
DMZ
PROD NON-PROD
SERVICES
APP-1-VM’s
APP-2-VM’s
WEB
MID
DB WEB
MID
DB
Phase-3: Intra-APP Micro-Seg Policy
より詳細な allow-list によるポリシー構成

Network, Workload, Application, User Context などをベースとする柔軟なグルーピング機構
Virtual Zone を柔軟に定義する：NSX Grouping
Static
Members
Criteria-Based
IP/MAC
User Identity (IDFW)
AD Groups
IP/MAC
Addresses/Subnets
Segment
Segment Port
VNIC
Virtual Machine
Group
Segment Port (Tag )
Segment ( Tag )
Virtual Machine ( Tag )
Virtual Machine (Name)
OS Name
VM Hostname
O p t i o n s E x a m p l e
Nested Group
“XYZ-APP-GROUP”
Members “XYZ-WEB-GRP”+ “XYZ-MID-GRP” + “XYZ-DB-GRP”
Group
“XYZ-WEB-GRP”
VM with name starts with
“xyz-web”
Group
“XYZ-MID-GRP”
VM with
tag “pci” & tag “xyz-mid”
Group
“XYZ-DB-GRP”
VM on
Segment “XYZ-DB-
SEGMENT”
172.16.10.0/24
XYZ-WEB-SEGMENT
GW
172.16.20.0/24
XYZ–MID-SEGMENT XYZ –DB-SEGMENT 172.16.30.0/24
xyz-web-1 xyz-web-2

35
©2021 VMware, Inc.
Best Practice - Grouping

Network, Workload, Application, User Context などをベースとする柔軟なグルーピング機構
NSX Grouping
Static
Members
Criteria-Based
IP/MAC
AD Groups
IP/MAC
Addresses/Subnets
Segment
Segment Port
VNIC
Virtual Machine
Group
Segment Port (Tag )
Segment ( Tag )
OS Name
VM Hostname
O p t i o n s B e s t P r a c t i c e s
• おおまかな Segmentation 単位のグルーピング
- IP Block/CIDR や Segment といった Static な因子を利用
• E.g. Prod/Non-Prod, PCI/Non-PCI-Zone
• Application/Application レベルのグルーピング
- VM Tags や VM name といったDynamic な因子を利用、こ
れら両方を組み合わせた表現も可能
• 複数の AND/OR クライテリアによる Dynamic Grouping
o できる限り VM Tag/name “Equals” を使用
o その他の正規表現を使う際は導入後の運用管理に留意する
- contains/starts with/ends-with/not-equals
• Nested group – 複雑な管理運用を回避するためにも
3レベルまでのNest Groupに収めることを推奨

NSX Security Tags
Overview
Overview
様々な要素にTagによる因子の割当が可能
• VMs
• Segments &
• Segment-Ports
割当てられた Tag によりワークロードの
context を認識する事が可能に
動的なグループ構成やポリシーの作成に利
用することが可能 -Zone, Inter-App, Intra-
APP …
VM ごとに複数の Tag を割り当てることも
可能、最大数は30まで
各Tag は ”Scope（範囲）”という副因子を含
めることも可能 (optional)
Web App DB
APP-1
APP-2
Production Development
Web App DB
App 1
App 2
App 1
Web-Tier App-Tier DB-Tier
Shared Services
AD
DNS
Shared Services
App 2
APP-1 APP-2

NSX Security Tags
Benefits
Benefits
Tag による動的な Group/セキュリティポリ
シーを構成することが可能に
IP (v4/6) アドレスや物理/論理ネットワー
ク・トポロジーに依存しないセキュリティ
を実現
新しいサービスやワークロードの立ち上げ
、消去などのライフサイクルに添った自動
的なセキュリティ強制を提供することが可
能に
個別のアプリケーションごとやZone, テナ
ントなど動的なポリシーをきめ細やかに配
備
異なる環境に対して容易な使い回しができ
自動的なセキュリティによる管理運用負荷
の軽減に寄与
Web App DB
APP-1
APP-2
Web App DB
App 1
App 2
App 1
Web-Tier App-Tier DB-Tier
Shared Services
AD
DNS
Shared Services
App 2
APP-1 APP-2

NSX Tagging – Best Practice
Multiple TAGs vs Combined Tag
PROD APP-1 WEB
GROUP-1: PROD
match tag = PROD
PROD_APP-1_WEB
GROUP -2: PROD-APP-1
match tag = PROD &&
match tag = APP-1
GROUP-3: PROD-APP-1-WEB-VM
match tag = PROD &&
match tag = APP-1 &&
match tag = WEB
GROUP-1: PROD
match tag “starts-with”/”contains” PROD
match tag “starts-with”/”contains” PROD_APP-1
match tag = PROD_APP-1_WEB
Combined TAG
Multiple TAG’s VS
複合的なタグによりできること；
• NSX のオブジェクトに対して複数のメタデー
タを付与することが可能
• 最大で30までのTagをオブジェクト単位ごと
に付与することが可能（システムWideでは数
千〜数万のTagをサポート）
• 5 つまでの AND/OR GROUP クライテリアに
よるの表現をサポート
複数 Tag を利用する際の注意点；
• 初期設計時に注意深くルール決めを行う
必要あり
• 運用開始後に Tag のルールを変更する必
要がでてしまうと影響範囲の精査確認な
ど柔軟性を欠く運用になってしまう
• できる限り正規表現 (contains/starts-
with/end-with) のマッチクライテリア
によるグルーピングを利用したほうが複
数Tag 設定時の && オペレーションの煩
雑さを回避できる

SCOPE（範囲）オプションでできる
こと
• NSX のオブジェクトに対して複数のメタデータ
を付与することが可能
• 最大で30までのTagをオブジェクト単位ごとに
付与することが可能（システムWideでは数千〜
数万のTagをサポート）
• 5 つまでの AND/OR GROUP クライテリアによ
るの表現をサポート
Scope を利用する際の注意点；
• Scope を含んだ Tag を利用する場合は、
初期設計時に注意深くルール決めを行う必
要あり
• 重複したメタデータ構造となる場合があり
複雑性が発生 – E.g. とあるTag に対する
Scopeのメタデータが他のNSX Tagのメタ
データと重複してしまう場合、など
Tag with/without Scope
Tag: PROD Tag:APP-1 Tag:WEB
GROUP-1: PROD
match tag = PROD
Tag: APP-1; Scope: PROD
match tag = PROD &&
match tag = APP-1
match tag = PROD &&
match tag = APP-1 &&
match tag = WEB
GROUP-1: PROD
match tag “” ; Scope = PROD
match tag = APP-1 ; Scope = PROD
match tag = APP-1 ; Scope = PROD &&
match tag = WEB ; Scope = APP-1
Tag With Scope
Tag Without Scope VS
Tag: WEB; Scope: APP-1
＊多くの環境にとって、 NSX は必要十分な Tag と Group
クライテリア数量をサポートしているので、できる限り複数
TagやScopeを利用しないシンプルなTag構成にしておくこと
が望ましい

Tagging VM vs Segment vs Segment-Port
PROD MGMT
VM Tag Segment Tag Segment port Tag
Grouping オプションサポートされる Grouping クライテリア:
• Equals,
• Contains,
• StartsWith,
• EndsWith
サポートされる Grouping クライテリアは1つのみ；
• “Tag : Equals”
Bulk Tagging
(オブジェクトへの複数Tag割当)
UI & API から実施可能未サポート
Tag 割当のタイミング VMが作成された瞬間 Segment が作成された瞬間
（VMの作成や接続には関係しない）
VM が Segment に接続された
瞬間
利用シーン VM レベルのグルーピングやポリシー制御を
行いたいあらゆる場面
• 大まかなグルーピングを行いた
い場合、例えば ZONE/Tenant
に付随した Segment を表現す
る場合など
• VM がマルチホーム接続されて
いる環境で、接続する
Segment に応じたポリシーを
利用したい
• VM がマルチホーム接続され
ている環境で、接続する
Segment に応じたポリシー
を利用したい
• Conrainer Plugin は
Group/Policyを分離するた
めに Port Tagging Label を
利用
Tag の保持期間 VM が Inventory から削除されるまで Tag
情報は保持される
Segment が Inventory から削除
されるまで Tag 情報は保持され
る
VM/Containers が削除される、
もしくは他のSegment に接続
し直されるまで Tag 情報は保持
される
Dynamic Grouping Members
（動的に追加されるGroup メンバー）
• VM に関連する VNIC/Segment-Port
• VM の IPアドレス
• Segment に接続されている
VNIC/Segment-Port
• Segment に接続されているす
べてのワークロードにおけるIP
アドレス
• 接続されている
VNIC/Segment-Port
• 接続されている
VNIC/Segment-Port に関連
したIPアドレス
PROD
PROD-SEG
MGMT-SEG
MGMT
WEB

Tag and Grouping Example
PROD-Environment/ZONE
DMZ
Application
Confidential
Compliance
APP-1-A
APP-1-B
APP-1-C
APP-1-D
APP-2-A
APP-2-B
APP-2-C
APP-2-D
PROD APP-1
A. Tag: app-1-web Scope: PROD-DMZ
B. Tag: app-1-service1 Scope: PROD-APPLICATION
C. Tag: app-1-service2 Scope: PROD-CONFIDENTIAL
D. Tag: app-1-db Scope: PROD-COMPLIANCE
GROUP-PROD
match criteria
Scope == PROD-DMZ OR
Scope == PROD-APPLICATION OR
Scope == PROD-CONFIDENTIAL OR
Scope == PROD-COMPLIANCE
PROD APP-2
A. Tag: app-2-web Scope: PROD-DMZ
B. Tag: app-2-service1 Scope: PROD-APPLICATION
C. Tag: app-2-service2 Scope: PROD-CONFIDENTIAL
D. Tag: app-2-db Scope: PROD-COMPLIANCE
GROUP-PROD-APP-1
Match criteria
Tag == app-1-web Scope == PROD-DMZ OR
Tag == app-1-service1 Scope == PROD-APPLICATION OR
Tag == app-1-service2 Scope == PROD-CONFIDENTIAL OR
Tag == app-1-db Scope == PROD-COMPLIANCE
GROUP-PROD-APP-2
Match criteria
Tag == app-2-web Scope == PROD-DMZ OR
Tag == app-2-service1 Scope == PROD-APPLICATION OR
Tag == app-2-service2 Scope == PROD-CONFIDENTIAL OR
Tag == app-2-db Scope == PROD-COMPLIANCE
TAGGING
GROUPING

NSX Tagging
Tag to VMs
インベントリ＞タグ
から Tagを作成
割り当て先の“仮想マ
シンの設定”
から作成した Tag を
ワークロードに対して
適用

NSX Tagging
Tag to VMs（Best Practice）
Tag付け時には仮想マ
シン名からフィルタを
行うことで、対象とな
る仮想マシンを抽出す
ることが可能なので、
仮想マシンを払い出す
ときの命名規則を初期
フェーズから決めて運
用に入ることが重要

NSX Tagging
Tag to Segments
ネットワーク＞セグ
メント
から Segment を作成
保存 > 設定の続行
で Tag の割り当て
フィールドが表示され
るので必要に応じて
“タグ（必須）”、“範囲
（オプション）” を適
用

NSX Tagging
Tag to Segment-ports
ホーム
から設定したい
Segment Port を検索
して、“セグメント
ポートで編集”
Tag の割り当てフィー
ルドが表示されるので
必要に応じて“タグ
（必須）”、“範囲（オ
プション）” を適用

Workload & Policy Grouping Methodology & Consumption
• Grouping: 静的・動的、両方の表現
形式によるメンバーシップグループ
を構成
• Tag を利用して VM, Segment,
Segment-Port を容易にグルーピン
グすることが可能
• Tag のインシデント、及び Scope（
範囲）と呼ばれるSub-インシデント
を含んだメタデータでグルーピング
を構成
• 5つまでの (Tag を利用した) AND &
OR クライテリアを使った表現をサ
ポート
Dynamic Membership Criteria の利用方法

• VM の名前やOSをベースにしたグル
ーピングもサポート可能

• 作成済みのメンバーを復数定義する
ことでNest された Object Group を
作成することも可能

• IPアドレスやMacアドレスといった
静的なオブジェクトを含めたいとき
はTXT/CSV ファイルでインポートし
て一括登録することが可能

In phases
NSX Tag Based Dynamic Security Policies
DMZ
PROD NON-PROD
SERVICES
APP-1-VM’s
APP-2-VM’s
WEB
MID
DB WEB
MID
DB
Phase-1: Virtual Security Zones
Dynamic Network Segmentation
Phase-2: APP Level Firewall Policy
Create Fence Around Each of the app
Phase-3: Intra-APP Micro-Seg Policy
More Granular allow-list policy model
Tag を利用した Dynamic Group Objectにより、NSX FW は
新しいアプリケーションがプロビジョニングされたタイミングで
自動的にセキュリティポリシーの強制を実行することが可能に

52
©2021 VMware, Inc.
Best Practice – Applied To field

DFW Applied To
Recommendation:
• セキュリティRule が設定される範囲を限定することは様々な利点に
– メモリ使用量を軽減；
参照されることのない不必要なRuleやAddress Setがインストールされることを回避
– CPU使用率の軽減；
参照されることのないRuleに対する不要なPolicy Lookupを行うCPU負荷を削減
• 仮に Rule が IP/IP Set のような静的な因子で構成されている場合、Applied
To でポリシーを適用させる Segment /Segment-Port を指定しないと環境
によっては問題が発生する場合も
（日本語UIでは“適用先”）
“Applied To” Field（
日本語UIでは“適用
先”）は、DFW展開
時には必ず考慮すべ
き設定パラメータ

ESX/KVM ホストのリソースを最適化
Security Policyを追加する際に、適用す
る範囲を限定することで、既存の環境や
他のテナントやZoneへの影響を回避する
ことが可能
“Applied To” – フィールドの指定により
Ruleごとにセキュリティポリシーを適用させ
る範囲を指定できる
Default では “DFW” となっており、Rule はす
べてのVM ワークロードにインストールされ
てしまう
管理者はDFW Ruleの設定時に特定のGroup
やワークロードを指定することが可能
Overview
DFW Applied To
Applied-To でセキュリティ強制を行う範囲を指定
“Applied-To（適用先）” フィールドをを使うことで
Rule ごとに適用させる範囲を指定することが可能

Applied To - Rule によるセキュリティ強制の範囲限定とリソースの最適化を提供
Source Destination Service Action Applied To
ANY ANY DNS, NTP Allow ALL
GREEN-VMS DB1 MYSQL Allow GREEN-VMS
BLUE-VMS DB2 MYSQL Allow BLUE-VMS
Source Destination Service Action
ANY ANY DNS,NTP Allow
VM1,VM3 DB1 MYSQL Allow
VM
1
VM2 VM3 VM4
1
2
3
3
Source Destination Service Action
ANY ANY DNS,NTP Allow
VM2,VM4 DB2 MySQL Allow
ESX/KVM
ESX/KVM
N-VDS

NSX DFW- Applied-To at Policy Level vs Rule level
DFW Policy レベルでの Applied-To（適
用先）が ”分散ファイアウォール
(default)” だった場合、Rule レベルで
の Applied-To パラメータが参照される
仮に DFW Policy レベルでの Applied-
To（適用先）に Group が指定されてい
た場合、
• Rule Level での Applied-To パラ
メータは無視される
• Policy 内に記載されたすべての
Ruleは、Policy レベルで設定され
た Applied-To（適用先）パラメー
タを参照する
Policy レベルでの 'Applied-To’ には Rule レベルでの 'Applied-To’ よりも高い Priority が与えられている

NSX DFW- Applied-To at Policy Level vs Rule level
Policy レベルでの 'Applied-To’ には Rule レベルでの 'Applied-To’ よりも高い Priority が与えられている
1
2
3
4
左のサンプルUIの場合、
1) 4 rule すべてが、NSXで管理されている
すべてのVMのvNICに適用される
2) 4 rule すべてが、Policy で指定された
Group に関連するVMのvNICに適用される
GROUP -> “PROD-MRS-APP”.
3) Rule ごとに Applied-To で指定した
Group のVMのvNICにRuleが適用される
4) 4 rule すべてが、指定された Group に関
連するVMのvNICに適用され、Ruleごとに設
定されたパラメータは無視される
GROUP -> “PROD-MRS-APP”.
よって、Best Practiceは
Option 2 or 3

DFW Applied To
適用先の設定
Dynamic
Membership Criteria
を利用して作成した
Group（VM,
Segment、Segment-
portの組み合わせ）を
柔軟に指定することが
可能

NSX FW Rules Scale Limit – System, Host vs VNIC
1. NSX System Wide Rule
NSX Manager で各
Zones/Tenanats/Apps などに割り
当てるべく設定されたルールの総数
(左の例では 6.5 K rules)
2. Per VM VNIC rule count
Applied To フィールドのパラメー
タにより実際のvNICに割り当てら
れrたルールの総数
(左の例では、Blue VM’s 1.5K, Green
VM 2.5 K, Purple VM 3.5 K rules)
3. ESX Host Rule Count
VMのvNIC に設定されたruleのホス
トごとの総和
(左の例では、ESX-1 には 15K rule,
ESX-2 は 21K rule)
このようにシステム全体のリソースを最
適化するためにも Applied-To フィール
ドは重要
Rule 数のリミットと Applied-To の関係
Policy ID Number Of Rules In the Policy Applied To
Policy-0 500 ALL
Policy-1 1K BLUE-VM
Policy-2 2K GREEN-VM
Policy-3 3K RED-VM
ESX-1
1.5 K
Rules
1.5 K
Rules
2.5 K
Rules
2.5 K
Rules
3.5 K
Rules
ESX-1 Total Rule Count = 15 K Rules
3.5 K
Rules
Rules/
VNIC
3.5 K
Rules
3.5 K
Rules
3.5 K
Rules
3.5 K
Rules
3.5 K
Rules
ESX-2 Total Rule Count = 21 K Rules
3.5 K
Rules
ESX-2
Rules/
VNIC
NSX System Wide Rules = 6.5K
1
2
3
NSX Supported Max Limit in Config Max as of NSX-T 3.1 document.
System wide Stateful Firewall Rules 100,000
Rules per Virtual NIC 4,000
Rules per Hypervisor Host 120,000

現状設定されているスケール数や意図せず最適化されていないポリシーなどがないか、
チェックするための Scriptを提供
NSX DFW – Get FW Rule Per VM
RUN SCRIPT TO GET VM’S WITH MORE THAN N RULES
RUN SCRIPT TO GET SYSTEM WIDE RULES AND PER VNIC RULES
Github Link to Script Here

61
©2021 VMware, Inc.
Best Practice – Rule Structure and
Ordering

Zone/Tenant間のセキュリティを定める通
信制御と、Tenant/アプリ内のセキュリ
ティを定める通信制御、それぞれに専用の
個別に対応したアーキテクチャを提供
さらにDFWとGFW内でルールを最適化す
る記載を促すための “Category” というコ
ンセプトを提供
Policy Structure
East-West セキュリティとNorth-South セ
キュリティを一つのPaneで管理コントロー
ルできるSecurity の UIを提供
East-West のセキュリティ; DFW
North-South のセキュリティ；GFW
Security UI
East-West セキュリティに対するDFWとNorth−South セキュリティに対するGFW
NSX FW Policy Structure

“カテゴリー”によりファイアウォールは
ルールの処理に優先度を与える事が可能
・カテゴリーは、左から右へ順に処理さ
れる
・カテゴリー内のルールは上から下の順
で処理される
カテゴリーとルールの処理順番
NSX FW Policy Structure
カテゴリー間におけるポリシーの処理順序
カテゴリー内におけるルールの処理順序

Rule Ordering の基本
Recommendation:
• ヒットする確率の高いRuleを上位に配備することにより、新規Flowが発生
した際にDFWがLookup する Rule の数を減らすことが可能になる
（Lookup するポリシー数が増えればそれだけFirewall により内部処理が行
われるための時間が増えることになる）
• その効果は新規Flowのコネクション作成時だけではなく、例えばポリシー
に変更 (rule や group の更新) を加える際に行われる、ホストが保有する
既存セッションに対するポリシー再精査の際にも有効
（既存コネクションに対しての新しいRulesetでの再精査がより早く完結す
るほうが安定稼働の観点としても望ましい）
最もヒットするRuleを上位に配備
最もヒットするRule
を Ruleset における上
位の方に配備すること
がリソース最適化の観
点では有効
”上位の方に" は必ずし
もUI において最上位
に配備するという意味
ではなく、Ruleがイン
ストールされるVIFの
観点で上位に配備され
ることを意識する必要
がある（Group/Tag
と Applied-to のデザ
インを活用）

Rule Ordering
NSX の Gateway Firewall は以下の事前設定された Category ごとに
セキュリティポリシーを策定することが可能となっている:
• Emergency（緊急）
• System （システム）
• Pre-Rules （事前ルール）
• Local Gateway （ローカルゲートウェイ）
• Auto Servcie （自動サービス）
• Default （デフォルト）
Category 内では、Security RuleがSecurity Policy（Section）でグループ化され
ており、Security Policyが上から下へ順に評価される
Security policy が内包している rule もまた記載されている順番に応じて上から下
へとセキュリティ評価が行われる
GFW – Pre-defined Categories
NSX FW では、事
前に設定された
”Category”を利用
することでセキュテ
ィポリシーの策定を
シンプル化
Security
Policy/Ruleは
Categoly 内の上か
ら下へと順に評価さ
れ、Categoly 間は
左から右へと順に評
価される

NSX Gateway Firewall
GFWのPre-defined Category；
Emergency；検疫ソリューション用に利用
System：NSXによって自動的に作成される
Control Plane用ルール（手動による設定変更
は行わないでください）
Shared Pre-Rules：すべてのGateway
Firewallに共通で適用させたいルールを記載
Local Gateway：特定のGatewayに適用させ
たいルールを記載
Auto Service：NSXの機能拡張により自動的
に適応されるルールを記載
Default：Gateway FirewallのDefault
behaviorを定義
GFWにおける主な設定は、一般的にShared
Pre-RulesとLocal Gatewayに実施することで
設定をシンプルにすることができる
eg. Cooperate PolicyをShared Pre-Rule、
Tenant/App Policy をLocal Gaterwayへ
Security Rule Model – Pre-defined Categories
Emergency
System
Shared Pre-Rules
Local Gateway
Auto Service
Default
Used for Quarantine
and/or Allow Rules
System Auto-policy for BFD, VPN contro
plane
Global Policy
- across multiple Gateways
Policy specific to Gateway
Zone/Tenant/Namespace policy
System Auto-policy for other NSX
Services
Default Policy
NSX GFW Pre-defined Categories
Security Rule は Top  Down (Left  Right) の順で精査される

すべてのGatewayに共
通するルールは“すべ
ての共有ルール”から
カテゴリーを指定して
Policy や Ruleを記載

Gateway毎固有のルー
ルは“ゲートウェイ固
有のルール”からPolicy
や Ruleを記載
（便宜上、共有ルール
のPolicyも一緒に表示
される）

Rule Ordering
NSX の Gateway Firewall は以下の事前設定された Category ごとにセキュリ
ティポリシーを策定することが可能となっている:
• Ethernet（イーサネット）
• Emergency（緊急）
• Infrastructure（インフラストラクチャ）
• Environment（環境）
• Application（アプリケーション）
Category 内では、Security RuleがSecurity Policy（Section）でグループ化され
ており、Security Policyが上から下へ順に評価される
Security policy が内包している rule もまた記載されている順番に応じて上から下
へとセキュリティ評価が行われる
DFW – Pre-defined Categories
NSX FW では、事
前に設定され
た”Category”を利
用することでセキュ
ティポリシーの策定
をシンプル化
Security
Policy/Ruleは
Categoly 内の上か
ら下へと順に評価さ
れ、Categoly 間は
左から右へと順に評
価される

Used for L2 Policy
NSX Distributed Firewall
DFWのPre-defined Category；
Ethernet；MacアドレスをベースとしたL2ルー
ルで利用
Emergency；検疫ソリューション用に利用
Infrastructure：Shared サービスに対するアク
セス用途に利用される
eg. AD,DNS,NTP,DHCP, などなど…
Environment：Zone間通信に適用させたいルー
ルを記載
Application：アプリケーションおよびアプリ
ケーションTier,マイクロサービスごとの制御に
資料
DFWでは共通RuleのGlobal、Zone FWとして
のEnvironment、およびアプリケーション内の
マイクロセグメンテーションを提供する
Application Categoryにルールを記載し、E-W
トラフィックを効率的に制御する
Ethernet
Emergency
Infrastructure
Environment
Application
Used for Quarantine
and/or Allow Rules
Global Policy
- AD,DNS,NTP,DHCP, etc…
Policy between Zones/Tenant
Policy between apps, app-tiers or rules
between micro-services
NSX DFW Pre-defined Categories
Security Rule は Top  Down (Left  Right) の順で精査される

Distributed Firewall
は“カテゴリ固有の
ルール”からポリシー
を追加したいカテゴリ
を選択して Policy や
rule を記載

“すべてのルール”を選
択することでDFWに記
載されている
Policy/Rule の一覧を
確認することも可能
（Lookup されるルー
ルの順番が定められた
Categoryの順番に
なっていることに留
意）

73
©2021 VMware, Inc.
• Getting Started.
Exercise ;
NSX Firewall- Virtual Security Zones

サンプルシナリオ
NSX Firewall – Virtual Security Zones
DMZ
PROD NON-PROD
SERVICES

Tag の作成と割り当て – そして Dynamic Group の定義
• Zone に紐付いたワークロードを特定し、Virtual Zone としてグルーピング
NSX Zone Firewall Policy を定義
• Intra & Inter-Zone DFW policy で実現
Zone Profile を利用して NSX Zone IPS/IDS Policy を定義
• ZONE ごとの IPS/IDS profile を作成
• Zone ごとに distributed IDS/IPS policy を定義
シンプルな 3 ステップ
NSX Firewall – Virtual Security Zones
1
2
3

Zone に紐付いたワークロードを特定し、Virtual Zone としてグルーピング
Static
Members
Criteria-Based
IP/MAC
AD Groups
IP/MAC
Addresses/Subnets
Segment
Segment Port
VNIC
Virtual Machine
Group
Segment Port (Tag )
Segment ( Tag )
OS Name
VM Hostname
DMZ
Non-Prod
Prod
G r o u p s T a g s
DMZ PROD
EXTERNAL
Internal
NON-PROD
External/Internal
Segments
1

Example: Define & Assign Tag to “prod” zone workload
1

Example: Create “prod-zone” Group using Tag Criteria
1

Similarly Create Tags and Groups for all the other zones
1

NSX Zone Firewall Policy を定義
Inter-Zone & Intra Zone DFW Policies
2
①で作成した Zone Group を
要して、 Inter-Zone &
Intra-Zone DFW policy を定
義して、Allow / Reject アク
ションを設定
必要に応じて“Jump to
Application” アクションの利
用も検討
“Jump to Application” は
Environment Category によ
るZone 間制御より細かな制
御を提供するために
Application Category へ転送
することができる機能

Define Zone/Target specific IDS/IPS Profiles
3
Application/Zoneの要件に応
じたNSX D-IDS/IPS Profileを
作成
この例では以下2つのProfileを
作成 :
- APP-BACKEND Profile
PROD Zone におけるバッ
クエンドApp Server を保護
するためのプロファイル
- DMZ Profile-
DMZ に配備されたワーク
ロードを保護するためのプ
ロファイル

Define Inter-ZONE IDS/IPS Policies
3
①②で作成したDynamic
Group と Profile を利用して
IDS/IPS ポリシーを作成
この例では以下2つのPolicyを
作成:
- DMZ-to-PROD policy
- External-to-DMZ Policy
各Policy はこのZone ために作
られた専用のIDPS Profile を
参照する形で構成されている
なおかつ Applied to オプショ
ンでこのPolicyが必要なZone
内のワークロードのみに参照さ
せることで効率的にセキュリテ
イを強制

83
©2021 VMware, Inc.
• vRealize Log Insight
• vRealize Network Insight
• NSX Intelligence
Other Security Tools

想定利用シーン；
• 早急にマイクロセグメンテーション
の運用に入りたいプロジェクト
• 豊富な検索機能やフィルタリング機
能を有したLog 管理ツールが必要な
場合
得意分野；
• NSX DFW RuleからのLog情報によ
りアプリケーション間のFlow状況か
ら違反トラフィックの認識まで、リ
アルタイムに近い分析を簡単に実行
可能
スケール；
• 小規模〜中規模のアプリケーション
展開に最適
• NSXのDFWから物理ネットワーク・
FW（ CHKP/PAN FW, Cisco ACI
Underlay ）を含めたアプリケーシ
ョンフローの認識可視化が必要な場
合
得意分野；
• 全体的なネットワークの可視化
– 仮想と物理ネットワークの紐付け
– 多種多数の物理ネットワークデバイス
をサポート
– ネットワーク全体を俯瞰したトラブル
シュート
– アプリケーションフローのモデリング
スケール；
• ~10 million flows per day
• AIによる仮想ネットワークとセキュ
リティとアプリケーションの関連性
対する深い分析が必要な場合
• 分析の結果から必要なセキュリティ
ポリシーを直接NSXにインストール
したい場合
得意分野；
• シンプルなオペレーションで自動的
に必要なFW Policyの推奨を作成し
、その結果を直接NSXのDFWにイン
ストールすることが可能
• マイクロセグメンテーションを迅速
にフィールドへ展開
スケール；
• ~144 million flows per day
（Massive Scale な環境にも対応）
NSX Firewall の運用を補佐する Security Tool 群
“Right tool for the right job”
vRealize Log Insight vRealize Network Insight NSX Intelligence

85
Confidential │ ©2021 VMware, Inc.
vRealize Log Insight

vRealize Log Insight
DFW Rule のロギングを行うため
には、Rule 設定で”ログの記録” を
有効化にする必要がある 
DFW rule のLogは、Hypervisor
内の以下に保存される
• /var/log/dfwpktlogs.log

vRealize Log Insight Contents Pack
異なるベンダー毎の異なるSyslog
Formatを見るべき形で構造化し可
視化を提供
NSX-T のコンテンツパックを投入
することで FWのSyslog運用を可
視化することが可能

Rich logging and Micro-segmentation capabilities
NSX-T Firewall Logging

DFW Action DFW Rule ID
Traffic Direction Destination IP and Port
Source IP and Port
Host

91
vRealize Network Insight

End to End の可視化
DCからSD-WAN、マルチクラウドまで含めた可視化の提供

NSX Policy Manager Dashboard

NSX-T Policies

セキュリティ計画 - ダッシュボード
フロー情報を収集し、
East-West トラ
フィックを分析
• 何が何につながってい
るかを俯瞰的に把握
• アプリケーション、
ネットワーク、VM、な
どの論理的な構成によ
るグループ化
• 各スライスまたはパイ
全体に対する推奨ファ
イアウォールルール
• データの背後にある
ネットワークフローに
ドリルダウンすること
で詳細を確認

Export recommended firewall rules as XML or CSV for VMs

97
NSX Intelligence

NSX Intelligence
NSX Intelligence がアプリケーシ
ョン間の通信フローを自動的に分
析しセキュリティ状態をチェック
NSX のインベントリー情報を過去
に渡って可視化
ワークロードのグルーピングやそ
れに基づいたマイクロセグメンテ
ーションのためのポリシーを自動
生成することが可能
Single Pane of Glass – Part of Existing NSX-T UI

NSX Intelligence
NSX Intelligence がアプリケー
ション間の通信フローを自動的に
分析しセキュリティ状態をチェッ
ク
れに基づいたマイクロセグメン
テーションのためのポリシーを自
動生成することが可能

FW Recommendation
NSX Intelligence
FW許可ルールで許可された通信
FWドロップルールで遮断された通信
FW”暗黙の許可”ルールで許可された通信
各通信が適切に保護されているかをモニタリング

FW Recommendation
NSX Intelligence
過去に遡って実績があり信頼できる通信フローを自動抽出

FW Recommendation
NSX Intelligence
通信実績のあるフローをベースに推奨FWルールを自動作成し、確認の末に発行することが可能

FW Recommendation
NSX Intelligence
各通信が適切に保護されているかを継続的にモニタリング

105
©2021 VMware, Inc.
• Session Timers
• Rule Explosion via Services
• DFW Drafts
• DFW Configuration Import/Export
• Time-base DFW/GWFW policy
• Stateless rule
• DFW Exclusion List
• Migrating/Importing 3rd Party Firewall Configurations
NSX Firewall – Tips.

Firewall Session Timer
Firewall Session timer は、アプリケーション要求に
応じて Firewall の TCP, UDP, ICMP セッションに対す
る取り扱いの挙動を変更させることができる機能
Session timer は以下の3つの要素により構成される :
• Policy Firewall Session Timer Profile
• Nsgroup
• Policy Firewall Session Timer Profile Binding Map

Default Timer の確認と変更
Security > Security
Profiles > Session
Timer
でプロファイルを作
成（新しいProfileを
作成する際に
Default の Timerが
表示される）
右図は、
TCP/Established
Timer を 24 hours
(86400 seconds)
に変更している例

CLI による Default Timer の確認
Vsipioctl gettimeout
–f <filter> により設
定情報を表示
[root@host-192-168-109-153:~] vsipioctl gettimeout -f nic-2619623-eth0-vmware-sfw.2
Connection Timeouts:
dfw.tcp.first_packet : 120
dfw.tcp.opening : 30
dfw.tcp.established : 43200
dfw.tcp.closing : 120
dfw.tcp.fin_wait : 45
dfw.tcp.closed : 20
dfw.udp.first_packet : 60
dfw.udp.single : 30
dfw.udp.multiple : 60
dfw.icmp.first_packet : 20
dfw.icmp.error_reply : 10
dfw.other.first_packet: 60
dfw.other.single : 30
dfw.other.multiple : 60
dfw.ip.frag : 30
dfw.interval : 10
dfw.adaptive_start : 200000
dfw.adaptive_end : 270000
dfw.src_node : 0
dfw.ts_diff : 30
dfw.invalid_state : 600
dfw.invalid_l7 : 600

Rule Explosion via Services
インストールされるRule数の肥大
UIに記載されたRuleは、
ハイパーバイザーにイン
ストールされるRue数と
1:1で紐付けられている
わけではない
特にService 部分での表
記方法はデータプレーン
へのRueインストール時
に大きな影響があるので
注意が必要
この表記方法では、UIでは一つのSecurity Ruleに見えるが、、、

host-192-168-109-151.corp.local> get firewall efa0ce66-895f-498c-8f3c-83aee21b38c0 ruleset rules
Firewall Rules
----------------------------------------------------------------------
VIF UUID : efa0ce66-895f-498c-8f3c-83aee21b38c0
Ruleset UUID : 748f1e3c-aace-43d5-af90-9fcdb5ec45c2
Rule count : 2
rule 1194 inout protocol tcp from any to any port 80 accept;
rule 1194 inout protocol tcp from any to any port 443 accept;
インストールされるRule数の肥大
実際には2行のSecurity Rueとして
データプレーンに書き込みが行われている

Group port を利用して
サービスが必要とする
通信ポートを一つのエ
ントリーとして表現す
ることが可能
• データプレーンにインス
トールするRueの数を削
減
• DFWが利用するメモリ
ー使用量を削減
• Session 構築時に
Lookupするルール数量
を削減
host-192-168-109-151.openstacklocal> get firewall efa0ce66-895f-498c-8f3c-83aee21b38c0 ruleset rules
Firewall Rules
----------------------------------------------------------------------
VIF UUID : efa0ce66-895f-498c-8f3c-83aee21b38c0
Ruleset UUID : 748f1e3c-aace-43d5-af90-9fcdb5ec45c2
Rule count : 1
rule 1194 inout protocol tcp from any to any port {80, 443} accept;
Note: Service entriy は最大15 の Port 数までまとめて表現することが可能、Portレンジでの表現では最大 2 まで
Rule数の肥大を防ぐためのサービス定義方法

DFW Draft
NSX FW の Draft 機能を使うことでDFWに対する設定作成、変更を事前に行って
おきつつ、ワークロードやアプリケーションに対しての適用を任意のタイミングで
行うことを可能とする
多数のDraftを管理することも可能だが、ドラフトは作成されたタイミングのFW
設定を元に構成されているので作成された時間軸を意識しておくことは重要
Draft による Rue の設定変更は保存された複数のDraftの中から選んでLoadする
ことが可能
• こにれにより反映前に確認を行った上で落ち着いてPublishすることが可能に
事前行った設定定義
を保存しておいて、
アプリケーションに
対する適用は任意の
タイミングで実施す
ることが可能に
多数のドラフトを保
存しておくことも可
能

DFW Draft
DFW Draft は（Publishされていない）Firewall 全体
の設定として保存されている
2つのタイプのDraft が存在
• Auto saved
– システムにより自動保存されたもの
• User saved
– ユーザーにより変更、保存されたもの

DFW Draft
DFW Draft として保存できるのは記載されている
Rule/Policy のみ
（Group は参照は行うものの、Group 自体の作成や
変更は DFW Draft では取り扱えないので実環境では
注意が必要）

DFW Draft
Draft は保存される際に作成された時間をマークし、
これにより作成された Draft が過去3ヶ月でどのタイ
ミングのものだったのかを確認することができる
設定Draftと時間軸、履歴の関係性を表示
Draft を確認する際にはRuleに対する、追加、変更、
削除、などの変更点がハイライトされる

DFW Configuration Import/Export
自動 / 手動で Draft に対する
Import/Export をUI もしくは API から提
供可能
Export できるのはすべてのCategoryに記
載されている Rule/Policy のみ
（Group/Context-profile/Service は
Exportできないので注意）
Export した設定は、同一のNSX Manager
でも別のNSX ManagerでもImportするこ
とが可能
Import を行うとDraft を読み込んだのと同
様の状態として取り扱われる
通常のNSX-T Manager のFull Backupとは
別にFirewall Policy のBackup として利用す
ることが可能

Time-base DFW/GWFW policy
日/時間に応じて異なるセキュリティポ
リシーを適用
GFW/DFW 両方で利用することが可能
Use Case
• 営業時間内に特定のアプリケーションへ
のアクセスのみを許可
• メンテナンスウィンドウなどの間、アプ
リケーションへのアクセス制限を強制
• 経理以外のユーザーが、金融データを含
む可能性のあるアプリケーションへのア
クセスを平日夜間と休日は遮断する
ポリシーを指定した時間帯のみ実行させる予約機能
月曜-金曜
7 AM- 7PM (日中)
月曜-金曜
7 PM- 7 AM (夜間/休日)
土曜-日曜
終日
App DB
Finance-App-1
HR-App-1
Web

Time-base DFW/GWFW policy
ポリシー(セクション)レベルで適用
(オプション機能)
ポリシーごとに1つのタイムウィンドウを指定
NSX-T Managerが、タイムウィンドウが設定
されたトランスポートノード(TN)にポリシー
をプッシュ
トランスポートノード側で時間を確認し、2分
ごとにタイムベースのポリシールールを有効
化/無効化の更新を行う
利用に際してはトランスポートノードでNTP
有効化が必須
Implementation
KVM, Bare Metal , NSX Cloudは未対応

Stateless Rules
Firewall の Session State 管理がアプリケーションに対して問題を与えてしまう
場合など、限定的な利用にとどめるべき
Applied To フィールドを利用して、適用が必要な部分にピンポイントで適用させる
ワークロードに適用させる際にはできる限りRule baseの上位に記載を挿入させる
Stateless rule は、
コネクションテーブ
ルにエントリを作成
せず、常にトラフィ
ックの精査を必要と
する
個々のRuleを
Stateless rule とし
て設定することは出
きず、
policy/section 毎に
指定することが必要

DFW Exclusion List
NSX-T DFW は、特定のワークロードをFirewallの影響範囲から完全に除外させ
る事を可能とする機能を搭載
このExclusion Listに指定することでワークロードの通信はFirewallの機能を無
視して通信を行うことが可能になる
この機能は以下のような場合に有用；
• ワークロードがFirewallの影響下では使えない仕様の場合
• ワークロードに緊急アクセスを行いたい場合
• ワークロードに正しいFirewall設定がされてないと思われる場合の切り分け用途
除外リスト
DFW Exclusion
List（除外リスト）
を利用することで
logical-port 単位で
DFWの機能をバイ
パスする設定を行う
ことが可能
Member Types:
• NSGroups
• Logical Ports
• Logical Switches

除外リスト
DFW Exclusion List
host-192-168-109-153.openstacklocal> get firewall exclusion
Firewall Exclusion
----------------------------------------------------------------------
Exclusion count: 1
38512455-5fae-47ca-97f3-3fe2b9373925
nsxmgr-01a> get firewall exclude-list
target_id target_type target_display_name
---------- ------------ --------------------
765555fb-7195-43b8-ae91-9195a22a1912 LogicalSwitch ls-policy-web
f6499630-64fc-4a08-92c3-8b25205681da LogicalPort T1_DB_VM
47fb90b7-8602-48f0-adc4-9d96c01d2fcd NSGroup default.policy-nginx-web-app
NSX Manager
Transport Node
NSX Manager はどのようなタイプのオ
ブジェクトを除外設定しているのか、
を表示することが可能
Transport Node 毎に除外リストを確認
することも可能

DFW Exclusion List
Recommended Practice
• セキュリティの観点からも乱用は控える
– ある種のレガシーアプリケーションで TCP State を一般的なFirewallでは追随で
きない場合、など
– NSX-T は Stateless Policy も提供可能なため、除外リストを適用する前に一考す
ることも場合によっては有効
• ネットワークデバイスの仮想インスタンスなどには有効
– F5 Load Balancers, Virtual Routers, Virtual Firewall (PAN1000 for example)
除外リスト
乱用は控えて、本当
に必要な場合に飲み
利用することを推奨
ネットワークデバイ
スに適用
ワークロードの特徴
をよく理解して利用

Migrating/Importing 3rd Party Firewall Configurations
旧来型 Firewall からのポリシー設定移行
やれること、と
やるべきこと、は異
なるので慎重な検討
が必要
（旧来型Firewallの
オブジェクト/ポリ
シーの書式とその移
行に必要以上にこだ
わることは、NSX
Firewallの運用上の
利点を損なうことが
多いので要注意…）

Migrating/Importing 3rd Party Firewall Configurations
/32 アドレスを Grouping 機能の利用で適切な Virtual Machine/Logical port
として紐付ける (可能な限り)
利用しているネットワークレンジ (i.e. /24) を Grouping 機能の利用で適切な
Segment に紐付ける (可能な限り)
復数の Service port を（できる限り）一つの Service Entry としてまとめる
ルール作成時には必ず APPLIED TO で適用範囲を指定
旧来型 Firewall からのポリシー設定移行
それでもやらなくて
はならない場合、の
ガイダンス…

Restructuring dc f-wbynsx_202106

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Restructuring dc f-wbynsx_202106

Similar to Restructuring dc f-wbynsx_202106 (20)

More from Virtual Cloud Networkers @JPN

More from Virtual Cloud Networkers @JPN (12)

Recently uploaded

Recently uploaded (7)

Restructuring dc f-wbynsx_202106