More Secure Backup & Migrate With S3
Drupal’s Backup & Migrate module provides an awesome tool to help automate offsite backups, a critical part of site operations. We manage a fleet of Drupal sites in various enviroments, from simple shared hosting to various cloud hosting providers. This made backups somewhat difficult to centralize, since each environment has different OS tooling available (and sometimes none, if shell access isn’t available).
So what’s the problem?
There is a lot of debate about the security of initiating backups from within the server, as pushing backup content off of the server and into some remote repository requires the server to have some degree of access to the remote repository (S3, SCP, etc). That means that if one of your sites/systems becomes compromised, the attacker can pivot into your backup repository. They could get access to archives of other sites, potentially destroy your entire backup set, the list goes on. As such, many advocate for outside pull backup strategies, where an outside backup tool shells into each of your machines/accounts, and grabs a snapshot of your data and pipes it into storage. This way the hosting account has no access to any outside systems, so if it’s compromised the attacker is isolated.
With Backup & Migrate, though, your site has to have stored credentials for your outside repository, since it’s pushing the data directly from the host into storage. That means that if you push all your client backups into one bucket and the backup user has full S3 access, you could have a lot of trouble in the event of an intrusion.
Another solution (for S3, anyway)
AWS IAM users offer a solution to this problem, via Policies. Hopefully you should already be using an IAM user for your S3 access, otherwise you’re storing your master AWS credentials in your site. Using IAM Users you can create a locked-down user that has almost non-existent permissions on S3, allowing them to safely push content into S3, and nothing else.
Getting Started
This assumes that you already have an active S3 bucket that you are using for backups. If not, we’ll cover that in another post.
To do this, Log Into AWS and go to IAM Users. Once there, select “Create New Users”, and put your backup user username in the first box. Make sure you leave “Generate an access key…” checked. Click “Download Credentials” to get a CSV of the credentials for this user, and then click “close”.
Once back at your user list, you now need to attach a policy to this user to grant them the minimum level of access required to push data into S3. To do so, click on the user, and on the resulting screen click “Inline Policies”, and then click “click here” to create an inline policy for this user.
On the subsequent screen, choose “Custom Policy”, and choose “Select”. Give the policy a name, like “write-only-backups”, and paste in the following policy document:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:putObject"
],
"Resource": [
"arn:aws:s3:::my-s3-bucket/*"
]
}
]
}
Ensure you update the part of the snippet that says “my-s3-bucket” to match your S3 bucket name. Click “Validate Policy”, and if it passes, then click “Apply Policy”.
And that’s it! Use the Access Key ID and Secret Access Key for this user when you configure Backup & Migrate, and it will only be able to push data onto S3, and nothing else!
Note that you will get errors in the UI for Backup & Migrate about being unable to list your backups, but that’s a feature, not a bug… You could allow the list permission as well, but that leaves you open to potential info disclosure if someone steals your S3 credentials. I’m paranoid, so I prefer for this user to only have “blind drop” permissions, so that the credentials have no use aside from uploading data into a specified bucket.
What’s the worst that could happen?
If an attacker gets the credentials for this user, they could potentially flood your S3 account with junk files, but that’s about it. They can’t download the files they upload, nor can they alter permissions to make them accessible. As such, there wouldn’t be much in it for them unless they want to have you go bankrupt on S3 fees, which would mean someone would have to be really bored, and with a really fast internet connection. So we’re not too worried about it :).