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.
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.”
- 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
Always combine different backup strategies and test your backups. One day you will need them!