AWS Network Access Analyzer Overview

Kunal Shah - Aug 27 - - Dev Community

AWS Cloud Hands-on Lab Practice Series

Project Overview —

The AWS Network Access Analyzer project aims to provide a comprehensive understanding and practical demonstration of the Network Access Analyzer (NAA) feature within Amazon VPC. This lab will equip participants with the knowledge and skills to effectively assess, verify, and improve their VPC network security posture.

Solutions Architecture —

Image description

First Let’s understand the real world use case :

Network Access Analyzer uses automated reasoning algorithms to analyze the network paths that a packet can take between resources in an AWS network.

The key concepts of the Network Access Analyzer are:

  • Network Access Scope

  • Findings

A Network Access Scope determines the types of findings that the analysis produces. You add entries to MatchPaths to specify the types of network paths to identify. You add entries to ExcludePaths to specify the types of network paths to exclude.

Findings are potential paths in your network that match any of the MatchPaths entries in your Network Access Scope, but do not match any of the ExcludePaths entries in your Network Access Scope.

  1. Security Audits and Compliance Verification:
  • Use Case: A financial services company needs to ensure that their network configurations comply with industry regulations such as PCI-DSS or HIPAA.

  • Solution: The Network Access Analyzer can be used to scan the VPC configurations and identify any non-compliant access patterns, helping the company verify that their network setup adheres to the required security standards.

2. Proactive Threat Detection:

  • Use Case: A healthcare provider wants to minimize the risk of unauthorized access to sensitive patient data stored in their AWS environment.

  • Solution: The analyzer helps identify potential security gaps or misconfigurations, such as overly permissive security groups, that could be exploited by malicious actors, allowing the provider to tighten security controls before an incident occurs.

3. Network Segmentation Validation:

  • Use Case: An e-commerce platform separates its production, development, and testing environments within the same VPC to maintain strict isolation between them.

  • Solution: The Network Access Analyzer can verify that the segmentation is correctly configured, ensuring that there is no unintended communication between environments that could lead to data leakage or cross-environment attacks.

4. Incident Response and Forensics:

  • Use Case: A tech company experiences a potential security breach and needs to quickly assess if the VPC’s network configuration contributed to the incident.

  • Solution: The Network Access Analyzer can be used to analyze the network access paths that existed at the time of the incident, helping the incident response team identify misconfigurations or unauthorized access that may have facilitated the breach.

Prerequisite —

  • AWS Account with Admin Access.

  • Knowledge about basic networking concepts (such as IP Addressing, CIDR notation, and routing), an understanding with basic cloud operations.

  • Familiarity with navigating the AWS Management Console.

AWS Services Usage —

  • AWS VPC, EC2, SSM, S3, Endpoints, Network Analyzer, CloudFormation and IAM

STEP BY STEP GUIDE -

STEP 1 : Clone the GitHub Repo

  • Navigate to following GitHub Repository **VPC-Network-Access-Analyzer**

  • Clone the repo to download the CloudFormation Template used for this project lab.

  • CloudFormation template name — custom-vpc-cfn-template.yaml

STEP 2 : Creating AWS resources through CloudFormation service.

  • Login to AWS account, Navigate to AWS CloudFormation Service.

  • Head over & change the region of the aws console where you want to deploy the Primary region resources.

  • NOTE : CODE IS TESTED IN Middle East (Bahrain) me-south-1 region.

  • If you want to use other region then you will have to modify the CloudFormation template accordingly.

  • Click on Create Stack & upload the template downloaded in the step 1.

  • This stack will create Three VPC and 3 EC2 Instances as depicted on the architecture diagram with public and private subnet, an internet gateway, Nat Gateway, Security Groups required for this lab exercise.

  • You can verify the deployments by exploring VPC, EC2 sections on AWS management Console.

STEP 3 : Explore and Analyze

TASK 1 : Use a Network Access Scope template to analyze ingress traffic

  • In this scenario, we will use a pre-built template to analyze available traffic paths from an internet gateway.

  • In the left navigation pane, scroll down to the bottom of the page, and choose Network Manager.

  • Now In the left navigation pane, choose Network Access Analyzer.

  • Choose Get started .

  • We are going to use templates to create new Network Access Scopes.

  • Choose Create Network Access Scope .

  • Choose the template named Identify access from Internet Gateways.

  • Choose Next , then configure:

  • Name: naa-ingress-routes

  • Leave the default configuration in the rest of the fields.

  • Choose Next .

  • Review the template and conditions within the Network Access Scope.

  • Choose Create Network Access Scope .

  • Select the naa-ingress-routes and click on Analyze.

  • The analysis takes a few minutes or less to complete.

  • After completion, the result is Findings detected.

  • This page also presents a path display. The display presents the network elements within the ingress path from Source to Destination.

  • The ingress path analysis starts from the internet gateway of VPC3 all the way up to the network interface of VPC3-public-ec2.

  • Review the network architect diagram provided at the top Both VPC2 and VPC3 have an internet gateway. But Findings are only of VPC3.

  • The reason is — the Network Access Scope definition for this analysis has a source of internet gateway and a destination of network interface, in this case VPC2-private-ec2 is in a private subnet, and internet gateways do not have a direct path to network interfaces in a private subnet.

  • This analysis helps verify ingress traffic paths, and even demonstrate compliance in certain use cases.

TASK 2 : Verify the use of a NAT gateway for internet traffic

  • A very common use case for having a NAT gateway in a VPC is to enable internet access for a private subnet.

  • There are some use cases where you have a private subnet that does not require access to the internet.

  • In our architecture Both VPC1 and VPC2 have private subnets.

  • However, Only VPC2 contains NAT gateway which means only Private subnet in VPC2 requires access to Internet, while private subnet in VPC1 does not require internet access.

  • Lets use Network Access Analyzer to validate this.

  • Select Network Access Analyzer.

  • Choose Create Network Access Scope.

  • Select Empty template.

  • Choose Next , then configure:

  • Name: NAT-Gateway-usecase

  • Choose Add match condition.

  • No conditions configured under Source section.

  • Under Destination section:

  • Resource selection: choose ‘Resource types’

  • Resource types: choose ‘Internet Gateways’

  • Choose Next and Review the Network Access Scope definition.

  • Choose Create Network Access Scope .

  • Select the NAT-Gateway-usecase and click on Analyze.

  • The analysis takes a few minutes or less to complete.

  • After completion, the result is Findings detected.

As expected, there are two Findings:

  • A private EC2 Instance in VPC2 accessing the internet gateway.

  • A public EC2 Instance in VPC3 accessing the internet gateway.

  • The findings do not include the private EC2 instance in VPC1.

  • Toggle between the two findings and review the display path for each finding.

  • You see a NAT gateway within the path for VPC2 instance.

  • This validates the architecture diagram, showing internet access is enabled for the private subnet in VPC2 through the NAT gateway; while the private subnet in VPC1 does not have access to the internet.

TASK 3 : Duplicate and modify a Network Access Scope

  • Network Access Scopes can be duplicated, modified, then used to run a new analysis.

  • This can help save time from creating a new Network Access Scope.

  • In this task, duplicate the NAT-Gateway-usecase Network Access Scope created in the previous task, and use the new scope to check any internet access path that doesn’t include a NAT gateway.

  • Select NAT-Gateway-usecase.

  • From the Actions button, choose ‘Duplicate and modify’.

  • In the Duplicate Network Access Scope page, configure:

  • Name: NO-NAT-Gateway-usecase.

  • In the Exclusion conditions section, choose Add exclusion condition.

  • Under Through section, choose Resource types.

  • Resource Types: NAT Gateways

  • Choose Duplicate and analyze Network Access Scope.

  • After a few moments the ‘Analysis status’ for the newly created scope transitions to Complete.

  • There is one Finding -

  • EC2 Instance (VPC3-public-ec2) in VPC3 accessing the internet gateway.

  • This is because instance is in a public subnet.

  • This confirms what we observed in the architecture diagram.

  • VPC3 can access the internet directly, without the need of a NAT gateway.

TASK 4 : Demonstrate a network configuration meets compliance requirements

  • In this final task, We configure a network change and demonstrate a compliant configuration.

  • Here the private instance in VPC2 is required to access a specific IP address and port number.

  • Allow egress traffic to destination IP address — 172.217.164.110 (this is an google.com IP address).

  • Destination port number — 443.

  • Lets review the current internet bound configuration path for VPC2-private-ec2.

  • Choose Network Access Analyzer.

  • Choose Create Network Access Scope.

  • Choose Empty template.

  • Choose Next , then configure:

  • Name: VPC2-private-outbound-path

  • Choose Add match condition.

  • Under Source section:

  • Resource selection: choose ‘Resource IDs’

  • Resource types: choose EC2 Instances

  • Resource IDs: choose VPC2-private-ec2

  • Under Destination section:

  • Resource selection: choose ‘Resource types’

  • Resource types: choose Internet Gateways

  • Choose Next .

  • Review the Network Access Scope definition.

  • Choose Create Network Access Scope.

  • select VPC2-private-outbound-path.

  • Hit Analyze .

  • When the analysis is complete, the result is: Findings detected.

  • Review the path analysis and notice the second element in the path is the Security Group

  • The Destination address is 0.0.0.0/0 ; and the outbound port is 80

  • Now lets Update the security group to match the requirement.

  • Select the security group label.

  • Choose the security group Resource ID.

  • Click the Outbound rules tab.

  • Choose Edit outbound rules .

  • In the HTTP **drop down list, choose **HTTPS.

  • Replace the 0.0.0.0/0 destination address with 172.217.164.110/32

  • Choose Save rules .

  • Now select VPC2-private-outbound-path.

  • Hit Analyze.

  • Review the path analysis and notice the second element in the path is the Security Group

  • The Destination address is 172.217.164.110/32 ; and the outbound port is 443

  • This analysis validates the current configuration is compliant with the requirement.

  • Understood, verified, and improved a network security posture.

  • Demonstrated a network configuration meets compliance requirements.

STEP 4 : Decommission:

  • Go to CloudFormation Stack.

  • Delete the CloudFormation Stack created for this lab.

Congrats ! We have successfully completed lab to Improve and Analyze AWS VPC Security Posture with AWS Network Access Analyzer.

I am Kunal Shah, AWS Community Builder, AWS Certified Professional Solutions Architect, helping clients to achieve optimal solutions on the Cloud. Cloud Enabler by choice, DevOps Practitioner having 9+ Years of overall experience in the IT industry.

I love to talk about Cloud Technology, DevOps, Digital Transformation, Analytics, Infrastructure, Cloud Native, Generative AI, Dev Tools, Operational efficiency, Serverless, Cost Optimization, Cloud Networking & Security.

aws #community #builders #VPC #network #access #analyzer #cloudformation #compliance #troubleshoot #network #security #hybrid #network #peering #segmentation #validatations #isolated #solution #war #reliability #operations #Excellence #infrastructure #deployment #private #secure #design #acloudguy

You can reach out to me @ acloudguy.in

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .