An exposed resource, a broad permission and a missing control are different problems. Bring identity, network and storage configuration into one review while preserving each provider’s policy model.
The examples below describe planned scope. Contact us to discuss your requirements; this capability is not currently available for evaluation.
Relationships to inspect · No access decision is calculated here
01 / Identity & policy
An access request is more than an Allow.
Principal
role / application
Resource scope
bucket / reports/*
Additional context
Conditions, boundaries, session and organization policies
For this AWS example, the principal type, target resource and applicable policies matter together. Explicit denies can override allows; cross-account requests add a separate trust boundary. A single policy statement is not an effective-access verdict.
Review question
Which policies and request conditions apply to this exact caller and resource?
Relationships to inspect · No access decision is calculated here
02 / Storage exposure
Public prevention and access control are different controls.
publicAccessPrevention
enforced
uniformBucketLevelAccess
enabled
Still review
IAM bindings and delegated access paths
Public access prevention blocks grants to allUsers and allAuthenticatedUsers. Uniform bucket-level access disables ACLs in favor of IAM. Neither label means that every other access path has been reviewed; signed URLs, for example, are outside public access prevention.
Review question
Who still has authorized access, and how is that access delegated?
Relationships to inspect · No access decision is calculated here
03 / Endpoint & data access
A public endpoint is not the same as anonymous data.
publicNetworkAccess
Enabled
allowBlobPublicAccess
false
Still review
Network rules, private endpoints and data authorization
Disabling anonymous blob access at the storage-account level prevents anonymous container access. It does not itself remove the public network endpoint. Network restrictions and authenticated or delegated data access remain separate review questions.
Review question
Can a client reach the endpoint, and what separately authorizes the data request?
A useful evaluation agrees the input, context and decision record before measuring the result.
01Collection boundary
Accounts, regions, APIs and resource types
02Native identity
Provider resource identifier and observation time
03Policy context
Principal, action, condition and resource controls
04Dated evidence
Observation, coverage gap and review rationale
Inputs
What you provide
List accounts, projects, subscriptions or compartments with regions, APIs and resource types. Agree the collection principal and network path for each provider.
Context
What must stay attached
Use short-lived, least-privilege read access. Denied or unavailable reads stay visible as coverage gaps; provider-native policy semantics are retained.
Output
What the review should retain
Record the native resource ID, observed time, collection scope, relevant principal and control rationale so the observation can be reproduced and challenged.
Boundary
What it must not imply
A point-in-time configuration snapshot is not continuous monitoring or proof of effective access. Collection permission does not authorize write remediation.
Review in depth
Keep the account boundary. Keep the evidence.
A configuration review needs a precise resource, scope and observation time.
01
Define the collection boundary.
Name the accounts, projects, subscriptions or compartments under review, together with regions and resource types. Unavailable APIs or denied reads must remain visible gaps rather than disappear from the inventory.
02
Read-only does not mean unrestricted.
Use explicitly authorized, least-privilege collection. Configuration APIs can still reveal sensitive metadata; credential lifetime, rotation, tenant isolation and retained fields need their own controls. Collection permissions do not imply permission to modify resources.
03
Preserve provider-specific decisions.
IAM policy evaluation, storage exposure and network boundaries differ across clouds. Keep native resource identifiers and control names with the observation. A shared review view should not turn one provider’s setting into an equivalent control on another.
Your environment. Your constraints.
Describe your environment. Define the review.
Discuss your stack, access model and review requirements with the TraceMint team.
AWS