VMware NSX Security
免責事項: これはコミュニティメンテナンスのオープンソースプロジェクトであり、VMware, Inc. または Broadcom Inc. とは提携、承認、またはスポンサー関係にありません。「VMware」および「NSX」はBroadcomの商標です。ソースコードは github.com/zw008/VMware-NSX-Security でMITライセンスの下で公開されています。
VMware NSX DFW マイクロセグメンテーションとセキュリティ — 分散ファイアウォール、セキュリティグループ、VMタグ、Traceflow、IDPS のための21個のMCPツール。
ドメイン特化型のNSX-T / NSX 4.x Policy API向けセキュリティスキル。 関連スキル: vmware-nsx(ネットワーキング)、vmware-aiops(VMライフサイクル)、vmware-monitor(読み取り専用監視)、vmware-avi(AVI/ALB/AKO)、vmware-harden(コンプライアンスベースライン)。 | vmware-pilot(ワークフローオーケストレーション)| vmware-policy(監査/ポリシー)|
このスキルの機能
| カテゴリ | ツール | 数 |
|---|---|---|
| DFWポリシー | 一覧表示、取得、作成、更新、削除、ルール一覧 | 6 |
| DFWルール | 作成、更新、削除、統計取得 | 4 |
| セキュリティグループ | 一覧表示、取得、作成、削除 | 4 |
| VMタグ | VMタグ一覧、タグ適用、タグ削除 | 3 |
| Traceflow | トレース実行、結果取得 | 2 |
| IDPS | プロファイル一覧、状態取得 | 2 |
合計: 21ツール(10個読み取り専用 + 11個書き込み)
クイックインストール
uv tool install vmware-nsx-security
vmware-nsx-security doctor
このスキルを使用すべきタイミング
- DFWセキュリティポリシーとルールの一覧表示、作成、変更
- VMタグ、IP範囲、またはセグメントメンバーシップに基づくセキュリティグループの作成
- 仮想マシン上のNSXタグの適用または一覧表示
- Traceflowを実行してパケットパスをトレースし、ドロップ理由を診断
- IDPSプロファイル設定、シグネチャステータス、およびグローバルIDS設定の確認
- アプリケーション層間でのゼロトラストマイクロセグメンテーションの実装
関連スキルを使用する場合:
- NSXセグメント、ゲートウェイ、NAT、ルーティング、IPAM →
vmware-nsx - VMライフサイクル、デプロイ、ゲスト操作 →
vmware-aiops - vSphereインベントリ、ヘルス、アラーム、イベント →
vmware-monitor - ストレージ: iSCSI、vSAN、データストア →
vmware-storage - Tanzu Kubernetes →
vmware-vks - ロードバランシング、AVI/ALB、AKO、Ingress →
vmware-avi
関連スキル — スキルルーティング
| ユーザーの意図 | 推奨スキル |
|---|---|
| NSXセキュリティ: DFWルール、セキュリティグループ、IDS/IPS | vmware-nsx-security ← このスキル |
| NSXネットワーキング: セグメント、ゲートウェイ、NAT、ルーティング | vmware-nsx |
| 読み取り専用のvSphere監視、アラーム、イベント | vmware-monitor |
| VMライフサイクル、デプロイ、ゲスト操作 | vmware-aiops |
| ストレージ: iSCSI、vSAN、データストア | vmware-storage |
| Tanzu Kubernetes | vmware-vks |
| 承認を含むマルチステップワークフロー | vmware-pilot |
| コンプライアンスベースライン (CIS / 等保 / PCI-DSS)、ドリフト検出、LLM修復アドバイザー | vmware-harden (uv tool install vmware-harden) |
| ロードバランサー、AVI、ALB、AKO、Ingress | vmware-avi (uv tool install vmware-avi) |
| 監査ログクエリ | vmware-policy (vmware-audit CLI) |
一般的なワークフロー
アプリケーション層のマイクロセグメンテーションを実装する
事前確認(判断 — DFWの変更は全員をロックアウトする可能性があります):
- 最初にデフォルト許可: 新しいポリシーの最初のルールは、管理トラフィック(DNS、NTP、vCenter、SSH(ジャンプホストから))に対してALLOWである必要があります。これがないと、デフォルト拒否を追加した瞬間に自分自身のアクセスが遮断されます。
- タグインベントリ: 保護しようとするVMに実際にタグが付いていることを確認します(
tag list <vm>)。存在しないタグに基づくグループは0台のVMにマッチします — ポリシーは「適用された」ように見えますが、何も強制しません。 - カテゴリの選択: アプリケーション層マイクロセグメンテーションには
Applicationカテゴリ(ルールはインフラストラクチャルールの後で評価されます)。緊急用のEmergencyカテゴリを日常的なルールに使用すると、実際のインシデント対応能力を損なう可能性があります。 - ステートレス?デフォルトはステートフルに — NSX DFWはステートフルであり、ほとんどのルールはステートレスであるべきではありません。ステートレス = 両方向を明示的に許可する必要があります。
- 常に新しいルールで ログ記録を有効 にし、後で確認してから無効にします。サイレントドロップは最悪のバグです。
手順:
- まずVMにタグを付けます(以下のワークフローを参照) — 空のグループ = 強制なし
create_groupMCPツールを使用して、tag_scope/tag_valueでグループを作成します(タグ条件は"scope|tag"、例:tier|webとしてマッチします。複数の条件タイプ(タグ/IP/セグメント)はOR(論理和)で結合され、AND(論理積)ではありません)policy create app-microseg --category Application- ルールを順序通り追加: ALLOW(管理)→ ALLOW(同一層内)→ ALLOW(Web→アプリ、アプリポート上)→ DROP(any-any、ログ記録あり)
- traceflowで確認(以下を参照)デフォルト拒否を有効にする前 に
NSXタグをVMに適用する
判断: タグはグループメンバーシップを駆動し、それがDFWの強制を駆動します。スペルミスのあるタグは、サイレントにVMを保護から除外します。適用後は必ず再一覧表示してください。
tag list my-web-vm-01→ VMの外部IDを記録し、既存のタグも確認します(重複/タイポ衝突を避けるため)tag apply <vm-external-id> --scope tier --value web- 確認:
tag list my-web-vm-01を再度実行 → 新しいタグが存在し、想定外のタグがないことを確認します
Traceflowでパケットをトレースする
判断: traceflowはDFW変更の検証メカニズムです。拒否ルールを有効にする 前 と、ルール変更の 後 毎に実行してください。「UIで正しく見える」を信頼してはいけません。
vmware-nsx troubleshoot vm-segmentを使用してソースVMの論理ポートIDを取得しますtraceflow run <lport-id> --src-ip <src> --dst-ip <dst> --proto TCP --dst-port <port>- DFWヒットチェーンを検査します: どのルールがマッチしたか、ALLOWかDROPか、どのトランスポートノードで発生したか
- よくある失敗: ルールがカテゴリApplicationでマッチしているが、カテゴリEnvironmentの以前のDROPによってシャドウイングされている — トレースを上から下まで読み、最終的な判定だけを見ないでください
DFWポリシーのヒット数を確認する
vmware-nsx-security policy list
vmware-nsx-security rule list <policy-id>
vmware-nsx-security rule stats <policy-id> <rule-id>
マルチターゲット操作
すべてのコマンドは、特定のNSX Managerに対して操作するために --target <name> を受け入れます:
# デフォルトターゲット
vmware-nsx-security policy list
# 特定のターゲット
vmware-nsx-security policy list --target nsx-prod
vmware-nsx-security group list --target nsx-lab
使用モード
| シナリオ | 推奨 | 理由 |
|---|---|---|
| ローカル/小規模モデル (Ollama、Qwen) | CLI | MCPの |
| クラウドモデル (Claude、GPT-4o) | どちらでも | MCPは構造化JSON I/Oを提供 |
| 自動化パイプライン | MCP | 型安全なパラメータ、構造化出力 |
MCPツール (21 — 10読み取り、11書き込み)
すべてのMCPツールはオプションの target パラメータを受け入れます。
| カテゴリ | ツール | タイプ | 説明 |
|---|---|---|---|
| DFWポリシー | list_dfw_policies | 読み取り | カテゴリ、シーケンス、ルール数を含むすべてのDFWセキュリティポリシーを一覧表示 |
get_dfw_policy | 読み取り | ポリシーの詳細を取得: カテゴリ、ステートフル、ロック、スコープ、タグ | |
create_dfw_policy | 書き込み | カテゴリとシーケンス番号を指定して新しいDFWポリシーを作成 | |
update_dfw_policy | 書き込み | 部分更新: display_name、description、sequence_number、stateful | |
delete_dfw_policy | 書き込み | ポリシーを削除 — アクティブなルールが存在する場合は拒否 | |
list_dfw_rules | 読み取り | ポリシー内のルールを一覧表示: アクション、送信元、宛先、サービス | |
| DFWルール | create_dfw_rule | 書き込み | 送信元/宛先/サービス/アクション/スコープを指定してルールを作成 |
update_dfw_rule | 書き込み | ルールフィールドを部分更新 | |
delete_dfw_rule | 書き込み | ポリシーからルールを削除 | |
get_dfw_rule_stats | 読み取り | ルールのパケット/バイト/セッション/ヒット数とpopularity_indexを取得 | |
| セキュリティグループ | list_groups | 読み取り | 式の数を含むすべてのセキュリティグループを一覧表示 |
get_group | 読み取り | グループの詳細を取得: 式の条件 + 最大50の有効なVMメンバー | |
create_group | 書き込み | タグ/IP/セグメントメンバーシップ条件(タグは "scope | |
delete_group | 書き込み | グループを削除 — DFWルール/スコープで参照されている場合、または参照スキャンが失敗した場合は拒否 | |
| VMタグ | list_vm_tags | 読み取り | 表示名でVMのNSXタグを一覧表示 |
apply_vm_tag | 書き込み | VMにスコープ/値のタグを適用(追加的、既存のタグを保持) | |
remove_vm_tag | 書き込み | VMからスコープ/値のタグを削除(他のタグは保持;動的グループメンバーシップが変更される可能性あり) | |
| Traceflow | run_traceflow | 書き込み | プローブパケットを注入;operation_state + ホップバイホップ観測結果(resource_type別)+ dfw_hitsを返す |
get_traceflow_result | 読み取り | 既存のtraceflowのoperation_state/観測結果を確認 | |
| IDPS | list_idps_profiles | 読み取り | 深刻度とフィルタ条件を含むIDPSプロファイルを一覧表示 |
get_idps_status | 読み取り | IDPSシグネチャステータス + グローバルIDS設定(auto_update、syslogエクスポート)を取得 |
CLIクイックリファレンス
# DFWポリシー
vmware-nsx-security policy list [--target <name>]
vmware-nsx-security policy get <policy-id>
vmware-nsx-security policy create <id> --name "表示名" --category Application [--dry-run]
vmware-nsx-security policy delete <id> [--dry-run]
# DFWルール
vmware-nsx-security rule list <policy-id>
vmware-nsx-security rule stats <policy-id> <rule-id>
vmware-nsx-security rule delete <policy-id> <rule-id> [--dry-run]
# セキュリティグループ
vmware-nsx-security group list
vmware-nsx-security group get <group-id>
vmware-nsx-security group delete <group-id> [--dry-run]
# タグ
vmware-nsx-security tag list <vm-display-name>
vmware-nsx-security tag apply <vm-external-id> --scope env --value production [--dry-run]
vmware-nsx-security tag remove <vm-external-id> --scope env --value production [--dry-run]
# Traceflow
vmware-nsx-security traceflow run <lport-id> --src-ip <src-ip> --dst-ip <dst-ip>
# IDPS
vmware-nsx-security idps profiles
vmware-nsx-security idps status
# 診断
vmware-nsx-security doctor [--skip-auth]
トラブルシューティング
「アクティブなルールが存在するため、ポリシーを削除できません」
delete_dfw_policy は削除前にアクティブなルールをチェックします。vmware-nsx-security rule list <policy-id> を使用して、どのルールを先に削除する必要があるかを確認してください。その後、各ルールを個別に削除してから、ポリシーの削除を再試行します。
「DFWルールで参照されているため、グループを削除できません」
delete_group は、ルールのsource_groups、destination_groups、applied-toスコープ、およびポリシーレベルのスコープにおけるグループへの参照をすべてのポリシーでスキャンします。まずそれらの参照からグループを削除し(update_dfw_rule でグループパスを 'ANY' または別のグループに置き換える)、その後再試行します。エラーが参照スキャン自体の失敗を示す場合、削除は予防措置として中止されました — vmware-nsx-security doctor でNSX接続を確認し、再試行してください。
「display_nameに一致する仮想マシンが見つかりません」
list_vm_tags はNSXファブリックAPIを介して表示名でVMを検索します。一般的な原因:
- 表示名の不一致 — NSX Managerの名前がvCenterと異なる場合があります。
vmware-monitor vm listで正確なNSXファブリック表示名を確認してください。 - VMが登録されていない — 新しくデプロイされたVMがNSXファブリックに表示されるまでに時間がかかる場合があります。
- 同じ名前のVMが複数ある — 特定のexternal_idで
apply_vm_tagを使用してください。
Traceflowが空の観測結果を返す
operation_stateがIN_PROGRESSの場合、トレースはまだ完了していません —get_traceflow_result <traceflow-id>で再度ポーリングしてください。src_lport_idが正しい論理ポートアタッチメントUUIDであることを確認してください — セグメントポートパスではありません。vmware-nsx troubleshoot vm-segment <vm>から取得します。- ソースVMは電源がオンで、NSXオーバーレイセグメントに接続されている必要があります。
- VMがVLANバックアップセグメント上にある場合、Traceflowはサポートされません。
- NSX Managerは、ソースVMをホストするトランスポートノードに到達可能である必要があります。
vmware-nsx health transport-nodesを確認してください。
DFWルールの統計がゼロヒットを示す
新しく作成されたルールは、トラフィックがマッチするまでヒット数はゼロです。予想されるトラフィックでもゼロのままの場合:
- ルールが無効になっていないことを確認します(
list_dfw_rulesの出力でdisabled: false)。 get_groupを使用して、送信元/宛先グループのメンバーシップが正しいことを確認します。- ルールのシーケンス番号を確認します — シーケンス番号が低いALLOW/DROPルールが先にマッチしている可能性があります。
「パスワードが見つかりません」エラー
パスワード変数の命名規則: VMWARE_NSX_SECURITY_<TARGET_UPPER>_PASSWORD
ハイフンはアンダースコアに置き換えられます。ターゲット nsx-prod の場合:
VMWARE_NSX_SECURITY_NSX_PROD_PASSWORD。~/.vmware-nsx-security/.env を確認してください。
invalid peer certificate: UnknownIssuer (uvx)
企業TLSプロキシがuvのバンドル証明書ストアによって信頼されていません。v1.5.15以降の単一コマンド形式 vmware-nsx-security mcp(PyPIの再解決なし)を使用するか、export UV_NATIVE_TLS=true を設定してuvがシステム証明書ストアを使用するようにしてください。
安全性
- 監査ログ記録: すべての書き込み操作は、タイムスタンプ、ユーザー、ターゲット、操作、パラメータ、結果とともに
~/.vmware/audit.db(SQLite WAL、vmware-policy経由)にログ記録されます。 - 依存関係チェック:
delete_dfw_policyはアクティブなルールをチェックし、delete_groupはDFWルール参照をチェックします — 不注意によるカスケード障害を防ぎます。 - 入力検証: すべてのIDは安全な文字セット(英数字、ハイフン、アンダースコア、ドット)に対して検証され、すべてのテキストフィールドは制御文字を除去するようにサニタイズされます。
- ドライランモード: CLI書き込みコマンドは
--dry-runをサポートし、実行せずにAPI呼び出しをプレビューします。 - 二重確認: CLIの破壊的操作(削除)には、2つの別々の確認プロンプトが必要です。
- 認証情報の安全性: パスワードは環境変数(
.envファイル)からのみロードされ、config.yamlからは決してロードされません。 - ネットワーキング変更不可: セグメント、ゲートウェイ、NAT、またはルーティングは変更できません — その範囲は
vmware-nsxに属します。 - プロンプトインジェクション防御: すべてのAPIソース文字列は、ツール出力に含める前に
_sanitize()を通過します。
セットアップ
uv tool in
…
[後続部分は翻訳のため省略]