Zero Trust Architecture¶

A comprehensive guide to implementing zero trust security models across AWS, Azure, and Google Cloud Platform.

Table of Contents¶

1. Architecture Overview
2. Architecture Diagram Description
3. Component Breakdown
4. AWS Implementation
5. Azure Implementation
6. GCP Implementation
7. Design Considerations
8. Network Security vs Identity Security
9. Continuous Verification Patterns
10. Cost Estimation
11. Production Checklist

Architecture Overview¶

What is Zero Trust Architecture?¶

Zero trust is a security model based on the principle of "never trust, always verify": - No Implicit Trust: Every request is authenticated and authorized regardless of origin - Least Privilege Access: Users and services get the minimum permissions required - Microsegmentation: Network is divided into small zones to limit lateral movement - Continuous Verification: Trust is continuously re-evaluated, not granted once - Assume Breach: Design systems assuming the network is already compromised - Identity-Centric: Identity replaces network perimeter as the primary security boundary

Core Principles¶

1. Verify Explicitly: Always authenticate and authorize based on all available data points (identity, location, device health, service, workload, data classification)
2. Use Least Privilege Access: Limit user access with just-in-time and just-enough-access (JIT/JEA), risk-based adaptive policies, and data protection
3. Assume Breach: Minimize blast radius and segment access, verify end-to-end encryption, use analytics for visibility and threat detection

Benefits¶

• Reduced Attack Surface: Microsegmentation limits lateral movement
• Improved Visibility: All access attempts are logged and monitored
• Data Protection: Classification-aware access controls
• Compliance: Granular audit trails for regulatory requirements
• Remote Work Support: Secure access regardless of user location
• Cloud-Native Security: Designed for distributed, multi-cloud environments

Trade-offs¶

• Complexity: Significant architectural and operational overhead
• User Experience: Additional authentication steps can impact productivity
• Legacy Systems: Older applications may not support modern identity protocols
• Cost: Identity providers, policy engines, and monitoring add cost
• Migration Effort: Transitioning from perimeter-based security is gradual

Use Cases¶

• Enterprise environments with remote and hybrid workforces
• Multi-cloud and hybrid cloud deployments
• Regulated industries (finance, healthcare, government)
• Organizations with contractor and third-party access
• Applications handling sensitive data (PII, financial, health records)

Architecture Diagram Description¶

High-Level Architecture¶

flowchart LR
  U[User + device] --> IDP[Identity provider<br/>MFA, device posture]
  IDP --> CTX[Context:<br/>identity, device, location, risk]
  CTX --> PE[Policy engine]
  PE --> PDP[Policy decision point]
  PDP -- allow --> AG[API gateway]
  PDP -- allow --> AP[App proxy]
  PDP -- allow --> ZT[ZTNA tunnel]
  PDP -- deny --> X[Block]
  AG --> R1[Microservice]
  AP --> R2[Internal app]
  ZT --> R3[Legacy app]
  PE -. continuous re-eval .-> PDP

[User/Device] --> [Identity Provider] --> [Policy Engine]
                                              |
                                     [Policy Decision Point]
                                              |
                           +------------------+------------------+
                           |                  |                  |
                    [API Gateway]     [Application Proxy]  [VPN/ZTNA]
                           |                  |                  |
                    [Microservice A]  [Internal App]     [Legacy App]
                           |                  |                  |
                    [Data Store]      [Data Store]       [Data Store]

Request Flow¶

1. User or device initiates a request
2. Identity provider authenticates the user (MFA, device posture check)
3. Policy engine evaluates context (identity, device, location, risk score)
4. Policy decision point grants or denies access
5. Traffic is routed through an enforcement point (proxy, gateway, service mesh)
6. All access is logged for monitoring and analytics
7. Continuous monitoring re-evaluates trust throughout the session

Component Breakdown¶

Identity and Access Management¶

Network Security¶

Monitoring and Analytics¶

AWS Implementation¶

Identity Layer¶

Network Layer¶

Monitoring Layer¶

Documentation: - AWS IAM Identity Center - AWS Verified Access - AWS PrivateLink - Amazon GuardDuty

Azure Implementation¶

Identity Layer¶

Network Layer¶

Monitoring Layer¶

Documentation: - Microsoft Entra ID - Conditional Access - Azure Private Link - Microsoft Sentinel

GCP Implementation¶

Identity Layer¶

Network Layer¶

Monitoring Layer¶

Documentation: - BeyondCorp Enterprise - Identity-Aware Proxy - VPC Service Controls - Security Command Center

Design Considerations¶

Identity-Centric Design¶

• Use strong authentication: Enforce MFA for all users, preferably phishing-resistant methods (FIDO2, passkeys)
• Implement SSO: Centralize authentication through a single identity provider
• Short-lived credentials: Use temporary tokens and certificates instead of long-lived credentials
• Service-to-service identity: Use managed identities (Azure), IAM roles (AWS), or workload identity (GCP) instead of API keys

Microsegmentation Strategy¶

• Start coarse, refine over time: Begin with broad segments and narrow based on traffic analysis
• Workload-based segmentation: Group by application, environment, and data sensitivity
• Default deny: Block all traffic not explicitly allowed
• East-west traffic inspection: Monitor and control traffic between workloads, not just north-south

Data Protection¶

• Classify data: Tag resources by sensitivity level
• Encrypt everywhere: Enforce encryption in transit (TLS 1.2+) and at rest
• DLP policies: Prevent sensitive data exfiltration
• Access based on classification: More sensitive data requires stronger authentication

Network Security vs Identity Security¶

Traditional Perimeter Model¶

Migration Path¶

1. Phase 1 - Inventory: Catalog all users, devices, applications, and data flows
2. Phase 2 - Identity: Deploy centralized identity provider with MFA
3. Phase 3 - Device Trust: Implement device posture checks
4. Phase 4 - Microsegmentation: Segment networks and apply least-privilege rules
5. Phase 5 - Continuous Monitoring: Deploy analytics and automated response
6. Phase 6 - Automation: Automate policy enforcement and incident response

Continuous Verification Patterns¶

Session-Based Verification¶

• Re-evaluate trust at regular intervals during active sessions
• Step-up authentication for sensitive operations
• Session timeout policies based on risk level
• Device posture re-checks during long sessions

Risk-Based Adaptive Access¶

• Low Risk: Standard authentication, full access to non-sensitive resources
• Medium Risk: MFA required, limited session duration
• High Risk: Phishing-resistant MFA, restricted access, additional logging
• Critical Risk: Block access, alert security team

Context Signals¶

Cost Estimation¶

AWS (Monthly Estimate for Mid-Size Deployment)¶

Azure (Monthly Estimate for Mid-Size Deployment)¶

GCP (Monthly Estimate for Mid-Size Deployment)¶

Production Checklist¶

Identity and Access¶

• Centralized identity provider deployed and configured
• MFA enforced for all users (phishing-resistant for admins)
• SSO configured for all applications
• Least privilege access policies implemented
• Service-to-service authentication uses managed identities
• Privileged access management (PAM) in place
• Regular access reviews scheduled

Network Security¶

• Microsegmentation implemented with default-deny rules
• Private connectivity configured for all PaaS services
• mTLS enabled for service-to-service communication
• DNS security filtering active
• WAF deployed for public-facing applications
• VPN replaced with ZTNA where possible

Data Protection¶

• Data classification scheme defined and applied
• Encryption in transit enforced (TLS 1.2+)
• Encryption at rest enabled for all data stores
• DLP policies configured for sensitive data
• Key management using HSM-backed services

Monitoring and Response¶

• SIEM deployed with correlation rules
• All access events logged and retained
• Anomaly detection and UEBA configured
• Automated alerting for high-risk events
• Incident response playbooks documented
• Regular security assessments and penetration testing

Governance¶

• Zero trust policy documented and approved
• Compliance requirements mapped to controls
• Regular policy reviews scheduled
• Security awareness training for all staff
• Third-party access policies defined

Related Guides: - Microservices Architecture - Web App 3-Tier Architecture - Service Comparison - Networking