LEARN. PRACTICE. GROW.Concept and mechanism
Zero trust reduces implicit confidence based on location or ownership. A VPN or managed workstation may contribute to assessment but does not authorize every action. Distinguish identity, posture, resource, action, and context. An mTLS-authenticated session can still lack permission for the requested tenant. Design needs enforcement points on actual paths, with enough records to understand grants and denials. It also needs failure behavior: decision-service unavailability should not produce indefinite global permission or a policy improvised during an incident. Define cached-decision validity, resource-specific restrictions, and tested recovery.
Guided application
In a fictional EC2 service, the team remains responsible for the guest operating system despite AWS-managed hardware. Record who patches and who verifies outcomes. For a short intervention, bind privilege elevation to the request, limit duration and scope, and retain traceability. In a FinOps integration, a multi-customer supplier can become a confused deputy if it accepts role references without distinguishing customers. ExternalId should be unique across its customers and supplier-controlled, applied in the trust policy and matching request. It is not a password or a replacement for least privilege. Acceptance testing should show that the correct customer can access what is needed and another context cannot use the same delegation.
Confirmed identity + wrong tenant = authorization still unmet.
Common pitfalls
VPN as global authorization; mTLS as universal access; shared ExternalId; undifferentiated cloud responsibility.
Related topics: Governance, risk, and exceptions · Suppliers, data, and threats · Resilience and recovery dependencies
Document who decides, who enforces, and how failure is handled.
Reference: Zero trust architecture · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17