Chapter 15: Security, zero trust, and authorization

Introduction

ACME’s experience shows why zero trust depends on policy-based authorization of each access request rather than reliance on a network perimeter.

• Limits of perimeter security: Explain why ACME could not achieve zero trust simply by strengthening network boundaries. Its global workforce, multicloud systems, and external customers meant there was no clear inside and outside to protect.
  Why it matters: This explains why improving the network perimeter alone would not solve ACME’s access-control problem.
• Policy based access decisions: Describe how ACME’s PBAC system provides a foundation for zero trust: a policy engine evaluates every access request using identity and contextual signals, applying security policy consistently across systems.
  Why it matters: It turns zero trust from a slogan into a way to make and enforce access decisions across ACME.

Key terms: zero trust, perimeter, Policy-Based Access Control (PBAC), policy engine, identity attributes, contextual signals, control plane

15.1 Rethinking security for the zero-trust era

The section explains why perimeter-based security fails in ACME’s distributed environment and why zero trust shifts security toward contextual authorization for every access request.

• Limits of perimeter trust: Explain how the traditional perimeter model trusted access from inside the network and why that model no longer fits ACME’s environment.
  Why it matters: It explains why being on the corporate network is no longer enough to justify access.
• Contextual zero-trust decisions: Describe zero trust as replacing inherited trust and broad, durable access with contextual evaluation of every access request.
  Why it matters: It identifies the change in how access is decided, rather than treating zero trust as a product purchase.
• Authorization decision foundation: Describe the signals and policy capability ACME needs to make zero-trust access decisions across its systems.
  Why it matters: Checking every request is useful only if decisions draw on reliable context and consistent policies.

Key terms: perimeter, implicit trust, lateral movement, zero trust, continuous authorization, inherited trust, identity signals, device posture, operational signals, governance

15.2 Authorization is the foundation of zero trust

This section explains how ACME makes zero trust concrete through consistent, context-aware authorization decisions that combine enterprise security policies with application rules.

• Continuous access evaluation: Trace how ACME evaluates an access request regardless of its origin and enforces the resulting decision at the target resource.
  Why it matters: Zero trust depends on consistent decisions for requests from any origin, not on replacing every existing enforcement component.
• Authentication and authorization roles: Distinguish the evidence authentication supplies from the complete request an authorization policy evaluates.
  Why it matters: A verified identity is the starting evidence for an access decision, not permission to perform any action.
• Enterprise security policy layer: Explain what ACME’s foundational security policies express and how they coexist with application-specific policies.
  Why it matters: Enterprise security requirements become enforceable access rules without taking application-specific policy ownership away from teams.
• Combined policy testing: Describe why application teams must test their rules alongside foundational security policies and name conditions they should test.
  Why it matters: Testing both policy layers helps teams catch access behavior that isolated application-policy tests would miss.

Key terms: policy engine, Policy Enforcement Point (PEP), Policy Decision Points (PDPs), device posture, contextual signals, authentication, authorization, principal, PARC, context

15.3 Policies for zero trust

The section explains ACME’s three layers of authorization policy and why cross-system operational rules need a layer between enterprise-wide requirements and application-specific logic.

• Three policy layers: Distinguish foundational security, shared operational, and application policies by their scope and ownership, and explain how the layers work together.
  Why it matters: The layers show where a rule belongs and who should be responsible for it.
• Purpose of shared operational policies: Explain why ACME introduced shared operational policies, using an example of a rule that spans systems but is not an enterprise-wide security mandate.
  Why it matters: A shared middle layer lets teams express common operational rules without copying them into every application.

Key terms: foundational security policies, shared operational policies, application policies, functional groups, policy store

15.3.1 Foundational security policies

This section explains how ACME’s foundational policies impose organization-wide security requirements on every access request.

• Enterprise-wide security baseline: Explain how foundational policies set non-negotiable conditions that every access request must meet, regardless of decisions made by application or operational teams.
  Why it matters: A team’s permission to grant access does not override the organization’s basic security requirements.
• Broad scope and security checks: Describe how ACME’s example foundational policy applies broadly and when it refuses authorization.
  Why it matters: The broad scope makes basic device and authentication requirements apply regardless of the requested access.

Key terms: foundational policies, baseline conditions, enterprise-wide security commitments, Cedar, principal, action, resource, device posture, authentication strength

15.3.2 Shared operational policies

Explains how shared operational policies let responsible teams enforce cross-system rules consistently, using ACME’s deployment rule as an example.

• Shared policy scope and ownership: Explain what shared operational policies govern, who manages them, and why teams use them instead of embedding the same rule in each application or tool.
  Why it matters: This helps distinguish a reusable operational rule from a rule built separately into every application.
• After-hours deployment rule: Describe ACME’s shared deployment rule and explain what defining it as policy achieved across its production pipelines.
  Why it matters: The example shows how one operational rule can produce uniform decisions across otherwise separate pipelines.

Key terms: shared operational policies, functional groups, cross-system operational requirements, forbid-unless structure, on-call engineer, deployment pipelines, policy engine

15.3.3 Application policies

This section explains what application policies control and why service teams can focus on domain access rules while other policy layers handle broader security controls.

• Service-specific authorization rules: Explain that application policies are the narrowest policy layer, defining who may perform which actions on which resources within a particular service.
  Why it matters: It identifies where a service’s own access rules belong.
• Responsibility across policy layers: Distinguish the finance service’s domain rules from the broader security controls handled by foundational and shared operational policies, and explain how that split helps the teams.
  Why it matters: Separating responsibilities lets service teams write domain rules without duplicating organization-wide security controls.

Key terms: application policies, resource types, roles, allowed actions, business logic, domain rules, foundational, shared operational, device posture, authentication freshness

15.3.4 Putting the layers together

This section explains how three policy layers produce one zero-trust authorization decision and why Cedar’s forbid-overrides-permit rule keeps that decision secure.

• Unified layered authorization decision: Explain how foundational security, shared operational, and application policies contribute to a single access decision.
  Why it matters: Separate policy layers can express different requirements without producing separate, conflicting access decisions.
• Distributed policy ownership: Describe who owns each policy layer and why distributed ownership does not require fragmented decision logic.
  Why it matters: Teams can manage the rules they are responsible for while requests remain subject to the organization’s full expectations.
• Forbid overrides permit: Explain Cedar’s forbid-overrides-permit rule and why it is essential when policies from multiple layers are combined.
  Why it matters: An application’s permission cannot cancel a security-critical restriction from another layer.
• Fail closed on missing context: Describe what happens when context required by a foundational policy is missing or outdated.
  Why it matters: Missing security evidence does not silently turn into permission to access.

Key terms: foundational security policies, shared operational policies, application policies, policy stores, unified authorization decision, policy ownership, security and identity teams, functional groups, product teams, Cedar

15.4 Using policy to control access

Shows how ACME makes zero-trust access decisions by combining three policy layers for each request, and why those combined decisions must be tested.

• Request-to-decision access flow: Trace how an access request moves from the PEP at the target resource through policy evaluation and back to enforcement.
  Why it matters: Zero trust depends on evaluating each request using relevant context and all applicable rules, rather than trusting network location.
• Combined policy layer effects: Explain how foundational, shared operational, and application policies jointly determine access, including what happens when a foundational forbid conflicts with an application permit.
  Why it matters: A service’s permission is only part of the answer when enterprise security and operational requirements also apply.
• Centralized rules and team control: Justify why ACME combines centrally applicable policies with application-specific policies instead of hard-coding every requirement into each service.
  Why it matters: Common requirements can stay consistent across services without taking service-specific decisions away from application teams.
• Cross-layer decision testing: Describe how to test policy changes in a layered architecture and why isolated policy tests are insufficient.
  Why it matters: Testing combined decisions catches unintended access changes that isolated policy tests can miss.

Key terms: PEP, normalized request, policy engine, effective policy set, unified authorization decision, foundational policies, shared operational policies, application policies, forbid-overrides-permit, application teams

15.5 Measuring progress toward zero trust

The section frames zero-trust progress as improvement in contextual authorization decisions, measured across independent architectural indicators rather than maturity stages.

• Authorization decision quality: Explain why ACME measures zero-trust progress through the quality of authorization decisions rather than a vendor-defined maturity ladder.
  Why it matters: This makes zero-trust progress something ACME can assess in its authorization architecture rather than a stage it claims to have reached.
• Independent progress indicators: Describe what ACME’s independent indicators reveal about its authorization system and why they are not sequential stages.
  Why it matters: The indicators let ACME spot different weaknesses without treating zero trust as a single score or fixed sequence.

Key terms: zero trust, authorization decisions, identity, device posture, operational signals, policy, policy coverage, signal quality, decision consistency, perimeter controls

15.5.1 Policy coverage

This section explains how ACME measures policy coverage and uses it to gauge progress toward zero trust.

• Policy coverage as an indicator: Explain why the breadth of systems and access decisions using PBAC indicates ACME’s progress toward zero trust.
  Why it matters: Coverage shows whether policy-based decisions are spreading beyond isolated systems.
• Coverage inventory and gaps: Describe how ACME tracked policy coverage and used the results to find and address gaps.
  Why it matters: An inventory makes overlooked systems visible and gives teams a concrete way to increase coverage.

Key terms: policy coverage, PBAC, policy engine, zero trust, inventory, embedded or ad hoc logic, hard-coded role checks, network-based trust

15.5.2 Signal quality

This section explains how ACME measured and improved the quality of the signals used in authorization decisions.

• Signal quality and decision reliability: Explain why accurate, timely, and governed signals matter to authorization decisions, even when policies are well written.
  Why it matters: A sound policy cannot make a dependable decision from undependable inputs.
• Measuring and refreshing signals: Describe how ACME assessed signal freshness, completeness, and consistency, and use its device-posture example to explain how it improved an outdated signal.
  Why it matters: Measuring signal gaps lets a team fix the inputs its access decisions depend on.

Key terms: signal quality, device posture, authentication freshness, principal attributes, operational context, conservative fallback rules, service-level indicators, freshness, completeness, consistency

15.5.3 Decision consistency

This section shows how ACME tests whether the same authorization conditions produce the same decisions across systems and uses improving consistency as a sign of zero-trust progress.

• Cross-System Decision Consistency: Explain what decision consistency means and why ACME previously got different authorization outcomes for identical requests.
  Why it matters: A decision should not change merely because a different application receives the request.
• Testing Consistency as Progress: Describe how ACME measured decision consistency and why an increasing share of matching outcomes indicated progress toward zero trust.
  Why it matters: Comparing the same test requests across systems makes architectural progress observable.

Key terms: decision consistency, PBAC, embedded authorization logic, canonical test requests, foundational policies, shared operational policies, device posture

15.5.4 Reduced perimeter reliance

The section shows how ACME reduced reliance on network location for access decisions and measured that shift as progress toward zero trust.

• Context over network location: Explain why ACME moved from trusting requests based on network location to evaluating identity, device posture, and context through policy. Describe how its reporting-tool example illustrates consistent decisions inside and outside the network.
  Why it matters: It distinguishes zero-trust access decisions from simply requiring users to be on the corporate network.
• Measuring declining perimeter reliance: Describe how ACME tracked whether application access was becoming less dependent on perimeter controls. State what trends indicated greater reliance on policy-based authorization.
  Why it matters: These trends give the security team observable evidence that access decisions depend less on location.

Key terms: network-based trust signals, policy-based authorization, evaluated context, supporting signals, network-derived signals, identity- and context-based signals, VPN exceptions, IP allowlists, firewall rules

15.5.5 Decline in authorization exceptions

This section explains why authorization exceptions reveal gaps in an access-control model and how their decline can indicate progress toward zero trust.

• Authorization exceptions as warning signs: Explain why one-off authorization exceptions can signal that the access-control model does not express the organization’s real access needs, and describe the problems caused when those exceptions accumulate.
  Why it matters: An exception may be evidence of a policy gap rather than just an unusual request.
• Exception decline as progress: Describe how ACME measured authorization exceptions and why replacing workarounds with shared policies made a decline in exceptions a sign of zero-trust progress.
  Why it matters: A falling exception count offers concrete evidence that standard policies are handling access needs previously met by workarounds.

Key terms: authorization exceptions, one-off rules, shared policy, emergency bypass flags, special-case configurations, shared operational policies, policy drift, zero trust

15.6 Beyond security: The organizational payoff

The section explains how policy-based authorization made ACME’s zero-trust architecture a consistent decision layer that improved security and day-to-day operations.

• Authorization as the decision layer: Explain why authorization is the meeting point for ACME’s zero-trust controls: signals, governance, and enforcement come together in a policy-grounded decision at the moment of access.
  Why it matters: This explains how ACME turned separate security measures into decisions it could apply and govern.
• Consistent decisions across systems: Describe how shared policies and common signals replaced differing local interpretations of access permissions, and what that consistency changed for users and teams.
  Why it matters: Consistent decisions make access less confusing to use, support, and investigate.
• Operational agility and resilience: Explain how ACME’s policy layers let teams change requirements without widespread code changes, while handling missing or stale signals predictably.
  Why it matters: The same design that controls access also makes changes easier and failures more predictable.

Key terms: zero trust, decision layer, authorization, policy governance, PBAC, shared policies, common signals, shared decision layer, foundational policies, shared operational policies

15.7 Summary