Logaholic.de

Avatar

web development

Secure backups with push and pull strategies via amazon s3

Note: If you don’t want to or cannot by company-rule trust Amazon S3, this is probably not what you want to read.

I’m going to show you how one could improve the security of his production environment backups. In this setup the production environment can never harm any old backup. There is another offsite backup location if Amazon S3 should fail – for us being our office, this is also perfect for up-to-date testing/development database snapshots.

We will need two separate Amazon S3 accounts and any s3 console tool (like s3bash).

The production environment, with its own (restricted to put and get files) s3 user, will push backups to our s3 bucket. It is not allowed to delete backups there. It does not have any access to the offsite location. If someone gets access to our production environment, he can not delete our backups on s3 per their acl, and can never harm our offsite backups. This is kind of an one-way solution and represents the “push-strategy“.

The offsite location, with the second, full privileged s3 account, will pull the backups from s3 every night. There are also tools for backup verification and testing-environment updates. This is the “pull-strategy“. The offsite location has access to the production environment for maintenance task and deployment.

Small graphic:

securebackups

I wanted to mention this setup since i read a blogpost about a worst case scenario:

“A huge flight sim site was hacked and destroyed this weekend  – avsim.com. An important lesson on why off-site backups are critical! They had two servers, and had a backup of A on B, and B on A. Both were taken out.”

Downsides:

  • Access to our office network/offsite backups would be bad.
  • Bruteforcing/getting access to our administrative S3 Account would be bad.
  • you have to trust Amazon with your data

Conclusion:

Always combine different backup strategies and test your backups. One day you will need them!

Bookmark and Share

Related posts:

  1. Thank you Windows Home Server
  2. OCZ Apex SSD 120GB and How to move a vista boot partition to a new drive

3 Comments, Comment or Ping

  1. Lem

    Have you actually implemented this? I am unclear on how “The production environment, with its own (restricted to put and get files) s3 user, will push backups to our s3 bucket. It is not allowed to delete backups there.” is supposed to work.

    As far as I can tell, the ACLs in S3 support granting READ or WRITE on buckets and objects. If you grant WRITE on a bucket, then the user can put, but they can also upload and delete. I do not see how you can allow upload but disallow delete.

  2. Lem

    I meant to say “then the user can put, but they can also overwrite and delete”.

  3. Karsten Deubert

    Hi Lem, thank you for your comment. You are right, i haven’t actually implemented this fully.

    At the moment we use amazon s3 just as temporary storage, whilst our nightly pull-script just downloads and deletes the backups from the bucket.
    Would it maybe be possible to let the pull-script set the owner of the file to the adminaccount and therefore permit the push-user to delete/modify it?

Reply to “Secure backups with push and pull strategies via amazon s3”