WordPressでS3に自動バックアップ（＋最小権限運用）

2024年3月4日

UpdraftPlus
BackWPup

Amazon S3は高耐久、かつ、安価なオンラインストレージサービスとして使用できます。
手動アップロードのほか、アクセスキーを発行することで外部のプログラムからファイルをアップロードすることが可能です。

WordPressのプラグインを使ったバックアップでは、バックアップ用のストレージとしてよく使われます。
S3に自動バックアップ可能で、かつメジャーなプラグインが最初の2つです。
※All-in-One WP Migrationは自動バックアップ不可（有料版は可能）です

どちらを使うかは完全に好みです。
私は処理負荷を調整できるBackWPupの方を使っていますが、おすすめするのはUpdraftPlusです。（BackWPupより人気で復元が簡単にできるので）

IAMポリシーのJSON

恐らく多くの方が最も迷う設定箇所と思われるので、いきなり紹介します。

UpdraftPlus

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads"
      ],
      "Resource": "arn:aws:s3:::【バケット名】",
      "Condition": {}
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:GetObjectVersion",
        "s3:GetObjectVersionAcl",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:PutObjectVersionAcl"
      ],
      "Resource": "arn:aws:s3:::【バケット名】/*",
      "Condition": {}
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*",
      "Condition": {}
    }
  ]
}

引用元はUpdraftPlusの公式サイトのマニュアルです。

公式で案内してくれるのはとてもありがたいです。
私はBackWPupを使っているものの、こういうところでもUpdraftPlusの方に好感が持てます。

最小権限にする

マニュアルを一読すれば分かりますが、実は下記の2つの権限については必要ありません。

"s3:DeleteObject",
"s3:DeleteObjectVersion",

では何のためにこの権限を定義しているかというと、UpdraftPlusが過去のバックアップを削除できるようにするためです。
バックアップというものは取得し続けると際限なく容量がかさむため、通常は過去数件分（もしくは数か月分）だけ残す、という運用が一般的です。

過去分のバックアップを消さなかったがためにサーバーの容量をパンクさせてしまい、サーバーが停止するという本末転倒な事態に陥ることがありますね。
AWS（外部ストレージ）にバックアップするならその心配はありませんが、S3の容量が増え続けることでストレージ料金が増え、不要な支払いが増えてしまうという別な心配があります。

ですが、実はこの権限を付与することがセキュリティリスクに繋がります。
なぜなら、WordPressやサーバーが悪意のある第三者に乗っ取られた場合、過去分のバックアップを消すことができてしまうからです。

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.
https://updraftplus.com/faqs/what-settings-should-i-use-for-amazon-s3-and-how-should-i-configure-my-amazon-s3-account/

もちろんこれについてもマニュアルに記載されており、どう対処すればよいかまで記載されています。

「UpdraftPlusが過去のバックアップを消せる」ということは、「WordPressが乗っ取られた場合、UpdraftPlusを好き放題操作できるから第三者が過去のバックアップを消せる」ことになるのは容易に想像できますよね。
そういうことです。

"s3:DeleteObject",
"s3:DeleteObjectVersion",

最小権限にする方法は、この2つの権限をIAMポリシーの記述から削除し、S3側にライフサイクルルールを追加することです。
UpdraftPlusから削除権限を取り上げつつ、S3側で定期的に過去のファイルを削除する設定を加えることでより安全にできます。
なおこの場合、UpdraftPlusに設定した削除に関する設定は無効になります。

設定の工程が増えて運用も少し難しくなるので、ここら辺は手間との相談ですね。
最小権限の原則に従うなら必要な設定です。

BackWPup

UpdraftPlusのように公式サイトの記述が見つからなかったので、ユーザーメイドです。
公式ドキュメントはあるのですが、執筆時点でS3については記載がありません。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:GetBucketAcl",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": "arn:aws:s3:::【バケット名】"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:ListMultipartUploadParts",
                "s3:AbortMultipartUpload",
                "s3:DeleteObject",
                "s3:DeleteObjectVersion"
            ],
            "Resource": "arn:aws:s3:::【バケット名】/*"
        }
    ]
}

※参考 https://www.andrewgorton.uk/blog/backwpup-to-s3-iam-policy/

簡素な運用にするため、引用元に対して「s3:DeleteObject」と「s3:DeleteObjectVersion」を独自に追加していますが、UpdraftPlus同様に最小権限の原則的によろしくないので、削除する方が好ましいです。
そのまま削除しただけでは上手く動作しないので、前述のUpdraftPlusと同じ設定をする必要があります。

IAMポリシーについて

一応補足です。

AWSのサービスは権限の扱いが少々複雑で、例えばWordPressのプラグインからS3にアップロードするには、AWS側でS3にアクセスできる認証用のアクセスキーを発行する必要があります。

意図しているならばいいのですが、発行したアクセスキーによく分からないままAmazonS3FullAccessなどの権限を割り当てるのは危険です。

実用上の問題は発生しませんが、もしアクセスキーが外部に漏れてしまった場合、AmazonS3FullAccessの権限があればS3上の全てのファイルを改変・削除できる上、勝手にアップロードし放題です。

S3に限らずAWSのアクセスキーは取り扱い注意で、DevelopersIOも警鐘を鳴らしています。
※AWS関連の総合支援サービスを提供するクラスメソッド社が運営している技術ブログです

[AWS利用者必読] アクセスキー漏洩...

[AWS利用者必読] アクセスキー漏洩による不正利用について | DevelopersIO

世の中にはアクセスキー収集botというものが存在し、GitHubの公開リポジトリに誤ってアクセスキー情報をアップロードすると数分以内に悪用されるというのは有名な話です。
（余談ですが、AWS自身もbotを動かしていてGitHubで野ざらしのアクセスキーを見つけるとメールで通知してくれる機能があります）

権限はAmazonS3FullAccessに限らず星の数ほどあり、AWSではIAMポリシーと呼ばれています。
できれば、IAMポリシーは必要最小限の権限で済ませたいところです。

バックアップ設定方法（主にAWS側）

簡単にバックアップ設定方法を紹介します。
（S3側にライフサイクルルールを設定しない簡易的な方法です）

1. S3バケット作成

まずはS3バケットを作成します。
UpdraftPlusとBackWPupで共通です。

バケット作成時に設定が表示されますが、すべてデフォルトで大丈夫です。
（過去には自分で設定しないとバケットが暗号化されなかったりしましたが、今はデフォルトで暗号化してくれます）

今回はバケットの中に「backup」フォルダを作成し、そこにバックアップを格納する運用とします。

S3バケット内のbackupフォルダ — 自分で作成しなくても自動で作成してくれたような気はしますが、念のため。

2. IAMポリシーの作成とアタッチ

バックアップに必要なIAMポリシーを作成します。

ポリシーの作成画面に行くと「ビジュアルエディタ」「JSON」があるので、「JSON」を選びます。
記述内容は前述したJSONを参考にして記述してください。

私は「Backup-WordPress-to-S3」という名前でポリシーを作成しました。

作成が終わったら、既存のIAMユーザーにポリシーをアタッチします。
※このとき、ポリシーをアタッチするIAMユーザーはバックアップ専用のユーザー（コンソールログインすらも不可能なユーザー）にした方が好ましいです。WordPressからS3に対するバックアップ以外の操作を行えないIAMユーザーであった方が権限が狭まるからです
※AWSは作成したIAMポリシーを内包したIAMロールを作ってそれをIAMユーザーに割り当てることを推奨していますが、今回は飛ばしています