QuTS hero 6.0におけるイミュータブルスナップショットとストレージプール削除についての質問

QNAPチームおよびコミュニティの皆様へ

QuTS hero 6.0で導入された**イミュータブルスナップショット(immutable snapshots)**に大変興味を持っており、最近は日本語の記事(原幸人氏、LinkedIn Japan)でこの機能の詳細な検証を拝見しました。その記事によると、イミュータブルスナップショットはSSH経由やroot権限でも削除できないことが示されています。

このことから、イミュータブルスナップショットは、誤削除だけでなく**侵害された管理者アカウントによる悪意ある、または不正な操作(例:ランサムウェア攻撃時)**からもデータを保護することを意図していると理解しています。

しかし、ここで重要な概念的疑問が生じます。

イミュータブルスナップショットを含むストレージプール全体を管理者が削除することは可能でしょうか?
もし可能であれば、プールを削除することで、保護ポリシーに関係なく全ボリュームやスナップショットが消去され、イミュータビリティの概念が実質的に損なわれることになりませんか?

念のため明記しますが、
ハードウェアの物理的破壊やディスクの取り外しなど、物理的アクセスがあれば防げないことは十分理解しています。私が質問しているのはそれではありません。

私の質問は、OS内での論理的な保護についてのみです:

  • イミュータブルスナップショットは、rootでも削除できないよう保護されています。

  • しかし、ストレージプールレベルで、イミュータブルスナップショットの保持期間中にプールの誤削除や悪意ある削除を防ぐようなセーフガードは現状存在しますか?または今後導入予定はありますか?

言い換えると:

  • 現在の設計は、スナップショット/ボリュームレベルの保護に意図的に限定されていますか?

  • それとも、将来的にプールレベルでの破壊的操作も防ぐようなイミュータビリティ保証の拡張が計画されていますか?

想定する脅威モデルや設計方針について、ご説明いただけますと幸いです。

この重要な新機能のご提供とお時間に感謝いたします。

よろしくお願いいたします。

「いいね!」 1

コミュニティへようこそ。私はまだ hero 6 を使用していませんが、私の見解を述べます。

ストレージプールを破壊したり変更したりすることに対する「保護」はありません。WORM(Write Once Read Many)イミュータビリティは共有フォルダ単位、また hero 6 の場合はスナップショット単位でも設定されます。WORM 構成では、すべてのフォルダがイミュータブル(不変)に設定されているわけではありません。そうしたくはないでしょう。そうすると、NAS 上の何も削除や変更ができなくなってしまいます。

さらに、イミュータビリティは期間を限定することもできます。たとえば、ファイルが書き込まれてから 5 日間ロックされるフォルダを作成することも可能です。その期間が過ぎればロックは解除されます。他の設定では、すべてを永久にロックしたままにすることもできます。

ストレージプール単位でイミュータビリティを設定したいとは思わないでしょう。それではストレージプールに容量を追加することなどができなくなってしまいます。

WORM はランサムウェア攻撃からファイルを守るのに役立ちます。ファイルは変更できません。たいていの場合、NAS に侵入した攻撃者はファイルを感染させて、あなたから金銭を脅し取ろうとします。彼らはプールを消去して破壊することには時間をかけません。もしそうした場合、すべてのファイルが消去されてしまい、あなたを脅迫する材料がなくなってしまうからです。つまり、彼らの目的に反します。さらに、こうした攻撃は迅速に広がることが求められます。システムに侵入し、マルウェアを拡散させてすぐに離脱します。プールの消去にははるかに多くの労力と作業が必要です。

以上が私の見解であり、「公式」なものと受け取らないでください。

貴重なご意見をいただき、誠にありがとうございます。ご指摘いただいた点につきましては、社内チームにて今後の評価と分析のために共有いたします。

こんにちは、NA9Dさん。私の問い合わせにご返信いただきありがとうございます。

念のため、少しだけ確認させてください。イミュータブル・スナップショット(immutable snapshot)という概念の内部ロジックについて少し混乱しています。私の理解では、システムの小さな単位を「管理者権限が侵害された場合でも不変でなければならない(最大限の非物理的保護を提供するため)」と定義するならば、この原則は階層全体(つまりストレージプールレベル)に波及しなければならず、そうでなければイミュータビリティ(不変性)が損なわれると思います。私にとって、これは「現在イミュータブルなファイルが保存されていない場合のみ削除が許可される」といった形で、重要なストレージプール操作に対して実装がチェックを強制すべきであることを意味します。

攻撃ベクトルに関するご質問についてですが、ほとんどの攻撃は、恐喝の論理からファイルを削除したがらないというご意見には同意します。しかし、アクセス権を持つ高度な攻撃者が、削除前にファイルを自身のインフラにコピーし、「支払わなければファイルは戻らない」という同じ恐喝の論理を使う可能性も考慮すべきです。

あなたの言っていることは理解できます。しかし、ストレージプールを再構成できないようなイミュータブル(不変)なシステムは望みません。つまり、一度設定したらそれが固定されて、二度と変更できないということですよね。それだと、プールの拡張もできないし、データを新しい大きなプールに移したいからプールを削除することもできません。あなたの提案には多くの問題があります。イミュータブルファイルだけでも十分面倒です。私は、あるフォルダにファイルをコピーしようとして、間違えてイミュータブルなフォルダにコピーしてしまったことがあります。その結果、ファイルが2つの場所に存在し、1つは本来置きたくなかった場所にあります。もしこれをプールでうっかりやってしまったらどうなるでしょうか?

悪意のある第三者が、時間をかけて大量のファイルを自分たちのインフラにコピーしようとするとは到底思えません。仮にやったとしても、特にNASが適切なバックアップ戦略を持っていれば、それはほとんど意味がありません。