Immutable Backupでランサムウェアを阻止：RcloneとS3 Object Lockの組み合わせ – ITFROMZERO

Table of Contents

バックアップまで暗号化された時：午前2時の恐怖のシナリオ

アラートが鳴り響く。私は飛び起き、ただのネットワーク障害であることを願いながらノートPCを開いた。しかし、本番サーバーでls -laを叩いた瞬間、心臓が止まりそうになった。すべてのデータベースダンプと設定ファイルの拡張子が.lockedに変わっていた。README.txtには、冷酷な身代金要求メッセージが記されていた。

最初にとった行動はバックアップディレクトリの確認だった。その時、致命的なミスに気づいた。バックアップはサーバーに直接マウントされたNFSドライブに保存されていたのだ。root権限を奪取したハッカーは、メインデータを暗号化する前にrm -rfを実行し、すべてのバックアップを消去していた。500GBの顧客データが一瞬にして消え去った。

教訓はシンプルだ：アクセス可能な（書き換え可能な）バックアップは、必ず削除される。 ランサムウェアを生き延びるには、Immutable Backups（不変バックアップ） — つまり、変更も削除もできないバックアップが必要だ。

従来のバックアップ手法が「敗北」する理由

多くのITエンジニアは、依然としてrsyncやrcloneのスクリプトを使ってサブサーバーにデータを転送する習慣を続けている。この方法には2つの大きな脆弱性がある：

過剰な権限： スクリプトが削除（Delete）権限を持つAccess Keyを保持している。ハッカーがこのキーを入手すれば、数コマンドでクラウドストレージを空にできる。
上書きメカニズム： ランサムウェアが元のファイルを暗号化すると、バックアップスクリプトは律儀にその破損したファイルをアップロードし、最新のクリーンなバックアップを上書きしてしまう。

我々には、ルート管理者やAccess Keyの所有者でさえ、一定期間データを削除できない仕組みが必要だ。そこでS3 Object Lockの出番となる。

解決策：RcloneとS3 Object Lock（コンプライアンスモード）

S3 Object Lockは、AWS、Wasabi、MinIOなどのプラットフォームにある機能で、WORM（Write Once, Read Many）モデルで動作する。区別すべき2つのモードがある：

Governance Mode（ガバナンスモード）： 特別な権限（バイパス権限）を持つユーザーはファイルを削除できる。巧妙なハッカーならこれを悪用する可能性がある。
Compliance Mode（コンプライアンスモード）： 保存期間（Retention Period）が終了するまで、クラウドプロバイダーのルートアカウントを含め、絶対に誰も削除できない。これが最も強固な「盾」となる。

ステップ1：Object Lock対応のS3バケットを作成する

バケット作成時にObject Lock機能を有効にする必要がある。ほとんどのプロバイダーでは、既存のデータがあるバケットに対して後からこの機能を有効にすることはできない点に注意が必要だ。

アカウントのセキュリティについては、パスワードジェネレーターなどのツールを使用して、強力なコンソールパスワードを作成すること。バックアップスクリプトにIAM権限を割り当てる際は、s3:PutObject、s3:GetObject、そして最も重要なs3:PutObjectRetentionのみを付与する。s3:DeleteObject権限は絶対に付与しないこと。

ステップ2：Rcloneのインストール

Rcloneは、現在Linuxで最も強力なクラウドストレージ管理ツールだ。インストールはわずか10秒で完了する：

curl https://rclone.org/install.sh | sudo bash

rclone configを実行して、新しいリモート（例：s3-storage）を作成する。前のステップで作成したAccess KeyとSecret Keyをここに貼り付ける。

ステップ3：不変バックアップの実行

syncコマンドの代わりに、データロックパラメータを付けたcopyコマンドを使用する。例えば、/data/db_dumpsディレクトリをバックアップし、30日間ロックしたい場合は以下のようになる：

rclone copy /data/db_dumps s3-storage:my-backup-bucket \
    --s3-object-lock-mode COMPLIANCE \
    --s3-object-lock-retention-days 30 \
    -P

--s3-object-lock-mode COMPLIANCEパラメータは、最も厳格なロックモードを有効にする。30日間、このファイルは「不可侵」となる。

ステップ4：ハッカーになりきってテストする

システムを確認するために、アップロードしたばかりのファイルを削除してみよう：

rclone delete s3-storage:my-backup-bucket/backup_file.sql

画面にAccess DeniedやObject is under active retentionというエラーが表示されれば成功だ。これでデータは外部からのあらゆる削除の試みに対して安全になった。

無駄な出費を避けるための実戦経験

Immutable Backupは非常に強力だが、設定を誤ると金銭的な代償を払うことになる：

保存期間（Retention）の検討： 本当に必要でない限り、あまりに長いロック期間（例：1年）を設定しないこと。コンプライアンスモードで一度ロックすると、期間を短縮することはできず、最終日まで保存料金を支払う必要がある。
バージョニングの使用は必須： Object Lockにはバケットのバージョニングが有効であることが求められる。古いファイルを上書きするたびに新しいバージョンが作成され、両方に料金が発生する。管理しやすいように、ファイル名にタイムスタンプ（例：db-2023-11-01.sql）を含めるようにしよう。
ストレージコスト： 古いデータを削除できないため、バケットの容量は増え続ける。データセットが1TBを超える場合は、予算を慎重に計算すること。

ランサムウェア対策は、ソフトウェアをインストールして終わりではない。厳格なプロセスと適切なテクノロジーの組み合わせだ。Immutable Backupがあれば、万が一サーバーが攻撃を受けても、少なくとも「逃げ道」があることが分かっているため、枕を高くして眠ることができる。