1.2.2. Zero Trust and Assume Breach
First Principle: Traditional perimeter-based security fails in cloud environments because there is no fixed perimeter. Zero trust shifts the security model from "trust but verify" to "never trust, always verify" — treating every request as potentially hostile regardless of its origin.
In a traditional data center, you might trust traffic inside the corporate network. In AWS, this model collapses: resources communicate over shared infrastructure, developers access services from anywhere, and API calls arrive from hundreds of sources. A compromised EC2 instance inside your VPC is just as dangerous as an external attacker if your internal controls assume trusted status.
Zero Trust Principles:
- Verify explicitly — Always authenticate and authorize based on all available data points (identity, device, location, service)
- Use least-privilege access — Limit access to just-in-time and just-enough-access
- Assume breach — Minimize blast radius and segment access. Verify end-to-end encryption. Use analytics for threat detection
Assume Breach is the operational partner of zero trust. Instead of hoping your perimeter holds, you design your architecture to minimize damage when (not if) a breach occurs:
- Segment networks so a compromised instance can't reach your database tier
- Rotate credentials automatically so stolen keys expire quickly
- Monitor everything so you detect breaches in minutes, not months
- Automate response so containment happens in seconds
AWS Implementation of Zero Trust:
| Zero Trust Principle | AWS Service/Pattern |
|---|---|
| Verify explicitly | IAM Identity Center + MFA, Cognito, Verified Access |
| Least-privilege access | IAM policies, SCPs, Permissions Boundaries |
| Assume breach | GuardDuty, Security Hub, VPC segmentation, EventBridge-driven remediation |
⚠️ Exam Trap: Questions may describe a "trusted internal network" and ask which additional controls are needed. The correct answer applies zero-trust principles even to internal traffic — never assume trust based on network location alone.
Scenario: Your company's security team argues that resources within the same VPC don't need security groups because "they're already behind the firewall." How does zero trust thinking challenge this assumption?
Reflection Question: Why is "trust the network" a dangerous assumption in cloud environments, and how does zero trust address the specific risks of multi-tenant, API-driven infrastructure?
