Skip to content

PATTERN Cited by 1 source

Zero-trust re-verification

Shape

Zero-trust re-verification re-runs the authorization check at each trust boundary that handles a privileged request, using the same policy engine — an API Gateway authorizer does the edge check, the backend service re-evaluates against the same policy store before performing the actual operation, and the data store accepts only requests that carry proof of authorization.

Convera's multi-tenant flow instantiates this:

1. API Gateway + Lambda authorizer
   → Call AVP (check #1)
   → Allow → forward with tenant_id in custom header

2. Backend Kubernetes pod receives request
   → Re-call AVP against the tenant's policy store (check #2)
   → Build tenant context
   → Forward to database

3. RDS
   → Accepts only requests with tenant context
   → Returns data specific to tenant_id

(Source: sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization)

The backend is explicitly described as re-validating "with Verified Permissions again (for zero-trust policy)" — the second AVP call is deliberate, not accidental.

Why it works

  • No single-point-of-failure for authorization. A bug in the API Gateway authorizer, a misconfigured route, a compromised middleware, or a spoofed internal header cannot cause cross-tenant or over-scope leakage — the backend catches it.
  • Layer-specific context. Each layer has slightly different context available. The edge has token + route; the backend has the resolved resource identifier + domain semantics. Re-evaluating at each layer lets the policy engine use the most specific context for each decision.
  • Graceful failure mode. If a future service boundary is added (new microservice, new database), the re-verification habit means it naturally inherits authz without each new service re-implementing perimeter trust.

When to apply

  • Multi-tenant SaaS where cross-tenant leakage is catastrophic.
  • Regulated workloads (financial, healthcare, government) where audit requires per-operation authorization evidence.
  • Microservice architectures where request paths fan out through multiple internal services, each of which could be compromised independently.
  • Long-lived backends where adding zero-trust-hostile code to add a new bypass would be a larger change than re-verifying.

Trade-offs

  • Latency cost. Each re-verification is an additional policy engine call. Decision caching at each tier is essential, not optional.
  • Policy store duplication risk. Re-verification works only if both tiers query the same policy store. If tiers drift to different stores, correctness depends on policy-store synchronization — a new failure mode.
  • Authorization expense dominates for small requests. For a request whose actual work is a single DB row lookup, the authorization cost might exceed the data cost. Cache aggressively.

Relationship to defense in depth

Zero-trust re-verification is one concrete realization of "defense in depth" for authorization. Other complementary layers:

  • Data-layer enforcement. RDS configured to accept only tenant-context-carrying requests (last line of defense below re-verification).
  • Network segmentation. Per-tenant VPCs, subnets, or security groups (defense at the connectivity layer).
  • Cryptographic binding. Tenant-scoped encryption keys (concepts/cmk-customer-managed-keys) so leakage of ciphertext across tenant boundaries is still safe.

A system doesn't need all of them, but identifying which boundaries to harden is the design decision.

Caveats

  • Perfect zero-trust is uneconomical. Re-verifying on every in-process function call is overkill. Pick the boundaries that matter (ingress, tenant boundary, data-layer boundary) and enforce there.
  • Policies must be consistent across tiers. Policy drift is a new failure mode — works at ingress, fails at backend, or vice versa.
  • Re-verification is only as strong as the policy store. If the policy store is compromised, every tier makes the same wrong decision. Pair with per-tenant policy stores and restricted policy-authorship IAM roles.

Seen in

Last updated · 200 distilled / 1,178 read