Architecture Notes: Microsegmentation with NSX Without Boiling the Ocean

Microsegmentation is one of those projects that’s easy to green-light and hard to finish. The technology works. What kills these projects is scope, rule sprawl, and the fact that nobody actually knows what their applications talk to. These are my working notes from a deployment that made it to production and stayed there.

The phasing that worked

We explicitly rejected “segment the datacenter” as a goal. The phases:

1. Phase 0 — Visibility only. Deploy the DFW with allow-all rules and logging. Let NSX Intelligence / vRNI observe flows for six weeks. No enforcement, no risk, and the flow data becomes the raw material for everything after.
2. Phase 1 — The perimeter of one crown jewel. Pick a single high-value application with a motivated owner. Ring-fence it: one section of rules that says what may enter and leave the app boundary. Default-deny only between the app and everything else — traffic within the app stays open.
3. Phase 2 — Intra-app rules for that same app. Tier separation (web → app → db) inside the fence.
4. Phase 3 — Repeat per application, in order of value, forever. There is no “done” — there’s a repeatable factory.

Rule design: groups, tags, and nothing else

Every DFW rule references security groups; every group membership is driven by VM tags; no rule ever references an IP or a VM by name. The tag schema stayed deliberately small:

Tag scope	Values	Drives
app	crm, billing, dw, …	Application fence membership
tier	web, app, db	Intra-app rules
env	prod, test, dev	Environment isolation rules

Tags are applied at provisioning time by the same automation that creates the VM — they are not applied by hand, ever. A VM with no tags lands in a quarantine group that can reach patching and monitoring infrastructure and nothing else. That single default did more for our security posture than half the explicit rules.

Section: app-crm (managed by crm pipeline)
  1  allow  grp-lb-prod        → grp-crm-web   : 443
  2  allow  grp-crm-web        → grp-crm-app   : 8443
  3  allow  grp-crm-app        → grp-crm-db    : 5432
  4  allow  grp-crm-any        → grp-core-svcs : dns, ntp, ad-auth
  5  drop   any                → grp-crm-any   (logged)
  6  drop   grp-crm-any        → any           (logged)

Six rules. The whole application. Rules 5 and 6 are the fence; rules 1–3 are the tiers; rule 4 is the reality tax (everything needs DNS, NTP and auth).

The egress rule argument

Rule 6 — blocking outbound traffic from the app to everywhere — generated more meetings than the rest of the project combined. Teams accept “control what reaches my app” easily and resist “control what my app reaches”. Hold the line anyway: an app that can’t reach arbitrary destinations is an app that can’t exfiltrate, can’t be a lateral-movement launchpad, and can’t develop surprise dependencies.

Operational reality checks

Things that mattered more than expected:

• Rule sections map to owners. Each application’s section is generated from a file in that team’s repo. NSX is the enforcement point, git is the source of truth, and the security team reviews pull requests instead of processing tickets.
• Firewall rules need CI. We lint rule files (no any → any, drops must log, every rule carries a ticket reference) and apply through the NSX policy API on merge.
• Emergency bypass must be designed, not improvised. Ours is a break-glass tag that moves a VM into a logged, time-limited allow group — and pages the security channel when used.

What I’d tell past me

Start with visibility, fence one application, and industrialize the repeat. Resist the platform-wide big bang, however good the demo looks. And budget as much time for the organizational work — ownership, process, exceptions — as for the technical build, because NSX will not be the thing that blocks you.