Skip to content

CONCEPT Cited by 3 sources

Policy-as-data

What it is

Policy-as-data stores authorization policies outside application code — in a database, a dedicated policy store, or a config bundle — so they can be changed, audited, and reasoned about independently of code deploys. The runtime reads policies from the store at evaluation time (often with caching).

Contrast with policy-in-code: if user.role == "admin" { allow(); } sprinkled through the codebase. Every policy change is a code change; policies are invisible to auditors; no unified analysis is possible.

Why it matters

  • Change velocity. Authorization policy change cadence typically exceeds code change cadence — new tenants, new roles, new regulatory requirements. Coupling them slows both.
  • Auditability. A single store of all policies is trivially auditable; policies scattered through code are not.
  • Analyzability. A single store of policies written in a formal language (Cedar) is amenable to automated reasoning — equivalence, reachability, redundancy, policy-change impact analysis.
  • Separation of duties. Policy authorship can be gated by a different role (infosec) than code authorship (app teams).

Governance flow

Convera's production shape:

Cedar policy authors (infosec team, regulated IAM role)
  → Write policies into DynamoDB (source of truth)
  → DynamoDB Streams capture changes
  → Continuous-sync pipeline propagates to AVP policy stores
  → Lambda authorizer evaluates at request time

Key properties:

  • Write-side IAM-bounded. Only infosec can author policies, via a regulated IAM role.
  • Read-side app-bounded. The Lambda authorizer reads evaluated decisions, not raw policies.
  • Asynchronous propagation. DynamoDB Streams + sync pipeline means policy changes propagate on a bounded (but non-zero) delay; cache TTLs at API Gateway define the effective floor.

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

Relation to spec-driven development

Policy-as-data is a special case of concepts/specification-driven-development — the policy is the spec, the runtime is the executor. Cedar's analyzability-by-design makes the spec subject to proof: policies can be proven equivalent, policies can be proven to never reach a given resource, policies can be proven redundant. This is why policy-as-data + Cedar + AVP is a coherent stack — the surface, language, and engine were co-designed around the policy-as-data premise.

Caveats

  • Cache-invalidation is the propagation floor. Policy change → authorizer-decision-cache TTL is the time before a new policy takes effect. Convera's source doesn't discuss this tradeoff.
  • Policy-store size limits matter. Each engine has quotas; at scale, per-tenant policy stores (patterns/per-tenant-policy-store) are needed not just for isolation but for quota reasons.
  • Dynamic attribute lookups still happen. "Policy as data" is about the policy text, not the attributes it references; those still need authoritative sourcing at evaluation time.

Seen in

Last updated · 200 distilled / 1,178 read