How to think about Zero Trust architectures on AWS

Note: On November 23, 2020 we posted our perspective​ on the overarching subject of Zero Trust. We encourage you to review that post for background before diving into the details below.

Customers with stringent regulatory or risk-averse considerations may look to Zero Trust architectures to refactor legacy applications or deploy new ones. This blog will help you evaluate your application architecture against Zero Trust principles and use Amazon Web Services (AWS) to build secure and scalable architectures.

What is Zero Trust?

Zero Trust security is a model where application components or microservices are considered discrete from each other and no component or microservice trusts any other. This manifests as a security posture designed to consider input from any source as potentially malicious. It starts with not trusting the underlying internal network fabric, and extending to things such as input and output validation at every microservice. Additional efforts can include designing a defense-in-depth approach to protect against individual components, microservices, or identities compromise.

Traditional network security relies on a secure perimeter – everything within the perimeter is trusted and anything outside the perimeter is not. A Zero Trust network evaluates all actions and resources in real time to reduce the risk of unintended access to business data and sensitive resources.

Designing on AWS using Zero Trust principles

To better understand Zero Trust architectures, let’s use threat modeling to compare them to traditional and cloud-native architectures. In threat modeling, users attempt to determine all of the potential attack possibilities to define risk and identify mitigations. One threat model that can be used for illustrative purposes, STRIDE, identifies threats in these categories:

• Spoofing of user identity
• Tampering with data
• Repudiation the source
• Information disclosure
• Denial of service
• Elevation of privilege

AWS best practice architectures

AWS offers foundational tools for designing Well-Architected applications on AWS. The AWS Well-Architected Framework includes strategies to help you compare your workload against AWS best practices, and obtain guidance to produce stable and efficient systems. The Well-Architected Framework contains five distinct pillars, including one for security. To build off this well architected material, let’s use a web application as an example of applying Zero Trust to an AWS architecture.

Figure 1. An example of a web hosting architecture on AWS

The architecture represented is a well architected and secure design for your web application. The system is protected against common attack vectors leveraging the following services:

1. Load balancing with Elastic Load Balancing (ELB)/Application Load Balancer (ALB) allows you to spread loads across multiple Availability Zones and Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling groups for redundancy and decoupling of services.
2. Virtual firewalls using AWS security groups moves security to the instance to provide a stateful, host-level firewall for both web and application servers.
3. Domain Name System (DNS) services with Amazon Route 53 provides DNS services to simplify domain management.
4. Edge caching with Amazon CloudFront decreases the latency to customers.
5. Edge security for Amazon CloudFront with AWS Web Application Firewall (AWS WAF) filters malicious traffic, including XSS and SQL injection via customer-defined rules.
6. Distributed Denial-of-Service (DDoS) attack protection with AWS Shield safeguards your infrastructure against the most common network and transport layer DDoS attacks automatically.

Applying Zero Trust

Let’s reevaluate the architecture, but protect each component as a microservice instead of as part of a larger trusted system. For example, let’s evaluate how we protect against tampering and information disclosure by a SQL Injection attack using the AWS WAF service. By design, customers using the website will come through Amazon CloudFront to access both static and dynamic content. While it makes sense to apply the AWS WAF rules to the CloudFront distribution, ELB/ALB will use a public IP address that could be discoverable by someone else. One mitigation would be to apply the same WAF rules directly against the load balancer.

What about between the web server and app server tiers? Those are traditionally considered “internal” components and data flowing between them is not subject to the same scrutiny. However, the Zero Trust model requires all components and communications be considered untrusted. AWS WAF might not be the right solution depending on the communication methods, but another layer of filtering – either host-based or network-based – would be implemented to do input validation before the input is ingested by the app tier. Additionally, authentication and authorization of commands between these two tiers would be continuous similar to how AWS uses the AWS Signature Version 4 for API signing.

AWS WAF rules and local input validation are effective at protecting against some attacks – but what about DDoS? AWS Shield protects against the most common volumetric and state exhaustion attacks, but you should evaluate potential threats coming from other elements of the system. The best practice architecture does not address the potential of a web server instance flooding the application server with valid but meaningless work, or addresses an inadvertent misconfigured security group. In a Zero Trust model:

• Implement additional metrics and monitoring so a consistent amount of traffic flows from each instance.
• Implement Amazon CloudWatch Anomaly Detection to use machine learning (ML) algorithms to analyze specific metrics such as Amazon EC2 instances generating unusually large amounts of network traffic.
• Use the alarm to notify an Amazon Simple Notification Service (Amazon SNS) topic, which will then trigger a custom Amazon Lambda function that removes the offending Amazon EC2 instance for the auto-scaling group, stops it, and isolates it for further analysis.

To further protect against information disclosure, tampering, and afford some level or repudiation, leverage encryption and least privilege. For example, as a web tier creates backups, use an AWS Key Management Service (AWS KMS) key that only that instance role has KMS:Encrypt permissions on. Since the web tier shouldn’t need to decrypt its own backups, deny or omit KMS:Decrypt to that role. Since that instance role is the only entity with the ability to use the KMS key to encrypt data, and coupled with CloudTrail logs for auditing, you can validate that backups were written by those instances and have not been tampered with. If those instances are accessed by an unauthorized user, they cannot read from past backups.

These are just some of steps you could take. You could also add user authentication between tiers on the Application Load Balancer or use API Gateway between your App Tier and the databases to execute validation of queries. Taking the previous architecture and applying a Zero Trust model to it could lead to an architecture similar to the following.

Figure 2. An example of a Zero Trust web hosting architecture on AWS

Zero Trust goes beyond building a network boundary between each microservice in your architecture. Beyond strengthening your component perimeters; rethink threat sources and investment to protect against them. Zero Trust models are not always appropriate. The second diagram (Figure 2) offers some security benefits, but it also introduces cost, complexity, and operational overhead for maintaining the overall system. When considering Zero Trust architecture, evaluate all five pillars of the Well-Architected framework to properly balance your needs.

Read the Web Applications Hosting in the AWS Cloud whitepaper to learn more about this reference architecture. Learn more about hosting web applications on AWS in our tutorials.

Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.