Network security as controlled communication

Network security constrains which identities and workloads can communicate, over which paths and protocols, with what confidentiality, integrity, inspection, availability and evidence. It is defense in depth around resources—not proof that traffic, endpoints, users or applications are trustworthy. Begin with current data flows, assets, dependencies, administrative paths and failure requirements. An undocumented flow cannot receive a deliberate least-privilege rule, and a rule that nobody owns will drift.

Firewalls, segmentation, and egress

A firewall enforces policy at a boundary using available network and sometimes application context. Stateful filters track connections, but “established” traffic can still carry malicious application data. Default-deny rules should name source identity or scoped network, destination, protocol/port, purpose, owner and expiry. Rule order, shadowing, IPv4/IPv6 parity, load balancers, proxies, cloud security groups, host firewalls and Kubernetes policies all affect the effective path. Test from both permitted and denied locations and observe counters/logs; configuration presence is not evidence that packets traverse that control.

Segmentation limits reachability and blast radius. Separate internet ingress, application, data, management, build, user and high-sensitivity zones or workload groups, then permit only documented service-specific flows. Microsegmentation increases granularity but also policy volume, identity dependency and outage risk. A flat “internal” network turns one endpoint compromise into broad discovery and lateral movement. Egress deserves equal attention: restrict outbound destinations, protocols and DNS paths; isolate fetchers and build workers; protect metadata/control-plane endpoints; and bound proxies so SSRF or malware cannot freely reach internal services or exfiltrate data.

VPNs and encrypted channels

A VPN protects traffic across an untrusted network and can connect a device, user, site or workload to defined resources. It does not make the device healthy, the user authorized for everything, or the tunneled traffic benign. Strong peer authentication, current IPsec/IKE or another reviewed protocol, scoped routes, DNS behavior, endpoint posture, key/certificate lifecycle, idle/absolute duration, revocation and monitoring are part of the control. Full-tunnel routing improves centralized policy but affects latency, capacity and privacy; split tunneling reduces load but creates simultaneous trusted/untrusted paths. Avoid granting an entire private network merely because a tunnel exists.

TLS protects a channel between validated peers. Certificate name/trust validation and every termination hop matter; traffic is plaintext at endpoints and possibly at approved inspection proxies. Inspection creates a powerful trust and privacy boundary requiring explicit purpose, protected keys, bypass policy for sensitive traffic, capacity planning, audit and incident response. Encryption without endpoint identity can create a private channel to an attacker.

Zero trust and operations

Zero trust removes implicit trust based solely on network location or ownership and focuses policy on users, devices, services and resources. It is an architecture and operating strategy, not a product or a demand to remove every network control. A policy decision uses verified subject/workload identity, device posture, requested resource/action, risk and current policy; an enforcement point creates a narrowly scoped session. Continuous signals can trigger reevaluation, but heuristic risk is not proof and failure semantics must be explicit. Network segmentation, service identity, application authorization and encryption complement one another.

Operate network policy as versioned code with review, simulation, canary, rollback and drift detection. Maintain flow inventory and ownership; reconcile observed traffic against intended policy; remove expired rules; and test revocation and dependency outage. Telemetry includes decision, source/destination identity and addresses, protocol, policy/version, bytes/timing and correlation while minimizing payload and personal data. Detection covers unexpected east-west/egress paths, scans, denied bursts, DNS anomalies and configuration change. Capacity, DDoS protection, redundant enforcement, safe fail behavior and recovery drills ensure security controls do not become silent single points of failure.

Segmentation earns its cost only when the boundaries follow the blast radius you actually care about. A network split into zones that every service can traverse anyway has the operational cost of segmentation and none of the containment, and a flat network with strong host-level controls may genuinely be safer than a segmented one whose rules have accumulated exceptions for years. Derive the segments from what an attacker gains by reaching each one — the database tier, the secret store, the build system, the administrative plane — and verify by asking what a compromised workload in each zone could reach, measured against the running policy rather than the diagram.

Default-deny is the correct posture and the migration is where it fails. Applying it from an architecture document breaks the undocumented dependencies that every real system has, so it is reverted within the hour and not attempted again for a year. Run in observation mode long enough to capture periodic traffic — nightly batches, weekly reports, quarterly jobs — because a two-day observation window will miss the connection that only appears at month end, and that connection will break in production at the least convenient time. Generate the initial rules from what was observed, review them for the ones that should not exist rather than blessing them all, and enforce per segment rather than everywhere at once.

Egress deserves the attention that ingress usually gets. Most organisations restrict what can reach a workload and allow that workload to reach anything, which is precisely the path that data exfiltration and command-and-control traffic use. Restricting egress to a declared allowlist is harder than it sounds because dependency resolution, telemetry, and package installs all reach outward, so the practical route is the same one as for ingress: observe, generate, review, then enforce. Where full egress control is impractical, an outbound proxy that logs destination and volume at least makes the traffic visible enough to reason about.

Worked example: the diagram is not the blast radius

A compromised payments API pod is supposed to talk only to its own database. Measure what the running policy allows, not the zone drawing.

destination	architecture diagram	live network policy	what the pod can take
payments-db:5432	allow	allow	tenant invoices
vault:8200	deny	deny	nothing
169.254.169.254	deny	allow (never reviewed)	instance IAM credentials
analytics-s3	deny	allow (exception 2019)	full event history

The diagram said two denies. The live path is three allows. Closing 169.254.169.254 and the 2019 S3 exception shrinks blast radius more than drawing another zone. That table is the interview: segmentation is the policy that is actually loaded.