Your Cache Is Part of the Security Model

Caching is often introduced with the goal of improving performance. However, when cached data influences authorization outcomes, it plays a crucial role in determining how long an outdated security fact can remain in use. This is the fourth installment in a series examining the intersection of security design and production systems.

While caches aim to accelerate authorization, they can inadvertently maintain old permissions even after the source of truth has revoked them. This issue typically arises inadvertently rather than as a deliberate security choice.

Teams may add caching to reduce latency from an identity service or store authorization decisions for an extended period. While these changes can enhance performance, they can inadvertently prolong the lifespan of outdated security information. When a user changes departments or a device falls out of compliance, the authorization path may still rely on yesterday's cached answer rather than the current state. At this juncture, the cache configuration can effectively become an access-control policy.

Caches can be differentiated based on the type of data they store. Caching a policy bundle allows the system to evaluate the current request, whereas caching an attribute carries the risk of storing outdated information. A cached "allow" decision preserves both the old inputs and the old conclusion, which can pose security risks if not managed properly.

To address this, an example caching key is provided: cache_key = (subject_id, resource_id, action, policy_version, attribute_generation). If a cache decision does not capture policy and attribute versions, it cannot determine when its answer has become obsolete.

Different attributes require different cache lifetimes. For instance, a display name may become stale without affecting authorization, while employment status must be current. Device posture might change frequently during the workday, necessitating more frequent updates. Assigning a single cache lifetime to all attributes can mask these differences.

The appropriate lifetime is determined by the operation's risk and the behavior of the source system. These values should be defined by policy rather than a uniform time-to-live (TTL).

When an allow decision is cached for an extended period, it can preserve access after revocation. This asymmetry between stales denies and allows is why long caching periods for allow decisions are generally avoided. When feasible, revocation events should invalidate the affected entries, continuing to use the normal TTL for the remaining entries. Event delivery failures should be anticipated, and a strategy to handle such scenarios should be in place.

The cache invalidation process typically involves invalidating by subject, which is straightforward but may be resource-intensive. An alternative is to invalidate by changed fields, which is more targeted but requires each policy to declare its dependencies. The choice between these methods depends on the system's scale and risk tolerance.

When the identity source is unavailable, a cache miss is evident, but a stale hit can be more dangerous as it appears successful. Implementing a soft expiry and a hard expiry for cached values can mitigate this issue. After the soft expiry, cached values can be served if policy permits, with the system refreshing in the background. After the hard expiry, the documented failure posture for the operation should be used.

In the event of an outage, a cache miss is immediately apparent, but a stale hit can cause serious security problems. To address this, cached values should have both a soft and hard expiry. If a value exceeds the hard expiry, the system should use the documented failure posture for the operation. The authorization decision should be aware that the cached value is stale to prevent it from being treated as current.

When questioned about a decision, the evidence should indicate whether each significant attribute came from a live source or a cache, along with the observation time and age of the cached data. Sensitive raw values should not be included in broadly accessible logs but can be protected where necessary.

Testing the cache is crucial to ensure its reliability. Authorization tests should include scenarios where a cached "allow" decision is followed by revocation. Additionally, tests should consider what happens if the invalidation event is delayed, helping the team understand the maximum exposure window. When reviewing cache configurations, it is essential to treat them with the same scrutiny as authorization rules.

The responsibility for setting authorization-cache lifetimes can fall to various stakeholders, including performance owners, security owners, or the team that originally implemented the cache.