Security – S3 backup with versioning plus lifecycle management to prevent malicious deletion of backups

amazon s3backupSecurity

I just want to run this idea by some smarter people to make sure I'm not overlooking something obvious:

I want to backup my Linux server to S3 using one of the many backup scripts that allow automatic pruning of backups. So my S3 IAM policy will obviously have to give that user GET, PUT, and DELETE permissions. But since the DELETE permission will be there, I need to plan against the worst-case scenario of a hacker getting root access to my server and deleting the backups on S3 using the stored credentials. To eliminate this possibility, I was thinking about the following configuration:

  • Versioning enabled on the bucket (hacker can delete the files but they are only tagged as deleted on S3 and recoverable by me)
  • Lifecycle policy enabled on the bucket to automatically delete old versions (eventually eliminating all versions of the file to minimize storage costs)

Then, the only user that would have bucket-deletion or version-deletion permissions would be my main Amazon account user, which I would configure with MFA.

Am I missing anything obvious here?

I did find this claiming that…

You can use the Object Expiration feature on […] You cannot, however, use it in conjunction with S3 Versioning

…I assume that's obsolete information? In my quick informal experimentation it appears to be possible to use versioning with Object Expiration.

Thanks a lot!

Best Answer

Yes, the blog post you linked (from 2011) appears to contain obsolete information. From the docs:

If the bucket is versioning-enabled (or versioning is suspended), the Expiration action logically deletes the current version by adding a delete maker as the new current version. The NoncurrentVersionExpiration action permanently removes the noncurrent versions.

http://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectExpiration.html

The only problem with your plan is that a lifecycle policy to remove deleted objects (to save storage) is somewhat at odds with disaster recovery protection against maliciously deleted content. You'd have to discover the breach quickly, or the lifecycle policy would purge your apparently-deleted-but-actually-hidden objects.

That isn't to say that your strategy isn't theoretically good -- I would suggest that it is, as I use something similar -- but the purge of no longer needed objects may need to be more sophisticated than lifecycle policies can provide, and may require custom logic that runs on a schedule and has additional rules.

Related Topic