みなさん、こんにちは。
SB C&S 技術担当の小林です。

前回は、NetAppのランサムウェア対策機能「Autonomous Ransomware Protection with AI（ARP/AI）」と、ONTAP 9.17.1でSAN環境にも対応した流れについて整理しました。

その中で「なぜSAN環境でもランサムウェアを検知できるのか」と疑問に思われた方もいらっしゃるのではないでしょうか。
今回のブログでは、シリーズ第2弾のブロックアーキテクチャ編として、この問いを技術的な観点から整理します。

まず、ARP/AI for Blockの検出アーキテクチャを解説し、続いてSystem Manager上での有効化や検知時の動作を確認します。

さらに後半では、SAN環境における復旧設計の考え方についても触れます。

ARP/AI for Blockの検出アーキテクチャ

ランサムウェアを自動で検出して、検出時には、管理者へのアラート通知とSnapshotの取得を自動で行うという基本的な機能概要については、SAN環境でも、NAS環境でもいずれも共通です。

一方、SAN環境では検出アーキテクチャが異なります。

ここでは、ARP/AI for Blockの検出アーキテクチャについて、NAS環境との違いを中心に整理します。

まず前提として、NASとSANの違いを簡単に確認しておきます。
NASとSANとは、サーバーとストレージの接続形態の違いです。

細かい違いはありますが、NAS接続とは、ストレージ側がファイルシステムを管理し、ファイル単位でサーバーとデータのやりとりを行います。
一方、SAN接続はファイルシステムの管理がホスト（サーバー側）で行われ、ブロックというファイルよりも細かい単位でサーバーとデータのやりとりを行います。

つまりSANストレージではブロック単位のデータを認識しているため、拡張子、ディレクトリ構造といったファイルの情報はストレージ側からは見えません。

ではどのようにランサムウェアを監視しているのでしょうか？

前述の通り、NASボリュームではファイル単位で監視が可能なため、エントロピー、拡張子の種類、アクセスパターンなど、ファイル情報を加味した複数要素を組み合わせた検出が可能となっています。

一方、SANボリュームではファイルではなくブロックデータを対象とします。
そのため検出はボリューム単位で行われ、検出要素となるのは「書き込みデータのエントロピー変化」です。

ちなみに、エントロピーとは、データの"乱雑さ"や"ランダムさ"を数値化したものです。
通常の業務データはある程度の規則性を持っているため、エントロピーは比較的安定した状態にあります。
しかし、ランサムウェアによって暗号化されると、データは非常にランダムな状態へ変化します。
このときエントロピーは急激に上昇し、通常時とは明確に異なる傾向を示します。

ARP/AI for Blockは、このエントロピーの急激な変化を検知する仕組みです。

さらに、SAN環境でARP/AIを有効化すると、評価期間が設けられます。

この評価期間では、対象ボリュームのワークロードがランサムウェア保護に適しているかを判断するとともに、評価期間中に収集された統計情報に基づいて、その環境に最適な暗号化判定基準（しきい値）が自動的に決定されます。

なお、評価期間中であっても通常のARP/AIの動作は行われ、異常を検出した際はアラートが発報され、Snapshotが取得されます。

そして、ワークロードが保護に適していると判断された場合には、評価期間の統計に基づいて暗号化しきい値が自動設定され、そのボリュームの特性に合わせた保護が構成されます。

つまり、ARP/AI for Blockはそれぞれのワークロードの特性に合わせて、最適化されたかたちでデータを守っているのです。

最新のARP/AIについて

ここまで、SAN環境での検出アーキテクチャについて解説してきました。

実は、このARP/AIのアップデートはSAN環境への対応だけではないのです。

ONTAP 9.17.1から、ARPを有効化したボリュームには自動的に4時間毎のSnapshotポリシーの適用が行われるようになりました。

そして、さらにONTAP 9.18.1からは新規作成されたボリュームに対して、ARP/AIが自動有効化される仕様となりました。
自動有効化はボリューム作成後、12時間の猶予期間後に実行がされるため、12時間以内に無効化することも可能となります。
また、無効化後もSystem Managerから個別での有効化が可能になっています。

※二つのアップデートはNAS環境、SAN環境ともに適用されます。

こういった新しいARP/AIの仕様は、各種操作にどのような関わりがあるのでしょうか。
次の章では、アップデートされた点を含め各種操作方法を確認します。

各種UI画面及び操作方法

ここからは、ARP/AI for Blockが実装されたONTAP 9.17.1のSystem Manager上の画面を通して、有効化方法および検出時の動作等を確認していきます。

①有効化に関する操作

System Managerにログイン後、ARPを有効化したい任意のボリュームを選択

　ARPの有効化操作
　　→「セキュリティ」
　　→ランサムウェア対策の「アクティブモードで有効」を選択

　ARPの一時停止操作　
　　ARP有効化時のみ「セキュリティ」画面の右上に表示される「ランサムウェア対策を一時停止」を選択

これだけ強力なランサムウェア対策機能が数クリックで有効化できる点は大きな特長です。

前章でお伝えした通り、ONTAP 9.18.1からはARPがデフォルトで有効化されるようになりました。
デフォルト有効化設定を無効化した後は、このようにボリューム単位での有効化ができます。
そのため、お客様の要件に応じてARP/AIの有効化設定を柔軟に行えるのも魅力の一つになります。

②異常検知時の操作

　該当ボリュームのセキュリティ画面から
　　→「アクションを選択」
　　→管理者による確認後、以下A/Bを選択
　　　　
　　　　A. 実際の攻撃検出時の操作
　　　　　→「ランサムウェア検知の可能性としてマークする」を選択
　　　　　　　 ※その後の復旧手順は顧客ごとのポリシーに従い、操作していただくようお願いします。
　　
　　　　B. 誤検知時の操作
　　　　　→「誤検知としてマークする」を選択

検知イベントの発生状況をUI上で確認できる設計となっています。

③異常検知時の復旧に関する操作

　該当ボリュームのSnapshot画面から
　　→任意のSnapshotの「︙」をクリックして、顧客ごとの復旧ポリシーに従い、以下A/Bから選択
　　　※各種Snapshotの説明は画像下にございます。

　　　A. SnapshotのRestore操作
　　　　→「リストア」を選択
　　　　→「ボリュームのリストア」ポップアップ内、
　　　　　「このSnapshotからボリュームをリストアする」をチェック
　　　　→「ボリュームのリストア」ポップアップ内、「リストア」
　　　　　※手順のUI画像については次章で詳細含め、ご説明します。
　　　
　　　B. クローン生成（およびマッピング）操作
　　　　→「クローン ボリューム」を選択
　　　　→「クローン ボリューム」ポップアップ内、「クローン」
　　　　→左側メニュータブ「LUNs」
　　　　→生成したクローン ボリュームのLUNの「︙」
　　　　→「LUNの編集」
　　　　→「LUNの編集」画面内、「該当のigroup」をチェック
　　　　→「LUNの編集」画面内、「保存」
　　　　　※手順のUI画像については次章で詳細含め、ご説明します。

こちらも、前章でお伝えした通り、ONTAP 9.17.1以降、ARPを有効化したボリュームは、デフォルトで4時間毎のSnapshot取得ポリシーが適用される仕様となっています。

そのため、異常検知時には以下の2種類のSnapshotが存在します。

・Anti_Ransomware_Attack_backup.yyyy.mm.dd.hh.mm
　 ランサムウェア攻撃時(異常検知時)に取得されたSnapshot

・Anti_Ransomware_Periodic_backup.yyyy.mm.dd.hh.mm
　 ポリシー適用によりスケジューリング機能で定期的に取得されたSnapshot

ランサムウェアの進行速度にも依存しますが、一般的には以下の関係になります。

攻撃検出直後に取得される「Attack」Snapshotは最新の状態を保持しますが、
暗号化の進行状況によっては一部のデータが暗号化された状態を含んでいる可能性があります。

一方、攻撃検出直前の「Periodic」Snapshotは暗号化が一切行われていない状態でデータを保持している可能性が高いです。

この2種類のSnapshotの役割を理解することで、暗号化の進行度合いを見極めながら、お客様のポリシーに応じた復旧手順を設計することが可能となります。

SAN環境における復旧手順の一例

ここまで、操作画面とともに、AttackおよびPeriodicという2種類のSnapshotの役割を整理してきました。

前述の通り、これら2種類のSnapshotの特性を理解することで、暗号化の進行度合いを見極めながら、
お客様のポリシーに応じた復旧手順を設計することが可能となります。
そして、本章では、ストレージの仕様と検証結果をもとにした、2026年2月時点における最適な復旧手順について、ご紹介していきます。

復旧手順①：Attack SnapshotのRestore
　　　　　　これにより、検知時点までの最新状態を可能な限り維持したうえで環境を復旧し、
　　　　　　暗号化されているデータと健全なデータの確認および切り分けを行います。

復旧手順②：最新のPeriodic Snapshotから"クローン ボリューム"を生成し、復元対象のサーバーにマウント
　　　　　　マウント後は、①で特定した暗号化データをPeriodic Snapshot側から抽出することで、
　　　　　　影響を受けた部分のみを補完し、環境を可能な限り最新状態に近づけます。

NAS環境ではONTAPの機能により②の操作をファイル単位のリストアが実施できるため、復旧設計を取りやすい構成となっています。
しかし、SAN環境ではストレージ側がファイルシステムを管理していないため、同様の方法を取ることはできません。

また、2026年2月時点では、Attack Snapshotを保持した状態で攻撃検出直前のPeriodic SnapshotをSystem Managerから復旧することはできず、クローン生成のみが可能な仕様となっています。

そのため、上記のストレージ仕様等を踏まえて、現時点においては、本章で提示した復旧手順が最新かつクリーンなファイルを戻す最適な手段となっております。

まとめ

今回の内容はいかがだったでしょうか。

本記事では、ARP/AI for Blockの検出アーキテクチャからUI操作、そしてSAN環境における復旧の考え方まで整理しました。

ボリューム単位でエントロピー変化を監視することで、SAN環境でも暗号化という挙動を捉える仕組みが実装されています。
また、AttackとPeriodicという2種類のSnapshotを理解することで、状況に応じた復旧対応が可能になります。

次回は検証結果をもとに、ARP/AI for Blockの検知の特性について整理していきます。