オンプレ NAS と AWS S3 でランサムウェア対策｜3-2-1-1-0 の構成例

はじめに

ランサムウェア対策のバックアップは、「速く戻せること」と「攻撃者にも消せないこと」を同時に満たす必要があります。この 2 つは別々の層で担うのが現実的で、ローカルの NAS が前者を、クラウドの不変ストレージが後者を受け持ちます。本記事では、オンプレ NAS と AWS S3 を組み合わせて 3-2-1-1-0 を満たす構成例を、役割分担と AWS 連携を主軸に解説します。

各製品の設定手順そのものは個別記事に譲り、ここでは「どう組み合わせ、どこに注意して運用するか」に焦点を当てます。前提となる考え方は『ファイルサーバーのランサムウェア対策｜不変バックアップ設計の基礎』を、全体像は『ランサムウェア対策の基本と全体像｜3-2-1-1-0 で守るバックアップ設計』をあわせて参照してください。

結論を先に述べると、ローカルの NAS で即時復旧（短い RPO）を、S3 の Object Lock で「消せない」オフサイトコピーを担うのが基本形です。ただし、NAS のバックアップソフトを Object Lock バケットへ直接向けると保持の整合で詰まりやすいため、後述する「複製先で不変化する」設計を取り入れると堅牢になります。

全体構成: 3-2-1-1-0 をどう満たすか

まず、全体像を 3-2-1-1-0 に対応づけて整理します。

各層の役割（本番 / NAS ローカル / S3 オフサイト不変）

• 本番データ: クライアントやサーバーが日常的に読み書きするファイルサーバーの実体
• NAS ローカル層: 共有フォルダの不変スナップショットや WORM で、暗号化・誤削除からの即時復旧を担う。
• S3 オフサイト層: Object Lock により、管理者でも消せない不変コピーを別ロケーションに保持する。

この 3 層で、3 つのコピー（本番・NAS・S3）、2 種類のメディア（ローカルディスクとオブジェクトストレージ）、1 つのオフサイト（S3）、1 つの不変 / オフライン相当（S3 Object Lock）、そして 0（復旧テスト）が満たせます。

データフロー（本番 → NAS → S3）

データは、本番から NAS へバックアップ・スナップショットされ、さらに NAS から S3 へ転送されてオフサイト化されます。NAS 側は復旧の速さ、S3 側は最後の砦という役割分担です。

ローカル層: NAS のスナップショットと WORM

ローカル層の狙いは、復旧の速さと短い RPO です。NAS 上のスナップショットは時点復旧が速く、ファイル単位での巻き戻しも容易です。さらに不変スナップショットや WORM を併用すると、管理アカウントが侵害されてもローカルの復旧ポイントを保護できます。

ここで重要なのは、ローカルのスナップショットは同じ筐体にある以上、オフサイト要件は満たさないという点です。あくまで「速い復旧」を担う層と位置づけ、オフサイトは次のクラウド層に委ねます。NAS 側の具体的な設定は、関連記事『Synology・QNAP の不変スナップショット｜NAS のランサムウェア対策の手順』を参照してください。

クラウド層: S3 Object Lock で不変オフサイト

クラウド層の狙いは、攻撃者にも消せないオフサイトコピーです。これを担うのが S3 Object Lock です。

参考: AWS「Amazon S3 Object Lock」
“S3 Object Lock blocks permanent object deletion during a customer-defined retention period”
（S3 Object Lock は、利用者が定めた保持期間中、オブジェクトの完全削除を防ぐ）
https://aws.amazon.com/s3/features/object-lock

NAS から S3 へのバックアップと注意点

NAS から S3 への転送には、Synology の Hyper Backup や Cloud Sync、QNAP の Hybrid Backup Sync などが使えます。ただし、ここに実務上の落とし穴があります。Hyper Backup などのバックアップソフトを Object Lock 有効バケットへ直接向けると、保持期間後に古い世代を削除できず、バックアップ容量とコストが膨張し続けることがあります。これはソフト側のローテーションと Object Lock の不変性が噛み合わないために起きるもので、ツールによっては Object Lock 運用が想定されていません。

このため、設計時は次のいずれかを検討することをおすすめします。

• 採用するバックアップソフトが Object Lock の保持・ローテーションに対応しているかを事前に確認し、対応しない場合は Object Lock を使わない構成（バージョニング ＋ ライフサイクルでの世代管理）にとどめる。
• 後述のレプリケーションを使い、NAS が書き込むバケットは通常運用とし、別バケット側で不変化する。

Object Lock を活かす AWS 連携

AWS 連携の利点を活かすと、上記の課題を回避しつつ不変性を確保できます。おすすめは、NAS が書き込む「作業用バケット」と、不変化する「保管用バケット」を分け、S3 レプリケーションで保管用へ複製し、保管用バケットだけを Object Lock で保護する設計です。これにより、NAS 側ソフトのローテーションを妨げずに、消せないオフサイトコピーを別に持てます。保管用バケットを別の AWS アカウントに置くと、本番側が侵害されても影響が及びにくくなります。

あわせて、IAM の最小権限、MFA Delete、バケットポリシーによるガードレール、CloudTrail での監査を組み合わせると、多層防御になります。これらの設定手順は、関連記事『AWS S3 Object Lock でランサムウェア対策｜設定手順と注意点』で詳しく解説しています。

RPO・RTO とコストの考え方

構成を決める際は、復旧シナリオとコストを具体的に見積もると判断しやすくなります。

復旧シナリオ別の動き

• 直近のファイルを誤って暗号化・削除した場合: NAS のスナップショットから即時に復元できます（短い RTO）。
• NAS 自体が侵害・破壊された場合: S3 の不変コピーから復元します。データ量と回線によっては時間がかかるため、RTO は NAS 復旧より長くなります。

コスト（ストレージ・egress・復元）

S3 はストレージ容量・リクエスト・データ転送（egress）に対して課金されます。古い世代はライフサイクルで Glacier 系の安価なクラスへ移行すると、保管コストを抑えられます。注意点として、Object Lock を Compliance モード ＋ 長期保持にすると、保持期間中はオブジェクトを削除できず、その分の保管料金が発生し続けます。検証や初期は Governance モード ＋ 短い保持で挙動とコストを確認することをおすすめします。大規模な復元では egress 費用もかかるため、コストを重視する場合は egress 無料の Wasabi を使う『オンプレ NAS と Wasabi でランサムウェア対策｜低コストな 3-2-1-1-0 構成例』も比較対象になります。

運用と多層防御の補強

最後に、構成を安全に保つための運用面を補強します。

認証情報・権限の分離

NAS の管理系と、S3（特に保管用バケット）の操作権限を分け、可能であれば保管用は別 AWS アカウントに置きます。本番が侵害されても、不変コピーへ手が届きにくくなります。

監視・通知

CloudTrail で S3 の操作を記録し、NAS 側のスナップショット失敗やストレージ異常の通知も有効にしておきます。

復旧テスト（「0」）

定期的に NAS と S3 の双方から実際に復元できることを確認します。取得できていても復元できなければ意味がないため、ここまでを運用に含めると安心です。

まとめ

オンプレ NAS と AWS S3 の組み合わせは、ローカルの即時復旧とクラウドの不変オフサイトを役割分担できる、現実的なランサムウェア対策の構成です。鍵は、NAS 側ソフトのローテーションと Object Lock の整合に注意し、レプリケーションで複製先を不変化する設計にある点です。

• ローカルの NAS が即時復旧と短い RPO を担う。
• S3 Object Lock が消せないオフサイトコピーを担う。
• バックアップソフトの Object Lock 直書きは保持の整合に注意
• 複製先を Object Lock で不変化する設計が堅牢
• 保管用バケットは別アカウント・最小権限で分離する。
• コストはライフサイクルと保持モードの設計で抑える。
• NAS と S3 の双方で復旧テストを定期的に行う。

以上、最後までお読みいただきありがとうございました。