Over-Scoped Pre-Authenticated Request Exposes Customer Exports
A developer in the data-science compartment created a pre-authenticated request (PAR) for bucket customer-exports to share one CSV with an external partner. The PAR grants read access to all objects in the bucket, expires in 30 days, and the bucket holds 18 months of customer PII (about 2 TB). The developer's IAM policy allows manage object-family in the compartment. Cloud Guard raises a finding about a bucket with a pre-authenticated request. At 14:05, the security team sees 1.8 TB downloaded through the PAR URL from an unrecognized IP address in another country. The developer says they shared only partner-list.csv. The bucket is not public, and versioning is enabled. Audit logs are enabled at the tenancy level.
1. What are the first containment actions and why?
Read the worked answer
Delete the PAR immediately; that revokes the URL without deleting the bucket or objects. Preserve Audit logs and any Object Storage access logs before making broader changes, because they are the evidence for scope and timing. Notify the incident response and privacy teams because customer PII may have been exfiltrated. Check for other PARs in the compartment and tenancy and revoke any that are over-scoped or unnecessary. Do not delete the bucket or objects; versioning and object metadata may be needed for investigation. Identify which objects were accessed and whether the download was limited to partner-list.csv or the whole bucket. The PAR being scoped to the bucket, not the single object, is the direct cause of the broad exposure.
2. How do you investigate scope and root cause using OCI services?
Read the worked answer
Use Audit logs to find the PAR creation event, the identity that created it, the bucket scope, and the object GET requests from the unrecognized IP. Correlate with IAM policy changes that allowed manage object-family in data-science. Use Object Storage inventory and versioning to list objects and confirm what existed at the time. Review Cloud Guard findings for related public or over-scoped access. Check whether the PAR URL was posted to a public site or shared beyond the partner. Confirm whether the download came through the PAR only or through other credentials. Preserve results in the incident record and compare the accessed object list with the intended partner-list.csv.
3. What preventive controls would you put in place?
Read the worked answer
Reduce IAM scope: remove manage object-family from the developer group and grant only the specific object permissions needed. Restrict PAR creation to a small approved group with a separate policy, and require PARs to be scoped to a single object with a short expiry and an approval record. Use Security Zones or Cloud Guard detectors to flag or deny public bucket access and over-scoped pre-authenticated requests. Enable data classification and require PII buckets to have additional review before sharing. Add a Cloud Guard responder or notification for PAR creation in sensitive compartments. Finally, train developers that a bucket-level PAR grants access to every object, not just the file named in the ticket.