WordPress を 50 サイト以上扱う現場では、ツール側に保存される認証情報の量が一気に増えます。各サイトの管理者パスワード、SSH 接続情報とパスフレーズ、SMTP の送信パスワード、サーバープロファイル ── これらをまとめてバックアップして、別の PC で復元できるようにしたい、というのは保守を続けていると必ず出てくる要望です。
WP Maintenance Manager にもこのバックアップ・復元機能を載せていますが、その実装過程で、「動くバックアップ」と「持ち運べるバックアップ」は別物だと痛感する場面がありました。本記事では、認証情報をクロスマシンで安全に運ぶための設計上の判断と、私たちが採った方式を共有します。
1. なぜ認証情報バックアップが必要か
少数のサイトを担当しているうちは、サーバーごとにパスワード管理ソフト（1Password、Bitwarden 等）を使うだけで足りる場合が多いです。ところが扱うサイト数が二桁を超えると、別の事情が出てきます。
- メンテナンスの自動化を組み込みたい: ツール側で SSH 接続して
wpコマンドを実行する以上、ツールに認証情報を持たせる必要がある - PC を買い替えたとき、まとめて新 PC に引き継ぎたい: 50 サイト分を 1 つずつ手で再入力するのは現実的ではない
- 証跡を残すため: いつどのサイトをどのアカウントで作業したかをツール内で一元管理し、レポートに反映したい
これらをまかなうために、ツール側のローカルストレージに認証情報を保管するという選択になります。そして、保管した以上は PC 故障・買い替え・OS 移行のいずれかが起きても復元できる 状態を担保しなければなりません。
2. 認証情報をどう保管するか
ローカルに認証情報を持つ以上、平文で保存するのは論外です。最低限の防御として、暗号化キーで認証情報を暗号化し、ツール起動時にだけ復号して使う形になります。
WP Maintenance Manager では Python の cryptography ライブラリの Fernet（対称鍵暗号）を使い、ユーザーのホームディレクトリ直下にキーファイル（~/.wp_maint_pro_key）を置く設計にしています。各認証情報は ENC:gAAAAABoT... のような形で保存され、外から見ても意味不明な文字列としか映りません。
ここで重要なのが、この暗号化キーをマシンごとに別物にするという判断です。
| 項目 | マシン共通キー | マシン固有キー（採用） | |—|—|—| | 設定ファイル流出時の影響 | キーも一緒に流出すれば即時に復号可 | キー単体ではどのマシンの認証情報も復号できない | | クラウド経由バックアップの安全性 | キーが漏れたら詰み | 単独流出ではほぼ無害 | | 移行のしやすさ | バックアップを別 PC に置けば即動く | そのままでは別 PC で復号できない |
セキュリティ観点ではマシン固有キーの方が圧倒的に堅牢です。バックアップ ZIP が万が一クラウド同期や USB 経由で流出したとしても、キーファイルが攻撃者の手元にない限り中身は復号できません。
ただ、この選択は次のセクションで説明する クロスマシン復元の落とし穴 をセットで運んできます。
3. 落とし穴：マシン固有キー × バックアップ ZIP
最初に作ったバックアップ機能の挙動はこうでした。
1. ユーザーが「バックアップを書き出す」を選ぶ 2. ツールが sites_*.json、server_profiles.json、settings.json 等を ZIP に詰めて保存 3. ZIP の中には 暗号化済みのまま の ENC:... 文字列が入っている
同じ Mac で復元する分には何の問題も起きません。キーが同じなので復号できる。ところが Mac で取った ZIP を Windows で復元しようとすると、症状はこうなります。
- 復元処理自体は 成功 する（ZIP は正しく展開され、ファイル配置も正常）
- サイト一覧も普通に表示される
- だがいざメンテナンスを実行すると SSH 接続が全部失敗
- メール通知の SMTP 認証も 全部エラー
- WordPress 管理画面ログインも パスワード不一致
復号が黙って失敗した結果、「使い物にならない認証情報」が並んでいる状態です。バックアップファイルそのものは正常で、復元ロジックも正常に動作している。それなのに使えない、という最も判別が難しいタイプの故障です。
4. 設計のトレードオフ
ここで取れる選択肢は 3 つでした。
A案：マシン共通キーに切り替える
最も単純な解決策ですが、キーを共通にすると バックアップファイル × キーファイル が両方流出した時点で詰む構造になります。クラウド同期でやらかしやすいパターンなので、この案は採用見送り。
B案：暗号化のまま運んで、復元先で「あとから」復号
現実的に不可能。マシン固有キーで暗号化された文字列を、別マシンのキーで復号する手段はそもそも存在しません。
C案：書き出し時に復号 → ZIP に短時間だけ平文 → 復元先で再暗号化（採用）
以下の流れで運用します。
書き出し時:
Mac のキーで復号 → 平文の認証情報 → ZIP に格納
復元時:
ZIP を展開 → 平文の認証情報 → Windows のキーで再暗号化 → 通常の保存形式ZIP ファイルの中身は 「ユーザー自身の手元にある間だけ」 平文相当になります。
「平文で運ぶのは怖い」という反応は当然出ます。私たち自身、これに行き着くまでに散々検討しました。決め手になった観点は以下です。
- ZIP はユーザーが自分の PC で管理する成果物 であって、サーバー間転送やクラウド共有を前提にした成果物ではない
- ユーザーは ZIP を 暗号化ストレージや外付け SSD、PGP 等で追加保護することを選択できる
- 「クラウド同期で勝手に上がってしまう」リスクを語るなら、それは ZIP の置き場所を選ぶ運用ルール の話
- 一方、復号できないバックアップ という被害は、ユーザーが取れる対策が「やり直す」しかなく、もっと深刻
要は 「セキュリティの責任分界点を、ZIP の管理者であるユーザーに渡す」 という設計判断です。これは妥協ではなく、認証情報のような取り扱いが繊細なデータについて、ユーザーが自分でコントロールできる場所に責任を置くという原則の適用にあたります。
補足: 平文でいる時間の最小化
上記方式でも、バックアップ ZIP を作成して別 PC で復元するまでの間、認証情報は平文相当の形で ZIP の中に存在します。これを小さくするための運用ルールとして、私たちは以下をユーザーマニュアルに明記しています。
– バックアップ ZIP は移行作業の直前に作成する
– 復元が完了したら ZIP を削除する
– 長期保管が必要な場合は ZIP 自体を別の暗号化レイヤー（OS のディスク暗号化・暗号化 ZIP・PGP 等）でくるむ
5. 副次的に見つかった問題：絶対パスの罠
復号方式の修正と並行で、もう一つの落とし穴が見つかりました。
レポート機能で使うロゴ画像のパスが /Users/<username>/Documents/logo.png のような 絶対パス で settings.json に保存されていたのです。Mac で設定したこのパスを Windows で読もうとしても、当然そんなディレクトリは存在しません。同じ Windows 同士でも、ユーザー名が違えば破綻します。
対処はシンプルで、復元先のマシンに該当ファイルが存在しない場合は その項目だけ空欄に置き換える 処理を追加しました。ロゴ画像は手動で再選択する必要が出ますが、それ以外の認証情報・設定は引き継げます。
教訓: 設定ファイルにファイルパスを保存する場合、絶対パスではなく、復元先で意味を持つ相対パスや識別子に置き換えるか、復元時に該当が無ければ無視するフォールバックを最初から組んでおく。これは認証情報の話とは別軸ですが、クロスマシン要件では同じくらい重要です。
6. 設計から運用までで見えた原則
このバックアップ機能を作り直す過程で、保守ツールを設計するうえでの原則がいくつか整理できました。
原則 1：暗号化は「保存」と「移行」の両方を一度に設計する
暗号化を入れるとき、ローカル保存だけを考えると失敗します。バックアップ・PC 移行・OS 入替のシナリオを最初から並べて、どれが暗号化境界をまたぐのかを把握してから方式を決める必要があります。
原則 2：セキュリティの責任分界点を明示する
「どこまでをツールが守り、どこからはユーザーが守るか」を ドキュメント上で明示 する。これが曖昧だと、ユーザーは過剰に安心したり、逆に過剰に不安になったりします。
原則 3：「動く」と「持ち運べる」は別の品質
機能テストでは正常動作したはずのバックアップが、別 PC では機能しない ── という事故を防ぐには、設計段階でクロスマシンを前提に置いた検証 が要ります。同じマシンで取って同じマシンで戻すテストでは絶対に発見できません。
7. WP Maintenance Manager ではどう運用しているか
現在のバックアップ機能は、上記の C 案（書き出し時に復号、復元時に再暗号化）と、絶対パス対策のフォールバックを実装した状態で配布しています。
- バックアップは GUI から数クリックで生成
- 復元時には自動的に新マシンのキーで再暗号化される
- ロゴ等の絶対パス参照が無効になった場合は空欄でロード
- マシン固有キー設計は維持（バックアップ ZIP 単体ではセキュアな状態のまま）
WordPress 保守の現場では、PC 入替・OS 移行・別スタッフへの引継ぎといった事象が日常的に発生します。「保守ツール自体の保守性」 をどう担保するかは、保守そのものの品質に直結する課題です。
まとめ
- 認証情報のローカル保管では、マシン固有キーで暗号化するのが安全性として正解
- ただし マシン固有キー × そのままのバックアップ は別マシンで復号できない
- 解決は 書き出し時に復号、読み込み時に再暗号化 という方式
- 平文化される時間と場所が最小化されるよう、運用ルールをセットで提供する
- ファイルパスの絶対指定など、副次的なクロスマシン破綻も同時に潰す
WP Maintenance Manager は WordPress 保守の現場で必要な「複数サイト × 認証情報 × 自動更新 × 証跡」を一括で扱うために設計しています。バックアップ・PC 移行を含めた運用ライフサイクルまで踏み込んで作り込んでいるのは、保守の品質はツールの保守性で決まる、という前提に立っているためです。詳細は 公式サイト と ご利用ガイド をご覧ください。