Trending
Most data center breaches do not begin with a clever attack on the perimeter. They begin with one workload that should never have been able to talk to another. A developer's test VM reaches the production database. A compromised web server quietly scans the internal /16 and finds an unauthenticated admin panel. The edge firewall sees none of it, because none of it ever leaves the building.
Microsegmentation is the discipline of fixing that. Not with a single product, but with an architecture: workload-level identity, default-deny policy, and enforcement placed close enough to the workload that east-west traffic is filtered where it actually flows.
North-south traffic crosses the data center boundary, and it is where firewalls, proxies and IPS boxes have always lived. East-west traffic — server to server, container to container, tier to tier — stays inside. On a traditional three-tier design, most of it crosses a core switch that has no security policy at all beyond VLAN separation.
VLANs were the first attempt at internal segmentation, and they still have a place. The problem is granularity and speed. A VLAN is a coarse container, often organised around network topology rather than application ownership, and re-cutting one usually means a change window, a firewall rule request, and a week of waiting. Teams route around friction, so flat networks and permissive any-any rules survive long past their usefulness.
The core idea is simple: policy follows the workload's identity, not its IP address, and it is enforced as close to that workload as possible. Default deny, then explicit allow for the flows the application genuinely needs.
Three properties distinguish real microsegmentation from a well-maintained firewall:
This is the architectural decision that shapes everything else. There is no single correct answer, and larger environments usually run two layers.
An agent or kernel-level filter on the workload's own operating system — eBPF, Windows Filtering Platform, or a managed local firewall. It sees traffic before it leaves the machine, works on bare metal and virtual machines alike, and survives live migration. The cost is an agent on every host, plus the operational work of keeping it healthy and current.
Policy is applied in the virtual switch, so the guest OS needs no agent. This is clean for VM estates, but blind to anything running outside the hypervisor, and it can be awkward when workloads span multiple platforms.
Switches and routers apply group-based policy, often tied to overlay encapsulation. It is hardware-independent of the workload OS and covers appliances you cannot install agents on. It is also the most demanding in terms of switch capability, and it can be the least flexible when teams want changes today rather than next quarter.
Sidecars or ambient proxies enforce at layer 7: which service may call which endpoint, with what method and identity, backed by mutual TLS. Excellent inside Kubernetes; less useful for the mainframe and the backup appliance.
Policy quality is downstream of taxonomy quality. Keep the label set small and boring — five to seven dimensions is usually plenty: application, environment, tier, data classification, owner, and maybe region. Ten dimensions will produce combinatorial policy nobody can read.
Assign ownership of the label catalogue to one team, and review additions. Label sprawl is the most common reason microsegmentation projects stall in year two: the policy engine works fine, but no one can explain why thirty thousand rules exist. A useful habit is treating labels as code — defined in a repository, changed through review, with automated checks that every workload carries the required set.
Application owners rarely know their full dependency graph. Discovery will show you things nobody documented: the batch job that writes to a shared file server at 02:00, the reporting tool with a direct database connection, the monitoring agent polling an odd port. Work in this order:
Two traps worth naming. First, a rule that allows a whole subnet "for now" will still be there in three years. Second, encryption and mutual TLS are valuable, but they solve authenticity and confidentiality, not reachability — a compromised service with valid certificates can still call everything it is allowed to call.
Start with development and pre-production, where a blocked flow costs a ticket rather than revenue. Then a small production application with a cooperative owner. Then the rest, leaving the crown jewels until your process has survived a few failures.
Give every ring a defined soak period in alert mode before enforcement, and a break-glass path: temporary allow rules that require a ticket, expire automatically, and log loudly. Expect a spike in alerts in the first days of enforcement — staff a responder window rather than enforcing on a Friday evening. If your platform supports simulation, use it to preview the effect of a policy set before it goes live.
Treat policies as code. Store them in version control, review changes, test them, and deploy through a pipeline so an outage can be traced to a specific commit. Turn on drift detection so a manually added rule does not quietly defeat the model. Review deny logs weekly at first, and prune rules that have not matched in a quarter — unused permits are the debt that eventually makes the whole system unmaintainable.
The point is not to block everything. It is to make every allowed conversation a deliberate decision, and to make lateral movement expensive for anyone who gets a foothold. Start narrow, measure, and expand the scope only as fast as your team can operate it.
Photo: Brett Sayles / Pexels
