Amazon Web Services ブログ

【寄稿】そのデータ復旧できますか？

この投稿はネットアップ合同会社 瀧山 毅 氏、松田 紘典 氏にサイバーレジリエンスにおけるデータリストアの解説と AWS における実装ポイントについて寄稿いただいたものです。

同シリーズの第 1 回「サイバーレジリエンスとはなにか？」、第 2 回「Amazon FSx for NetApp ONTAP イミュータブルバックアップの利用でランサムウェア対策の強化」も併せてご覧ください。

こちらは、サイバーレジリエンスブログシリーズの第 3 回です。今回まで組織にとって重要な資産「データ」の観点から、サイバーレジリエンスの基本を解説してきました。
シリーズの最終回となる今回は、「バックアップとリストアの重要性」と「ランサムウェア被害を想定したリストアシナリオ」についてご紹介します。

今取得しているバックアップ大丈夫ですか？

ランサムウェアの被害が年々拡大および複雑化する中、バックアップの取得はランサムウェア対策の手段の 1 つとして現在多くの人に認知されています。NetApp はデータを蓄積・保護するストレージを扱う企業としてバックアップの重要性を理解しているため、たびたび  ”今取得しているバックアップ大丈夫ですか？” とお客様に聞くことがあります。その中で ”うちは問題なく取得できているはず” 、”どこどこのバックアップソフトを使用しているので大丈夫” という風に回答いただくことがありました。
併せて取得したバックアップのリストア実績について尋ねると ”ファイルレベルではあるけど、大規模な形での復元はない” 、”バックアップ成功しているってログがあるから特に気にしていない” という回答も少なからず聞く機会がありました。このようなコメントをいただいた中、今取得しているバックアップが有事の際に本当に使えると胸を張って言える企業が何社いるのだろうかという疑問を感じることがあります。

実際に警察庁が広報資料としてまとめている ”令和５年におけるサイバー空間をめぐる脅威の情勢等について” にてランサムウェア被害企業・団体のバックアップ取得・活動状況がレポートされており、バックアップ取得の有無に関しては有効回答数 140 件中 ８ 件 (6%) が取得していない状況で、リストアに関しては 126 件中被害直前の水準まで復元できた企業・団体が 21 件 (17％) のみで 105 件 (83％) の企業・団体が被害直前の水準まで復元できなかったという結果になっています。

図 1: バックアップの取得・活用状況 *1

(*1) 警視庁Webサイト,“令和５年におけるサイバー空間をめぐる脅威の情勢等について”, https://www.npa.go.jp/publications/statistics/cybersecurity/data/R5/R05_cyber_jousei.pdf, (2024/08/20 閲覧)

レポートのようにファイルが元の水準で復元できず、そのためシステムや業務を長期間停止せざるを得ない事態になった場合、後日多くの労力とお金を費やしてシステムの改善等する必要に迫られると推測されます。このようなことを避けるため一度バックアップに求められる要素について考えてみたいと思います。

バックアップに求められる要素って何だろうか？

よく情報セキュリティで聞かれる項目として機密性 (Confidentiality)、完全性 (Integrity)、可用性  (Availability) がありますが、バックアップをこの項目に当てはめてざっくりと考えると以下のような内容になると考えています。

  • 機密性:バックアップデータの改ざん/削除防止がされていること
  • 完全性:データを完全な状態に復元可能な状態であること
  • 可用性:どこから／どこにでも復元可能な状態であること

上記の項目を考慮して具体的にランサムウェア対策としてのバックアップに必要な要素としては以下のようなことが挙げられると思います。

  1. RPO を顧慮した細かいバックアップの取得（可用性）
  2. 3-2-1 ルールを考慮したバックアップ（可用性）
  3. バックアップデータの保護/改ざん防止対策（機密性）
  4. 業務可能な状態でのデータ復旧のためのプロセス策定（完全性）

可用性と機密性に関してはバックアップの方式や取得方法のため、バックアップ取得後の完全性を考慮したデータ復旧にフォーカスしたお話をしたいと思います。完全性を考慮したバックアップを実施するということは “バックアップ成功しました。はい、終わり。” ではなく、取得したバックアップデータが業務に耐えうる水準でリストアできるかを確認するまでを実施することが理想であり、ランサムウェア攻撃等の有事に備えた有効な復旧プロセスの確立も含めて考慮する必要があります。ただし確認のため策定した復旧プロセスを経てリストアテストを実施するということになると、システムの規模によりますがリストアのためのストレージの空き容量や既存システムへの影響度合いも考慮する必要があるため簡単且つ定期的に実施できないというのが現状となります。

前置きは長くなりましたが、実は Amazon FSx for NetApp ONTAP (以降 FSx for ONTAP と記載します) 環境ですと簡単に復旧プロセスを含めたリストアテストが実施できます。
※もちろんオンプレミスの ONTAP も同様に可能です。

次に FSx for ONTAP 環境でどのようにして簡単にリストアテストが実行できるか理由を記載します。

なぜ Amazon FSx for NetApp ONTAP ではリストアが簡単なのか

サービス利用者が FSx for ONTAP に保管したデータについて、NetApp ONTAP のファイルシステム内では、データの保存場所を示すポインタ情報とデータブロックに分けて管理しています。Snapshot 作成を実行すると、前回作成した Snapshot とポインタ情報を比較し、ポインタ情報の更新部分を Snapshot 差分量として扱うことで、データブロックを動かさず Snapshot を作成することができます。この動作はリストアを行う際にも利用しており、データブロックを動かさないためバックアップデータを高速にリストアやクローンすることが可能となっています。
一般的なリストアテストでは、Snapshot をテスト領域にリストアしファイルが復旧するか確認するかと思います。リストアテストしたいデータが例えば 100TB 存在する場合、どのような影響が考えられるでしょうか。100TB をコピーする時間やコピー中ストレージにかかる負荷が本番サービスに影響を与えないか確認する必要があり、データ量が多ければ多いほどリストアテストを実施することが難しくなっていきます。NetApp ONTAP のファイルシステムでデータ管理を行なっている場合は、データブロックとポインタ情報を賢く扱うため、バックアップ・リストア・クローンが簡単に行えるようになります。
完全性を持ったバックアップを取得する方法については、関連する記事「Amazon FSx for NetApp ONTAPイミュータブルバックアップの利用でランサムウェア対策の強化」にて、改ざんできないバックアップ (Tamperproof Snapshot) 機能を紹介しています。

ランサムウェア攻撃を受けた際のデータリストアシナリオ

ランサムウェア攻撃を受けファイルサーバ内のデータが改ざんされてしまった場合、どのような復旧操作が必要となるでしょうか。被害のないバックアップデータからリストアする操作を行いますが、被害を受けたファイルサーバはどのような攻撃を受けたか調査を行う必要があるため上書きリストアすることはできません。
この状況下でファイルサーバを復旧するには、バックアップデータを新たな領域にコピーし復旧する操作が必要となってきます。NetApp ONTAP では Snapshot から高速でボリュームを複製する FlexClone 機能があります。

この FlexClone 機能を使いデータリストアテストを行ってみましょう。

Amazon FSx for NetApp ONTAP にてデータリストアテスト

攻撃を受けファイルが改ざんされた共有データ data2 があります。

図 2: クライアントのエクスプローラーでの共有データ data2 の確認

FSx for ONTAP ファイルシステムの管理エンドポイントに ssh でログインします。取得済みの Snapshot 一覧を表示し被害を受ける前の Snapshot データがあることを確認します。
::> snapshot show

図 3: Snapshot の確認

data2 の Snapshot を指定し FlexClone を data3 として作成します。
::> volume clone create -flexclone <Clone Volume Name> -type RW -parent-vserver <SVM Name> -parent -volume <Origin Volume Name> -parent-snapshot <Snapshot Name> -junction-active ture -junction-path /<junction-path>

図 4: volume clone の作成

data3 を参照すると改ざんされる前のファイルがリストアできていることが確認できます。

図 5: クライアントのエクスプローラーでの共有データ data2 のリストア確認

復旧した data3 を恒久的に利用する場合は親ボリュームと切り離し (split) 通常のボリュームにすることができます。Split 操作を行う場合、Split 操作にて追加で必要となる容量を確認します。
::> volume clone show -estimate -vserver <SVM Name> flexclone <Clone Volume Name>

図 6: volume clone の確認

FSx for ONTAP の空き容量を確認します。
::> storage aggregate show

図 7: FSx for ONTAP のファイルシステム容量の確認

ボリュームを Split します。
::> volume clone split start -flexclone <Clone Volume Name>

図 8: volume の split の設定

リストアテストが終了し、複製したデータが不要となった場合は以下の手順でクリーンナップすることができます。テストで使用した data3 ボリュームをオフラインにし、ボリュームを削除します。
::> volume offline <Clone Volume Name>
::> volume delete <Clone Volume Name>
::> volume show

図 9: volume のオフライン作業、削除、削除されたことの確認

まとめ

バックアップはランサムウェア攻撃を含む多くの有事に対する最後のかなめとして重要な位置づけにある中、意外とユーザが望む水準の状態まで復元できなかった企業が多いことがわかりました。NetApp としてはバックアップに関し一つ踏み込んだ形で、定期的にリストアまでのプロセスを含んだ一連の流れを実施することを推奨しています。その中で FSx for ONTAP 環境で出来るバックアップ・リストアについて Snapshot/FlexClone で実施する方法をご紹介させていただきました。

定期的に防災訓練のようにデータ復旧の一連の流れを実施することにより、バックアップの質のみならず有事の際の対応も早くなりランサムウェア攻撃等の被害を最小限にすることが可能と考えておりますのでぜひ実践下さい。