How can administration teams (or software processes) be granted the ability to alter or remove objects from in AWS S3, while prohibiting the permanent deletion of underlying data versions, so as to guarantee (for a window of time defined by a lifecycle policy) the ability to reverse any misadvertent destruction of critical data?
For an organisation facilitated with multiple accounts, can those be leveraged to better protect the data (i.e., the versions) of objects stored in S3?
For background, it looks as though the same API action is used both for marking an object as deleted (i.e., hidden), as for actually expunging a version of its' data from storage.
The Python SDK docs for the S3 deletion API say that "to remove a specific version you must be the bucket owner". I'm unsure if this is still generally true, as I found a similar statement in some of the other SDK docs but not in the S3 API docs. The bucket owner seems defined as the AWS account in which the bucket has been created, rather than any particular user or role in IAM. However, it's not clear what happens if the bucket owner delegates deletion permissions to a role with a policy that permits a user (or compute process) from another account to assume that role. (I'd naively presume that as soon as the foreign user/process assumes the local role, to be able to delete an object, they also inherit the ability to delete historic versions of that object.)
I'm wondering if the docs were in reference only to the specific configuration where the bucket owner grants permissions directly to users/roles of another account without them needing to assume any cross-account role. (And especially the now-discouraged ACL case where the bucket is configured to grant "full control" over individual contained objects to whichever other account was originally used to store that particular object into the bucket.)
