Finding access nobody needs

Lesson 4 of 4 in Network Security Controls.

Every environment accumulates access. A rule opened for a migration in 2023, a peering connection for a project that was cancelled, a security group that grew a 0.0.0.0/0 entry during an incident and never lost it. None of it shows up as a breach; all of it shows up as a path.

Two completely different questions let you find it, and the exam separates them deliberately:

"Is there a path?" is a question about configuration, and it is answered by analysis, not observation. Network Access Analyzer takes a Network Access Scope — a declaration such as "paths from any internet gateway to any network interface in these subnets" — and evaluates your actual configuration: route tables, security groups, NACLs, gateways, peering connections, transit gateway attachments, endpoints, load balancers. The findings list every matching path hop by hop. A run that returns nothing is a provable statement about the configuration as it stands, which is why this belongs in a pipeline and on a schedule rather than in an annual review. Amazon Inspector's network reachability findings answer a narrower version of the same question for EC2 instances, and fold the answer into each vulnerability's risk score.

"Is anything using the path?" is a question about traffic, and only telemetry can answer it: VPC Flow Logs (and Transit Gateway flow logs) show what actually connected, what was rejected, and — the useful part — what has not been used at all. An allowed port with 90 days of silence is the strongest argument you will ever have for closing it.

You need both. Analysis finds paths nobody noticed; telemetry tells you which of them anybody wants.

Network Access Analyzer: from a question to a closed path

  1. Declare a Network Access Scope

    What you want to be untrue: "no path from an internet gateway to the data subnets", "no path from the corporate VPN to production except via the bastion-free admin path". Amazon-created scopes cover the common ones.

  2. Analyze the current configuration

    The analysis reasons over route tables, security groups, NACLs, gateways, peering, Transit Gateway, endpoints and load balancers — no packets are sent and nothing needs to be running.

  3. Did any path match the scope?

    A match is a path that exists whether or not anyone has ever used it.

  4. No findings — a provable negative

    Keep the scope and re-run it: on a schedule, and after infrastructure changes, so the next peering connection that reopens the path is caught by machinery rather than by an auditor.

  5. Finding lists every hop in the path

    Internet gateway, route table entry, NACL rule, security group rule, the interface at the end. The remediation is whichever hop you choose to remove.

  6. Is this access actually required?

    Check the flow logs. Traffic on the path means a dependency you must handle; silence means you are closing an unused hole.

  7. Remove the permitting hop

    Delete the route, narrow the security group, remove the peering connection — the narrowest change that breaks the path.

  8. Keep it, with an exception and a narrower scope

    Required access is documented, narrowed to what the traffic shows is used, and excluded from the scope so the next run is not noisy.

  9. Re-run as a control

    In CI against proposed infrastructure, on a schedule against reality. A one-off analysis is a report; a repeated analysis is a control.

Interactive sorting exercise: Two different questions, three different instruments. Sort each piece of evidence.

AWS Verified Access belongs in this lesson rather than only in the hybrid module, because it changes what "unnecessary access" means. A VPN grants a route into a network and then relies on everything downstream to decide what a user may touch. Verified Access grants access to one application at a time, evaluating every request against identity and device trust data. The access you never granted is access nobody has to find and remove later — which is the cheapest form of least privilege available.

Two notes on scope, so you spend your study time where C03 does. The exam guide's skill list for this task was narrowed in C03: VPC Reachability Analyzer, packet-level analysis, and fundamental TCP/IP concepts (ports, the OSI model, UDP versus TCP, network utilities) were removed. What remains is the design and troubleshooting of controls, and the identification of unnecessary access — Network Access Analyzer, Inspector reachability findings, Verified Access. In practice Reachability Analyzer is still a fine tool for "why can't A reach B"; it is simply not what the current guide points at. Spend the time on reading a configuration and deciding whether a path should exist.

The habit to carry out of here: unnecessary access is found by periodic analysis, not by memory. Keep a handful of scopes that encode your invariants — nothing reaches the data subnets from the internet, no spoke reaches another spoke, no production ENI is reachable from the guest network — and run them on a schedule and in the pipeline. Pair each finding with flow-log evidence before you close anything, and you will remove paths without breaking the one workload that quietly depended on one.

Key terms: Network Access Analyzer, Inspector network reachability finding, AWS Verified Access

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.