Review public paths and cloud grants together

TL;DR: Trace the caller's path to the resource and evaluate its effective authority. Reduce unnecessary exposure and permissions without treating recent non-use as proof that a legitimate rare workflow is unnecessary.

Where you are. Your coverage register is ready; now investigate the staging service with production data access.

Trace reachability and authority as different graphs

For the fictional staging service, the public path is internet → load balancer → worker. A firewall blocks direct internet-to-worker traffic but permits the load balancer. That is enough to keep the application path reachable; it says nothing by itself about whether the application authorizes a requested customer operation.

The worker's cloud role has a separate path to the production document store. Review caller identity, role assumption, session constraints, identity policy, resource policy and organization controls under the provider's semantics. The public caller and the workload identity are not the same principal.

Read the exposure packet

The fictional staging service is reachable through a public load balancer. Its role can read a production document store and update unrelated functions. An internal firewall blocks direct access to its instance, and the team argues that the service is therefore private.

Trace the complete path. The load balancer can still relay requests to the service, so blocking the direct route does not establish that the application is unreachable. Then review application authorization and resource policy. Public reachability, allowed cloud access and business permission are different decisions.

Establish the intended use

The owner confirms that staging needs synthetic documents only. Remove the production-data grant and supply a separate test dataset. The unrelated function-update permission also lacks an approved purpose. The strongest repair changes those authority paths rather than relying only on an alert about their use.

The production exporter has a different case: its annual dataset permission is unused in the recent observation window but has an approved seasonal purpose. Constrain it to the needed resource and execution context, and evaluate time-bound activation. Do not apply the same deletion decision to every unused grant.

Verify effective authorization

Review the relevant identity and resource policies, role trust and higher-level restrictions. A policy attachment listing an action does not by itself establish the final authorization outcome. Conversely, removing one identity policy can leave access through another relationship.

Test the proposed state with harmless authorized cases. Staging should no longer read the production store, while its synthetic-document workflow still works. The production exporter should retain its approved seasonal path and fail an unrelated operation. Record the policy versions and identities used in the tests.

Preserve response and collection limits

A posture repair reduces future exposure; it does not establish whether the prior grant was misused. Review available activity evidence for the relevant period and carry any gap into the next lesson. Existing sessions or delegated credentials may need separate containment according to provider behavior.

Update the coverage register after the change. If a collector loses permission while the role is revised, record the observation failure rather than celebrating a drop in findings. The final decision should identify which paths were removed, which remain justified and what evidence still cannot be obtained.

Preserve unknown edges in the path analysis

A path is established only when every required edge is known to permit the relevant flow. A known blocked edge can break that particular path; an unknown edge prevents a positive conclusion. Alternative paths must be assessed separately. The following code is a three-valued graph exercise, not a cloud policy evaluator.

def path_state(edges):
    if any(edge is False for edge in edges): return "blocked"
    if any(edge is None for edge in edges): return "unknown"
    if all(edge is True for edge in edges): return "reachable"
    raise ValueError("edges must be true, false or unknown")

paths = {
    "direct": [True, False, True],
    "via-balancer": [True, True, True],
    "alternate-endpoint": [True, None, True],
}
results = {name: path_state(edges) for name, edges in paths.items()}
assert results == {"direct": "blocked", "via-balancer": "reachable", "alternate-endpoint": "unknown"}

def aggregate(states):
    states = list(states)
    if "reachable" in states: return "reachable"
    if "unknown" in states: return "unknown"
    return "blocked"

assert aggregate(results.values()) == "reachable"
paths["via-balancer"][1] = False
assert aggregate(path_state(edges) for edges in paths.values()) == "unknown"
print(results["direct"], results["via-balancer"], results["alternate-endpoint"])  # => blocked reachable unknown

The fixture models only supplied paths and booleans. It does not discover routes, evaluate packet state or prove there are no additional endpoints. A blocked result requires a complete enough path inventory for the claim being made. Keep private endpoints, service proxies and application-mediated reads in scope where relevant.

When implementing an aggregator, materialize a one-use iterator before checking it repeatedly. The example materializes its input before the membership checks. Without that step, a failed search for reachable could exhaust a generator and hide an unknown state. Test unknown before and after blocked entries. A security decision should not depend on input iteration order.

Evaluate cloud permissions under the actual provider rules

Do not reduce every cloud request to one universal intersection of policy lists. Identity policies, resource policies, session policies, permissions boundaries, organization controls and principal types interact under provider-specific rules. An explicit deny is significant, but the sources of an allow and the effect of a boundary depend on the request context.

Build a request tuple: principal and session, action, resource, environment and relevant conditions. Evaluate that tuple using the supported policy analysis path, then verify harmless allowed and denied cases where authorized. Keep the policy versions and observation time. An attached policy document alone is not the effective decision.

For staging, the owner confirms no production-data purpose. Remove the production grant and unrelated function-update permission, then test the synthetic-document workflow. For the seasonal production exporter, preserve the approved purpose through a narrower resource and activation window. Recent non-use is evidence about the observed interval, not proof that an annual workflow is unnecessary.

Separate preventive repair from incident conclusions

The repaired policy can reduce future authority without establishing whether prior authority was used. Retain the earlier grant interval and ask which activity sources covered it. A permission path supplies potential scope; a successful read receipt supplies observed activity. Neither alone proves who received the data or whether the use was authorized by the business.

Check residual sessions and delegation according to the provider's behavior. If the collector loses read permission during the change, mark the source failure and restore the intended observation path. A disappearing finding is not verification when its source disappeared too.

The final review should identify each removed path, each retained justified path and each unknown path. Attach a permitted workflow test alongside a denied prohibited operation. That pairing makes the repair useful to the service owner and prevents broad denial from masquerading as a complete engineering solution.

Do this before moving on

Test the path aggregator with all permutations of blocked and unknown states, using both lists and generators. Add an alternative endpoint and show why closing the load balancer route alone cannot support a fully blocked conclusion.

Write a request matrix for staging and the seasonal exporter: principal, action, resource, conditions, intended result and verification receipt. State which provider policy semantics must be checked outside the simplified graph model.

Review your result. The matrix distinguishes network reachability, application permission and workload authority. It removes unjustified staging access, preserves the bounded seasonal purpose and keeps unknown alternative routes visible. A policy repair is not described as proof of no historical misuse.

Go deeper

• CIEM explains effective grants and the limits of unused-access evidence.
• Public exposure traces alternate routes through network and application controls.
• Unused-access review adds policy rollout and emergency-recovery constraints.

Key takeaways

• Review the entire caller-to-data path.
• Rare approved work and unnecessary authority need different decisions.
• A repaired policy does not reconstruct historical activity.