What settings should I use for Amazon S3, and how should I configure my Amazon S3 account?

This answer assumes that you have already created your Amazon S3 account, and have made a note of your S3 access key and secret key. If not, then go here: http://aws.amazon.com/s3/.

When you enter your Amazon S3 details in the UpdraftPlus setup, the only thing that some people find non-obvious is what to enter into the “S3 location:” field. All you have to enter is the name of the bucket that you wish to use. (If this bucket does not yet exist, then that is also fine – it will be created for you).

Amazon S3 setup

Amazon S3 setup

The other question that sometimes arises is, “what permissions do I need to set on the Amazon S3 bucket (in the Amazon S3 console)?”

Firstly, if you are using your master S3 access and secret keys, then these have permission to do anything upon any bucket in your account. So you will not need to adjust any permissions to make these work. If you are not an advanced user, and do not wish to read about the most secure possible configurations, then you can stop reading now.

If, however, you have set up a different user with its own access and secret keys (which can be done using the Amazon AWS console’s “IAM” service), then you will need to make sure that that user has enough permissions.

Finding the Identity and Access Management (IAM) console in Amazon AWS

Finding the Identity and Access Management (IAM) console in Amazon AWS

Exactly what user policy is right for your use-case depends upon what that use-case is. However, if you have a user “myuser” and a bucket called “mybucket”, then the following policy is sufficient to give that user all the permissions that UpdraftPlus requires to access that bucket, and only that bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads"
      ],
      "Resource": "arn:aws:s3:::mybucket",
      "Condition": {}
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:GetObjectVersion",
        "s3:GetObjectVersionAcl",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:PutObjectAclVersion"
      ],
      "Resource": "arn:aws:s3:::mybucket/*",
      "Condition": {}
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*",
      "Condition": {}
    }
  ]
}

What is the most secure possible setup?

Since UpdraftPlus needs to store an S3 API key and secret to upload your backups to S3, there is a potential point of weakness. If a hacker breaks into your site, then he can steal that API key + secret, and use it to access your backups. Ideally, the hacker should not be able to delete or change your backups – you want to know that backups taken before hackers break-in are “clean” and can be deployed without fear.

To accomplish this with an Amazon S3 setup, implement these recommendations. They involve more complexity, but given the securest possible setup:

  1. Do not use your “master” API key + secret (which can access all your S3 data). Instead, set up a separate IAM user (which will thus have its own API key and secret). (Note – this is an IAM policy, not a bucket policy. You will need to switch back and forth in the Amazon AWS console between S3 to IAM a few times during these steps.)Switch service
  2. Set up a bucket from the Amazon S3 console (https://console.aws.amazon.com/s3/) for your UpdraftPlus backups, and only for these.Create bucketCreate bucket
  3. In the AWS console, bring up the bucket’s properties (either right-click on the bucket and choose “Properties” from the menu, or left-click and use the “Properties” button). Enable versioning. What is versioning? It means that if an attacker gains access to your bucket, and over-writes your backups (e.g. with a new, hacked version), then the previous versions still remain accessible. They are not deleted.Bucket propertiesEnable versioning
  4. Set up a policy for that IAM user, as above, but without the two delete permissions. i.e. Without these two lines:
            "s3:DeleteObject",
            "s3:DeleteObjectVersion",
  5. Finally, since UpdraftPlus cannot now delete historic backups, you will need to manage this another way (the “retain this many” setting in UD will take no effect). The easiest way to do this is to use S3’s built-in “life-cycle” feature, in the bucket properties (i.e. as in 3. above).

S3 lifecycle

S3 lifecycle rule

That’s it. What is the total effect of those changes? It means that UpdraftPlus is configured with Amazon S3 access credentials that can only write to the defined bucket, and no others. It cannot delete any existing backups. Its ability to write, however, still means that it can overwrite existing backups, which is effectively a way of deleting them, as well as tampering with them. Therefore, we add versioning in order to make sure that over-writing does not destroy existing backups.

The final part of this is that, 1) if restoring, you should retrieve your backup sets directly from the Amazon S3 console rather than from the UpdraftPlus dashboard’s built-in method 2) if you press the “Test S3 Settings” button, then it will create a test file, and report that it failed to be able to delete it. This is now expected, so do not worry about it.

 

 

 

 

 

Posted in: Amazon S3

twitterlinkedingoogle_plusFacebook