7.3 Zero-Trust Access & Network Access Analysis

7.3 Zero-Trust Access & Network Access Analysis

Traditional enterprise security relied heavily on the "castle-and-moat" network perimeter model: any user or device located inside the corporate network or connected via a legacy client VPN was implicitly trusted, while everything outside was untrusted. In modern cloud and distributed architectures, this assumption creates severe vulnerabilities. Compromise of a single remote worker's laptop allows lateral movement across internal VPC CIDRs.

Modern AWS security implements Zero-Trust Network Access (ZTNA)—anchored by the principle of "never trust, always verify" (NIST SP 800-207). Trust is never granted based on network location or IP address; instead, every access request is authenticated and authorized dynamically using user identity, device posture, and environmental context. Concurrently, security engineers require mathematical assurance that network perimeters and inspection boundaries cannot be bypassed, leveraging Automated Reasoning tools to analyze reachability without generating live packet probes.

This section covers AWS Verified Access (AVA), Centralized vs Distributed Inspection Architectures, the Gateway Load Balancer (GWLB), and automated reasoning tools including VPC Reachability Analyzer and Network Access Analyzer.

---

AWS Verified Access: Zero-Trust Application Portal

AWS Verified Access (AVA) enables secure, granular access to corporate private applications hosted in an Amazon VPC without requiring a traditional client VPN. It acts as an identity- and device-aware reverse proxy at the application boundary.

Loading diagram...

1. Architectural Building Blocks

• Verified Access Instance: The regional management component that coordinates trust providers, endpoints, and policies.
• Verified Access Trust Providers: Services that supply verifiable context claims regarding the request:
  • User Identity Trust Providers: Native integration with AWS IAM Identity Center or third-party OpenID Connect (OIDC) identity providers (e.g., Okta, Microsoft Entra ID, Ping Identity).
  • Device Trust Providers: Integration with endpoint security and management platforms (CrowdStrike, Jamf, and JumpCloud).
• Verified Access Endpoints: The target application entry points. Can be associated directly with an internal Application Load Balancer (ALB) or a Network Interface (ENI).
• Verified Access Groups: Logical groupings of endpoints that share common security requirements (e.g., all Finance Department internal tools), enabling centralized group-level policy administration.

2. Cedar Policy Language Grammar & Evaluation

Verified Access evaluates each incoming HTTP/S request in real time using the Cedar policy language. Cedar is an expressive, formal logic policy language designed for deterministic authorization.

Each trust provider's data appears under context.<policy-reference-name>, the name you give the provider when you attach it:

• IAM Identity Center: context.<name>.groups (keyed by group ID) and context.<name>.user (for example, user.email.address and user.email.verified).
• CrowdStrike: context.<name>.assessment.overall, the Zero Trust Assessment score (higher is healthier), plus OS and sensor-configuration sub-scores.
• Jamf: context.<name>.risk, a level such as LOW or SECURE.
• Request data: context.http_request (for example, client_ip) and context.tcp_flow for TCP endpoints.

Below is a Cedar policy requiring that the employee belongs to a specific IAM Identity Center group (referenced by group ID so renaming the group doesn't break the policy), has a verified corporate email address, and uses a device whose CrowdStrike overall assessment score is above 50:

// Permit finance staff on healthy devices only
permit(principal, action, resource)
when {
    // 1. User identity from IAM Identity Center (policy reference name: idc)
    context.idc.groups has "c242c5b0-6081-1845-6fa8-6e0d9513c107" &&
    context.idc.user.email.verified == true &&
    context.idc.user.email.address like "*@enterprise.example.com" &&

    // 2. Device posture from CrowdStrike (policy reference name: crwd)
    context.crwd.assessment.overall > 50
};

3. Comparison: AWS Verified Access vs Traditional Client VPN

---

VPC Traffic Inspection Architectures: Ingress, Egress & East-West

Enterprise multi-VPC networks require systematic inspection of three distinct traffic patterns:

1. North-South Ingress: Inbound traffic arriving from the public internet directed to internal workloads.
2. North-South Egress: Outbound traffic initiated by internal workloads directed to external SaaS or internet endpoints.
3. East-West: Inter-VPC or VPC-to-on-premises traffic moving laterally between internal network segments.

Loading diagram...

1. Centralized vs Distributed Inspection Architectures

• Distributed Inspection: Deploys an AWS Network Firewall endpoint directly inside each individual workload VPC. While this limits the blast radius of routing misconfigurations and simplifies intra-VPC debugging, it becomes cost-prohibitive across hundreds of AWS accounts and complicates enterprise-wide rule governance.
• Centralized Inspection: Directs all traffic through a dedicated Inspection VPC connected via an AWS Transit Gateway:
  • Centralized Egress: All workload VPCs default-route (0.0.0.0/0) to the Transit Gateway. Transit Gateway route tables forward outbound traffic to the Inspection VPC, where an AWS Network Firewall or third-party firewall cluster filters outbound FQDNs, detects command-and-control beacons, and routes clean traffic to a centralized NAT Gateway and Internet Gateway.
  • Centralized Ingress: Ingress traffic enters an Ingress VPC, traverses a firewall cluster, and routes through Transit Gateway to internal workload VPCs.
  • Centralized East-West: Workload VPC A communicates with Workload VPC B by routing packets to the Transit Gateway, which directs the flow through the Inspection VPC (with Appliance Mode enabled) before forwarding packets to Workload VPC B.

2. Gateway Load Balancer (GWLB) & The GENEVE Protocol

When organizations deploy third-party virtual firewall appliances (e.g., Palo Alto VM-Series, Fortinet FortiGate, Cisco Secure Firewall) instead of AWS Network Firewall, they deploy a Gateway Load Balancer (GWLB):

• Layer 3 Bump-in-the-Wire: GWLB acts as a transparent network gateway and load balancer. Unlike standard Application or Network Load Balancers, GWLB operates at Layer 3: it does not terminate TCP connections or alter original IP source and destination headers.
• GENEVE Protocol Encapsulation (RFC 8926):
  • GWLB encapsulates the entire original customer IP packet inside a GENEVE (Generic Network Virtualization Encapsulation) packet using UDP port 6081.
  • The GENEVE header carries metadata (such as the GWLB endpoint ID and a flow cookie); encapsulation adds 68 bytes to each packet.
  • The virtual appliance decapsulates the GENEVE header, inspects the raw original IP packet, applies firewall policies, re-encapsulates the packet in GENEVE, and transmits it back to the GWLB.
• MTU Considerations: The GWLB interface accepts packets up to 8,500 bytes and drops larger ones; it doesn't fragment or support Path MTU Discovery. Because encapsulation adds 68 bytes, appliance interfaces must support at least 8,568 bytes.

---

Automated Reasoning: Network Access Analyzer vs VPC Reachability Analyzer

Traditional network security validation relies on active packet testing (e.g., port scanners like Nmap, ICMP pings, synthetic traffic probes). In cloud infrastructure, active testing is incomplete, cannot prove the absence of misconfigurations, and creates operational noise. AWS provides Automated Reasoning tools that apply mathematical formal logic theorem proving to network configurations—evaluating route tables, security groups, NACLs, VPC endpoints, and gateway attachments without sending a single real packet.

Loading diagram...

1. VPC Reachability Analyzer: Hop-by-Hop Point-to-Point Diagnosis

• Primary Purpose: Diagnostic troubleshooting between two specific, declared endpoints.
• Operational Mechanics: You specify a Source (e.g., an EC2 instance ID, ENI, or VPC endpoint) and a Destination (e.g., an RDS instance, another EC2 instance, or an Internet Gateway), along with the protocol and destination port.
• Output: The tool evaluates the configuration graph and returns a deterministic answer:
  • If Reachable: Displays the exact hop-by-hop network path (Source ENI -> Outbound SG -> Subnet NACL -> Route Table -> Peering / TGW -> Destination Subnet NACL -> Inbound SG -> Destination ENI).
  • If Not Reachable: Pinpoints the exact component blocking traffic (e.g., "Security Group sg-01 does not allow outbound TCP 443" or "Subnet NACL acl-02 Rule 50 explicitly denies traffic").
• Execution Mode: Static analysis; zero real packets or network disruptions.

2. Network Access Analyzer: Declarative Governance & Invariant Auditing

While Reachability Analyzer tests point-to-point pairs, Network Access Analyzer provides enterprise-wide security posture auditing against formal security invariants:

• Network Access Scopes: A declarative definition of permitted and prohibited network paths across an entire AWS environment. Scopes define:
  • Source / Destination Criteria: Resource types, subnet tags, ARN patterns (e.g., all instances tagged Tier=Database).
  • Traffic Invariants: Conditions that must never occur (e.g., "No database instances should have any inbound or outbound network path to an Internet Gateway").
  • Exclusions / Allowable Paths: Approved pathways (e.g., "Traffic to the internet is permitted ONLY IF it traverses an AWS Network Firewall endpoint").
• Automated Reasoning Audit Findings: When executed, Network Access Analyzer scans all VPC network configurations against the Scope and generates detailed Findings identifying any non-compliant network path that violates the invariant.

3. Comparison: Reachability Analyzer vs Network Access Analyzer

---

Specialty Exam Pitfalls & Architectural Traps

1. Reachability Analyzer vs Network Access Analyzer Selection: Specialty exam questions often present scenarios where a Chief Information Security Officer (CISO) requires automated verification that zero production database instances have reachable paths to public internet gateways across dozens of VPCs. Selecting VPC Reachability Analyzer is incorrect because it requires testing explicit pairs of resources one by one. The correct architectural solution is Network Access Analyzer, using a Network Access Scope to audit compliance invariants across the entire estate.
2. Automated Reasoning Does Not Send Live Packets: A persistent distractor on the exam states that VPC Reachability Analyzer or Network Access Analyzer causes minor latency or requires scheduling during maintenance windows because it injects synthetic probe packets. Both services utilize Automated Reasoning (formal logic proofs based on AWS configuration data) and never transmit real network packets, creating zero network load or disruption.
3. GWLB Appliance MTU: GENEVE encapsulation adds 68 bytes, so a 1,500-byte packet reaches the appliance as 1,568 bytes, and a maximum 8,500-byte packet as 8,568 bytes. GWLB does not fragment, so appliance interfaces must accept at least 8,568 bytes or packets are dropped.
4. Verified Access OIDC Claims vs Device Posture: A common zero-trust pitfall is assuming that configuring an OIDC identity provider in AWS Verified Access is sufficient for complete zero-trust access. OIDC verifies only user identity. To enforce true zero-trust endpoint hygiene, a Device Trust Provider (such as CrowdStrike Falcon or Jamf) must be integrated, and Cedar policies must explicitly check the device trust data (such as the CrowdStrike assessment score or the Jamf risk level).