Network Security
Intermediate 18 min read Network Security
Zero Trust Networking
Treat every network as hostile: identity is the boundary, least-privilege is the law, and 'allow by default' is the enemy.
zero trustZTNAidentityleast privilegemicrosegmentationcontinuous verification
Introduction
What is this?
Zero trust abandons the trusted-inside/untrusted-outside castle model. Every device, user, and flow earns access continuously based on identity, posture, and policy — never location.
Motivation
Why do you need it?
- The enterprise network has dissolved into cloud, BYOD, and SaaS — the castle wall no longer contains the castle.
- Breaches now move laterally inside 'trusted' networks every day; micro-permission is the only sane default.
- Zero trust is procurement reality: vendors and auditors now expect it, not innovation theater.
Think about it
Mental model
Imagine
Castle with a moat
Think of
Airport security at every door
You do not get in with one badge and wander freely; every gate re-checks who you are and where you may go.
Mechanics
How it works
- Every request starts with a strong identity (X.509 device cert or workload identity) plus a session and posture picture.
- Policy engines (PDP) decide per-request; policy enforcement points (PEP) grant a narrow, time-boxed connection.
- Microsegmentation and per-service ACLs implement least privilege at the flow level, often in the cloud via policy/CDN/broker.
- Telemetry from every decision feeds continuous re-evaluation; anything anomalous can revoke the session mid-flight.
Request-time policy evaluation loop
Requestuser + device + posture assert
Identityverify cert, MFA, session
PolicyPDP resolves rights + risk
Segmentconnect to only the allowed service
Verifyloop telemetry, revoke on anomaly
Real world
In production
- A hybrid office deploys ZTNA so users reach only the one SaaS/VDI app they need, bypassing old per-IP VPN rules.
- A bank's cloud workloads use mTLS mesh policies: 'payment-service may talk to ledger-service, nothing else'.
- An MSP runs conditional access: unpatched or unknown devices get web-only access, not the corporate data plane.
Guidelines
Best practices
- Be explicit: every rule names a known identity, service, and path — nothing catches unknown identities.
- Pair identity with device posture (patch level, encryption) as a re-check on each request.
- Log authorizations and denials as first-class telemetry; the deny stream is where real insight hides.
- Migrate zone by zone; force trust-chokeholds on the highest-value assets first.
Watch out
Common mistakes
- Slapping 'zero trust' on the old VPN and expecting identity magic while any-any ACLs remain.
- Making policy so strict that legitimate flows break and engineers ship bypass accounts.
- Letting a single shared service-account identity own a dozen microservices — that's one identity, zero trust.
- Collecting authorization events but never reading them, so re-evaluation has nothing to chew on.
When things break
Debugging tips
- When a flow is denied, pull the PDP decision log for that identity+service pair before touching the firewall.
- In certificate-authenticated setups, clock skew breaks every handshake — sync NTP first.
- Segment pilot conversion: watch the denied-request volume as you flip a segment from allow-all to policy.
Security
Security considerations
- Identity is the new perimeter — protect the credential store and rotate aggressively.
- Continuous verification needs data: implement logging and SIEM wiring before rollout, not after incident one.
- Zero trust is a policy discipline; vendors selling 'zero trust in a box' are usually selling a VPN with a rebrand.
Interviews
Interview checkpoint
Test yourself
Quick quiz
0/2
1
Zero trust treats location as...
2
Which pair is at the heart of every zero trust decision?
Go deeper