S3 Object Lock governance mode still has an escape hatch
Amazon S3 Object Lock protects an object version with a retention period, a legal hold, or both. The retention mode is the part that many teams miss during design. Compliance mode prevents every user, including the account root user, from deleting or shortening the protected version before retention ends. Governance mode permits users with the appropriate permission to bypass retention. A backup or evidence-retention control that assumes governance mode is equivalent to compliance mode has a deliberate path around its protection.
The distinction is visible in the API and identity policy. Setting or removing a legal hold uses s3:PutObjectLegalHold. Bypassing governance retention requires s3:BypassGovernanceRetention. The bypass does not remove a legal hold. It also does not make an unprotected object version permanent. Treat retention and legal hold as separate controls with separate permissions and monitoring.
Object Lock is version-level protection. A request that targets one version cannot be assumed to protect another version, and a delete marker can leave the bucket's observable state different from the protected version's state. Inventory and restore testing should identify the exact version ID, the retention mode and date, and the legal-hold state.
Separate administrative recovery from evidence custody
Governance mode is useful when an operator must be able to correct an overlong retention setting during an incident. It is a poor fit for records that an outside party may later challenge unless the bypass permission is tightly controlled and its use is recorded. Compliance mode is appropriate when the account owner must have no direct deletion path during the retention period.
Do not grant s3:BypassGovernanceRetention to the application role that writes backups. Put it in a break-glass role with a documented recovery procedure, MFA or step-up authentication where the organization supports it, and an alert on every use. A role that can shorten retention and delete the resulting version effectively controls the evidence even if the API labels the bucket as protected.
Validate the data path
Enable Object Lock when the bucket is created or by following the documented update path. Set a sensible default retention period for new objects, then verify the actual retention metadata on representative versions. Confirm that lifecycle rules, replication, batch operations, and application overwrites preserve the intended protection.
Run a denial test with the application role: attempt to shorten retention and to delete a protected version. Then run a controlled test with the break-glass role and confirm that the governance bypass succeeds only where policy permits it. For compliance mode, verify that the protected version cannot be deleted or shortened by any normal administrative identity. Do not use production evidence for the destructive part of the test; use a separate protected test bucket.
Monitor what changes protection
Alert on changes to Object Lock configuration, legal holds, retention dates, bucket policy, and the identities that hold the governance bypass permission. Log the object version and the principal for every retention change. Review snapshots of the policy after role changes, because an apparently small policy edit can give a broad automation role the ability to remove retention.
Object Lock is a strong control when its mode, permissions, and object versions are understood together. A bucket labeled as immutable can still have an administrative exception, and that exception belongs in the recovery plan and the audit trail.
Top comments (0)