これはどちらか一方ではなく、両方の準備が必要になります。
私の経験ではサイバー・セキュリティは既に多くのお客様が対策を講じられています
一方で、サイバー・レジリエンシーについては、これから検討を開始される方も多いかと思います。
そういった方のために、今回はサイバー・レジリエンシーで注意すべき点を解説していきます。

1. ランサムウェア対策における判断時間の壁
ランサムウェア対策において、多くの方が課題として挙げられるのは ランサムウェア被害に遭った際の早期復旧 です。
これはRTOの短縮と置き換えられるでしょう。こうした課題はストレージの機能(※)を使えば、技術的なリカバリー時間は極小化することができます。
しかし、早期復旧を目指す上で、機能面以外に見落とされがちな重要な要素があります。それは、 実際にリカバリーを実施するかの判断に要する時間 です。

※ IBM FlashSystemで提供可能なランサムウェア対策機能の解説ページ
FlashSystemのデータ保護

FlashSystemのランサムウェア兆候検知

2. 判断には時間がかかる
ランサムウェアの兆候を検知した瞬間、自動的にリカバリーの実行、あるいは即座に手動でリカバリーボタンを押せるでしょうか？
現実には決して簡単ではないはずです。

• 誤検知の確認: ログなどの他の情報からもランサムウェアの兆候があるかを確認し、本当に攻撃を受けているのかを特定
• 意思決定: 役員会や対策本部を招集し、業務停止を伴うリカバリーを本当に実施するのかを決断

これには数分ではなく、数時間(場合によっては半日以上)を要することになるでしょう。
つまり、どんなにリアルタイムで兆候を検知し、リストアが高速であっても、人の判断時間がリカバリーの時間(RTO)を大きく引き伸ばしてしまうのです。

3. RPOを視野に入れたデータ保護ポリシーの二重化
この判断のタイムラグを埋めるために有効なものが、データ保護間隔のポリシー設計を見直すことです。
具体的には、次にある二重のポリシーを軸に検討を進めてみてはいかがでしょうか？

• Hourly（1時間毎 × 6世代）： 直近のデータを保護し、リカバリーの判断が下りるまでの初動の6時間(半日)をカバー
• Daily（1日毎 × 7〜14世代）： 長期に渡るデータを保護し、潜伏期間の長期化や、判断が翌日以降に持ち越された場合をカバー

すべてを1時間毎で長期間残そうとすると、データ保護のためのストレージ容量が肥大化してしまいます。
直近は細かく、過去は粗く管理することで、リソース効率とRPOのバランスを最適化することができます。

4. Native機能と外部スケジューラーのハイブリッド構成
IBM FlashSystemでは、この構成を以下の組み合わせで実装可能です。

• Hourly：FlashSystemのネイティブ機能である内部スケジューラーを使用する
• Daily：CSM(Copy Services Manager)を仮想マシン上のサーバーなどに導入し、稼働させる

ここで重要な技術的注意点があります。管理プレーン(指令元)が分かれていても、最終的に発行するのは同じFlashSystem内のコマンドです。
もし、両方のスケジュールが重なってしまう(例：00時00分に両方が走る)と、コマンドが競合し、エラーとなるリスクがあります。
これを回避するため、 設計時には必ず実行時刻のオフセットをする設計 をしてください。(例：Nativeは毎時00分、CSMは毎日00時15分に実行するなど)

5. 最後に
ランサムウェア対策は、単に高機能なストレージを導入するだけでは完成しません。
人が判断する時間 という実際の運用を加味した設計こそが、有事の際に会社を救う鍵となります。