Zero Trust Architecture - Vertraue niemandem, verifiziere alles

Zero Trust is not a product you can buy—it is a security paradigm that replaces the outdated perimeter model: The network is never trustworthy, not even from the inside.

The Problem with the Perimeter Model

Why "Trust but Verify" No Longer Works

The classic perimeter model looks like this:

[Internet] - Firewall - [Internal Network = "trusted"]

The underlying assumption: Everything inside the firewall is trustworthy. This assumption has several fundamental weaknesses:

Problem 1 - VPN Users: A remote employee connected via VPN is considered to be "on the network." A compromised VPN client therefore also puts the attacker “on the network.”

Problem 2 – Insider Threats: An employee is already “inside”—the perimeter offers no protection whatsoever.

Problem 3 – Lateral Movement: Initial access to a single workstation allows free movement across the network. The perimeter does not protect against an internal attacker.

Problem 4 - Cloud and Mobile: Data in AWS/Azure has no perimeter. Employees work from home, from cafés, from the airport. The perimeter is dissolving (Dissolution of the Perimeter).

Results of Real Attacks:

• Maersk/NotPetya 2017: once inside the network → 40,000 computers compromised
• Colonial Pipeline 2021: no MFA on VPN → ransomware
• SolarWinds 2020: supply chain → trusted software bypassed the perimeter

Zero Trust Core Principles (NIST SP 800-207)

1. Verify Explicitly: Authentication and authorization at all times—not just during login, but continuously
2. Least Privilege Access: Minimal permissions, just-in-time access
3. Assume Breach: Act as if you have already been compromised—minimize blast radius, end-to-end encryption

Zero Trust Architecture Components

Identity Provider (IdP)

> "Identity is the new perimeter"

Examples: Azure Active Directory / Microsoft Entra ID, Okta, Ping Identity, ForgeRock.

Requirements:

• MFA: mandatory for everyone (exceptions = risk!)
• Conditional Access: Rules governing who accesses what, when, and from where
  • "Only from managed devices in Germany"
  • "Administrative access: only from the office (IP range)"
  • "Highly sensitive applications: MFA + compliant device + insider risk score < medium"

Device Trust (Device Status)

MDM (Mobile Device Management):

• Intune (Microsoft), Jamf (macOS/iOS), Kandji
• Device registered + policy-compliant → "Compliant"
• Non-compliant: no access (or restricted access)

Device Health Check - Minimum Requirements:

• OS up to date? (No Windows 10 end-of-support!)
• Antivirus active and up to date?
• Disk encrypted? (BitLocker/FileVault)
• No jailbreak/root access?

Hardware Attestation:

• Windows: Trusted Platform Module (TPM) + Health Attestation
• macOS: Secure Enclave + Gatekeeper
• iOS/Android: MDM enrollment certificate

Network Access

Micro-segmentation instead of VPN:

• Traditional: VPN = access to everything
• Zero Trust: access only to specific applications

Zero Trust Network Access (ZTNA):

• Zscaler Private Access: no VPN, direct app access
• Cloudflare Access: Identity-aware proxy
• Palo Alto Prisma Access: SASE platform

Connector model:

Employee → Identity Provider (Auth) → ZTNA broker → App connector → Application

No direct network access. Only verified users with compliant devices are granted access.

CASB (Cloud Access Security Broker)

• Visibility and control over cloud usage
• Detect shadow IT: Which cloud apps are employees using?
• DLP for the cloud: No customer data in personal Dropbox accounts
• Examples: Microsoft Defender for Cloud Apps, Netskope, McAfee MVISION

Zero Trust Implementation (Maturity Model)

The CISA Zero Trust Maturity Model defines five pillars, each with three maturity levels:

Pillar 1: Identity

Traditional (Start):

• Password-based authentication
• MFA only for admins

Advanced (Goal):

• MFA for everyone (Conditional Access)
• Continuous Identity Verification
• Privileged Identity Management (PIM)
• Risk-based authentication (Insider Risk Score)

Optimal (Best Practice):

• Passwordless (FIDO2/Windows Hello)
• Adaptive MFA (high risk = stronger verification)
• Identity Threat Detection (ITDR)

Pillar 2: Devices

Traditional:

• No device management (unmanaged devices have access)

Advanced:

• MDM for all devices
• Compliance as a prerequisite for access
• EDR on all endpoints

Optimal:

• Hardware attestation (TPM)
• Continuous Device Health Monitoring
• Zero-Touch Provisioning (Autopilot)

Pillar 3: Networks

Traditional:

• Flat network, VPN for remote access

Advanced:

• VLAN segmentation
• Micro-segmentation (east-west)
• ZTNA instead of VPN

Optimal:

• SASE (Secure Access Service Edge): SD-WAN + Security
• Universal ZTNA (including internal users!)
• DNS Security, Encrypted DNS

Pillar 4: Applications

Traditional:

• Applications accessible via the network

Advanced:

• Application-level Access Control
• API Gateway with Auth
• WAF

Optimal:

• Application Threat Protection
• Continuous Application Monitoring
• DevSecOps Integration

Pillar 5: Data

Traditional:

• No data classification

Advanced:

• Data classification implemented
• DLP Policies
• Encryption at rest + in transit

Optimal:

• Information Protection (Microsoft Purview Labels)
• Rights Management (files remain encrypted even outside the system!)
• Data Access Governance

Practical Roadmap

Months 1–3 (Quick Wins):

• MFA for all users (including internal ones!)
• Conditional Access: unknown devices = no access
• MDM enrollment of all company devices

Months 4–6:

• Basic network segmentation (VLANs)
• ZTNA for remote access (instead of VPN)
• Privileged Identity Management (JIT admin access)

Months 7–12:

• Microsegmentation (critical servers)
• CASB implementation (cloud visibility)
• Data classification + DLP

Annually:

• Maturity assessment (CISA Maturity Model)
• Penetration testing (verify Zero Trust effectiveness!)
• Policy adjustments

Google BeyondCorp as a Model

The Original Zero-Trust Implementation

Google BeyondCorp (2011–present):

• Background: In 2010, Operation Aurora (a Chinese APT) compromised Google’s systems. The result was a new zero-trust concept.
• 2014: BeyondCorp paper published
• Today: In use internally at Google for all 100,000+ employees

Core Principles of BeyondCorp:

1. No "privileged" network: LAN = Internet = same risk
2. Access based on device + user (not on network affiliation)
3. All applications accessible via the Internet (no VPN!)
4. Access decision: Identity + Device Health + Context

Technical Components:

• Trust Engine: continuously evaluates device and user
• Access Proxy: all requests are routed through a proxy
• Device Inventory: all devices registered with a health score
• Certificate-based Auth: no password stored directly on the device

BeyondCorp Enterprise (Google Cloud)

Commercial product based on BeyondCorp principles: Identity-Aware Proxy + Chrome Enterprise. Integration with Google Workspace and other IDPs (Okta, Azure AD).