Security & Governance for Data Networking

Part 6 of 6 in the Networking & VPC Foundations for Data Engineering series

We've built the pieces (Part 1), compared how AWS and GCP implement them (Part 2), assembled a real 3-tier architecture (Part 3), closed the gap to managed data services (Part 4), and connected multiple VPCs together (Part 5). This last part is about a different kind of question: how do you know whether what you built is actually secure — not on day one, but six months later, after a dozen people have touched it?

This is where most real-world network security failures actually happen. Not from someone deliberately building an insecure architecture, but from a correctly designed one slowly drifting as changes accumulate.

Least Privilege, Applied to Networks

Every principle in this section is really one idea wearing different outfits: a resource should only be reachable by exactly what needs to reach it, on exactly the port it needs, and nothing else. A few concrete applications of that, specific to data platforms:

• Your data warehouse's security group / firewall rule should name the specific app-tier security group or service account that's allowed in — never a broad CIDR range, and never "allow from anywhere."
• Compute clusters (EMR, Dataproc, self-managed Spark) should run in private subnets with no external IP, by default, every time — not as an exception you remember to configure.
• Admin access should go through SSM Session Manager or IAP (Part 3), not a standing bastion host with a permanently open port.
• If a private-subnet resource doesn't need outbound internet at all — many data-tier resources don't — don't route it through NAT "just in case." No route out is a stronger guarantee than a route out plus a rule that's supposed to block it.

None of this is exotic. The hard part isn't knowing these rules — it's that they quietly stop being true over time unless something is actively checking.

How Configurations Drift

A few patterns account for the overwhelming majority of real incidents:

1. A rule added for a one-time fix that never gets removed. Someone needed temporary access to debug something, opened up a security group or firewall rule to make it happen, and it's still there a year later.
2. A rule that's technically correct but way broader than intended. 0.0.0.0/0 on a port that only needed one specific IP range, because it was faster to write during an incident.
3. Shadowed rules. In rule systems that evaluate in order — GCP firewall rule priorities, AWS NACL rule numbers — a more permissive rule earlier in the sequence silently overrides a more restrictive one added later: the restrictive rule looks like it's protecting you, but it's never actually evaluated. (AWS security groups don't have this problem — every rule is evaluated, with no ordering — which cuts both ways: you also can't neutralize an overly broad SG rule by adding a stricter one.)
4. Route tables changed for an unrelated reason — one route table edit silently reclassifies a subnet's internet reachability, with zero code changes on the data team's side.

The fix for all four isn't vigilance — humans are bad at noticing things that used to be right and quietly became wrong. The fix is tooling that checks continuously, plus a review cadence that doesn't depend on someone remembering.

Tools That Actually Catch This

AWS:

• VPC Flow Logs — captures accepted and rejected traffic at the ENI, subnet, or VPC level. The raw material for almost every other investigation.
• VPC Reachability Analyzer — answers "can resource A actually reach resource B?" by tracing the full path (route tables, security groups, NACLs) without sending any real traffic. Genuinely useful for confirming a fix worked before you find out the hard way.
• Network Access Analyzer — scans for unintended network access at scale, e.g. "which resources are reachable from the internet that shouldn't be."

GCP:

• VPC Flow Logs — same core idea as AWS's version, captured per subnet.
• Firewall Insights (part of Network Intelligence Center) — automatically flags shadowed rules, overly permissive rules, and rules that have never matched any real traffic. This is the direct answer to failure mode #3 above, and it's worth running as a matter of routine, not just when something's already gone wrong.
• Network Analyzer — continuously monitors your VPC configuration and proactively surfaces misconfigurations and suboptimal routing, correlating failures with recent config changes to point at likely root causes.
• Connectivity Tests — GCP's equivalent of Reachability Analyzer: simulate a packet path between two points and get a definitive allowed/blocked answer, with the reason why.

None of these tools are a substitute for the design principles above — they're what catches the moment those principles quietly stop being true.

A Working Review Checklist

When you're checking a data platform's network posture — your own, or reviewing someone else's — this is roughly the order that actually finds problems, largely mirroring the debugging order from Part 1, now run proactively instead of reactively:

Run this quarterly at minimum, and definitely after any significant architecture change — a new VPC connection (Part 5), a new managed service integration (Part 4), or a new team onboarding onto shared infrastructure.

Closing the Loop

Back in Part 1, the whole series opened with a diagram nobody had actually explained, and a job that couldn't reach an external API for a reason nobody could immediately see. Six parts later, that diagram isn't mysterious anymore: it's CIDR blocks and subnets (Part 1), implemented slightly differently depending on which cloud you're on (Part 2), arranged into tiers of decreasing trust (Part 3), with a private path to your data services that skips the public internet entirely (Part 4), connected to whatever other networks your organization actually needs (Part 5) — and now, checked continuously instead of trusted blindly (Part 6).

That's the whole foundation. Everything past this point — Kubernetes networking, service meshes, more exotic hybrid-cloud topologies — is built on exactly these same primitives, just with more layers on top. If this series did its job, none of it should feel like starting from zero.