3行まとめ：vDefend BlueprintsはSSP、管理ドメイン、ワークロードドメインの順に読む
SSP for VCFを共通基盤として確認し、ID、ロール、管理境界、ライセンスの前提をそろえます。
管理コンポーネントと管理系通信を先に棚卸しし、通常のアプリケーション通信と分けて扱います。
DFW 1-2-3-4、VPCセキュリティプロファイル、委任範囲を成果物ベースで確認します。
個別機能の採用判断に入る前に、どのブループリントで何を決めるかを分けると設計レビューが進めやすくなります。
- VMware Security Blogは2026年6月1日、VCF 9.1の設計ドキュメントに「Lateral Security with vDefend」ブループリントが入ったことを告知しました。これは、vDefendを個別機能ではなくVCFの設計単位で読む入口になります。
- まずSecurity Services Platform for VCFを共通基盤として確認し、次にManagement Domain Security、最後にWorkload Domain SecurityとDFW 1-2-3-4へ進むと、管理面とアプリケーション面を混同しにくくなります。
- vDefend 9.1のSelf-Service Lateral Security、VM/VKS向け統合IDS/IPS、IDPS Turbo Mode、Distributed Firewall拡張は便利な見出しですが、ライセンス、対応バージョン、検査対象、委任範囲を公式資料で確認してから設計に入るべきです。
VCF 9.1でvDefendを調べると、ゼロトラスト、横方向防御、IDPS Turbo Mode、VPCセキュリティプロファイル、VKS保護など、似た重さに見えるキーワードが一度に出てきます。ここで最初からDFWルールの作り方へ進むと、管理ドメインを守る話、テナントへ委任する話、ワークロード通信を段階的に絞る話が混ざります。
この記事では、2026年6月16日JST時点で確認できるVMware Security BlogとBroadcom TechDocsをもとに、VCF 9.1で「Lateral Security with vDefend Blueprints」を読む順番を整理します。作業手順書の代替ではありません。実作業では、必ず自社の構成、契約、サポート条件、最新のTechDocs、Broadcomサポート情報を確認してください。
Broadcom Watch JapanはBroadcomおよび関係会社とは非提携です。この記事は製品・サービス情報の整理であり、投資助言、購買推奨、個別環境への導入指示ではありません。
VCF 9.1でvDefendの読み方は何が変わったか
Lateral Security with vDefend BlueprintsがVCF 9.1の設計ドキュメントに入ったことを入口として確認します。
個別機能の説明ではなく、VCF全体の設計単位としてvDefendを読み直します。
SSP、Management Domain Security、Workload Domain Securityを、それぞれ別のレビュー対象として扱います。
3つを同時に読もうとすると、共通基盤、管理面、ワークロード面の判断が混ざりやすくなります。
2026年6月1日のVMware Security Blogは、「Lateral Security for VMware Cloud Foundation with VMware vDefend」が、VCF 9.1の設計ドキュメントに「Lateral Security with vDefend」ブループリントとして統合されたと説明しています。ここで重要なのは、vDefendが単独製品の機能一覧だけではなく、VCF private cloudの設計ブループリントとして読める形になったことです。
この変更は、自動的にすべてのVCF 9.1環境で横方向防御が有効になる、という意味ではありません。設計文書の入口が整理され、SSP、管理ドメイン、ワークロードドメインという単位で確認しやすくなった、という読み方が安全です。
設計ドキュメントに統合された意味
vDefendの横方向防御は、単に「東西トラフィックを見る」だけではありません。VCFの管理コンポーネント、アプリケーションワークロード、VKSクラスタ、テナント単位の委任、IDPSの検査性能が関係します。そのため、設計レビューでは製品名より先に、どの領域を守る設計なのかを切り分ける必要があります。
公式ブログが示す3つのブループリントは、次のように役割が分かれます。
| ブループリント | 最初に見る理由 | 読者が確認すべきこと |
|---|---|---|
| Security Services Platform for VCF | vDefendの共通基盤と管理境界を置くため | SSPの構成、管理面、ライセンス、関連サービス |
| Management Domain Security | VCFを支える管理コンポーネントを守るため | vCenter、NSX、SDDC Manager、VCF Operationsなどの依存関係 |
| Workload Domain Security | アプリケーション通信を段階的に守るため | DFW 1-2-3-4、VPC、セキュリティプロファイル、例外設計 |
根拠
2026年6月1日のVMware Security Blogは、Lateral Security with vDefend Blueprintsが、VMware vDefend security solutionsを使ってVCF platformへ統一的なenterprise-grade security servicesを提供するための設計要素を説明するとしています。また、SSP for VCF、Management Domain Security、Workload Domain Securityの3つを挙げています。
注意点
ブループリントは「設計のテンプレート」です。自社環境の構成、既存のNSX設計、ライセンス、サポート条件、運用ロールに合わせて読み替える必要があります。特に管理ドメインの通信は、一般的なアプリケーション通信と同じ強さでいきなり遮断候補にしないほうがよい領域です。
3つを同時に読まない
設計レビューでまず決めたいのは、「今回はどのブループリントをレビュー対象にするか」です。SSPを未確認のままDFWルールに入ると、後からライセンス、管理境界、ロール、監査方法の話が戻ってきます。管理ドメイン保護を飛ばしてワークロードだけを見ると、VCF基盤を支える管理コンポーネントの通信が後回しになります。
読み方としては、次の順番が扱いやすいです。
- SSPで、vDefendの共通基盤、管理面、ライセンス、関連サービスを確認する。
- Management Domain Securityで、管理系コンポーネントの通信と保護方針を棚卸しする。
- Workload Domain Securityで、アプリケーション側のDFW 1-2-3-4と段階適用を設計する。
- VM/VKS、IDPS Turbo Mode、Application Identificationなどの9.1機能を、必要な設計項目へ割り当てる。
まずSSPで共通基盤と委任範囲を確認する
- 1VCF基盤
VCF 9.1、NSX、vDefend、SSPの対応関係とサポート範囲を確認します。
- 2IDとロール
中央管理者、運用担当者、テナント側の操作範囲を分けて整理します。
- 3管理境界
中央ポリシー、委任されたDFW設定、VPCセキュリティプロファイルの境界を確認します。
- 4ライセンス確認
使いたい機能が契約、バージョン、サポート条件の範囲に収まるかを確認します。
- 5ブループリント選択
管理ドメインを先に見るか、ワークロードドメインへ進むかをレビュー対象に合わせて決めます。
SSPはインストール手順だけでなく、後続の横方向防御設計に共通する前提条件として扱います。
Security Services Platform for VCFは、vDefendを導入するうえでの共通基盤として読みます。ここを「インストール手順の話」としてだけ見ると、後続の管理ドメイン保護やワークロード保護で、誰が何を管理するのかが曖昧になります。
SSPの確認で見るべきポイントは、vDefendのどのサービスを使うのか、どの管理面で操作するのか、どのドメインに関係するのか、どのロールが運用するのか、ライセンスやサポート条件がどう関係するのかです。
SSPを最初に見る理由
vDefend 9.1の話題では、Distributed Firewall、IDS/IPS、VPCセキュリティプロファイル、VKS保護、IDPS Turbo Modeが目立ちます。ただし、これらは独立して採用判断するより、どの共通基盤の上で管理されるかを先にそろえたほうが、後の変更管理が楽になります。
たとえば、セキュリティチームが中央で定義するガードレールと、テナント管理者がセルフサービスで選ぶ範囲を分けないまま設計すると、運用開始後に「このDFW設定は誰が変更できるのか」「監査ログは誰が見るのか」「テナント側の例外申請はどこに出すのか」が残ります。
確認項目
- SSPが関係するvDefendサービスと管理面
- VCF 9.1側のコンポーネント、ドメイン、ネットワーク境界
- VCF Automationを使う場合のテナント管理者と中央管理者の役割
- vDefend 9.1 Release Notesで示される新機能、既知の問題、サポート条件
- License Hubや関連ライセンスの扱い
注意点
「vDefend 9.1に機能がある」ことと「自社環境でそのまま使える」ことは別です。エディション、SKU、追加サービス、対応バージョン、既存NSX構成、VCF Automationの利用有無によって、設計に入れるべき範囲は変わります。
中央管理とセルフサービスの境界を決める
2026年5月5日のVMware Security Blogは、vDefend 9.1の新機能としてSelf-Service Lateral Security with VCF Automationを挙げています。説明では、インフラチームやセキュリティチームがpredefined VPC security profilesやdelegated DFW settingsなどのガードレールを用意し、tenant adminsがオンデマンドでセキュリティ機能へアクセスできる流れが示されています。
ここで重要なのは、セルフサービス化を「テナントが自由に全DFWルールを編集できる」と読まないことです。中央側が定義する標準、テナントが選べる範囲、システム定義のポリシー、ユーザー定義ポリシーの優先順位を分けて設計する必要があります。
| 項目 | 中央側で決めること | テナント側で扱うこと |
|---|---|---|
| ガードレール | 標準セキュリティプロファイル、監査対象、例外申請の流れ | 利用するプロファイルや許可範囲の選択 |
| DFW設定 | 基本方針、優先順位、変更承認 | 委任された範囲での設定 |
| 監査 | ログ確認、逸脱検知、定期レビュー | 変更理由、アプリケーション側の影響説明 |
| 例外 | 期限、理由、戻し条件 | 一時許可の申請、検証結果の共有 |
評価基準
設計レビューでは、テナント側が選べる範囲、変更できない範囲、中央側が監査する範囲を1枚の表にできるかを確認します。この表が作れない場合、セルフサービス化より先にロールと承認フローを整理したほうがよいです。
ライセンスとサポート範囲を後回しにしない
vDefend 9.1 Release Notesは、Turbo Mode IDPS、Exempt action、VKS node support、Self-Service delegation、RBAC-labeled Security Profiles、License Hubなどを扱っています。これらは機能名だけを見ると一気に使いたくなりますが、実際の導入判断では、サポート対象、前提バージョン、ライセンス、既知の問題を先に確認します。
確認項目
- vDefend 9.1 Release Notesの新機能と既知の問題
- License HubやLicense Serverまわりの条件
- VCF 9.1、NSX、ESXi、VCF Automationとの対応関係
- 既存運用で使っている監査、SIEM、変更管理との接続
注意点
ライセンスや対応範囲が未確認のまま、DFW 1-2-3-4やIDPS Turbo Modeを導入計画に入れると、後から設計が戻ります。とくにセキュリティ機能は、使えるかどうかだけでなく、監査証跡や例外運用までセットで確認したほうが安全です。
管理ドメイン保護はワークロード保護より先に棚卸しする
管理ドメインはワークロード保護の前提になるため、通信の依存関係を把握してからポリシー化へ進みます。
横方向防御という言葉は、アプリケーション間通信やランサムウェア対策の文脈で語られがちです。ただ、VCFでは管理ドメインの通信も重要です。管理系コンポーネントが見えないままワークロード側だけを絞ると、運用に必要な通信、証明書、ログ、バックアップ、アップグレード作業の影響を見落とします。
Management Domain Securityは、VCFを支える管理コンポーネントを守るためのブループリントとして読みます。ここでは「遮断する通信」を先に探すのではなく、「守るべき管理面と依存関係」を先に見ます。
管理コンポーネントを先に守る理由
管理ドメインには、vCenter、NSX Manager、SDDC Manager、VCF Operations、ログ、ライセンス、バックアップなど、VCF全体を支える要素があります。これらの通信をアプリケーション通信と同じ感覚で扱うと、保護より先に運用断を起こす可能性があります。
たとえば、vCenterやNSXの管理通信、SDDC Managerのライフサイクル管理、VCF Operationsの監視データ、ログ転送などは、セキュリティポリシーを強める前に依存関係を可視化すべき対象です。管理系VMのリソースや状態確認については、既存記事の「VCF Operationsで管理VMのリソース割り当てを確認する」も合わせて見ると、保護前の棚卸しに使いやすくなります。
根拠
2026年6月1日のVMware Security Blogは、Management Domain Securityを、VCFを支えるcritical management componentsを保護し、セキュリティ面で堅牢なprivate cloud環境の基礎を作るためのガイドラインとして説明しています。
注意点
管理ドメインでは、最初から強い遮断をゴールにしないほうがよいです。可視化、依存関係の確認、例外の説明、段階適用、ロールバック条件の順に進めます。
通信の棚卸しからポリシー化へ進む
管理ドメインで最初に作るべき成果物は、DFWルールではなく通信棚卸しです。どの管理コンポーネントが、どの相手と、どの目的で通信しているかを並べます。そのうえで、ログ、監査、例外、変更承認を設計します。
| 対象 | 守りたい通信 | ポリシー化前の確認 |
|---|---|---|
| vCenter | 管理操作、証明書、アップグレード関連通信 | 管理者操作、バックアップ、監視、拡張機能の依存関係 |
| NSX Manager | ネットワーク制御、DFW、Edge関連通信 | 管理プレーンとデータプレーンの影響範囲 |
| SDDC Manager | ライフサイクル管理、アップグレード、バンドル取得 | メンテナンス窓と失敗時の戻し条件 |
| VCF Operations | 監視、メトリクス、ログ、アラート | 監視断を起こさない例外設計 |
| ライセンス/ログ基盤 | ライセンス確認、監査ログ、証跡 | 接続方式、保存期間、監査責任 |
評価基準
設計レビューでは、管理通信の可視化結果、例外の理由、変更時の影響確認、ロールバック方針を説明できるかを見ます。説明できない通信が多い場合は、ポリシー作成よりも観測期間を延ばす判断が現実的です。
管理ドメインで先に決める運用ルール
管理ドメイン保護では、誰が変更を承認するのか、メンテナンス時にどの通信を一時許可するのか、監査ログをどこで確認するのかを先に決めます。特にVCF 9.1のアップグレードや管理サービス変更と並行する場合、セキュリティポリシー変更が障害切り分けを難しくすることがあります。
VCF 9.1全体の導入順序や管理サービスIPの確認は、「VCF 9.1を導入前に確認する」のような導入観点の記事と合わせると、セキュリティ設計だけが先行しすぎるのを防げます。
確認項目
- 変更承認者と緊急変更の扱い
- メンテナンス時の一時許可と期限
- 監査ログの保管場所と確認頻度
- 失敗時に戻す設定と戻せない設定
- vCenter、NSX、SDDC Manager、VCF Operationsの依存関係
ワークロードドメインはDFW 1-2-3-4を成果物で管理する
- 観測
どのワークロードがどの通信をしているかを確認し、通信棚卸しと依存関係一覧を作ります。
- グルーピング
アプリケーション、環境、所有者などの単位で保護対象を分け、管理しやすいグループにします。
- ポリシー候補
許可すべき通信、例外通信、中央ポリシーとの関係を整理し、DFWルール案を作ります。
- 段階適用
適用範囲、監視期間、影響確認、戻し条件を決めてから制御を強めます。
VPCセキュリティプロファイルやDFW委任は、中央ポリシーとの優先順位とあわせて確認します。
Workload Domain Securityは、アプリケーション側のゼロトラスト横方向防御を進めるためのブループリントとして読みます。公式ブログは、Workload Domain SecurityがvDefend DFW 1-2-3-4の段階的なprescriptive workflowを使うと説明しています。
ここで大切なのは、DFW 1-2-3-4を手順名として覚えることではありません。各段階で何を観測し、何を成果物として残し、どの条件を満たしたら次へ進むかを決めることです。
DFW 1-2-3-4を手順名で終わらせない
マイクロセグメンテーションは、最初から完成形の遮断ルールを作る作業ではありません。現状の通信を見て、アプリケーション単位や環境単位に分け、許可すべき通信と例外を確認し、段階的に適用します。
| 段階 | 主な問い | 成果物 |
|---|---|---|
| 観測 | どのワークロードが、どの通信をしているか | 通信棚卸し、依存関係一覧 |
| グルーピング | どの単位で保護対象を分けるか | アプリ/環境/所有者ごとのグループ |
| ポリシー候補 | 何を許可し、何を例外にするか | DFWルール案、例外リスト |
| 段階適用 | いつ、どこまで、どう戻すか | 適用計画、監視期間、戻し条件 |
根拠
2026年6月1日のVMware Security Blogは、Workload Domain Securityを、VCF workload domain内のアプリケーションでZero Trust lateral security modelを満たすために、vDefend DFW 1-2-3-4の段階的なワークフローを利用するブループリントとして説明しています。
注意点
公式のDFW 1-2-3-4セルフデプロイガイドやTechDocsを確認し、各ステージの表記、入力、成果物、戻り条件は最新の公式表記に合わせてください。この記事の表は、設計レビューでの読み替え方を示すもので、公式手順の置き換えではありません。
VPC、セキュリティプロファイル、DFW委任を同じ表で見る
vDefend 9.1では、VCF Automationと組み合わせたSelf-Service Lateral Securityが強調されています。VPC Simplified Security、セキュリティプロファイル、委任されたDFW設定は、アプリケーションチームやテナント管理者の使い勝手に関係します。
ただし、セルフサービス化は「セキュリティ責任をテナントへ丸投げする」ことではありません。中央側がどこまで標準化し、どこから先をテナントへ委任するかを明示する必要があります。VPCやネットワーク範囲の設計は、「VCF 9.1のVPC Network Spanを導入前に確認する」の観点ともつながります。
確認項目
- VPCセキュリティプロファイルの種類と適用単位
- テナント管理者が選べる設定
- 中央側が固定するポリシーと監査項目
- ユーザー定義ポリシーとシステム定義ポリシーの優先順位
- 例外通信の期限と戻し条件
注意点
テナント側がセルフサービスで選べる範囲を、全DFWルールの自由な編集と誤解させないことが重要です。システム定義ルール、優先順位、変更不可の範囲は公式資料に合わせて確認してください。
適用前に戻り条件を決める
DFWの段階適用では、許可リストや例外リストと同じくらい、戻り条件が重要です。想定外の通信断が起きたとき、どのルールを戻すのか、誰が判断するのか、どのログで確認するのかを決めておきます。
評価基準
- 観測期間を確保しているか
- 重要業務の例外通信を説明できるか
- 変更対象と影響範囲が一致しているか
- ログ、アラート、利用者影響の確認担当が決まっているか
- 戻す設定と戻せない設定を分けているか
下振れ要因
通信可視化が不足している、アプリケーション所有者が不明、例外通信に期限がない、監査ログの保存先が未確定。この状態で遮断フェーズへ進むと、セキュリティ強化より運用障害のほうが目立ちやすくなります。
VMとVKSは同じ保護方針で見て、確認単位は分ける
VMとVKSを同じ保護モデルで見ても、確認する粒度と運用責任は同じとは限りません。
2026年5月5日のVMware Security Blogは、vDefend 9.1の新機能としてUnified Lateral Threat Prevention for VMs and VKS Workloadsを挙げています。説明では、VKSクラスタを、VMを保護する高性能distributed IDS/IPSと同じ仕組みで検査・保護できる方向性が示されています。
これは、VMとKubernetesを別々のセキュリティ運用に分断しないために重要です。一方で、確認単位まで同じになるわけではありません。VM、クラスタ、Pod、CNI、VPC/VDS、ロードバランサー、管理者ロールは分けて確認します。
VMとVKSを同じ記事で扱う理由
AIやモダンアプリケーションの運用では、VM上の既存アプリケーションとKubernetes上の新しいワークロードが同じVCF基盤で動くことがあります。このとき、VM側だけにIDS/IPSやDFWを入れても、Kubernetes側の東西通信が別管理になると、攻撃経路や監査範囲が分断されます。
vDefend 9.1の説明は、VM、VKS、bare-metal workloadsをまたいだ一貫したlateral threat preventionを目指すものとして読めます。ただし、設計上は対象ごとに確認項目を分けます。
| 対象 | 確認単位 | 見落としやすい点 |
|---|---|---|
| VM | VM、アプリ、ポート、タグ | 既存アプリの暗黙通信、バックアップ、監視 |
| VKS | クラスタ、Namespace、Pod、CNI | Pod間通信、CNI連携、運用者の責任範囲 |
| VPC/VDS | ネットワーク範囲、セグメント、ルーティング | テナント境界、Network Span、例外経路 |
| IDS/IPS | 検査対象、シグネチャ、除外、ログ | 高流量通信、誤検知、性能影響 |
根拠
VMware Security Blogは、VKSクラスタがVMを保護するdistributed IDS/IPSと同じ仕組みで検査・保護でき、セキュリティチームがone console、one policy model、consistent lateral threat preventionを得られると説明しています。また、VKS workloadへの保護はCNI integrationにも触れています。
注意点
「同じコンソール」「同じポリシーモデル」という説明を、すべての確認作業が同じ粒度で済む意味にしないことが大切です。VKSでは、Pod、Namespace、CNI、Ingress/LB、VPC/VDSの設計が絡みます。VKSの基礎設計は「VKS on VCF 9.1を設計前に確認する」や「VCF 9.1のVKSマルチネットワーク対応を導入前に確認する」と合わせて確認すると読みやすくなります。
VKS保護はCNI、Pod、ネットワーク設計と一緒に確認する
VKS保護を検討するときは、セキュリティ機能だけを見ないほうがよいです。クラスタ設計、VPC/VDS、Antrea、ロードバランサー、Podレベルの検査、ログの取り方が関係します。
確認項目
- VKSクラスタのネットワーク設計
- CNI連携の前提
- Podレベル検査の対象と除外
- VMとVKSをまたぐ通信
- テナント管理者と中央管理者の責任分界
- 検査ログ、アラート、SIEM連携
セルフサービス化しても監査責任は残る
Self-Service Lateral Securityは、アプリケーションチームの待ち時間を減らす可能性があります。ただし、セルフサービス化しても中央側の監査責任は残ります。テナントが選んだ設定、例外、変更理由、利用期間を中央側が追えるようにします。
評価基準
テナントが選べるプロファイル、中央が固定するルール、例外申請の期限、監査ログの確認者を分けて説明できるか。ここが曖昧な場合、セルフサービス化は導入効果より運用混乱を増やします。
IDPS Turbo ModeとDFW拡張は性能値だけで判断しない
公式情報ではホストあたり最大9Gbps、VCFドメインあたり最大9Tbpsの脅威防御スループットが示されています。
対応ホスト、ESXi、NSX、vDefendのバージョン、検査対象、トラフィックプロファイルを確認します。
ログ、アラーム、除外設計、障害時の影響範囲を、採用判断と同じタイミングで決めます。
L7可視化とIDベース制御は、目的、適用対象、既存運用への影響を分けて確認します。
公式値は設計判断の入口であり、実環境の保証値として扱う前に条件確認が必要です。
vDefend 9.1の発表で目立つのが、IDPS Turbo Modeです。VMware Security Blogは、IDPS Turbo Modeがホストあたり3Gbpsから9Gbps、VCFドメインあたり最大9Tbpsへ脅威防御スループットを高めると説明しています。TechDocsのTurbo Mode Distributed IDS/IPSページも、トラフィックプロファイルに依存しつつ、ホストあたり最大9GbpsのDistributed IDS/IPS throughputに触れています。
これは大きな更新ですが、設計判断では性能値だけを見ないほうがよいです。対応ホスト、ESXi/NSX/vDefendの前提、検査対象、除外設計、ログ、アラーム、障害時の影響を確認します。
IDPS Turbo Modeで確認する性能と前提条件
Turbo Modeは、高性能なAI/HPC系ワークロードや大量通信を扱う環境では魅力的です。ただし、公式値はすべての環境で保証される実測値ではありません。トラフィックプロファイル、ホスト構成、検査対象、リソース予約、既存運用の監視方法に左右されます。
| 確認項目 | 見る理由 |
|---|---|
| 対応ESXi/NSX/vDefendバージョン | 有効化条件とサポート範囲を確認するため |
| 検査対象トラフィック | どの通信を深く検査するか決めるため |
| Exempt action | バックアップや信頼済み高流量通信をどう扱うか決めるため |
| CPU/メモリ予約 | IDPS用リソースとワークロード影響を分けるため |
| ログ/アラート | 検知と誤検知の運用を回すため |
根拠
VMware Security Blogは、IDPS Turbo Modeが3x throughput、9Gbps per host、up to 9Tbps per VCF domainを実現すると説明しています。vDefend 9.1 Release Notesは、Turbo Mode IDPS、Exempt action、VKS node support、signature management workflowsなどを9.1の更新点として挙げています。
注意点
性能値を自社環境の保証値として書き換えないことが大切です。採用判断では、事前検証のトラフィックプロファイル、ピーク時通信、バックアップ通信、誤検知時の対応、監視担当を合わせて確認します。高性能ネットワークと検査性能を合わせて見る場合は、「VCF 9.xのEnhanced Data Pathを導入前に確認する」のようなネットワーク性能観点も参考になります。
除外設計と監視をセットにする
vDefend 9.1では、Distributed IDS/IPS rulesでExempt actionを使えることがRelease Notesで示されています。これは、信頼済みトラフィックや高流量通信をどう扱うかという設計に直結します。
確認項目
- どの通信を検査対象にするか
- どの通信を除外候補にするか
- 除外の理由、期限、再評価日
- 誤検知時の連絡先
- 検査性能が落ちた場合のアラート
- バックアップ、レプリケーション、大量データ移動の扱い
評価基準
「有効化できるか」ではなく、「通常時と障害時に運用できるか」で判断します。除外設計がないIDPSは、性能問題や誤検知が出たときに一括無効化されやすくなります。
DFW拡張はL7可視化とIDベース制御に分ける
VMware Security Blogは、Distributed Firewallの拡張としてApplication Identificationの増加と、フェデレーション環境でのidentity-based firewalling対応を挙げています。説明では、Application Identificationは5x increase、約4,000の新しいApplication IDsを追加するとされています。
これはL7可視化とルール作成の助けになりますが、すべての通信が自動的に正しく分類されるという意味ではありません。未知アプリ、独自プロトコル、暗号化通信、例外通信、誤分類時の扱いを確認します。
注意点
アプリケーションIDを使うルールは、ポート/プロトコルより読みやすくなる一方、分類できない通信や誤分類への備えが必要です。IDベース制御も、IDソース、同期、フェデレーション範囲、障害時の挙動を確認してから設計に入ります。
導入前チェックリストとして読み終える
未確認の条件は採用可否として断定せず、設計レビューの残タスクとして明示します。
vDefend Lateral Security Blueprintsを読む目的は、機能名を覚えることではありません。設計レビューで、どの公式ページを見て、どの担当者に確認し、どの成果物を残すかを決めることです。
設計レビューの順番
- SSP for VCFで、共通基盤、ライセンス、管理面、関連サービスを確認する。
- Management Domain Securityで、管理コンポーネントと通信依存関係を棚卸しする。
- Workload Domain Securityで、DFW 1-2-3-4の段階と成果物を決める。
- VCF Automationを使う場合、VPCセキュリティプロファイルとDFW委任範囲を明確にする。
- VMとVKSの保護方針を合わせ、確認単位はVM、クラスタ、Pod、ネットワークで分ける。
- IDPS Turbo Modeは、性能値、対応条件、除外設計、監視、障害時対応をセットで判断する。
- Release Notes、TechDocs、既知の問題、サポート条件を公開前と導入前に再確認する。
この順番で読むと、セキュリティ機能の名称を追うだけではなく、社内レビューで誰が何を判断するのかまで落とし込みやすくなります。
確認項目
- 最新のvDefend 9.1 Release Notesを読んだか
- Design Blueprints for VCF 9.1の該当ページを確認したか
- Lateral Security with vDefend Blueprintsの3分野を分けたか
- 管理ドメインの依存関係を可視化したか
- DFW 1-2-3-4の成果物と戻り条件を決めたか
- VM/VKSの検査単位を分けたか
- Turbo Modeの前提と除外設計を確認したか
- ライセンス、サポート、既知の問題を確認したか
未確認として残すべきこと
この記事では、個別環境のライセンス可否、SKU、エディション、既存NSX構成での対応範囲、具体的なDFWルール、実測性能、運用ログの保存設計までは断定しません。これらは、Broadcomの最新TechDocs、サポート、契約情報、自社検証で確認すべき項目です。
更新履歴・運用メモ
- 2026年6月16日JST: VMware Security Blog、Broadcom TechDocs、vDefend 9.1 Release Notes、Turbo Mode Distributed IDS/IPS TechDocsを確認して初版作成。
- 需要シグナル: 2026年6月1日のvDefend Blueprints告知、2026年5月5日のvDefend 9.1新機能ブログ、Broadcom Community上のvDefend 9.1関連案内を確認。コミュニティやウェビナー情報は読者需要の確認に使い、製品仕様の根拠は公式ブログとTechDocsへ寄せました。
VCF 9.1、vDefend、Broadcomの製品更新を継続して追う場合は、2026年6月 重要トピックまとめと資料・確認ログも合わせて確認してください。ニュースレターでは、公式発表、製品ページ、TechDocs更新、噂確認の更新通知を控えめにまとめています。
次に読むなら
参照した主な情報源
確認日: 2026年6月16日 JST
- VMware Security Blog, Introducing VMware vDefend Lateral Security Design Blueprints for VCF 9.1
https://blogs.vmware.com/security/2026/06/vdefend-design-blueprints-vcf-9-1.html
- VMware Security Blog, VMware vDefend for VCF 9.1: Zero Trust Lateral Security for the AI Era
https://blogs.vmware.com/security/2026/05/vdefend-vcf-9-1-zero-trust.html
- Broadcom TechDocs, Design Blueprints for VMware Cloud Foundation
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-blueprints-for.html
- Broadcom TechDocs, Lateral Security with vDefend Blueprints
https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/design-library-for-vdefend/index/lateral-security-for-vmware-cloud-foundation-with-vmware-vdefend.html
- Broadcom TechDocs, VMware vDefend 9.1 Release Notes
https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/vdefend-firewall/9-1/release-notes/vmware-vdefend-91-release-notes.html
- Broadcom TechDocs, Turbo Mode Distributed IDS/IPS for VMware vDefend
https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/vdefend-atp/4-2/nsx-ids-ips-and-nsx-malware-prevention/ddpi-engine.html