前提

• 常時起動しているLinux環境と、そこからrclone(いろいろなクラウドストレージへファイルを同期するコマンド)で日次バックアップを取っている状態
• バックアップ先はBackblaze B2(安価なオブジェクトストレージ。1GBあたり月$0.005前後)
• 構築の土台は自分の「サーバー」を持つとはどういうことか

何が問題だったか

心配していたのはランサムウェア(侵入したうえでファイルを暗号化し、戻す鍵と引き換えに金銭を要求する攻撃)のような、サーバーを乗っ取られるケース。

「B2側に30日間のバージョン保持(上書き・削除された古い版を30日間取っておく設定)があるから、仮に荒らされても戻せる」と考えていた。これが成立していなかった。

サーバーに置いていたB2のアプリケーションキー(APIから操作するための鍵。権限を選んで発行できる)の権限を一覧してみると、18個の権限が付いていた。問題はこの3つ。

• deleteFiles — ファイルの版そのものを完全削除できる
• writeBucketLifecycleRules — ライフサイクルルール(古い版をいつ消すかの設定)を書き換えられる。「0日で消す」に変えれば30日の保持は即座に無意味になる
• writeBucketReplications — 複製ルールを止められる

つまり鍵を1本盗られたら、バックアップ本体も、それを守るはずの設定も、まとめて壊せる。実際に同期スクリプトが使っていたのはlistBuckets, listFiles, readFiles, writeFiles, deleteFilesの5つだけで、残りは余分だった。

もう1つ、根本的な制約を自分に課した。「予備のハードウェアをもう1台持つ」案は採らない。将来は拠点を移して身軽に暮らしたいと思っているので、機械を持ち続ける前提の設計にはしたくなかった。ハードウェア不要・手作業ゼロで回る形に限定して考えた結果、3層構成になった。

層0: 鍵の権限を必要最小限にする

まずサーバー上の鍵を、実際に使う5権限ちょうどの新しい鍵に差し替えた。

ここで分かった制約: B2のWeb管理画面の鍵発行UIでは権限を細かく選べない。「読み書き」のような粗い単位しかないので、b2コマンド(Backblaze公式のCLI = コマンドライン操作ツール)が必須になる。全権限を持つマスター鍵を扱う作業なので、サーバー上ではなく手元のPCから実行した。

b2 account authorize
b2 key create --bucket <バケット名> <鍵の名前> \
  listBuckets,listFiles,readFiles,writeFiles,deleteFiles
b2 key list --long     # 権限が5つちょうどか確認
b2 key delete <旧鍵のID>

• b2 account authorizeとb2 key createの出力は、どこにも貼り付けない。鍵の本体(パスワード相当の文字列)が含まれる。自分はこの作業中にターミナルの出力をそのままAIチャットに貼ってしまい、鍵が会話ログに残った。同日中にマスター鍵の再発行と露出した鍵の削除で無効化したので実害はなかったが、確認はb2 key list --longで行うのが正しい(鍵のIDと権限しか出さず、本体は出ない)。
• 鍵の状態確認はWeb管理画面を信じない。削除済みの鍵が残って見えたり、新規作成した鍵が出てこなかったりした。b2 key listを正とする。

層0は次の層1とセット。層0をやらずに複製ルールだけ作っても、writeBucketReplicationsを持った鍵でルールごと止められてしまう。

層1: 削除が伝播しない複製先を作る

B2にはCloud Replicationという、バケット(ストレージ上のフォルダのような入れ物)の内容を別のバケットへ自動複製する機能がある。決定的な仕様はこれ。

削除と hideマーカー(B2が「削除された」印として置く目印)は複製されない。

つまり複製先は、構造的にappend-only(追加だけができて削除が伝わらない)なミラーになる。元のバケットでファイルが消されても、複製先には残り続ける。これがランサムウェア対策の本体になる。

同一アカウント内の別バケットへの複製で十分と判断した。理由は、サーバー上の鍵は元のバケットに限定されているので、別バケットには構造的に届かないから。別アカウントが必須になるのは「別リージョンへ複製する場合」だけで、同一アカウント・同一リージョンの別バケットへの複製は普通にできる。別アカウント構成と差が出るのは「B2のログイン自体を乗っ取られた場合」と「リージョン障害」の2つだけで、前者は後述の2段階認証のほうが本質的な対策になる。

複製元を読む鍵・複製先に書く鍵はB2が自動で2本発行し、どちらもB2の内部にしか存在しない(サーバー上に置かれない)。侵害経路にならないのがこの構成の強み。

複製先のライフサイクル設定でUIに落とし穴が2つあった。

• 🔴 「Keep only the last version」(最新の版だけ残す)を選んではいけない。上書き攻撃を受けた瞬間に正常な旧版が消え、複製先を用意した意味がなくなる。必ずUse custom lifecycle rulesを選ぶ。
• 🔴 Days Till Hideは必ず空にする。ここに数字を入れると、現役のバックアップ本体が自動削除される。埋めるのは「古い版を何日後に消すか」の1箇所だけ。

自分は古い版を180日で削除に設定した。毎晩上書きされるデータベースのダンプ(写真サーバー188MB + ファイルサーバー18MB + 認証サーバー13MB ≒ 日220MB)が積み上がって年80GB増える計算だったため。180日なら約40GBで頭打ちになる。保護が弱まるわけではない——削除は複製されないので消されたファイルには無関係で、上書き攻撃は次の層2が1週間以内に検知する。

複製元141.5GB・118,503ファイルに対して、複製先は149.0GB・118,976ファイルで完了。複製先のほうが大きいのは設計どおり(元で消えた・上書きされたファイルが残り続けるので膨らむ)。初回コピーは数日かかった。

• 初回コピーの進捗はAPIでは測れない。B2が複製の状態フラグを付けるのはルール作成後に新規アップロードされたファイルだけで、既存ファイルの後追いコピー分は全件「未設定」のまま。進捗はWeb管理画面の複製先バケットのファイル数で見るしかない。
• 初回コピー完了を待つ必要はない(層2の判定は「減った/増えていない」なのでコピー中に誤報は出ない)。ただしライフサイクル設定は初回コピー完了まで触らない——コピー中の変更は直後のファイルが消える危険があると公式ドキュメントに明記されている。
• コストは複製分で月$0.70。複製の転送料は無料。

層2: サーバーの外に見張りを置く

複製が本当に続いているかを誰も見ていなければ、仕組みは静かに壊れる。そこでデッドマンスイッチ(定期的な生存信号が途絶えたら警報を出す仕掛け)を用意した。

肝はサーバーの外で動かすこと。サーバー監視には別途Uptime Kumaを使っているが、これはサーバー自身の上で動いているので、サーバーごと死んだら自分の死を通報できない。

実装はGitHub上の非公開リポジトリ1つ + GitHub Actions(GitHubが提供する、決めた時刻やイベントでスクリプトを自動実行する仕組み)。週1回、複製先バケットを走査して、次のどれかに当たったらTelegramへ通報する。

1. ファイル件数が前回より減った
2. 合計サイズが前回比1%を超えて減った
3. 21日間まったく増えていない
4. B2へ接続・認証できない

観測値はリポジトリ内のJSONファイルにコミットして、次回の比較基準にする。外部ライブラリは使わず標準ライブラリだけでB2のAPIを直接叩く作りにした(依存が増えると、それ自体が壊れる原因になる)。見張り用の鍵は複製先バケット限定・読み取り専用なので、こちらはWeb画面の発行UIで作れる。

• 件数の減少は「複製先を直接触られた」ことのシグナルとして意味が強い(削除は複製されないので、正常運用では減らない)。
• 上書き破壊の検知は不完全だと正確に理解しておく。同サイズ・より大きいサイズで上書きされた場合は検知できない。ただしその場合も版管理で旧版が残るので復元は可能で、守りは版管理側が担っている。
• GitHub Actionsの定時実行は大幅に遅れる。0 1 * * 1(毎週月曜01:00 UTC)と書いたジョブが実際に走ったのは06:16 UTCで、5時間16分遅れだった。:00は最も混雑する分なので、奇数分(17 1 * * 1など)にずらすと改善する。週次監視なら遅延自体は無害だが、時刻を当てにした説明を書かないこと。
• 通報が空振りする状態で放置してはいけない。鍵をGitHubのSecrets(リポジトリに暗号化して保存する秘密情報)に登録する前に初回の定時実行が走り、認証情報が無くて失敗した。設計どおりの挙動だが、これを放置すると毎週失敗通知が来て、デッドマンスイッチの警報を無視する習慣がつく。それが一番の実害。

踏んだ落とし穴: 「鍵の差し替え」が設定ファイルを作り直していた

層0の鍵差し替えには、以前自分で書いたrotate-b2-key.shというスクリプトを使った。これがrcloneの設定ファイル(rclone.conf)を丸ごと作り直す作りになっていた。

同じ日の朝に、送信前に自前で暗号化するための設定ブロックをこのファイルに追加していた。スクリプトはそのブロックを知らないので、鍵の差し替え自体は成功したのに直後のバックアップが「設定ブロックが見つからない」で全滅した。

• 教訓: 構成に新しい設定ブロックを足したら、そのファイルを書き換える既存スクリプトを洗い出す。「鍵の差し替え」という名前から、設定ファイル全体を作り直しているとは読み取れなかった。
• スクリプトは、丸ごと上書きをやめて該当2行だけを置換する形に直した。加えて書き込む前に「設定ブロックが減っていないか」「新しい鍵IDが入ったか」を検査し、1つでも失敗したら一切書かずに中止するようにした。
• 🔴 もう1つの地雷: 設定ファイルはroot用と一般ユーザー用の2箇所にあり、復旧を片方だけやって放置していた。バックアップはrootで動くので「成功」と出続け、一般ユーザーで実行したときだけ静かに失敗する状態になっていた。
• 教訓: 「両方必要」と書いた手順は、実施後に必ず両方を実測で確認する。grep "^\[" <設定ファイル1> <設定ファイル2>のようにセクション名だけ出すコマンドなら値が漏れないので、安心して結果を見られる。
• おまけの罠として、ssh サーバー 'bash -s' <<'EOF'形式のヒアドキュメント(複数行のスクリプトを流し込む書き方)はsshの標準入力と競合して出力が二重化し、成功したのか失敗したのか読めなくなった。サーバー操作は1行のssh サーバー '...'に分解して1つずつ流すのが確実だった。

2段階認証が1段階だった

作業中にもっと基本的な穴が見つかった。「2段階認証は済んでいる(ログインのたびにメールでコードが来る)」と認識していたが、これはBackblazeが既定で有効にしているメールMFA(多要素認証)だった。

コードの送り先も、パスワードリセットの送り先も、同じメールアドレス。つまりメールボックス1つ取られると2要素が1要素に潰れる。同一アカウント構成を選んだ結果、このアカウントが全データの唯一のオフサイトコピーを持っているので、ここが設計上の最大の残留リスクだった。

TOTP(認証アプリが30秒ごとに生成する6桁コード方式)に切り替えて解消した。

• 認証アプリはEnte Auth のオフラインモード(アカウント登録なしで使える)を選んだ。Google Authenticatorは、自分がGoogleアカウントを削除する方針で同期が使えないこと、Google Playが載らない端末への移行を検討していることの2点で不適だった。アプリ登録が必要なものだと、復旧手段がまた別の会社のアカウントに依存して、断ち切った鎖を作り直すことになる。
• バックアップコードは必ず生成してパスワードマネージャーに保存する。ただしTOTPそのものは同じ金庫に入れない(同じ場所に入れたら1要素に戻る)。TOTPはスマートフォンのアプリに、バックアップコードはVaultwardenに置いた。

残る「鶏と卵」

この構成にも、原理的に閉じない循環が残っている。

• B2に入るには → TOTP(スマートフォン)
• スマートフォンを失くしたら → バックアップコード(Vaultwarden)
• VaultwardenはサーバーVPS上 → サーバーを失ったらB2から復元が必要 → B2に入る必要がある

スマートフォンとサーバーを同時に失うと詰む。対処は「バックアップコードを紙でもう1箇所持つ」しかない。これはパスワードの移行の記事で書いた、バックアップの取り出し鍵自体をどこに置くかという問題とまったく同じ構造になっている。自前で持つほど、最後の1本をどこに置くかという問題に必ず行き着く。

結果と、やらなかったこと

鍵の権限削減・append-onlyな複製先・サーバー外の見張りの3層が稼働状態になった。追加費用は複製分の月$0.70だけで、ハードウェアは1台も増えていない。

やらなかったことも書いておく。Backblazeというプロバイダ1社に依存しているのは未対策のまま。アカウントの凍結や会社都合に備えるなら、別会社のストレージへもう1本(追記専用の設定で月€4前後)が答えになるが、今回は見送った。手を広げる前に、今ある3層が本当に回り続けるかを数ヶ月見ておきたかった。

更新履歴 — 2026-10-01: 初版