Elevating Security Standards: Zero Trust Network Access in AWS
TABLE OF CONTENT: -
- Introduction
- Perspective on Zero Trust
- The Triad of Zero Trust
- Human-to-application & Server-to-Server Dynamics
- Zero Trust Network Access
- AWS Services for Zero Trust Network Access
- Implementing ZTNA Architecture with AWS
- Supplementary Security Measures
- Conclusion
1. Introduction
This blog is all about Zero Trust Network Access (ZTNA) in AWS, part of the broader Zero Trust Model. We’ll cover everything from the basics of the Zero Trust Model to ZTNA and which AWS services to use for it. The goal is to make your architecture secure using AWS services and implementing ZTNA for added protection.
2. Perspective on Zero Trust
Definition of Zero Trust varies from place to place but by AWS Zero trust is essentially a security model and associated set of mechanisms that focus on providing security controls around digital assets that don’t solely or fundamentally depend on traditional network controls or network perimeters.
Zero Trust is a security framework requiring all users, whether in or outside the organization’s network, to be authenticated, authorized, and continuously validated for security configuration and posture before being granted or keeping access to applications and data.
3. The Triad of Zero Trust
Zero Trust is majorly an integration of networking, identity and security.
About these 3 sectors on which Zero Trust relies, two major sole sectors are network centric and identity centric viewpoint of architecture. Though all 3 sectors are dependent on each other, but the security cannot be defined as a separate perspective because security is something which is very crucial and important and needs to be proactively integrated at each and every stage of architecture building rather than discussed afterwards.
Network centric and identity centric comes under the security and in many places, it comes under the name of “Types of security controls”.
Let’s discuss network centric and identity centric views in architecture in detail with the help of an example of a simple AWS architecture.
In this setup, a Virtual Private Cloud (VPC) hosts a Load Balancer distributing traffic to multiple EC2 instances managed by an Auto Scaling Group. Users access the application via the Load Balancer, which ensures even load distribution and fault tolerance. The Auto Scaling Group dynamically adjusts the number of EC2 instances based on demand, ensuring scalability and high availability.
- NETWORK CENTRIC
In a network-centric view within Zero Trust, the focus is on securing the network and controlling access based on network-related parameters.
From the above example a network centric will be like securing the VPC, and applying firewalls, adding security groups, adding NACLs,etc.
2. IDENTITY CENTRIC
In an identity-centric view within Zero Trust, the emphasis shifts from network location to individual user authentication and authorization
Using the above example, the AWS IAM roles, User authentication, Role based access to the services all come under the identity centric.
IMP: — In a zero-trust architecture, networking and identity-based controls aren’t just simultaneously present and configured, they’re actually aware of one another.
An illustrative example of this is an Amazon Virtual Private Cloud (VPC) endpoint. VPC endpoints provide private network connectivity to AWS services from your own virtual private cloud and allow you to specify access control policies. These policies and their associated enforcement engine understand not only the network, but also the identities and resources that are flowing across this border network control. They can make authorization decisions that consider this converged context.
4. Human-to-application & Server-to-Server Dynamics
One can categorize any architectural design into two main components: human-to-application and server-to-server.
4.1 Human-to-Application refers to the interaction between users and software applications. It encompasses the user interface, authentication, user experience, and presentation layer, focusing on how users interact with and consume applications.
From the above architecture example, the external user interacting with load balancer for accessing the website on the EC2 is a part of human-to-application architecture.
4.2 Server-to-Server pertains to the communication and interactions between backend systems, servers, or services within an architecture.
From the above architecture example, the load balancer communicating with auto scaling group and EC2 instance is part of the server-to-server architecture.
From an external viewpoint, there exists an association between the dimensions of human-to-application and server-to-server, which can be correlated with the paradigms of network-centric and identity-centric, as demonstrated in the provided table:
User interactions (human-to-application) involve authentication and authorization, while server communications (server-to-server) entail server identities and verification for secure and trusted interaction within the architecture.
So further discussion is about the human-to-application part which is also called Zero Trust Network Access (ZTNA).
5. Zero Trust Network Access
Zero Trust Network Access (ZTNA) is a security service that verifies users and grants access to specific applications based on identity and context policies.
ZTNA removes implicit trust to restrict network movement and reduce attack surfaces.
6. AWS Services for Zero Trust Network Access
This is a list of services that we can use to create a secure ZTNA biased architecture.
6.1 AWS Cognito
6.2 AWS Verified Access
6.3 AWS Verified Permission
6.4 OCID Configurations (OpenID Connect Identity Provider)
6.5 AWS Identity and Access Management (IAM)
6.6 AWS Single Sign-On (SSO)
6.7 AWS Web Application Firewall (WAF)
6.8 AWS Firewall Manager
6.9 AWS Security Hub
6.10 AWS Network firewall
6.11 AWS Shield
6.12 AWS Route 53
6.13 AWS Certificate Manager
7. Implementing ZTNA Architecture with AWS
First let’s see the human-to-application side of architecture. For the human side I have created the below given architecture.
In the outlined architecture, user identities are stored either in AWS Cognito user pools or in other identity providers. To authenticate and authorize these users, the system leverages AWS Verified Access (AVA), which utilizes Cedar language policies for granting user access. However, prior to AVA, user authentication is necessary. AWS Cognito user pools handle the authentication for users stored within them, whereas a different identity provider uses OpenID Connect Identity Provider (OCID) for authentication, with the help of authentication endpoints such as the Auth Endpoint, Token Endpoint, and User-info Endpoint. Once users complete the authentication and authorization processes, they gain access to the application based on the specified policies.
Secondly, to secure applications or the services interacting with humans I have drafted the below given architecture.
So, after users are authenticated and before they access the application services, they need to pass through the layer of a security which contains different services like AWS Firewall Manager, AWS Network Firewall, AWS Shield, AWS Web Application Firewall, AWS Route53 and many other services too. There is no need to use all these services or only these services we can modify accordingly. We also have a security hub which is a centralized security service and automates security practices. Then the application services need to be secured by the Security Groups, IAM and other services available.
8. Supplementary Security Measures
There are some additional things that we can use to make our application more secure: -
- AWS IAM
- AWS SSO
- AWS trust provider integration
- Mutual TLS
- Lambda Authorizer
- HTTPS
- JWT authorizer
9. Conclusion
The blog above introduces an architecture designed for implementing Zero Trust Network Access (ZTNA) in AWS. It reflects a personal viewpoint on using AWS services for ZTNA, allowing for modifications based on customer preferences and specific needs.