S3 Object Ownership changes control, not the need for an access policy
A bucket owner can control who reads an object without owning the object, and an object owner can exist without owning the bucket. Amazon S3 Object Ownership is designed to reduce that split. With the Bucket owner enforced setting, ACLs are disabled and the bucket owner owns every object in the bucket. Access is then managed through policies rather than object ACLs.
AWS documents this as the default for new buckets and recommends keeping ACLs disabled except where individual object control is required. The recommendation is sensible for most data lakes, application uploads, and cross-account ingest patterns. It does not make the bucket public or private by itself. It changes the permission system that must be reviewed.
ACLs off means policies matter more
When Object Ownership is set to Bucket owner enforced, a legacy ACL that granted public read access is not a valid control surface. The bucket owner manages access with bucket policies, IAM policies, and related controls. An access review therefore needs to inspect policy conditions, principal scopes, resource paths, and any anonymous access path. A team that only checks for ACLs can miss an overly broad bucket policy.
The other settings are not equivalent. Bucket owner preferred can give the bucket owner ownership of new objects written with the bucket-owner-full-control canned ACL. Object writer leaves ownership with the writer and allows ACL use. Existing buckets may need an ACL migration before Bucket owner enforced can be applied. Attempting to change the setting without reconciling existing grants can break workloads or leave operators uncertain about which permissions remain effective.
Cross-account uploads deserve a deliberate test. Verify the upload path, the account that owns the resulting object, and the policy path used to read it. Do not infer success from an empty access-denied error or from an object appearing in the console.
A practical review sequence
Start with the bucket configuration and record Object Ownership, public-access settings, encryption, versioning, and policy documents. Enumerate principals that can write, list, read, and delete. Include roles used by applications, not only human users. Check whether the bucket policy grants access to a service principal or organization path with conditions that match the intended use.
Then test sample objects written by each ingest path. Query object ownership and permissions using the account that owns the bucket. Attempt reads from an allowed and a denied principal. Confirm that ACL-disabled behavior rejects an ACL-based grant while a policy-based grant still works.
Object Ownership removes a class of cross-account ambiguity. It does not replace least-privilege policy design, logging, or data classification. The useful question is not whether ACLs are disabled. It is which policy now authorizes every path to the data.
Top comments (0)